Editor's Note: At my first engineering job fresh out of college, I worked
at Data General on ECL based computers. After about a year there, I
foolishly volunteered to be DG's first American "exchange" engineer with
the Japanese division of DG. This meant my taking eight months of very
intensive Japanese language and culture lessons. Oh, and it was simply
brutal! I never knew how much of a slave to English I was until I tried to
learn and understand the Japanese language. It hurt! None of it made sense
to me, constantly keeping track and chasing down those little words like
"na", "ga", "wa", "no", "yo" that are sprinkled around Japanese sentances
and that have no direct English translation whatsoever! Ugh. At night I
would dream that I had died, gone to Hell and all the demons spoke Japanese
to me as they tormented me. Ugh. But, if DG hadn't sold its Japanese
division then, I probably would have had a completely different career...
Last week I just finished taking a week-long course in behavioral synthesis.
Oh, and it was simply brutal! The unnatural, sadistic things they do
with clocking statements and loops on your source HDL defies any human
RTL-style synthesis understanding. To make matters worst, for Synopsys old
timers like myself, you have to do all sorts of unlearning and relearning
on the concept (and even catch-phrase) level, too! Ugh. And all that
additional Designware Developer bullshit obfuscates the learning process
so much so it makes IRS tax codes seem easy, logical and friendly! Ugh!
The funny thing is that my died-and-gone-to-Hell dreams have returned.
And even though my demon-tormentors now speak English, they're making me
design chips using behavioral synthesis! "Ki-ga au-ne?" :^)
- John Cooley
the ESNUG guy
(* - "Ki-ga au-ne?" == "Our thinking is the same, isn't it?")
( ESNUG 271 Item 1 ) -------------------------------------------- [11/97]
Subject: ( ESNUG 267 #6 269 #3 ) *EVERYONE* NEEDS Power Keys W/ DC 97.08
> I have noticed that many of your readers have experienced FATAL ERROR
> ENCOUNTERED when compiling with 1997.08. We were experiencing this problem
> using the AMI 6G5 library. ... We traced the problem to I/O buffers. If
> there was an I/O buffer in the design, the compiler would crash. ... We
> turned it in to the Synopsys support center and they could not re-create
> the problem. ... All of a sudden I received an email from Synopsys
> containing a Power Compiler key and a note indicating that this would
> solve my problem. Sure enough, the compiler completed without crashing on
> the design and our test cases.
>
> - William G. Eign
> Xerox Corporation
From: Rick Weiss <rickw@nablewest.com>
John,
We, too, are using 1997.08 here, and were having alot of problems with FATAL
ERRORs. Synopsys hotline gave me one workaround that fixed some of the
problems:
Do a "compile -no_map" then a "compile"
But for the rest of the problems, synopsys could NOT reproduce my FATALs.
When I read the ESNUG 269 Item 3 (above), even though my testcases did NOT
involve I/O cells, I suggested that synopsys try compiling my testcase
*without* a PowerAnalysis license. Sure enough, it indicated that was the
problem. (The synopsys people were automatically accessing the PowerAnalysis
keys which is why they couldn't replicate my problem.) Now with my temp
power-analysis keys, I can now finally produce a netlist. (Thanks ESNUG!).
- Rick Weiss
N*ABLE Technologies
( ESNUG 271 Item 2 ) -------------------------------------------- [11/97]
Subject: ( ESNUG 270 #6 ) I Miss The SOLV-IT Puns!!! :(
> If you are on the SOLV-IT mailing list, you are probably aware there is
> a new owner of the mailing list. This person, unfortunately, has decided
> not to follow the previous owner's policy to put all the information in
> the form of puns, instead opting for a straightforward-here-is-your-info-
> in-black-and-white approach. Now, I usually would not have a problem with
> this, but I used to look forward to getting SOLV-IT just for the puns. Of
> course, there was the added benefit of getting the great info that comes
> along with SOLV-IT, too. Now, all I have to look forward to is plain
> info....no fun....and no diffenent than other comapnies.
>
> I know, I KNOW, you do not want to start flame wars on ESNUG, but I thought
> this was important, because those puns would usually draw my eye to the
> more important pieces of info. Am I crazy?!?
>
> Oh well, I'd really like you opinion on this. If you think that I'm not
> crazy, then maybe you could post some editorial about this on ESNUG,
> encouraging readers to write the new owner to put the same "fun with
> pupose" content as the last owner.
>
> Hoping to not go crazy.....
>
> - Ted Boydston
> Harris Semiconductor
From: Janet Kaul <jmk@synopsys.com>
Dear John,
I'm very glad Ted enjoyed the results of my somewhat bizarre sense of humor
as much as I enjoyed writing the Scout. However, when looking at the Scout
as created by Catherine, the new SOLV-IT! editor, I urge you to remember a
couple of things:
1. I was at Synopsys for a couple of years when I started doing the
Scout, and was already comfortable with my management and position.
Catherine is very new to Synopsys. She has a wonderful sense of humor,
but is rightfully cautious with it until she knows her customer base
and the company atmosphere. Feedback like yours will certainly help her
justify finding her own style, although it may be very different from
mine. But diversity makes the world an interesting place!
2. We got as many complaints about my puns as we got compliments, and I
was several times cautioned to tone down my writing. You just can't
please everyone. Again, having verbal customer support is essential
to taking risks, so by all means, mail your feedback to ESNUG.
Thanks again for the compliments. I know Catherine works very hard to
support you, and hope you will give her your support as well as she
establishes her own style on the Scout. I assure you she's more than
capable of the job she's taken on, & has already improved SOLV-IT! immensely.
- Janet Kaul
Past Editor Of The Synopsys "Scout"
( ESNUG 271 Item 3 ) -------------------------------------------- [11/97]
Subject: ( ESNUG 267 #6 268 #2 270 #7) DC 1997.08 -- To Use Or Not To Use?
> Our fatal errors with 1997.08 are related to the use of parameterized
> sub-modules. If you analyze/elaborate a design that instantiates
> a parameterized block, dc_shell croaks just as it tries to build
> the sub-module. So far I've observed this on two separate designs.
> Since we make heavy use of parameterized blocks, this is a major
> roadblock for us.
>
> We're using Verilog, although I'm not sure yet if that's significant.
> Unlike Howard Landman, we don't use connection_class at all. For
> now, 1997.08 has been declared unfit for human consumption around
> here while I try to find a work-around.
From: "Tom Harrington" <tharring@ford.com>
John,
To update the fatal error situation with Synopsys 1997.08: Recently I heard
back from the support center. They've opened a STAR for the problems we're
seeing. At our site, we'll be sticking with 1997.01 until we get either a
bug-fix release, or until 1998.01 shows up.
For those keeping score, it's STAR 48884.
- Tom Harrington
Ford Microelectronics, Inc.
( ESNUG 271 Item 4 ) -------------------------------------------- [11/97]
Subject: (ESNUG 268 #5 269 #4 270 #5) *WHO* Is Using Behavioral Compiler?
> For designs that contain memories and/or sequential Designware components
> that BC is required to stall, Victor Duvanenko is absolutely correct. For
> other designs, BC can support the stall functionality. We are currently
> planning on expanding the scope to include memories and sequential
> Designware components.
>
> - [ A Synopsys BC CAE ]
From: Victor_Duvanenko@truevision.com (Victor Duvanenko)
John,
The trouble with my design space is that a destination FIFO (where my
results go) gets full and must tell the rest of the logic/pipe to stop
(stall). BC needs to support simple VHDL constructs as follows:
wait until clk = '1';
go_registered <= go;
if ( go_registered = '1' ) then
all of my pipe logic goes here...
end if;
Currently BC generates such gobble-gook when it sees this... The result
need to work not only with DesignWare components, but all BC constructs
(such as memories, FIFOs, and random logic). Otherwise, the designer is
more productive not using BC. Keep in mind, this is the case of "my design
space". BC may work perfectly fine for other "design spaces", and the only
frustration that I'm expressing is that of not being able to use a more
powerful tool, to be more productive, when BC is so close to being able to
handle "my design space".
- Victor J. Duvanenko
Truevision
> If you choose to use BC in the super-state mode, then the tool has
> additional degrees of freedom. These degrees of freedom can be used to
> adjust latency and other cycle-specific behavior. If you want to take
> advantage of efficiencies which can be generated by allowing the
> compiler to decide when an output becomes available then you need to be
> careful at the interfaces. Using a data available signal to handshake
> with external blocks can make your design more robust, flexible and
> reusable in general. When the cycle specific timing is unknown then the
> handshaking is essential.
>
> If using handshakes is unacceptable within your design methodology then
> BC can equally be used in cycle_fixed mode which preserves the
> cycle-specific behaviour of the design at the behavioral, RTL and the
> gate level. BC is still able to schedule and share operations etc in
> your design.
>
> - [ A Synopsys BC CAE ]
From: Victor_Duvanenko@truevision.com (Victor Duvanenko)
John,
Maybe it's been a while since I've looked at BC, or maybe BC has improved,
but here is the scenario that I remember which BC could not tackle and why
I say that BC fails in the basics of hierarchical design. I code up a BC
block that may or may not generate a data item on every cycle, so I have a
signal calle "valid" that accompanies the data output. Then since my blocks
are symmetrical, my next block can take the input on every cycles, but once
in a while it can't. So, my next block has a handshaking signal going back
to the first block called "got_it".
This methodology is followed at nausium.
What BC could not handle is the fact that there was a two-way handshaking
mechanism (which is very common - like PCI-bus's IRDY# and TRDY# signals),
where the sender and the reciever both have flow control. BC wanted only
one of the blocks to be able to control the flow of data, but not both. To
me that meant that I could design only certain blocks with BC (the ones that
BC could handle) and the rest with an RTL methodology. That once again may
be enough of a productivity gain for some "design spaces", and there maybe
lots of "design spaces" that BC can handle very well, just not the one I
needed. At the time when I took the BC class I spoke to the BC CAE and he
admitted that BC couldn't handle stalling or the two-way handshake, but that
in the future BC would improve and take on more "design spaces". I'm just
more ready that most to move beyond this RTL-level design methodology that
we've been crawling with. I'm very glad that Synopsys continues their
relentless march toward the next level of design tools (good job!) - I just
wish that it was here already.
Enjoy,
- Victor J. Duvanenko
Truevision
( ESNUG 271 Item 5 ) -------------------------------------------- [11/97]
From: Raja Gosula <Raja_Gosula@notes.seagate.com>
Subject: Constraining "Wraparound" Multicycle / Single Cycle Paths
> I need to run a register every other clock cycle because there is a path
> (Q-A) driven by this register to the register itself that takes more than
> 1 cycle to propagate. I use "Enable" signal that toggles each clock cycle.
>
> +--------------------------------+
> | |
> | |\ |
> +-----|B \ +-----+ |
> | | | | |
> | |--------|D Q|-------|
> DoubleCycle| | | | |
> +-----|A / | Dreg| |
> | |/| | | |
> Enable | | | | |
> ----------------+ Clock-->C | |
> | +-----+ |
> | +--------------------+ |
> +-------| Double-cycle logic |---+
> +--------------------+
>
> signal DoubleCycle : sul;
> signal Dreg : sul;
> process(Clock)
> begin
> if(Clock'event and Clock = '1')
> if(Enable ='1')
> Dreg <= DoubleCycle;
> end
>
> I add following lines to the synthesis script:
>
> set_multicycle_path 2 -from Dreg -to Dreg
> set_multicycle_path 1 -hold -end -from Dreg -to Dreg
>
> I need a wraparound path (Q-B) to be single-cycle but it has the same
> starting and ending points as a path specified to be a double-cycle.
>
> Question: How can I constrain the wraparound path to be single-cycle ?
>
> - Raja Gosula
> Seagate
From: ryan@oscsystems.com (Ken Ryan)
You need what's called "path segmentation". There's actually a good app
note in the Synopsys documentation, but here's the Reader's Digest condensed
version: Define separate timing constraints for the paths Q->B, Q->A, A->D
and B->D. Make sure they're consistent, e.g. the Q->B path ends at the same
time the B-> path starts. You can then apply multicycle path constraints
to the segments independently. Example:
create_clock -period 10 -name "CLK"
set_input_delay 7.0 find(pin,"MUX/B")
set_input_delay 6.0 find(pin,"MUX/A")
set_output_delay 3.0 find(pin,"MUX/B")
set_output_delay 4.0 find(pin,"MUX/A")
set_multicycle_path 2.0 -from find(pin,"REG/Q") -to find(pin,"MUX/A")
Note the paths through A and through B each add up to the clock period. You
have to do this manually, Synopsys provides no means to do it automatically.
- Ken Ryan
Orbital Sciences Corp.
---- ---- ---- ---- ---- ---- ----
From: olsenc@kodiak.ee.washington.edu (Clint Olsen)
Do you really need this path Q-B like this? Why not use a gate on the clock
signal?
+--------------------+
+---| Double-cycle logic |---+
| +--------------------+ |
| +-----+ |
| | | |
+---------|D Q|------------+
| |
| Dreg|
clk+----\ | |
| |---->C |
en +----/ | |
+-----+
Perhaps I've overlooked something?
- Clint Olsen
University of Washington, Seattle, WA
---- ---- ---- ---- ---- ---- ----
From: wehr@mikro.uni-stuttgart.de (Andreas Wehr)
"Perhaps I've overlooked something?" Yes, glitches, race conditions,
testability, ATPG, all advantages of synchronous design.
- Andreas Wehr
Institute for Microelectronics Stuttgart
( ESNUG 271 Item 6 ) -------------------------------------------- [11/97]
From: "Yuan (Steve) Hwang" <hwang@eng.adaptec.com>
Subject: Watch Out For Infinite Loops During Designware Mapping !!
John,
We ran into infinite loops during Designware mapping for some of the
designware component (DW01_incdec, DW01_GP_SUM) of 97.01 and 97.08.
Our current workaround is dont_use them from Designware library, and I am
waiting for more information from Synopsys. However, I want to know if
any designers have seen the same problem or any other workaround.
set_dont_use (standard.sldb/DW01_incdec)
set_dont_use (standard.sldb/DW01_GP_SUM)
Regards,
- Yuan (Steve) Hwang
Adaptec
( ESNUG 271 Item 7 ) -------------------------------------------- [11/97]
Subject: ( ESNUG 270 #9 ) Seeking DesignWare Foundation Licensing Tricks
> We have less DW Foundation licenses than DC licenses. Currently we have
> the designers not point to any of the advanced DW architectures unless
> their design is not meeting timing. Does anyone know of a way to only
> check out the DW Foundation license when you want to write out the design
> and maybe run everything else in eval mode?
>
> - Russ Ray
> Mitsubishi
From: Chris Noland <cnoland@cisco.com>
Hi John,
If you have any information regarding a fix for ESNUG 270 item 9, which was
forwarded to me, I would appreciate it as it is currently near and dear to
my heart.
- Chris Noland
Cisco
( ESNUG 271 Item 8 ) -------------------------------------------- [11/97]
Subject: ( ESNUG 269 #9 ) Seeking Tips & Tricks W/ Asynchronous Synthesis
> I am trying to learn and put into "real" practice synthesizing some
> asynchronous logic using Synopsys. Do you mind giving me tips on the
> general guidelines for such designs, how to avoid any possible pitfalls,
> and any sample scripts?
>
> - Mehrdad Toofan
> SMOS
From: pbe@cs.man.ac.uk (Phil Endecott)
Dear John,
I was quite suprised to see this message on ESNUG since Synopsys is
inherently very much a synchronous tool. I'll be interested to see if
there is much followup from other readers.
The group that I work as a member of here at the University of
Manchester, England has developed quite substantial expertise in
asynchronous design. We have implemented two asynchronous versions of
the ARM microprocessor and are now working on a third; these chips
have advantages or potential advantages over their synchronous
counterparts in the areas of power consumption, electromagnetic
compatibility and possibly performance. Our current design is a
collaborative project with a German telecomms company and will end up
in some of their products.
The fact the our synchronous competitors have tools like Synopsys to
help them puts us at a disadvantage - most of our work to date has
been old fashioned manual design. Realising the problem we have put a
fair bit of effort into tools, and my work over the last couple of
years has been developing a behavioural modelling language. At
Manchester we haven't done much work on synthesis (apart from a couple
of postgraduate student projects). Others have put effort in this
direction though. Philips have an excellent system called Tangram
which has produced some really incredible results - in one case they
improved the power efficiency of an error detector/corrector chip by
two orders of magnitude over the synchronous version. Tangram's main
problem is that it is proprietry, so if you are a potential competitor
you can't have it. Another tool that also has great promise is an STG
synthesis tool called Petrify from the University of Newcastle and
others. This takes a hybrid STG/Petri Net description of a circuit
and generates a speed-independent circuit from them. This approach
works really well for smallish subcircuits (<10 gates say); for bigger
things you need to do some decomposition by hand beforehand. The
input notation also takes a bit of getting used to.
I would be very interested to hear what sort of circuits designers are
looking at. I think I have been exposed to most of the asynchronous
synthesis tools around, and I would be keen to help point them in the
right direction. You might also like to have a look at our web page:
http://www.cs.man.ac.uk/amulet
Somewhere in there you can find a list of asynchronous tools, a searchable
bibliography, links to other groups doing async. work, etc. etc.
- Phil Endecott
University of Manchester, England
( ESNUG 271 Item 9 ) -------------------------------------------- [11/97]
From: "J.H.Wu" <dragonwu@faraday.com.tw>
Subject: How Does Design_Power "See" Mixed-Voltage I/O Cells?
Hi, John and the ESNUG guys.
Can anyone tell me how design power calculate "switching power" for
mixed-voltage I/O cells? For example,
core=5V interface=3.3V
How can I get the accurate switching power for an I/O net on Design Power?
- Jeng-huang Wu
Faraday Technology Corp., Taiwan
( ESNUG 271 Item 10 ) ------------------------------------------- [11/97]
From: Ori Chalak <ori.chalak@analog.com>
Subject: Discharge Characterization In A Synopsys Library
Hi John,
I am looking for the right way to characterize discharge for a Synopsys
library. Since Discharge is a cell that has only falling edge only, I
wonder whether I should specify some value for the rising edge or ignore
the rising edge altogether.
Also is it better to define the Discharge cell as a tristate?
- Ori Chalak
Analog Devices Israel
( ESNUG 271 Networking Section ) -------------------------------- [11/97]
Cupertino, CA -- N*ABLE Technologies seeks ASIC designers/verifiers with
Verilog -> Synopsys -> standard_cell design flow exp. "rickw@nabletech.com"
|
|
