( ESNUG 364 Item 6 ) --------------------------------------------- [02/01/01]
From: [ Socks, the Clinton's Homeless Cat ]
Subject: Latch-Based Designs Are HELL In Lib Compiler, DC, & DFT Compiler
Hi John,
Please make me anon.
I'm an experienced Synopsys DC user but new to latch-based design. My
company's design methodology is latch-based, mixed freely with FFs (which
are just std. cells containing two latches). Clocks are dual-phase and
distributed in both true/inverted polarity. Scan methodology is fairly
similar to clocked-LSSD. Hence there are 4 functional-mode and 4 scan-mode
clocks. Currently we have to wire them manually, this obviously has many
drawbacks. I recently had negative experiences trying to raise the level
of automation using DC and Library-Compiler. Also we tried out
DFT-Compiler. Am I missing something or is this just the state of things?
Issue 1: Modeling of master-slave clocking, "set_signal_type" problem
I found out that DC does not propagate "set_signal_type ... clocked_on_also"
attribute in hierarchical designs (unlike the clock properties). (This is
needed for the master/slave FF modeling style of SYNTH-481941.html)
Since we parameterise register primitives, etc, all our designs are deeply
hierarchical. I find it absurd to have to manually propagate this attribute
down the hierarchy before a compile. (If we omit it, DC only sees one of
our clock phases, and uses a one-phase enable-FF from our library.)
Apparently it used to propagate until 2000.05, then R&D took it out for some
reason that nobody could tell me. This wan't documented in the release
notes either, which leads me to think very few people use it. Now they are
reluctant to put it back in 2000.11. My AC raised STAR 113503 on this, to
allow users to choose the behaviour, but can anyone give me one reason why
this should not be the default? Until then, mixed latch/FF designs will
have to be modelled as if there was only one clock. (We don't personally
care about timing modeling inside DC, but I'm sure that raises issues, too.)
For good measure I also experimented with "create_clock -related_clock" but
that's even more flaky. SOLVIT is just in a complete mess as regards
modeling and synthesis on this.
Issue 2: Modeling of extra clock pins, and implications
We distribute true- & inverted-sense of each clock phase, hence 4 clock
pins. Lib-Compiler can't handle it, neither can DC, doesn't matter whether
the pin group has attribute 'clock' or not. Obviously the inverted clocks
don't occur in the statetables. (There was also no way DFT-Compiler would
accept these were scan-controllable. Without at least making the statetable
unreadably long.) It would be nice to override the tendency to blackbox
everything they can't understand. If we could at least override, we could
script the wiring fix inside synthesis. As it is we have to generate a
kludge library with full physical connections and wire things up, after
scan. If I could at the very least direct all three tools to just ignore
the pins completely, let alone usefully understand the concept of >2 clocks:
create_clock ph1
create_clock ph2 -related_clock ph1 /*this is the slave clock*/
create_clock ph1_b -related_clock ph1 /*just wire any subsequent
clocks*/
create_clock ph2_b -related_clock ph1
Further, not only did DC/DFT-Compiler refuse to use them, they failed to
find their scan-equivalents using either mapping method. If two cells
are scan-equivalent, except for dangling pins which match by name, then
scan-equivalent cells should be found. e.g. non-scan FF and scan-FF with
ph2, sph1, sph2 dangling. ("test_allow_matching_unconnected_pins = true"?)
And finally, even when I manually instantiated them for DFT-Compiler, it
automatically assumed having unconnected pins being 'X' makes a scan-cell
uncontrollable, and there was no command using something like:
set_test_ignore / or
set_test_hold / to stop it.
Surely there will always be pins that DFT-C cannot be made to understand, so
isn't it about time we had a command for this?
Issue 3: Bussed signals not allowed in a Lib-Compiler statetable.
This is only slightly annoying. (We bus the scanclocks, to make the wiring
scripting less painful.)
I'm interested in all responses, John.
Thank you.
- [ Socks, the Clinton's Homeless Cat ]
|
|
