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.

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.

"Hubble" <reiner@huober.de> writes:

<snip>

> 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;
> 

I do this in a package:

    CONSTANT in_simulation : BOOLEAN := false
--synthesis translate_off
                                        OR true
--synthesis translate_on
;
    CONSTANT in_synthesis : BOOLEAN := NOT in_simulation;

Then I don't have to worry about remembering to change the constant
when I synthesize.  And there's only one set of pragmas in the whole
design to worry about.

Cheers,
Martin


-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Hi Suman,

Verific DOES allow nesting of translate_off pragma's.
The Verific parsers are used in some 35 EDA tools, including
synthesis and verification tools.
For example, Altera's Quartus II synthesis uses the Verific's parsers,
and thus it will support translate_off nesting.

Sometimes nesting happens legally in the standard VHDL packages, albeit
under different 'vendor' translate_on/off pragma's.
Verific needs to be complient with many different tools, and thus needs to
be sensitive to many tool vendor pragma's. Thus support for nesting was needed.

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.

Rob

<suman.nandan@gmail.com> wrote in message news:1121403963.905016.111000@z14g2000cwz.googlegroups.com...
> 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.
> 

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

I dispute your claim about there being no written spec.
You will find these synthesis directives specified
and standardized in IEEE 1076.6-1999.

In the EDA community we have a major disconnect
between EDA vendors, users, and standards developers.
We need to proactively solve this problem.

The old methodology of a group of experts collectively
developing and publishing a standard is not working.
The problem is that after developing new features, the
features need to be marketed to the user community
and then the user community needs to nag the EDA vendors
to implement the new features.

There is no one party that the blame can be placed on.
Standards developers sometimes do not address users
needs.  Users do not have time to nag the EDA vendors.
EDA vendors do not have enough revenue to benevolently
implement features that have little value to the
user community and, hence, their product.

There are changes happening in the EDA standards
community.  Recently Accellera was granted rights
by IEEE to make derivative works of the VHDL
standard (IEEE 1076) and has formed a VHDL working
group.  While it is still in its early stages its shows
promise of having a model that will ensure that user
prioritized features get standardized.  This in turn
will reassure EDA vendors that their product will have
a higher value to their users if they implement the
newly standardized features.

SynthWorks firmly believes in this process and has
become a member of Accellera to support this effort.

I urge experienced VHDL users to participate in this
effort.  I suspect that most of the the meaningful
language revisions to VHDL will be done by the
Accellera WG.  The VHDL-200X Fast Track work, which
is currently held up by lack of funding, has been
submitted the Accellera WG for their consideration,
prioritization, and funding.   Currently funding is
necessary to fund the task of LRM writing.

While non-members of Accellera do not have an official
vote, you do have influence in the form that well
thought out discussions are generally given
consideration.  One way to look at it is there are
very few organizations of this type that will turn
away free labor.

Best Regards,
Jim Lewis
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"Jim Lewis" <Jim@SynthWorks.com> wrote in message news:42D9722E.9000409@SynthWorks.com...
> 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. 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 ?

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.

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).

> I dispute your claim about there being no written spec.
> You will find these synthesis directives specified
> and standardized in IEEE 1076.6-1999.

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

The charter of 1076.6 was honest and and well-intended,
but I think that the effectiveness of the the group
was greatly compromized when
  (1) Synopsys walked out, and
  (2) the group started to re-invent new stuff rather than
       focus on defining behavior of existing industry standards
      (such as pragma's), for backward compatibility, and
  (3) it costs $100 just to get a copy of the work group results.

>
> In the EDA community we have a major disconnect
> between EDA vendors, users, and standards developers.
> We need to proactively solve this problem.
>
> The old methodology of a group of experts collectively
> developing and publishing a standard is not working.
> The problem is that after developing new features, the
> features need to be marketed to the user community
> and then the user community needs to nag the EDA vendors
> to implement the new features.
>
> There is no one party that the blame can be placed on.
> Standards developers sometimes do not address users
> needs.  Users do not have time to nag the EDA vendors.
> EDA vendors do not have enough revenue to benevolently
> implement features that have little value to the
> user community and, hence, their product.
>
> There are changes happening in the EDA standards
> community.  Recently Accellera was granted rights
> by IEEE to make derivative works of the VHDL
> standard (IEEE 1076) and has formed a VHDL working
> group.  While it is still in its early stages its shows
> promise of having a model that will ensure that user
> prioritized features get standardized.  This in turn
> will reassure EDA vendors that their product will have
> a higher value to their users if they implement the
> newly standardized features.
>
> SynthWorks firmly believes in this process and has
> become a member of Accellera to support this effort.
>
> I urge experienced VHDL users to participate in this
> effort.  I suspect that most of the the meaningful
> language revisions to VHDL will be done by the
> Accellera WG.  The VHDL-200X Fast Track work, which
> is currently held up by lack of funding, has been
> submitted the Accellera WG for their consideration,
> prioritization, and funding.   Currently funding is
> necessary to fund the task of LRM writing.
>
> While non-members of Accellera do not have an official
> vote, you do have influence in the form that well
> thought out discussions are generally given
> consideration.  One way to look at it is there are
> very few organizations of this type that will turn
> away free labor.
>
> Best Regards,
> Jim Lewis
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> > 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

"Eric DELAGE" <eric_delage@yahoo.fr> wrote in message news:75b8d52e.0507190349.7e5c010a@posting.google.com...
>> > 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

Yeah, it's a mess out there.
But you won't need to (and should not) enumerate all vendors in your translate_off pragma's.

Apart from the vendor-specific pragma's the 'general' form of the pragma is
-- synthesis translate_off
-- synthesis translate_on

Since the purpose of the pragma is to let a synthesis tool ignore certain
portions of text, this seems the most obvious pragma.
I believe this is supported by all vendors.

Also, -- pragma translate_off is pretty much a general defacto-standard,

>
> 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 ;-)

