// pragma signal_name preserve_signal
then you better add
// pragma preserve_initial_instance_footprint
Which would stick a "dont_modify" the initial mapped cell and not
change its footprint (i.e. it could be upsized/downsized only).
Since the process of optimization removes all nets restructures
boolean equations and maps them to technology specific cells and
creates the necessary nets to connect them.
Consider
assign foo_temp = b & c; // pragma signal_name "foo_temp"
assign foo = a | foo_temp;
What you are forcing the tool to do is implement:
AND i_0(foo_temp, b, c);
OR i_1(foo, foo_temp, a);
When it would naturally pick the faster more efficient:
AO2 i_0(foo, a, b, c);
However if we narrow the pragmas use to outputs of sequential elements
we begin to have a ghost of a chance since sequential elements dont
generally go through restructuring.
Incidentally, most synthesis tools already preserve the signal name at
the Q output of flop anyway so you dont get a whole lot of new
functionality here.
Also to be effective, this type of pragma would have to be written out
in the gate-level netlist so that IPO and other post-synthesis
optimizations preserve the signal name as well (a lot to ask from your
ASIC vendor) and write it out in thier output as well.
Don't get me wrong I like the idea, but loath the implementation and
its effect on the final netlist. Frankly I cant see synthesis tools
supporting it.
-Don
frm145 writes:
> Yeah I like this pragma to preserve signal name during synthesis. This
> allows the signal
> to be observable from the top in gate level simulation. Is it introduced.
>
> > // Don't collapse signal and use this signal name in place of any other
> > naming option.
> > // pragma signal_name preserve_signal
>
> ----------
> > From: Michael McNamara <mac@surefirev.com>
> > To: btf@boyd.com
> > Cc: vlog-synth@eda.org
> > Subject: pragmas
> > Date: July 6, 1998 7:04 PM
> >
> >
> >
> > I am also on the Verilog Synthesizability group (1364.1), and
> > one issue they have is trying to standardize the
> >
> > // synopsys parallel_case
> >
> > directives.
> >
> > They are proposing a buch of stuff, in the context that they
> > can not change the language.
> >
> > But of course, what would be much better, is if we would
> > introduce a pragma to the language, and go further and define some
> > pragmas, while leaving others for vendors extentsions.
> >
> > I propose we introduce a new tick define, `pragma
> >
> > Further, we introduce a set of pragmas as follows:
> >
> > `pragma rtl_full_case
> > Tells the system that every value is decoded.
> >
> > `pragma rtl_parallel_case
> > Tells the system that each case_item is mutually exclusive,
> > and hence a full priority decoder (if then [else if then]* )
> > is not needed.
> >
> > `pragma rtl_translate_on
> > `pragma rtl_translate_off
> > Turns on and off synthesis translation. Can be used to wrap
> > design verification code.
> >
> > I asked the list what other pragmas they wanted, and one of the
> > gentlemen (Ken Coffman <kcoffman@atvideo.com>) said:
> >
> > other pragmas I'd like to see:
> >
> > // Define pin assignment.
> > // Hierarchal assignment should be possible.
> > // Pin assignment example 1
> > // pragma signal_name pin_number nnn
> >
> > // Pin assignment example 2
> > // pragma top_module_name1.lower_module_name2.signal_name pin_number nnn
> >
> > I know we can sometimes infer the following, but I'd rather command the
> > hardware to synthesize a certain way.
> >
> > // Assign signal to clock enable if supported by hardware.
> > // pragma signal_name clock_enable
> >
> > // Assign signal to global clock resource if supported by hardware.
> > // pragma signal_name global_clock
> >
> > // Assign signal to global reset resource if supported by hardware.
> > // pragma signal_name global_reset
> >
> > // Assign signal to global preset resource if supported by hardware.
> > // pragma signal_name global_preset
> >
> > // Don't collapse signal and use this signal name in place of any other
> > naming option.
> > // pragma signal_name preserve_signal
>