Big Day Today! Today's the e-mail absolute DEADLINE to get those proposals
in to speak at the next upcoming SNUG meeting in March '94 in California!
Send those proposals to this year's SNUG '94 Grand PooBah, Willis Hendley
at "willis.hendley@east.sun.com" or if you're having problems getting e-mail
to him send it to "jcooley@world.std.com" and it'll be forwarded.
Today's also a big day for the sheep at my farm: today's Winter Culling.
Because you have to buy grain and hay to feed sheep over the winter, most
sheep farmers do a decisive thining of the herd with the unlucky ones being
sent "to visit the market" this time of year. (And you just worried about
losing your job in your company's next layoff!)
Get those SNUG '94 proposals in NOW or wait until next year to speak!
- John Cooley
the ESNUG guy
(and sheep farmer, too!)
( ESNUG 166 Item 1 ) ---------------------------------------------- [12/93]
From: lsto@caddy.tdata.no (Lech Slawomir Tomczak)
Subject: (ESNUG 165 #4) "A Test Compiler Question"
> When I set the latches in my design to be transparent using the "set_scan"
> command, it introduces combinational feedback loops. We are using the
> 'full_scan' test methodology and 'multiplexed flip-flop' as our scan style.
>
> Any ideas on how to fix this problem ?
Hi John,
It happens very often that making latches transparent introduces feedback
loops, specially when using bidirectional I/O pads.
To break the loop I would suggest inserting extra so-called shadow FF's,
which would hold the latch value during test. Inputs to these FF's should be
connected to inputs of the latch. Outputs should be mux'ed with latch
outputs and controlled with a test mode signal.
Example: set_test_hold TM 1
----------------------------------- I/O Pad
| Latch
| ______ |
| | |
|--|D |------ LUMP OF COMBINATIONAL LOGIC
| | | |
| | | | |
| | | | ----- |
| ------ ---| | |
| | MUX |-----------
| Shadow FF ---| |
| ------ | -----
| | | | |
--|D |------ |
| | TM
CLK ----| |
| |
------
Make sure that latches in the feedback loop are not set 'scan false'!
Remember never to set 'scan false' attribute on a latch in the library.
Instead set 'scan false' on all the other latches which should be transparent.
Otherwise Test Compiler will not understand the logic and will still
assume latch open and keep inserting X'es on the other side of MUX. (This
may be a significant problem if you use wide bidirectional busses.)
We spent over two weeks to make Test-Compiler understand this logic !!!
- Lech Slawomir Tomczak
Tandberg Data Storage, Oslo Norway
( ESNUG 166 Item 2 ) ---------------------------------------------- [12/93]
From: cindy@zoran.hellnet.org (Cindy Eisner)
Subject: (ESNUG 165 #3) "DC Expert and DC Professional"
in post 165, item 3, synopsys marketing says:
> [DC Professional supports multiple clocks of the same frequency]
john, what are multiple clocks of the same frequency? do you mean multiple
clocks of exactly the same waveform? or do you mean multiple clocks of the
same frequency but with rise times shifted? or do you mean multiple clocks
of the same frequency with edges matched, one positive, one negative?
from what i know of the old algorithm (2.2), the only thing that was correctly
supported was multiple clocks of exactly the same waveform. or does dc prof
use an algorithm somewhere between that of 2.2 and that of dc expert?
- Cindy Eisner
Zoran Microelectronics
( ESNUG 166 Item 3 ) ---------------------------------------------- [12/93]
From: dan@qlc.com (Dan Pinvidic)
Subject: HDL Compiler 3.0a and Latches
In going to version 3.0b we could not infer latches with async resets. In
reviewing the 3.0b "Release Notes" (page 28) it is stated that HDL Compiler
version 3.0a was NOT forward or backward compatable with version 2.2 or 3.0b
when infering latches. It seems to me that a larger majority of designs
would perfer the ability to infer a resetable latch without the additional
gating.
I would rather use a "synopsys_directive" (ie: //synopsys latch_async_reset)
than be required to set an "undocumented" variable for the 3.0a compatability
mode. Does anyone have any additional background or comments on this change?
- Dan Pinvidic
Q-Logic corp.
( ESNUG 166 Item 4 ) ---------------------------------------------- [12/93]
Subject: (ESNUG 164 #2, 163#6 165 #5) "Why Design Compiler Comes Up Short?"
>>> I take a simple design, say register/adder/register, create clock with
>>> period 20 ns and compile. I get a circuit that runs at 26 ns. With the
>>> same source code, I relax the period to 40 ns and compile. I get a circuit
>>> that runs at 43 ns. Obviously the compiler can make a circuit that runs
>>> at 40 ns, since it had successfully made a circuit that runs at 26 ns. Why
>>> does Design Compiler want to seemingly always come up short?
>>
>> What Design Compiler does is first optimizes your circuit to meet the
>> optimization constraints ... Then it fixes the design-rule constaints ...
>> The flaw which was ok during the first phase, is now hosed during the
>> second phase...
>
> In my design, it is the first phase that always comes up short!
--- --- ---
From: rjones@lagrange.amd.com (Robert Jones)
Try using a tighter constraint for the flatten and structure, then apply
the true timing constraint for the mapping.
- Robert Jones
AMD
--- --- ---
From: [ Synopsys R & D ]
There are several places in the tool where delay estimates are used during
optimization. At those points, the evaluated constraints may not correspond
exactly with the user-specified constraints. They may be within 10-20% of
the real constraints (depending on the delay-model, wire-load model, etc.)
For the simple CMOS delay-model, there shouldn't be any problems. This is
the reason for the hotline's suggestion to tighten constraints by a certain
factor in certain cases.
This is only an explanation of the problem (not a justification). We are
working on a couple of ideas to try to improve the correlation between some
of the internal estimates and the real constraint values. In the meantime,
designers can workaround this problem by tightening constraints by 10-20%
during the initial compile. They can follow-up with an incremental compile
with the real constraints to try to recover some area and give back some of
the delay (if possible).
- Synopsys R & D
( ESNUG 166 Item 5 ) ---------------------------------------------- [12/93]
Subject: A Comparision of Cadence Synergy with Synopsys Design_Compiler
> Is anybody out there using the Logic Synthesis package (Synergy) from
> Cadence? What do you think? How does it compare to Synopsys?
>
> - Wilbur Luo
> Cypress Semiconductor
From: bobh@oakhill.sps.mot.com (Robert Hoffman)
I've been using Cadence's Synergy for about a year now and have worked through
numerous bugs which seemed fairly basic. My exposure to Synopsys is not much,
but what I have seen suggests it is fairly robust (although it did crash my
system occasionally.) :)
The current rendition of the Cadence Synergy tool seems robust, I've been
using it primarily to synthesize Xilinx 3000 FPGA's (homebrew library) so
I have minimal exposure to area vs. speed issues. (Fitting in an FPGA is an
altogether different ballgame.)
My personal opinion, after the above basis, is that the Synopsys tool is
more capable. However, I had no success with the Cadence to Synopsis
Interface (CSI) under the framework (4.2.1a) whereas the Synergy tool is
wonderfully integrated (which kind of makes sense since it is by Cadence.)
This was one of the key issues in my particular endeavors.
- Bob Hoffman
Motorola
( ESNUG 166 Item 6 ) ---------------------------------------------- [12/93]
From: abdoo@adtaz.sps.mot.com (David Abdoo)
Subject: A Workaround For The Licencing Wars
In ESNUG 164 #3:
> And this still dosen't address one of the main aggravations, when the design
> compiler is finished with the HDL optimization IT SHOULD LET GO OF THE
> HDL LICENSE. Even if users accept the rational in the above referenced
> Synopsys note, there is no reason for the design compiler to keep the
> HDL license locked up.
John,
Whereas I agree that Synopsys should somehow be modified to wait for a
floating HDL Compiler License, rather than just die; and that it should
release licenses automatically that it isn't using; we've found a simple
solution.
All that it takes is to get all of the Synopsys users to put the dc_shell
command:
remove_license HDL-Compiler /* Note the user of upper-case and the hyphen */
after each and every 'read -f verilog' and 'write -f verilog' statement
in their dc_shell scripts. As it has been pointed out, the vast majority
of the time is taken in tasks other than read/write, so if every user includes
the above command in their scripts, (and if you have a reasonable number of
HDL licenses) it is very rare that enough users want a license at the same
time to cause anyone a problem. In fact, every time I have had a script
crash due to a lack of a license, it has been that we have a new user who
has not been educated on license sharing yet.
Note that this command can also be entered in design_analyzer, either from
the command line or somewhere in the menus.
As long as you have more than one HDL license for a small group, or a
reasonable ratio of HDL licenses to DC licenses, and you have cooperative
users, I think this should clear it up.
- Dave Abdoo
Motorola, Tempe AZ
|
|
