Subject: Re: [sv-ec] Re: [sv-bc] Packed arrays
From: Michael McNamara (mac@verisity.com)
Date: Fri Jan 31 2003 - 15:20:09 PST
Steven Sharp writes:
>
> >There doesn't appear to be a good reason why you can't connect
> >packed structs through ports to me, but I don't need to since I
> >can put the struct in an interface and share it that way.
>
> Which may be sufficient for your needs. However, variables shared
> via an interface don't provide all the capabilities that HW
> designers get with nets: things like driver resolution, net delays,
> path delays, interconnect delays and SDF back annotation.
>
>
> >Well, since people build hardware that processes reals as well as
> >ints I see no reason for making a distinction.
> >
> >How would you describe a bus carrying a double value as well as
> >other values?
>
> As Mac pointed out, HW designers don't build hardware that processes reals.
> They build hardware that processes the bits that represent floating point
> numbers in the format that their hardware is designed for.
>
> If someone is working with Verilog reals as data, they are working with
> abstractions. There is no reason to require that they be mapped to a
> particular hardware representation as a vector of bits. So there is no
> reason to require them to be allowed in a packed struct. And if they were
> allowed in a packed struct, there would be no reason to require a particular
> bit layout.
>
> If I was working with an abstraction that I wanted to be able to use to
> hold/carry a real as well as other values, I would use a non-packed struct.
>
> Steven Sharp
> sharp@cadence.com
>
And indeed, most hardware designers actually designing logic that
needs to deal with floating point numbers don't actually use IEEE 754
double precision!
I am not trying to say that no designers build 754 compliant logic (I
did a bit of this myself back in the 1980s); instead it is the case
that the ones that do work are the select few that work in the CPU
groups at Intel (x86), at Sun (sparc), at IBM (PowerPC) and so on.
The large majority of teams today that build floating point hardware
are building perhaps a graphics chip, that they have determined needs
just 12 bits of precision in the mantissa to render circles to pixels
that will fit on your 1200x1600 computer screen; because a 12 bit
mantissa is sufficient for the task at hand, and more importantly with
just 12 bits of precision, they can complete the multiplies and square
roots quickly enough to render real time Mario Brothers graphics on
your PlayStation2.
Signal processing designers are another set where custom FP hardware
is designed; and again they will likely pick an exponent and mantissa
that is sized to their particular performance and gate count
requirements; and this size will most likely not be 1.11.52 of IEEE
754 double precision.
And even if one truly is designing IEEE 754 compliant hardware, there
is no way that design compiler is going to map
real a,b,c;
assign a = op == DIV ? b/c : op == MPY ? b*c : op = ADD ? b+c : 0.0;
into the kind of hardware that these teams would have any interest in
using. Maybe behavorial compiler, or CynApps and the like could do
(have done) this; but even then one would need a ton of directives to
get the tool to select the right parts and sizes and so on.
This archive was generated by hypermail 2b28 : Fri Jan 31 2003 - 15:21:01 PST