Re: EXTERNAL: Re: [vhdl-200x] RE: Modular types

From: <whygee@f-cpu.org>
Date: Mon Aug 04 2014 - 03:18:02 PDT
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