Editor's Note: The implications of the following letter (below) just blew
me away. See http://www.newscientist.com/971115/features.html to
read the complete details of what this guy is saying. Whoa! - John
From: "Evan Shattock" <ems@riverside-machines.com>
> There's a pretty amusing article in the 15th november '97 issue of "New
> Scientist." A 'researcher' loaded random configurations into a device
> (he doesn't say which one, but it's probably a Xilinx XC4003) in an
> attempt to produce a tone discriminator. By selecting configurations
> according to how successful they were, & 'breeding' these configurations
> (i.e. randomly swapping bits between configurations), he eventually,
> after 3500 generations, found a configuration that successfully
> discriminated between a 1KHz and a 10KHz tone. The circuit is
> unclocked. The cover describes the circuit as 'smart, strange, & beyond
> our understanding'.
>
> According to the article, he produced this solution with "fewer than
> one-tenth of the components that a human designer would have used". (It
> appears to have used 37 cells out of the 100). But...
>
> 1.) The circuit works only over a 10 degrees C range.
> 2.) It only works on one device.
> 3.) He doesn't seem to have checked the voltage range over which
> it works.
> 4.) Five of the cells are not logically connected to the others,
> but the circuit doesn't work without these cells.
>
> Apparently, Motorola is interested in the work.
>
> - Evan Shattock
> Riverside Machines Ltd. Cambridge, UK
( ESNUG 276 Item 1 ) ----------------------------------------------- [1/7/97]
Subject: Facing Problems With The Xilinx-Synopsys Interface (XSI)
> I'm having some problems with the XSI (Xilinx Synopsys Interface). I
> have the Synopsys and XSI installed on a Sun Workstation but the XACT6 /
> Foundation Series is installed on a PC. As I don't have the license to
> use VHDL from Xilinx, I'm using the Synopsys tools to implement the
> "modules" of my design. The documentation describes the whole process of
> implementing designs in Synopsys and how to export the XNF file
> generated (using syn2xnf, etc...) to the Xilinx tools, so that one can
> place and route the design. But it assumes that the design is a
> top-level one, that is, it contains PADS and the signals are connected
> in some way to the external pins. In my case, I want to generate blocks
> (known as "macros") and place them in my schematic (Foundation Series)
> so that I can make the interconnections mannualy.
> I can successfully import the xnf generated by Synopsys and translated
> by the SYN2XNF from XSI into the schematic, but when I try to Place and
> Route something goes wrong and I receive dozens of warnings and PPR
> errors. Please, if someone can help me, do it !
>
> - Rodrigo Cesar de Moraes Tavares
> Universidade Federal de Minas Gerais, Brasil
From: Terry Graessle <graessle@vlsiDOTgsfc.nasa.gov>
Use the -sub command line option with syn2xnf:
syn2xnf -sub xxxx.sxnf
This tells syn2xnf that the design is a subcircuit & not at the top level.
- Terry L. Graessle
Lockheed Martin - Space Mission Systems
---- ---- ---- ---- ---- ---- ----
From: Brian Philofsky <brianp@xilinx.com>
Rodrigo,
Take a look at http://www.xilinx.com/techdocs/2450.htm This tells you
how to import a Synopsys design into Viewlogic but Foundation should be
similar. Things to note, change part 1 about the part changing the bus
naming style to:
bus_naming_style = "%s<%d>"
bus_dimension_separator_style = "><"
bus_inference_style = "%s<%d>"
I belive Foundations uses angle brackets (<>) as bus separtors.
Also, the creation of the symbol would be slightly different but I do not
have the details on this. Do not beleieve it would be too hard to figure
out though.
I am guessing that the problem you were having before is maybe you did not
specify the -s switch when you ran syn2xnf specifying this is a
sub-module. Without the switch, SYN2XNF will place EXT records in the XFF
file and possibly cause the problems you were seeing.
- Brian Philofsky
Xilinx
---- ---- ---- ---- ---- ---- ----
From: Bill Lenihan <lenihan3we@earthlink.net>
I've done this with Synopsys FPGA Compiler & Mentor tools, all on a
workstation. If you use different schematic & simulation tools some details
will likely differ, but the principle may remain the same.
1) Synthesize your HDL module(s) in Synopsys, and save as <design>.sxnf
files in "xnf" format. If the top level schematic has timespecs, make
sure you "remove_constraint -all" in synopsys, otherwise the timing goals
you set in Synopsys will get passed into the sxnf file and may conflict
with the timespecs you set in your (higher level in the heirarchy)
schematic.
2) Run the syn2xnf conversion utility (use -help to see all the switches
you must set) to produce the <design>.xnf and <design>.xff files. Copy
the <design>.xff to <design>.xnf in the directory that has the main
(schematic) design. Make sure you have a symbol created for the
HDL-based components (no underlying schematic will exist, yet, for these
symbols). Aside from the usual attributes on these symbols, they should
also have "FILE = <design>.xnf" attributes, too. This associates the
synthesis-generated .xnf file with the symbol and keeps men2xnf from
trying to generate an xnf netlist from a schematic that doesn't exist.
3) From here, the xmake design flow continues as before. The Mentor-Xilinx
design flow does generate a schematic for the synthesis-based components,
but this is just to keep the simulator happy and this schematic is quite
un-readable.
I have complained about this before to Synopsys & Xilinx. Namely, that most
HDL tutorials show the flow for complete-HDL designs, yet HDL newbies start
off doing a little bit of HDL in an otherwise schematic design, and
tutorials should be written with this in mind. A Synopsys FAE wrote to
agree with me and take it to the powers that be at Synopsys. My response
from Xilinx was, of course, silence.
- William Lenihan
Hughes
( ESNUG 276 Item 2 ) ----------------------------------------------- [1/7/97]
Subject: (ESNUG 275 #2) FSM Extraction/Synthesis with Synopsys FSM Compiler
> I get much better timing results in both ASICs and FPGAs when I extract
> the FSM and use one-hot encoding. Of course, the area grows.
>
> - Frederick K. Best
> Lockheed Martin Electronics and Missiles
From: cgregory@hns.com (Chris Gregory)
John,
I have recently played with the fsm extraction tool in the FPGA
compiler. I cannot stress enough that, in my experience, writing good HDL
in the beginning is more valuable than letting the compiler do any
automatic optimization. I experienced virtually no improvement when
extracting fsms. I had a couple cases where the extracted and recompiled
fsm turned out to be significantly larger and did not improve the
performance.
I think if I had very rigerously constrained my design I could have
gotten good results from extraction but in my situation I didn't need
terribly tight timing constraints. It should be noted that mine was a
special case because I was trying to reduce AREA not speed of my fsm in
order to fit into an FPGA. Since Synopsys is primarily an ASIC tool I
don't think it tries terribly hard to optimize logic such that it fits into
the smallest number of FPGA cells. It seems to do mostly boolean
optimization and then it quits as soon as the timing is met -- even when I
set_max_area to zero.
(I know a lot of you are saying "why the hell would anyone go to so
much trouble to fit into an FPGA when you could just get a bigger part".
In my situation this was a board that was designed 5 years ago and I had to
make an FPGA modification without changing the existing artwork and there
weren't any pin compatible solutions that were anywhere close in price.)
By experimenting with different state encoding patterns in my HDL, I
was able to reduce the combo logic and subsequently the number of FPGA
LUTs. Strangely enough, when I used the exact same encoding patterns with
the set_fsm_encoding command in Synopsys, my results were not as good.
One last comment about the fsm tools, the state table format is
incredibly difficult to use with even a moderately sized fsm. I attempted
at one point to write my fsm from scratch in state table format ....... I
shot that idea down PDQ.
- Chris Gregory
Hitachi Network Systems
---- ---- ---- ---- ---- ---- ----
From: [ I Am Paranoid ]
Hi, John,
No name please. I am paranoid.
I tried several things with FSM compiler in the past, and I'd like to put
my two cents into this matter.
My experience tells me that the best coding style follows the guidelines
described in Synopsys manuals (Design Compiler Reference, HDL Compiler
for Verilog, etc). Basically, the FSM should be in a module by itself,
the only flip-flops there should be those containing state info, and
all necessary directives (enum state_info, state_vector, etc) are used.
When the guidelines are followed, the extraction is very simple; otherwise,
the result depending on how much effort one spends on seperating the
FSM logic from other codes.
After extraction things get a little tricky. In general I observe these
three problems: undefined output can limit DC, large FSM can become
worse, and DC can't find an optimal state encoding.
Sometimes I leave an output X to give DC more freedom in optimization, but
this always requires extra work after extraction. The reason is during
compile the X is used to optimized the original state encoding, which is
often binary. Since compile and extract turn all X into 0 and 1, DC has
less freedom when choosing new state encoding. To work around this one
must write out the FSM into a state table, edit the table, and read it
back in. Not an easy task.
I don't know how hard DC tries to optimize the FSM, but my guess is not
very hard. I had a FSM with 40+ states once. It basically controlls the
CAS and RAS and bursts data from DRAM. It has very few outputs, and
there are no branches. Just out of curiosity I tried one-hot encoding,
gray-code encoding, binary encoding, and whatevery DC chooses. I found
that binary encoding and gray-code encoding yield approximately the same
result, but the encoding DC chose had about the same area as one-hot
encoding (and slower). After some more experiments I found that DC
can't do a good job starting around 20 states. Some FSM got bigger, some
had less-than-optimal encoding, and some did both.
From these observations I concluded that there is not a significant
advantage using FSM compiler. For now, I follow the guidelines when
coding, but I don't modify existing codes to meet the guidelines. When
a state machine is large, I select an encoding method rather than let
DC decide. And if I have lots of x, I run simulations to extract a
state table, and use the table instead of compile-extract.
And finally, if easy-to-read code is the top priority, then by all means
follow the guidelines. They make the codes a lot easier to understand.
- [ I Am Paranoid ]
( ESNUG 276 Item 3 ) ----------------------------------------------- [1/7/97]
Subject: ( ESNUG 275 #4 ) Converting Synopsys ".db" Files to ASCII
>> By using Library Compiler, ASCII source file to ".db" Synopsys library
>> file can be made. How can I convert ".db" file to ASCII file?
>>
>> - Tetsuji Oguchi
>
>From: rohm@cayman.engr.sgi.com (Matthew Rohm)
>
>The closest thing to what you want is the report_lib command. I think you
>need a library compiler license to actually get any useful information out.
>
> - Matthew Rohm
> SGI
From: Andrew Frazer <Andy.Frazer@idt.com>
More importantly, you can't read anything from a .db file unless you also
have the source code (.lib) file. For example, if you try to translate the
.db file into VHDL source code, it won't let you procede unless the source
code is also accessible. I think they do this as a security precaution so
that people don't try to read everything that's in an ASIC foundary's
library without their permission.
- Andy Frazer
Integrated Device Technology
( ESNUG 276 Item 4 ) ----------------------------------------------- [1/7/97]
Subject: (ESNUG 274 #8) What's Better? "Rich" Or "Sparce" Synopsys Libs?
> I have been involved in an effort of generating Synopsys libraries.
>
> The target is to be able to compile a design to the fastest speed. One of
> the questions that arises is how "rich" the library should be? Some
> libraries out there have over 1000 cells, but, on the other hand, some have
> much fewer cell selection (~300). I know, theoretically, more is better,
> but I have seen cases where it does not apply. For example, we had a
> complex gate that had (by mistake) only one size. Removing the cell made
> the design synthesize to a faster speed. It seems like Design Compiler
> picked up this cell, assuming it could bump up the size, but then when it
> found out it cannot do that, it could not recover.
>
> Does any one has any experiece with this? Is there a DC runtime penalty
> for using the rich libraries vs sparce libraries?
>
> - Erez Naory
> National Semiconductor Hertzlia, Israel
From: abair@parsons.sps.mot.com (Alan Bair)
Hi John,
From what I have read and heard in talking to other users within Motorola
and Synopsys support, there are a couple issues.
* For each function in the library, there should be 4-5 sizes to
provide for adequate choice in sizing.
* Performance is not hurt until the library has several thousand cells.
* Once all the basic functions are handled the best way to improve a
library seems to be to look for common pairings Synopsys is making
and turn those into extra cells.
Hope this helps.
- Alan Bair
Motorola
( ESNUG 276 Item 5 ) ----------------------------------------------- [1/7/97]
Subject: (ESNUG 274 #4 275 #6) Synopsys On-Line Help W/O Tying Up A Licence
From: jeffb@el.nec.com (Jeff Buckles)
BTW, Does anybody else use the synopsys MAN pages??? I usually find much
more useful info here, and more quickly, than in the online "documentation".
- Jeff Buckles
NEC
---- ---- ---- ---- ---- ---- ----
From: Zehentner Georg <zehentner@heidenhain.de>
Hi John,
I simply aliased the iview:
alias synhelp '$SYNOPSYS/worldview/bin/iview &'
This alias works quiet well.
- Georg Zehentner
Dr.Joh.Heidenhain GmbH, Germany
( ESNUG 276 Item 6 ) ----------------------------------------------- [1/7/97]
Subject: ( ESNUG 275 #9 ) DC Putting Delays On Flip-flop Feedback Lines
> Another problem we have noted here is Synopsys putting in delay lines on
> flip-flop feedback lines when using clock uncertainty. To get around this
> problem, an engineer here proposed adding the following script:
>
> foreach(dummy, all_registers()) {
> set_false_path -hold -from dummy -to dummy
> }
>
> and then compiling incrementally.
>
> This appears to produce the desired results on small files, but causes
> large ones to spin, more or less, forever. For now, we have decided that
> we can live with those extraneous delay lines.
John,
One word of warning to using this approach.
Every point-to-point timing exception significantly increases compile time.
Use timing_self_loops_no_skew (remember those MAN pages?)
- Jeff Buckles
NEC
( ESNUG 276 Item 7 ) ----------------------------------------------- [1/7/97]
Subject: (ESNUG 272 #2) Choice Of C Compiler & The Synopsys VSS C Interface
> Hi there, after working a lot with the SYNOPSYS C Language Interface CLI
> we are currently encountering problems with the C compiler used. The cc
> does not fit our needs, so we are interested in using the gcc. Does anyone
> know where set the default C compiler for the CLI or the parameters for
> the call as this is not explained in the manual. Renaming the gcc to cc
> helps, but this still does not solve the problem with the fixed parameter
> set in the compiler call.
>
> Any experience on that subject? We would be really grateful for any help.
>
> - Fabian Wolf
> Institut fuer Datenverarbeitungsanlagen
From: [ A Synopsys Simulation Support Engineer ]
John,
Here are some instructions on how to specify a alternate c compiler for cli.
Using the GCC compiler with CLI of VSS is accomplished by changing some
variables in the CLI script. The name of the compiler and the flags used
by the compiler are specified in the CLI script. Each of the supported
platforms of VSS has a section in a case statement of the CLI script which
identifies items such as the compiler, compiler options, linker, and
linker options.
How to modify the CLI script:
1. Copy the CLI script from a bin directory of the VSS installation
to a temp working area.
cp $SYNOPSYS/sparcOS5/sim/bin/cli .
2. Edit the copy of the cli script and locate the section of script that
sets platform specific defaults and modify the compiler setting for the
desired platform.
a. Modify the compiler variable tCC and assign it the name of the
alternate C compiler
b. Modify the variable for the C compiler options. The variable is
tCflags. There may be multiple location for the compiler options
variable one for dynamic and one for static linking.
c. For Solaris version of gcc the flags settings for static linking is:
-c -fPIC -O1
EXAMPLE:
for CLI script in 1997.08
"sparcOS5"
tCC=gcc ## modified to use GCC
tLINT=lint
PR="pr -t -l1 -s -1"
tLflags="-I${tIncludeFiles} -u ${tLintLibs}"
if [ "$bStatic" = "" ] ; then bStatic=0
fi
if [ $bStatic -eq 0 ] ; then
tLD=ld
## modified for flags required for cc to run on VSS
tCflags="-c -fPIC -O1 -I${tIncludeFiles}"
tLDflags="-dy -G -z text"
tLibext=".so"
tArchive=libCLI${tLibext}
tArchives=
else
tLD=${tCC}
tCflags="-I${tIncludeFiles}" ## no changes for dynamic
tLDflags="${tCflags}"
tArchive=./vhdlsim
tArchives=" \
${SYNOPSYS}/${SIM_ARCH}/sim/lib/libvhdlsim.a \
${SYNOPSYS}/${SIM_ARCH}/sim/lib/libCLIsupport.a \
${SYNOPSYS}/${SIM_ARCH}/sim/lib/libsimbus.a \
${SYNOPSYS}/${SIM_ARCH}/sim/lib/libwifio.a -lm -ll -ly \
-lsocket -Bdynamic -lm -lc -lnsl -ldl -Bstatic -lsunmath"
for CLI scripts prior to 1997.08 release
case "sparcOS5":
set tCC=gcc ## modify name of the compiler
set tLINT=lint
set PR="pr -t -l1 -s -1"
set tLflags="-I${tIncludeFiles} -u ${tLintLibs}"
if ( ! $?bStatic ) set bStatic = 0
if ( ! $bStatic ) then
set tLD=ld
## modify the flags for static
set tCflags="-c -fPIC -O1 -I${tIncludeFiles}"
set tLDflags="-dy -G -z text"
set tLibext=".so"
set tArchive = libCLI${tLibext}
set tArchives = ( )
else
set tLD=${tCC}
## no mods required for dynamic linking
set tCflags="-I${tIncludeFiles}"
set tLDflags="${tCflags}"
set tArchive = ./vhdlsim
set tArchives = ( ./libvhdlsim.a )
3. Place the modified cli script in the working directory and make sure
the working directory is in the search path for executables before the
path of the installed version of VSS.
4. Run you cli build procedures as before, making sure that the modified
cli script is used.
5. If you have any question about this please send email to the Synopsys
simulation group at sim_supt@synopsys.com
- [ A Synopsys Simulation Support Engineer ]
( ESNUG 276 Item 8 ) ----------------------------------------------- [1/7/97]
From: plaberge@micronpc.com (Paul A. LaBerge )
Subject: Seeking User's Views On Off-The-Shelf Standard ASIC Libraries
Hi John,
I'm fishing for information, horror stories, and user insights concerning
off-the-shelf standard cell ASIC libraries. (In particular, but not limited
to, how they work with Synopsys synthesis.)
John, I know it's your philosophy that each question in ESNUG should teach
something while it asks for something, so, here's what I know of these libs.
Compass:
Seems like these guys invented portable libraries with the introduction
of passport libraries. I liked the technology and they had quite a few
foundries signed up. Their future seems uncertain. They were losing
money and I think bought up (mentor?). I like having the option of
either high performance or high density standard cells available (don't
know if you can mix and match). Didn't see any PCI or GTL+ IOs. Lots
of gates, data path elements, and SRAM compiler.
Aspec:
They are taking it one step further with quickport for porting to new
processes (although unproven). Good I/O cells and memory. A little
behind needing 0.25um technology (estimated soon).
Virtual Silicon Technology:
Good packing density. Quick DRC migration for quick cross-foundry
optimization.
Artisan Components:
Good SRAM compilers? (Don't know. Does anyone else know?)
In-Chip:
Supposed to have good routing technology. (Does anyone know?)
Synopsys Silicon Architects:
I'm always a cynical when it comes to anything from Synopsys. Seems
like there should be some advantages to library and synthesis from the
same company. (Is anyone actually using CBA?)
Cascade:
Seems very similar to Compass. SRAM compilers etc. Looks like good
technology, but I'm not sure how many foundries they support.
Also, which is most used in the industry? Other comments? Does anyone know
of a website, paper, or information comparing pros & cons of these libraries?
Who really owns the market in these types of libraries?
- Paul A. LaBerge
Micron Electronics Inc.
|
|
