[ Sometimes the stuff that people appear to be seriously promoting is far
more fun/bizzare than anything I could conjure up on the farm! Have a
happy Friday & don't take any wooden "CryptoCredits" ! :^) - John ]
From: nobody@pmantis.berkeley.edu (Blacknet)
Subject: Introduction to Blacknet
BlackNet is in the business of buying, selling, trading, and otherwise
dealing with *information* in all its many forms. Our location in physical
space is unimportant. Our location in cyberspace is all that matters.
BlackNet is nonideological, but considers all nation-states, export laws,
patent laws, national security considerations and the like to be relics of
the pre-cyberspace era that are often used to explicity project national
power and imperialist, colonialist state fascism.
BlackNet is currently building its information inventory. We are interested
in information in the following areas:
- trade secrets, processes, production methods (esp. in semiconductors)
- nanotechnology and related techniques (esp. the Merkle sleeve bearing)
- chemical manufacturing and rational drug design (esp. fullerines and
protein folding)
- new product plans, from children's toys to cruise missiles (anything on
"3DO"?)
- business intelligence, mergers, buyouts, rumors
BlackNet can make anonymous deposits to the bank account of your choice or
can credit you in "CryptoCredits". [Lots more "interesting" stuff deleted.]
( ESNUG 179 Item 1 ) ---------------------------------------------- [2/93]
Subject: (ESNUG 176 #6 177 #1) Synopsys Is Inverter 'Happy'!
>We have been anaylzing the buffering that is inserted into designs and have
>found that two inverters are used consistently over a single buffer cell. The
>inverter combination has the same area as the single buffer but the buffer is
>faster than the inverter combination.
>
>Why does it consistently choose the inverters over the buffer? And how can
>I get it to choose the buffers?
From: Jon.Kuppinger@FtCollinsCO.NCR.COM
John, one thing you could try to effect the use of inverters over buffers is
to build a wire load model yourself which does not zero out the wire load
*area* parameter. This can be done by building the wire load model and doing
an 'update_lib' command which will add the wire load model to your vendor's
library. You will need to play around with the value you use for area to see
what works. The area will show up in a 'report -area' report. I have used
this technique to try to get Synopsys to use cells with many inputs over the
mass usage of 2-input cells. It may or may not be of benefit to you. An
example of a wire load model that you could use as a template is as follows:
wire_load("EXAMPLE") {
resistance : 0 ;
capacitance : 1.0 ;
area : 0.0 ; <------ Change this value
slope : 0.046254 ;
fanout_length(1, 0.108657) ;
}
In my view I see problems with Synopsys inserting inverters instead of buffers
in a happy fashion in designs. My issue with the insertion of inverters to
add delay, for example, is in a given path to meet hold times at best case
operating conditions. The synthesis will not match the layout and violations
are likely to persist. (The delay that Synopsys is calculating is based on
the wire load model chosen. Because wire load models are generally empirical
and statistically derived such that the first fanout is longer (or has larger
capacitance) than the subsequent fanouts (which may be modelled as linear)
most layout tools will place cells with a fanout of only one right next to or
very close to each other, thus not matching the expected synthesis model
which was derived from all ranges of fanouts. That is, the delays calculated
by Synopsys for a path which contains inverter chains to derive delay will
contain more timing inaccuracy when compared to post-layout than a path which
would account for the delay created using a minimum of cells (i.e. one buffer
or delay cell).
In my opinion, this reveals a weakness in the synthesis tool because it does
not understand this issue. Also, the wire load model currently supported by
Synopsys does not allow different modelling for low and high fanout nets
separately. I have had many customers complain vigorously over this issue and
the overuse of inverter chains in designs.
- Jon Kuppinger
AT&T Global Information Solutions
( ESNUG 179 Item 2 ) ---------------------------------------------- [2/93]
Subject: (ESNUG 174 #1 177 #3 178 #3) 3.0c DC + High Map = Crashed SPARC 10's"
>>If I compile Verilog source with the design_compiler using '-map_effort
>>high', after about 15 minutes the work station will trap to the boot prompt
>>with the message "watchdog timeout"! ... Any setting other than
>>'-map_effort high' appears to work OK.
>I'm sorry to report that we can't seem to reproduce Mark's problem either
>at Synopsys or at his local FAE field office. ... I'm lead to believe the
>problem to be due to Mark's c-shell scripts... - [Synopsys Support Center]
--- --- --- ---
From: (Brian Logsdon)
John, please no company, no address; just use my name only.
This is probably and RAM failure of some kind. You may want to test the RAM
using the built-in diagnostics. Normally, this is tested at startup, but most
Sysadmins either disable the test or only test 1 Mb of RAM. You can also use
the sundiag program to test the RAM completely.
Also, you need to make sure your RAM's are installed properly, if you are
mixing 64 Mb and 16 Mb SIMMs in the same system, they MUST be installed with
a 64Mb SIMM in the first memory slot. If you don't, bad things can happen!
I've seen this before using other memory-intensive programs. Good Luck.
- Brian Logsdon
--- --- --- ---
From: mark_indovina@pts.mot.com (Mark Indovina)
Thanks John, and ESNUG and especially to the three helpfull ESNUG readers
from the net. Two readers suggested we move to SunOS 4.1.3c; very strongly
I might add! We've done this on 4 sparc10's. There was also a suggestion
from another reader that we get copy a of the vendor's ASCII library and try
to compile it ourselves. We did and saw hundreds of timing arc problems.
Needless to say they quickly supplied a clean library. At this point we are
back on our feet with the help of ESNUG.
To follow the ESNUG tradition of showing code examples, I've written a
Verilog model of this problem. Here goes:
module synRun( CRASH, SynopsysCompileTime, SunOS_4_1_3c,
clean_vendor_library )
output CRASH;
input SynopsysCompileTime, SunOS_4_1_3c, clean_vendor_library;
reg CRASH;
always @( posedge SynopsysCompileTime )
if ((using_3.0c) && (SunOS_413c) && (clean_vendor_library))
CRASH <= 1'b0;
else
CRASH <= 1'b1;
endmodule
- Mark A. Indovina
Motorola Applied Research & Advanced IC Technology Laboratory
( ESNUG 179 Item 3 ) ---------------------------------------------- [2/93]
Subject: (ESNUG 178 #5) Suggestions on Synthetic Library Cache Setup & Usage?
>John, has anyone explored the use and setup of the cache for the synthetic
>libraries? We only have the basic DesignWare libraries, and currently every
>user has their own cache. Often times different engineers may be compiling
>a single design as a joint effort -- we don't use logins per chip.
>
>Is there much to be gained by using a general cache? I have looked briefly
>at Chapter 4 of the DesignWare Databook, and would like some advice whether
>we should try to set something up. If we use a general cache, how should
>we handle write/delete situations? Is there ever a problem that a design
>doesn't use the best possible library, because a non-optimal one is already
>cache'd? Any advice, suggestions, pointers would be appreciated.
From: Ihab_Mansour@smtp.esl.com (Ihab Mansour)
John, here's the scoop on using design caches. There are essentially two
approaches in using design caches:
1. Central (one cache that everyone shares)
2. Local (one cache per user)
As an individual Synopsys user, the default is "Local." But, if you're
willing to set it up, the efficient way of using design caches is the central
one (which saves disk space and time.) To share a cache among several users,
everyone sets these pointers to same directory:
cache_read = "/sys/central_cache" /* or where ever you want them */
cache_write = "/sys/central_cache"
To protect the central cache againt accidental deletions it is important to
set file and directory access rights via variables:
cache_file_chmod_octal : 666 ;
cache_dir_chmod_octal: 777;
When you read in your design the design analyzer will build your design by
generic components which come from various libraries and will optimize
depending upon your own constraints. When you optimize for the first time,
if the desired part is not found, the compiler will create it and place it
in the (central, local) cache which to my knowledge the generic part will
then be saved for any future use. That is, the optimized part will be in
your design but the generic unoptimized part will live in the design cache.
This way, no matter who uses this newly created part next, he can use the
generic part before any optimization and then optimize it according to his
own current specific constraints.
- Ihab Mansour
TRW / MEAD
( ESNUG 179 Item 4 ) ---------------------------------------------- [2/93]
Subject: (ESNUG 159 #1) STILL Test Compiler Left Ports Unrouted Out Of Designs
>Hello, John. Here comes a brand new bug of the Synopsys Test Compiler (We're
>using version 3.0b-12954, on Sun Sparc 10)... We are trying to create a
>scan path in a circuit. One of the circuit modules already contains a scan
>chain set, while the others don't... [ Lots of stuff deleted ] ... The
>corresponding ports are NOT routed outside the submodule, and are left
>hanging by the test compiler!
--- --- --- ---
From: paolini@sisun9.CSELT.STET.IT (Maurizio Paolini)
Hello, John. Do you remember the Test Compiler bug I reported in 3.0b ?
(see ESNUG 159 item #1). Well, that bug is still with us - and it looks as
if there is no way of getting rid of it! I am currently using 3.0c on a Sun
Sparc 10 under SunOS 4.1.3. -- thought the ESNUG readers would like to
know this. Old bugs never die, they just go from rev to rev.... :)
- Maurizio Paolini
CSELT - Centro Studi E Laboratori Telecomunicazioni
( ESNUG 179 Item 5 ) ---------------------------------------------- [2/93]
From: Steven Redant <redant@imec.be>
Subject: std_logic vs std_ulogic for VHDL
John,
I have been wondering for a while now why Synopsys have decided to write their
SIGNED and UNSIGNED VHDL packages using std_logics instead of std_ulogics.
The synthesis manual states that this was done because Design_Analyzer has a
built in function that checks on multiple outputs on one wire anyway. This,
in my opinion, is a weak defense. As they state in the simulator core
programs manual, VHDL resolution functions are executed each time an event
occurs on a source of a resolved object. This means, for example, that the
simulation of an adder, that makes use of the std_ulogic_signed package,
executes a lot of unnecessary resolution functions (in fact: one for every
input change!)
For simulation efficiency, the package should be written in std_ulogic. I
would like to know what the other ESNUG readers think about this.
- Steven Redant
IMEC, INVOMEC division, Belgium
|
|