Frankly I don't see how standardization could help here.
There will always be vendors which want their own pragma's, to offer
immediate work-arounds for problems with their tool in customer designs.
Many of these pragma's are really intended for that specific tool only.
So, as a user, just avoid these as the plague !

>
> 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

You just invented yet another pragma-trigger : -- RTL
I don't think that is a good idea.

Also, since pragma 'nesting' is not necessarily supported by some
tool vendors, you might want to avoid this too.

>
> 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.

I think it is much easier to follow the de-facto standard :
-- synthesis translate_off is your standard for text off/on pragma's.

Apart from that, just ask your vendor if the tool is Verific-complient.
Much easier than trying to push for a pragma standard.

Thanks for your input !

>
> Eric 

"Jim Lewis" <Jim@SynthWorks.com> wrote in message news:42DC6DFF.5010100@SynthWorks.com...
> 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.
>

I understand. And it did not for this pragma, and other 1076.6 'synthesis' features.

But it did work for VHDL itself !!
The 1076 87 and 93 standards are so complete and accurate,
that there is virtually no way for a tool builder to 'hide' behind LRM ambiguities,
and in turn this greatly enhanced tool-interoperatebility.

>
>> 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.
>

Right.
If translate_off pragma's is all that we talk about, then I think that with VHDL,
the process is nicely under control, caused by the tight and
unambiguous VHDL standards.

The situation is MUCH worse for Verilog...

>
>> 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.
>

It's not difficult to implement, but we are not solving a problem here.
How many ways do we need to exclude text for a tool ?
Just use -- synthesis translate_off

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

If you want to persue this for a standards change, then I seriously
recommend to change it to -- synthesis translate_off

If you want, could you also propose a standard for the
real pragma's ? The ones that define a synthesis implementation for
VHDL functions ? Things like :

 -- pragma map_to_operator SUB_UNS_OP
 -- pragma type_function LEFT_UNSIGNED_ARG

There is a far greater veriety there than on the translate_off pragma

Problem with pragma's :

The cat is already out of the bag.
Tool builders need to support existing functionality, and thus at this point
(18 years after the standard came out), it fruitless to start an additional
standardization process.

>
>> 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.
>

No, I did not. Since there is no need for this pragma.

I am no longer directly involved in language standardization.
But indirectly, the Verific parsers are setting a standard by themselves.
We are complient with all major vendors pragma's and language
support, for a wide range of tools and applications.

So if every vendors would use Verific, tool interoperability problems
due to issues that we missed in the language LRM, will become less
and less of a problem. And that helps everyone.

>
> > 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.
>

I would like Accellera to slow down.
Does us joining Accellera help for that ?
System Verilog 3.1a is more than complex enough to let front-end builders
work for a couple of years. Nobody can use it currently,
since there is no complete 3.1a simulator yet, and most tools are lacking SV support.

Other than that, I think that tool builders like Verific should not interfere
too much with language features required or desired by designers.

Languages should be driven by users, not by parser builders.
But if there would be an efford to standardize the old (non-standardized,
yet ultimately critical feature of) -v/-y XL options
(library reading for Verilog 95), then I will be the first one
to join the effort.

We might join Accellera, or at least will issue feedback for
existing LRM 3.1a ambiguities or incompleteness.
We found many such issues already.

> 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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~