Synthesis results when testing for 'X' and 'U'

Sometimes it can be a bit tricky to stop 'X's and 'U's creeping into
the logic, especially at startup initialisation. If any logic tries to
use these values then Modelsim cheerfully spawns lots of warnings.
I've written a function called clean() which goes through a vector and
replaces any 'X' or 'U' values with '0'. This sorts out alot of
Modelsim problems but I'm slightly worried about any unintended
effects on synthesis. It does seem to synthesise without any problems,
but can I rely on this for all synth tools or even future XST
releases?

Is a better solution to meticulously make sure all registers are
initialised when they are declared? or is it perfectly safe not
necessarily poor coding practise?

Cheers
Rob

You simulation model should match the behaviour of your hardware,
otherwise it is useless.
Modern FPGAs initialize all registers upon poweron. You models should
reflect that.
Just initialize the signales at declaration and you are done.

In many ASIC libraries and some older FPGAs the initial values of
registers are random. 'X' is the
perfect representation for that. You definitely want the 'X's in your
simulation in that case because
it is the only way to make sure that your circuit works correctly even
with random start values.
Your circuitry must be design so that all flip-flop eventually obtain
defined states.

Kolja Sulimma


On 18 Jun., 13:25, Rob <BertyBoos...@googlemail.com> wrote:
> Sometimes it can be a bit tricky to stop 'X's and 'U's creeping into
> the logic, especially at startup initialisation. If any logic tries to
> use these values then Modelsim cheerfully spawns lots of warnings.
> I've written a function called clean() which goes through a vector and
> replaces any 'X' or 'U' values with '0'. This sorts out alot of
> Modelsim problems but I'm slightly worried about any unintended
> effects on synthesis. It does seem to synthesise without any problems,
> but can I rely on this for all synth tools or even future XST
> releases?
>
> Is a better solution to meticulously make sure all registers are
> initialised when they are declared? or is it perfectly safe not
> necessarily poor coding practise?
>
> Cheers
> Rob

On Jun 18, 7:57 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:
> You simulation model should match the behaviour of your hardware,
> otherwise it is useless.
> Modern FPGAs initialize all registers upon poweron. You models should
> reflect that.
> Just initialize the signales at declaration and you are done.
>
> In many ASIC libraries and some older FPGAs the initial values of
> registers are random. 'X' is the
> perfect representation for that. You definitely want the 'X's in your
> simulation in that case because
> it is the only way to make sure that your circuit works correctly even
> with random start values.
> Your circuitry must be design so that all flip-flop eventually obtain
> defined states.
>
> Kolja Sulimma

You have just argued against yourself.  You have told him to
initialize registers in the declaration, then you say you want Xs to
represent arbitrary initialization.  This arbitrary initialization is
what the X is intended to represent, an unknown state.  If you really
want to model the hardware, you need to *never* initialize registers
in the declaration, but rather initialize them in an async reset
portion of the process.  Then any that you miss show up as Xs and any
that you properly initialize should be synthesized that way.

Rick

On Jun 18, 1:38 pm, rickman <gnu...@gmail.com> wrote:
> On Jun 18, 7:57 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:
>
>
>
> > You simulation model should match the behaviour of your hardware,
> > otherwise it is useless.
> > Modern FPGAs initialize all registers upon poweron. You models should
> > reflect that.
> > Just initialize the signales at declaration and you are done.
>
> > In many ASIC libraries and some older FPGAs the initial values of
> > registers are random. 'X' is the
> > perfect representation for that. You definitely want the 'X's in your
> > simulation in that case because
> > it is the only way to make sure that your circuit works correctly even
> > with random start values.
> > Your circuitry must be design so that all flip-flop eventually obtain
> > defined states.
>
> > Kolja Sulimma
>
> You have just argued against yourself.  You have told him to
> initialize registers in the declaration, then you say you want Xs to
> represent arbitrary initialization.  This arbitrary initialization is
> what the X is intended to represent, an unknown state.  If you really
> want to model the hardware, you need to *never* initialize registers
> in the declaration, but rather initialize them in an async reset
> portion of the process.  Then any that you miss show up as Xs and any
> that you properly initialize should be synthesized that way.
>
> Rick

