[ Editor's Note: Although I may disagree with Don on *many* points here,
my personal values require that I publish his letter entirely. - John ]
From: Donald Rasbridge <rasbridg@ctron.com>
John, I appreciate your work on ESNUG. However, I don't appreciate your
promotion of immorality - I subscribe to ESNUG for professional concerns.
I read ESNUG 265 about wakes and strip bars. I have noticed a trend in
your writings in the last 2 years. Contrary to popular belief, not every
man in America is focused on beer, lust, and sports. I (and many others)
stand for the Truth. We are not conservatives, not republicans, not
"religious" people. We are Christians. We stand on the Rock -- Jesus
Christ. He is the standard for our values.
You have mentioned several times about "personal growth" seminars. I pray
that you're seeking God in this growth & not seeking personal satisfaction.
You will never find lasting peace and joy in anything other than Jesus
Christ. If you would like to know more about where I stand on certain
moral issues, or what I rely on for a standard, please write me. I don't
claim to have all the answers. I do claim to know God, who does have all
the answers and is constantly offering them to us.
If you would like to discuss moral issues or influence people with your
values, I humbly request that you would not mis-use ESNUG for that purpose.
There are so many other vehicles you can use. Thank you for understanding.
- Don Rasbridge
Cabletron
( ESNUG 266 Item 1 ) -------------------------------------------- [9/97]
Subject: ( ESNUG 265 #6 ) Highlight Cells In Design_Analyzer From Scripts
> Presented with a list of cell names, how can you highlight the objects in
> the schematic of design_analyzer FROM the command window? ... 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. ... 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?
From: Brian Arnold <bka@hpesbka.fc.hp.com>
John,
Here is a script I wrote a while back that answers this question.
if (find (port endpoint)) {
foreach (source, find("pin","*/CK")){
highlight_path -from source -no_auto_cycle endpoint
}
foreach (source, find("port")){
highlight_path -from source -no_auto_cycle endpoint
}
} else {
echo "please define endpoint as an output port on this design"
}
Change the structure as applicable as the command he is after is
highlight_path -no_auto_cycle. For example, one can specify an input pin
and an output pin for the same cell and that cell will be highlighted.
- Brian Arnold
Hewlett Packard, ETL
---- ---- ---- ---- ---- ---- ----
From: rnair@BayNetworks.COM (Rajesh Nair)
John,
This ain't so neat but seems to do the job (it worked OK for some simple
cases that I tried).
cell_name = "U216" /* Enter cell name here */
pin_names = cell_name + "/*" /* denotes all pins of cell */
filter find(pin, pin_names)"@pin_direction == in" /* find input pins */
input_pins = dc_shell_status
filter find(pin, pin_names)"@pin_direction == out" /* find output pins */
output_pin = dc_shell_status
highlight_path -from input_pins output_pin /* highlight path from
i/p to o/p */
The idea here is to use the highlight_path command in DC and use it to
highlight the path from the input to the output of the desired cell. This
makes DC highlight the cell for you.
- Rajesh Nair
Bay Networks
( ESNUG 266 Item 2 ) -------------------------------------------- [9/97]
From: Peter Kamphuis <peter.kamphuis@hl.siemens.de>
Subject: Changing Designer's Minds About Using BC With COSSAP
John,
I've been dealing with Behavioral Compiler since the beginning of last
year. In our CAD/support department we are aware that there is or will be
a need for behavioral synthesis and related methods: design complexity
keeps increasing and design time must decrease. We've done an evaluation
on an existing design (reimplemented that) and the results were ok (it
took quite some efforts at that time), but not in a manner that we really
could convince the designers in changing their design methodology.
Currently we're setting up a new project (again a reimplementation) where
we hope to see a real improvement in our design flow: Cossap (which is
widely used here) will generate behavioral VHDL from the algorithmic
design implementation. Behavioral Compiler will "do the rest". There is
no need anymore to reimplement the Cossap design on RT-level. As a second
step we will see how Behavioral Compiler has improved since the latest
versions. The designers in this project are willing to change to an
improved design methodology.
Still I think designers need their time to switch to new methodologies.
Some years ago it was similar as they changed from schematic entry to RTL
(V)HDL design.
- Peter Kamphuis
Siemens Semiconductors, Munich
( ESNUG 266 Item 3 ) -------------------------------------------- [9/97]
Subject: (ESNUG 264 #7 265 #4) Efficient/Cheaper Use of Synopsys licenses
> 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?
From: Vickie Moore <moore@minim.sps.mot.com>
John,
This may be helpful:
hdl_keep_licenses = "false"
When this variable is false, hdl licenses are released during execution of
compile, after compile has completed the subtasks that require the license.
- Vickie M. Moore
Motorola
---- ---- ---- ---- ---- ---- ----
From: [ Someone Inside Bill & Dave's Old Company ]
John,
Before you spend too much money on HDL licenses look at the man page for
'hdl_keep_licenses' (defaults to true). We have been using about a 2:1
ratio of Design-Compiler to HDL licenses without any issues. Our scripts
do the following:
Wait for an HDL license.
Read in HDL
Give up HDL license
Compile
If the compile grabs another license the 'hdl_keep_licenses = false'
will ensure that it is released as soon as possible.
Please keep me anon.
- [ Someone Inside Bill & Dave's Old Company ]
---- ---- ---- ---- ---- ---- ----
From: Victor_Duvanenko@truevision.com (Victor Duvanenko)
John,
This is in reply to using fewer (V)HDL readers than Synthesis licenses.
I've been runing in this mode for the last 5 years (since Synopsys 1.5)
and have complained about Synopsys not being frugal with licenses, which is
the mode that they test under, but is not the usage mode of the (smaller)
customers. Before DesignWare, writing scripts to wait for (V)HDL reader
and then reading in your source code, and then removing (V)HDL reader
license used to work perfectly fine. Then when DesignWare came out,
Synopsys needs to check out the (V)HDL reader to synthesize some of the
parts (which are written in a technology independent way - i.e. some using
(V)HDL source). At that point (which is after the "compile" command), the
(V)HDL reader is grabbed and then is never released. The "compile" command
gets done with DesignWare and then goes on to the optimization stage, but
does not release the (V)HDL reader. Thus, removing license after you read
in your (V)HDL source may not be enough, since the first time that Synopsys
needs to make you a 28-bit incrementer it may need a (V)HDL reader, but in
the subsequent runs it may not. This introduced enough uncertainty into
the license scheme to cause some customers to complain a lot (those with
little $$'s) and some to buy more (V)HDL readers (those with more $$'s).
With all this "history" summarized, is there anything an engineer can do?
Yes, in the 1997.08 release there is a new variable "hdl_keep_licenses"
that you can add to your .synopsys_dc.setup. By default, for backward
compatibility reasons, it is set to true. So, you should set it to
"hdl_keep_licenses=false", and magically the (V)HDL reader will be given up
after DesignWare is done. Synopsys documentation has a mistake in it, they
refer to "hdl_keep_license" -- this is wrong. You'll need the plural form
of "licenses", or it won't work (this took me some time to discover).
Synopsys has also added a very nice feature that allows you to invoke the
dc_shell along with the required licenses right off the bat. The
combination of these two features allow the designers to get the dc_shell
with the needed licenses and then give up the (V)HDL reader right before
the mapping stage of the compile.
It is very nice to see a vendor respond to the cries of the users, even if
it does take a few years.
There is a snag, however - if you want to use "compile -scan" then a "Test
Compiler" license is checked out and is kept during the entire optimization
stage. And, I have not found a "test_keep_license=false" variable - and
I've tried.
- Victor J. Duvanenko
Truevision
( ESNUG 266 Item 4 ) -------------------------------------------- [9/97]
Subject: ( ESNUG 264 #1 265 #2 ) 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: walker@cs.tamu.edu (Duncan M. "Hank" Walker)
John,
The problem is even worse than described. This topic was discussed at
the VLSI Test Symposium in the context of how do you make cores testable in
their embedded environment, without giving too much information to the
user. There was one paper from LSI on trying to do this for full scan
designs, and scanning from 0 to 100% of the core I/Os. A bunch of IBM
people in the audience said that they had studied this, and found that if
your design was full scan, it was straightforward to reverse engineer the
logic, so you had no gate-level IP protection. At best you had protection
for the higher-level meaning of the core algorithms, RTL, etc. But
documentation may help the user figure them out too.
It sounds like you are more concerned about having the user synthesize to
gates, and then tech map to a non-TI cell library. As you mentioned, this
is fundamental unless the synthesis procedure uses some sort of encryption
to prevent the IP from being synthesized to a non-matching library. But is
this the real issue? It would seem to me this is only the case for
commodity-type library elements. I thought the whole point of TI's shift
to being an IP provider was that their value added was complex cores such
as DSPs, DRAM, etc., that are not easily replicated. I have a hard time
believing many people will be able to take a TI DRAM macro and fab it at
another vendor reliably.
After spending the summer working on gigahertz microprocessor issues, I
guess I believe that a high-performance, library-independent, soft macro is
an oxymoron. This will work for toaster ovens and slow, low power things.
But anything fast must have its physical design tuned to a specific process.
And can't this whole "fab only with us" thing be taken care of by a license
agreement?
- Duncan M. (Hank) Walker
Texas A&M University
---- ---- ---- ---- ---- ---- ----
From: krag@lsil.com (Kevin R. Grotjohn)
John,
Here is an idea for solving ASIC vendors "soft" IP being reused with other
ASIC vendors as a target: As most IP is in ASCII form - EDA vendors need to
support standard key based encryption for reading/writing ASCII files. The
technology name that the tool is using must match that encrypted into the
key. The use of the keys themselves would be licensed using standard unix
license keys. The ASIC vendor would the license use of the IP for a given
technology and timeframe using the combination of keys.
- Kevin R. Grotjohn
LSI Logic
( ESNUG 266 Item 5 ) -------------------------------------------- [9/97]
Subject: (ESNUG 262 #4 263 #1 264 #2) *WHO* Is Using Behavioral Compiler?
> I waited 3 years. I was starting a new project and brought BC in again.
> It seemed to have matured a bit and the AE's were competent. They
> also had an example design similar to my architecture. The deal was
> that I would go to a BC training class (which I did). Then I would write
> the behavioral code and testbench (which I did). They would "BC" it and
> give me back an RTL model and gate netlist which passed the testbench. At
> that point I'd be obligated to purchase the tool (as long as there were
> no surprises). Everyone agreed this was a perfect target design for BC.
>
> For 6 months they worked on the design. They said over-and-over that they
> almost had the RTL working. I finally ended it. Again they were
> surprised. I never received a report or explanation for the poor results.
From: samng@corp.cirrus.com (Sam Ng)
Dear John,
I have use BC on and off for approximately 1 year mainly on 3D graphics
accelerator designs. The design I have used BC on is a triangle setup
/geometry processing engine of ~40K gates in size at running at 100MHz.
The goal for the design was to find the shortest schedule for performing all
the operations in setting up a triangle for rasterisation on the smallest
number of arithmetic units. BC, in this respect, is very useful since the
turn-around time for behavioural code change to reschedule is quite short
(10-15min) which allowed me to experiment with different latencies and
throughputs for the arithmetic units.
BC has done largely what I want but there are a few things to improve on
eg. unable to share memory between process (there is a tedious work-around),
unable to perform scheduling for a pre-existing architceture and lengthening
of schedule whenever conditional statements are encountered.
- Sam Ng
Cirrus
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
[ Editor's Note: What follows is an exchange of specific e-mails on BC
between Dwayne Bennet, Steve Molloy, and Arthur Marris. - John ]
From: Dwayne Bennett <Dwayne.Bennett@Matrox.COM>
> My experience with BRT was very positive. I had a circuit which needed an
> extra stage, but adding this extra stage would have seriously affected
> performance of the circuit and this could not be tolerated (the chip was
> for a giga-bit Fibre Channel Switch and operated at 53Mhz.) The solution
> was to better make use of the stages I had by optimally placing them along
> the critical path. Unfortunately this path involved indexing into arrays
> and so changing the placement of stages in verilog RTL would have been a
> mess and would have been time-consuming. This is when I turned to BC.
> The change to the synthesis script was trivial; I just added the command
> "optimize_registers" and let it run. It resolved the problem and the
> circuit was able to meet our timing goals. The cost in gates was minimal.
>
> - Dwayne.Bennett
> Matrox
From: molloy@ix.netcom.com ( Steve Molloy )
To: Dwayne Bennett <dbennett@matrox.com>
Dwayne,
Couldn't you have just used the balance_registers command of design compiler
to get the same effect? This shifts around the existing registers in a
design to balance the delay between registers.
Just wondering,
- Steve Molloy
---- ---- ---- ---- ---- ---- ----
From: Dwayne Bennett <dbennett@matrox.com>
To: molloy@ix.netcom.com ( Steve Molloy )
Agreed, Steve,
The two commands are similar but optimize_registers considers area in
determining placement of stages.
- Dwayne.Bennett
Matrox
---- ---- ---- ---- ---- ---- ----
From: Dwayne Bennett <Dwayne.Bennett@Matrox.COM>
> I might add that a change to the verilog not only would have taken up my
> time, but also would have forced a slew of regression simulations to have
> to be re-run. I think it is clear that BC/BRT saved me significant time
> and effort.
>
> - Dwayne.Bennett
> Matrox
From: Arthur.Marris@tiuk.ti.com ( Arthur Marris )
To: Dwayne.Bennett@matrox.com ( Dwayne Bennett )
Dwayne,
Interesting comments you made. Didn't you have to run a slew of regression
simulations on you gate level model after running BRT? Or do you assume
that what you get out of Synopsys is correct by construction and not bother
doing exhaustive simulations of your gate-level netlist?
- Arthur Marris
Texas Instruments
---- ---- ---- ---- ---- ---- ----
From: Dwayne Bennett <dbennett@matrox.com>
To: 'Arthur.Marris@tiuk.ti.com'
Hi Arthur,
Yes, chip-based gate-level sims were run following synthesis, but a long
set of system-level source-code simulations were not necessary to repeat
since the source code was not actually changed.
- Dwayne.Bennett
Matrox
( ESNUG 266 Item 6 ) -------------------------------------------- [9/97]
From: "J.H.Wu" <dragonwu@faraday.com.tw>
Subject: Characterization Of Combinational Logic for Design-Power
Hi John,
Characterization for Design-Power seems a little bit troublesome for me
since I need to cut each power source (VCC) for each stage in cells. I
hate to do this since I can't find a good way out to cut power for all
the cells in all the libraries I have.
My question is: how do you characterize power for combinational logic
cells for Design-Power (for example, a 2:4 decoder)? Do you group the
last two stages power to establish the output pin look-up table for
Design-power?
- Jeng-huang Wu
Faraday Technology Corp., Taiwan
( ESNUG 266 Item 7 ) -------------------------------------------- [9/97]
From: alfieri@nano.asd.sgi.com (Bob Alfieri)
Subject: How Do You Disable "Max Fanout" Warnings Just On Clocks?
John,
How do you disable max-fanout-exceeded warnings on clocks that show up in
report files? We care about these warnings only for non-clock signals.
We've tried a number of things without success. Thanks.
- Bob Alfieri
SGI
( ESNUG 266 Item 8 ) -------------------------------------------- [9/97]
From: Jonathan Mayer <jmayer@crystal.cirrus.com>
Subject: Tri-state Buses, Wired Muxes, And A DesignWare Part
John, going through some old ESNUGs, I've been following the tristate-bus
vs. wired mux bus debate closely. Since this issue is causing so much
trouble, wouldn't it be nice to have a magic designware component that
simply is the bus? The idea would be to have a component that designware
and synopsys would dynamically change between tristate and wired
implementations as the number of devices on the bus and the design
constraints shift.
Or is the issue too route-dependant?
And... who wants to write one? :)
- Jonathan Mayer
Cirrus
( ESNUG 266 Networking Section ) -------------------------------- [9/97]
Andover, MA - Pixel Magic - ASIC Enginners needed with 2+ years IC design,
image proc/codin, sim, synth exp. No headhunters. schipani@pixelmagic.com
|
|
