( ESNUG 163 Item 1 ) ---------------------------------------------- [11/93]
Subject: (ESNUG 162 #2) 3.0a & b FPGA Compiler / Incorrect Logic - STAR 13749
> The problems and workarounds listed below are of interest to FPGA Compiler
> customers who use the Xilinx 4000 technology and v3.0.
>
> FPGA Compiler has a problem with CLB optimization in the compile command for
> the Xilinx 4000 technology. If a table-lookup output feeds to its own input
> directly, then incorrect logic can result.
From: [ Name Withheld ]
john, if you print this please have my name withheld. we have been using the
synopsys fpga compiler and having all sorts of trouble with it. finally by
the end of yesterday we figured out that the fpga compiler was creating bad
designs. i had planned for the next morning to phone the hotline to give
them #$@%! for this and to write an angry esnug post to boot. then i got
the esnug with my exact fpga bad design bug from their quality department
with the workaround. i totally changed my tune. we tried the fix. it works!
please send an anonymous customer's thanks to your contacts in the synopsys
quality department for this bug and workaround they reported to esnug. we'd
like to see more of these on esnug. it saved a lot of pain on our part.
- Name Withheld
[Editor's Note: I think Quality Engineering now knows how you feel. - John]
( ESNUG 163 Item 2 ) ---------------------------------------------- [11/93]
From: brad@hdls.COM (Brad Eltman)
Subject: Research Results of Wires Models Having Area Affecting Final Designs
John,
I'm still not convinced one way or another about wire areas. I have been
running about 7-10 small to large designs through with wire area of
0 to 100 in increments of 5. Here's a summary of results:
1) For many of the smaller designs there is absolutely no difference in
gate count, number of nets, number of references or timing. (This might
be because we write highly structured (factored) code that Synopsys
finds attractive in terms of the cost function.)
2) For some (not all) of the intermediate designs there is a noticiable
change for the better if the wires have area. The telling point is that
the number of nets and number of references decreases. This does not
always improve the timing of the design. (Although one must believe
that in layout less routing congestion will improve local timing).
3) For larger designs there is no appreciable difference.
4) For some designs (which I believe depends on the type of design) the
number of nets and number of references increases!
CONCLUSIONS:
The increased area is showing up in the optimization cost, therefore in the
cost function -- but I think this is an artifact. The cost function is not
tuned to know that the area is due to a net and is using a misleading
area cost for a gate, but only after selection. I don't think that the net
area is used when deciding what gates to use for initial mapping or during
optimization (the rule base does not understand net area). The rule base is
correcting for the increase in area after the selection is made and may or
may not be able to do anything about it. In fact the corrections may be in
different parts of the design. (Could some of the Synopsys R & D people
comment on this theory?)
The results are totaly unpredictable, some designs will benefit in accounting
for net area, some will do worse. After spending hundreds (literally) of
hours of computer time on this we will probably use it sparingly. Like other
Synopsys commands, for the near future I believe users will need to have a
instinct about when to use this option with a particular design style.
- Brad Eltman
HDL Systems
( ESNUG 163 Item 3 ) ---------------------------------------------- [11/93]
From: uunet!fmicos!splinter!flieder (Jeff Flieder)
Subject: Tricking Synopsys To Use Asynchronous Reset Pins The Way We Wanted
John,
Problem: How do I get Synopsys to use the asynchronous reset pin when I infer
"set" behavior while using the Q_bar output as the data output when I have no
settable latch in my library?
Answer: Synopsys is not very good at using a reset only latch when "set"
behavior is inferred. There is, however a workaround that will use the reset
pin correctly and put the data output on the Q_bar output. Here's an example
on an 8-bit latch where only one bit is set and all the others are reset:
module latchRst(newData,clk,rst,test);
input[7:0] newData;
input clk,rst;
output[7:0] test;
reg[7:0] testReg;
wire[7:0] test = {testReg[7:5],~testReg[4],testReg[3:0]};
always @(clk or rst or newData) begin
if(~rst)
testReg = 8'b0;
else if(clk)
testReg = {newData[7:5],~newData[4],newData[3:0]};
end
endmodule
NOTE: That by assigning the output "test" to have the required inversion,
Synopsys will use the Q_bar output of the latch for the data on bit 4 and
at the same time it will use the asynchronous reset pin as desired!
- Jeff Flieder & Martin Gravenstein
Ford Microelectronics, Inc.
( ESNUG 163 Item 4 ) ---------------------------------------------- [11/93]
From: [ Synopsys Marketing ]
Subject: (ESNUG 158 #4 159 #2 160 #2 161 #1) 'Licensing Wars'
Synopsys has tried to be clear and fair regarding licensing. Unfortunately,
there has been some confusion regarding licensing which has caused some
customers problems including those described in previous postings.
The HDL Compiler family began as simple translators from an HDL to a
gate-level description for logic optimization. We have since added
significant high-level optimization capabilities to the HDL Compilers.
Implementation selection of synthetic components is now a major part
of high-level optimization.
Synopsys has always advertised high-level optimization as part of HDL
Compiler. In fact we intended to license V2.2 to require HDL Compiler's
use during compile in order to get timing-driven implementation selection.
In V2.2 we accidentally did not license it that way. Since it was our
mistake we have made the V2.2-type functionality available without requiring
an HDL Compiler license during compile. NOTE: This only affects Synopsys
customers that have more Design Compiler licences than HDL compiler
licences (which is a relatively small number of Synopsys users.)
For customers who do not need timing-driven implementation selection, in V3.0
HDL Compiler can perform area-based implementation selection prior to compile
by setting "hdlin_replace_synthetic = true" prior to read (See ESNUG 160 #2.)
In this case compile will NOT require an HDL Compiler license.
For customers who want timing-driven implementation selection, the situation
is a little more complicated. Timing-driven implementation selection is only
possible during compile because the necessary timing information is not
available until logic optimization. We made this the default because it
delivers higher quality of results for many applications. Designers can get
timing-driven implementation for their design by doing an initial compile
(which will require an HDL Compiler license) to build a synthetic component
cache. With this cache subsequent compiles will not require an HDL Compiler
license (the equivalence of V2.2).
Future versions of HDL Compiler will have even more high-level optimization
capabilities to further improve quality of results. One example is the
incremental implementation selection available in V3.1. Compile will require
the HDL Compiler license for users to take advantage of all future high-level
optimization functionality.
We hope this clarifies any misunderstandings that may exist with regards to
licensing, and we will make sure to more clearly explain our licensing
mechanisms in the future.
- Synopsys Marketing
( ESNUG 163 Item 5 ) ---------------------------------------------- [11/93]
From: toofan@acuson.com (Mehrdad Toofan)
Subject: (ESNUG 141 #2) "Design Rules Being Ignored Bug" - It's Still With Us!
> John, Recently we encountered a bug with v3.0a-10063. We found that design
> rule constraints were being lost during compiling the design. As a result
> the design rule fix up phase of the compile process was being skipped.
>
> We used "compile -only_design_rule" to work around this problem. Synopsys
> proposed a better work around for this problem (once I convinced them it was
> a bug).
>
> From: [ Synopsys Hotline France ]
>> The issue is that compile() loses the design-rule cost during some
>> sequential optimizations. This problem has been fixed in v3.0b, ...
>>
>> The workaround is to turn off sequential optimization, by saying
>> "seqmap_on = 0" before running compile(). This may reduce the quality
>> of results obtainable in the general case.
Hi John,
We continue to encounter this bug reported in the ESNUG 141 that's been
claimed to have been fixed in Synoposys 3.0b. The problem we have is with the
"max_fanout" design rule. No matter how hard we try, Synposys refuses to
obey this design rule during the compilation. We have tried both setting the
"seqmap_on = 0", as suggested by the article in ESNUG 141, as well as using
"compile -only_design_rule". And the Synopsys hot line claims that they can
not reproduce the bug! We use the following compile script:
current_design = test
max_fanout 10
max_transition 3
compile -map_effort medium
After compiling we see a lot of violations on the fan out. Any clues why?
- Mehrdad Toofan
Acuson
( ESNUG 163 Item 6 ) ---------------------------------------------- [11/93]
From: walp@optilink.com (Pat Walp)
Subject: Why Does Design Compiler Want To Seemingly Always Come Up Short?
A naive question using Synopsys...
I take a simple design, say register/adder/register, create clock with
period 20 ns and compile. I get a circuit that runs at 26 ns. With the
same source code, I relax the period to 40 ns and compile. I get a circuit
that runs at 43 ns.
Obviously the compiler can make a circuit that runs at 40 ns, since it had
successfully made a circuit that runs at 26 ns. Why then does the compiler
stop at 43?
The hotline tells me to set my clock "a lot faster than it needs to be".
This seems ridiculous. What's really going on here? Why does Design
Compiler want to seemingly always come up short?
- Pat Walp
Optilink
|
|
