Editor's Note: Every now and then I get together with my friend Matt and
some of the guys just to watch videotaped episodes of various campy sci-fi
TV shows. Matt has odd television tastes and belongs to an underground
network of people who eagerly swap such videos. Matt's the one who
introduced me to "Red Dwarf". And years ago, before it was readily
available to the U.S. public, Matt managed to get his hands on a Japanese
release of "The Rocky Horror Picture Show". (Let me tell you, it was
simply *weird* to see "Rocky Horror" in Japanese. I think my psyche has
been permanently damaged from that one experience...)
Anyway, our little group of friends have been used to Matt having bootleg
videos coming from somewhere far away. Last night, after a rather
exhausting weekend for most of us, we gathered at Matt's house at 11:PM
to watch "Babylon 5". We were all fried from work. It appeared that this
tape was made somewhere in upstate New York late at night. How did we know
that? Because one of the commercials was for a phone sex line. We watched
the ad with the usual half-lust, half-boredom, and half-cynicism a group
of exhausted males has at that time of night. Envision three very sexy
and scantly clad women sorta half dancing around saying:
"I love to talk to men who are free... free with their love...."
"Yes, I'm just a free and easy girl. Call me. I'm lonely... and free."
"Call us at (800) FREE-LUV... Call now... Call (800) FREE-LUV..."
And we all simultaneously burst out laughing when we saw that last legally
required, rest-of-the-story, truth-in-advertising part of the ad:
"1 (800) FREE-LUV costs $2.50 per minute. Visa or Mastercard
accepted. You must be 18 or older to call."
- John Cooley
the ESNUG guy
( ESNUG 270 Item 1 ) -------------------------------------------- [10/97]
From: Sean Murphy <skmurphy@netcom.com>
Subject: Get Apollo OS Patch Before Sysclock Strikes -0.25s On Nov-2-97 !!!
John,
Even though it's Halloween today, what follows is not a Halloween prank for
those of your readers still using Apollo workstations for designing or as
an archive server for old designs. The Apollo system clock was based on
counting the number of 1/4-seconds since January 1, 1980, and on this
Sunday, November 2, it will roll over the sign bit in the 32-bit number that
it is stored in. Here is the HP field service description of the problem:
D500186213 - After 14:59 GMT on November 2, 1997, penultimate bit of the
system clock will be set. This may cause numerous problems
as not all of code is doing timer comparisons correctly.
and warns that data corruption may ensue after the "Rollover" date. Patches
are available from the HP web site (http://us.external.hp.com/) for several
versions of Apollo Domain SR9 and SR10. An HP user group, the InterWorks
Technical Users Forum, has a long and detailed article about the best way to
implement these patches at http://www.interworks.org/Tech/apollonov2/ and if
you are still relying on V7 based data archives, Concurrent CAE Systems
(http://www.ccaes.com/) has released a free utility that can be used to
unload all of the design database information into an ASCII dump format.
- Sean Murphy
Consultant
( ESNUG 270 Item 2 ) -------------------------------------------- [10/97]
Subject: ( ESNUG 269 #5 ) Synopsys Design Compiler & Removing Gated Clocks
> I am converting a 2-phase latch based gated-clock design into a non-gated
> clock design. We're removing the gated clocks to avoid any surprises with
> the clock tree distribution. Our proposed solution was to take the gated
> clock, call it CKHLD, and break it into it's constituents, namely CK &
> HLD. A latch that had
>
> always @(CKHLD or D)
> if (CKHLD) Q <= D;
>
> would be rewritten to
>
> always @(CK or HLD)
> begin
> if (CK) begin
> if (!HLD) Q <= D;
> else Q <= Q;
> end
> end
From: mcurry@ti.com (Mark Curry)
John, it's funny, great minds must think alike!
Regarding Thomas Tomazin's problem with Synopsys and latches, we were having
similar problems with our Synopsys jobs and latches, and came up with the
same solution as he did above. For anyone else that's using this trick
be sure you set the following:
hdlin_keep_feedback = true
Without this, Design Compiler sees the Q <= Q, and optimises the HLD back
out -- what he was trying to avoid.
But, I've also found that this doesn't always work. It depends on what
cells are in the library. Adding asynchronous reset/sets will really gum
things up as well. Synopsys sees the CK, and HLD as functionally
equivalent, and optimizes them. With a reset, it'll create a path to the
CK, and D of the latch, creating a race.
I'm hoping someone else out there in ESNUG-land has found better solutions
and will chime in...
Regarding the latches that feedback on themselves. Yep, we ran into that
too. Here's a little script we used to counter:
/* Synopsys get's confused by latches that feedback on themselves.... */
foreach( latch, all_registers( -level ) ) {
set_false_path -from find( pin, latch + "/C*" ) \
-to find( pin, latch + "/D*" )
}
You'll notice that I coded this assuming the clock pin matches "C*", and
the D matches "D*". You may need to modify as per your vendors libraries.
A warning however -- this turns off all timing from a latch to itself
-- you may have some long paths that really are violating - but timing is
not being checked!!
- Mark Curry
Texas Instruments ASIC Design Center - San Jose
( ESNUG 270 Item 3 ) -------------------------------------------- [10/97]
Subject: ( ESNUG 268 #8 269 #1 ) HP, DEC, SUN Benchmarks w/ Synopsys
> At our company we have historically used SparcStations and UltraSparcs as
> our Verilog and Synopsys engines. Given the nosebleed prices of *certain*
> EDA tools, we are curious if other hardware platforms might deliver better
> Synopsys performance and, as a result, improve the utilization of our
> Synopsys licenses. Sooo.... Has anyone out there benchmarked HP,
> Dec-Alpha, and Ultra Sparc's running Synopsys. Could you please share
> them with us on ESNUG?
From: Mike Gallagher <gallagher@alc.com>
John,
I hear that Verilog is in the process of moving to a Pentium / Windows NT
capability. Anybody else hear this? Just curious. A System Engineering
tool I use that is very resource hungry has been adopted that way and in
general, its performance matches, but usually exceeds the performance on
Unix platforms.
- Mike Gallagher
Ascent Logic Corporation
( ESNUG 270 Item 4 ) -------------------------------------------- [10/97]
Subject: ( ESNUG 269 # 6 ) DC 97.01 & 97.08 Inconsistant W/ Bussed VHDL Ports
> When I first installed 1997.08, I did experience an inconsistency (which
> I reported to Synopsys) in versus 1997.01 with respect to how the VHDL
> writer handles bussed ports (w/ certain combinations of switch settings).
>
> When I read into 1997.08 a source VHDL file containing a vector port in
> which the LSB was non-zero, and then wrote out the same design as VHDL
> output file, it changed the range of the vector of the LSB to zero!
From: bautista@cma.ulpgc.es (Tomas Bautista)
Hi, John,
In using the Synopsys design_analyzer, I've found this bit blasting to only
be a VHDL-related problem. In my designs, every port I have inside the
design is written out all right when saving the design in a DB file or in a
Verilog one. But when saving it in a VHDL one, it splits the whole bus port
into a set of 1-bit ports. For instance, a(31:0) is translated into
a_31_port, a_30_port, and so on.
- Tomas Bautista
University of Las Palmas de G.C.
( ESNUG 270 Item 5 ) -------------------------------------------- [10/97]
Subject: (ESNUG 267 #1 268 #5 269 #4) *WHO* Is Using Behavioral Compiler?
> BC is just not ready - plain and simple.
>
> BC does not follow the fundamental design methodology of hierarchy -
> it's hard to hook two BC generated blocks together. BC wants the
> freedom to change the interface on each of the blocks (a very
> block-centric approach).
>
> - Victor J. Duvanenko
> Truevision
From: [ A Synopsys BC CAE ]
John, This really depends on how Victor wishes to use BC.
If you choose to use BC in the super-state mode, then the tool has
additional degrees of freedom. These degrees of freedom can be used to
adjust latency and other cycle-specific behavior. If you want to take
advantage of efficiencies which can be generated by allowing the
compiler to decide when an output becomes available then you need to be
careful at the interfaces. Using a data available signal to handshake
with external blocks can make your design more robust, flexible and
reusable in general. When the cycle specific timing is unknown then the
handshaking is essential.
If using handshakes is unacceptable within your design methodology then
BC can equally be used in cycle_fixed mode which preserves the
cycle-specific behaviour of the design at the behavioral, RTL and the
gate level. BC is still able to schedule and share operations etc in
your design.
- [ A Synopsys BC CAE ]
---- ---- ---- ---- ---- ---- ----
> About 6 months ago, I evaluated Behavioral Compiler for use in a DSP modem
> asic. Previously, I had used verilog and found the use of parameterized
> designs for handling datapath to be an incredible timesaver. Carrying this
> forward, I concluded that the use of vhdl with its more robust generic
> command (allowing for optional hw elements) in combination with BC would
> result in excellent architectural flexibility.
>
> Now the bad news, I found that BC was incompatible with the use of
> parameterization. This to me was a fundamental flaw -- I would rather have
> parameterization over scheduling.
>
> Just wanted to forewarn others - and I never got a Synopsys commitment to
> fixing this.
>
> - Robert Hoffman
> Siforge
From: [ A Synopsys BC CAE ]
Hi, John,
As you know, the Verilog language allows you to create parameterized designs
by overriding parameter values in a module during instantiation. In Verilog,
you can do this with the defparam statement or with the following syntax:
module_name #(parameter_value,parameter_value,...) \
instance_name (terminal_list)
Currently neither HDL Compiler or Behavioral Compiler supports the Verilog
defparam statement, but HDL Compiler does support the above mentioned syntax.
Behavioral Compiler does not support the previous statement per se because
it does not support component instantiation. However, this ESNUG reader
might be interested to know that it is possible to use parameters to define
bit widths or latency for modules within Behavioral Compiler. Define your
module as follows:
module par_des (a, b, c);
parameter in_width = 8;
parameter out_width = 16;
input [in_width-1:0] a, b;
output [out_width-1:0] c;
Now, these parameters can then be overwritten at elaboration time using:
elaborate -s par_des "in_width=>16,out_width=>32"
Of course, the RTL blocks which instantiate the Behavioral Compiler blocks
can still use the "module_name #(parameter_val..." from above. And for
those VHDL users out there, you can of course use generics instead of
parameters. :-)
- [ A Synopsys BC CAE ]
---- ---- ---- ---- ---- ---- ----
> BC does not understand the concept of "stalling data pipes", such as
> when your block is surrounded by FIFO's and there happened to be no
> data available for the pipe to work on, so BC doesn't know how to
> design pipes that stop for a while and wait for data to get there.
>
> - Victor J. Duvanenko
> Truevision
From: [ A Synopsys BC CAE ]
John,
For designs that contain memories and/or sequential Designware components
that BC is required to stall, Victor Duvanenko is absolutely correct. For
other designs, BC can support the stall functionality. We are currently
planning on expanding the scope to include memories and sequential
Designware components.
- [ A Synopsys BC CAE ]
( ESNUG 270 Item 6 ) -------------------------------------------- [10/97]
From: tboydsto@su102s.ess.harris.com (Ted Boydston)
Subject: I Miss The SOLV-IT Puns!!! :(
John,
If you are on the SOLV-IT mailing list, you are probably aware that there is
a new owner of the mailing list. This person, unfortunately, has decided
not to follow the previous owner's policy to put all the information in the
form of puns, instead opting for a straightforward-here-is-your-information-
in-black-and-white approach. Now, I usually would not have a problem with
this, but I used to look forward to getting SOLV-IT just for the puns. Of
course, there was the added benefit of getting the great info that comes
along with SOLV-IT, too. Now, all I have to look forward to is plain
info....no fun....and no diffenent than other comapnies.
I know, I KNOW, you do not want to start flame wars on ESNUG, but I thought
this was important, because those puns would usually draw my eye to the more
important pieces of info. Am I crazy?!?
Oh well, I'd really like you opinion on this. If you think that I'm not
crazy, then maybe you could post some editorial about this on ESNUG,
encouraging readers to write the new owner to put the same "fun with
pupose" content as the last owner.
Hoping to not go crazy.....
- Ted Boydston
Harris Semiconductor
( ESNUG 270 Item 7 ) -------------------------------------------- [10/97]
Subject: ( ESNUG 267 # 6 268 # 2) Synopsys 1997.08 -- To Use Or Not To Use?
> We are finding that designs that compiled fine with 1997.01-44683 and 3.4b,
> cause those "friendly" FATAL ERROR ENCOUNTERED in 1997.08.
>
> I've been trying to get a pulse from some of the AE's at Synopsys if this
> 1997.08 release is worth progressing to (from 1997.01-44683) or not. At
> least one AE claimed none of his/her other customers had upgraded, yet, so
> he/she had no other feedback but mine.
From: "Tom Harrington" <tharring@ford.com>
John,
As Greg Mann mentioned to you, we've been bitten by fatal errors on
Synopsys 1997.08. I thought ESNUG readers might be interested in the
details of the problem as we're experiencing it.
Our fatal errors with 1997.08 are related to the use of parameterized
sub-modules. If you analyze/elaborate a design that instantiates
a parameterized block, dc_shell croaks just as it tries to build
the sub-module. So far I've observed this on two separate designs.
Since we make heavy use of parameterized blocks, this is a major
roadblock for us.
We're using Verilog, although I'm not sure yet if that's significant.
Unlike Howard Landman, we don't use connection_class at all. For
now, 1997.08 has been declared unfit for human consumption around
here while I try to find a work-around. I've submitted a test case
to Synopsys support, but so far I've only received auto-responses.
Our AE says he hasn't heard of any other problems with this release.
Synopsys 1997.08-12345, anyone?
- Tom Harrington
Ford Microelectronics, Inc.
---- ---- ---- ---- ---- ---- ----
From: landmh@taec.toshiba.com (Howard Landman)
Hi John,
My problems with 1997.08 crashing went away after I:
(1) Removed all connection_class statements from my library
and recompiled the library.
(2) Removed all "set_connection_class" commands from my scripts.
(3) Executed the following on all .db files to remove any stored
connection_classes:
foreach(des,find(design)) {
current_design = des
set_connection_class "default" find(port)
}
So, it looks like the problems *were* connection_class related. However,
some other people reported that they were crashing without having any
connection_class stuff. I'll see if I can find their email and forward
it to you.
I'm still having other problems, most notably long run times. One job just
completed after 11.5 cpu-days, for example. And that was "-incremental"!!!
- Howard A. Landman
Toshiba America Electronic Components
( ESNUG 270 Item 8 ) -------------------------------------------- [10/97]
From: Anindya Saha <asaha@tif.ti.com>
Subject: A Tip When Inferring Negative Edge Triggered Flip-flops
Hi John,
If you are using some negative edge triggered flip-flop constructs in your
VHDL design of the type:
if ( clk'event and clk='0') ...
or for the Verilog users, of the type
always @( negedge clk) ...
I've found that Design Compiler sometimes creates a *rising* edge triggered
flip-flop with an inverter at the clock input instead of grabbing a negative
edge flip-flop!
My tip is that if you want to make sure you get a true negative edged flip-
flop, before compiling in DC, make sure to place a set_dont_touch attribute
on clk.
- Anindya Saha
Texas Instruments
( ESNUG 270 Item 9 ) -------------------------------------------- [10/97]
From: "Russell Ray" <rray@msai.mea.com>
Subject: Seeking DesignWare Foundation Licensing Tricks
John,
We have less DW Foundation licenses than DC licenses. Currently we have
the designers not point to any of the advanced DW architectures unless their
design is not meeting timing. Does anyone know of a way to only check out
the DW Foundation license when you want to write out the design and maybe
run everything else in eval mode?
- Russ Ray
Mitsubishi
|
|