This is exactly the problem, i'd rather not give certain registers
init values, especially in the data path, as firstly it is unnecessary
for the actual hardware implementation and secondly because in
simulation seeing a vector of 'X's indicates that this bus hasn't yet
been assigned a proper value. The problem comes when that data bus is
driving a process that says something like "if data_bus = 0 then...".
I can usually avoid this with clock enables, but sometimes it isn't
convenient to have a clock enable signal with the data.

On Wed, 18 Jun 2008 04:57:04 -0700 (PDT), Kolja Sulimma
<ksulimma@googlemail.com> wrote:

>In many ASIC libraries and some older FPGAs the initial values of
>registers are random. 'X' is the
>perfect representation for that. You definitely want the 'X's in your
>simulation in that case because
>it is the only way to make sure that your circuit works correctly even
>with random start values.
>Your circuitry must be design so that all flip-flop eventually obtain
>defined states.
>
I completely agree with this : you want to see that any initial "X"es
are  cleared to valid values in a few cycles after reset, BY THE LOGIC
ITSELF and not a spurious "clean" function.

The disadvantage is that I typically have to live with pages of warnings
from the first 200ns or so (until all "X"es are purged from the
pipeline) followed by a clean simulation.

There are options in some libraries (numeric_std for one) in Modelsim to
suppress these warnings; but this carries the risk of suppressing real
information. So I don't think that's a good idea either.

