X propagation in Timing Simulation

Hi,

In a timing simulation, Setup / Hold violation of Flip-Flop will result in value of 'x' at the output. Is that Right?

If so, how double synchronisation circuits work in timing simulation ? Won't it propagate x. ?

Regards, Muthu S

Reply to
Muthu
Loading thread data ...

Usually so. It depends on how the model was written. Most FF models (in Verilog at least) put X on the output if there's a violation. This X will presumably be corrected on the next clock edge, unless there's another timing violation there.

Yes - at least for one clock cycle. Tedious stuff.

Most people fake their way around this by replacing the first FF model in the resynchroniser with a FF model that doesn't propagate X. In most cases there are very few FFs that need to be modified in this way, so it's not very hard to do. And we hope that you have analysed your resynchroniser very carefully, so you are happy to accept the poor modelling because you already know (from the analysis) exactly how the resynchroniser behaves in all cases.

It would be better if the FF model should do rather more accurate modelling of metastability: the output should go to X, then after some settling time it should go to a random choice of 0 or 1. Once you have decided to do this, it's easy to make the model even more accurate: use the precise time of the setup violation to determine how long the settling time should be, and to bias the random choice of 0/1. However, if you do this, the FF model will probably become very inefficient and slow to simulate; so, once again, you should apply this model only to the resynch FFs.

There's another possible approach, which I have not tried. You could write some Verilog in your test fixture to sense the FF model's internal notifier register, and take control of the FF's output whenever the notifier toggles, using "assign" or "force". In this way there would be no need to modify the simulation netlist, but you would need to know the exact structure of the models. And it assumes that the test fixture and the models are all written in Verilog - although that's probably a fairly safe guess, for timing simulation.

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
 Click to see the full signature
Reply to
Jonathan Bromley

I think the value of the more complex model is very limited and may even be counter productive. Accurate models are nice, but it would be very hard to do anything useful with modeling metastability rates since a failure of once a month is typically not good enough. Would anyone be willing to run a month long simulation? That would take, what, a couple of years?

It is likely better to pick a settling time and to model that. Or even better to analyze metastability in static timing analysis.

My suggestion is to go with the minimal model that ignores setup violations and not model metastability in simulation. Static timing analysis is the correct tool to analyze metastability.

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

I wholeheartedly agree that theoretical analysis is the right approach - especially for things like this where, as you correctly say, it is absurd to expect simulation to detect every possible failure. On the other hand, it's nice to know that you *can* realistically model metastability effects. If such modelling has any value, it is much the same kind of value as modelling a short nominal clock-to-output delay on flip-flops in RTL simulations - it makes real behaviour much easier to visualise. It also makes the simulation easier to believe, especially for project managers who are paranoid about metastability but don't understand it :-)

On balance, I think I probably agree.

Agreed, without reservation.

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
 Click to see the full signature
Reply to
Jonathan Bromley

This is the default behavior is most timing simulation models, including Xilinx's. There is a better way to get around this though. For Xilinx simulations, if you place the attribute ASYNC_REG=TRUE on the offending FF, it will disable the X-propagation for that particular FF in timing simulation. You will see see timing warnings generated as a timing violation is still occurring however the behavior of the FF during a timing violation is changed to that it keeps its previous value rather than going to X. Keep in mind that the FF may have gone metastable or resulted in a changed value so that must be weighed in for simulation but this will allow for a more usable behavior for simulation if this situation occurs.

If using Xilinx, rather than doing this, just put an ASYNC_REG=TRUE on the first synchronization FF. It is not necessary on the second as it will not see a timing violation as long as the route is not too long for it from the first. If it is, you would want to know about that and likely correct that so it generally is not a good idea to put it on the second synchronizing register. That attribute can be put on either an instantiated or inferred register and can be put either in the code itself (that is how I like to do it) or in the UCF file. See the Xilinx Synthesis and Verification Design Guide for more details on using this attribute if you are interested in learning more.

We have investigated this and while it is possible to use some statistical analysis (MTBF data) to attempt to predict the amount of settling time after a metastable event happens it will almost never be truly accurate (predicting this is still a bit more magic than science in my opinion) and the model will be far more complicated and slow. We would not be able to use standard timing checks built into the simulator but instead craft our own. These checks would need to not only look to see if a violation occurred but when it occurred in respect to the timing window and make predictions about how long the output should remain X and what the final value should settle to. This would have to be done for every register in the simulation and I suspect it would slow down simulation by quite a few orders of magnitude and still we could not be confident that the output would be true-to-life (either in the prediction of settling time or the prediction of the end value that it settles to). There are obvious liability issues to weigh in as well for that which is why we are taking the safe route and not planning to do this work any time soon. My hope is that the ASYNC_REG attribute will suffice most people's needs for this.

Again, I suggest to use the existing mechanisms in the simulation libraries and netlists. Once you start taking a path like this or replacing models, all bets are off whether the simulation is still acting like it should. But of course, to each their own and this is another tool in the tool box if you choose to use it but I would be very cautious if you do.

-- Brian

Reply to
Brian Philofsky

Usually.

See part 12.0 in this very good paper:

formatting link

Cheers, JonB

Reply to
Jon Beniston

Thank you all..

Regards, Muthu S

Reply to
Muthu

Another way is to have the testbench fake synchronized stimulus for the "unsynchronized" inputs.

This allows a functional test of the untainted synthesis code or netlist.

-- Mike Treseler

Reply to
Mike Treseler

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.