I'm using Design Analyzer command window to
(try and) unset verilogout_unconnected_prefix.
Apparently, this is how to avoid the millions
of SYNOPSYS_UNCONNECTED node
connections to unconnected pins. If
verilogout_unconnected_prefix is not
set, those unconnected pins are left
out of the verilog netlist (according to
examples in the online documention).
I first tried "unset" but this command is not
recognized by dc_shell. Then I tried
remove_variable, but the response I get is
that the system variable cannot be removed.
Then I tried setting the variable to null (""),
but the verilog output still hooks up those
unconnected pins to dummy nodes -- the
only difference is that the dummy node
names are simple integers rather than
integers appended to
"SYNOPSYS_UNCONNECTED".
I can't think of any other way to try, and
nothing comes up on SOLD or Solvnet.
What is the right way to do it?
Fred
-------------------------------------------
Fred Ma
Department of Electronics
Carleton University, Mackenzie Building
1125 Colonel By Drive
Ottawa, Ontario
Canada K1S 5B6
f...@doe.carleton.ca
===========================================
The variable only defines the prefix. If you want
to remove the unconnected ports from your netlist,
use "remove_unconnected_ports".
SolvNet note is Synthesis-878 on "How to remove dead
logic from your design".
Lars
--
Address: University of Mannheim; D7, 3-4; 68159 Mannheim, Germany
Tel: +(49) 621 181-2716
email: lar...@ti.uni-mannheim.de
Homepage: http://mufasa.informatik.uni-mannheim.de/lsra/persons/lars/
It's probably remove_unconnected_ports. I never needed to play with
verilogout_unconnected_prefix once I used it on the design hierarchy.
Caveat: designware-specific attributes are lost in the process (often an
adder/substracter/... has some inputs tied to 0/1 or unused outputs, so
they are prime candidates for that command. And once some of their ports
have been removed, it no longer is a DesignWare part), which may be a
concern in your post-layout IPO methodology (or not).
Regards
--
Jean-Marc Calvez, jmca...@club-internet.fr
Grenoble, France
Good point. Removing unconnected ports, dead logic, etc. should be done
in the final cleanup of the netlist, right before sending it to
the layouter.
But DW info is lost when you get a netlist back from him, with SDF, PDEF,
etc. So the normal IPO compile is not able to reselect DW archs.
> Good point. Removing unconnected ports, dead logic, etc. should be done
> in the final cleanup of the netlist, right before sending it to
> the layouter.
> But DW info is lost when you get a netlist back from him, with SDF, PDEF,
> etc. So the normal IPO compile is not able to reselect DW archs.
>
> Lars
> --
> Address: University of Mannheim; D7, 3-4; 68159 Mannheim, Germany
> Tel: +(49) 621 181-2716
> email: lar...@ti.uni-mannheim.de
> Homepage: http://mufasa.informatik.uni-mannheim.de/lsra/persons/lars/
Actually, I'm not following an ASIC flow, I'm just
using DA for hierarchical netlist manipulation.
The lowest level cells are instantiations of empty
module (designs with ports only and no internal
logic). That's because these are black box cells.
I just tried the remove_unconnected_ports, and
it turns out that all it does is connect all undriven
input pins to 1'b0. All unconnected output pins
are still SYNOPSYS_UCONNECTED. After some
reading it was clear that all cells needed to be
uniquified before remove_unconnected_ports
can do anything significant. So I uniquified all
cells (this is a hierarchically ungrouped design,
so here is only one layer of cells).
Surprise, when remove_unconnected_ports
was applied, *all* interconnect disappeared,
and the black boxes no longer had any ports.
This made sense only after reading the
documentation...since the black boxes did
not internally connect their ports to anything,
all the wires between the black boxes end up
connecting nothing to nothing. So they were
wiped out.
Perhaps I'm using the wrong tool for the job,
since I'm not targetting an ASIC design. I
just want to manipulate a netlist, higher
level of abstraction than gates. In verilog,
it is legal to leave out pins that don't
get used by the parent module, so that's all
i want to accomplish in this step. It looks
like I have to write a script to get rid of all
the SYNOPSYS_UNCONNECTED from the
verilog output. Someone please prove me
wrong....
Fred
Ahh, ok. That sounds like a job for Perl.
Should be easy to do that with a small script.
> fred (Please remove 1st F from my email) wrote:
> > In verilog,
> > it is legal to leave out pins that don't
> > get used by the parent module, so that's all
> > i want to accomplish in this step. It looks
> > like I have to write a script to get rid of all
> > the SYNOPSYS_UNCONNECTED from the
> > verilog output. Someone please prove me
> > wrong....
>
> Ahh, ok. That sounds like a job for Perl.
> Should be easy to do that with a small script.
>
> Lars
Yes, that's what I was thinking. I've printed
out several tutorials to Perl for people with C
experience. Will be using them next. Too bad
that DC doesn't have a switch to deal with this,
but if such a feature isn't used in an ASIC flow,
then that's the real world. Up until this point,
though, the hierarchy traversal and manipulation
of DC is very helpful, and saved me the task
of having to write primitive scripts to do the
same (I had to rip out control path logic,
which was intertwined with datapath logic in
every module). Though it took 2 weeks to
become familiar enough with dc_shell (and
even a brief stint into TCL), it was preferrable.
Come to think of it, it would have been
quicker to manually recode , but extremely
tedious and error prone. Who knows, that
might have taken longer by the time all is said
and done.
Thanks for your help.