Looking through your timing report, there is nothing that indicates a potential issue. Since you have a problem, this means that the scenarios that static timing analysis (STA) is checking are not covering the actual usage of your circuit.
Without any serious setup of STA, some common assumptions are that all inputs are valid by the time the clock rises, and that all states are known (meaning a logic 1
or 0
). Immediately, the UUUUUUUU
on bus3
looks very suspicious, and is a possible issue with initialization. In logic simulations, U
implies that the line is either a 1
or 0
, but a register driving it was not initialized properly. This could cause the simulator to give weird answers until all registers are loaded or reset. However, this problem manifests itself in later cycles after all registers have been initialized.
The other potential issue is bus1
starts in a high impedance state (ZZZZZZZZ
). Considering that tri-state is not usually assumed in timing analysis, this is the most likely source of the timing discrepancy. Tri-state conditions must be carefully coded into your STA tool in order for them to be considered. This can be a very difficult task, and is prone to error (incorrect programming, missed cases, etc.). I believe that programming in tri-state delays would most likely give you an accurate STA result that should match your simulation.
However, tri-state is usually a bad choice for on-chip communication for both ASICs and FPGAs. This ambiguity of STA reliability, potential for bus contention, and the uncertainty of drive strength requirements make tri-state more likely to cause problems than fix them. The safer method is to use a multiplexor to select which source "talks" to the bus, or partition the design differently. I would only use tri-state when I know it will solve more issues than it can cause.
I imported the netlist into LTSpice and it worked ok (I only had to rename V(CL) to V(4) in the .PROBE directive, since LTSpice didn't recognize that syntax to specify the voltage across the cap):
The results of the simulation are shown below:
Therefore there is nothing inherently wrong with your netlist. Probably the simulation engine of PSPICE didn't succeed to find a solution for the equations. Try to fiddle with the simulation accuracy parameters (I don't use PSPICE, so I cannot help with that).
Best Answer
I don't know which version of PSpice are you using. But after adding TR and TF a small value, it works. Usually a 1 picosecond rise/fall time is extremely small with regard to the simulation time, so it closely approximates the ideal step function. Set them to 0 may cause convergence problems in some transient analysis simulations.