> 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.
That may not be entirely true. Sequential elements do go through many
optimizations like register sharing/collapsing which could blow away
the original signals at the outputs of these sequential elements.
Apurva
> From owner-vlog-synth@vhdl.org Tue Jul 7 23:45 IST 1998
> X-Authentication-Warning: server.eda.org: majordom set sender to owner-vlog-synth@vhdl.org using -f
> Date: Tue, 7 Jul 1998 11:07:19 -0700
> From: Don Hejna <djhejna@rhino.ambit.com>
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> To: <frm145@microtec.net>
> Cc: <mac@surefirev.com>, <btf@boyd.com>, <vlog-synth@eda.org>,
> djhejna@ambit.com
> Subject: Re: pragmas
> X-Mailer: VM 6.34 under Emacs 20.2.1
> Reply-To: djhejna@ambit.com
> Sender: owner-vlog-synth@eda.org
>
>
> If you are going to add
>
> // 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
> >
>