Le 2014-08-04 09:49, Brian Drummond a écrit : > On Mon, 2014-08-04 at 08:03 +0200, tgingold@free.fr wrote: >> But you can do such experiment already today (and even with vhdl 87): >> declare a record type with one integer element, add declare all the >> operations you need: +, -, and, or, ... >> No need to perverse an existing feature to do experimentations. I would think that this "feature" itself is perverse, but for my own personal reasons :-P I have not seen it done, it's not a "classic pattern" because usually, users try to "stick to the least common denominator" and some tools might not even know what a record is. it might work with synthesis and the result of the simulation will be "correct" with moderate code complexity. However Brian has a point there : > I think Whygee's point is that while there are ways of experimenting > with the semantics today, using records, what he wants is the > performance of native boolean/shift operators on integer-like > quantities. So, in the case of GHDL, being able to emit "OR"/"AND"/"XOR"/"NOT"/etc. opcodes to GCC. > My suspicion is that adding modular types natively will get close to > the > performance gain he wants (compiling down to native machine > instructions), but that adding the semantics via heavier tools like > resolution functions - or records - might add most of the performance > penalty of signals over variables and thus destroy what he wants to > accomplish. There is that. But... It also overlooks one detail : the functions I request are not present, allowed or even remotely "emulable" with VHDL integers. I've covered the difficulty of doing basic boolean operations a few years ago (for example, shifts with divides and multiplies with powers of two...) and the actual result was worse than using std_logic_vector. A "clean" modular (sub/whaterver)type would solve most of these problems and VHDL would be a language that people could use for doing actual fast simulations, instead of being forced to use other languages or FPGA. Just the other day, a colleague complained that it was so slow (simulating a whole SoC to boot OS code) that it was faster to synthesise a FPGA and add manual probbes. > Your vastly greater knowledge of a simulator implementation may shed > some light on this. It seems that this discussion shows the limits of understanding of VHDL. I know what I need, what it should look like but the implementation is beyond me. I hope Tristan and others help us find the path of least effort/resistance/risk for implementing those necessary features :-) > - Brian yg -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Aug 4 03:19:14 2014
This archive was generated by hypermail 2.1.8 : Mon Aug 04 2014 - 03:20:26 PDT