Subject: Re: [sv-ec] Re: [sv-bc] Packed arrays
From: Steven Sharp (sharp@cadence.com)
Date: Wed Jan 29 2003 - 16:10:07 PST
>From: Michael McNamara <mac@verisity.com>
>Those of us actually design floating point hardware (I was indeed one
>of these people) instead fully specified our wallace trees and
>fp_inexact bits setting logic and the like 100% in bits and vectors.
I could imagine that if you were designing IEEE standard floating point
hardware, you might use Verilog real arithmetic to compute "correct"
results to compare with your output in the testbench. But otherwise I
don't see why anyone would need access to the bits of a real.
>Going further and making simulator vendors insert extra code to
>shuffle the bits to get a mandated intermediate representation would
>make the simulators go slower (as currently is the case as one must do
>this to support the what I always assumed was the VAX represenation of
>byte strings used for memories that Verilog-XL made visible to end
>users in the tf_nodeinfo() call in the pli), with no benefit to
>anyone.
I agree. That tf_nodeinfo() memory layout has indeed been an issue for
performance. It turns out that the bytes are backward from vpi_vecval
on big-endian machines like the Sun and HP. As part of the Verilog-2001
changes, we are going to require a switch to get that tf_nodeinfo layout,
so we can run faster otherwise. I expect to gain a few percent in speed
on some testcases. Requiring a specific layout that may not match the
native data layout will hinder performance.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2b28 : Wed Jan 29 2003 - 16:16:17 PST