Tracing UNKNOWN drivers

Y

Yaseen Zaidi

Guest
On Post Map and Post Route model simulations intermittently I get few X
bytes. I set up a trace check for source in ModelSim and found out that
it leads to X_BUF with 658 ps pathpulse which connects to vitalbehavior
(gsr, prld, dly of clk, set, rst etc). It's only bit 0 of the bus
that goes to X at times.

What do I do to get consistent timing?

Best wishes.
 
Yaseen Zaidi wrote:
On Post Map and Post Route model simulations intermittently I get few X
bytes. I set up a trace check for source in ModelSim and found out that
it leads to X_BUF with 658 ps pathpulse which connects to vitalbehavior
(gsr, prld, dly of clk, set, rst etc). It's only bit 0 of the bus
that goes to X at times.

What do I do to get consistent timing?
1. Perform static timing analysis. The output of this will be the
following bits of information:
- Maximum clock frequency for each clock in the design.
- Setup time of input pins relative to whatever clocks sample those
input pins.
- Clock to output time of all synchronous output pins.
- Propogation delays to all output pins that are combinatorial
functions of input pins.

2. Make sure your testbench does not violate any of the above timing.

3. If output signals are blipping to 'X' for a little bit then those
signals are outputs of combinatorial logic and not directly out of a
flip flop. If this momentary blip is an issue for whatever reason then
you need to get rid of it. To get rid of the blip, change the output
to be a clocked output. Obviously this changes the function somewhat,
delaying the output to occur some Tco after the clock edge but if the
signal is not allowed to blip even momentarily then a flip flop is the
only output type that help you meet that goal.

KJ
 

Welcome to EDABoard.com

Sponsor

Back
Top