It's always interesting for me to read "EE Times" when I give them a quote
for a news article. The reason why is I want to know what I said! Here's
an example quote, with the parts they cut within "( ... )", about the new
Synopsys Power Compiler that I gave "EE Times":
("In engineering terms, I think Power Compiler is sexier than being
the only guy stranded on a Pacific desert island with twenty Miss Nude
Universes. It's that hot!") "This is a real breakthrough. This is
the first real attempt at taking a proactive approach to doing low-power
designs." ("I know designers who would freely give their first born
child for something like this.") "I think this will be one of the
hottest products of the year."
Although I may be technically accurate, sometimes I get the sad, lonely
feeling they think my way of speaking isn't considered exactly, well,...
"Politically Correct"... <sniff!> :^(
- John Cooley
the ESNUG guy
( ESNUG 238 Item 1 ) ---------------------------------------------- [4/4/96]
From: jaf@leia.wustl.edu (Andy Fingerhut)
Subject: The Change_names v3.3b Command Is A Real Dog!
John, when we run the change_names command in Synopsys on our whole chip
(somewhere in the neighborhood of 60K - 100K gates), it goes *very* slowly.
We're running on Sparc-10 machines with 256 MB of RAM, and the ps command
says that the dc_shell process is using almost 100% of the CPU, so it
shouldn't be swapping. When I say very slowly, I mean that it renames 1 net
every 3 or 4 seconds! The command takes roughly 24 hours to complete.
define_name_rules verilog -allowed "a-zA-Z0-9_$" \
-first_restricted "0-9$" -replacement_char "_"
change_names -hierarchy -verbose -rules verilog > change_names.log
The best workaround for this is to avoid using change_names altogether.
Instead, create a Perl script to do the job on your Verilog netlists.
- Andy Fingerhut
Washington University
( ESNUG 238 Item 2 ) ---------------------------------------------- [4/4/96]
Subject: (ESNUG 234 #5 235 #1 237 #3) "What's The Customer 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.
From: ekadys@swi055.ericsson.se (Dyson Wilkes)
Hi, John,
The current writings on BC are interesting. It has been tried in a couple
of quite different application examples in Ericsson with completely different
degrees of success.
In one case the RTL designer got the basic design together in about a week.
The BC verison took 3 or 4 times to get through and was much larger and
slower. The main reason was that the code used in the BC case was not
suited to BC. Also it was an early verison and even Synopsys were on a
learning curve.
In another case the results were so encouraging that the designer involved
was advocating the use of BC. His main motivation was the reduction of
the number of lines of code you have to put in. I have no good metric but
my gut feeling is that the room for error increases geometrically with the
number of lines of code you have to enter to get a result. (Sit down! all
you Verilogers yelling Verilog is better than VHDL because the fewer number
of lines is less with Verilog for given function! -- I will just throw a
VHDL/Verilog scaling factor at you!)
The other major plus for BC is that you can verify the input to BC which
simulates >10 times faster (depends on how many clock cycles your
implementation takes to do the "loop" of course).
- Dyson Wilkes
Ericsson
> 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.
From: [ A Synopsys (Field) Application Consultant ]
John, the 150 operations number is a guidline. We usually say 150-200
operations as a guideline for running schedules pretty quickly. This is sort
of the same idea as recommending blocks of around 5-7k gates for Design
Compiler runs -- advice for keeping the run times reasonable. But, the
user's point is well taken -- you can burn up 150 operations fast. I've seen
some customer examples where they have used BC to make pipelined operators
out of several operations (say a custom MAC kind of function or something)
that may be require several cycles of latency -- then take the results back
into a higher level run of BC by means of DW. In that case, BC now sees the
complex DW operator as a single operator - BC understands how many cycles
that are required to process data through it. So, it can then schedule one
or more of those in the current design - and each will be a single operator
regardless of how many 'sub operations' reside in it.
- [ A Synopsys (Field) Application Consultant ]
( ESNUG 238 Item 3 ) ---------------------------------------------- [4/4/96]
From: Andy.Frazer@idt.com (Andrew Frazer)
Subject: Three Ways To Port From Synopsys To Cadence Dracula
John,
How do other users run layout verification (such as Dracula) on a design that
was synthesized with Synopsys? Synopsys writes out Verilog and VHDL
netlists, but it does not write out the CDL (similar to Spice) format which
Cadence's Dracula prefers. I know of three ways around this:
1.) tell Synopsys to create schematics, translate the output to a schematic
tool (such as Viewlogic) through EDIF, then write out the CDL/Spice
netlist from Viewlogic.
2.) use the Verilog netlist reader in Dracula's LOGLVS.
3.) write a home grown NAWK/C/Perl tool to translate the verilog netlist
into CDL/Spice format.
At IDT, we have adopted #1 as our standard, because we've had limited success
with #2 and never bothered to work on #3. I'd like to hear on ESNUG how
other users have solved this problem.
- Andy Frazer
Integrated Device Technology
( ESNUG 238 Item 4 ) ---------------------------------------------- [4/4/96]
From: ellement@sdd.hp.com (David Ellement)
Subject: (ESNUG 237 #4) Bum 2-D Arrays & Using "alias" To Mimic Functions
Hello John,
I overlooked an important detail in the two dimensional array example I sent
in ESNUG 237 #4 -- strong variable typing in Design Compiler. To correct this
find the two places in my script where:
_name = _period = _rising_edge = _skew = ""
and replace them with:
_name = ""
_period = _rising_edge = _skew = - 1.0
Sorry for the mistake!
Also, when I asked about emulating functions in dc_shell (ESNUG 237 #4), I've
used aliases for that purpose, except that it seemed necessary to use global
variables to pass parameters. (I suppose what I what I'm looking for is a
way to avoid the use of global variables.) Here's an example alias:
We've been using a set of generic scripts to synthesize our design (which
allows for some variation in synthesis process such as adding block specific
constraints by including block specific scripts if they exist.) IMPORTANT:
To avoid generating superfluous error messages, we wanted to test for the
*existence* of the specific scripts, before trying to "include" them.
With 'block_name' set to the block name, the test for the block timing
constraint script looked like this:
_file = block_name + "_timing.scr"
find_file
if (dc_shell_status == 0) { /* 'sh' exit code '0' when successful */
block_timing_script = _file
} else {
echo "Warning: missing script: " + _file
block_timing_script = ""
}
Since this same test is applied for different files, the test part has been
setup as an alias (find_file):
alias find_file "_test = \"\";\
foreach (_dir, search_path) { \
_test = _test + \"test -f \" + _dir + \"/\" + _file + \" || \"; \
}; \
sh _test + \"false\"" /* exit code `0' when successful */
This works, but what I'd really like is to define a function "find_file" that
would be applied:
block_timing_script = find_file (block_name + "_timing.scr")
As it stands now, I expect that I'll get bit by '_file' defined in mutiple
scripts when I don't want it defined.
- David Ellement
Hewlett Packard
( ESNUG 238 Item 5 ) ---------------------------------------------- [4/4/96]
Subject: Behavioral Compiler's Problems With Async Resets
>Achieving a design in Behavioral Compiler 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. ... 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...
From: [ A Synopsys (Field) Application Consultant ]
John,
I read Ted's comments about the use of Behavioral Compiler in the latest
ESNUG - I thought I'd pass on something that might help with async resets.
There is now a way to get BC to use async resets for more than just the FSM
registers. There is a variable called:
reset_clears_all_bc_registers="true"
that will connect an async reset to zero to all registers in the design.
Yes -- I meant that exactly -- *all* registers will be async reset to ZERO.
This means that BC will not currently encode async resets per the reset
portion of the behavioral code block - if there is a signal that must be set
asynchronously instead of reset, it would need to be manipulated by hand.
(I'm not sure what the status may be with an enhancement that would do that.
The current variable approach was implemented to at least get some sort of
async reset capability in there quickly.)
For sync resets, BC will use the encoding in the reset portion of the block
to set or reset signals. (I know that this variable was available in v3.3b
-- it may be available in v3.3a as well.) You'd use it along with:
set_behavioral_async_reset <pin name>
for getting async resets in the FSM.
- [ A Synopsys (Field) Application Consultant ]
( ESNUG 238 Item 6 ) ---------------------------------------------- [4/4/96]
From: gunes@jadeite.Eng.Sun.COM (Gunes Aybay)
Subject: Is Speedsim's DEC History A Customer Liability?
Hi John,
Concerning your discussion about Speedsim where you mentioned that they did
a lot of cycle-based simulation work while at DAC: how can we be sure that
SpeedSim is not using Digital's prorietary technology? Digital has a pretty
fast in-house cycle-based simulator which is considered one of the reasons
of their success with Alpha development. They would not be very happy about
somebody selling this techonogy to their competitors. If I make a deal with
SpeedSim today and they get sued tomorrow by Digital, I would not like to
change my design methodology in the middle of my design cycle.
- Gunes Aybay
Sun Microsystems
( ESNUG 238 Item 7 ) ---------------------------------------------- [4/4/96]
[ Editor's Note: "A Wanderer" below is *NOT* Gunes from above; I wouldn't
be that stupid nor careless with an anon user's anonimity. - John ]
From: [ Just A Wanderer ]
Subject: One User's Initial Impressions of Four Cycle-based Simulators
John
If you publish any of the following please keep my name (and company name)
out of it! I have recently (late 1995) talked to all the players in the
Cycle Based arena. A brief summary of what I found:
SpeedSim: as fast as they say it is but it only worked at gate level.
Company fast in reponding to customers; Good support for
Multi-processing too. Very fast compile (but its only from gate
level input.) Verilog only.
Cadence: a complete mess in terms of response to our requests. Not as
fast on real examples as they claim. Does do RT level. Compile
very slow. Verilog only (VHDL promised).
Synopsys: VHDL only, so we did not look as the interest was from hard-nosed
Verilog users ( *you* know the type <grin>).
Viewlogic: looked too far in the future for our needs at the time.
VHDL only (if I remember rightly)
The key thing is this Multi-Value DD stuff (i.e. Cadence and SpeedSim -- I
cannot comment on the technology of the other tools). It sucks! It means
you have to compile (effectively synthesize without optimization and
technology mapping) your nice, relativly abstract RTL into gate level
(logical) operations like NAND, NOR etc. Yeeech! Just for the hell of it
I threw a multiply operation at one of these tools & it neary died of shock!
(OK, you would not normally have a multiply in RTL you are about to stuff
into Design Compiler but + - or *anything* else that would get Synopsys's
DesignWare going is truely bad news!)
The right approach is to evaluate the RTL directly in a cycle-based way.
- [ Just A Wanderer ]
P.S. John, this work has led me to look at VHDL<->Verilog translation, too.
( ESNUG 238 Item 8 ) ---------------------------------------------- [4/4/96]
From: benz@npss.enet.dec.com (Chuck Benz)
Subject: How Do You Synthesize To Glitchless Logic (Or At Least Test For It?)
Hi, John,
I'm wondering whether I can trust synthesis on generating logic that won't
glitch in one mode of operation, when there is another mode of operation in
which glitches are likely, and acceptable.
module glitch_or_no (clk, reset, data_a, data_b, select, mode, dataout) ;
input clk, reset, data_a, data_b, select, mode ;
output dataout ;
reg dataout ;
reg [3:0] count, count_D ;
always @ (posedge clk)
begin
if (!reset)
count <= 0 ;
else
count <= count_D ;
end
always @ (clk or reset or data_a or data_b or select or mode or count)
begin
dataout = data_a ;
if (mode && select)
dataout = data_b ;
if ((mode == 0) && (count == 4))
dataout = data_b ;
count_D = count + 1 ;
end
Clearly, the decoder of 'count == 4' can glitch when clk changes, if
'mode == 0'. But most of us can design logic that will not glitch dataout
if 'mode == 1'! (I know about the trivial design fix to pass dataout through
a flop, but I'm trying to avoid that because of the performance hit.) It's
just my luck the synthesis of this trivial example will probably result
in safe logic -- but, if I had something like this buried in a large design,
how do I know it will this *always* synthesize to glitch-free logic?
Are there tools, or ways to use Synopsys tools to ensure (or later determine)
that the result is safe ? More abstractly, can tools determine whether
glitchless operation is possible for a given RTL ?
- Chuck Benz
Digital Equipment Corp.
|
|
