Question regarding pragma translate_off/on , synthesis_off/o

Hi all,
Can anyone tell me what should be the ideal behaviour for a
synthesis tool regarding the pragmas translate_off/on and
synthesis_off/on ?
My question is, can we nest the pragmas one inside the other ?
like say ..

-- pragma translate_off
-- pragma synthesis_off
.... (some logic here)
-- pragma synthesis_on
-- pragma translate_on

or

-- pragma tranlate_off
-- pragma synthesis_off
....(some logic here)
-- pragma tranlate_on
-- pragma synthesis_on

I have heard that DC ignores such nesting and take the outermost
into account. Can you tell me what is the behaviour of other tools ?

Thanks.

 

[Hubble]

Hi,

these pragmas (actually comments) are an add-on of synthesis tools and
completeley without standardization (to my knowledge). They should be
used to disable warnings for code which checks parameters, but is not
synthesizable.

Unfortunately, they demonstrate the lack of an appropriate preprocessor
for VHDL.

If you want to disable/enable logic, use boolean generics and if
statements:

GENERIC in_synthesis: boolean:= true;
..

If not in_synthesis then
... (some logic here)
end If;

When simulating, set the generic in_synthesis to false.

The ideal behaviour of synthesis tools is not to have such pragmas
(instead pragmas warnings_off/warnings on)

This is completely inside the VHDL standard and should be possible in
most cases. Nesting is no problem.

Hubble.

 

[Jim Lewis]

Rob,

The problem with pragma's is that there is no written spec on how they should work. So if you can, try to avoid them.

Does Verific support the following?
-- RTL_SYNTHESIS OFF
-- RTL_SYNTHESIS ON



No, we don't.

Not surprising as I don't think anyone does.
The point of my question was to illustrate that
the process of standards being made by benevolent
experts does not always work well.

No, we don't. Mainly because these are never used by HDL designers.
Why support something that is not used, and for which there is already
an existing solution ?

This illustrates the classic stand-off:
Vendors: Why implement a new feature if no-one uses it.
Users: Why use a new feature if not all the vendors in
my current design flow implement it.

Without devine intervention, this process will never work.

We support pragma's which are used in real life EDA tools :
-- <pragma_trigger> translate_off
-- <pragma_trigger> translate off

pragma_trigger> by default includes the defacto standard vendor names.
This was the template used by all vendors, and there is/was no need to change that.

You are right.

To be fair, 1076.6 was developed in the time frame between
1996 and 1998 and the only common pragma trigger that
I was aware of was "-- synopsys". I think "-- pragma"
either came out during the same time or a little later.

The WG chose the pragma trigger "RTL_SYNTHESIS".
One reason was to differentiate RTL from behavioral
synthesis. Since VHDL was taking so much abuse about
having long names, rather than translate_off and
translate_on it was shortened to OFF and ON.

Based on your template, the IEEE pragma would adds the
format:
-- <pragma_trigger> off

This does not seem unreasonable or difficult to implement.
We would only need one flavor if all tools supported the
same one.


Also note that if the standard is broken there is
no reason not to fix it.

But even for the RTL_SYNTHESIS OFF pragma, there is no definition
of hiw to deal with nesting (and with mixing-in existing pragma's).

True. Have you submitted a issue report with respect to this?
ISAC is alive and working to make sure all issues get forwarded
to the right place and so they can be worked on.

I was involved in the 1076.6 working group, back in the early 90s.

Since your product is integrated into 35 vendor tools,
you really should be part of the current standards process.

My main point is that we have a new standards organization
called Accellera. They are working hard to create standards
that represent user priorities. Users will want to use
these features. Your wisdom will certainly help us create
something better than we could without you. Furthermore,
if cost is an issue, non-members can participate, they just
can't have an official vote on all items. Note that this
year VHDL has lots of work that needs to get done so anything
you can do to help funding would be greatly appreciated.

Best Regards,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Eric DELAGE]

We support pragma's which are used in real life EDA tools :
-- <pragma_trigger> translate_off
-- <pragma_trigger> translate off

pragma_trigger> by default includes the defacto standard vendor names.
This was the template used by all vendors, and there is/was no need to
change that.

You are right.

You're wrong. I develop VHDL code for multiple VHDL compilers from
Xilinx, Synopsys and Synplicity. According to your convention, I
should write:

-- synopsys translate_off
-- xilinx translate_off
-- synplicity translate_off
.... my code ...
-- synplicity translate_on
-- xilinx translate_on
-- synopsys translate_on

If now, I want to compile my VHDL code for Altera and use its Quartus
compiler, I should look for the pragmas in all my VHDL files and add
your --altera translate_off/_on. Honestly, I think that you miss the
point for standardization ;-)

It's funny to know that Synplicity supports the -- SYNOPSYS pragmas
and that Synopsys supports the standardized -- RTL SYNTHESIS_ON/_OFF
ones (as well as the -- SYNOPSYS). In this mess, I would rather
suggest to use:

-- RTL SYNTHESIS_OFF
-- <your vendor @ a point in time> TRANSLATE_OFF
.... my code ...
-- <your vendor @ a point in time> TRANSLATE_ON
-- RTL SYNTHESIS_ON

and to put your EDA vendor under high pressure to add the official
standardized pragmas in its VHDL parser. Designers are responsible for
informing them again and again on their needs incl. their need for
standardization.

Eric