HOT GOSSIP THAT BECAME TRUE: For about two weeks I've been pelted by people
on ESNUG asking whether the rumor that Synopsys bought Logic Modeling Corp.
(LMC) was true. Well, it appears so. LMC is well known in the engineering
world for having over 12,000 commericially available libraries for both
hardware & software modeling of components for use in systems design. (They
provided both Verilog and VHDL models custom tailored to a wide array of
simulators plus hardware emulators.) LMC made about $37 million in '93 and
was in the process of going public with its stock when Synopsys bought LMC
with a stock swap of 2.6 million Synopsys shares currently trading in the
neighborhood of $45. (This translates to LMC being bought for ~ $120 million.)
From a business point of view, this was a major surprize in the industry.
With LMC being independent, it was seen as not favoring any one EDA company
over another and, as a result, was given help by most simulation vendors on
how to best model components with their simulators. This recent change has
caused many of the major simulator vendors and EDA related companies to
privately voice a collective expletive or two because they fear that Synopsys
will use this as an opportunity to promote its own VHDL simulator over
Verilog and other VHDL vendors. "You don't pay one hundred million dollars
for something that doesn't help you directly, hurts your competitors or
doesn't hopefully do both.", said one EDA corporate executive. Many EDA
companies have openly stated that they're now rethinking their relationship
with LMC and how they will approach the library modeling problem for their
own EDA software offerings in the future.
To these comments, Synopsys president Aart de Geus says: "Our objective is
to have the customer be able to use LMC's models with any simulator he or
she choses. We want LMC to continue supporting our competitors as they
always have. I know this sound like talk at this point so I suggest you
look at LMC 12 months from now and see if we delivered. Our intent is
very crisp on this: we want LMC to keep working with our competitors."
LMC has publically stated it will operate as a separate division of Synopsys
in Beaverton, Oregon and will be assuming the DesignWare aspect of the
Synopsys product line.
- John Cooley
the ESNUG guy
( ESNUG 171 Item 1 ) ---------------------------------------------- [1/93]
Subject: False Alarm on "Bad Gate Level Code" (ESNUG 170 #2)
From: daves@cirrus.com (David Sherman)
>Thanks for the responses to my posting about asynchronous loads. It appears
>that this behavior was induced by the target cell library I was using. Sorry
>about the false alarm.
From: jcooley@world.std.com (John Cooley)
>David, could you write up a little blurb on how you came to this conclusion
>so I can post it on ESNUG? (It's important to do follow-up on bugs so
>I don't get asked weeks later "What was the fix to ESNUG XXX?")
>
>Don't worry about the false alarm; we're all human last I checked. :^)
From: daves@cirrus.com (David Sherman)
OK, John, here goes on how I got the solution...
The asynchronous set/reset flip flop in our cell library had internal
gating that let's the reset override a simulataneous set. If you look at page
37 of the Synopsys Logic Synthesis 2 workshop documentation (Mar 1993,day 2)
it shows a similar thing.
Anyway, my first thought was that the fact that our cell being asymetric was
causing the behavior of not gating the "set" with the "data," because it works
logically with our cell (but it will cause glitches). However, after looking
at the above documentation (I didn't actually take the class) a person that
did take the class convinced me that it might be a bug in Synopsys. So I
posted the question. In the meantime, we changed the cell description to
symmetric (i.e. set and reset active at the same time is illegal), tried it,
and lo and behold, it worked OK. So I should have tried that first before
posting to you!
IN SUMMARY, asynchronous loads SHOULD work in Synopsys 3.0b. If you find that
it doesn't gate the "set" and "clear" to the DFF symmetrically, it could be
that the cell library that is to blame. (And depending on the internal logic
in the cell, it might be OK. It wasn't in my case.)
Thanks ESNUG readers for your patience!
- Dave Sherman
Cirrus Logic
( ESNUG 171 Item 2 ) ---------------------------------------------- [1/93]
From: Charles Wang <wang@ncrtory.TorreyPinesCA.ncr.com>
Subject: Yet Another Licensing Bug
Hi John,
Concerning the EE Times article about the Synopsys licencing bugs: EE Times
didn't cover it all. This is to report yet another a licensing bug.
Conditions for this bug are to mix using one FPGA Compiler license while
using many other licenses. The scenario is:
Someone is using FPGA compiler within design_analyzer or dc_shell
- and then -
someone else trys to analyze VHDL files by using "vhdlan -spc file.vhd"
Results in an error message (from vhdlan):
SPC_Error: All 'FPGA-Compiler' licenses are in use. (SEC-50)
If you reverse the order by doing the "vhdlan -spc file.vhd" first and then
start to use the FPGA compiler, you get:
Error: All 'FPGA-Compiler' licenses are in use. (SEC-50)
The current users of this feature are:
wang at sv013, started on Thursday 1/6 at 9:39
Information: Compile terminated abnormally. (OPT-100)
Looks like you always get this with multiple licences.
- Charles Wang
NCR Corp.
( ESNUG 171 Item 3 ) ---------------------------------------------- [1/93]
Subject: ( ESNUG 170 #5) "DC Uses NORs When It Is Better To Use NANDs"
>We have a problem that the Design Compiler loves to use NOR gates. In fact,
>it likes using NOR gates so much that it often uses them along with inverters
>where it could have just as easily used NAND gates. The problem, is that a
>series of NOR/NOT's is larger and slower than simple NAND gates.
>
>Does anyone know how to "encourage" DC to use NAND gates, other than just
>eliminating NOR's from the library?
--- --- --- ---
From: Gilbert Nguyen <nguyen@hpicc.dseg.ti.com>
John, I believe the simple use of the "PREFER" attribute on your library's
NAND gates should solve this problem.
- Gilbert Nguyen
Texas Instruments
--- --- --- ---
From: brad@hdls.COM (Brad Eltman)
Check the synopsys library and make sure that the Design_Compiler doesn't
think that NOR gates are really much smaller than a NAND or much faster. IF
the library is correct. Then you must have a borderline case where the NOR
is just a delta better to use in when the cost function determines the cost
of NOR + INVERTER vs NAND. In this case you might want to try using a wire
load model in which wire area is counted. This might (stress might) just
push the cost function to the NAND gates.
- Brad Eltman
HDLS
( ESNUG 171 Item 4 ) ---------------------------------------------- [1/93]
From: soroc@devnull.mpd.tandem.com (Scott Smith)
Subject: Synopsys Bug Alert - write_script
To All ESNUG Readers;
This is to alert all ESNUG subscribers to a bug/defect in the 'write_script'
command. Synopsys has confirmed that this is indeed a bug with the
'write_script' command, and that there is no fix or patch for it until the
release of their V3.1 software, STAR #15009 addresses this defect. The work
around is to parse the output of the 'write_script' command prior to using
the data in a Synopsys job.
The function 'write_script' is normally used with the characterize function
to write out the data that was created by the characterize run.
The following line is an example of a line written out by 'write_script':
set_driving_cell -cell ram -pin dataout<35> find(port,"TBusIn<71>")
^^^^^^^^^^^
The above line is not syntacticly correct because there are no double quotes
around that signal name "dataout<35>." (If all bus signal names are written
in the following naming convention, then synopsys accepts the line as
correct, no errors:
set_driving_cell -cell ram -pin dataout_42 find(port,"XB_data_42")
^^^^^^^^^^
WORKAROUND:
The following change to the above line (added double quotes "" to the
bus signal name) will make the line syntacticly correct, and thus will
work as expected in synopsys:
set_driving_cell -cell ram -pin "dataout<42>" find(port,"XB_data<42>")
^^^^^^^^^^^^^
There will soon be a script released to 'fix' the output of the synopsys
'write_script' command. Details to follow as development continues.
The following sample perl script corrects some of the problems found in
the 'write_script' output:
perl -pi.bak -e 's/-pin ([^" ]+) /-pin "\1" /g;' *.rcsr
Hope this helps!
- Scott Smith
Tandem Computers
( ESNUG 171 Item 5 ) ---------------------------------------------- [1/93]
From: [ Anon. ]
Subject: No VHDL ASIC Library Available For Synthesis.
Hi, John, (please keep me anonymous),
We just found out that our ASIC vendor will not release their new synthesis
library until June. We had been counting on getting it in January.
Maybe if I tell you what I think our options are, you could comment on
them. Maybe you can see other options.
1. Dump VHDL altogether and return schematic capture gate level design.
GOOD: Dont need synthesis library. Dont need to learn Synopsys and VHDL.
BAD: No behavioral simulation before schematic capture.
2. Synthesize with beta version libraries. Keep the modules so small that
we can comprehend the schematics generated, then manually modify as
needed.
GOOD: Still have behavioral simulation. Can reuse test vectors at gate
level (through translation).
BAD: Link between VHDL and gate level is weak. Beta library may cause
serious delays.
3. Just build a VHDL model, and test vectors. Forget synthesis altogether.
Manually create the gate level (using Mentor), based on the VHDL model.
GOOD: Eliminate modification/repair stage resulting from beta library.
Still have VHDL model and test vectors.
BAD: No link from VHDL to gate level. May take more time to manually
design gate level.
Is it true that some developers use VHDL models without synthesis? And why?
Thanks for your comments.
- [ Anon. ]
( ESNUG 171 Networking Section ) ---------------------------------- [1/93]
San Jose, CA, Xilinx FPGA/EDA Apps Eng. needed for Verilog & VHDL w/ sythesis.
Create design examples, app notes, etc. for Xilinx. e-mail: pam@xilinx.com
|
|
