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

Reply to
Rob
Loading thread data ...

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

Reply to
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

Reply to
rickman

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.

Reply to
Rob

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.

ze registers

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.

formatting link
Page 3: "Avoid asynchronous reset because it prevents packing of registers into dedicated resources and affects performance, utilization, and tool optimizations."

formatting link
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

Reply to
Kolja Sulimma

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

Reply to
Brian Drummond

..

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

formatting link

Reply to
HT-Lab

n
-

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

Reply to
KJ

Doh!

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

Hans

formatting link

Reply to
HT-Lab

LOL. How about: set NumericStdNoWarning 'X'

Kolja

Reply to
Kolja Sulimma

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

formatting link

Reply to
HT-Lab

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

Reply to
Rob

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

Reply to
Rob

n

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.

ze registers

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.

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

Reply to
rickman

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.

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

Reply to
rickman

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

Reply to
Mike Treseler

Metastability.

--
These are my opinions, not necessarily my employer's.  I hate spam.
Reply to
Hal Murray

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

Reply to
Brian Drummond

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

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

Reply to
Brian Drummond

I am asking if there is a reason to *not* use the GSR to control the initial state of the FFs. I am not sure I understand about the SRLs. They are implemented using the configuration memory in the LUT. That is definitely loaded on power up. I guess it is not set by the GSR, but it is well defined even if not controllable from your code. Do you need a way to control the values of SRL elements other than on configuration?

If the SRL is in a determined state on configuration, but this state can not be restored by user reset of any sort, how does Xilinx recommend that you model this?

I assume there is some logic in front of the SRL, but that is not certain I expect. Either way, each SRL only has a single input and you can use another LUT to provide a "clamp" to the input or output to prevent the spread of the 'X' state. I know you don't want to use extra resources, but personally, I find that preferable to fighting the tools (like I am doing now).

Rick

Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.