| Copyright © 2005 ARM Limited. All rights reserved. | ARM DUI 0302A |
| Non-Confidential | |
 PDF version | |
| Home > Timing > About the timing shell > The pin-to-pin timing model |
| |||
| Home > Timing > About the timing shell > The pin-to-pin timing model |
The following scenarios illustrate the behavior of a timing shell:
Initially, the behavior of a simple synchronous block with no timing functionality is described.
The model has an external pin-to-pin timing shell added around it, implementing setup and hold checks, in addition to a delay on the output. It demonstrates that the addition of the timing shell does not affect the functionality of the model.
The implications of negative timing constraints, for example, negative setup and hold times are examined. It shows you that a simple pin-to-pin timing shell, used in conjunction with a zero-delay core, cannot be used to model negative timing constraints. To support negative timing constraints, a modification to the basic implementation is described in Use of negative timing checks.
The first example is a simple synchronous block with:
a clock, CLK
an input signal IN, that is sampled on the rising edge of the clock
an output OUT, that is driven on the falling edge of the clock.
Figure 5.2 shows a simple synchronous block with clock.
The sequence of events from the point of view of the model, without a timing shell is:
All signals are set to zero.
At 10ps, the IN input rises to 1. Because the block is sensitive to changes on IN, it is evaluated but the behavior of the block is so that no action is taken.
At 20ps, CLK, rises to 1. The model is evaluated and latches the value of IN internally.
At 25ps, IN falls to 0. The model is evaluated, but takes no action.
At 30ps, CLK falls to 0. The model is evaluated and determines that a drive to OUT is required.
Still at 30ps, but in a subsequent simulation evaluation, the OUT output, rises to 1 because of the drive from the block model.
This sequence of events is for a zero-delay, behavioral model, a DSM, with no timing shell. The model is sensitive to all of its inputs and drives its outputs immediately. Because of the simulation semantics of a DSM, no other part of the simulation is evaluated in parallel with the DSM evaluation. Consequently other functional blocks in a simulation cannot insert values between individual DSM evaluation steps even if they are set to drive its inputs at the same simulation time.
In this case a pin-to-pin timing shell is placed around the periphery of the model. The timing shell, like the model is also behavioral code. It monitors input events without affecting their passage, this is only true in the simple case, see Use of negative timing checks and Interconnect delays for more information, and inserts a delay-buffer through which output events propagate. Assume that the timing shell is annotated from the following SDF fragment:
(SETUP (POSEDGE CLK) IN (5))
(HOLD (POSEDGE CLK) IN (6))
(IOPATH (NEGEDGE CLK) OUT (3))
The timing shell has no special information about the behavior of the device that it is wrapped around. It also does not have any special knowledge of what the signals are used for. For example, clocks versus synchronously sampled inputs.
The sequence of events and their consequences is modified as follows:
Initially all signals are set to zero.
At 10ps, IN rises to 1. The timing shell notes the current simulation time 10ps as the time when IN changes and passes the change through to the underlying model. This behaves as described in Zero delay model core and no action is taken.
At 20ps the clock, CLK, rises to 1. The timing shell notes the current simulation time 20ps as the time when the clock rose. A setup check is now performed of IN against the positive edge of the clock by subtracting the stored time when IN changed 10ps from the current simulation time, 20ps. This value 10ps is greater than the setup time of 5ps so no warning is emitted. The timing shell passes the clock change event through to the underlying model which latches the value of IN as before.
At 25ps, IN falls to 0. The timing shell notes the current simulation time when IN changed and replaces its previous value, 10ps. It then performs a hold check by subtracting the stored time when the clock rose 20ps from the current simulation time 25ps, and notes that the actual hold time of IN against the positive edge of the clock was 5ps. This is less than the 6ps indicated in the SDF file, and so a hold violation message is printed in the simulation log. The event on IN is passed through to the model as before and the hold violation has no effect on the underlying model behavior. The output is not forced to X because of the timing violation.
At 30ps, CLK falls to 0. The timing shell notes this time as the time when the clock fell. No more action is necessary. The model is evaluated and determines that a drive to OUT is required.
Still at 30ps, but in a subsequent simulation evaluation, the output OUT, rises to 1 because of the drive from the block model. The timing shell intercepts this drive from the model and notes that the negative edge of the clock happened at the current simulation time, even though this occurred from a previous simulation evaluation. It therefore inserts a delay on the propagation of OUT to the outer edge of the timing shell of 3ps.
At 33ps, the delayed version of OUT propagates from the outer edge of the timing shell, and into the wider simulation, see Figure 5.3.
The model core drives this output at 30ps simulation time, the subsequent delay is implemented entirely by the timing shell.
As an event simulation, the behavior differs from physical hardware in a number of ways. Firstly, if we examine the point where the hold-window for the sampling of IN by the device was violated:
In physical hardware, this renders the subsequent behavior of the device unpredictable because it cannot be guaranteed that the correct value of IN was actually sampled and used in the evaluation of the output.
In the event simulation, the sampling of synchronous inputs occurs as a discrete event at the clock edge. The resultant hold violation is a cosmetic warning that does not affect the subsequent behavior of the simulation, and must be taken to indicate that the simulation can no longer be assumed to match reality after this point.
ARM DSMs do not drive outputs to X in response to a timing violation.
Secondly, in this example, the model evaluates its outputs when it has all pertinent information. This is when it receives the negative-edge event on the clock.
In physical hardware, the delay of 3ps on the output OUT, is partly because of internal path delays in the device and partly because of the load to be driven by the output.
In this event simulation, the new value is calculated immediately and the timing shell simulates the cumulative delays after the fact. This works for the purposes of simulation provided that the output value can really be calculated at the point when the clock edge that drives them occurs. This might not always be the case, an explanation is provided in the next section.
In this example there is a high performance device where a sampled input has a negative-setup time, and the output it affects is driven by the same clock edge as when the input is sampled. Figure 5.4 shows this situation.
In this situation, the value of IN can change for a certain time after the clock edge, and still affect the value of the derived output. For example, this can be because of a delay in propagating the clock around the inside of a large device. In reality the output OUT is driven at a point some time after the input clock edge is nominally said to have occurred because of propagation delays inside the device. A DSM-style model does not model these delays. The output is driven immediately and delayed by the timing shell. A subsequent change on IN, even if it occurs before the final drive of OUT by the timing shell, cannot affect the simulation because the model has already driven the result and cannot revoke it.
Simulating this type of behavior in a pin-to-pin timing shell is therefore quite complicated, and if applied to the scenario outlined does not work. See Use of negative timing checks for information on how the timing shell behavior is modified by the simulator to handle these situations.
| Copyright © 2005 ARM Limited. All rights reserved. | ARM DUI 0302A |
| Non-Confidential | |
| PDF version | |
| Home > Timing > About the timing shell > The pin-to-pin timing model |