Re: [vhdl-200x] Modular types

From: <whygee@f-cpu.org>
Date: Thu Jun 26 2014 - 00:51:24 PDT
Le 2014-06-25 16:17, Martin.J Thompson a écrit :
> Greetings all,

Hello !

> Bitwise "and", "or", "xor" and "not" are all defined for modular types
> (which is good).

It's not "good".
It's "why did I have to wait for this essential feature ?" :-)

> Ada has limits on the maximum range of a modular type, but I would be
> tempted to say we shouldn't add one to VHDL, to allow for large bit
> vectors to be modelled.
yes.

I guess a simulator implementation can chose between
a scalar or vector implementation (bignum ?) since the size is known
at run time.

> At the very least I think we should allow for
> bit vectors of the length of current applications (such as crypto) and
> add a few bits for expansion.

Concerning crypto i've been playing with adding boolean operations to 
the "integer" type
http://ygdes.com/GHDL/int_bool/  (uses GHDL and custom C extensions)
and the speedup on crypto is stunning. I expect other applications
to benefit from this kind of "new feature" and help close the 
performance gap
with system description languages.

In practice I've run into issues when the "integer" size is not the same
as (smaller than) the bitvector I want to simulate, so I hope that the 
"modular" type
will help avoid these problems.
For example : I use a Integer to simulate a bit_vector(3 downto 0),
so i declare a range 0 to 15.
now take this variable or signal and negate its value : it is now out of 
range
because it sets the MSB to 1.
that's why I chose a 32-bits only based "testbench" (SHA-1).
In practice I develop CPU cores and I need all kinds of bit vector 
lengths...

> So, are there any features you would like which are not mentioned?
> Constraints which do not make sense?

Please don't forget the shifts and rotations, or I'll still have to use
my dirty hacks and write non-portable VHDL source code just because it
simulates 400x faster.

> Cheers,
>  Martin

Regards,
YG

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Jun 26 00:51:42 2014

This archive was generated by hypermail 2.1.8 : Thu Jun 26 2014 - 00:51:49 PDT