Yikes! Today's Friday the 13th! Even my sheep know that's unlucky! -John
( ESNUG 142 Item 1 ) ---------------------------------------------- [8/93]
From: Synopsys Quality Engineering Department
Subject: Two 3.0b Install Problems for VHDL Simulation & VHDL Synthesis Users
John, here's another hot tip for ESNUG.
There are two problems introduced by the V3.0b Synthesis software release
that impact VHDL users.
PROBLEM #1: The analyzed packages ($SYNOPSYS/$ARCH/packages) are out-of-date
with the source files ($SYNOPSYS/packages). This may cause Warning messages
during "analyze" (i.e. Warning: File XXX out-of-date with source files YYY).
("Analyze" is more commonly used by VHDL lanuage users and similar to using
the "read" command. For more information on "analyze", look in the Commands
Reference Manual or type "help analyze" on the dc_shell command line.)
PROBLEM #2: The GTECH packages entities are out-of-date with their
architectures. This may cause Error messages (i.e. Error: Intermediate file
"GTECH.XXX.sim" was produced recently. Re-analyze files that depend on this
file). Because Error messages are issued, this problem is the most critical
of the two.
NOTE: The packages on the Synopsys VHDL System Simulator v3.0b media (CD-ROM
or tape) ARE correct -- these error messages come from date differences on
installed files!
Workarounds - Three possible installation scenarios:
CASE I: Installation of both Synthesis and Simulation software under
common $SYNOPSYS root directory
The v3.0b READ ME FIRST document specifies an installation dependancy for
customers using both Synopsys synthesis and simulation tools. The Synthesis
tools CD-ROM (or tape) must be loaded first, so that the common packages will
be overwritten by the (correct) files on the Simulation tools CD-ROM (or tape).
CASE II: Installation with both Synthesis and Simulation software under
different $SYNOPSYS root directories (different disks, different hosts, etc.)
If the tools are not loaded under the same $SYNOPSYS root, then the customer
can choose to:
- copy the package source & analyzed files from the v3.0b
Simulation media/image
- or re-analyze the source files (see case III below)
To clarify the workaround for Case II, copy the package source
($SYNOPSYS/packages) and the analyzed files ($SYNOPSYS/$ARCH/packages) from
installed software installation from the Simulation CD-ROM (or tape)
(preferably with tar -p option) to the Synthesis disk image at the
corresponding directory paths. (The -p option for the tar UNIX command will
maintain the installed modes.)
Presuming that you had two different SPARC hosts, one installed with
Synthesis v3.0b and other with Simulation v3.0b, you would do the following:
1) Install the synthesis and simulation software on the appropriate host.
2) Create tar files for the $SYNOPSYS/packages and $SYNOPSYS/SPARC/packages
directories on the simulation installed host.
3) Copy the tar files to the synthesis tools host, placing the tar files so
that when the contents are extracted, the files will overwrite the Synthesis
installed files.
4) Extract the files from the tar files brought over from the simulation host.
You should then not get either the "analyze" warnings or the "GTECH" errors.
CASE III: Synthesis only installations
Synthesis-only customers using VHDL Compiler will need to re-analyze the GTECH
source files (under $SYNOPSYS/packages/src/gtech). A script has been provided
below to assist with this process. This workaround will address the possible
Error messages with GTECH packages.
NOTE: For the Synthesis only installations, there is no workaround for the
possible warning messages described in Problem #1 above.
NOTE: In the script below, change <<path to working area>> to the directory
path where the script is located. Also note that this script will create a
file called "analyze_script" which will automatically be removed if the
script completes successfully.
---=== CUT HERE and save to an executable file ===---
#!/bin/csh -f
setenv SCRIPT_HOME <<path to working area>>
echo "" >> $SCRIPT_HOME/analyze_script
echo "" >> $SCRIPT_HOME/analyze_script
cd $SYNOPSYS/packages/gtech/src
foreach vhd_file ( *.vhd )
echo "analyze -work GTECH -f vhdl $SYNOPSYS/packages/gtech/src/$vhd_file
\ >> $SCRIPT_HOME/analyze_script"
end
echo "quit" >> $SCRIPT_HOME/analyze_script
dc_shell -f $SCRIPT_HOME/analyze_script
rm $SCRIPT_HOME/analyze_script
---=== CUT HERE - END OF SCRIPT ===---
ADDITIONAL INFORMATION:
Impact on HDL Compiler for Verilog users:
The problems listed above should only impact VHDL Compiler users as the
problems exist in VHDL packages and files explicitly referenced or used
by VHDL Compiler and the Synopsys VHDL System Simulator.
Impact on VHDL Compiler users who do not use the Synopsys VHDL System
Simulator:
The impact of the warnings of the date mismatch warning (Problem #1) on users
interfacing to third-party VHDL tools is not known at this time. Additional
information on this will be posted to ESNUG and as it becomes available.
If there any questions regarding this information, please submit it to ESNUG.
- Synopsys Quality Engineering
( ESNUG 142 Item 2 ) ---------------------------------------------- [8/93]
> Subject: ( ESNUG 141 #1 ) "Inconsistant References Problem During Synthesis"
>
> I am having a lot of problems synthesizing a particular design. I get the
> following message:
>
> Error: Inconsistent references found for cell '*SELECT_OP_1_1_1'. (OPT-205)
>
> Has anybody seen this and understand whats causing it. I think its something
> to do with asynchronous resets on latches/flip-flops. I have this problem
> with 3 out of 5 sub-blocks in a design I have. (As best I can tell)
From: uunet!force-c!pfarrer!stefen (Stefen Boyd)
From: schooler@boilerbob.corp.mot.com (Tony Schooler)
I was having this same problem. I emailed the hot-line, and they gave me
the information below. I tried their script, but it never found anything in
my design, so I wouldn't trust the script. The easiest way around the problem
is to compile each module seperately first, then compile the hierarchy last.
- Stefen Boyd
Force Computers
- Tony Schooler
Motorola AIEG
Here's what I got from Synopsys:
Q. When compiling his entire hierarchical design the user gets the following
error message from the Design Compiler:
Error: Inconsistent references found for cell '*SELECT_OP_4_1_4'. (OPT-205)
If a design contains a signal that is assigned in the reset portion of an
"always @" block, that infers a register with an asynchronous reset, and
is not assigned in any other portions of the design, the HDL Compiler appears
to get confused in the naming convention that is used for the ports of the
synthetic celss *SELECT_OP_1_1_1. Instead of using the normal convention,
which is used for other designs:
Pin list for cell U12 is {U12/DATA1[0], U12/CONTROL1[0], U12.Z[0]}
The HDL Compiler uses the following convention:
Pin list for cell U12 is {U12/DATA[0], U12/CONTROL[0], U12/Z[0]}
Now when the same component, *SELECT_OP_1_1_1, is used in two seperate
designs within the same hierarchical block and one cell has the pin list
{U12/DATA1[0], U12/CONTROL1[0], U12/Z[0]} and the other cell has the pin
list {U12/DATA[0], U12/CONTROL[0], U12/Z[0]} the Design Compiler issues
the following error message during compilation or any other command which
updates the design information:
Error: Inconsistent references found for cell '*SELECT_OP_1_1_1'. (OPT-205)
This message should not be issued as the HDL Compiler should be naming all
the Synthetic components according to the same naming convention. The code
segment below shows the case where this problem can occur:
module run_incorrect (wr, clk, reset);
output wr;
input clk,reset;
reg r,wr:
always @(posedge clk or negedge reset)
if (!reset)
begin
r <= 0;
wr <= 1'b0;
end
else
begin
wr <= 1'b1;
end
endmodule
Initial Workaround:
To fix the HDL cde and get rid of the error message the user can
modify the code in one of two ways:
1. comment out the assignment to the signal that is unused elsewhere:
begin
// r<= 0;
wr <= 1'b0;
end
2. make an assignment to the signal elsewhere in the design:
begin
wr <= 1'b1;
r <= 1'b1;
end
Three Workarounds Developed Later:
1. read design and uniquify those modules where the SELECT_OP cell is
used; afterwards compile from the top.
2. Or check the design for situations where a signal has been assigned in
the reset portion of an always block that infers a register with an
asynchronous reset, but has not been used any where else in the code.
If this is the case he needs to either comment out that signal
assignment or assign it to some value elsewhere in the design.
3. Or compile each module separately.
This error occurs if two cells have the same name but have different
port interfaces or name. The bug in the tool currently causes the
SELECT_OP cells to have different pin names when they are used more
than once.
To find where in the design *SELECT_OP* cells are being used, use the
following Synopsys script:
foreach (design, find("design","*")) {
current_design = design
foreach (cell_inst, find("cell","*")) {
rn = get_attribute(cell_inst, ref_name)
if (rn=={*SELECT_OP_1_1_1}) {
echo "Found SELECT_OP cell" rn "in design" current_design
}
}
}
( ESNUG 142 Item 3 ) ---------------------------------------------- [8/93]
From: stallmann.pad@sni.de (Juergen Stallmann)
Subject: Wrong Bus Members When Reading Bussed EDIF-netlist
John,
We are trying to read an EDIR-netlist with bussed ports. These netlist parts
look like this:
....
port (array (rename DT__DA__O_2831_3A0_29 "DT_DA_O(31:0)") 32)
(direction output )
....
instance (rename A__C "A_C")(viewref v(cellRef A__C (libraryRef xy)))
(portInstance (member DT__DA__O_2831_3A0_29 16))
....
Setting edifin_array_range_extraction_style = "%s(%d:%d)"
read_array_naming_style = "%s(%d)"
gen_bus_range_naming_style = "%s(%d:%d)"
gen_bus_member_naming_style = "%s(%d)
results in a schematic, where we got a "bus swapper" at the rippers, so the
schematic is wrong !!
Setting edifin_array_range_extraction_style = "" , we got the right bus
members at the rippers, but the bus and the pin names conflict with the
Mentor rules (which is our final target).
busname and pinname: DT_DA_O(31:0)(0:31)
Did anybody find this problem and a solution for it ?
- Juergen Stallmann
Siemens Nixdorf Information Systems
Paderborn, Germany
|
|
