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

On 18 Jun., 16:29, "HT-Lab" <han...@ht-lab.com> wrote:

> Doh!
>
> set StdArithNoWarnings 1
> set NumericStdNoWarnings 1

LOL.
How about:
set NumericStdNoWarning 'X'

Kolja

"Kolja Sulimma" <ksulimma@googlemail.com> wrote in message 
news:8e8331f2-d305-40db-8b97-fd0c2c8ba02d@x35g2000hsb.googlegroups.com...
> On 18 Jun., 16:29, "HT-Lab" <han...@ht-lab.com> wrote:
>
>> Doh!
>>
>> set StdArithNoWarnings 1
>> set NumericStdNoWarnings 1
>
> LOL.
> How about:
> set NumericStdNoWarning 'X'

If you give that command than Modelsim will automatically un-install, delete 
your license file and block any emails to support@..... Of course this only 
works in version 6.3, 4.7 to 6.2 simply deletes your partition table. 
Version 6.4 (expected soon) will also send an email to your boss to get you 
fired,

Hans
www.ht-lab.com

>
> Kolja 

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

You misunderstand. I'm not adding clock enables to bodge around this
problem, the data is ordinarily accompanied by a clock enable signal
by design. It's where it isn't that I get problems.

Well, I'm pretty convinced that a clean function is a horrible hack
never to be spoken of again. Thanks for your helpful comments.

One issue not covered is where a part of the design doesn't receive
data until a way into simulation and therefore turning off warnings
for the first few hundred ns doesn't fix things. I suppose that
sometimes you just can't avoid plugging a 'x' vector into some
arithmetic function, and there doesn't seem to be a magical fix for
all scenarios.
maybe if you could attach an attribute to an offending signal(s) if
you've had a good look and decided you don't care about warnings on
this part of the design....

By the way, it's a Xilinx FPGA design using XST and Modelsim.

On Jun 18, 10:01 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:
> 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 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.  You have told him to
> > initialize registers in the declaration, then you say you want Xs to
> > represent arbitrary initialization.
>
> 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.

Yes, I did read your post.  It discusses two separate cases and does
not show that you fully understand what is going on in the part vs.
the simulation.  If you don't want to discuss it, please read no
more.   But if you are interested in what I have to say read further.


> >  If 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.  Then 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/doc=
umentation/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."

Xilinx may tell you not to use async resets, but the GSR, which is the
signal that you are referring to when you wrote, "Modern FPGAs
initialize all registers upon poweron", is an ***asynchronous*** reset/
set.  So in FPGAs you can't avoid using it, unless there is a trick to
totally disable it that I have not heard of.

My point was that you described two separate cases as if either one is
valid.  But that is not correct.  The only valid case is one that
matches your hardware.  ASICs may not need the async reset for some
self synchronizing circuits or for data path.  Data path will
typically sort itself out once valid data enters.  But a self
synchronizing circuit will never sort itself out in simulation even if
it does in the real chip.  So it is better to initialize those
circuits as well so that the simulation will match the hardware.


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

Specifying an initial condition in the declaration is not a match to
the hardware.  The GSR signal is released asynchronously and should
not be used to provide an initial condition for logic that can be
disrupted by different FFs being released on different clock cycles.
I always generate a reset from an arbitrary signal, preferably an
external reset.  The software will assign this net to the user input
to the GSR function and as long as the prop delay is not slower than
your clock, it will function correctly.

The above note from Xilinx is not referring to the use of the GSR
function, it is referring to arbitrary signals being used as async
sets and resets.

Rick

On Jun 18, 10:04 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Wed, 18 Jun 2008 04:57:04 -0700 (PDT), Kolja Sulimma
>
> <ksuli...@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.

There are applications that will work correctly in hardware without an
initial condition, but never reach a valid state in simulation without
it.  In those cases I find it easier to add an initialization to the
hardware to make the simulation match the hardware.

An xxample is a free running divide by 2 clock generator.  It will
start up in a 1 or a 0 state.  It does not matter.  But the simualtor
will never resolve the 'X' starting state.  Some state machines can
start in any state and find their way to a valid state, by design.
This is hard to verify in simulation.  It typically requires starting
the FSM in every possible state.  But letting it start in an all 'X'
state will typically leave it in an all 'X' state forever.


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

Is it important to not use an initial condition controlled by a global
reset?  In FPGAs this is typically free, or almost free to use it
properly.  In ASICs I guess it is a different matter.

Rick

Rob wrote:

> Is a better solution to meticulously make sure all registers are
> initialised when they are declared?

Not for the synth code.
Most of my unintended metalogic sim values
stem from improper testbench stim, not from the synthesis code.
I like hold init values on the stim signals until
the reset process is complete. Something like:

   begin  -- process tbmain
      wen_s   <= '0';
      ren_s   <= '0';
      burst_s <= '0';
      wait until rst_s = '0';
      wait until rising_edge(clk_s);
      ...
> or is it perfectly safe not
> necessarily poor coding practise?

More a question of useful than safe.
In a blockram cache, I'd *prefer* to
to see my data filling up a block
of 'X' bits rather than '0' bits.


           -- Mike Treseler

>Is it important to not use an initial condition controlled by a global
>reset?  In FPGAs this is typically free, or almost free to use it
>properly.  In ASICs I guess it is a different matter.

Metastability.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

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

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

Explicit return to an initial state without the penalty of
reconfiguration. Hopefully the same initial state: always using reset
will ensure that; otherwise the post-config (signal initialization) and
post-reset states could be different...

(There may be cases where initialization alone is good enough)

- Brian

On Wed, 18 Jun 2008 10:10:24 -0700 (PDT), rickman <gnuarm@gmail.com>
wrote:

>On Jun 18, 10:04 am, Brian Drummond <brian_drumm...@btconnect.com>
>wrote:
>> On Wed, 18 Jun 2008 04:57:04 -0700 (PDT), Kolja Sulimma
>>
>> <ksuli...@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.

>> 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.
>
>There are applications that will work correctly in hardware without an
>initial condition, but never reach a valid state in simulation without
>it.  In those cases I find it easier to add an initialization to the
>hardware to make the simulation match the hardware.
>An xxample is a free running divide by 2 clock generator.  It will
>start up in a 1 or a 0 state.  It does not matter.

Good point. I would suggest these are the exception rather than the
rule, and need some special treatment by the designer. Initialization is
an unnecessary constraint on the hardware but IMO probably the best
compromise.

Another way is to use a "to_01" function on that specific signal to
arbitrarily resolve the unknown level if you don't want to initialize
(e.g. if you need a portable design, and not all tools/technologies
support the initialization).

>> ... 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!).
>
>Is it important to not use an initial condition controlled by a global
>reset?  In FPGAs this is typically free, or almost free to use it
>properly.  In ASICs I guess it is a different matter.

Not sure I understand the question. If you mean use the global reset
signal to suppress warnings; it won't solve the whole problem.

It'll suppress warnings while Reset is active, but I need to suppress
warnings for a couple of dozen cycles after Reset. Resetting pipeline
registers is unnecessary and inefficient (it prevents packing into
SRL16s for example) so "XXXX" is to be expected for a small but
deterministic time after reset while the pipelines flush.


- Brian