In ESNUG 166, John Cooley wrote:
>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!)
--- --- --- ---
From: kustiner@hwcae.az.honeywell.com (Dan Kustiner)
ANIMAL KILLER !!!! YOU SHOULD BE ASHAMED OF YOURSELF, BOASTING ABOUT
SOMETHING LIKE THAT OVER A PUBLIC MEDIUM. HOW WOULD YOU LIKE IT IF THEY
DID THE SAME THING TO YOU OR SOMEONE CLOSE TO YOU ???!
- Dan Kustiner, Member of 'People for the Ethical Treatment of Animals'
Honeywell
--- --- --- ---
From: Dave Chapman <dchapman@well.sf.ca.us>
Hmmmmm. . . first, we had the term "downsizing", and them "rightsizing",
and now you give us "culling". Pretty hard-core, I'd say.
- Dave Chapman
( ESNUG 167 Item 1 ) ---------------------------------------------- [12/93]
Subject: (ESNUG 165 #3 ESNUG 166 #2) "DC Expert and DC Professional"
> 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: [ Synopsys R & D ]
The answer is simple: DC Professional handles an arbitrary combination
of clocks as long as they have the same period. Each clock may have
just two edges, but there is no restriction on where the edges must be.
- Synopsys R & D
( ESNUG 167 Item 2 ) ---------------------------------------------- [12/93]
Subject: (ESNUG 165 #4 ESNUG 166 #1) "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 ?
From: [ Synopsys Corporate Applications Engineering ]
When a latch is transparent, a path from Q back to the D input will cause an
asynchronous loop. If the return path is inverting, the circuit oscillates
when transparent. If it is non-inverting, it latches. The loop is truly
inherent in the circuit. If the test methodology is full scan, meaning,
combinational ATPG is used, it is not possible to predict the state of
such a loop. As a result, the loop must be broken somewhere. This "break"
introduces an unknown state on at least one pin of one cell. The best
approach is to use set_test_isolate to specify the exact location for
optimum fault coverage. Otherwise, check_test will select a location
automatically, and this location is not guaranteed to be optimum. It can,
in fact, cause other scan rule violations because the state of dependent
logic can become unknown.
One frequently found circumstance where loops around latches exist is due
to the style of RTL which is used for synthesis. The results can be improved
by changing style. If multiple nested if-then statements are used to derive
the conditions under which the latch is updated, the innermost condition will
become the enable, and all outer conditions are used to determine whether
to select Q or update data to feed the D input of the latch. By modifying the
synthesized RTL to have a single signal which permits latch update, and
deriving the signal from all nested conditions, the loop can be eliminated,
and the resulting logic will be faster and smaller.
Example:
if (condition1) then
if (condition2) then
if (condition3) then
latchQ <= data_in;
end if;
end if;
end if;
can be written:
enable <= condition1 and condition2 and condition3;
if (enable) then latchQ <= data_in;
end if;
If this is the circumstance in the design in question, the end result is
a circuit with NO combinational feedback loop, faster, smaller logic, and
improved testability.
- [ Synopsys Corporate Applications Engineering ]
--- --- --- ---
>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.
From: Paul Zimmer <prz@hprnd.rose.hp.com>
Actually, you don't even have to insert any extra FF's. ANY output from a
flop ALREADY on the scan chain will do the trick. In fact, you can mux
around an entire bus full of latches with a single signal from a scanned flop!
I suspect, however, that this could lower test coverage down-stream, since
the mux outputs are not individually controllable. Also, it loads the signal.
So, I tend to spread them out a bit.
- Paul Zimmer
HP-Roseville Networks Division
( ESNUG 167 Item 3 ) ---------------------------------------------- [12/93]
Subject: (ESNUG 166 #6) "A Workaround For The Licencing Wars"
>>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.
>
>All that it takes is to get all of the Synopsys users to put the dc_shell
>command:
>
> remove_license HDL-Compiler /* Note the use of upper-case and 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, 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.
From: [ "Managed" into Remaining Anonymous ]
John - because of my overly paranoid management, please keep me anonymous.
I don't know if the verilog part of Synopsys works different than the VHDL
part, but as the replies from Synopsys itself point out, the VHDL compiler
license is required by the design compiler to do high level optimizations.
As Dave points out "the vast majority of the time is taken in tasks other
than read/write". This is exactly why his "fix" dosen't really fix the
problem. I can release the license as soon as I do a read on the file, but
as soon as I try to compile it takes the license back. Then it proceeds to
keep the hdl license during the entire compile time (which is where almost
all the time is spent), even after it is no longer needed. That is why
people have been complaining about needing hdl licenses for each compiler
license. The longest part of the process keeps licneses locked up after it
is finished using them.
The replied point is still valid, and good practice, but I don't feel that
it will help with the real root problem. Synopsys still needs to do a
much more appropriate job of managing the licenses (from a user
perspective, not from their marketing perspective).
- "Managed" into Remaining Anonymous
( ESNUG 167 Item 4 ) ---------------------------------------------- [12/93]
From: wpcallah@rwasic17.aud.alcatel.com (Paul Callahan)
Subject: Test Compiler Happily "Plays" Between Two Clock Domains!
John, using Synopsys (and VHDL), presently I'm attempting scan insertion of
a multi clock device. Know what? Test Compiler isn't set up for multi
clocked devices! It happily routs scan chains from one clock domain to
another and back. No worry about setup and hold -- doesn't even recognize
there is a problem!
So, I'm interested in what others have done. Talking to my vendor, I might
think no one has done this before.
- Paul Callahan
Alcatel
( ESNUG 167 Item 5 ) ---------------------------------------------- [12/93]
From: stallmann.pad@sni.de (Juergen Stallmann)
Subject: Synopsys "Ghosts" Haunting Our CPU 10 Minutes AFTER Quit Or Kill
We are struggling with a quite serious "ghost" problem on our SPARC2. They
are equipped with 128 MB and 500 MB Swap as a local swap_file. When leaving
Synopsys (by either quit or kill), the CPU gets heavily loaded for a few
minutes (up to 10 minutes). During this time nothing else is running, no
cursor, no clock, no nfs-daemon, no license-server etc. This means, other
Synopsys-jobs that are going to read or write files on any disk connected to
this system are crashing. Even jobs, not working on these disks get in
trouble, as one of these SPARCs is our license_server.
Please! Does anybody have an idea to solve this problem ?
- Juergen Stallmann
Siemens Nixdorf
|
|
