From: EE Times, March 21, 1994, (pg.2)
> Chronologic Simulation, the largest of the Verilog simulation clone
> vendors, has been the target of separate acquisition attempts by
> Synopsys Inc. and ViewLogic Systems Inc., according to industry sources.
> At press time, no firm deals had been revealed, but Chronologic was
> believed to be near completion of an agreement with ViewLogic.
Editor's Note: I can confirm that this was a rumor definitely going around
last week's OVI conference. And because Synopsys and ViewLogic are
publically traded companies, the SEC has very strict rules governing what
they can & can not say about mergers & aquisitions -- namely they can't say
anything! Another item that was interesting at last week's OVI was that
Mentor dropped a pretty piece of change buying a pricey lunch for all the
OVI attendees and was quite active in the technical forum. What this tells
me is that the Big Four EDA vendors appear to be pulling out of the
disasterous Verilog/VHDL wars. Interesting...
- John Cooley
the ESNUG guy
( ESNUG 183 Item 1 ) ---------------------------------------------- [3/94]
From: bobh@model.com (Robert D. Hunter)
Subject: Model Tech / Synopsys VHDL Differences
John,
Here's a copy of the standard apps note you've been pestering me for that we
send to our customers outlining the known differences between the way Model
Technology implements VHDL and the way Synopsys implements VHDL.
We know of four differences between the versions of the VHDL language
accepted by V-System and Synopsys:
1) If a parameter to a procedure is an unconstrained array, the VHD Language
Reference Manual does not allow an aggregate assignment containing an
"others" choice to that parameter. (LRM Section 7.3.2.2) The Synopsys
VHDL compiler allows this usage, and the Synopsys package "mvl7textio"
uses such assignments on lines 149, 157, 200 and 210 to the variable
"value", e.g.:
value := (others => 'X');
This can be changed to legal VHDL as follows:
value := (value'range => 'X');
2) The Synopsys VHDL analyzer extends the visibility of a "library" clause
from a package or an entity to the context clause of the corresponding
package body or architecture body. This is contrary to the last paragraph
of LRM Section 10.1.
The Synopsys package "arithmetic" and the file of entity declarations
"entities.vhd" can be corrected as follows:
The "use" clause on line 142 of arithmetic (immediately preceding the
start of the package body) can be removed or commented out.
Before lines 2302 and 2466, which read as follows:
use SYNOPSYS.BV_ARITHMETIC.all;
insert the line:
library SYNOPSYS;
3) When an enumerated data type is declared, an implicit declaration of the
operator "=" is also generated. This declaration can be hidden by an
explicit declaration of "=" in the same package (LRM Section 10.3).
However, if another version of the "=" operator is declared in a different
package than that containing the enumeration declaration, and both
operators become visible through "use" clauses, neither can be used without
explicit naming (i.e. ARITHMETIC."="(left, right)). This is inconvenient.
The Synopsys compiler allows the explicit declaration to hide the implicit
declaration, which is what most users expect. Model Technology asked that
this be changed in the 1992 version of VHDL, but the suggestion was not
accepted.
Due to the inconvenience, the Model Technology VCOM command has been
modified to allow the explicit "=" operator to hide the implicit one if
the command line "-explicit" switch is specified.
4) The TEXTIO function "endline" was dropped from VHDL because it cannot be
legally declared in the VHDL language (VASG-ISAC VHDL Issue Number 0032,
10 November 1988). It seems to still be supported in the Synopsys version
of TEXTIO. All occurrences of "ENDLINE(LLL)" should be replaced by
"LL'length = 0"
Hope this helps your readers.
- Bob Hunter
Model Technology
( ESNUG 183 Item 2 ) ---------------------------------------------- [3/94]
From: [ An Anon i-Logix/Synopsys User ]
Subject: i-Logix / Synopsys Compatibility Bug
Hi John!
Please keep my name and company out of this.....
We ran into a problem when trying to synthesize Verilog RTL code generated by
iLogix/ExpressV-HDL 2.5. This piece of Verilog generated by i-Logix caused
Synopsys to crash regardless of which version I tried (which was only up to
Synopsys 3.0c.) Also this only happened if I put contraints to the design.
So, a way to walk around this problem was to do a two pass compile, one
without contraints followed by one with constraints. Not very nice but it
worked.
- [ An Anon i-Logix/Synopsys User ]
This is the reply from my Synopsys FAE:
From: [ A Synopsys FAE ]
STAR 17889: This star is a duplicate of star 16810.
The problem results because there are some redundant hdl operations in the
description. The particular operations that have been deemed redundant are
the ">" operators on the lines bellow marked with "**".
Extract from the code:
** else if ((AM == 1 && CNT > 0) && (CNT == 8 && (PAR_TEMP ==
BLOCK_PAR && AM == 0)))
begin
VC_CELL <= 0;
CDR_READER_isin <= VC_OR_META;
end
else if ((AM == 0 && CNT > 0) && (CNT == 6 && (PAR_TEMP ==
BLOCK_PAR && AM == 0)))
begin
VC_CELL <= 0;
CDR_READER_isin <= VC_OR_META;
end
else if ((AM == 1 && CNT > 0) && (CNT == 8 && (PAR_TEMP ==
BLOCK_PAR && AM == 1)))
begin
CDR_INFO_VALID <= 0;
CDR_READER_isin <= VPI_STATE;
end
** else if ((AM == 0 && CNT > 0) && (CNT == 6 && (PAR_TEMP ==
BLOCK_PAR && AM == 1)))
(** - The two lines causing Synopsys to crash are marked with "**".)
These are redundant because they are part of an "&&" separated list that
includes both "AM == 1" and "AM == 0".
Since the boolean expression for the if branch can never be TRUE, the entire
branch is pruned out. When logic synthesis prunes out the operators, it
causes problems in resource sharing as it expects the cells to be there.
This bug has been fixed in Synopsys v3.1a.
- [ A Synopsys FAE ]
( ESNUG 183 Item 3 ) ---------------------------------------------- [3/94]
From: Oren Rubinstein <oren@waterloo.hp.com>
Subject: Impressions of SNUG '94
Hello John.
As I promised, I'm sending you my impressions about SNUG '94 and a summary
of the tricks that were presented there.
A. Impressions
Generally, I liked the conference and I found it interesting. The one
feature that stood out is having some R&D guy standing in the back for
all the tutorials, so they had a quick and accurate answer to any question.
One thing I didn't like was the obvious bias towards VHDL. Considering
there are more Verilog users than VHDL ones (understatement of the month),
I found it disappointing that most of the presentations and tutorials kept
referring to VHDL.
Another thing was the level of the tutorials. They were fine for beginners
and intermediate users, but after all these years, there is a population
of advanced designers who don't need to hear once again about C-Ch-WS-RC,
but could benefit from a really _high_level_ presentation.
B. A few tricks
1. compile_default_critical_range! This variable sets a critical range
for all the path groups. The default value is 0.0 It is not the same
as specifying a critical range for all the path groups, unless you make
sure to do it for the -default range as well.
2. compile_use_low_timing_effort (not documented) Setting this variable
"true" tells the compiler not to backtrack all the input transitions
every time it swaps cells during mapping, which saves a lot of time
when using the non-linear delay model, at the expense of some accuracy.
People who use the NLD model have seen speed degradations of up to
a factor of 10, compared to the linear model. The variable doesn't
affect the reports, so you still get accurate information, but you may
need to set it "false" and run an incremental compilation if there are
any violations.
3. auto_disable_link (not documented) Setting this variable "false" tells
the compiler not to re-link the design after each command that affects
the timing, like set_false_path, set_multicycle_path, etc. This speeds
up the constraints setting, but it must be set "true" again when you're
done. (When I tried "auto_disable_link" as it was presented by the
Synopsys R&D type at SNUG I found it doesn't do anything -- but there is
something called "auto_link_disable" which seems to behave the way
"auto_disable_link" was described.)
4. report_timing_requirements -ignored
If a command like set_multicycle_path or set_false_path is invalid
because the -from is not a valid startpoint or the -to is not a valid
endpoint, you don't get any warning, because later on there might be
another command which makes the invalid point be valid, through path
segmentation (apparently, this is legal, the order doesn't matter).
Therefore, the only way to know about these "ignored" commands is to
issue a report_timing_requirements -ignored after you're done, and
they strongly recommend it.
5. Path segmentation.
According to Synopsys, many users don't know how to do this, so here it
is. Path segmentation means creating a valid timing start or end point
in the middle of a path. To do this, you need to:
- decide on a time budget first, i.e. decide how to split the overall
timing of the original path,
- then you issue a set_output_delay command for that point, which puts
a timing constraint on the first part of the path,
- followed by a set_input_delay (for the same point), which sets the
start point for the second part of the path. Note that if you don't
do this last thing, the default value for the new startpoint is 0.0,
NOT the same timing as the one from the preceding set_output_delay,
as one might expect.
- Oren Rubinstein
Hewlett-Packard (Canada) Ltd.
( ESNUG 183 Item 4 ) ---------------------------------------------- [3/94]
Subject: (ESNUG 180 #4 182 #1) Synopsys Test Compiler w/ LSI Logic
>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: [ No Name, No Nothin' ]
John, No name, no address , no nothin', please. (I suffer from Revengophobia
- the fear of Synopsys Corporate reprisals.) Anyway, on with the topic...
Buy the vector format converter? ... from who? If Synopsys doesn't have it,
and LSI doesn't have it, then who does? I suspect that if LSI or Toshiba or
NEC or anyone else has performed this for you, it has been done either by hand
editing, or grep/awk/sed which is obviously prone to error! FYI, TSSI won't
support this conversion in a coherent fashion either.
The big problem with ATPG translation from Synopsys (or AIDA) to LSI is that
LSI uses a parallel vector format for ATPG vectors in CMDE. That is, rather
than simulate every SCAN IN - CAPTURE - SCAN OUT cycle in a serial format that
require millions of clock cycles, LSI uses a parallel insertion of the SCAN IN
data and a parallel monitoring of the SCAN OUT data in the ATPG simulation.
This reduces the number of simulation cycles to:
Cycles = # of ATPG vectors * number of cycles per vector (usually 4-6)
Converting into the LSI format takes a bit of work. AIDA has a translator,
but it is not perfectly clean. Things also get a bit wierd if you are using
JTAG with the TAP Controller setting up and running the Scan chain.
Personally, I _don't_ believe that it is reasonable to expect your ASIC vendor
to support the n+1 various tools for you, _especially_ when he has given you a
SCAN/ATPG path to follow. If you believe it is, then you should be willing to
pay full-boat price for your silicon with no complaints. If you don't want to
use CMDE, fine, have LSI do the SCAN/ATPG for you. A few K-bucks and you
won't have to mess with it.
However, I suspect that given the alliance between LSI and Synopsys inked last
year, you will probably see a Synopsys/LSI vector translator before very long.
- [ No Name, No Nothin' ]
--- --- --- ---
From: victor@truevision.com (Victor J. Duvanenko)
> 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 & 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!
John, I agree completely with the above caveat. The way I've dealt with this
problem in the past has been not to output vectors in any format at all, but
simply run through all of the steps for scan design to see what problems
arise and the coverage obtained. Once the design was done, I sent the
entire design (just the .db files and my top level dc_shell script that
assembles the whole chip) to my ASIC vendor. The ASIC vendor then ran the
script and added their test vector formatting flow to it. For instance,
TOSHIBA needs only this and the .vdb file (which is very compact). The rest
of the process is upto the ASIC vendor, and they get to deal with the disk
issues (which they are used to, since they get to do mostly back end, which
means a lot of vectors, and thus, lots of disk space). This has worked great
on several designs now, and one of them had over a million vectors (for the
scan chain). Granted, I have been nice to my ASIC vendor and have split my
scan chains up, to reduce their length and the length of scan vectors (this
works well in Synopsys and is quite easy).
One problem that I do, however, run into and haven't gotten to the bottom of
yet, is that the Test Compiler knows nothing about propagation delays and I
goofs up because of this, when you have several asynchronous clocks (i.e. when
it propagates values from blocks of one clock to block of another clock).
My ASIC vendor simulated scan vectors on their gate-level simulator and it
always has miscompares. Has anyone else seen this problem and have any
words of wisdom about fixing it? Hope this helps.
- Victor J. Duvanenko
Truevision
|
|
