On Jan 18, 8:49=A0am, Gabor
<ga...@alacron.com> wrote:
> On Jan 17, 7:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > > In the end,
> > > it more a matter of preference than anything. =A0If you like the form=
at
> > > of your code using Booleans, go ahead. =A0There are no real roadblock=
s
> > > 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. =A0"Uninitialized"
> logic in an FPGA generally defaults to zero

And when that first clock cycle comes along right after configuration
that nicely initialized value of zero is overwritten...and that first
clock edge happens to violate the setup time of the flop(s)...and you
use that flop in a feedback path (like a state machine) and you
neglected to add a reset term...well, you might well appreciate the
value of an 'X' in simulation after all

While it's true that boolean more closely models reality in that real
digital logic only has two values, the reality is that the tools and
data types are abstractions to help one engineer a robust design.
Things that assist in finding design errors earlier are a good thing.

Kevin Jennings

On Jan 18, 8:49=A0am, Gabor
<ga...@alacron.com> wrote:
> On Jan 17, 7:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > > In the end,
> > > it more a matter of preference than anything. =A0If you like the form=
at
> > > of your code using Booleans, go ahead. =A0There are no real roadblock=
s
> > > 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. =A0"Uninitialized"
> logic in an FPGA generally defaults to zero, at least for
> Xilinx XST. =A0There 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.

This is an interesting issue.  I deal with this by always initializing
registers which should be good enough to control a simulation and
should match what happened inside the FPGA.

As to Booleans, do they ever get implemented as False =3D High?  Some
parts I have worked with do not have inverters in some spots which
then require that the signal sense be flipped to eliminate a LUT used
as an inverter.  I would think the hardware default of the Boolean
would then not be a False.  Oh, maybe this is moot.  On further
reflection, the case where the signal is inverted is when the initial
state of the FF is High and the part has no set capability!  So that
wouldn't be an issue in this case.  But are there other times when a
Boolean would be inverted?

Rick

Hi,

Gabor wrote:
> On Jan 17, 7:49 pm, KJ <kkjenni...@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

On 18 Jan., 17:36, whygee <y...@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

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

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

Jonathan Bromley wrote:
> On Mon, 18 Jan 2010 17:36:07 +0100, whygee wrote:
>> Has anyone already explored this path ?
> 
> I haven't, but it has been thoroughly explored in the
> verification literature.
Can you point me to any online paper or website about this subject ?

>  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.
yes, the ADA legacy has some good advantages :-)

> 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,
I've seen this too, the false positives are quite annoying :-/

> 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.
heh, good point !

> 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.
I've explored this around 2001 :-)
and I have then run into file read issues
from VHDL and compatibility issues with
different simulators. But it worked quite
well on a few platforms.


> 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).
i'll check that, thanks !

yg
-- 
http://ygdes.com / http://yasep.org

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

whygee wrote:

> 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.

That is the common default for bits.
The *only* advantage is it covers tristate signals.
Otherwise std_ulogic can detect multiple drivers
at compile time and has no downside
as it is 100% compatible with std_logic.
Vectors are a more complicated story.

      -- Mike Treseler

On Jan 18, 2:51=A0pm, whygee <y...@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 :-/
>
> > =A0 =A0 =A0-- 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