( ESNUG 249 Item 2 ) -------------------------------------------- [8/30/96]
Subject: ( ESNUG 248 #8 ) Handling Timing Paths Through A Bi-Directional Bus
> I have registers with paths through logic, then through a tri-state driver,
> and then out to a bidirectional bus. Data can also be brought in from the
> bus to the same registers but not on the same bus cyle. I need to disable
> the timing path which loops from the flip-flop Q out through the bus
> interface and back to the flip-flop D input without disabling other paths
> with the same end-points. I still need the timing to be checked between
> the data bus and the flip-flop.
> Bidirectional Data Bus
> ______________________ ======================
> | ___ ^ Enable ___ ^
> V______| | ____ | __ | | __
> ______|MUX|__| | | ,-~ \__ |\| | |\ ,-~ \__
> ^ |___| | |___|__( Logic }____| \___V___| \___( Logic }__
> | | | FF | | \ _/ | / | / \ _/ |
> | Select_| ck-|> | | ~---' |/ |/ /~---' |
> | |____| V__________________________________/ |
> |___________________________________________________________________V
>
> Has anyone come up with a good solution to this type of timing problem?
From: Ajay Nath <nath@ecpi.com>
John, I figured it was time I gave back to ESNUG.
This is a classic case of using path segmentation. Path segmentation has
uses when there are multiple paths between two points, and they are
multicycle. It is preferable over path disabling, because you still
specify timing requirements. If set_multicycle_path or set_false_path had
a '-through' option, it would solve a lot of problems like these.
To perform path segmentation you must break the combinational path (at
the bidirectional data bus, in this case). When this is done, the break
in the path creates a new end point, and a new starting point. Timing to
(from) this end (starting) point must be specfied in order to meet path
timing requirements. But there is no through path anymore.
So, if I have interpreted Greg's problem correctly, we would end up with:
Bidirectional Data Bus
_____________________ ======================
| ___ ^ Enable ___ ^
V______| | ____ | __ | | __
______|MUX|__| | | ,-~ \__ |\| | |\ ,-~ \__
^ |___| | |__|__( Logic }____| \__A B_V___| \___( Logic }_
| | | FF | | \ _/ | / | / \ _/ |
| Select_| ck-|> | | ~---' |/ |/ /~---' |
| |____| V_____________________________________/ |
|_____________________________________________________________________V
Where A, and B are the new end and starting points. You would then
specify the required setup/hold output requirements at A, and the input
delays at B to complete the path timing picture. What this process has
done, is that it has broken the path through the data bus. Now you have
the true paths [FF to FF through logic, FF to databus, and databus to FF]
separated, and can optimize accordingly.
For a 32 bit data bus, assuming no other driver on the bidirectional data
bus in this module, and the variable 'databus' is a list of all data bits:
foreach (databusnet, databus) {
remove_variable driver_pin
driver_pin = filter (all_connected(databusnet), "@pin_direction==out")
set_input_delay ... [to driver_pin]
set_output_delay ... [from driver_pin]
:
set_false_path .. [if needed]
}
NOTE: The above methodology is to be applied when the design has been
mapped. This cannot be applied on an unmapped design, since this
requires that the driver pin be a valid mapped cell pin.
You have to specify timings to A and from B, and should be able to get
these from the mapped design, if the databus is not a constrained I/O
(internal signal). An implicit dont_touch attribute is placed on the
leaf cells associated with the start or endpoint of a (segmented) path.
[set_input_delay / set_output_delay]. This will cause a dont_touch to
be placed on the bus driver in the above example.
- Ajay Nath
Motorola
---- ---- ---- ---- ---- ---- ---- ----
From: Oren Rubinstein <oren@waterloo.hp.com>
Hello John.
The solution is called "path segmentation". You apply a pair of
set_input_delay and set_output_delay on the same point, which creates a
new startpoint and endpoint in the middle of the path. In this case, the
correct point to apply the commands to, is the output of the tristate driver.
Unfortunately, applying the constraints also applies an implicit
dont_touch on the tristate driver, and that prevents DC from mapping it.
Which means you have to compile twice: the first time to map it,
then you do the segmentation, then an incremental compile.
- Oren Rubinstein
Hewlett-Packard (Canada) Ltd.
---- ---- ---- ---- ---- ---- ---- ----
From: ryan@fsd.com (Ken Ryan)
John,
We had nearly the same situation as Greg. What you need is "set_false_path
-through", which of course doesn't exist. We spent considerable time
looking for a way to get the same effect, without finding one.
Here are two things we did to take care of it:
1) Path segmentation. There's a methodology note on it in the online docs,
which is pretty good. The node where the bidi bus connects to the block
can be disabled with set_input_delay and set_output_delay. The downside
is having to maintain consistent timing budgets, and adjust them as
optimization warrants. If you have a *lot* of paths like this, it can
get out of hand quickly.
2) Nuke the bidi buses. That's what we eventually did. We were able to
make a floorplan that had contained the bidi busses in a relatively
small area, so we restructured it to use muxes instead of tristate
busses. It ended up much cleaner, and as a bonus the time to do
update_timing went down by a factor of about 8.
- Ken Ryan - Glenn Griffin
Orbital Sciences Corp. Intrinsix Corp.
|
|
