> Since I am not a 'registered' Synopsys user, I can't get at the papers.
> Would you be so kind as to email them to me or let me know how I go
> about acquiring them?
>
> (MA2) Tutorial of FPGA Compiler II
> (MC3) Large FPGAs, FPGA Express
> "FPGA Express Coding Techniques" by David Nye of Xilinx.
>
> Regards,
>
> - Austin Franklin
> Darkroom
From: "Roberta Fulton" <Roberta.Fulton@xilinx.com>
Hi John,
I was looking up the company Darkroom because I had not heard of it
before so I could send Austin Franklin a copy of the paper, "FPGA Express
Coding Techniques" by David Dye of Xilinx. (That's Dye by the way as in
dye your clothes, not Nye as in "the science guy").
Well any ways, my company's firewall won't let me near it! It thinks
www.darkroom.com is a porn site.
Do you know anything about Darkroom and do they have another web site
other than the obvious one I tried? I won't even go into what I found
with a search on "darkroom.com".
- Roberta Fulton
Xilinx, Inc.
( ESNUG 319 Subjects ) ------------------------------------------- [5/99]
Item 1: No, We Actually Think Behavioral Compiler *Is* The Way To Go
Item 2: Why Are There Odd Question Marks In My Synthesis Log Files ???
Item 3: Customer Problems Accessing Intermediate Bits In Module Compiler
Item 4: Extremely Wild Lucent ORCA Timing Estimates W/ FPGA Compiler 98.02
Item 5: Current Cadence/Synopsys/Avant! Techniques For Verilog Encryption
Item 6: Modelsim & VSS Having VITAL (VHDL) SDF Lib Conflicts W/ DC 99.05
Item 7: How Can I Reduce My Number Of Test Vectors Using The Sunrise Tool?
Item 8: The Revolting Way Avant!/InterHDL Now Sells Its Verilint Tool
Item 9: Are There No Waveform Viewers For DSP & Ram Intensive Designs?
Item 10: ( ESNUG 318 #6 ) IBM Supports PrimeTime, Just Not For Sign-off
Item 11: ( ESNUG 318 #3 ) Reactions To "We Will Consider Using PGP"
Item 12: ( ESNUG 318 #10 ) Want DC To Remove Tied-off/'Dead' Flip-flops
Item 13: ( ESNUG 318 #6 ) Cooley And Collett Live In Different Worlds
Item 14: Help! 'Error: The Package 'STD_LOGIC_UNSIGNED' Is Out Of Date' !
Item 15: ( ESNUG 318 #3 ) Converting SPICE Libs Into Synopsys Power Libs
Item 16: Which Of These Power Books Are Useful? Which Are A Waste Of Time?
( ESNUG 319 Item 1 ) --------------------------------------------- [5/99]
Subject: No, We Actually Think Behavioral Compiler *Is* The Way To Go
> The Big Shiney Plastic Prize one was supposed to get for opening the
> Behavioral Compiler breakfast cereal box was BOA and BRT; two very nice
> come-ons, but not worth the hassles & headaches of BC/DW. So, like
> hiding the idiot uncle in the basement when guests visit, Synopsys has
> wisely de-emphasized BC, moved BOA/BRT into DC-Ultra, and you now see
> there are 18 Module Compiler classes for every 6 BC classes given
> at Synopsys Corporate.
From: david_johnson@paging.mot.com (David Johnson)
John,
I'd like to respond to the commentary in the SNUG'99 Trip Report on BC.
There is much more to Behavioral Compiler (BC) than just Behavioral
Optimization of Arithmetic (BOA) and Behavioral Retiming (BRT).
Fundamentally, BC allows the systems/hardware designer to think and
write code algorithmically and still get efficient implementations.
I've known several designers that made up their mind that they did not want
to use BC without ever even seeing any presentations on BC. To these
designers that are used to being handed a micro-architectural spec, BC
is a mysterious, black-magic proposition. The paper I presented at
DesignCon98 "Design Automation of a Receiver: Breaking the RTL Cycle Time
Barrier Using Behavioral Compiler" was intended to explain the basic
concepts of architectural synthesis in a very intuitive way. The proof
is in the working silicon and the fact that all new blocks within our
group are designed using BC. One experienced ASIC designer I know
didn't see any value in BC until one of his RTL blocks was re-written
algorithmically for BC and BC did a more efficient job of resource sharing
fully automatically than the original manual RTL. A new designer in the
group took to BC like a fish to water -- he had a good systems background
and he had no prior experience designing ASICs in RTL, hence no
prejudices against BC. One reason for the quick learning curve for the
new designer with BC was that he was presented with a complete end-to-end
flow, not just the BC point solution, and he was provided with existing
design examples in BC for our type of applications. Any time he had
a question as he was ramping up, help was readily available.
It may take a while for designers to appreciate the new possibilities
available with BC, for example the reality and utility of quickly
being able to generate different architectures from the same code.
In order to take advantage of the latest R&D for one design, I needed
to change the number of cycles in a loop from 3 to 1, (lower latency,
more parallel resources) and incorporate loop-pipelining. I could
do this all with a few behavioral synthesis commands and no change
to the code. The new IC features would not even have been considered
without the proven quick-turnaround time using BC in the methodology.
Loop-pipelining is another concept mysterious to many experienced RTL
designers, but nevertheless yet another very powerful capability in BC,
and well worth the effort to learn the concept.
For combinational tasks/functions, user DesignWare has been virtually
eliminated in BC. Yes, DesignWare hoops are still needed in some cases
for sequential/pipelined tasks/parts. I don't want to have to deal with
DesignWare memories either -- that should completely be handled by the
ASIC vendor, but for now there is a new GUI BC MemWrap to make that
process very straightforward for memories (we've seen it in Beta).
I expect that over time, as the designers who invest in educating
themselves on how to use Behavioral Compiler experience first-hand the
significant productivity improvements available over designing manually
in RTL, the debate over Behavioral Synthesis will become moot. BC
expertise will become as necessary for ASIC designers to have on their
resume as DC RTL expertise has been.
- David Johnson
Motorola
( ESNUG 319 Item 2 ) --------------------------------------------- [5/99]
From: "T.P. Nguyen" <nguyen@natlab.research.philips.com>
Subject: Why Are There Odd Question Marks In My Synthesis Log Files ???
Hi John,
Could somebody help me to understand why I get sometime the question marks
for a certain register in my synthesis log file. A part of the log file
looks like this:
======================================================================
Register Name | Type | Width | Bus | MB | AR | AS | SR | SS | ST
======================================================================
cnt_reg | Flip-flop | 8 | Y | N | N | N | N | N | N
dac_buf_reg | Flip-flop | 1 | - | - | N | N | N | N | N
data_buf_reg | Flip-flop | 8 | Y | N | N | N | N | N | N
mod2cnt_reg | Flip-flop | 1 | - | - | N | N | N | N | N
sum_reg | Flip-flop | 8 | N | N | ? | ? | ? | ? | ?
======================================================================
The register bank sum_reg got the question mark for all parameters:
AR, AS, SR, SS, ST
Thanks for any help.
- T.P Nguyen
Philips Semi/ASG-Microtel Eindhoven, The Netherlands
( ESNUG 319 Item 3 ) --------------------------------------------- [5/99]
From: "Barry A. Williams" <bawillia@collins.rockwell.com>
Subject: Customer Problems Accessing Intermediate Bits In Module Compiler
John,
I have been given the task of evaluating Module Compiler. After cruising
along the learning curve quite well, I came to a roadblock. The ALU
datapath I was implementing as a test case included the use of intermediate
carry bits from the 32-bit adder. I have yet to find in the documentation
how one gets access to these bits or if it is even possible. Any help from
ESNUG would be appreciated.
- Barry Williams
Rockwell Avionics
( ESNUG 319 Item 4 ) --------------------------------------------- [5/99]
From: Robert_W_Smith@res.raytheon.com ( Robert Smith )
Subject: Extremely Wild Lucent ORCA Timing Estimates W/ FPGA Compiler 98.02
John,
I have a general FPGA question I would like to put to the ESNUG community.
We have been using FPGA Compiler 98.02 (not FPGA Express) to design mostly
Lucent ORCA 2C and 3C/T FPGAs. Our impression has been that the timing in
the provided Synopsys FPGA libraries is not too accurate, or at least
doesn't agree with the FPGA tools -- the Synopsys timing reports seem
to vary from wildly pessimistic to wildly optimistic compared to what we
get when we route. Consequently, we have been using Synopsys mainly as a
plain synthesis engine and doing our optimizations, pipelining, etc. from
the place and route results. Needless to say, we would love to optimize a
lot sooner in the process, as long as Synopsys can reflect the actual
results we can get when we route.
So what is the experience in ESNUGland? Are the Synopsys FPGA libraries
accurate enough to trust Synopsys' timing info? Should we be making better
use of Synopsys up front to reduce our FPGA place and route iterations? Do
other FPGA companies provide more accurate libraries than Lucent? Is FPGA
Express or the coming FPGA Compiler II better at this?
BTW, one trick we have been using is to examine the verbose timing report
for the mapped circuit, where all routing delays are set to zero. Not only
does this save having to run place and route, but it better highlights your
true logic bottlenecks. If the router tackles tough logic first, then the
paths which end up not meeting timing won't be the ones really causing your
problem.
- Bob Smith
Raytheon Systems Company Marlboro, MA
( ESNUG 319 Item 5 ) --------------------------------------------- [5/99]
Subject: Current Cadence/Synopsys/Avant! Techniques For Verilog Encryption
> I was wondering if anyone knew the status of source code protection/
> encryption for Verilog. I know Cadence and some others have this
> feature but that they were not cross-vendor compatible.
From: Lance Pickup <lpickup@xanadu.btv.ibm.com>
As far as I am aware, source code protection is available via the following
means (this list may not be complete):
1) Most (all?) Verilog vendors provide a source code encryption mechanism
based on use of `protect blocks and the +protect command line arguments.
I know that Cadence Verilog-XL, Chrono VCS and Avant! Polaris all have
this capability. It's quick and painless to protect your source this
way, involving a mere pass through the front-end parser and spitting out
platform independent "encrypted" code. It is also very inexpensive: the
Verilog simulators that support this allow you to use this feature for
free. The drawbacks are:
- There are exposures using these methods. The Verilog-XL encryption
has been cracked in the past. Apparently VCS has a possible security
hole that has been addressed. The moral here is that this is not
an extremely safe method!
- It is vendor-specific. So you would have to encrypt in whatever
simulator the person receiving your source is using. This may
invalidate my comment about cost above if you have to go out and
buy a simulator seat just to protect your models!
2) There are tools available which obfuscate the source -- transforming
module, component, net, port, etc. names into "undecodable" strings of
characters such as IO0Oo000II111iO in an attempt to mask the true nature
of the source. I'll leave it to you to assess the security of this
approach. Still, if you are certain you have non-malicious users and
your source is not incredibly sensitive, this may be a workable approach.
3) There is the VMC tool from Synopsys which compiles your Verilog (with the
VCS engine) into object code. Prior versions output a model with a PLI
interface that would work with any Verilog simulator. The latest version
puts a SWIFT interface on the model which can be used with most popular
simulators, allowing you to share your Verilog model with VHDL users
(without the need for co-sim licenses). The SWIFT interface does not
currently support cycle-based simulators. I am not sure how this relates
to the Synopsys CoreBuilder product.
4) Keep an eye on OMI (Open Model Interface). This is not a current
solution, but is one that is in the works. This is now an IEEE standard
(1499) API for simulators. Cadence and a few other vendors have said
that their simulators will be OMI compliant by year end and Cadence
plans to offer a "packager" utility which will package up models
presumably compiled with one of their simulators). I believe the
packager will come with the simulator and allow you to package models for
free to be used with Cadence simulators. If your models need to be used
with other vendors' simulators, there will be a cost associated.
It is said that OMI will have the capability to support cycle simulators.
- Lance Pickup
IBM Microelectronics Burlington, VT
( ESNUG 319 Item 6 ) --------------------------------------------- [5/99]
Subject: Modelsim & VSS Having VITAL (VHDL) SDF Lib Conflicts W/ DC 99.05
> I'm trying to do a post-synthesis simulation with Modelsim EE 5.2, using
> the VITAL lib of my ASIC vendor. I keep getting errors that some instances
> do not have one or two generics (e.g.: tpd_c_q_posedge). (I do not have
> errors of missing instances...) I don't think there is any error on the
> top instance I apply the SDF file, nor similar things... However, I don't
> know if I produce wrongly the SDF/VHDL files from Synopsys DC 99.05 (I use
> the SDF v2.1 format). Is there any chance that the vendor ASIC VITAL
> models are not 100% VITAL compatible, as said in the Modelsim user manual?
From: alex_schreiber@my-dejanews.com
The story has two sides. For an ASIC library used inside DC, a Synopsys
model needs to be described (.lib) which is compiled into a binary format
(.db) by Library Compiler (lc) of Synopsys. Usually the ASIC vendor is
already providing the .db format, so you as customer do not need to have
the lc license and do not need to compile it yourself.
In this Synopsys model below there is a delay defined from the rising edge
of 'c' to the output 'o' (for tpd_c_q_posedge). It looks like follows in
the .lib model (often not delivered by the ASIC vendor):
pin(q) {
:
timing() {
timing_type : rising_edge;
timing_sense : "non_unate";
intrinsic_rise : 2.00;
intrinsic_fall : 2.00;
rise_resistance : 0.20;
fall_resistance : 0.20;
related_pin : "c";
}
}
Based on this model the delay calculator in Synopsys DC is generating the
SDF file. In your case you will find there an entry like
IOPATH (posedge c) q (2.00:2.00:2.00)
The second part are the VITAL models of your standard cell library. To be
able to backannotate the values estimated by Synopsys delay calculator, the
VITAL timing generics need to meet certain requirements. Only then the SDF
backannotator in the Simulator (like ModelSim) can map the SDF entry with
the VITAL generic correctly. In the assumed SDF entry given above the
generic needs to be like follows:
tpd_c_q_posedge
If you have the VHDL/VITAL source code of your standard cell lib (usually
delivered by the ASIC vendor) you can check the defined timing generics of
the cell which makes trouble. I guess, you will find either no definition
or something like
tpd_c_q
The missing edge specifyer is enough to let the SDF backannotator failing.
- Alex Schreiber
---- ---- ---- ---- ---- ---- ----
From: Alan Fitch <alan@doulos.com>
I've seen this problem twice at two different customers when we were running
the Design Flow exercise in our Comprehensive VHDL training course.
The customers both told me that it was a problem with Synopsys writing
out SDF. However I have no proof of this.
Unfortunately as I was on customer sites, I could not take away the log
files. I cannot reproduce the problem back in the office, as we haven't
got VITAL compliant ASIC libraries, so I haven't reported it to Synopsys.
Both the customers had other routes to create SDF files which were then
compatible with Modelsim, which is why I suspect Synopsys. However I
must stress that I have no proof of this, and it is certainly possible
that the respective ASIC libraries were in error.
- Alan Fitch
DOULOS Hampshire, UK
P.S. If anyone knows of a VITAL compliant ASIC library that we could use
on our public training courses, we should be eternally grateful!
---- ---- ---- ---- ---- ---- ----
From: Laurens Drost <drost@synopsys.com>
Alan,
The constructs used to write out SDF depend somewhat on the actual
technology library you use, and might depend on the version of our software.
The SDF we write out is 2.1 compliant, but VITAL level 0 (perhaps 1 as well)
has not necessarily a one on one relationship with the SDF. Your VITAL lib
might not fully support SDF v2.1.
- Laurens Drost
Synopsys (Northern Europe) Ltd. Reading, UK
---- ---- ---- ---- ---- ---- ----
From: Kyungjin Jang <sandrose@phoenix.dwe.co.kr>
I confronted similar problem. I used Synopsys's DesignPower to estimate of
power of the chip. When I compiled the VITAL internal memory libary of STM
by VSS, such as lines made errors.
==> VITAL Entity 'FIFO_94X16' has VITAL conformance error(s):
TPD_OE_Q : VitalDealyArrayType01z(7 downto 0) := (others =>
^
**Error: vhdlan,2148 FIFO_94x16_ent.vhd(20):
The type of a scalar timing generic parameter 'TPD_OE_Q' does not
match the type of the associated ports.
Other man who compiled by Cadence Leapfrog said he didn't have such error.
I could escape the error by changing the name TPD_CK_Q => aTPD_CK_Q. I
don't kwow why such error, but after changing it compiled well. Maybe the
name was a reserved word of VSS? So, in my opinion, you may avoid error by
changing names... Is there a person who knows the reason of my case?
- Kyungjin Jang
Daewoo Electronics Korea
---- ---- ---- ---- ---- ---- ----
From: alex_schreiber@my-dejanews.com
Kyungjin,
I guess, that something in your FIFO model is not correct. In the VITAL
standard the width of the type is defined like follows (types as example):
Case 1: at least one port is bus
--------------------------------
tpd_<Input_Port>_<Output_Port> : VitalDelayArrayType01Z(0 to
((width_Input * width_Output)-1))
Case 2: both ports are pins
---------------------------
tpd_<Input_Port>_<Output_Port> : VitalDelayType01Z(0 to
(width_Output-1))
Please check in your FIFO model if the ports (in the entity) are defined
correctly:
OE : std_logic
Q : std_logic_vector(7 downto 0)
By changing the name
TPD_OE_Q => aTPD_OE_Q
you excluded the generic (it's no more a VITAL generic) from the conformance
check of the VHDL compiler. Because of this you do not get any error
anymore. BUT you excluded it from backannotation as well. When you try
to read in a SDF file, you will get an error of missing generic as well.
- Alex Schreiber
( ESNUG 319 Item 7 ) --------------------------------------------- [5/99]
From: Micha Ophir <micha@zoran.co.il>
Subject: How Can I Reduce My Number Of Test Vectors Using The Sunrise Tool?
I am trying to improve the coverage I get using SUNRISE. I have a given
amount of space and therefore must not exceed 1500 vectors.
(1) The -reverse option is mentioned in the manual, but it is not clear
from it whether it can reduce the number of vectors needed in every
case. Could you please explain when it is most effective.
(2) What is the largest number of vectors that can be given to the
-compactbuf option? In the manual they give an example of 300, if
this is exceeded does it take a lower default number ?
(3) What is the optimization verses time penalty in using :
(a) -staticcompact
(b) -genetic
(c) both of the above together
(4) Is there anything else that can be done inorder to improve coverage
without increasing greatly the number of vectors ?
Some of the flags I spoke about (compactbuff etc) use a lot of memory. What
would be best in order to stay within 1 to 1.5 GB res memory and below ~2 GB
swap file ? (I tried a compactbuf of 300 and it seems to be very memory
hungry).
- Micha Ophir
Zoran Israel
( ESNUG 319 Item 8 ) --------------------------------------------- [5/99]
From: [ I Am Sparticus ]
Subject: The Revolting Way Avant!/InterHDL Now Sells Its Verilint Tool
Hi John,
Years ago I was a beta site customer for InterHDL's Verilint tool. It
wasn't a very good tool in those days but it showed promise and I sent in a
bunch of test cases of things it failed on and things it should have found.
If you called InterHDL in those days, you got Eli Sternheim personally.
Eventually the tool was released and we bought a copy. It didn't use
Flexlm which was a pain, but it wasn't a big deal.
Somewhere in there InterHDL figured out each customer only needed one copy
because the tool is just a syntax checker and ran pretty fast. To help
their sales they put in a 27 minute timer that allowed access to only one
user for that time. This was the first way they screwed their customers.
We only bought one anyway - so there!
Now Avant! has purchased InterHDL & sent a fax to all the Verilint customers
offering to "upgrade" the license to flexlm and remove the 27 minute timer
-- all for only $10K and $7K in annual maintenance. This for a tool that
originaly cost less than $10K. That's screw number 2. If you want to buy
the tool new from Avant! the list is $47K!!! Screw 3. Sheesh, that's more
than a verilog license. Who are they kidding? This thing is a SYNTAX
checker.
By the way: if you decide not to upgrade, they'll give you a permanent key
for the old tool - forever locked to the machine you specify -- they'll
never allow a future rehost! Screw 4.
What a way to run a business.
No name please - I haven't got my final permanent key yet.
- [ I Am Sparticus ]
( ESNUG 319 Item 9 ) --------------------------------------------- [5/99]
From: "Jim Avant" <javant@homewireless.com>
Subject: Are There No Waveform Viewers For DSP & Ram Intensive Designs?
John,
We've been auditioning simulators and stand-alone waveform viewers and
I've identified a couple of common holes in the feature lists. I thought
that maybe some of your subscribers may be able to help. Or at least let
me know if I'm the only one who cares.
I do a lot of DSP verilog code development and I'd like to be able to
right click on a signal and format the signal as analog AND as 2's
complement. Furthermore I'd like to be able to scale and offset the
resulting waveform as well as control the height of the field allocated
for its display. I'd also like to be able to independently change the
color of this signal.
I've found several waveform viewers that each do part of this (ModelSim
comes closest but doesn't understand sign-magnitude vs. 2's complement).
Of course the work-around is to create code in your testbench which
dredges up signals buried in the hierarchy and reformat the signals for
display (this is not even possible with some waveform viewers).
The other thing I want to do but haven't found anything close is to view
the contents of a RAM at the time selected by the cursor in the waveform
display window. This should be a separate display window with a column
for address on the left side and data laid out to the right. A new row
should start every 8 data items but if you stretch the window wide enough,
it should change to every 16 data items. Of course there should be
features in this view such as scroll bars and the ability to search for a
pattern. There are ample examples of how this should work in logic
analyzers, device programmers, etc.
I realize that this could be very compute/time intensive especially for
large memories. But in DSP designs, you often have lots of small memories
or register files to keep track of. I'd like to be able to open several
"memory monitor" windows and see the contents change as simulation time
progresses (or turn off updating to speed up the simulation).
I know I can write a PLI to do some if not all of this but it seems to me
that this is a feature that should be incorporated into the waveform
viewer and that many designers could make use of this.
Am I the only one who's asking for these features? Are there any
relatively painless work-arounds that anyone has found?
- Jim Avant
Home Wireless Networks
( ESNUG 319 Item 10 ) -------------------------------------------- [5/99]
Subject: ( ESNUG 318 #6 ) IBM Supports PrimeTime, Just Not For Sign-off
> [ Editor's Note: Karla, doing a web search, I found press releases from
> each of those companies endorsing PrimeTime except IBM. For IBM, at
> http://www.chips.ibm.com/products/asics/methodology/design_flow.html
> clearly has PrimeTime being supported by IBM. My appologies if this
> data is wrong; I assumed IBM's own web site was accurate. - John ]
From: reynoldk@us.ibm.com (Karla Reynolds)
John,
IBM's web states that either Einstimer or PrimeTime can be used for static
timing analysis. This is true. However, we make a distinction between
sign-off and analysis. For example, Design Compiler, does timing analysis
as do many other tools. However, not all are qualified for sign-off by
ASIC vendors. If you go down to the footnote at the bottom of the web page,
it says that Einstimer is required for release-to-layout sign-off. While
you can argue that our WEB page doesn't make the distinction clear enough,
I think I can safely say that both the WEB page and my original statement
are correct.
- Karla Reynolds
Mgr. Timing and Synthesis Department
IBM Microelectronics Essex Junction, Vermont
( ESNUG 319 Item 11 ) -------------------------------------------- [5/99]
Subject: ( ESNUG 318 #3 ) Reactions To "We Will Consider Using PGP"
> Regarding Mr. Brier's observations on encryption for IP -- his comments
> are interesting and worth investigation, but are, in fact, based on
> misinformation about our tools. To set the record straight, encryption of
> a coreKit and the files that coreConsultant produces (e.g., RTL) is
> **strictly optional**. It's done only if the **provider** of the core
> chooses this option when using coreBuilder to create the coreKit. We put
> this feature into the product based on consistent customer demand.
> Specifically, core designers want to preserve the black-box nature of the
> reusable core; hence, they want to keep core end-users from modifying the
> source. In addition, they asked for a level of *basic* (lightweight)
> protection of their RTL to "keep honest people honest," and to satisfy
> legal IP protection requirements. Synopsys core competency isn't
> encryption, so we welcome Mr. Brier's suggestions that we (and the EDA
> industry) consider PGP (or perhaps other industrial encryption like RSA).
>
> - [ John Chilton, VP/GM Design Reuse at Synopsys ]
From: "John Allen" <jallen@vhfcom.com>
John,
PGP is the most underused technology of the late 20th century. Very sad.
It deserves great success. Even Intel supports PGP, but most people are
clueless about it.
- John Allen
IronBridge Networks Lexington, MA
---- ---- ---- ---- ---- ---- ----
From: Dave Brier <dbrier@ti.com>
John:
Interesting remarks by Mr. Chilton, my impression from the original posting
was that encryption was a big part of the feature set of their coreBuilder
tool set. He also states that many of their customers have asked for some
sort of light encryption to be available to keep the honest honest. That's
nobel and I applaud their listening to their customers that way. The only
problem that I have with the way that they listen is that they (and not just
Synopsys, but the entire EDA industry) approach the problem in a self
centered manner.
The challenge as I see it is to deliver models in a uniform manner to
customers that use VSS, Modeltech, Verilog, VCS,... in one standard format.
I'm sure that Mr. Chiltons customers use other simulators and would really
appreciate some method to enable those technologies. I grow weary attempting
to remember all of the different formats, peculiarities, etc. that accompany
the various tools that are on the market at this time. We have so many
languages to know in order to get our designs done it would be nice for
once that the industry would gather in one room and cooperate on a uniform
solution to a problem. That is my dig on this situation, it's not a shot at
Synopsys per se, they are behaving in the manner that they must to survive
and grow. It would be nice if that growth could come in a manner in which
uniformity would prosper.
Once upon a time when VHDL was in it's infancy I had a conversation with a
number of companies, Synopsys, and Vantage (remember them?) were in that
crowd. My group (not at TI) stated that if VHDL were to prosper, then the
simulators would need to be more of a commodity item basically meaning that
the value added was in performance not coverage of the language or
"trueness" to the LRM. They all should produce the same simulation results
for the same input. If the EDA companies want to do something great for
the IP providers of the world, if they want to be smiled upon then they
could drive to uniformity of interface an interpretation of the commands and
languages that they use. I don't hesitate to say that many IP providers
spend a considerable amount of time and money in making their models correct
across multiple EDA platforms. It's sort of like the U.S. mixing all the
different power outlets and power formats that you find when you travel
overseas. Imagine what that would do to our economy.
- Dave Brier
Texas Instruments Dallas, TX
---- ---- ---- ---- ---- ---- ----
From: Steven Sharp <sharp@Cadence.COM>
John,
It doesn't matter what encryption algorithm is chosen, it doesn't solve
the problem. The problem is, who gets the key?
Every tool that accepts this encrypted code has to be able to decrypt it.
That requires the key. You can't put the key into some published standard,
because then anyone could decrypt and steal the code. IP vendors can't give
their key to their licensed users, because if the user could be trusted, the
encryption wouldn't have been needed. That means that the key has to be
embedded in the tools. Now the question becomes, which tool vendors do
we trust with this key? Since it is a standard, should we give it to any
vendor who wants it? What about a vendor whose product is a code decrypter
to let people steal IP, or is just a front for a company stealing IP? We
could restrict the key to some small set of "reputable" vendors. Then
any others will have to come up with their own non-standard encryption.
What we have now is just the extreme case of this where each vendor has
an encryption approach that they don't trust anyone else with. Given the
difficulty of proving who leaked a key, that is the only reasonable view
they can take.
One possible alternative would be for each IP vendor to use a different
key and provide it to those vendors they consider trustworthy. This would
complicate the entire process, and is still susceptible to leaks and the
resulting finger-pointing.
There are other weaknesses in using a standard encryption package. Since
every user has a decrypter built into their tools, they can try to reverse-
engineer it enough to extract a key or the decrypted model. The more that
is known about the algorithms and the code, the easier this is. If it is
some separate program with publically available source code, it is a trivial
matter of modifying it to print out the decrypted source that is being fed
back into the tool.
People who talk about standard code encryption don't understand the problem
that is being solved.
- Steve Sharp
Cadence
( ESNUG 319 Item 12 ) -------------------------------------------- [5/99]
Subject: ( ESNUG 318 #10 ) Want DC To Remove Tied-off/'Dead' Flip-flops
> I am having difficulty getting Design Compiler to remove flip-flops that
> are tied off to a useless state. The specific example I am looking at is
> a d-type flip-flop with an asynchronous clear. It's D input is tied to
> '0'. The CLR input comes from other logic. So only 0's can be clocked in
> to this flop, and it can be cleared to set it to '0'. There is no way to
> set it to '1'.
> ---------
> '0' ----| D Q |---- Output
> | |
> CLK ----|> |
> Reset -----------| RST |
> ---------
>
> It seems to me that Design Compiler should optimize this dead flip-flop
> away and replace it with a tie-off to '0', which should then allow
> logic on the output side of the logic to be further optimized away.
> However, in my experience, this is not the case. The commands: compile,
> compile -boundary, and compile -in_place will not do what I want it to
> do. This configuration is not exactly the same as a tie-off since the
> flop could possibly power on in the '1' state, but I don't think this is
> a good enough reason not to allow the above optimization. Has anyone had
> any success with this, or know a better reason why this should not be
> optimized away?
>
> - John Patty
> Ericsson Research Triangle Park, NC
From: Gzim Derti <gderti@intrinsix.com>
Hi John,
Just my $0.000002 worth on this...
The issue that I see with the way that the gates are generated have to do
with the timing around the reset vs. clk interface. I'm not sure, but I'd
bet money that since DC sees a timing arc between reset and CLK, i.e. if
reset changes state too close to when clock occurrs possibly causing a
metastable condition, that DC "thinks" that this is an important issue
to model in simulation so the Flop stays as-is.
While for a long time, at slower clock freq's, many designers, myself
included, have seen the transition out of reset as a "system level" issue
when things start speeding up you've got to try and create "synchronous"
transitions on your reset signal or things go to "hell-in-a-hand-basket",
so to speak.
Anyway, it's early AM for me right now and I could be all wet, but that's
my best guess into the "mind of DC".
- Gzim Derti
Intrinsix Corp. Rochester, NY
---- ---- ---- ---- ---- ---- ----
From: Andrew Maccormack <andrewm@bristol.st.com>
John,
We use a pretty similar circuit quite frequently in our designs here:
--------------- (Q feeds back to D)
| --------- |
----| D Q |---- Output
| |
CLK ----|> |
Reset -----------| RST |
---------
Why? Well, we call these circuits "testable ties". If you have a real
gnd/vdd tie in your circuit, it can ruin your fault coverage. Since our
ATPG target is 99.7% coverage in all standard cell designs, we do not
want to take that hit. The above circuit offers the same functionality
in functional mode, but in parallel scan mode, we can shift a '1' into
the register no problem and therefore have complete controllability and
therefore fault coverage of that output.
Maybe that's why those FFs are in there and this user should consider what
removing them would do to his fault coverage.
- Andrew R MacCormack
STMicroelectronics UK
---- ---- ---- ---- ---- ---- ----
From: William Liao <wliao@mmcnet.com>
Hi, John,
I've noticed the problem John Patty described for several years now, and
it's only a subset of the real problem, which is Design Compiler never
removes storage elements. I've tried connecting set, reset, clock, or data
to force FFs or latches to constant values, and DC always kept them in
the design.
I asked a Synopsys engineer about this problem once (at SNUG'97 I think).
He suggested me to file a bug report. I never followed up. Perhaps I
should have.
- William Liao
MMC Networks
( ESNUG 319 Item 13 ) -------------------------------------------- [5/99]
Subject: ( ESNUG 318 #6 ) Cooley And Collett Live In Different Worlds
> However, I'm a reasonable guy, & I'm willing to give you a second chance,
> because perhaps you have gained lots of insight into what what kind of
> design methodologies will be needed in the future -- I hope so for your
> client's sake. What do you think the chip design methodology will look
> like 4 years from now? What are the issues? What will the solution space
> look like? What does the design environment look like? Be specific.
>
> - Ron Collett
> Collett International Santa Clara, CA
From: "Roberta Fulton" <Roberta.Fulton@xilinx.com>
John,
I have some sympathy for both Ron Collett and you, John, having been both a
real ASIC designer plus a semiconductor application and technical marketing
engineer trying to develop future methodologies for tomorrow's issues. As
a designer I was usually annoyed at not having today's problem's totally
solved and the EDA companies on my back trying to sell me a tool I really
didn't need yet (or at all) while trying to meet the deadline that was
already three weeks late before it was given to me.
Now on the other side of the fence, I am trying to access what the customers
might want tomorrow when they don't even know or to avoid uselessly try to
develop a market for a product that nobody would buy in a million years...
Its been eye-opening to walk a mile in the other gal's shoes.
- Roberta Fulton
Xilinx, Inc.
( ESNUG 319 Item 14 ) -------------------------------------------- [5/99]
From: Fabrice Barthier <barthier@spec.com>
Subject: Help! 'Error: The Package 'STD_LOGIC_UNSIGNED' Is Out Of Date' !
Hi John,
I have a problem when running Synopsys 99.05 design compiler on a vhdl
file using STD_LOGIC_UNSIGNED. Synopsys tells me, when I try to
elaborate a cell by keeping the option "Re-Analyze out-of-date libraries"
(in design_analyzer) :
Information: Re-analyzing the out of date architecture
'cellname(RTL)'. (LBR-15)
Error: The package 'STD_LOGIC_UNSIGNED' is out of date
and I can't find the source file
'/vobs/dware/packages/IEEE/src/std_logic_unsigned.vhd'. (LBR-4)
That means it tries to reanalyze a package that has already been compiled
but finds out this package is out-of-date and looks for the source in
/vobs/dware/...
BUT our Synopsys DC is installed in /tools/synopsys99.05, and not in
/vobs/dware.
Do you know how to solve this problem?
- Fabrice Barthier
SPEC Austin, TX
( ESNUG 319 Item 15 ) -------------------------------------------- [5/99]
Subject: ( ESNUG 318 #3 ) Converting SPICE Libs Into Synopsys Power Libs
>You may want to check with Mentor Graphics about their CellBuilder. It
>probably does what you want. It does characterize for power, but exactly
>into what formats I don't know, however writing a small script to translate
>from a to b when the simulation is done shouldn't be too difficult (at least
>when compared to writing scripts to automate simulation over temperature,
>voltage, process, load and slew-rate). Commercial pricing is probably a
>bit, shall we say prohibitive, but at least here in Scandinavia they have
>very reasonable license fees for academic institutions and the same should
>apply in the USA.
>
> - Magnus Svderberg
> Lunds Universitet Lund, Sweden
From: Shivkumar Kutty <kutty@Synopsys.COM>
Hi John,
I would like to inform your ESNUG readers about PowerArc, which is an
automated cell library power characterization tool from Synopsys. PowerArc
performs automatic and accurate power characterization of a variety cells
types including standard cells, IOs and memories and generates the standard
library (.lib) directly.
The key benefit of using PowerArc is primarily due to its accuracy,
automation and efficiency. PowerArc is based on the transistor-level
simulation technology provided by EPIC's PowerMill/ACE. It's roughly
10x faster than SPICE-based characterization tools.
- Shivkumar Kutty
Synopsys
( ESNUG 319 Item 16 ) -------------------------------------------- [5/99]
From: Paul Murata <paulm@sei.com>
Subject: Which Of These Power Books Are Useful? Which Are A Waste Of Time?
John,
Has anyone found a low power design reference worth reading? I've found a
number of books on Computer Literacy's web site but haven't had a chance
to leaf thru them yet:
Advanced Low-Power Digital Circuit Techniques
By Elrabaa, Muhammad S. / Abu-Khater, Issam S. / Elmasry, Mohamed
Low Power Digital CMOS Design
By Chandrakasan, Anantha P . / Brodersen, Robert W .
Logic Synthesis for Low Power VLSI Designs
By Iman, Sasan / Pedram, Massoud
Low Power Design in Deep Submicron Electronics
By Nebel, Wolfgang (Edt) / Mermet, Jean (Edt)
Low Power VLSI Design and Technology
By Yeap, G. K. (Edt) / Najm, F. N. (Edt) / Najm, Farid N. (Edt)
Low-Power Digital VLSI Design : Circuits and Systems
By Bellaouar, A. / Elmasry, Mohamed I. / Bellaouar, Abdellatif
Any suggestions/comments on these books would be greatly appreciated.
- Paul Murata
Silicon Engineering, Inc. Scotts Valley, CA
|
|
