( ESNUG 304 Item 11 ) -------------------------------------------- [11/12/98]
From: "Paul.Zimmer" <paul.zimmer@cerent.com>
Subject: My Fast-And-Slow-Clocks-Mixed-With-Logic DC Constraining Nightmare
John,
The reason why I asked for "ied" on Suns (in ESNUG 301) is because ied sits
between you and any stdin/stdout program, and provides ksh-like command line
history and editing. It works on most everything, including ftp, and
(ta-da!) dc_shell.
The reason I have to edit the Synopsys stdin/stout syntax (aside from the
fact that set_arrival has disappeared from the man pages ) is because I am
now dealing with modules that have multiple clocks all mixed in with logic
to be compiled (don't ask).
Now, this is what stdin/stout was invented for, so this should be easy,
right? Well, wrong. The stdin/stout approach assumes that the constraint
setter KNOWNS what inputs and outputs are related to what clocks. That's
fine at the top of the chip, where I've been using stdin/stout for years so
that I can break bidirectional loops, but my lower-level generic scripts
DON'T know that, and don't WANT to know that.
If you do the stdin/stout for each clock and clk_per in a foreach loop,
you'll get silly things like a path from the slow clock, plus the input
delay of the slow clock, ending at a flop clocked by the fast clock.
(Well, I guess this isn't really silly from DC's point of view. You've
effectively told dc that there is a source for each input from each
clock domain with a certain delay, and a sync for each output in
each clock domain with a certain delay, and it doesn't know any better.)
But, this isn't what you really WANT. What you want is for the input
and output delays for a clock to only be applied to paths that end/start on
that clock. So, an input that goes to flops on both the fast and slow
clocks (for example) should have the slow clock's input delay budget on
the path going to the slow clock flop, and the fast clock's input delay
budget on the path going to the fast clock flop. Likewise for outputs.
How do you do this? I'm still trying it out, but the only way I've found
so far is to do it all with editing DC's stdin/stout with ied, and then
setting false paths across all the clock boundaries.
foreach(_clock,all_clocks()) {
foreach(_other_clock,all_clocks() - {_clock}) {
set_false_path -from _clock -to _other_clock
}
}
That's a shame, since I've already gone to a lot of trouble to define the
clocks using harmonics of the fastest clock, then shrinking them to the
target period using minus clock skew. So, I shouldn't have to disable
all the cross-clock paths.
Does anybody know of a better way to do this?
- Paul Zimmer
Cerent Corporation
|
|
