Editor's Note: When I told my girlfriend I had to go to a wake, I had no
idea how odd my evening was truely going to be. She and I just got back
from a 3 day weekend and, upon returning, I found that "George" had left
a message on my telephone answering machine on Friday night that his
mother had died and the wake was on Tuesday night. I didn't really know
George. I met him at a personal growth seminar. But this being his time
of need, I, and quite a few of the other men from the seminar, were
there to support him.
The idea was to all meet after the wake in the parking lot of a well known
MacDonald's restaurant. George came with his dad, George, Sr. -- which
surprised us all because George hadn't seen his dad nor talked with him
substantially in 17 years (due to the really bad divorce his parents had
17 years ago.) We hung around in the parking lot for about 1/2 an hour
doing the usual mourning support stuff and were about to all go home when
George looked next door, saw a strip club there, and said: "Hey, let's
go in. Wanna go, dad?". Dad said "OK" and suddenly with eyes that told
me he needed this, George asked: "John, do you & some of the guys want to
join us?" I knew to say "yes" and then forced myself through a bizarre
shifting of mental gears from John-The-Mourner into John-The-Hedonist.
Once we got in and seated in the club, I then saw what was really going on
and instinctively started asking George, Sr. all sorts of questions about
his life. It took a while, but eventually George and George, Sr. got a
conversation started that they hadn't had in 17 years. They didn't even
notice the dancers. I and the other guys then did our best to focus on
the nude dancers to give this father and son the time and privacy they
so desperately needed after 17 years. It felt good.
Later that night, when I got home, I thought to myself: "My clothes reek
of cigarette smoke, I've had too many beers, about half a dozen women
(whose real names I don't know) collectively got about $100 from my
wallet in exchange for their nude dancing,... and *THAT* was a *wake*?!!?"
- John Cooley
the ESNUG guy
( ESNUG 265 Item 1 ) -------------------------------------------- [9/97]
Subject: ( ESNUG 264 #6 ) Going Verilog to VHDL Using Synopsys & Summit
> I want to reuse some Verilog code that meets timing that uses the same
> clock and technology as my design. The problem is that my design and
> testbench are both in VHDL. So I wrote out the Synopsys elaborated
> verilog code as VHDL. Then I used it in my design in a Summit Visual HDL
> enviroment with no problems. In Synopsys, it analyzes with no problem,
> then it has errors in elaboration. What methodology do you suggest I use
> for reusing Verilog in a VHDL design?
From: Della Budell <dbudell@us.ibm.com>
John,
This is in response to ESNUG 264 Item 6, in which the engineer gets the
following error when trying to elaborate a VHDL design that had originally
been Verilog:
Error: Cannot determine type of the aggregate
in routine Downlink_FSM_0 line 1459 in file
'/synopsys/vhdl/HL.vhd'
(This error can occur if an aggregate and a generic appear in the
same component instantiation.) (HDL-206)
I don't believe it has anything to do with converting from Verilog to VHDL.
I had this problem when reading in SGE-generated VHDL. I got around it by
deleting the aggregates (the '(xx downto yy)') from the left-hand sides of
the component instantiation of the design which also had generics. If
anyone knows a way to generate the VHDL in the first place without the
aggregates, I'd like to hear about it.
- Della. J. Budell
DSP Design and Development, IBM Corp.
( ESNUG 265 Item 2 ) -------------------------------------------- [9/97]
Subject: ( ESNUG 264 #1 ) Synthesizable IP Is *Unprotected* IP
> On one hand, we want to distribute IP to our customers, so they
> can synthesize them to gates, adjust the synthesis to meet their
> own constraints, and simulate with back annotated information
> the entire ASIC. On the other hand, we want to guarantee that our
> customers cannot copy the IP and make their own, *AND* we do not want
> them to be able to simply re-synthesize to another process after we have
> completed the design stage with them, and then fab it somewhere else.
From: "Janick Bergeron" <janick@qualis.com>
John,
In my opinion, this situation would be better resolved and in a more
timely manner if the business adapted to the currently available
technological situation instead of looking for or inventing a technology
to match its business process.
TI should view IP and foundry as two separate businesses and treat them
as such: sell IP as a separate product from manufacturing services.
Of course, the tight integration of an IP provider with an IC manufacturer
could be used as a competitive advantage: proven in silicon, default
synthesis scripts for typical performance parameters, built-in DFT, etc...
none of the benefits you'd get if you only purchased the IP and went to
another manufacturer.
Financial incentive could also be used to encite customer to stay with TI
for the manufacturing. For example, royalties could be waved if the IP
is manufactured with them.
Encryption and licensing should not get in the way of getting value out of
purchase.
- Janick Bergeron
Qualis Design Corporation
---- ---- ---- ---- ---- ---- ----
From: David LINSLEY <dlinsley@baea.com.au>
John,
I really liked 'The Engineer's Song'... we've just had a round of
'fat-trimming' here and we're all still a bit down so that brought a smile
to everyone's faces (well maybe a few managers won't like it too much).
Steve Korson of TI asked a quetion about Synthesizable IP. I have a
comment for him.
It sounds like what Steve is trying to do is something like trying write a
compiler which produces code which will run on the user's computer,
but which cannot be sold (or given) to anyone else without paying a
royalty to the writers of the complier. You could imagine potential
customers lining up to laugh then run away. IMHO the two 'wants' are
mutually exclusive and the only thing to do is to make the fabbing
attractive enough that the customers won't want to go somewhere else.
And, hey, if you make it really attractive, maybe you could win some
customers away from the competitors in your mythical IP arena; after all,
they will be facing the same dilemma as yourself.
I'm sorry, but from the other side of the world all this IP protection stuff
sounds really childish. In the end, if there are not enough swings and
roundabouts for everyone then the least popular kids will just have to go
and play somewhere else. (Although I suspect, given the way things
are, they'd organise a protest rally and either get the council to build
more roundabouts or get the park closed down so nobody could play).
- David Linsley
British Aerospace Australia
---- ---- ---- ---- ---- ---- ----
From: Moe Shahdad <mshahdad@viewlogic.com>
John,
By definition, synthesizable IP is in source form, and therefore it cannot
be protected. Majority of IP vendors fall into two buckets: soft and hard.
Soft IP vendors add value to their IP by demonstrating the quality of
their IP, i.e., demonstrating that the IP can be implemented in a sample of
technologies with good results for area, timing, or power. They then
supply the IP source to the user, who would design with the IP, and if
necessary modify the IP.
Hard IP vendors add value to their silicon by having a variety of IP blocks
that are targeted to their silicon. These blocks tend to be available only
from one source in order to lock the customer to the vendor. Hard IP is
optimized for the vendor's process and is generally distributed in a
protected form. In order to achieve this optimization, the IP is generally
synthesized and implemented in layout. Some hard IP vendors provide
configurable IP, which allows the user to configure a block for a specific
technology, memory size, co-processors, etc. In this case, the IP user may
receive a configurable block that he can play with to select a configuration.
During this process, the IP user receives only those protected views of the
IP that are necessary for his design, such as a simulation view or a timing
view. This is one of the primary application areas of VMC to protect
functional and timing information. It allows the IP vendor to disclose
sufficient information to enable the use of the IP, but not too much to
compromise the intellectual property of the vendor.
- Moe Shahdad
Viewlogic Systems
( ESNUG 265 Item 3 ) -------------------------------------------- [9/97]
Subject: (ESNUG 264 #3) 1.5 Hrs "Design Rule Compile" Now Takes 24 Hrs!
> I have a design, the top level of which compiled under synopsys3.4b in
> roughly 1.5 hours. ... In both 97.01 and 97.01-01_44683, that same
> compile takes over 24 hours (basically 24 hours fixing design rule
> violations). I have tried this using vendor libraries which were designed
> for 3.4b and new vendor libraries designed for 97.01. Again, most of the
> time (basically 24 hours) is spent fixing design rules. I've tried a
> number such as always using "best case tree", turning off automatic
> wireload selection which chose a chip level wire load (enclosed mode) and
> instead chosing a very small wire load. Any ideas?
From: Maurice_Labedan@hp.com (Maurice Labedan)
Hi John,
I experienced the same kind of problem; in my case the reason was very
simple but took some time to come out. In 3.4b, my library had asynchronous
FFs (and so the reset signal was declared as false path). In 1997-01, my
library had synchronous FFs only (and so the reset signal was no more
declared as false path). The difference in timing run was from half an hour
to 24 hours. And first of course I thought it came from the new Synopsys
revision ... It might look stupid, but may be have you got the same kind
of pathes !!
- Maurice Labedan
Hewlett-Packard
---- ---- ---- ---- ---- ---- ----
From: agelman@metaflow.com (Anatoly Gelman)
Hello, John.
I've had similar experience though not as dramatic as reported above.
Here are the results of experiment I've performed five monthes ago for one
module in my design. I did not try any other modules, and I don't know
if the noticed increase in run-time is a common experience with 1997.01.
My application is a high-speed microprocessor design.
Based on this experiment my basic conclusion was that 1997.01 barely
beats 3.4a at the expense of 2x increase in run-time. And this is true
only when the two major new features of 1997.01 were disabled. If enabled,
results were much worse.
Here are the results:
slack area run_time
----------------------------------+--------+------+---------
1997.01
new_sizing=true new_boolean=high -0.95 329700 ~2hrs
new_sizing=true new_boolean=med -1.31 326730 ~2hrs
new_sizing=true new_boolean=low -0.76 329025 ~2hrs
new_sizing=true new_boolean=false -0.63 326250 ~2hrs
new_sizing=false new_boolean=false -0.62 325635 ~2hrs
3.4a -0.64 327645 ~1hr
"New_sizing" reflects the state of "compile_new_gate_sizing" variable.
"New_boolean" reflects the effect of "compile_new_boolean_structure"
variable and "set_structure true -boolean true -boolean_effort <effort>"
command.
I am guessing that this user might want to try the following before doing
the compile:
set_resistance 0.0 find(net,"Logic0");
set_resistance 0.0 find(net,"Logic1");
It's possible that you are dealing with high transition times due to
fanout-driven computation of wire resistance value. I would guess the
Logic0/Logic1 nets have huge fanout in your case. You might also try this
instead before you start the compile:
set_max_fanout 15 current_design()
Just an idea. Have no clue though what changed in 1997.01 compared
to 3.4 in light of your problem.
- Anatoly Gelman
Metaflow Technologies
---- ---- ---- ---- ---- ---- ----
From: Terry_Hussey@3com.com
Hi John,
Apparently synopsys has changed the set_driving_cell command so that it
now annotates design rule constraints. I have the following command in my
compile script:
set_driving_cell -library (lib name) -cell(driving cell name) -pin
(driving pin name) all_inputs
Apparently this will take the max_transition design rule from my library
for that driving cell and apply it to all_inputs. However, it is somehow
placing that constraint on the logic0 and logic1 nets. Synopsys has not
been able to explain why this is happening. I did an "all_connected"
on logic0 and logic1 and verified that none of the input ports of my design
were inadvertantly connected to those nets (which was a possible
explanation); none were.
So, logic0 and logic1, which have many many loads, are now being targeted
for a design rule fix because they violate the library max transition of
2 ns. The large transitions on logic0 and logic1 also propegate to other
combinatorial logic to which they are connected. Hence there are alot of
design_rule constraints to fix.
Synopsys has a switch, however, called "-no_design_rule" which causes
set_driving_cell to revert to its old behavior. Sure enough, using that
switch caused a big improvement (down to about 7 hours of design_rule
fixing from 24 - not quite to 1.5 hours though). There are still
some things about the compile that look weird but I don't have my arms
around the issues yet.
Hopefully this is not the best that 97.01 can do.
- Terry Hussey
3Com Switching Division
( ESNUG 265 Item 4 ) -------------------------------------------- [9/97]
Subject: (ESNUG 264 Item 7) Efficient/Cheaper Use of Synopsys licenses
> I have a "thrifty" question: Do you know if the HDL-Compiler
> licenses are used only during the "read" and "write" in dc_shell or
> is it sometimes invoked during "compile"? My thought is of saving
> some $'s by buying one HDL-Compiler for several Design-Compiler
> licenses. Will this work or have some of your readers found some
> problems with this approach?
From: zehentner@heidenhain.de (Zehentner Georg)
Hi John,
Ori Chalak asks whether the (V)HDL-Compiler-License is used during compile.
I say: YES, because I added the command "remove_license VHDL-Compiler"
to my script. My "license.log" file tells me, that Synopsys "checks-in" the
VHDL-Compiler-License which the remove_license-command and then it does
"check-out" the License again during the compile-command:
8:52:52 (synopsysd) OUT: Design-Compiler a10354@asic02
8:53:18 (synopsysd) OUT: Test-Compiler a10354@asic02
8:57:03 (synopsysd) OUT: VHDL-Compiler a10354@asic02
9:01:29 (synopsysd) OUT: DC-Expert a10354@asic02
Regards,
- Georg Zehentner
Heidenhain GmbH
---- ---- ---- ---- ---- ---- ----
From: Jeff Freeman <jefff@mars.sps.mot.com>
John,
Beyond initial compiles, I have seen DC use either an HDL or VHDL compiler
license when elaborating DesignWare parts.
- Jeff Freeman
Motorola
---- ---- ---- ---- ---- ---- ----
From: [ "Only The Paranoid" ]
For a while we had twenty or so engineers using Design Compiler with
only three HDL-Compiler licenses. I just put a
"remove-license HDL-Compler" in the scripts after the verilog files
had been read and we didn't have any problems.
As my leader says, "Only the paranoid survive", I'd better ask you
to post this anonymously. Thanks!
- [ "Only The Paranoid" ]
---- ---- ---- ---- ---- ---- ----
From: Ori Chalak <oric@actcom.co.il>
Hi Jhon,
I now know further that the HDL Compiler is sometimes invoked during Hi Level
Optimization (HLO). Since HLO is invoked in the beginning of compilation,
the HDL Compiler license will be checked out all along the compilation
which means you have to have 1 HDL Compiler per 1 Design Compiler license.
The question now is - how often HDL Compiler is used during HLO?
- Ori Chalak
Analog Devices Israel
( ESNUG 265 Item 5 ) -------------------------------------------- [9/97]
From: Hesham El Adly <hesham@cae.ca>
Subject: Impressions Of BC With BOA, BRT, DesignWare Developer, & BCView
Hi John,
I've read with some interest the comments about BC recently on ESNUG. I
thought that I would share some experiences with BC mixed with BOA, BRT,
DesignWare Developer, & BCView.
We've been using BC for quite some time and are fairly experienced with the
"subtleties" of the tool. We design high-end real-time graphics systems for
the commercial and military flight simulator market.
Our deep sub-micron ASIC designs are datapath intensive and highly
synchronous. Our datapaths typically use large-bit width operators, make
extensive use of pipelining, and are sometimes massively parallelized to
meet performance goals.
We've focused much of our efforts with BC on using its BOA/BRT optimization
capability since most of our resources are clocked on every cycle - ergo no
scheduling required.
BOA, Behavioral Optimization of Arithmetic functions, can transform a
datapath structure to a functionally equivalent structure using faster
arithmetic operators such as carry-save-adders. Engineers skilled at
datapath design have been manually coding their datapath to perform
"BOA type" optimizations for years but BC can do some of these
optimizations nearly automatically. Timing of datapaths arranged in
tree structures can be improved with BOA with a potential hit in area
and without requiring the engineer to be a datapath expert.
BRT is just a smarter "balance_registers" that requires a BC license. BRT
can move registers across hierarchy and will try to place registers where
they have the least area impact. "Balance_register" will simply place
registers at fixed points in a timing path without taking into account the
area impact. "Balance_register" is also not able to move registers across
hierarchy.
We still schedule some of our designs through BC to take advantage of some
BC features such as loop pipelining, automatic fsm generation, etc. We
also, of course, have many RTL blocks that are compiled with DC.
Wrapping sections of code with DesignWare Developer is a critical
requirement in achieving high performance designs with a behavioral
methodology. Wrapping components is done to:
- improve timing accuracy
- speed up BC compile time
- reduce complexity of a design to BC
- encapsulate memories
In order to speed up compile, BC makes some assumptions as it times through
operators. Unfortunately, these assumptions sometimes leads to operators
that BC thinks do not fit into the specified cycle time. These same
operators, when compiled (default switches) with DC, are then sometimes
found to meet the cycle constraint. This issue can be resolved by either
pre-compiling these components and wrapping them or by relaxing the clock
period through BC.
DesignWare Developer is a very useful tool but is unfortunately difficult
to use properly. Synopsys needs to put some effort into improving
Developer's ease of use, providing more automation, improving its error
reporting, and providing better documentation.
One stumbling block many users have with BC has been with the lack of an
efficient interface. Users trying to debug their designs are sometimes
frustrated by the difficulty in understanding and correlating BC's reports.
With the introduction of BCView, the interface has been greatly improved.
The new graphical interface is very intuitive and a breeze to learn. We
have been using BCView for the last few months and have been part of its
beta program.
Overall, we have been successful in using a behavioral methodology with
BC. I hope I have not sounded too much like a cheerleader - we've had some
frustrating issues with BC but we've been able to resolve most of them by
working with Synopsys.
- Hesham El-Adly
CAE Electronics Ltd, Quebec
( ESNUG 265 Item 6 ) -------------------------------------------- [9/97]
From: Michael Gartlan <michaelg@sv.sc.philips.com>
Subject: Is There A Way To Highlight Cells In Design_Analyzer From Scripts?
Hi John,
Presented with a list of cell names, how can you highlight the objects in
the schematic of design_analyzer FROM the command window? Using the
Edit-Select menu item on each element of the list followed by a Ctrl+E to
highlight all those selected is not an option due to the time involved of
filling out the Name field in the Edit-Select menu for each element in the
list. There does not appear to be a command for the command window such as
highlight find(cell, cell_name1) or highlight cell_name_list
If such a command existed then it would be very easy to write a script
to process a cell list. A compromise would be the ability to select the
objects in the schematic of design_analyzer via a command such as
"select cell_name_list" and then perform a Ctrl+E.
It seems to me that this link between the command window and the schematic
graphics is missing. Has anybody out there got a neat solution to this?
- Michael Gartlan
Silicon & Software Systems
( ESNUG 265 Networking Section ) -------------------------------- [9/97]
San Jose, CA - start-up Advancel Logic seeks ASIC Engineer(s) with 2+ years
exp. w/ Verilog & Synopsys. No Headhunters/agencies. "srini@advancel.com"
|
|
