Prev: DCM
Next: bit vs std_logic (was Re: Simulation of VHDL code for a vendingmachine)
From: whygee on 18 Jan 2010 11:36
Hi,

Gabor wrote:
> On Jan 17, 7:49 pm, KJ <kkjenni...(a)sbcglobal.net> wrote:
>>> In the end,
>>> it more a matter of preference than anything. If you like the format
>>> of your code using Booleans, go ahead. There are no real roadblocks
>>> to using them.
>> In the end, the main advantage of std_logic is with unknowns.
>> Booleans will initialize themselves to 'False', std_logic to 'U'.
>> Proving that your design does not depend on a lucky initialization
>> value happens when you use std_logic not booleans.
>>
>> Kevin Jennings
>
> Interestingly enough, for FPGA synthesis, the boolean will
> more closely resemble the final hardware. "Uninitialized"
> logic in an FPGA generally defaults to zero, at least for
> Xilinx XST. There may be some architectures that don't
> initialize every register and memory bit in the configuration
> bitstream, but I haven't run across them yet.

But if we assume that the registers are correctly initialised
by a correct Reset signal, and the design is verified with std_logic,
a higher-level simulation (that deals more with using already
tested sub-functions), then we could swap the std_logic
with "bit"-based types to increase simulation speed ?

I'm diving into GHDL which is not as fast as, say... ncsim,
but has much more potential for me, so simulation time matters.
Not much yet but if I can cut the simulation time by one half,
simply by defining my signals differently, I take it :-)
I'm considering writing a couple of similar VHDL packages
that define local types for the wires, one that uses bits
and the other std_logic : I'm curious to see the simulation
speed difference.

Note that, with a nice simple testbench with clean signals and edges,
dirty setup conditions with /RESET don't usually happen,
so I don't expect Us or Xs to propagate through the whole design ;-)

Has anyone already explored this path ?

> Regards,
_o/
> Gabor
yg

--
http://ygdes.com / http://yasep.org
From: Kolja Sulimma on 18 Jan 2010 13:25
On 18 Jan., 17:36, whygee <y...(a)yg.yg> wrote:

> I'm diving into GHDL which is not as fast as, say... ncsim,
> but has much more potential for me, so simulation time matters.
> Not much yet but if I can cut the simulation time by one half,
> simply by defining my signals differently, I take it :-)
> I'm considering writing a couple of similar VHDL packages
> that define local types for the wires, one that uses bits
> and the other std_logic : I'm curious to see the simulation
> speed difference.

Note that a lot of the simulation time is take up by resolution
functions.
STD_ULOGIC should be a lot faster than STD_LOGIC.
As there are no tristates in FPGAs anyway nowadays there is hardly
any reason to use STD_LOGIC at all.

Kolja Sulimma
From: Jonathan Bromley on 18 Jan 2010 13:36
On Mon, 18 Jan 2010 17:36:07 +0100, whygee wrote:

>Note that, with a nice simple testbench with clean signals and edges,
>dirty setup conditions with /RESET don't usually happen,
>so I don't expect Us or Xs to propagate through the whole design ;-)
>
>Has anyone already explored this path ?

I haven't, but it has been thoroughly explored in the
verification literature. That's one of the reasons why
SystemVerilog added 2-state variables (int, bit) to the
language; VHDL has had 2-state integer, bit and boolean
from the outset, of course.

There is some strong evidence to suggest that X-simulation
is not only inconvenient because spurious Xs tend to
chase around the design when in reality it's OK, but also
they can give rise to unjustified optimism because of
the way certain RTL control constructs handle X inputs.
For example, in Verilog...

if (mode2)
do_mode2_stuff;
else
do_mode1_stuff;

If (mode2) is 1'bx in RTL simulation, the if() statement
will take its else-branch and the simulation will act
exactly as if (mode2) was zero.

So an alternative, which has been reported as giving
good results, is to use 2-state simulation **but to
randomize the values of all register variables at
startup**. If you use different seeds for the
randomization, you can simulate the design with a
wide range of startup values and therefore can see
whether it will reliably come out of reset. This
works nicely for ASIC designs where flip-flops
may power-up in an unknown state but the design
is nevertheless well-behaved. Consider, for example,
a simple clock divide-by-2 that has no reset - it
shoudl be OK in practice, but will be stuck at X
in a 4-state traditional simulation.

I believe that some simulators offer this startup
randomization as an option.

For a nice discussion of the drawbacks of 4-state
simulation, see Mike Turpin's survey at
http://www.arm.com/pdfs/Verilog_X_Bugs.pdf
The paper discusses Verilog, but many of the same
ideas map on to VHDL (although a lot of the details
are different).
--
Jonathan Bromley
From: whygee on 18 Jan 2010 13:39
An interesting thread is probably coming,
should we Xpost to comp.lang.vhdl ?

Kolja Sulimma wrote:
> Note that a lot of the simulation time is take up by resolution functions.
> STD_ULOGIC should be a lot faster than STD_LOGIC.
> As there are no tristates in FPGAs anyway nowadays there is hardly
> any reason to use STD_LOGIC at all.

That's what I thought. But recently (this summer)
I have been told to use STD_LOGIC anyway,
I don't remember why. There is hardly any
modification to my existing code because
I don't rely on resolution functions
or multiple-driver behaviour.
It was a pain (as anything VHDL-related)
to change all the declarations and interfaces
(both in the designs and the testbenches)
but it simply worked.

But this was only for synthesis.
I am wondering now what to do for high-level
simulations, when all the std_logic-ness
does not play any role anymore.
And with GHDL, for which integer directly maps
to the same C idiom, there are certainly
a lot of things to win (space, time)...

> Kolja Sulimma
yg

--
http://ygdes.com / http://yasep.org
From: rickman on 18 Jan 2010 20:25
On Jan 18, 2:51 pm, whygee <y...(a)yg.yg> wrote:
> Mike Treseler wrote:
> > whygee wrote:
> >> But recently (this summer)
> >> I have been told to use STD_LOGIC anyway,
> >> I don't remember why.
>
> > That is the common default for bits.
>
> ?
>
> > The *only* advantage is it covers tristate signals.
>
> sure. But I don't have/need tristates.
>
> > Otherwise std_ulogic can detect multiple drivers
> > at compile time and has no downside
> > as it is 100% compatible with std_logic.
>
> I still don't remember how/why I was convinced to drop ulogic
> but I switched anyway.
> It was probably something about externally provided
> (or proprietary/manufacturer-specific) code interface...
>
> > Vectors are a more complicated story.
>
> I don't see what could go wrong...
>
> well, except this whole mess with
> integer/signed/unsigned/bit_vector/std_logic_vector/std_ulogic_vector
> translations/type casts :-/
>
> >      -- Mike Treseler
>
> yg
>
> --http://ygdes.com/http://yasep.org

After struggling with VHDL type casting for some time, I finally
settled on using signed/unsigned for the majority of the vectors I
use. I seldom use integers other than perhaps memory where it
simulates much faster with a lot less memory. But nothing is
absolute. I just try to be consistent within a given design. I have
never used bit types, but the discussion here about the advantages of
ulogic over logic is interesting. I certainly like to speed up my
simulations. But it is such a PITA to get away from std_logic. I
don't recall if ieee.numeric_std converts between ulogic and the
signed/unsigned types. It is so verbose to use multiple conversions
in one assignment.

Rick
 |  Next  |  Last
Pages: 1 2
Prev: DCM
Next: bit vs std_logic (was Re: Simulation of VHDL code for a vendingmachine)