( Post 105 Item 1 ) ---------------------------------------------------------
From: landman@hal.com (Howard Landman)
Subject: Synopsys Follow-Up on ESNUG Post 103
John,
About the "bug" I reported:
>Using the 3.0a library compiler, a library which begins:
>
> library(foo) {
>
>compiles fine, but a library which begins:
>
> library(foo)
> {
>
>dies with errors
The official resolution of this from Synopsys is that it's a feature, not a bug.
It's even documented, on p.3-3 of the 3.0 Library Compiler Reference Manual,
where it says:
You must type the group name and the { symbol on the same line.
Apparently their parser is completely incapable of handling data where this is
not done. As far as I can tell, this single line is the only place that this
restriction is documented.
I still think it should be fixed, eventually. For someone who codes C or Perl,
it's a really easy mistake to make, and the error message is not very helpful.
Removing the restriction need not, and should not, break any existing sources.
Howard Landman
Hal Computers
( Post 105 Item 2 ) ---------------------------------------------------------
From: sylvie@ncrcol.columbiasc.NCR.COM (Sylvie Haddad)
Subject: Re: Post 103 Rules of Thumb for Partitioning Designs
Hi John,
In post #103 you asked if anyone knows some handy rules for the
partitioning novice. Following are rules that were suggested to us by
a Synopsys Consultant. I hope they can be of help:
- Keep the entity size small (250-2000 gates)
- Isolate state machines, so they can be optimized separately
- Merge logic that can share resources
- There should not be any glue logic between entities
- Have one clock per entity
- Register all outputs of an entity
- Separate entities with different design goals
- Merge together combinational logic
Sylvie Feghali Haddad
NCR, Midrange Computer Products Division
West Columbia, South Carolina, USA
( Post 105 Item 3 ) ---------------------------------------------------------
From: stevev@cirrus.com (Steve VanAken)
Subject: Re: Post 103 Rules of Thumb for Partitioning Designs
John,
The comments in Post 103 about partitioning are interesting because
I've spent some time investigating ways to do rapid prototyping by
mapping designs to multiple FPGAs. Usually, when multiple FPGAs are
required, the partitioning problem seems at the crux of the overall
problem; and the larger the design, the more difficult the partitioning.
With respect to multiple FPGAs, the major issue is the available
number of I/Os on each device. This, rather than the available number
of logic functions in each device, appears to be the primary resource
limitation in retargeting chip designs to multiple FPGAs. The goal is
to maximize the use of logic gates in each FPGA while not becoming I/O
bound. In practice, this is rare and some compromise between gate
utilization and I/O boundness turns up. This, in turn, creates an
expansion of the retargeted design over its premapped version, and
results in having to use a larger number of FPGAs than expected.
The obvious goal, then, is to create partitions to minimize the
number of interconnects between any given partition and all others in
the design. This is easy to say, but extremely difficult to execute.
The individual(s) charged with the partitioning task ought to have a
thorough understanding of the design's function and structure
-- this makes it possible to exploit the structural locality in
generating the partitions.
At best partitioning is time-consuming and tedious. There at least two
commercially available programs that I've heard of but I haven't used
them. They might be helpful to the partitioning task but I would doubt
if they're better than a knowlegable engineer.
- Steve VanAken
stevev@cirrus.com
( Post 105 Item 4 ) ---------------------------------------------------------
From: rm@hoy.nsc.com (Robert Marshall)
Subject: Plotting question
Can anyone confirm/deny that Synopsys postscript output will not
print to a Sun SPARCprinter (or indeed view in an openlook "pageview"
window), but print okay on other printers with hardware postcript
(eg LaserWriter). This was accepted by Synopsys, Inc. a long time ago as a
bug, but current Synopsys versions still do not work. I wonder if
the problem is universal, or if I have some funny scale factors,etc, set.
Robert Marshall
Telecom Products Group,
National Semiconductor, Scotland
( Post 105 Item 5 ) ---------------------------------------------------------
From: mikefitz@iphase.com (Mike Fitzsimmons)
Subject: a solution(?) to synopsys resource sharing problems
hello john,
i recently had a problem zinging into gates from a verilog behavior that
worked fine. my design had a fifo, and two state machines - one to write
into, and one to read out of, the fifo. the read fifo state machine would
go from idle state to "state 1", where it would determine the most efficient
way to transfer data over the destination bus. this sometimes would involve
waiting for the fifo to have >=32 bytes ( back to back burst). anyhow, both
state machines both had multiple >=, <=, or similar type comparators.
the gates didn't work. i re-wrote the code and compiled into
gates 3 or 4 times thinking it must be my code ( state 1 was the most
complicated of all the states ). i was compiling the two state machines
seperately (along with a lot of other modules), linking all the modules together
on the top level of the chip, and then ungrouping and recompiling with
transition time and a few other constraints.
the gates were failing. the read fifo state machine was getting stuck in
state 1. i finally simulated all behavior, with the verilog netlist
generated for the read fifo state machine being the only gates. it worked!
i then knew there was something funny about the way synopsys was handling
the full chip compilation.
anyhow, the problem turned out to be resource sharing between the two state
machines (and perhaps among other modules in the chip), and i did two things
to solve it:
1) added the folowing command to my compile scripts:
hdlin_resource_allocation = false
2) went into the wfifo and rfifo verilog netlist and searched and replaced
"comp" with wcomp (wfifo) and rcomp (rfifo). this gave the synthetic
comparators unique names, and therefore would avoid sharing. i am not
sure that this step is necessary after 1) above but since i am changing
jobs, i don't have any more time to play with it.
mikefitz@iphase.com
(soon to be mikefitz at VLSI in phoenix, az)
( Post 105 Networking Section ) --------------------------------------------
Opening in AMD for experienced Synopsys user to establish HDL-based design
methodologies. Min. 5 years exp. in design, simulation, and programming.
Contact: Jaime Tolentino at (408) 987-9014, jaime@amd.com, FAX: (408) 987-9001
|
|
