>From: markp@milpitas.lmc.com (Mark Papamarcos)
>Subject: Joining ESNUG
>
>It was, ummmm, _very interesting_ to meet you at SNUG'94 this week. But
>despite any initial impressions, I'd still like to be added to ESNUG.
>Do you accept people who make snide comments in their requests?
Sure, but anti-sheep jokes won't be tolerated! ;^)
REMINDER: For all the people I ran into at SNUG & OVI who told me about
some bug/issue/experience/product related incompatibility -- send in the
write-ups for these! You know who you are! (Remember, as always, if
office politics dictate that you should remain anonymous, just request
anonymity early in your letter and I'll gladly honor it.)
>From: asic@netcom.com (Henry George Berkley)
>Subject: SNUG'94 Bathrooms
>
>John, Did you notice that a urinal was missing from one of the bathrooms
>at SNUG'94? I think it's OK to to take a souvenir like a matchbook or bar
>of soap but ...
Which reminds me to also solicit user's opinions on what people thought
about the SNUG'94 and OVI'94 conferences themselves. (I'm looking for the
things you liked, what you didn't like, hot products, gossip, what you'd
change & what you definitely would not change. Please don't say "It was
great." or "It sucked." -- write *why* it was what it was!)
- John Cooley, Your "Unpresentable" ESNUG Moderator
( ESNUG 182 Item 1 ) ---------------------------------------------- [3/93]
Subject: (ESNUG 180 #4) Synopsys Test Compiler w/ LSI Logic
>Does anyone have experience using Test Compiler's Custom Test Vector tool for
>scan vector generation for LSI Logic ASICs? Does it work? What were the
>problems? Please share experiences on ESNUG. Thanks in advance.
--- --- --- ---
From: [No Name, Please]
John, I wish to remain anonymous, if you will be so kind.
The primary difficulty at LSI Logic is that they do not have a way of
translating a legitimate, coherent test description into appropriate
simulation controls, as they require for verifying that the test is correct
and usable.
Consequently, customers are required to run LSI's software with an unusually
large number of file types and process steps, in order to generate a
test description. This is distinct from many other foundry vendors who
have established test description formats and for which arbitrary simulation
platforms and test tools may be useful for the test generation or
verification.
For scan tests generated by ATPG, such as Synopsys generates, LSI's simulation
technique is quite restrictive and probably Synopsys underestimated the effort
required to make suitable adjustments for compatibility. We are attempting
to make use of the CTV option for soon to be released ASICs at the equivalent
of Synopsys 3.1 level, as it appears to be the closest to being complete.
So far, we have only run primitive small design samples from CTV to LSI
Logic's CMDE tool suite and have these conclusions:
* It is unlikely that any set of CTV generated files will be acceptable
tests without some amount of correction. There are some details which
are just irritating, like making allowance for test times which are
multiplied by 10, and inserting or correcting LSI required initializing
cycles at the test beginning. More ambitious work will be required if
the design requires a protocol sequence to establish test mode since
custom protocols are prohibited for LSI targeted tests.
* There is evidence that bidirects at the test interface may have produced
a Synopsys compromise in their use as test inputs, and a cosmetic approach
used to satisfy LSI.
* There is evidence that useful output data may be discarded at the test
ending, requiring its replacement when CMDE verification provides the
'correct' values.
We elected CTV, nevertheless, since it was clear that conversion involved
more than just interpretation, and fundamental test structures had to be
controlled. We expect to be successful, although not as easily as we had
hoped.
- [No Name]
--- --- --- ---
>John, the way I've dealt with this problem in the past is by requiring that
>my ASIC vendor (such as LSI) deal with the problem instead of me. I ask them
>to support Synopsys scan vectors in Synopsys format. Then the vendor buys
>the format converter and can use it for all of their customers, instead of
>you buying the converter for LSI, then another one for NEC, then TI, then
>Toshiba, etc.. I'm sure LSI already has a converter and they would be
>glad to convert the vectors for you at no cost (if you tell them that other
>vendors are doing it - and they do!). This way you have one less headache.
--- --- --- ---
From: jmcgoveran@aol.com (Jerry McGoveran)
John, I agree with forcing the vendors to support a common format, but
there is a caveat. Synopsys format ATPG patterns are print-on-change type
and with a large scan chain in a large circuit, you may have problems with
disk space and memory limitations. In a 165K gate design, I had a scan chain
with 9K elements. ATPG came up with 670 patterns. The number of vectors
produced was (670 + 1) * 9000 = 6.039 million. Print-on-change makes this
near impossible to write out to disk! (You might be able to stream it out to
a 5GB tape.)
I tried writing the output to a separate partition from my working disk, and
still crashed when the temp space exceeded the 270MB available. The output
file was just as big, and this was with only 180 of the patterns processed!
Your design size may not be anywhere near this big, but if disk space is a
problem, you don't want to use Synopsys format for ATPG. WGL might be a
better choice, or any other one-line-per-cycle format.
- Jerry McGoveran
McGoveran Engineering Design
( ESNUG 182 Item 2 ) ---------------------------------------------- [3/93]
From: jim@divi.com (Jim O'Sullivan)
Subject: VHDL-Xilinx-Synopsys 3.0c Building Ridiculously Large Designs
John,
A colleague here has run up against a strange VHDL-Xilinx-Synopsys problem.
He's trying to synthesize three structures, each of which is 16 3-input
AND gates OR'd together. The VHDL code is:
LIBRARY IEEE,common;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_unsigned.all;
use ieee.std_logic_arith.all;
use common.common_components.all;
entity ic1 is
port(
int_cntl_hb: in std_logic_vector(15 downto 0);
int_cntl_lb: in std_logic_vector(15 downto 0);
ints : in std_logic_vector(15 downto 0);
int_out : out std_logic_vector(2 downto 0) );
end ic1;
architecture rtl of ic1 is
signal temp0,temp1,temp2: std_logic_vector(15 downto 0);
begin
process(ints,int_cntl_hb,int_cntl_lb,temp0,temp1,temp2)
variable t0,t1,t2: std_logic;
begin
t0 := '0';
t1 := '0';
t2 := '0';
temp0 <= (ints and (not int_cntl_hb) and int_cntl_lb);
temp1 <= (ints and int_cntl_hb and (not int_cntl_lb));
temp2 <= (ints and int_cntl_hb and int_cntl_lb);
for i in 0 to 15 loop
t0 := t0 or temp0(i);
t1 := t1 or temp1(i);
t2 := t2 or temp2(i);
end loop;
int_out <= t2&t1&t0;
end process;
end rtl;
Synopsys generates an 18-level deep OR chain which turns out to have an
enormous propagation delay of ~120 ns after placement and routing! We tried
everything we can think of to get Synopsys to minimize the logic to fewer
levels (like three), with no improvement at all. Neither a Synopsys
consultant nor a Xilinx Synopsys FAE could figure this out.
- Jim O'Sullivan
DiviCom, Inc.
--- --- --- ---
From: [ Synopsys R&D ]
This poor result is due to an area only focus of the current XC4000 technology
mapping, in this case the non-optimality in depth is clearly shown. A quick
workaround for this is to turn on old tech mapping (prior to v3.0.B) by
setting:
"xilinx_map_effort = 0"
before you compile, to turn on old Xilinx mapping. Our tests with the above
example show the critical path was reduced to 4 CLBs (instead of 16).
- [ Synopsys R&D ]
( ESNUG 182 Item 3 ) ---------------------------------------------- [3/93]
From: peterjm@intrinsix.com (Peter J. Militello)
Subject: Problems Loading Large Designs Into Synopsys on IBM RS6000's
Hi John,
I was having great difficulty reading in a large SDF file into Synopsys
on the RS6000 due to AIX memory limitations. Any application cannot use
more that 256Meg of virtual memory (regardless of how much memory is
actually on the machine) unless the application is linked to use more
that one 256Meg segment. Hence, while Synopsys was off pondering this
problem, I was able to read the design in on a Sparc and an HP machine.
The response I received from Synopsys is below. I have successfully read
in the SDF using v3.0c on a machine with 1Gbyte memory.
- Peter J. Militello
Intrinsix Corp
--- --- --- ---
From: [ Synopsys Hotline ]
In v3.0c of our tools, we incorporated a flag into the RS6000 executables that
would allow the process to grow larger than 256 Mb. There was a STAR filed,
and was incorporated in v3.0c, and will remain in the future releases.
Following is the problem characterization, and the fix. STAR 14503:
Problem:
When designs that require more than 250meg of memory during compile cause
the Design Compiler to Fatal. This is due to a memory segmentation feature
on the RS6000 (datasize limit.)
Attempts at increasing the "/etc/security/limits" file failed to solve the
problem. According to IBM, this file only allows you to increase the
datasize limit up to a maximum of 256MB (from the 64MB default.)
Proposed Solution:
According to IBM, the only way that an application can use more than 256MB
of memory, is for the application to be linked with the linker flag
"-bmaxdata:n" when "n" is the maximum size, in bytes, that the user data
area is allowed to increase. If the maxdata variable is not specified,
the system default limit is used (Maximum 256MB.)
There is an unknown efficiency tradeoff in using the "-bmaxdata" flag is
that the large data space model which the "-bmaxdata" flag triggers, since
additional data segments must be managed with this model. It appears that
the only way to quantify this tradeoff, is to benchmark the application,
as there are many variables which affect the large data space model.
Related Information:
Out of memory errors can be confusing because they may be the result of a
per process limit rather than a lack of physical memory chips installed.
Unix has traditionally had these limits built into the kernel to prevent a
run-away process from absorbing all of the resources and hanging the
machine. The Design Compiler and other large modern software packages may
run into these limits in the course of normal operation. These limits can
be changed and, in fact, we have had to increase them on our machines.
- [ Synopsys Hotline ]
( ESNUG 182 Item 4 ) ---------------------------------------------- [3/93]
From: wendyl@hydrox.is.brooktree.com (Wendy Liu)
Subject: Sim vs. Synth Differences with Inferring Master/Slave Latches
John,
I have a problem matching the pre- and post- synthesis simulations with
master-slave-latches. In order for the cell to be inferred and connected
correctly I must have the following in my Verilog code:
always @(posedge CK) // where CK is the master clock
But this causes all latch outputs to change on rising edges of the MASTER
clock instead of the SLAVE clock in pre-synthesis simulations! Any tips?
- Wendy Liu
Brooktree
|
|
