cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
ugface
Visitor
Visitor
519 Views
Registered: ‎04-18-2018

strange timing violation in microblaze during post-implementation timing simulation

During post-implementation timing simulation, there are lots of warnings of timing violation in "FDRE.v" caused by microblaze as shown in the attached screenshot. But the timing is met in implementation, and the CPU works well in hardware.

The number of these warnings is huge. It's really troublesome for finding other simulation messages, and maybe also slows down the simulation a lot.

From simulation waveform, we indeed find some glitches in the R pin of FDRE. But aren't the glitches benign?

microblaze.timing.violation.jpg
microblaze.glitch.jpg
0 Kudos
4 Replies
calibra
Scholar
Scholar
511 Views
Registered: ‎06-20-2012

Pin R  is a synchronous reset so you can safely ignore the warning.

The question is why is it modeled in the library?

== If this was helpful, please feel free to give Kudos, and close if it answers your question ==
0 Kudos
avrumw
Expert
Expert
404 Views
Registered: ‎01-23-2009

Pin R  is a synchronous reset so you can safely ignore the warning.

I am afraid I have to disagree.

A timing path that ends at the synchronous reset pin of a flip-flop is no different than a path that ends at the D input - both are required to meet timing for your system to operate properly. In fact, the tools can even use the R pin to implement "normal" functionality - if any RTL condition results in the flip-flop going to 0 (unconditionally), the synthesis tool can choose to implement this combinatorial condition going to an AND gate in front of the D input, or to the R input of the flip-flop. It is even free to change back and forth between these two implementations as the tools progress (for modifying control sets).

Given that we see "glitches" on this R pin, it is clear that it isn't just a global reset - it is clearly the result of some combinatorial logic.

So you can never ignore violations on an R pin.

Even if this were an asynchronous clear pin, it is only sometimes true that you can ignore it. If the violation is on the asserting edge of the clear, and the clear is guaranteed to last for more than one complete clock period, only then can you ignore it. You can never ignore a violation on a deasserting edge of an asynchronous clear.

So, you can't ignore this timing violation.

So, why are you seeing them. Before we go any further, I need to be sure that during synthesis and implementation:

  • you had complete and correct constraints applied to your design AND
  • your design met timing

If this is true, then the most likely reason for these violations is that there is some discrepancy between the constraints you used to implement the design (your XDC constraints) and the conditions you are using to run your simulation (your testbench stimulus). The most basic one of these is the clock; when you synthesized, you specified the clock rate with a "create_clock" command. Is your simulation using this exact same clock rate (or slower?). If your testbench clock is even a tiny bit faster then you can get violations. For example if you specified 3.3333ns for your clock period in your XDC, but (for whatever reason) your testbench is generating a clock with a 3.3ns clock (maybe your `timescale doesn't have enough precision), then you will be running your design 0.033ns faster than your constraints, which can cause violations.

The same is true of your inputs. In your constraints you specified when the inputs will change (with a set_input_delay command). Is your testbench respecting those constraints; only changing the inputs within the time between the -min and the -max of the set_input_delay? Again, if not, you are violating the conditions you told the tools they need to make the circuit run with, and you may get violations.

Avrun

0 Kudos
calibra
Scholar
Scholar
386 Views
Registered: ‎06-20-2012

Dear@avrumw 

I am afraid and  I have to disagree too.

You said , "So you can never ignore violations on an R pin."

"glitches" on synchronous inputs can be safety ignored. Only setup and hold constraints must be meet.

"Even if this were an asynchronous clear pin, it is only sometimes true that you can ignore it."

You  NEVER can ignore "glitches" on asynchronous pins.

I designed cell libraries for 5 years.

Regards,

== If this was helpful, please feel free to give Kudos, and close if it answers your question ==
avrumw
Expert
Expert
366 Views
Registered: ‎01-23-2009

@calibra,

I stand corrected. I hadn't noticed that these were $width check failures and not $setup (or $setuphold) check failures.

Everything I said above is correct with respect to a setup or hold check. And it is important to make this clear, since there is a common misconception that setup/hold failures to reset/set/preset/clear pins are not valid, which, as I describe above is not the case.

But this is a width check. To be honest, I have spent a few minutes looking a the FDRE model, and I do not understand what this check is supposed to do. It has been in the model for at least a year (I don't have any earlier versions of Vivado or ISE around to see how far back it goes). It is not always enabled due to the &&& init_enable, but I can't figure out what this is for (it has something to do with the current state of the FF not being the INIT value on the previous asserting edge of the R, which makes no sense...)

Anyway, @calibra is right - a width check shouldn't exist on the R pin - even with these condition. I have no idea what it is for, but I am worried about saying "just ignore it" - even if I can't understand it I have to assume it is there for some reason (Xilinx has been doing modelling of their cells for a long time)...

Avrum

0 Kudos