Editor's Note: With the Clinton impeachment and the U.S. firing cruise
missles into Iraq, guess what makes front page news in my local small
town newspaper. Toy soldiers with guns. Yup, I'm not making this up.
Back in 1975, the owner of a local shopping mall made 20 13-foot tall,
wooden toy soldiers that looked like they came right out of Tchaikovsky's
children's Christmas ballet, "The Nutcracker". When the mall renovated,
the owner gave the large wooden toy solders to the town as part of the
town's heritage. ( Hey, it seemed safe at the time. With our American
paranoia over the separation of Church and State, wooden toy soldiers were
about as non-religious as you can get. Who could complain? What's to
complain about? ) Well, never under-estimate the power of The Offended
to find something To Be Offended About. It turns out that, after seeing
the same toy soldiers stand around town each Christmas for 23 years, a
handful of loopy Massachusetts liberals stepped forward to tell the town
officials that they were *offended* because these toy soldiers had toy
*guns* in their hands. And, in this age of the Tyranny of the Offended,
after no discussion, the town officials removed the toy guns from the toy
soldiers and they were given candy canes to hold instead!
I love the irony in this. They're *soldiers*, yet they're not supposed to
have guns! How loopy can we let Politically Correct get before we say:
"Enough!" (Oh, yea, I forgot. Discussion isn't allowed w/ The Offended;
they're simply right because they're Offended.)
And those cruise missiles being fired into Iraq? My guess is The Offended
must think they're full of Christmas candy or something... (Hope there
are no diabetics in Bhagdad.) :^)
- John Cooley
the ESNUG guy
( ESNUG 307 Item 1 ) --------------------------------------------- [12/98]
From: gregbell@znet.com ( Greg Bell )
Subject: Cryptic "OPT-1000" Message When Compiling With Pads Instantiated
Hi John -
Here's a tip for anyone out there in ESNUG land who's getting the confusing
"OPT-1000" error, which looks like:
Error: Need to insert a pad on port 'pci_ad[4]' before
compiling. (OPT-1000)
...or warnings OPT-1004 or OPT-1005 when they try to compile a module that
has hand-instantiated I/O pad cells. Here's what to do: just make sure
that you put dont_touch and dont_use attributes on all the I/O cells (only
one of the two attributes may be required... I didn't check). It's easiest
to do this on the library rather than on each of your instantiation names.
eg: set_dont_touch find(cell, "asiclib/*")
The online help for OPT-1000 is even more confusing than the actual error
message, and SolvIt doesn't have anything on the message.
Company politics and the fact that I'm an independent contractor say I
sign this ESNUG with just my name.
- Greg Bell
Independent Contractor
( ESNUG 307 Item 2 ) --------------------------------------------- [12/98]
Subject: ( ESNUG 306 #13 ) Put Routing Layer Preferences Per Pin In DC Libs?
> I'm a new Synopsys user. Our cell library has lots of ways to save metal2
> tracks by routing metal1 between adjacent cells.
>
> We'd like Synopsys to choose pin connections based on routability. That
> is, if a cell has a set of boolean equivalent pins but only one can connect
> with metal1, then Synopsys should connect to *that* pin if its target
> connection pin is also metal1-enabled.
>
> Is there a way to specify this in the library??? I'd rather not try to
> tweak delay numbers to make one pin more "attractive" than the others.
> Perhaps there is another clever workaround.
>
> - Andy Pagones
> Motorola Chicago Corporate Research Laboratories Chicago, IL
From: tomd@silogix.com (Tom David)
Hello, John,
I saw this post on ESNUG... I've faced that very same problem before.
Basically I've never found a capability within synopsys to deal with this
issue effectively. Usually this problem is dealt with within the
place&route tool. Your P&R tool must have the capability to understand
equivalent terminals. Therefore it will be able to route to the
electrically eqivalent terminal if it's easier to get to. Of course, this
makes your layout generated netlist different from the netlist extracted
from synopsys. This then causes you to have to turn off equivalent device
cheking in your LVS/DRC tool thus causing untold headaches for the folks
doing custom circuits (like pads and rams etc.). If your custom layout
is very tightly controlled this might not be too big an issue. In my
experience though the analog circuit guys are usually a whole lot more
inflexible than your P&R tool. :-) The other way to potentially resolve
this issue is to route just your digital standard cell block and verify it
against your netlist. Once it's verified clean, extract a netlist from
the layout and use this netlist at the top level. If you do this you
won't have to muck with the LVS/DRC issues...
- Tom David
SiLogiX, LLC
---- ---- ---- ---- ---- ---- ----
From: Andy Pagones-ACIC22 <Andy_Pagones-ACIC22@email.mot.com>
John,
This ESNUG mailing list is very helpful! I'm forwarding copies of ESNUG to
my co-workers so they can sign up, too. Anyway, to follow-up on my question:
I found that our Apollo P&R tool supports boolean pin swapping only to fix
timing violations, but not for routing length reduction. Bummer. Now I
gotta beat on the code developers (some more...)
- Andy Pagones
Motorola Chicago Corporate Research Laboratories Chicago, IL
( ESNUG 307 Item 3 ) --------------------------------------------- [12/98]
From: [ A Past Master Of Spin Control ]
Subject: Unspinning The Recent Spin Control In The Avant!/Cadence Lawsuit
John,
As a past master of spin control, I was able to deduce the following from
the recent Avant! press release doing damagment (damage management) on the
recent court banning of Aquarius.
What Gerry Hsu (CEO of Avant!) said...
"We expect to keep growing and intend to become the most diversified
company in the ICDA industry. Since these original charges were brought,
Avant! has grown into a complete front-end to back-end vendor and the
world's foremost supplier of TCAD to ECAD solutions."
What it means...
"Don't sell our stock! We will rely upon other areas of revenue now that
it is clear that we've been caught. We originally stole some source code
to get us going, take us public, and get enough cash to acquire companies
that were clean. We now have a lot of other revenue producing tools, so
don't worry, Mr. Stockholder!"
If you use this comment, please keep it confidential.
- [ A Past Master Of Spin Control ]
( ESNUG 307 Item 4 ) --------------------------------------------- [12/98]
Subject: (ESNUG 306 #7) DC Won't Buffer Module Outputs W/ Bottom-Up Approach
> We are using a bottom up synthesis approach for a chip that we are doing
> with LSI. On our critical paths dc is leaving ***A drive parts on the
> outputs when all the cells in the paths up to the output have C and D
> drive. We are using
>
> set_load load_of (lcbg10pv/BUFA/A) * 5.0 all_outputs();
>
> which might be a little weak for nets that are enclosed by a much larger
> wireload model, BUT even at the lowest compile level the last
> incremental delay is the largest in the path because dc won't upgrade
> from an A drive cell at the output! And these are paths that don't meet
> their constraints at the lowest levels! Why won't dc increase the drive
> strength of our output cells?
>
> - Greg Brookshire
> Peracom Cary, NC
From: [ A New Jersey Synopsys AC/FAE ]
John,
I'm an AC/FAE in the New Jersey office. Just out of curiosity, does the
following help at all?
set_max_delay 0.5 -to all_outputs()
(Using 0.5 might be off; use something representative of your flops'
CLK-to-Q.) What I'm wondering is, with a combination of the set_load on
the output and the timing requirement of a fast path from that output,
maybe this will help convince Design Compiler a high-drive flop really
*is* a good idea. :)
Another thing which helps a bottoms-up strategy go a little more smoothly
is a set_load on the input ports of your submodules, if you're not already
doing it. While set_driving_cell tells Design Compiler what is driving
an input port, set_load on an input informs it that it's sharing that drive
ability with other cells/blocks.
- [ A New Jersey Synopsys AC/FAE ]
( ESNUG 307 Item 5 ) --------------------------------------------- [12/98]
Subject: ( ESNUG 306 #3 ) Bizarre 13% - 41% Area Increase W/ Aspec Libraries
> I'm using Aspec libraries, and Synopsys 1998.02 and 1998.08.
>
> Even though I use no rams in my design, my design team shares a common
> setup script, therefore a "ram.db" is added into everyone's (including my)
> link_library and target_library.
>
> Here's the problem: Although I don't have any rams in my design, the areas
> increase about 15% to 40% if the *unused* Aspec RAMs are linked in!
>
> I submitted this bug to Synopsys two months ago. They re-produced the
> problem but no workarounds for me so far. They talked to Aspec and looked
> over their .lib source and report that it appears to be OK. When I tried
> all three above scenarios using Cascade libraries, I didn't have any area
> problems at all. (The main difference between Aspec libs and Cascade libs
> is that Aspec uses table lookup timing model, Cascade however uses
> piecewise linear model. I don't think this means anything, but it is a
> known difference between the two libs.)
>
> It's been two months. I can't wait any more. Did anyone run into the same
> situation? Any solutions? Thanks.
>
> - Eugene Ko
> Aureal Semiconductor
From: Scott Evans <scott@nplab.com>
My guess is that you are picking up the wire load area attribute from the
ram library and the tool is adding in additional area to account for the
wiring. The area value is probably not specified in any of your other
libraries.
Check the library compiler documentation for more details on the area
attribute for wire_load groups.
Make sure you set your wire load and operating conditions to come from
specific libraries that do not contain this attribute.
- Scott Evans
NeoParadigm Labs San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: eko@Aureal.com (Eugene Ko)
Scott,
Thanks.
There is no wire load in my ram library, only one timing lookup table and
the ram itself in the file.
Synopsys R&D told me that it should be a bug.
- Eugene Ko
Aureal Semiconductor
---- ---- ---- ---- ---- ---- ----
From: William Liao <wliao@vadem.com>
Hi, John,
Do report_area on all variations, then compare the numbers of cells and
nets. You can find them near the end of the reports. If the numbers
differ, then the total area should be different. To find out why they
are different, see the following paragraph.
Also do report_design on all variations. Pay attention to the Wire
Loading Model area of the reports. It should tell you the wire model
Design Compiler is using, and from which library the model is. If each
variation uses a different wire load model, Design Compiler might have
used different versions (1x drive, 2x drive, etc) of the basic cell,
causing changes in design area.
Finally, if nothing else works, do report_cell(find("cell", "*")) on
all variations. This will generate detailed cell reports on your
designs, including the instance name, reference name, source libary,
and most importantly size. In the last row of each report it also
sums up the sizes of all cells. You should be able to figure out
what else changes besides the library.
I hope this is helpful.
- William H. Liao
Vadem
---- ---- ---- ---- ---- ---- ----
From: Jay McDougal <jaym@hpcvcdt.cv.hp.com>
Given that the area increases as you add more rams to the db, this is
probably not your problem. However, it is a possibility and it is easy to
check.
Perhaps the Aspec libraries define some very pessimistic wire load models
and your design is using those during synthesis instead of the ones from
your other library. You can check this by looking at the report_design
output.
- Jay McDougal
Hewlett-Packard
---- ---- ---- ---- ---- ---- ----
From: eko@Aureal.com (Eugene Ko)
Jay and John,
Thank you for help.
There are no wireload models inside Aspec ram, so that wasn't the problem.
I finally got a workaround last night from the Synopsys Support Center.
They said put 'dont_use' on rams. I'll let you know the result after I
test it. Thanks.
- Eugene Ko
Aureal Semiconductor
---- ---- ---- ---- ---- ---- ----
From: eko@Aureal.com (Eugene Ko)
John,
I just verified the workaround from Synopsys R&D/AE. Always set_dont_use on
rams -- doesn't matter if you use them or not. The problem then goes away.
Thank you all for your help.
- Eugene Ko
Aureal Semiconductor
( ESNUG 307 Item 6 ) --------------------------------------------- [12/98]
Subject: ( ESNUG 304 #10 ) Tcl & Synopsys Wants To Buy Your SoC Start-Up
> Dc_shell does suck and designers have complained about it for years (it
> always feels good to know that you're not the only one suffering).
> DC_shell was a hack that got the job done, and you have to give Synopsys
> credit for that (it got you 80% there very quickly). Dc_shell is only
> part of the problem - inconsistent command structure and arguments are
> another (forcing designers to play adventure).
>
> Next year Synopsys will incorporate Tcl/Tk into their tools (Synopsys was
> one of the investors in Professor Ousterhout's company that will take
> Tcl/Tk to the next level). Definitely Anonymous.
>
> - [ Tickle Me Elmo ]
From: Bob Dahlberg <bob@Synopsys.COM>
Hi John,
I have been at Synopsys for nearly 11 years; my current assignment is
managing the Synopsys investment portfolio. I'd like to correct an error
mentioned in ESNUG 304 Item 10 [11/98]: Synopsys does not have an
investment in Professor Ousterhout's company. We have made investments in
Artisan Components, CCT (now Cadence), Gambit, nVidia and Synchronicity.
Your readers may be interested in knowing that we have recently formalized
our investment strategy with the formation of the Synopsys "System on a Chip
Venture Fund". The purpose of the fund is to accelerate the realization of
the "system on a chip". We seek to invest in potential "Star IP" companies
(the next ARM, Rambus, etc.) and complementary tool and groupware companies,
and to play an active role in helping these companies be successful.
If you know of any small start-ups that show serious promise in these areas,
please have them forward their business plans to me directly. To paraphrase
Humphrey Bogart's closing line from Casablanca: "This could be the beginning
of a beautiful friendship."
- Bob Dahlberg, Vice President, Business Development
(aka "the new venture guy")
Synopsys Mountain View, CA
( ESNUG 307 Item 7 ) --------------------------------------------- [12/98]
Subject: ( ESNUG 306 #10 ) Summit's "Visual HDL" vs. Escalade's "DesignBook"
> We have an internal debate going on between buying Summit Design's
> Visual HDL vs. Escalade's DesignBook. What we are looking for is a
> productivity improvement over hand writing VHDL and Verilog code. We
> also would like a tool to help us reuse and modify legacy code.
>
> Do you have any opinions on these tools?
>
> - Michael Patti
> Sarnoff Corporation Princeton, NJ
From: [ Ned Flanders from "The Simpsons" ]
John,
There is no one right answer for everybody. It really depends on your
needs today, where you are heading and where you think each company is
heading. We also had quite a bit of internal debate over these two tools.
Generally, users with with HDL experience favored Summit because it
supports all valid language constructs and its HDL import capabilities.
Inexperienced users were sold on Escalade's ModuleWare libraries along
with the user interface and the features in their state machine editor
and design verification tools. The lack of import capability and full
language support were of lesser concern, since we do not have a lot of
legacy HDL code we need to import. Also their Knowledge Extraction
technology seems very promising. Another benefit of Escalade's approach
is that it is language neutral so it is easy to output either language,
allowing experimenting to see which gives the best result. (Sometimes
it is surprising how much difference that can make.)
Due to my company's sensitivities, please keep me anonymous in all uses
of this note!
- [ Ned Flanders from "The Simpsons" ]
---- ---- ---- ---- ---- ---- ----
From: Fazel Taslimi <ftaslimi@lucent.com>
john,
i have been using escalade for about 2 yrs now. it is a great tool. i
haven't seen anything like it. i have played with summit and (when they
were in business) speedchart. but nothing really stacks up to designbook
from escalade. summit is not very easy to learn and it also not
language independent like designbook is. the equations that you have to
put in has to be either in VHDL or Verilog syntax. about 6 months ago i
was involved in the design of two complex (40k each) fpgas. There were 3
of us on the job. i was the only one with VHDL background the other two
didn't have VHDL background. we took the 2 day training class on the tool
and after that we started designing. we were the first group in Lucent to
have finished our design a head of time. that was mainly due to use of
designbook. it really boosted our productivity (three to four times). due
to our success story the tool is getting attention within Lucent. the other
thing i should mention is the support that i get from these folks, it is
just great. because some of our divisions standardized on summit, we have
an internal summit-related web site. from the discussions on that web site,
i think some of these divisions will be changing over to escalade. summit
has grown too big, they don't support you all that well. escalade is small
and treats you like gold. to sum it up you wouldn't go wrong if you choose
designbook as your graphical entry tool.
- Fazel Taslimi
Lucent Murray Hill, New Jersey
---- ---- ---- ---- ---- ---- ----
From: "Ella van Gool" <ella_translogic@csi.com>
John,
I know this might not exactly be the kind of answer you're looking for
concerning comparing Summit & Escalade, but there are multiple reasons to
at least have a look:
- a number of US and foreign companies have standarised on our option
(Translogic's EASE) above Summit, Renoir and Escalade,
- we offer 80% of the Summit/Renoir/Escalade functionality for 20% of
their price
- we are, for more than 10 years, a small and privately held company,
therefore very flexible
I apologize for this unsolicited mail, but hope it will add to your
due diligence in examining similar tools.
- Ella van Gool
VP & General Manager
Translogic USA Corp. Hollister, CA
( ESNUG 307 Item 8 ) --------------------------------------------- [12/98]
Subject: ( ESNUG 305 #12 306 #6 ) Find 3 Unloaded Nets Out Of 300,000 Nets
> The following UNIX shell script can examine a report_net report file and
> will filter out all nets which have no annotated capacitances: ...
>
> - Chris Bohm
> Analog Devices B.V. Limerick, Ireland
From: [ A Synopsys FAE ]
John,
It appears this user is unaware of the command:
check_design -post_layout
This has been an option since 1998.02 I think. It reports all designs or
instances that are missing SDF, resistance, capacitance or PDEF information.
- [ A Synopsys FAE ]
( ESNUG 307 Item 9 ) --------------------------------------------- [12/98]
Subject: ( ESNUG 304 #11 305 #1) Zimmer's Mother-Of-All Headaches ESNUG Post
> I've got some interrelated questions to throw out to the ESNUG community.
> This is pretty tricky. I suspect there are less than 10 engineers
> worldwide who could understand and/or answer these questions.
>
> Question 1:
> -----------
>
> Like a lot of people, I use default scripts to compile most blocks, and
> I don't mess with these defaults unless I have to. This implies setting
> appropriate constraints WITHOUT knowing the details of the logic inside,
> specifically without knowing what sort of paths exist (seq vs comb).
>
> So, imagine I've got a module that has inputs that go to flops, outputs
> that come from flops, and outputs that come from both inputs and
> flops (commonly known as a Mealy state machine).
>
> So, I want to budget this thing such that the input-to-clock paths get
> 0.85 clock period, the clock-to_output paths get 0.15 clock periods,
> and the combinational (input-to-output) paths get 0.50 clock periods.
>
> This was easy with the old set_arrival, set_max_delay syntax:
>
> all_inputs_no_clocks = all_inputs() - find(port,clkname)
> set_arrival 0.15 * clk_per all_inputs_no_clocks
> set_max_delay 0.15 * clk_per all_outputs()
> set_max_delay clk_per * ( 0.15 + 0.50 ) \
> -from all_inputs_no_clocks -to all_outputs()
>
> Which is why I've kept using the old syntax all this time.
>
> Now, because of question 2 below, I have to move to the "new" syntax
> of set_input_delay and set_output_delay.
>
> The input-to-clock and clock-to_output paths are easy enough:
>
> all_inputs_no_clocks = all_inputs() - find(port,clkname)
> set_input_delay -clock clkname 0.15 * clk_per all_inputs_no_clocks
> set_output_delay -clock clkname 0.85 * clk_per all_outputs()
>
> Unfortunately, this doesn't work for the input-to-output paths. We've
> now told dc that all the inputs and outputs are related to the clock,
> and that the combined delays take an entire clock cycle. So, there's
> nothing left for the comb budget.
>
> Basically, the sid/sod syntax ASSUMES that a clock cycles is consumed in
> the middle. This isn't true for combinational paths.
>
> The only way that I've found to get around this is to declare the
> combinational paths to be multicycle:
>
> set_multicycle_path 2.0 -setup -from all_inputs_no_clocks \
> -to all_outputs()
> set_multicycle_path 1.0 -hold -from all_inputs_no_clocks \
> -to all_outputs()
>
> (The second line is needed to make the hold calculation work correctly.)
>
> Now we have the clock-related constraints out of the way, and we can put
> combinational constraints on. You would think that this could be done by
> using set_max_delay. Unfortunately, I haven't been able to get this to
> work. Instead, I have to create a virtual clock and put output (or input)
> delay on it.
>
> create_clock -name combclk -period 10.0 -waveform {0, 5.0}
> set_input_delay -clock combclk 0.0 all_ins_no_clks -add_delay
> set_output_delay -clock combclk 17.0 all_outputs() -add_delay
>
> All those single-path timing exceptions sound like a potentially serious
> performance hit (although I must admit that on 9802 I haven't actually
> seen much of a problem). Besides, this is MESSY.
>
> Has anyone found a better way?
>
> Question 2:
> -----------
>
> [ Editor's Note: "sid/sod" = "set_input_delay/set_output_delay" ! - John ]
>
> The reason I have to go to the sid/sod 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 sid/sod was invented for, so this should be easy, right?
> Well, wrong. The sid/sod 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 sid/sod for years so that
> I can break bidi loops, but my lower-level generic scripts DON'T know that,
> and don't WANT to know that.
>
> If you do the sid/sod 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 all the same stuff above (Question 1), and then set
> 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
From: Juergen Stallmann <juergen.stallmann@pdb.siemens.de>
Hi Paul, Hi John,
Here are some suggestions concerning your question #1 in ESNUG_305.
We're also working with generic constraints and have been facing
this problem in all of our last projects and also in our current project,
We try to reduce the amount of combinational pathes in sequential
blocks, but as you can imagine, there are still some sequential blocks
with combinational pathes, and you probably don't know where they are.
I'm doing it in this way:
input_delay = 0.5*clock_period
output_delay = 0.8*clock_period
set_input_delay input_delay all_inputs_no_clock
set_output_delay -clock Clkname output_delay all_outputs()
I normally don't specify a related clock for input delays, so dc will
assume the clock of the fanout-tree ff as related clock. If any input
is related to multiple clock domains, ok, you have to specify a related
clock with these inputs.
With these sid/sod (I know, set_input_delay ....), the combinational
pathes would be violated by 0.3*clock_period, even if there's no gate
in this path.
In the next step, I'm looking for all the combinational pathes in
this block. This is done with a dc_shell script and creates a new
dc_shell script, which consists of commands like these for each
combinational path:
set_max_delay path_delay -from input_pin -to output_pin \
-group_path combi_group
Usually I'm allowing a combinational delay of 0.3*clock_period. So
path delay will be defined as:
path_delay = input_delay + output_delay + 0.3*clock_period
Now the automatically created script can be included. As a result, all
combinational pathes are in a separate path group and don't make
trouble in the sequential pathes. So your constraints for your sequential
pathes and you combinational pathes will be considered by dc.
In your early design phase, your combinational pathes may be changing
quite often, so the combi_path script should be invoked before each
compile. As you can't run it on the generic database, you can do it
in this way:
elaborate design
compile without constraints
invoke combi_path_script
apply constraints
define path_delay
include created script with set_max_delay commands
compile
Concerning your question #2, I must agree, it's quite hard if you're
dealing with different clocks in one block. I try to minimize
the number of blocks with different clocks and ports, related to
both of them. If I cant avoid it, ;-( OK, I sit down and write
the specific constraints, or I try to meet the harder constraints even
for the slower clock systems. Maybe I'll get more gates, but when dealing
with 2.5 million gates, who cares.
Hope this helps a little bit.
- Juergen Stallmann
Siemens AG Paderborn, Germany
---- ---- ---- ---- ---- ---- ----
From: gmann@ford.com (Greg Mann)
John,
I think what Paul has shown is that time budgeting is a difficult problem
and that a universal time budget which allows for combinational paths
from input to output and with multiple clocks is at best unreasonable.
It occurs to me that even with only one clock, your previous method of
time budgeting (set_arrival/set_max_delay...) results in timing which
is probably reasonable for each block but is invalid from the point
of view of the big picture. If you have a block "A" which has a
flip-flop feeding a combinational path in block "B" which feeds logic
going to a flip-flop in block "C", then "A" gets 15% of the clock cycle,
"B" gets 85%, and "C" gets 50%, for a total of 150%. You've given away
more time than you have in a clock cycle. (Have I missed something?)
I would try the new design budgeting offered by Synopsys. I haven't
personally used it, but it sounds promising.
- Greg Mann
Ford Microelectronics Colorado Springs, CO
---- ---- ---- ---- ---- ---- ----
From: Brian Jung <bjung@sdd.hp.com>
Hi John,
We ran into this last year too. My problem was an input that went to
clocked element. The output of the clock went through a multiplexor
to the an output port. However, the input also went to the multiplexor's
other selectable input.
We used sid for the input wrt "Clk" and sod for the output wrt "Clk".
Then we used set_max_delay from the input to the output with the exact delay
we wanted plus an offset. The offset was the "Clk" period. This took care of
correcting for the "Clk" relations attached to the input and output ports.
I know this may not be "generic" enough for your app w/ multiple clock
domains. Maybe you already knew this... anyhow, that's been my experience.
- Brian Jung
Hewlett-Packard San Diego, CA
---- ---- ---- ---- ---- ---- ----
From: "Klaasen, ir. C.E." <klaasen@natlab.research.philips.com>
Hello Paul (and John),
Perhaps I am one of the (un)lucky 10 people who understand your two
questions. I have encountered the exact same problems as you have
mentioned, and I came up with similar solutions. As far as question 2 is
concerned, this is what one of my Synopsys spokesmen suggested to do:
If the outputs on the combinational path, already have a set_output_delay
on them, because the output is also the output of a sequencial path (the
given solution for question 1, seems pretty good.)
However, if you only have a set_input_delay, you can still use the
set_max_delay command. This does work! You then have to add the input
delay and the desired comb. delay together ((0.15 + 0.50) * clk_per).
I agree that none of these solution are very nice and simple. It guess,
it would make sense, if you could set both an input- and output- delay in
combination with a max delay.
- Charles E. Klaasen,
Philips Semiconductors Eindhoven, The Netherlands
---- ---- ---- ---- ---- ---- ----
From: "Paul.Zimmer" <paul.zimmer@cerent.com>
John,
Attached is my summary of what I learned from the responses to my "Mother of
All Constraint Headaches..." posting. The bottom line is that there WAS a
better way. So, I'm glad I posted this on ESNUG!
Question 1:
----------
This boiled down to constraining mealy paths (without knowing anything about
the actual paths in the design) in a single-clock environment.
My method involved using set_multicycle_path 2 from the inputs to the
outputs, then creating a virtual clock to constrain these paths.
It turns out that there IS a better way to constain this case. What I
was missing was that set_max_delay COMPLETELY OVERRIDES the normal
clock-to-clock calculation, EVEN IF the clock-to-clock calculation is
"tighter". I didn't understand this (I assumed set_max_delay would set
an independent constraint on the path), and that was why I "couldn't get
set_max_delay to work".
In my case, set_max_delay does exactly what I want, if you know the trick.
The trick is to ADD one full period of the SLOWEST clock to your real
target constraint value, and use this as the max_delay.
When Synopsys looks at this path, the set_multicycle_path command
overrides the normal calculation (eliminating the need for the
set_multicycle_path), and takes the sum of the input and output
delays (which add up to one full clock cycle), plus the path delay, and
compares it to your max_delay value, which is one full clock cycle plus
your target path delay. The net effect is to compare the actual path
delay to the target path delay, which is exactly what you want.
In a multi-clock case, it will do this for the fast clock too, and get
lots of slack (because your max_delay value had a full period of the
slowest clock), but this is harmless.
Question 2:
-----------
This was essentially how to constrain designs with multiple (harmonic)
clocks WITHOUT setting false_path between the clocks.
No one has suggested an alternative yet. So, my final script looks like:
create_clock slowclk -period 100 -waveform {0, 50}
create_clock fastclk -period 10 -waveform {0, 5}
all_ins_no_clks = all_inputs() - slowclk - fastclk
set_input_delay -clock slowclk 60.0 all_ins_no_clks -add_delay
set_input_delay -clock fastclk 6.0 all_ins_no_clks -add_delay
set_output_delay -clock slowclk 40.0 all_outputs() -add_delay
set_output_delay -clock fastclk 4.0 all_outputs() -add_delay
/* constrain mealy paths to 5.0 ns */
set_max_delay 100 + 5 -from all_inputs() -to all_outputs()
/* set false paths between the clocks */
foreach(_clock,all_clocks()) {
foreach(_clock1,all_clocks() - {_clock}) {
set_false_path -from _clock -to _clock1
}
}
This produces exactly the same slack values as my old script, but without
the set_multicycle_path stuff.
Many thanks to all ESNUGers who responded, especially to Brian Jung of HP,
Juergen Stallman of Siemens, and Charles Klaasen of Phillips, who set me
on the right path.
And I HOPE this interests more than 10 people! :)
- Paul Zimmer
Cerent Corporation
( ESNUG 307 Item 10 ) -------------------------------------------- [12/98]
Subject: ( ESNUG 305 #13 306 #8 ) Other Tools To Estimate Power Consumption
> Sente (www.senteinc.com) develops tools which do accurate VLSI power
> estimation and analysis, at both RTL and gate levels, both module-level
> and full chip, both average and peak power.
>
> Simplex (www.simplex.com) also provides transistor-level power analysis
> tools in the same class as PowerMill.
>
> - Eric Filseth
> Sente
From: William Ruby <wruby@Synopsys.COM>
John,
Synopsys certainly offers other power analysis tools besides PowerMill:
PowerGate: Gate-level power analysis with time-based reports and waveform
display (accurate to a single switching event)
Design Power: power estimation early in the design process, using a
quick-mapped (Verilog or VHDL) RTL gate-level netlist and
RTL simulation activity to enable fast trade-off analysis
& identification of power problems.
PowerArc: a library power characterization tool to make db libs for these
Synopsys power analysis tools. (Although most foundries
simply give customers power characterized Synopsys db libs,
there are some customers who make their own ASIC libs who
would want a tool like PowerArc.)
Simplex's Thunder&Lightning calculates IR drop and does electromigration
analysis -- thus it is more like EPIC's RailMill, not PowerMill. (In
closing, I'd like to proudly wear my Marketting Hat and brag that PowerMill
has extensive power diagnostics -- excessive short-circuit current,
excessive leakage, DC paths, rise/fall time violations, circuit topology
checks, etc. -- Simplex's Thunder&Lightning has none of this.)
- William M. Ruby
Synopsys EPIC Technology Group Mountain View, CA
( ESNUG 307 Item 11 ) -------------------------------------------- [12/98]
From: Rodney Ramsay <rramsay1@ford.com>
Subject: How Can I Put Text Strings In DBs Made By Library Compiler ?
Dear John,
Has anybody discovered a way to compile text strings into a db library
with Library Compiler? We have groups within Ford who we make custom
db libs for. We have engineers run off with a db lib, make a chip, and
then they come back asking: "Did that db lib use the XYZ spice data?"
or "Was the 1-2-3 bug fixed with that db lib we used?" I can't, nor
can my db lib "customers", currently just use Design Compiler to look
at the db to find text strings that I'd like to put into db libs that
contain comments / text strings about revs, date created, bugs fixed,
spice assumptions, etc. I suppose you could create some kind of phoney
model with ascii encoded "delays", but I'd like to know if there's a
better way to do this.
- Rodney Ramsay
Ford Microelectronics
( ESNUG 307 Networking Section ) --------------------------------- [12/98]
Cary, NC - Raleigh Technology Corp. - Seeks Verilog, Synopsys, 5-10 years
design exp., ethernet a plus. Stock options! "gbrookshire@peracom.com"
|
|
