Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
asic:timing:graph [2024/03/21 14:22] rajit [Control logic and tick placement] |
asic:timing:graph [2024/03/29 06:19] (current) rajit [How does one tick edges?] |
||
|---|---|---|---|
| Line 11: | Line 11: | ||
| {{ : | {{ : | ||
| - | What happens if we make one of the ring oscillators slower? The C-element will wait for the //slower// of the two oscillators before changing its output. Hence, the cycle period of this particular circuit will be determined by the slowest cycle of gates in the circuit. This simple example and intuition can be translated into a [[https:// | + | What happens if we make one of the ring oscillators slower? The C-element will wait for the //slower// of the two oscillators before changing its output. Hence, the cycle period of this particular circuit will be determined by the slowest cycle of gates in the circuit. This simple example and intuition can be translated into a [[https:// |
| ===== From gates to events ===== | ===== From gates to events ===== | ||
| Line 38: | Line 38: | ||
| {{ : | {{ : | ||
| - | This is sometimes called a // | + | This is sometimes called a // |
| ===== Delays ===== | ===== Delays ===== | ||
| Line 46: | Line 46: | ||
| To determine delays, we need to know the slew rate (equivalently, | To determine delays, we need to know the slew rate (equivalently, | ||
| - | ===== The cycle period and delay reporting ===== | + | ====== The cycle period and delay reporting |
| A particular cycle of transitions in the timing graph imposes a constraint on the cycle period: namely, the cycle period must be at least the sum of the delays around the specific cycle divided by the number of ticked edges on the cycle. In our simple examples above, all simple cycles had only one ticked edge; in general, this need not be the case. The overall cycle period of the entire circuit is the maximum value of the cycle period constraints for every simple cycle in the graph. The cycle in the timing graph corresponding to the cycle period of the overall system is called the critical cycle. | A particular cycle of transitions in the timing graph imposes a constraint on the cycle period: namely, the cycle period must be at least the sum of the delays around the specific cycle divided by the number of ticked edges on the cycle. In our simple examples above, all simple cycles had only one ticked edge; in general, this need not be the case. The overall cycle period of the entire circuit is the maximum value of the cycle period constraints for every simple cycle in the graph. The cycle in the timing graph corresponding to the cycle period of the overall system is called the critical cycle. | ||
| Line 55: | Line 55: | ||
| The Cyclone static timing analysis engine reports the delay //offset// relative to '' | The Cyclone static timing analysis engine reports the delay //offset// relative to '' | ||
| - | ===== How does one tick edges? ===== | + | ====== How does one tick edges? |
| In the examples above, it was clear where the ticks in the timing graph should be placed. However, in a general asynchronous circuit, determining the placement of ticks after-the-fact is a non-trivial problem. | In the examples above, it was clear where the ticks in the timing graph should be placed. However, in a general asynchronous circuit, determining the placement of ticks after-the-fact is a non-trivial problem. | ||
| - | In fact, techniques for doing this that are known (e.g. described in the Cyclone paper) | + | In fact, techniques for doing this that are known (e.g. described in the Cyclone paper) |
| Placing ticks in the right location is probably the most confusing aspect of building a correct timing graph for asynchronous circuits. What follows are some rules of thumb that should help you with this process. Note that if you are using our logic synthesis tools, they automatically tick the appropriate edges in the timing graph, so this section need not concern you. However, if you are generating your own asynchronous design via some alternate approach, then you will need to develop a strategy for ticking the appropriate edges in the timing graph. | Placing ticks in the right location is probably the most confusing aspect of building a correct timing graph for asynchronous circuits. What follows are some rules of thumb that should help you with this process. Note that if you are using our logic synthesis tools, they automatically tick the appropriate edges in the timing graph, so this section need not concern you. However, if you are generating your own asynchronous design via some alternate approach, then you will need to develop a strategy for ticking the appropriate edges in the timing graph. | ||
| - | ==== Control logic and tick placement ==== | + | ===== Control logic and tick placement |
| Let's consider a simple example of a handshake protocol between two processes shown below. | Let's consider a simple example of a handshake protocol between two processes shown below. | ||
| Line 87: | Line 87: | ||
| Ticks are fungible; if all the inbound edges to a vertex in the timing graph are ticked, that is equivalent (from a timing analysis perspective) to adding a tick to all the outbound edges from the vertex (and eliminating the inbound ticks). While in general an edge could have multiple ticks, Cyclone restricts its attention to timing graphs where each edge has at most one tick. (This can be worked around easily if needed.) | Ticks are fungible; if all the inbound edges to a vertex in the timing graph are ticked, that is equivalent (from a timing analysis perspective) to adding a tick to all the outbound edges from the vertex (and eliminating the inbound ticks). While in general an edge could have multiple ticks, Cyclone restricts its attention to timing graphs where each edge has at most one tick. (This can be worked around easily if needed.) | ||
| - | ==== Datapath logic ==== | + | ===== Datapath logic ===== |
| - | ==== Some unintuitive examples ==== | + | In the simple linear pipeline example above, none of the datapath logic would have ticked edges since the '' |
| + | However, if instead we have a token ring, that token ring would have some datapath element (and the control handshake) that initializes with a token on its output and valid data in the datapath. For that particular datapath storage element, we would tick the data input to the storage element. | ||
| + | ===== Why tick edges at all? ===== | ||
| - | + | If a timing graph has a cycle of arcs with no ticks, this corresponds to an asynchronous circuit that is deadlocked--i.e. that does not oscillate. If this is detected, Cyclone will report an unticked cycle and display the cyclic path in the timing that is problematic and then stop. | |
| - | + | ===== When all else fails... | |
| - | ==== When all else fails... ==== | + | |
| We also provide a " | We also provide a " | ||