( ESNUG 217 Item 5 ) ---------------------------------------------- [5/3/95]
From: prz@hprnd.rose.hp.com (Paul Zimmer)
Subject: How To Handle Timing Through Bidirectional Ports?
John,
How do other people handle timing through bidirection I/O's -- especially
to/from an external RAM?
I'm doing a design that accesses an external RAM. In the vendor library I'm
using, bidi's are implemented by inst'ing an input pad and an output pad,
and hooking them together in the netlist.
This creates a whole load of bogus loop paths through the bidi's (I don't
generate write data and clock it back in!). disable_timing only works
to disable paths WITHIN a cell, not between cells. set_false_path only
works on path endpoints, so I can't just disable the piece of wire connecting
the input pad's input to the output pad's output.
A doc I retrieved from SolvIt recommended doing set_input_delay and
set_output_delay on the pins of the cells involved.
This works, but it has a nasty side effect. Apparently, this works by
creating a path endpoint on the pins, which breaks the loop. Unfortunately,
you have to do the set_.._delay relative to a clock, which now makes the
timing relative to an IDEAL clock.
Why is this a problem? Because I now cannot cleanly check the path:
clk_pin -> clk_network -> clk_pin of addr reg -> q of addr reg ->
ram_addr pin -> ram addr/data delay -> ram_data (bidi) pin ->
ram_data d input
I'm doing this by budgeting the clk->addr time, then using this budget
plus the RAM access time as the input_delay of the data.
The problem is that clk_network piece. Since it is approx'ly the same
for the addr_reg clock pin and the data_reg clock pin, it really
doesn't add anything to the path (it just shifts the clock cycle over,
but doesn't squeeze it). But, since the output is checked relative
to the propagated clock (other timing checks require propagated clocks),
and the input is (due to the bidi problem) now checked relative
to an ideal clock, the clk_network delay now squeezes the clock cycle.
Dang!
One possibility is to throw the clk_network delay into the budget, but this
will require hand checking of the clock timing when we get back-anno info
(since the budget has to take into account any difference between the two
clock paths).
Another possibility is to create my own synopsys library component for
the RAM, and do timing checks from the chip + RAM level. This would
also solve the WE checking problem (which I'll send as a separate post,
since John likes to restict the postings to a single topic). Will
I need a library compiler license to do this (OOOOOUCH!)?
The whole goal of this would be to turn the path into a clk-clk path. Would
the set..delay stuff to handle the bidi's make this not work anyway?
How do other people handle external RAM timing????
- Paul Zimmer
Hewlett Packard, Roseville
|
|
