jcooley@world.std.com (John Cooley) wrote:
> Conversely, I can't see how those silly, silly Californians can get
> *any* work done. Who wants to sit in a cubical and pour through
> 20,000 lines of source code chasing some obscure pain-in-the-ass
> design and/or EDA bug when you have "BayWatch" going on right there???
> How do they do it?"
From: wlenihan@CCGATE.HAC.COM (Bill Lenihan)
John,
As a former easterner now living in L.A., let me clue you in on two
points that help explain how we can get any serious work done here
in Southern California:
1) The real-world "BayWatch" crowd hasn't the slightest interest in
engineers, regardless of whether said engineers look like they stepped
out of a Dilbert comic strip or MTV's House of Style. The mythology of
the engineer is too strong out here and admitting membership in that
group paints a mental picture of "pocket-protector-ed, nerdy-ass
geekazoid" in the mind of your audience. Sadly, convicted serial
killers have better opportunities to hook up with members of the
opposite sex (pardon me, make that 'preferred sex' or whatever) than
technical professionals in California.
2) You've got cold weather to motivate you to stay indoors for a few
months. We have random, drive-by shootings and grid-locked freeways
year-round. Different causes, same effects.
- Bill Lenihan
Hughes Aircraft Co.
( ESNUG 273 Item 1 ) --------------------------------------------- [12/5/97]
From: jcooley@world.std.com ( John Cooley )
Subject: WARNING Design Compiler 97.08 Is Creating BROKEN Logic !
I just recieved a warning from my contacts within Synopsys that Design
Compiler 97.08 is creating functionally incorrect logic. (Apparently this
bug was a side-effect of Synopsys trying to speed up elaboration times
within HDL Compiler.) Currently, there are two workarounds to this bug:
1) Analyze/elaborate (or read) the design using DC 97.01. Write out the
*unmapped* .db file. Then compile the db file using DC 97.08.
2) Or, when using DC 97.08 release, set the following undocumented
variable at the dc_shell prompt *prior* to reading in the HDL source.
hdlin_turbo_sequential = false
The Synopsys people also told me that they'll be shipping a patched version
of DC 97.08 to all synthesis customers by the 3rd week of December.
- John Cooley
the ESNUG guy
( ESNUG 273 Item 2 ) --------------------------------------------- [12/5/97]
Subject: ( ESNUG 271 #1 ) Homebrew EDA Benchmarks & Synopsys On DEC Alpha
> Gosh *thanks* for the homebrew benchmark formula. But do they still port
> Synopsys tools onto the DEC Alpha platform?
>
> - Brien Anderson
> Acuson
From: Julie Staraitis <staraitis@ricks.ENET.dec.com>
John,
Synopsys on Alpha is alive, and maintained. It's used by several different
design groups around here in DEC.
- Julie Staraitis
Digital Equipment Corportation
---- ---- ---- ---- ---- ---- ----
From: [ Somewhere Within Synopsys ]
Hi John,
Just wanted to let everyone know that the DEC Alpha is a Synopsys supported
platform.
- [ Somewhere Within Synopsys ]
( ESNUG 273 Item 3 ) --------------------------------------------- [12/5/97]
Subject: ( ESNUG 272 #9 ) Floating DW Inputs, Weird Stuff, & Module Compiler
> I am using Design Compiler for my synthesis in VHDL. I have a matrix
> multiplication in my design. It is a 3 by 3 matrix. My coefficients as
> well as the inputs are signed. For one sum of partial products I use:
>
> a <= signed(c1) * signed(in1) +
> signed(c2) * signed(in2) +
> signed(c3) * signed(in3);
>
> Q1) DC does not recognize "signed" and thus when it uses designware for
> the mutlipliers, it does'nt connect the "TC" (two's complement) to high
> -- it just lets it float. (Floating inputs??!!!) The way I got around
> it is to instantiate the DW02_mult and "force" the TC bit high. Is
> there any other, more automatic way to solve this problem beyond hand
> instantiating & baby-sitting DW parts?
>
> Q2) When I use the above equation, I break it into partial products, i.e.
>
> wait until clk'event and clk='1';
> a1 <= signed(c1) * signed(in1);
> a2 <= signed(c2) * signed(in2);
> a3 <= signed(c3) * signed(in3);
> a <= a1 + a2 + a3;
>
> And I don't meet my timing.
>
> Although if I take the sum of the partial products ( a1, a2, a3) and
> optimize them seperately in another file, I seem to achieve my timing:
>
> VHDL file_1:
>
> wait until clk'event and clk='1';
> a1 <= signed(c1) * signed(in1);
> a2 <= signed(c2) * signed(in2);
> a3 <= signed(c3) * signed(in3);
>
> VHDL file_2:
> wait until clk'event and clk='1';
> a <= a1 + a2 + a3;
>
> Why is Design Compiler croaking on such a small magnitude design ??
>
> - Xerxes Wania
> Xentec Inc., Canada
From: charles@efficient.com (Charles Shelor)
John,
When you have it in 2 files, it has become pipelined. You will get a set
of registers for the partial products and then those registers will get
passed to the adders in the "second stage".
No multiplier is a "small magnitude design" being proportional to m * n,
where m and n are the bit lengths of the two inputs.
- Charles F. Shelor
Efficient Networks
---- ---- ---- ---- ---- ---- ----
From: Hesham El Adly <hesham@cae.ca>
Hi John,
Replying to Xerxes post in ESNUG 272; As an alternative to using DC's
somewhat limited datapath optimizations, matrix multiplications can be
targeted with either of Synopsys's datapath tools - BC's BOA/BRT engine
or Module Compiler.
With BC, I suggest using BOA with BRT. BOA, behavioral optimization of
arithmetic functions, can transform a datapath into a faster datapath based
mainly on carry save adder trees.
Carry save adders calculate partial sums. CSAs have no carry propagation
delay with the area of a standard adder. So, delay is independant of bit
width. A standard full adder, however, is still required at the bottom of
the tree to produce a single value.
BOA can be applied to any design that can be deconstructed into adder
trees. This is done through a single command, transform_csa, after
elaboration - no scheduling required.
If the design does not require data to be produced on every clock (ie. not
every resource is used on every clock) then you can try BC's scheduler. The
scheduler will try to share resources and may reduce area further.
BRT can be used after the design has been BOAed and compiled to move any
registers in the design to meet timing goals.
The usage model of BOA/BRT is interesting in that the design can be an RTL
design. We do not have to change our coding styles, as we do with BC's
scheduler, to use BOA/BRT. In fact, we just need to code our datapath and
instantiate some registers (or use the pipeline_design command to add
registers to a combinational design) and let BOA/BRT perform timing and
register optimization.
We're using BOA/BRT as a fairly standard approach to get our very high
performance datapaths to meet timing and area.
MC can be also be used and will eat the matrix operations for lunch. If you
use MC, I suggest that register placement be optimized with BRT instead of
MC's pipeline retiming capability. We've found that BRT reduces sequential
area somewhat better than MC.
Note that MC (Module Compiler) is a datapath "expert" design tool. You have
to be very experienced and understand exactly the datapath you want to
achieve to get the best results with MC. Conversely, BOA/BRT is really easy
to use but designers still need some datapath knowledge to make the best
use of BOA.
- Hesham El-Adly
CAE Electronics, Ltd. Quebec, Canada
---- ---- ---- ---- ---- ---- ----
From: tom@iota.com (Iu-Meng Tom Ho)
Hi John,
In our DCT/IDCT modules, we have over 16 Multipliers with a constant. Since
we need to go 100Mhz, we created our own two's complement Wallace tree for
multipling a constant.
In your application, we could use 3 of those trees and a 6 input adder for
the final add. The size is going to be larger than Synopsys. It is just a
lot faster.
DC is great. We want to use it as much as we can. In some of our special
cases, we just have to do things by hand. In most of the multiplier
applications, we insert our own netlists while synthesizing the rest with
Synopsys.
- Tom Ho
Iota
---- ---- ---- ---- ---- ---- ----
From: Xerxes Wania <xerxes_wania@xentec-inc.com>
John,
Here's a follow-up to my problems.
Synopsys did start to look at the problem. It seems that when you do use
DesignWare components with a TC pin, the logic generated is correct (of
course) but after optimizing, the TC pin inside the module may seem
unconnected. What it actually does is to optimize the TC pin internally to
logic 0 or 1 thus not requiring the TC pin to be connected external to the
component. Visiually this looks like an error, but internally it is all
working fine.
Regarding the matrix multiplication, Synopsys is still looking into
regenerating the design on their premises. They will get back to me soon.
Thanks ESNUG, it really got things going.
- Xerxes Wania
Xentec, Inc. Ontario, Canada
( ESNUG 273 Item 4 ) --------------------------------------------- [12/5/97]
Subject: (ESNUG 271 #4) How BC Handles Designs That Involve Handshaking
>Maybe it's been a while since I've looked at BC, or maybe BC has improved,
>but here is the scenario that I remember which BC could not tackle and why
>I say that BC fails in the basics of hierarchical design. I code up a BC
>block that may or may not generate a data item on every cycle, so I have a
>signal calle "valid" that accompanies the data output. Then since my blocks
>are symmetrical, my next block can take the input on every cycles, but once
>in a while it can't. So, my next block has a handshaking signal going back
>to the first block called "got_it".
>
>This methodology is followed at nausium.
>
>What BC could not handle is the fact that there was a two-way handshaking
>mechanism (which is very common - like PCI-bus's IRDY# and TRDY# signals),
>where the sender and the reciever both have flow control. BC wanted only
>one of the blocks to be able to control the flow of data, but not both. To
>me that meant that I could design only certain blocks with BC (the ones that
>BC could handle) and the rest with an RTL methodology. That once again may
>be enough of a productivity gain for some "design spaces", and there maybe
>lots of "design spaces" that BC can handle very well, just not the one I
>needed. At the time when I took the BC class I spoke to the BC CAE and he
>admitted that BC couldn't handle stalling or the two-way handshake, but that
>in the future BC would improve and take on more "design spaces". I'm just
>more ready that most to move beyond this RTL-level design methodology that
>we've been crawling with. I'm very glad that Synopsys continues their
>relentless march toward the next level of design tools (good job!) - I just
>wish that it was here already.
>
> - Victor J. Duvanenko
> Truevision
From: [ A Synopsys BC CAE ]
Hi John,
If I understand Victor correctly what he would like is that both blocks have
control over the signal flow. In other words the "producing" block provides
output data along with a data integrity signal specifying whether the output
data is valid or not (i.e. output_data and data_valid).
The "receiving" block then may or may not be able to read this valid
output_data so the "receiving" block is required to acknowledge the receipt
of the "producing" block's output_data. If the "receiving" block does not
acknowledge the receipt of the "producing" block's output_data then the
"producing" block should stall until it does.
There are two basic BC coding approaches to this scenario.
First, "Producing" block produces a data_valid output along with the
output_data itself. (This is very easy to do within BC.)
Verilog
-------
forever begin: main_loop
data_valid <= 1'b0;
d_reg = data;
@(posedge clk);
....
output_data <= calculation(d_reg);
data_valid <= 1'b1;
@(posedge clk);
end // main_loop
VHDL
----
main: loop
data_valid <= `0';
d_reg := data;
wait until clk'event and clk='1';
....
output_data <= calculation(d_reg);
data_valid <= `1';
wait until clk'event and clk= `1';
end loop main;
Second, the "receiving" block needs to let the "producing" block know
whether it received the data. (This is, again, very easy to do in BC.)
Verilog
-------
if ((data_valid == 1'b1 && i_am_ready == 1'b1)
begin
stall_producing_block <= 1'b1;
@(posedge clk);
....process data....
@(posedge clk);
end
else
begin
stall_producing_block <= 1'b0;
@(posedge clk);
end
end if;
VHDL
----
if ((data_valid = '1' and i_am_ready = '1') then
stall_producing_block <= 1'b1;
wait until clk'event and clk= `1';
....process data....
wait until clk'event and clk= `1';
else
stall_producing_block <= 1'b0;
wait until clk'event and clk= `1';
end if;
So, now that I've answered Victor's question, I'd like to ask he and the
other ESNUG BC users a somewhat related handshaking question:
BC allows read operations to take place during any cycle of a superstate.
Therefore, it is necessary to register all of the inputs to a BC process for
the entire duration of the superstate in which they are sampled. The
architectures produced by BC follow this recommendation, because all outputs
of any process scheduled by BC are registered and held for the entire
duration of the next superstate. So there is always a one cycle latency
between an input and output of a BC process.
Now the $64 question:
We (the BC team) have been toying with the idea of allowing users to define
a pragma/compiler directive that causes BC not to register particular
outputs. We have concerns that if users are not careful they can cause
their designs to fail. (For example if I remove the register for my
data_valid signal (above) and not my output_data signal, then my handshaking
protocol will no longer work.)
What do users think? Is this something we should do, and if so why?
- [ A Synopsys BC CAE ]
( ESNUG 273 Item 5 ) --------------------------------------------- [12/5/97]
From: charles@efficient.com (Charles Shelor)
Subject: Vhdlan Defaults Have Changed To Give You Lots Of Warnings
John,
Here is something I just noticed in the 1997.08 simulation release. The
'vhdlan' analysis software now defaults to 'compiled mode' analysis and
produces a warning about that. If you are tired of that warning message
put the following in your ".synopsys_vss.setup" file:
CS_COMPILED_WARN = FALSE
- Charles F. Shelor
Efficient Networks
( ESNUG 273 Item 6 ) --------------------------------------------- [12/5/97]
Subject: Headaches Ahead -- Cadence No Longer Supports The GCC C Compiler
From: Jim.Avant@Sciatl.COM ( Jim Avant )
Hi John,
As an FYI on your gcc thread, Cadence will no longer support anything but
Sun's C compiler in the future for PLI interfacing. We've been using gcc
for years and are having to purchase (aargh!) Sun compilers.
- Jim Avant
Scientific-Atlanta
( ESNUG 273 Item 7 ) --------------------------------------------- [12/5/97]
Subject: ( ESNUG 270 #6 271 #2 272 #7 ) I Miss The SOLV-IT Puns!!! :(
> It was my intent to get the opinions of others on this subject, allowing
> me to see if I was being absurd in my feelings towards the new list's
> style. I know that many may prefer an information-intensive approach to
> the list, and if they are the majority, then great, let them "have there
> cake and eat it too". But if many people felt that a bit of fun helped
> the list, then maybe a small changes to the list could improve it for
> everyone. A good example is when Catherine mailed that hilarious "Phrases
> you would overhear if a Klingon was on your software team", which I have
> posted on my cubicle wall.
>
> - Ted Boydston
> Harris Government Aerospace Systems Division
From: Catherine Starr-Young <csy@synopsys.com>
Ted,
Thanks for the kind words. Trying to find the best way to do the SOLV-IT!
SCOUT has been just one of the many challenges I have had since starting my
job at Synopsys. I love puns and have many friends who use this great wit
to brighten my life. As I become more comfortable with my role at Synopsys,
I do hope to instill more humor into the SOLV-IT! Scout, as I agree that
reading dry, technical information can be, well, just plain boring.
I'm also glad you appreciated my Klingon contribution. I, too, have this
hanging outside my cube and am even learning how to pronoun the Klingon
words. I was a little nervous about this first attempt -- and rightly so,
since I received several people who were complained about this and even a
couple or people who unsubscribed from the list. It seems that you cannot
please everyone.
I do want you to know that I did not take your comments as a personal
attack on the job I'm doing, but rather as a way to improve the quality of
the Scout. I appreciate your comments and support -- and I will see what
other tidbits I can add in the future to make the SOLV-IT! Scout a valuable
and enjoyable tool for you.
- Catherine Starr-Young
Editor, SOLV-IT! Scout
( ESNUG 273 Item 8 ) --------------------------------------------- [12/5/97]
Subject: ( ESNUG 271 #6 ) Infinite Loops During Designware Mapping !!
> We ran into infinite loops during Designware mapping for some of the
> designware component (DW01_incdec, DW01_GP_SUM) of 97.01 and 97.08.
>
> Our current workaround is dont_use them from Designware library, and I am
> waiting for more information from Synopsys. However, I want to know if
> any designers have seen the same problem or any other workaround.
>
> set_dont_use (standard.sldb/DW01_incdec)
> set_dont_use (standard.sldb/DW01_GP_SUM)
From: "Yuan (Steve) Hwang" <hwang@eng.adaptec.com>
John, here's a follow-up to this DW infinite loop problem.
The infinite loop is caused by some area optimization that Design Compiler
does by default. This problem has been fixed for the next release of DC
(1998.02). In the meantime, there are two workarounds:
1. Don't set_wire_load for the top level
2. Don't use the 'rpl' implementation of the DW01_incdec.
set_dont_use dw01.sldb/DW_incdec/rpl
set_dont_use standard.sldb/DW01_incdec/rpl
(There is nothing wrong with this implementation. It is just that
the area optimization algorithm is more sensitive to the structure
of this implementation.)
Regards,
- Yuan (Steve) Hwang
Adaptec
( ESNUG 273 Item 8 ) --------------------------------------------- [12/5/97]
Subject: Dc_perl Instantly Dies On The New Solaris Operating System
> I have a very quick question concerning the dc_perl script which Steve
> Golson wrote sometime ago in ESNUG 259. Since I've moved to the
> ULTRASPARC1 and at the same time upgraded to using the Solaris
> operating system, I have been unable to run dc_perl. I get:
>
> % dc_perl
> dc_perl version 0.001
> Thank you for using dc_perl.
> %
>
> That is, dc_perl dies the moment it starts.
>
> I'm curious if you have experienced this problem or are aware of any other
> people with the same problem and if you have any idea why this problem
> exists.
>
> - Branislav Cenanovic
> NORTEL (Northern Telecom)
From: <sgolson@trilobyte.com> Steve Golson
John,
Yes, the current version of dc_perl has a problem running under Solaris.
I've got a version that works, just barely, and I plan to release it within
a month. I'll let you know when it is available from my ftp site.
- Steve Golson
Trilobyte Systems
( ESNUG 273 Item 9 ) --------------------------------------------- [12/5/97]
From: Diego Coste <diegoc@olymp01.grenoble.hp.com>
Subject: Anyone Out There Ever Create An Xemacs For dc_shell Scripting?
Hi John,
As a new (but intensive) writer of dc-shell scripts, I'm wondering if
anybody has ever found (or created) an Xemacs dc-shell editing mode (with
highlighting, auto-indent, ...)
- Diego COSTE
Hewlett-Packard Grenoble, France
|
|
