In the creation of ESNUG, I've received a lot of help from many individuals
at Synopsys. I guess this was something that not only the users have
been wanting to see for a long time, but also the employees at Synopsys
felt they should have created but didn't get around to doing.
Nevertheless, Synopsys has set up (what I'm told) is an internal e-mail
exploder that distributes ESNUG posts to the people inside the company
including the very software designers who've written the code you're
using today!
Also, they've said that they're going to send me the list of e-mail
addresses of the engineers who went to this year's SNUG. Right
now we have a readership of over 500 people; this addition will
make it even more!
-John Cooley
( Post 51 Item # 1 ) -------------------------------------------------------------
[ Moderator's Note: This looks very similar to the bug in Post 48
Item 1, but that didn't involve buses - this does. ]
From: Marco.Rubinstein@eua.ericsson.se (Marco.Rubinstein)
Hi!
I am working with ASICS at Ericsson Telecom and have encountered a problem
with verilog netlists from Synopsys 2.3. If the module port contains an
output bus which is reg declared further down in the code, the tool splits
up the output bus and renames the constituent bits. It then produces
assign statements to associate the output bus with the new bit names
e.g.
RTL code
=========
..........
output [7:0] ML_OUT;
..........
reg [7:0] ML_OUT;
Netlist
========
.........
output [7:0] ML_OUT;
.........
assign ML_OUT[7] = ML_OUT_7;
assign ML_OUT[6] = ML_OUT_6;
assign ML_OUT[5] = ML_OUT_5;
assign ML_OUT[4] = ML_OUT_4;
assign ML_OUT[3] = ML_OUT_3;
assign ML_OUT[2] = ML_OUT_2;
assign ML_OUT[1] = ML_OUT_1;
assign ML_OUT[0] = ML_OUT_0;
........
This does not happen if the output bus in not reg declared further down.
I think this is a bug since assign statements don't belong in netlists.
Does anyone know of a remedy?
I would hate to have to use dummy buses as an extra layer between the real
output bus and the internally produced constituent bits. It would quite
confuse some of the designers, and the rest of them would forget to do it.
/Marco
( Post 51 Item # 2 ) -----------------------------------------------------------
CALL FOR DISCUSSION! CALL FOR DISCUSSION! CALL FOR DISCUSSION!
A number of readers have been asking for the discussion
of what others have done when compiling larger hierarchical
designs. Questions asked are:
- What scripts have you found work well for large designs?
- Are there ways to avoid getting into situations where you
find yourself in an endless loop of iterating through
recompiles, characterizings and such?
- What gatecounts have you found that work best for submodule
size? Where's the practical limit to when a design is too
big to not synopsize heirarchically?
- How do you handle JTAP modules and scan architectures here?
|
|
