Jan Decaluwe explains this clearly in one of his suggestions, and which I also agree: -- JanDecaluwe <http://www.eda-twiki.org/cgi-bin/view.cgi/Main/JanDecaluwe> - 2014-11-02 My suggestion is to implement this similar to vector types: allow unconstrained types (e.g. UNIVERSAL_INTEGER) in interfaces, but require finite constraints at elaboration time. This would provide the modeling advantages of arbitrary length integers while keeping the advantage of a compiled language: the elaborator/compiler could perform optimizations based on the constraints. This should address any performance concerns. On 10 January 2015 at 15:27, Daniel Kho <daniel.kho@tauhop.com> wrote: > Tristan, > As from what I understand from the ArbitraryIntegers proposal, it is not > suggesting to have infinite precision integers at simulation/elaboration > time. It is merely suggesting to have unconstrained integers (yes, infinite > precision if you may) prior to being constrained later at a higher-level > hierarchy of the design, which makes the design synthesizable and finite. > > -daniel > > > On 10 January 2015 at 15:13, Tristan Gingold <tgingold@free.fr> wrote: > >> On 10/01/15 07:46, Daniel Kho wrote: >> >>> This is one of the reasons I am supporting the proposal for extended or >>> arbitrary-length integers: >>> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ArbitraryIntegers >>> >> >> I still think this proposal is not clear enough. If infinite precision >> integers (at simulation time) are proposed, that's awful from a >> performance point of view. >> >> I repeat: I am ok with infinite precision at analysis time, and >> not against any but fixed precision at simulation time; but >> certainly not ok with infinite precision at simulation time. >> >> All integer types must have bounds. >> >> >> Tristan. >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> >> > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sat Jan 10 00:01:35 2015
This archive was generated by hypermail 2.1.8 : Sat Jan 10 2015 - 00:01:54 PST