( ESNUG 173 Item 1 ) ---------------------------------------------- [1/93]
From: Charles Wang <wang@ncrtory.TorreyPinesCA.ncr.com>
Subject: Synopsys IEEE VHDL Libraries Simulate Wrong
John, I have a real scary bug report to Synopsys but I don't know if it is
appropriate to slam Synopsys' face here. But then again, I think it is
Synopsys' responsibility to fix it in an timely manner and somehow notify
users about the problem and workaround ASAP (like on ESNUG). It's been 1
month and the only thing I knew from my AE was that they were working on
it. Hotline never called me back regarding to the resolutions of my
complaints, suggestions or what so ever on this one.
Here's a few lines of the problem description and workaround:
Problem: If you are using Synopsys VHDL packages, i.e.,
IEEE.std_logic_arith, IEEE.std_logic_unsigned and
IEEE.std_logic_signed in your design for simulation
and synthesis, you might be in trouble. Check your
simulation carefully.
Reason: If you use those packages with the IEEE library clause,
you will be using the built-in, pre-analyzed packages
that came along with your Synopsys CDROM. The built-in
packages were actually written in C and became part of
simulator. Unfortunately, the built-in versions behave
differently from the VHDL source code.
Some of the functions in the built-in packages behave
inconsistantly (ABS,...) but the result is still acceptable.
However, some of the functions ( =, >, ...) in the built-in
packages generate *wrong* results.
Work Around: Re-analyze those VHDL packages into a library name other
than IEEE. (Because the VHDL source code is correct.)
Then modify your design to reference the right packages.
Or cross your fingers and pray you didn't accidently use bad
functions in the built-in packages.
I feel this bug is an important one because Synopsys had made these packages
a part of the design methodology that they offer. The special "--pragma"
lines in the packages are the clues for Design Compiler to utilize synthetic
library and design_ware building blocks. (Too bad that they didn't even
want to tell you this trick, not to mention documented it. I guess they
assumed people would just use those packages for granted and are not going
to read them at all.) Anyway, I was very angry when I found this problem.
The bottom line: The user should be free of fear to be screwed up by such
a basic thing. It is a hole in the methodology; they didn't do QC well
enough to check the consistancy of the binary and source. I don't know
Synopsys is handling this bug now; but I figure if they didn't keep me
updated about this problem, you probably still don't know about it, either.
- Charles Wang
NCR
--- --- --- ---
From: [ Synopsys Corporate Applications Engineering ]
We have duplicated this problem reported by Charles Wang and have found it
involves the "built-in" IEEE Packages used by the VHDL System Simulator.
To summarize, it is possible that a customer may experience different
simulation results when comparing simulation runs using the "built-in"
IEEE packages versus the VHDL (external) source files for the IEEE packages.
There is a defect in the "built-in" version of the IEEE packages.
1) The problem exists in the v3.0x [a, b and c] releases of the VHDL
System Simulator.
2) The problem is exhibited when certain arithmetic functions such as
"ABS", "=" and "<=" are used with the standard logic 1164 values
'U', 'X', and '-' or vectors containing these values.
WORKAROUND:
To workaround this problem, analyze and reference ("use") the VHDL source
files for the IEEE packages instead of the built-in IEEE packages. For
example, to use the logic types defined in the package "std_logic_1164"
execute the following command from the UNIX prompt:
% vhdlan $SYNOPSYS/packages/IEEE/src/std_logic_1164.vhd
then change the syntax in the VHDL files that reference this package from:
library IEEE;
use IEEE.std_logic_1164.all;
to:
use work.std_logic_1164.all;
This problem should be fixed in v3.1a.
- [ Synopsys Corporate Applications Engineering ]
( ESNUG 173 Item 2 ) ---------------------------------------------- [1/93]
From: mark_indovina@pts.mot.com (Mark Indovina)
Subject: 3.0c Design Compiler + High Map Effort = Crashing Workstations
John,
Thought your readers might be interested in a problem I'm having using
"Version v3.0c -- Nov 12, 1993" (which we just received and loaded).
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"!
Our environment is all SPARCstation 10's with model 51 cpu's and at least
128M of ram; All machines run SunOS 4.1.3. Note: that last night I ran
a test case spawning the design_compiler on 8 different machines with the
same results on all eight machines. Since this is a "reset" to the
workstation, a corefile is not saved; you also cannot 'resume' the halted
kernel...
Any setting other than '-map_effort high' appears to work OK. Note: that I
did not see this problem with the latest release of 3.0b compiling the
same source (I went back this morning and loaded 3.0b-12954 as a sanity
check).
- Mark A. Indovina
Motorola
( ESNUG 173 Item 3 ) ---------------------------------------------- [1/93]
From: robertb@cadence.com (Robert Brashears)
Subject: Directing $ps_waves To A Printer
moss@mdd.comm.mot.com (Barry Moss) writes:
>I'm trying to find a way to use $ps_waves to send a plot directly to a
>printer without having to create a .ps file first and then go to another
>window to print it. Verilog doesn't seem to allow for UNIX pipes, so is
>there anyway to do this?
If the extra command in another window is the only problem, use the
following Verilog task.
task print_waves;
begin
$ps_waves("file.ps");
$system("lpr -Pprinter file.ps;rm file.ps");
end
endtask
I don't know of a way to do it without creating a file but if the postscript
file size is the problem there should be a solution. Create a named pipe
with "mknod file.ps p". Run the following command in the background "cat
file.ps |lpr -Pprinter". Then give file.ps as the file name to $ps_waves.
The named pipe is a fifo so file size will not be a problem.
- Robert Brashears
Cadence
( ESNUG 173 Item 4 ) ---------------------------------------------- [1/93]
Subject: (ESNUG 171 #5) "No VHDL ASIC Library Available For Synthesis"
> We just found out that our ASIC vendor will not release their new synthesis
> library until June. We had been counting on getting it in January.
>
> Maybe if I tell you what I think our options are, you could comment on
> them. Maybe you can see other options.
>
> 1. Dump VHDL altogether and return schematic capture gate level design.
> GOOD: Dont need synthesis library. Dont need to learn Synopsys and VHDL
> BAD: No behavioral simulation before schematic capture.
--- --- ---
From: mac@chronologic.com (Michael T.Y. McNamara)
Before you return to schematic capture, or take a chance with beta libraries,
or abandon the design win of using Synopsys to translate your high level
design into gates -- you should consider using Verilog instead of VHDL.
Verilog has been around since '87, has 20,000 experienced users and over
160 well debugged ASIC & standard cell libraries available in it. (In
contrast, VHDL has less than 20 libraries available -- most of which are
newly written beta versions which means you the user finds the bugs.)
Very likely, your ASIC vendor already has a well tested Verilog library for
the ASIC family you are using, and is having difficulty translating that to
VHDL. Also synthesizing with Verilog is very well known by Synopsys because
it was the HDL that made them so successful in the early synthesis market.
- Michael T.Y. McNamara
Chronologic Solutions
--- --- ---
From: trevor@ncd.com (Trevor Pearman)
John, here's my 2 cents worth...
a) Changing ASIC vendors is a possibility. There are a large number of ASIC
vendors who have synthesis libraries. If you are careful and write the code
in a generic fashion, then you should be able to switch from one vendor to
another without too much pain. I switched from To***ba to N*C recently after
some problems with To***ba and it took about a week.
You could use another vendor for your development and then switch to your
current vendor if their libraries work towards the end of the project. (I
make no comments on the ethics of such a plan, but it is an alternative.)
It does give you a pretty good lever for your current ASIC vendor to keep
them working at it.
b) You also need to consider the gate level simulation. Is the ASIC vendor
also going to support gate level simulation libraries in VHDL (and are they
doing it for your VHDL simulator)? -- or -- Do you have the means to
transfer schematics from the synthesis tool to a gate level simulator? I
would do a dummy run to check it works. This is frequently a major headache
area. Test vectors are usually a pain with this route, too.
c) In summary think about what netlist and test vector formats the ASIC
vendor needs and how you are going to produce them. Don't start too far
down a path until you know how you are going to do it. Don't rely on the
ASIC vendor to know how to process your output, either. A lot of them
still don't seem to understand some of the issues. I learned the hard way.
- Trevor Pearman
Network Computing Devices
( ESNUG 173 Item 5 ) ---------------------------------------------- [1/93]
From: maziar@vlsivie.tuwien.ac.at (Maziar Khosravipour)
Subject: Xilinx Synthesis with Synopsys
Dear Mr. Cooley,
We are embarking on a project where we expect to do silicon compilation
targetted to Xilinx FPGAs using Synopsys synthesis. Could readers please
post on ESNUG in name or anonymously their experiences using Synopsys with
Xilinx FPGAs?
Answers to the following questions and info/rumor/gossip etc. concerning
this will be appreciated:
How fast is the compilation?
How stable is the tool?
How effectively can you influence compilation strategies?
Did you target to FPGAs or a different technology?
How efficient is the generated layout?
Did the compiler generate a functionally correct layout?
What other tools where necessary to fully simulate the design and
generated a bit stream? Xilinx tools? Viewlogic?
Caveats?
Thanks in advance,
- Maziar Khosravipour
Vienna University of Technology
|
|