I just ignore them... (actually I pay a LITTLE attention to reducing
their number, but it's not important) ... but wouldn't it be nice to
tell the simulator to suppress these errors for the first XXX ns, then
report them.

I expect a simple TCL script would do it...

suppress Numeric_Std invalid value warnings;
run 250 ns;
enable Numeric_Std invalid value warnings;
run;

but haven't taken the time to learn enough TCL to try 
(my testbenches are entirely VHDL and that keeps me busy enough!).

- Brian

On 18 Jun., 14:38, rickman <gnu...@gmail.com> wrote:
> On Jun 18, 7:57 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:
>
>
>
> > You simulation model should match the behaviour of your hardware,
> > otherwise it is useless.
> > Modern FPGAs initialize all registers upon poweron. You models should
> > reflect that.
> > Just initialize the signales at declaration and you are done.
>
> > In many ASIC libraries and some older FPGAs the initial values of
> > registers are random. 'X' is the
> > perfect representation for that. You definitely want the 'X's in your
> > simulation in that case because
> > it is the only way to make sure that your circuit works correctly even
> > with random start values.
> > Your circuitry must be design so that all flip-flop eventually obtain
> > defined states.
>
> > Kolja Sulimma
>
> You have just argued against yourself. =A0You have told him to
> initialize registers in the declaration, then you say you want Xs to
> represent arbitrary initialization. =A0

Did you actually read my post? I explained two cases: Hardware that
starts with defined values, and hardware that starts with random
values. Of course you model those differently.
The OP did not mention the target technology so I had to explain both
cases.


> =A0If you really want to model the hardware, you need to *never* initiali=
ze registers
> in the declaration, but rather initialize them in an async reset
> portion of the process. =A0Then any that you miss show up as Xs and any
> that you properly initialize should be synthesized that way.

That is true for most ASIC libraries, but not for Xilinx FPGAs. (I
don't know much about Altera).  Xilinx explicitely discourages the use
of asynchronous resets on is flip-flops.
http://www.xilinx.com/support/documentation/white_papers/wp231.pdf
Page 3: "Avoid asynchronous reset because it prevents packing of
registers into dedicated resources and affects performance,
utilization, and tool optimizations."

http://toolbox.xilinx.com/docsan/xilinx10/books/docs/sim/sim.pdf
Page 67:
"All architectures support an asynchronous
reset for those registers and latches. Even though this capability
exists, Xilinx does not recommend that you code for it. Using
asynchronous resets may result in:
=95 More difficult timing analysis
=95 Less optimal optimization by the synthesis tool"

All DFFs are initialized at configuration time. If not specified
otherwise in the HDL code they are initialized to '0'.  The simulation
model should be consistent with this hardware behaviour.

Kolja Sulimma

On 18 Jun., 14:48, Rob <BertyBoos...@googlemail.com> wrote:
> This is exactly the problem, i'd rather not give certain registers
> init values, especially in the data path, as firstly it is unnecessary
> for the actual hardware implementation
But you can't prevent it in a modern FPGA. Why should you explicitely
build a model that does not reflect the actual behaviour of the
hardware?

> and secondly because in
> simulation seeing a vector of 'X's indicates that this bus hasn't yet
> been assigned a proper value. The problem comes when that data bus is
> driving a process that says something like "if data_bus = 0 then...".
> I can usually avoid this with clock enables, but sometimes it isn't
> convenient to have a clock enable signal with the data.

So you are replacing the free initialization of the registers by extra
clock enable hardware for what reason exactly?

Kolja Sulimma

"Brian Drummond" <brian_drummond@btconnect.com> wrote in message 
news:bt4i541q56gf2ukbbgbtvahq6nrlt0jo31@4ax.com...
> On Wed, 18 Jun 2008 04:57:04 -0700 (PDT), Kolja Sulimma
..
> There are options in some libraries (numeric_std for one) in Modelsim to
> suppress these warnings; but this carries the risk of suppressing real
> information. So I don't think that's a good idea either.
>
> I just ignore them... (actually I pay a LITTLE attention to reducing
> their number, but it's not important) ... but wouldn't it be nice to
> tell the simulator to suppress these errors for the first XXX ns, then
> report them.
>
> I expect a simple TCL script would do it...
>
> suppress Numeric_Std invalid value warnings;
> run 250 ns;
> enable Numeric_Std invalid value warnings;
> run;

Close,

set StdArithNoWarnings 1
set NumericStdNoWarnings 0
run 0 ns;
set StdArithNoWarnings 0
set NumericStdNoWarnings 0
run ....

or if you want to suppress the warnings until reset is negated you can use 
something like this:

when -label enable_StdWarn {reset_s == '1'} {echo "Enable StdArithWarnings" 
; set StdArithNoWarnings 0 ;}

Hans
www.ht-lab.com


>
> but haven't taken the time to learn enough TCL to try
> (my testbenches are entirely VHDL and that keeps me busy enough!).
>
> - Brian
> 

On Jun 18, 8:48=A0am, Rob <BertyBoos...@googlemail.com> wrote:
> On Jun 18, 1:38 pm, rickman <gnu...@gmail.com> wrote:
>
>
>
>
>
> > On Jun 18, 7:57 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:
>
> > > You simulation model should match the behaviour of your hardware,
> > > otherwise it is useless.
> > > Modern FPGAs initialize all registers upon poweron. You models should
> > > reflect that.
> > > Just initialize the signales at declaration and you are done.
>
> > > In many ASIC libraries and some older FPGAs the initial values of
> > > registers are random. 'X' is the
> > > perfect representation for that. You definitely want the 'X's in your
> > > simulation in that case because
> > > it is the only way to make sure that your circuit works correctly eve=
n
> > > with random start values.
> > > Your circuitry must be design so that all flip-flop eventually obtain
> > > defined states.
>
> > > Kolja Sulimma
>
> > You have just argued against yourself. =A0You have told him to
> > initialize registers in the declaration, then you say you want Xs to
> > represent arbitrary initialization. =A0This arbitrary initialization is
> > what the X is intended to represent, an unknown state. =A0If you really
> > want to model the hardware, you need to *never* initialize registers
> > in the declaration, but rather initialize them in an async reset
> > portion of the process. =A0Then any that you miss show up as Xs and any
> > that you properly initialize should be synthesized that way.
>
> > Rick
>
> This is exactly the problem, i'd rather not give certain registers
> init values, especially in the data path, as firstly it is unnecessary
> for the actual hardware implementation and secondly because in
> simulation seeing a vector of 'X's indicates that this bus hasn't yet
> been assigned a proper value. The problem comes when that data bus is
> driving a process that says something like "if data_bus =3D 0 then...".
> I can usually avoid this with clock enables, but sometimes it isn't
> convenient to have a clock enable signal with the data.- Hide quoted text=
 -
>
> - Show quoted text -

First off, these are only simulation warnings, not errors.  Not that
warnings should be simply ignored, but just keep that in mind.

Second, the warnings presumably go away rather quickly after running
the simulation as things all get properly initialized so it shouldn't
be a big problem.  Your functional sim and testbench should be
checking for proper functional behaviour hitting asserts whenver
something isn't as expected.  If your testbenching skills are not
quite at that level, then you may need to peruse the warnings a bit
closer at least once...and then work on learning the incredible power
of assertions to create self checking test benches.

Finally, if none of the above seems satisfactory, then realize that
there are other data types besides std_logic/std_logic_vector, namely
bit/bit_vector that can be used which have absolutely no knowledge of
unknowns.  Your 'clean' function then can simply be viewed as a
conversion function that converts std_logic/std_logic_vector into bit/
bit_vectors.

=46rom a synthesis perspective, the construct "if sig =3D 'U' then ..."
will be ignored...but will also (usually) generate a warning that you
can't compare things to metalogic values.  So now you've traded a
simulation warning for a synthesis warning so there is really no net
value being added by this new function you've created.  What's worse
is that now you should peruse the synthesis warning very closely to
see what is it actually doing when it hits the statement that compares
the signal to 'U'.  Some plausible examples might be:
1. Does it assume that 'U' is '0'?  (In general, this would be bad, in
a specific instance it might be OK)
2. Does it assume that the whole if statement is false (This would
probably be good).
3. Does this behaviour remain the same over different tools and
different versions of tools?  (This would be bad as well...but, if the
particular tool you use currently does #2, then you could get the
false hope that this cleaning works causing you later on to miss the
synthesis warning that reflects #1 down the road at some time and
that's when you'll get bitten by the cleaner).

You can work around all of this by then band-aiding some more by
making the cleaning only occur during simulation but that is just
making your synthesized code diverge from your functional simulation
model...which in my book is the worst of all worlds.

Bottom line is I'd recommend against 'clean'.

Kevin Jennings

"HT-Lab" <hans64@ht-lab.com> wrote in message 
news:5P86k.6335$aE7.5929@newsfe16.ams2...
>
> "Brian Drummond" <brian_drummond@btconnect.com> wrote in message 
> news:bt4i541q56gf2ukbbgbtvahq6nrlt0jo31@4ax.com...
>> On Wed, 18 Jun 2008 04:57:04 -0700 (PDT), Kolja Sulimma
> ..
>> There are options in some libraries (numeric_std for one) in Modelsim to
>> suppress these warnings; but this carries the risk of suppressing real
>> information. So I don't think that's a good idea either.
>>
>> I just ignore them... (actually I pay a LITTLE attention to reducing
>> their number, but it's not important) ... but wouldn't it be nice to
>> tell the simulator to suppress these errors for the first XXX ns, then
>> report them.
>>
>> I expect a simple TCL script would do it...
>>
>> suppress Numeric_Std invalid value warnings;
>> run 250 ns;
>> enable Numeric_Std invalid value warnings;
>> run;
>
> Close,
>
> set StdArithNoWarnings 1
> set NumericStdNoWarnings 0
> run 0 ns;
> set StdArithNoWarnings 0
> set NumericStdNoWarnings 0
> run ....

Doh!

set StdArithNoWarnings 1
set NumericStdNoWarnings 1
run 0 ns;
set StdArithNoWarnings 0
set NumericStdNoWarnings 0
run ....

Hans
www.ht-lab.com