( ESNUG 169 Item 1 ) ---------------------------------------------- [12/93]
Subject: (ESNUG 168 #6) "Seeking A Run Duration Rule-of-Thumb"
>Can anybody out there give me some 'rule-of-thumb' information for the
>improvements in synthesis run-durations you could expect if you upgraded a
>Sun Sparc10 from 64MBs internal memory to 128MB, 256MB?
>
>I imagine that this is going to be design-dependent but for a given design,
>did anybody notice the improvement to be linear?, exponential?, bizzare?
--- --- --- ---
From: neuman@lsil.com (Darren Neuman)
This is a study I ran to determine the memory requirements for our servers.
I used a reasonably large block of VHDL code for our design, so is
representative of our 'worst-case'. The Synopsys job which is a scripted
compile with 14991 cell units or approximately 5260 gates. This is compiled
with a map effort low, where the majority of job time is spent swapping.
All jobs are running on a Sparc10 with no other load.
Interesting to note: the job spends most of it's time swapping if the job
is larger than the Main Memory size. Beyond that size limit, there is
little speedup gained by adding additional memory.
design size : 14991 cell units (300K)
Mem Size: Runtime:
64Meg Main Memory 11:13 hrs.
128Meg Main Memory 4:20 hrs. -- swap for about 1.5hr
256Meg Main Memory 2:34 hrs. -- little swapping
512Meg Main Memory 2:09 hrs. -- no swapping
- Darren Neuman
LSI Corp.
--- --- --- ---
From: Dave Chapman <dchapman@well.sf.ca.us>
I did some quick-and-dirty analysis last year on the other side of the
problem: How much will performance degrade if you instantiate another
dozen ASICs? The situation looks like this:
..................
Run Speed ^ ..
.
..
........................
Real Memory -->
On the left side, virtual memory is more than twice real, and you will
be paging your life away. Adding another 64M will likely have no effect.
On the right side, virtual memory is less than real, and adding more RAM
will have no effect.
It is only in the middle that things get interesting. Depending on how
smart the algorithm in the simulator is, you may get either a fairly
graceful increase in speed with additional RAM, or sudden and discontinuous
improvements as the real RAM exceeds certain magic numbers, which vary
from run to run. Bizarre! The algorithms is question are things like
whether the various subroutines are called in the same order on subsequent
clock ticks, and similar esoterica.
The short answer is that it depends. If you have a good idea of how much
real memory would be necessary to eliminate page faults, then you know
whether to bother upgrading.
- Dave Chapman
Who, me? I'm just a software guy!
--- --- --- ---
From: f420610@fsd.com (Zach Stern)
Can't say exactly what improvement you will get - but will say that synthesis
tools may not even use additional memory unless you also increase your swap
space. We found that the amount of memory used is limited by swap space.
We started out with MORE RAM than swap (512M RAM, 250M swap) - and ran some
tests to discover this odd truth. Recommend you check swap space usage
(pstat -T) and see if your maxing out swap space before adding more memory.
- Zach Stern
Fairchild Space and Defense
( ESNUG 169 Item 2 ) ---------------------------------------------- [12/93]
Subject: (ESNUG 168 #4) "Design vs Reference ?"
> "what is the difference between a design and a reference?"
--- --- --- ---
From: uunet!fmicos!splinter!flieder (Jeff Flieder)
John, the explaination of the difference between a design and a reference can
be confusing, and I had the same problem putting dont_touches on references.
It turns out that it doesn't work at all. For some reason, you can put the
attribute on a reference, but it does nothing. It seems to me you should get
an error if you try, since it is ignored anyway. I will try to explain the
difference between designs, cell, and references.
A design, as defined by Synopsys, is a description of a function, whether
it be a newly read in design in the Synopsys primitives, or a gate level
description. A design can loosely be equated to a Verilog module (maybe not
that loosely, as each Verilog module creates a design in Design-Compiler).
A reference, on the other hand, is a pointer to a design. It can be thought
of as an instantiation of a design inside another design. As an example,
say you had one adder that was instantiated twice in a design. There would
be one design called adder, and two references to the design.
The reason that putting a dont_touch on the reference doesn't work, is that
it is only a pointer, and the design it the thing that needs to be
dont_touched in order for it to work. I know how confusing this is, so I
hope this helps. There is also an explaination of this in the Design-Compiler
manual, but it's tough to understand. Hope this helps.
- Jeff Flieder
Ford Microelectronics, Inc.
--- --- --- ---
>i had a hierarchical instance that was "dont_touch-ed"
>
> > get_attribute find(cell,mycell) dont_touch
> Performing get_attribute on cell 'mycell'.
> {"true"}
>
>but then i couldnt remove dont_touch with
>
> > remove_attribute find(cell, mycell) dont_touch
> Performing remove_attribute on cell 'mycell'.
> Warning: Can't remove attribute 'dont_touch' from
> object 'mycell'. (UID-339)
> {}
>
>and
>
> > remove_attribute find(design,mydesign) dont_touch
> Performing remove_attribute on design 'mydesign'.
> Warning: Attribute 'dont_touch' does not exist on
> design 'mydesign'. (UID-101)
> {}
>
> huh?
--- --- --- ---
From: vickiem@endor-e0.sps.mot.com (Vickie Mercier)
The problem with removing the dont_touch attribute in this case has to do with
the fact that an attribute should be removed in the same way that it was
applied. The following:
dont_touch find(reference,mydesign)
applies the dont_touch attribute to both the cell and reference, however
it can only be removed from the reference, thereby clearing both.
- Vickie Mercier
Motorola
--- --- --- ---
From: c0806@marsha.sanders.lockheed.com (James W. Lewis)
Hi John, I had a similar problem to this when we transitioned from Synopsys
2.2 to 3.0. Specifically the following worked in 2.2:
dont_touch ADD_30
... script stuff
remove_attribute find( design, ADD_30) dont_touch
In 3.0 I had to change it to the following:
dont_touch find( design, ADD_30) dont_touch
... script stuff
remove_attribute find( design, ADD_30) dont_touch
Similar to the orginal user's problem, the dont_touch seemed to default to
being set on the reference.
- Jim Lewis
Zycad
( ESNUG 169 Item 3 ) ---------------------------------------------- [12/93]
Subject: (ESNUG 167 #4 168 #2) Test Compiler "Plays" Between 2 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!
>>
>> - Paul Callahan
>> Alcatel
> John, try using:
>
> insert_test_scan_chain_only_one_clock = true
>
> [Editor's Note: Two others also independently wrote similar replies. -John]
--- --- --- ---
From: wpcallah@rwasic17.aud.alcatel.com (Paul Callahan)
I tried this, but Synopsys gets lost at my clock dividers. I think this
variable might work if I make test compiler think the output of my dividers
are clocks, and different clocks from my higher rate clocks.
For my trial I muxed in a separate clock, controlled by the Scan_Mode signal.
Setting insert_test_scan_chain_only_one_clock = true helps some, but the last
chain still uses flops from both clocks. I tried creating clocks form the
mux output ports, but that didn't change the chains.
- Paul Callahan
Alcatel
--- --- --- ---
From: "Teri A. Tracey" <teri@sdd.hp.com>
Depends on your design (and version of Test Compiler?)!
We also tried to use "insert_test_scan_chain_only_one_clock = true", but we
get a fatal error (on test compiler 3.0a-10063) because we need to have
multiple chains on one of our clocks, and this variable causes a crash in
that exact case. Example: clk1: 70 flops, clk2: 120 flops, clk3: x000 flops.
We wanted to restrict the chain length to 200, so we were looking at 15 chains
for clk3. Test compiler repeatedly crashed and we were told that the above
variable CANNOT handle multiple chains on any one clock.
- Teri Tracey
Hewlet-Packard - San Diego Printer Division
--- --- --- ---
From: lund@romulus.cray.com (Gregory Lund)
John, I've had trouble with:
insert_test_scan_chain_only_one_clock = true
Synopsys would crash when I tried to insert multiple scan chains. My design
had only one clock. Synopsys instructed me to set this variable to "false"
-- my problem went away. There is a STAR, but I never got the number from
Synopsys.
We are currently doing design with multiple clocks. When Synopsys does
insert_test with the
[number of chains] > [number of clocks],
Synopsys will construct the chains so that elements each chain are clocked
by the same clock. Scan works fine, but you still have to deal with problems
in the test data capture.
- Greg Lund
Cray
|
|
