( ESNUG 158 Item 1 ) ---------------------------------------------- [10/93]
From: dilip@sv.gpsemi.COM (Dilip Kumar)
Subject: (ESNUG 154 #3 156 #1 157 #1) "Wires Having Area - Is It Used?"
John,
After reading postings on area in wire_load models and different reactions
from numerous users, I would like to answer the same question using an
example, which makes it clear that synopsys uses interconnect area during
optimization. (As a matter of fact, it's easy to get tricked if someone is
synthesizing a circuit having a few number of interconnects only.)
Let's consider an example of a wire_load model called "TRICK".
wire_load (TRICK) {
resistance : 0 ;
capacitance : 42.0 ;
area : 0.1 ; /* NOTE: This says area is 0.1X per unit wire length */
slope : 0.1 ;
fanout_length(10,1) ;
}
And, the cell-area of components in the library are as follows:
NAND4 - 2 area units
OR2 - 2 area units
NAND8 - 7 area units
Using the same verilog example which Cindy used:
module wire8(out,in);
output out;
input [7:0] in;
assign out = ~(&in); /* an 8 bit AND gate with Inverted Output */
endmodule
Synopsys synthesized the circuit with two NAND4s, and an OR2 with the
following reports:
combinational area: 6 (2 + 2 + 2)
Net interconnect area: 0.11
Total area: 6.11
Accounting for the interconnect area:
fanout = 11 (look for report_net)
wirelength = 1.1 (look for the line: fanout_length(10,1) in wire_load model)
Interconnect area = 0.11 (= 1.1 * 0.1)
In order to synthesize the circuit with a NAND8 using the same wire_load
model, the circuit has to be larger with more number of gates and
interconnects. How large the circuit should be, can be calculated,
approximately, using the following "equation" for this particular example:
(6 + 1.1 * X) > (7 + 0.9 * X) [where X is the minimum area in
the wire_load model]
| | |
| | |__ # of interconnects = 9 while using NAND8
| |
| |_______ area of NAND8 in the library
|
|_____________________ area of two NAND4s and an OR2
ie, x > 5, which implies that the minimum gate-area should be 500 (=10*5/0.1)
for synthesis to use NAND8 with the above wire_load model.
To be on the safe side, let's try area=10 (which is as good as using a
gate-area of 1000 in the real world) in the above wire_load model.
It synthesized into a NAND8 gate with the following report on area:
combinational area: 7
Net interconnect area: 9
Total area: 16
Synopsys used the best of the options during area-optimization, which would
otherwise have been implemented with two NANDs and an OR, occuping an area
of 6 + 1.1 * 10 = 18
- Dilip Kumar
GEC Plessey Semiconductors
( ESNUG 158 Item 2 ) ---------------------------------------------- [10/93]
From: uunet!fmicos!splinter!flieder (Jeff Flieder)
Subject: (ESNUG Post 157 #4) "3.0b Latch Inferencing"
> In V3.0a, you could infer latches on a "slice" of a register bank and get
> predictable results. In V3.0b, the latch inference does not recognize
> asynchronous resetson register "slices". An example will probably make this
> as clear as mud, so here goes.
>
> reg [15:0] data;
>
> always @(data or gate or reset) begin
> if (!reset)
> data[7:0] = 0;
> else if (gate)
> data[7:0] = someNewData;
> end
>
> You would expect this to give you 8 latches with the reset signal tied to an
> asynchronous reset pin. In 3.0a, that is exactly what you will get. In 3.0b,
> you will get the gate and reset signals gated into the gate input, and the
> someNewData and reset signals "muxed" or "AOIed" into the data input. Not at
> all what you wanted.
John,
Thought I'd pass along the solution I found to this bug I posted earlier.
The fix for this is to set the default latch algorithms back to those used in
3.0a for asynchronous resets. Issue the command:
hdlin_latch_synch_set_reset = "false"
This will put the asynchronous resets back on the reset pin where they belong.
- Jeff Flieder
Ford Microelectronics
( ESNUG 158 Item 3 ) ---------------------------------------------- [10/93]
From: nathalie@txc.com (Nathalie Sosa)
Subject: Synopsys Netlist EDIF Writer Fails With Multidimensional Arrays
John:
The Synopsys EDIF writer fails with multidimensional arrays, such as an array
of std_logic_vector, when edifout_numerical_array_members is set to true.
A pin or port corruption error results and the EDIF file does not get written
at all. This is a known Synopsys bug and is documented in the Synopsys
Release Notes for Synthesis, v3.0b.
If we set edifout_numerical_array_members to false, however, we get the bits
reversed on all the busses in the output EDIF file (ESNUG 147 Item 3).
At this time, the only known workaround is to flatten all of the busses
before writing EDIF by setting:
edifout_no_array = "true"
and creating the schematic in dc_shell with -no_bus option. (you need to
create a schematic before you can write EDIF).
1) Does anyone know of any other workaround that does not involve
flattening all of the busses?
2) Does anyone know of any other workaround to the bit reversing problem
other than setting edifout_numerical_array_members to true?
3) We would like to bring our edif file(s) into a TI GOOD database, run TI
tools and then do back-annotated timing analysis in both Synopsys and
IKOS. Has anyone ever done back-annotated timing analysis on a design
with flattened busses? Were there any problems?
Any information at all on this problem would be greatly appreciated. We are
rapidly approaching the back-end of our project cycle and are horrified
at the thought of having to rewrite any VHDL at this late stage in the game.
- Nathalie Sosa
TXC
( ESNUG 158 Item 4 ) ---------------------------------------------- [10/93]
From: [ Anonymous ]
Subject: There Should Be A Switch To Disable The DesignWare "Feature"
Hello John,
Please post this anonymously.
When we used 2.2 and earlier, we have twice as many Design Compiler licenses
as HDL compiler licenses as we did not need to buy more HDL licenses than we
needed. Now, with Synopsys 3.0X, Design Compiler jobs crash if there is not
an equal number of HDL compiler licenses to Design Compiler licenses. The
reason for this is DesignWare. We don't use DesignWare at all, but
Synopsys 3.0X has the hooks built into DesignWare that automatically grabs
a HDL license when it thinks it needs to build parts. We have 4 options:
1.) decrease the number of Design Compiler licenses
2.) increase the number of HDL compiler licenses
3.) return to Synopsys 2.2b
4.) waste time finding a workaround
I think Synopsys should allow a switch to let users decide if they want
to use DesignWare or not. We'd immediately disable the DesignWare "feature"
and synthesize like we always have!
- Anonymous
|
|
