One of the other joys I got to experience involving returning home after
being away for 6 weeks came when I went to check my P.O. Box. When I
opened it, it was empty. ("What?!? I should have a *wheelbarrel* full of
mail!!!") It turns out that 2 weeks after I went on the road, the Post
Master put a little "Box Rent Due" notice in my mail box. Two more weeks
passed and I hadn't paid it nor pick up what was then a month's worth of
mail. After another week he figured I had left town for good so he freed
up my P.O. Box and returned *all* 6 weeks worth of mail to each sender
marking it "Addresse Unknown - No Forwarding Address Given". AAAAAAH!
I managed to get my old P.O. Box back but I'm *still* playing catch up
telling the phone company, my bank, the IRS, all my magazine subscriptions,
all the invoiced customers, all my other friends and business contacts
that yes, my same old P.O. Box is *still* my correct address. Argh.
- John Cooley
the ESNUG guy
( ESNUG 237 Item 1 ) ---------------------------------------------- [3/96]
Subject: ( ESNUG 234 #4 ) Synopsys/Leapfrog Library Incompatibly Issues
> We are just starting an ASIC design. Setting up the environment, we found
> out, that our ASIC vendor (TI) uses both the Synopsys IEEE (etc.) libraries
> and Leapfrog's (we are using Cadence Leapfrog for simulation). Simulation
> only modules use the Leapfrog libraries but synthesizable modules use it
> too. But, when it comes to synthesis, Synopsys' libraries have to be used
> instead.... Now, it seems just to be impossible to use the same set of
> libraries both for synthesis and simulation.!....
From: randy@vela.com (Randy Bolling)
John,
You need to compile the Synopsys libraries that are extensions into the IEEE
library. You will most likely require root access to do this (providing
Leapfrog was installed using root access ownership rights.) After compiling
the libraries, you can use the signed and unsigned packages. Creating the
library "synopsys" first and compiling the related packages into that library
is preliminary to compiling the synopsys packages into the IEEE library.
I usually setup creating the library "synopsys" with:
vhdlcom -work synopsys /vhdl/synopsrc/attributes.vhdl
vhdlcom -work ieee /vhdl/synopsrc/std_logic_textio.vhdl
vhdlcom -work ieee /vhdl/synopsrc/std_logic_misc.vhdl
vhdlcom -work synopsys /vhdl/synopsrc/math_complex.vhdl
vhdlcom -work synopsys /vhdl/synopsrc/math_real.vhdl
vhdlcom -work synopsys /vhdl/synopsrc/sdf_header.vhdl
vhdlcom -work synopsys /vhdl/synopsrc/bv_arithmatic.vhdl
vhdlcom -work synopsys /vhdl/synopsrc/distribution.vhdl
vhdlcom -work synopsys /vhdl/synopsrc/gs_types.vhdl
vhdlcom -work ieee /vhdl/synopsrc/std_logic_arith.vhdl
vhdlcom -work ieee /vhdl/synopsrc/std_logic_entit.vhdl
vhdlcom -work ieee /vhdl/synopsrc/std_logic_component.vhdl
vhdlcom -work ieee /vhdl/synopsrc/std_logic_textio.vhdl
vhdlcom -work ieee /vhdl/synopsrc/std_logic_signed.vhdl
vhdlcom -work ieee /vhdl/synopsrc/std_logic_unsigned.vhdl
vhdlcom -work ieee /vhdl/synopsrc/math_comlex.vhdl
vhdlcom -work ieee /vhdl/synopsrc/math_real.vhdl
vhdlcom -work ieee /vhdl/synopsrc/gs_types.vhdl
Where vhdlcom is the compile script to call up the vhdl compiler (or alias).
Check the command line switch -explicit for certian compilers. Explicit
declaractions will allow you to define the new signed and unsigned versions
of std_logic signed/unsigned arithmetic. Where "-work ieee" and "-work
synopsys" are the target libraries for the compilation. Last time I compiled
to Leapfrog, there were no signifigant issues (as with some vhdl compilers.)
All the code compiled directly, but some of the warnings / errors you might
encounter with various compilers :
- "(others=>'0')" clause for variable width constant declaration of a
Right-Hand value for the Left-Hand signal assignment fails in
compilation. Change to a for loop using 'high and 'low to determine
the bus width.
- Warnings about null bus width is cases where the bus is defined to
have no elements. Ignoring these is ok in most cases.
Libraries such as math complex and math real are compiled to both "synopsys"
and "ieee" to make them easy to reach. (It's merely a convenience!)
Every time you decide to re-compile these libraries, expect to out-of-date
all source code that reaches the libraries. (Meaning, entire ASIC's that are
taped out should have their libraries taped out!) It rarely happens, but
when you restore a tape and go searching for a bug in simulation, and can't
simulate without re-compiling, it leaves one with the feeling that "what if"
a change in the libraries affects the simulation.
- Randy Bolling
Vela Research
( ESNUG 237 Item 2 ) ---------------------------------------------- [3/96]
Subject: ( ESNUG 234 #2 ) "How To Borrow Synopsys Keys Within Your Company"
> Suppose your company has both East coast and West coast offices like, for
> example, Sun Microsystems. The people on the West coast won't get in
> until at least 11:00 East coast time, and the people on the East coast
> (officially) go home at 2:00 to 4:00 West coast time. The license keys are
> running 24 hours/day, why not temporarily use the ones from the other
> office while they aren't in the office? Here's how to use them...
From: [ NoName ]
John, please leave out my and my employer's name, OK?
Concerning the issue of sharing licenses across country, our Synopsys
license specifically states that the licenses can not be served to a machine
more than 10 miles distant from the license server. When we asked Synopsys
how much to convert our licenses to what they call a Wide-Area Network (WAN)
license, we learned that the WAN license costs about 20% extra.
Take into account that there are 5-6 hours of normal work time which overlap
between east and west coasts, and the fact that when the server goes down
during one coast's off hours, the other coast has no way to work or recover,
and you are talking about a very expensive solution. (While it is legally
and technically feasible to share licenses across countries, the problem set
that this solves is smaller than one might think.)
Synopsys, as we all should know, is not necesarily typical. Other companies
do not charge extra for WAN licenses.
- [ NoName ]
---- ---- ---- ---- ---- ---- ----
From: [ One Synopsys Salesman ]
Hi John,
Regarding ESNUG 234-Item 2, "How To Temporarily Borrow Synopsys Keys From
Within Your Company", it is a *violation* of the Synopsys license agreement
to use licenses outside a site. A site is defined as a 5 mile radius from
the license server. If you look into it, I believe you'll find that all the
major EDA companies have similar restrictions.
- [ One Synopsys Salesman ]
[ Editor's Note: I was surprized to hear about this 5 mile rule, especially
since I know Synopsys software is designed to run on workstations that
deviate by as much as 4 hours (the time zone width of the U.S.) as shown
in the "System Installation & Configuration Guide" under the heading of
"Verifying the Date" (at the end of Ch. 4.) Knowing this 5 mile rule, I'd
like to advise users *not* to borrow non-WAN licences or you'll just set
yourself up for a dip into deep legal doodoo when you're caught. (I do
mean "when" not "if" -- they almost always find out eventually.) - John ]
( ESNUG 237 Item 3 ) ---------------------------------------------- [3/96]
Subject: (ESNUG 234 #5 235 #1) "What's The Non-Propaganda Story On BC & DW?"
>I'm looking for information / real user testimony on ESNUG on Behavioral
>Compiler. I am also interested in the use model for DesignWare. We have
>been doing design for several years and have only been using the "free" DW
>components. Now with Behavioral Compiler, my Synopsys sales rep is really
>pushing DesignWare, saying that without it BC can't work its magic. (The
>only facts I can distill from my AE and the databooks is that I can't design
>pipelined arithmetic without DW.) He is also saying that in our industry,
>there is usually a DesignWare seat for every Design Compiler seat, which I
>found hard to believe.
From: khelifi@cae.ca (Djoudi Khelifi)
Hi John,
I'm a user of Behavioral compiler and DesignWare.
1.) BC is a very powerful tool for architectural exploration. You save
time and (vhdl lines) when coding in behavioral way.
2.) Coupled with BRT (behavioral retiming), BC performs a good job in area
and timing optimization.
3.) Designware is a very useful complementary feature for BC. The "magic"
is the capability of using piplined components and reducing complexity
of your BC code by encapsulating your bit-level logic operation
as DesignWare components.
4.) By using a DesignWare Developer you can create your own pipelined
arithmetic for BC.
This is only true if you change your RTL coding habits and learn how to code
in BC style way -- a specific design methodology.
- Djoudi Khelifi
CAE ELECTRONIQUE
---- ---- ---- ---- ---- ---- ----
From: TBOYDSTO@ic1d.Harris.COM (Theodore L. Boydston IV)
John,
I recently had the opportunity to use Behavioral Compiler for a couple of
mathematically complex blocks and was quite surprised at the high level
of resource efficiency the compiler produces. To get that efficiency and
verify the compiler's results, though, required overcoming many problems.
The first problem was trying to understand how Behavioral Compiler actually
constrains circuits. (This is a result of having to code your HDL quite
differently than you would if you were writing normal HDL Compiler code.)
This is compounded by Behavioral Compiler's ability to run in three different
constraining modes. Two of these modes give Behavioral Compiler the ability
to produce output that is timing and area efficient, although simulation
output between pre-synthesis and post-synthesis timing will, most likely, not
match! (To achieve pre-synthesis and post-synthesis simulations that match,
you must run Behavioral Compiler in a cycle-fixed mode, but then you will
not achieve the same timing/area efficiency!)
The next problem is that BC is limited to a total 150 operations. (An
operation is defined as *any* mathematical operation, signal assignment, or
variable assignment. This is quite a constraint, because most designs can
burn up 150 operations quite quickly!) There are workarounds to this
problem, like encapsulating complex operations into DesignWare components or
not unrolling loops, but I consider it a definite limitation. Oh, by the
way, these operations must exist in a single VHDL process (or Verilog always
loop) in order to achieve the best results. If you code multiple VHDL
processes or Verilog always loops, BC treats each as a seperate design!
Finally, achieving a design that has an asynchronous reset or strobes is,
well, a big pain in the buttocks! Optimally, Behavioral Compiler likes to
see one clock and a *synchronous* reset. This is because Behavioral Compiler
creates every design in terms of a state machine and associated logic.
(Behavioral Compiler does have the ability to use *asynchronous* reset, but
the output from pre- and post- simulations will not match!) If you use
strobes, you can only use an asynchronous reset, AND your pre- and post-
simulations will never match. (Oh, and when I SAY asynchronous reset, I do
not mean the obvious WAY of attaching a reset line to all the flops...
Oh No! -- Behavioral Compiler only puts asynchronous resets on certain
portions of the state machine. So, there are times where certain feedback
paths not in the state machine are not initialized and your simulation never
becomes defined!) The whole idea that I cannot use asynchrounous resets bugs
me, especially when I am using a resource limited device like an FPGA.
As for DesignWare, you will probably need it if you are doing a large design,
because of the 150 operations/process rule. Design Compiler only utilizes
the few of the non-free designware components, like the pipeline multiplier.
If you want to use any of the other DesignWare components, you will have to
instantiate them just like in your normal HDL code.
In summary, if you are building a design that has one clock and no strobes
and many small partitions, I say go for it. Otherwise, if you are doing a
complicated synchronous designs that use multiple strobes or resets, I would
be extremely careful using Behavioral Compiler. Hope this helps!
- Theodore L. Boydston IV
Harris Corporation
( ESNUG 237 Item 4 ) ---------------------------------------------- [3/96]
From: ellement@sdd.hp.com (David Ellement)
Subject: Will Trade "How To Fake Out 2-D Arrays In Dc_shell" For "Functions"
Hello John,
Following the "offer a little, *then* ask for a little" philosophy, here's a
tidbit on list processing in dc_shell to simulate two dimensional arrays.
Often times I have wanted two addition features in the Design Compiler
script language: two dimensional arrays and functions. I have found
a (clumsy) workaround to simulate dimensional arrays using the built-in
list processing capability.
To simulate a two dimensional array, I use a list and add or delete
items as n-tuples:
array_list = { initial_row_1 initial_row_2 initial_row_3 }
...
array_list = array_list + { next_row_1 next_row_2 next_row_3 }
...
array_list = array_list + { last_row_1 last_row_2 last_row_3 }
Later, when I need to access a particular piece of information, I use
a foreach loop:
item_1 = item_2 = item_3 = ""
foreach (item, array_list) {
if (item_1 == "") {
item_1 = item
continue
}
if (item_2 == "") {
item_2 = item
continue
}
item_3 = item
/* use item_1, item_2, item_3 */
item_1 = item_2 = item_3 = ""
}
One use has been for a generic script to compile pieces of a design with
multiple clocks (not all of which are present in each piece) and for which
the name used for each clock is different in the different designs:
/* in an initialization script */
/* set clock data: { name period rising_edge skew } */
clock_list = { "Clk" 50 0 0.5 }
clock_list = clock_list + { "iClk" 50 25 0.8 }
...
/* in the generic script */
_name = _period = _rising_edge = _skew = ""
foreach (item, clock_list) {
if (_name == "") {
_name = item
continue
}
if (_period == "") {
_period = item
continue
}
if (_rising_edge == "") {
_rising_edge = item
continue
}
_skew = item
create_clock -name _name -period _period \
-waveform { _rising_edge _rising_edge + _period / 2 } _name
set_clock_skew -uncertainty _skew _name
_name = _period = _rising_edge = _skew = ""
}
Now I've contributed to ESNUG, I'd like to ask: Does anyone have a method to
provide something like "function" capability?
- David Ellement
Hewlett-Packard
( ESNUG 237 Item 5 ) ---------------------------------------------- [3/96]
From: snowbin@ix.netcom.com (Joe Smith)
Subject: How Do You Synthesize A Digital PLL From Verilog Or VHDL?
Hello John,
I would like to know if anyone out there has described (and successfully
synthesized--using Synopsys or others) an RTL model of a digital Phase
Locked Loop (PLL) using purely Verilog or VHDL constructs. Examples and
suggestions here on ESNUG are appreciated.
- Joe Smith
KTE Comms, Inc.
( ESNUG 237 Item 6 ) ---------------------------------------------- [3/96]
From: monsefh@ws065.bytex.network.com (Hamid Monsef)
Subject: What Are The Best & Worst (To Use) ATPG Tools Currently Available?
John,
I have started designing a high gate count ASIC (100K +). I want to use ATPG
for fault coverage, but don't know which one to use. It seems there are many
ATPG tools for use. Since I have not used ATPG before, I would like to get
your opinion on that. On my last ASIC which was (only 4K gates) I used
Voyager Fault Simulator. It took me two weeks to increase my fault coverage
to 95%. It was a very tedious job which I don't think I want to do again.
- Hamid Monsef
Bytex
[ Editor's Note: As always, if those who reply to this (or any other topic)
want to be anonymous, just say so and you'll be anonymous! - John ]
( ESNUG 237 Networking Section ) ---------------------------------- [3/96]
Chelmsford, MA. -- Sun Microsystems wants Systems, ASIC, & Verif. Engineers
who know Verilog & Synopsys. No agencies. "willis.hendley@east.sun.com"
|
|
