> ... For the past 6 years, I've always put together the ESNUG on
> a cheesy 386 CPU, 33 Mhz, 8 Meg RAM, Windows 3.1 PC clone. Two days
> ago, ... I suddenly heard a very weird whine, followed by some
> cracking/poping noises, ... suddenly the monitor went black! ... a
> small cloud of black smoke came out of the *side* of my monitor! ...
> So now I'm suddenly thrust, against my will, into the PC market.
>
> - John Cooley, the ESNUG guy
From: danlutes@crystal.cirrus.com (L. Daniel Lutes)
John,
As a retailer of used computers pointed out to me when I complained about
a product he'd sold me, it is always a mistake to let the smoke out of
an electronic component. If you'd had the presence of mind to capture
the smoke that came out of your monitor, you might have been able to
re-inject it and salvage the montor. Alas, I fear that you like I were
probably too startled by the betrayal of technology to think about that
at the time. Happy shopping!
- Dan Lutes
Cirrus Logic
---- ---- ---- ---- ---- ---- ----
From: chase@udslaz.sps.mot.com (Mark Chase)
John,
What? You forgot to get the NOSMOKE.COM option on your computer? Shame!
- Mark Chase
Motorola
( ESNUG 279 Item 1 ) ------------------------------------------------ [2/5/98]
Subject: Looking For A User-Friendly GUI Revision Control System
> I have a friend who works on a big project and would like to get a user
> friendly graphical revision control system program to manage his
> project. Does someone know any good one?
>
> - Steven Twu
> Cirrus Logic
From: Andrew Evans <evans@best.ms.philips.com>
We use "vguide" from Lucent Technologies Nuernberg. It works very well for
controlling large designs using multiple designers.
I have no conection with Lucent. I just like the product.
- Andrew Evans
Philips Medical Systems
---- ---- ---- ---- ---- ---- ----
From: Pratix Parikh <pparikh@aanetcom.com>
There are several products available depending on your OS. For PC, there is
PVCS, MKS-RCS and CS-RCS. You can download them from www.shareware.com.
The first 2 are quite expensive -- about $500 a copy. CS-RCS is simple and
costs about $50. We use CS-RCS and are quite happy. It supports both WinNT
and Unix OS that we use here.
- Pratix Parikh
AANetcom, Inc. Allentown, PA
---- ---- ---- ---- ---- ---- ----
From: gogo@netcom.com (R. Mark Gogolewski)
We (at Denali Software) use a system from Clio Software. I believe that the
Web address is http://www.cliosoft.com. The tool works very well, and the
GUI is usable right out of the box; I've myself never bothered with the
documentation.
- Mark Gogolewski
Denali Software
---- ---- ---- ---- ---- ---- ----
From: Pam Rissmann <pam@magdesigns.com>
I use a tool that came out last year called SOS, made by Cliosoft. It's
graphical and easy to use (has a command line interface too though). Some
of my VHDL and Verilog clients use it too, and it's helped them out a lot.
It's based on RCS; in fact, you can import in existing RCS databases. But
you can also do a lot more than RCS. The website is http://www.cliosoft.com
- Pam Rissmann
Magenta Designs
---- ---- ---- ---- ---- ---- ----
From: James Goeke <goeke@kodak.com>
Check out SOS from Cliosoft. I believe it is www.cliosoft.com
- James Goeke
Eastman Kodak
---- ---- ---- ---- ---- ---- ----
From: Brian Rogoff <bpr@shell5.ba.best.com>
You might want to look at CVS, which is good, free, has several GUI based
front ends, import of RCS and SCCS, web browsing interfaces, and much
more. See www.cyclic.com
Also, there is a newsgroup, comp.software.config-mgmt, devoted to these
kinds of tools, and that might be a good place to go to get more info.
- Brian Rogoff
( ESNUG 279 Item 2 ) ------------------------------------------------ [2/5/98]
From: rramsay1@ford.com (Rodney Ramsay)
Subject: Making Your Own Home Grown Man Pages For PrimeTime
John,
I used to be mad that Synopsys On-Line Documents didn't have man pages for
the commands in PrimeTime. Now I feel a lot better. To make this happen,
I used the following trick:
pt_shell> help * > help.txt
Then use this perl program to awk out some man commands.
#!/usr/local/bin/perl
while(<>) {
if(m/^\s*(\S+)\s+/) {
print "man $1 > $1.txt\n";
}
}
Now, include this output in pt_shell to create all the text versions of
the man files. Put the files in some directory that everybody can access
with their web browser. When you read the directory as a file you see
hot spots for each command and tah-dah, some useful documentation.
Of course you can always use
man -M $SYNOPSYS/doc/man <some command>
in Unix but not with the same flair.
- Rod Ramsay
Ford Microelectronics Colorado Springs, CO
( ESNUG 279 Item 3 ) ------------------------------------------------ [2/5/98]
Subject: ( ESNUG 275 #1 ) Screw Module Compiler; Use TeraPath Instead!
> I am completely impressed with the Synopsys Module Compiler. You can tell
> it isn't an in-house Synopsys job (was acquired thru Silicon Architects).
> The language that is used to describe the operations is a cross between
> Verilog and C, with a smattering of extra operands and syntax. However,
> this is a small annoyance and takes a few hours to get the hang of coding.
> The speed of the thing is *fast*, where compiling up a FIR or multiplier
> was in the order of 2-3 minutes tops (including reports).
>
> We evaluated it here for a "math-intensive" project I'm working on. This
> tool is cool. We came up with 8 different variants of a mammoth pipelined
> multiplier (*really wide*) within a week including 1 day of instruction and
> a day of learning curve. Something like this would have taken months to
> develop and we were able to go back to management and say "here's a matrix
> of size vs. performance with our various implementations". Never saw a
> manager's jaw drop so fast when we were able to provide a real close gate
> count and performance eval. That really helps when the architects have no
> clue as to how fast we should run our part to get the math op results back
> in X time. The verilog netlist that MC spits out actually has comments
> in the code where the basic operations are taking place. Way cool for
> debugging! The only drawback is that I wish the input code was more
> behavorial so the design could be pushed thru formal verification, assuming
> that the formal tools available today could deal with it. Neato stuff.
>
> - [ "Intel Inside" ]
From: [ A "CAD" At LSI Logic ]
John,
Saying I'm from LSI Logic is OK, but don't use my name if you publish this.
To twist an infamous quote from a former EDA CEO -- if Synopsys put
"DogFood Compiler" on the market, would users be sending ESNUG testimonials
about how tasty the gravy bits are?
Module Compiler used to be the SciArc Datapath internal tool. Even though
Synopsys bought SciArc and is trying to reposition them as a Design Reuse/IP
vendor, deep down they really truly want to be the "standard" ASIC vendor.
This is the old EDA vs. ASIC CAD argument with a twist. Do you think that
Synopsys really wants us independent consultants and ASIC vendors adding our
value to silicon; when they have the opportunity to make everybody produce
the same lousy gates in all designs using Synopsys tools, IP, and designers?
The following is an evaluation of Module Compiler from Synopsys w.r.t
the recently announced Tera Systems' TeraPath (http://www.terasystems.com)
integrated into the LSI Logic FlexStream datapath tool suite
(http://www.lsilogic.com). In it I discuss the libraries, synthesis,
wireload models, timing budgeting, and HDLs.
Libraries
----------
Library support is always important for new tools - for datapath tools
this is even more critical. Any of us who have done datapath designs
know that you absolutely need custom cells in-context optimized for
speed/density. Hell - us real designers don't even use standard cells,
we design the whole chip at the transistor level for breakfast. So how
can this crowd of talented custom designers be drooling over Module
Compiler, when it uses the same lousy standard cell libraries that
Design Compiler uses?
Here at LSI Logic we have an entire world of custom circuit engineers -
your whole chip can be built with custom libraries if you want. I have
lost track of how many customer specific libraries have come through
this shop. Of course we will charge you massive NRE and long cycle
times to do this. But hey, we figure that you know that custom IC
design is 2-3x faster/smaller than what everyone else gets in the
standard library - so you must figure the time and money is worth it.
After a while I got tired of seeing yet another multiplier or adder
cellset from yet another guy who read yet another conference paper.
Why not put these same circuits guys to work building a datapath
library that everyone can use? The only way to do this was to write
parameterized netlist/placement generators to control the cell usage -
this way everyone can get the same custom IC result with a lot less
time and money. The problem was to fit this into the standard EDA/ASIC
flow, so that you would use it. We could wait around for Synopsys to
realize that every ASIC vendor wants to have their own datapath
libraries tied into Design Compiler or we could do something else...
In this industry the real innovation is in startups - which is where
Tera Systems' TeraPath came in. Tera Systems could care less about
selling you IP that another of their divisions designed (acquired),
instead they offer a standard customizable interface for LSI Logic to
plug in our datapath libraries. You can then concentrate on writing
the RTL at a higher level, the adders are just another library element
that gets selected like any other gate. And John - if you think you
can design a better adder than LSI Logic, then pay us to do the custom
cells and then plug the whole thing into TeraPath as a GreyBox model -
and go back to writing the rest of your RTL.
So if I already have an internal datapath generator that guarantees the
usage of my custom cells, then why on earth would I make them available
in the Design Compiler library just so that Module Compiler could find
them? Since Module Compiler came from SciArc (a possible competitor),
I would first have to concede that their macrofunction selection is
better than mine. I just cannot acknowledge that they are better
designers than we are, call it pride in LSI Logic if you will.
Sure they might give me a databook of functions I need to implement.
The problem is that datapath cell design must be done in context. I
need to know what the drivers and wire loads are - the very things that
are not guaranteed in Module Compiler because it does not do
placement-based synthesis. So if I was going to support Module
Compiler, I would have to use conservative reliable standard-cell
design practices. I cannot guarantee reliability/optimality on a
custom cell if you use it for an unintended purpose, so I will not let
them have it - which means you do not have it.
Of course if I do that then I have to listen to Synopsys whine to you
about how it is our fault rather than their fault when you cannot meet
timing. Where does the request for libraries end? Synopsys is asking
us to provide optimal libraries for Design Compiler, then DesignWare,
then Advanced DesignWare, then Design Compiler '97, then Power
Compiler, then Behavioral Compiler and now Module Compiler (yet we
still have DesignWare)?. Finally in '98 they are touting multi-bit
synthesis, and they tell you to complain to LSI Logic to put multi-bit
cells in the library. Guess what Synopsys - we dropped those cells
years ago because Design Compiler would not support them. I am
bringing them back for TeraPath to use though.
Tera Systems' TeraPath is much easier on us here at LSI Logic because
of the way in which they use standard shell scripts and libraries to
call our custom datapath compilers. This is exactly how the EDA/ASIC
vendor relationship should work.
Library Characterization
------------------------
I get calls all the time from RTL designers asking how fast is this or
that adder configuration and BTW can I tell them which one they should
use in their design. The truth is I don't know even if I designed the
damn thing - it all depends on the context of your RTL and physical
design. We usually end up guessing on the conservative side, because I
have no idea what the possible path permutations are - I only have so
many fingers to keep track of all these datapath operators.
When LSI Logic figured out in the 80's that characterizing the gates
and abstracting the transistors would change the magnitude of the chip
design problem - a whole new EDA industry took off to the point that we
dropped out of the synthesis/simulation/schematic/STA business in the
90's. Now with Tera Systems, LSI Logic is about to revolutionize the
whole EDA business again. As we close out the 90's I see tremendous
computing capability in our intranet going to sleep, so why not put it
to work characterizing RTL modules and thus abstract out the gates?
Since Tera Systems' TeraPath tool does everything using characterized
RTL modules, your datapath designs can be completed orders-of-magnitude
faster. Would you like to see an RTL signoff model that treats
synthesis/place/route as a backend constrained process? With the
current Synopsys tools I feel like I am at Wimbledon, what with all the
chaotic/iterative random logical/physical ping-ponging that goes on now
in our design centers. Of course my VP's want me to say that LSI Logic
has the best timing closure methodology available with todays synthesis
tools. Thankfully I get to work on new tools/circuits that you will
use for your next design tomorrow.
Looking back at Module Compiler it still uses gate level characterized
libraries to do synthesis. While Synopsys claims Module Compiler is
better than DesignWare because it uses datapath synthesis rather than
random logic synthesis, wasn't the same claim made for Designware vs.
DesignCompiler? Anyways - I cannot get excited about what synthesis
algorithm they use, for submicron datapath designs I am more concerned
about what wire load model they use since that is where all the delay
problems are.
Placement-Based Module Synthesis
--------------------------------
With Module Compiler - you still have to do the module-level iterations
manually to get the optimal gate-level synthesis result, as there is no
characterization database of the modules. The major architectural path
enumerations are left up to you, yet the only feedback you have is a
gate level and statistical wire timing report. I think most of us just
want to know how fast an adder really will be in the back-end, not how
fast the gates are inside it when they drive the wrong load.
Module Compiler does not do any floorplanning or even gate-level
placement; though it does put out a non-standard placement "hints" file
that no ASIC/P&R vendor can interface with. Since it is not doing any
actual placement it has to use something for a wire load model; SciArc
"integration" into Synopsys means they use the same fanout-based
statistical wire models that Design Compiler uses. I would love to see
an ESNUG discussion about how wonderful those models are! Any of us
that have actually done datapath designs know that the combination of
long/short data/control wires for the same fanout is impossible to
predict with statistical fanout based models.
In contrast, TeraPath automatically does a timing-driven floorplan to
ensure that the LSI Logic gate-level synthesis scripts are given the
exact data/control wire load and I/O delay. LSI Logic gate-level
datapath generators can do in place buffering/sizing because we
optimized them to simultaneously place and synthesize before detailed
physical design is performed. The combination of TeraPath module level
placement/synthesis and LSI Logic gate level placement/synthesis can
only be enabled with RTL rather than gate level characterization. Of
course LSI Logic adds a Datapath Compiler to transparently merge all
this into your physical design database.
BTW does anyone on ESNUG have an idea of what to call this integration
of logical/physical synthesis? I thought of placethesis but nobody
seems to like that term. Anyways on to the next topic...
Timing Budgeting
----------------
The TeraPath module-level logical/physical synthesis combined with the
characterized modules from LSI Logic gives you DEAD-ON accurate timing
budgets for every I/O port so as to tightly constrain gate-level
synthesis to a known realizable solution. LSI Logic's use of TeraPath
does not replace Synopsys Design Compiler - TeraPath just tells it
exactly what it needs to do to meet timing in a single run.
Verilog RTL HDL is by its very nature, a language that encapsulates
structure; every if-then-else, always block, case statement, bus
operator etc. is describing a relatively simple module. The value is
added in the architectural design - by connecting these simple RTL
modules together to create IP and communicating the synthesis/placement
requirements downstream to us. As a senior designer I do not have time
for someone else to be screwing with my design because they do not know
any better - but I guess junior engineers have to start somewhere.
Tera Systems has solved this problem by giving me a tool to properly
partition and budget these RTL modules to create efficient hierarchical
synthesis/placement constraints.
How many SNUG papers have we seen for massive scripts to do hierarchical
characterized compiles? SNUG97 had a whole session on this very topic, and
by popular demand so will SNUG98! For datapath designs this is a serious
problem: the hierarchy is usually combinational modules with deadly
control/data snaking paths -- or they are internally pipelined instead of
registered at the boundaries. TeraPath handles these issues automatically,
the module level timing engine is used to optimize module selection across
the control/data boundaries resulting in a realistic timing budget.
Synopsys does not get it - a datapath design style is the exact opposite of
the design style Design Compiler wants us to use for optimal synthesis. How
can Module Compiler solve this problem if it is a specialized datapath tool
which leaves the control logic for Design Compiler? If am responsible for
selecting the micro-architecture then I have to be self-aware of timing
budgets, but I cannot do that when lacking critical information about I/O
delay that has not been created yet.
Another HDL and design flow?!
-----------------------------
This leads to the next problem which was previously discussed here -- Module
Compiler uses a non-standard, proprietary HDL that cannot be directly
simulated or formal checked. This is a huge problem for me, as I am
essentially flying blind when I write the Module Compiler code. I feel
sorry for anyone writing control logic in MCL in an attempt to solve the
control/data timing problem. Sure Module Compiler will guarantee correct
by construction output, but I do not trust myself to get the control logic
equations correct when using an unverifiable language. We all know that
control logic is the toughest verification problem -- adder verification
is easy.
Do we really need another HDL regardless of how easy Synopsys says it is to
learn or how easy it is to register for the Synopsys training class? As has
been discussed in ESNUG, training and design services are the future profit
center for EDA vendors -- what better way to get all that money than invent
your own HDL! How many other EDA/ASIC vendors will standardize on support
tools for a new HDL? I thought the Verilog vs. VHDL religious wars have
settled with most people realizing they have to be bilingual (unless your
work is classified). I refuse to be trilingual, though -- enough is enough!
If Module Compiler can output an equivalent synthesizable/simulatable Verilog
RTL module -- doesn't this indicate that it was possible to write the micro
architecture of the datapath using Verilog RTL to start with?
Conclusion
----------
TeraPath supports the standard synthesizable RTL that fits into the ASIC
based sign-off flow, and does not change your use of RTL formal/functional
/accelerated verification tools in any way. Tera Systems also supports
standard library/placement interfaces that automate the gate-level
implementations that LSI Logic's custom designers have previously been doing
manually. Many of us here at LSI Logic find the marriage of standard top
down design with custom bottom up physical design to be the coolest thing.
I have used TeraPath's RTL-based module-level logical/physical synthesis for
a while now on datapaths. I can routinely do designs by myself several
orders-of-magnitude faster than the custom-design teams, and yet achieve
equivalent or better results. Finally datapath design is not limited to
expensive side projects using niche tools that do not fit in well with the
rest of the design flow.
- [ A "CAD" At LSI Logic ]
( ESNUG 279 Item 4 ) ------------------------------------------------ [2/5/98]
From: Srikant-reddy.MODUGULA@st.com (Srikant R Modugula)
Subject: Identifying Clock Trees As "Clock" Startpoints In Prime/DesignTime
Hi John,
Here is something which I have asked Synopsys for and want to share with
other users. I wish Synopsys provides the feature soon. Design:
_________
| |
| _____ |
| | DFF |_|__ NET_A
----|>|_____| | |
CLK_A | | |
|_________| |
Block "A" | _______
| NET_C | |
| ->-| |
| | | |
| | | |
| | |_______|
| _______________ | Block "C"
| | _______ | |
|->-|-| Comb. |_ | |
| | Logic | | | |
| |_______| |->-|->-|
| _____ | |
CLK_B | | DFF |___| |
----|>|_____| |
|_______________|
Block "B"
Premises:
1/ CLK_A and CLK_B are derived from SAME clock "phi" thru a clock-tree
network.
2/ Between CLK_B and "DFF" there is another clock-tree.
3/ The path "CLK_A - NET_A - NET_C" is longer than "CLK_B - NET_C"
4/ I dont (want to) know the instance names of "DFF" in Blocks A/B
Problem: Now I want to report_timing, from "CLK_B - NET_C" ?
I try :
report_timing -del max -from CLK_B -thr NET_C
--> no paths since the path starts at "clock pin" of "DFF";
not from CLK_B
report_timing -del max -from phi -thr NET_C
--> gives path from "CLK_A - NET_A - NET_C" since it is longer.
How can i pin point this path, using a report_timing command?
Now, the only (brutal!) way I found to get the path from "CLK_B to
NET_C" is to use report_timing -del max -max 100 -from phi -thr NET_C
--> hoping that "CLK_B - NET_C" is in those 100 paths I do text
processing to get that path.
Note that the "clock tree" from "phi" to "CLK_B's DFF" is understood
by DC/PTime with set_clock_skew -propagated command and this insertion
delay is considered while reporting paths from "CLK_B's DFF"! DC/PTime has
the information; it now needs to use it for understanding the command:
report_timing -del max -from CLK_B -thr NET_C
Is there any other/better way anyone can think of?
Did anybody else face this kind of problem?
Does anybody else want a solution for this, from Synopsys?
- Srikant R Modugula
SGS-Thomson Microelectronics, New Delhi, India
|
|
