Jim Lewis said:
Rob,
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.
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...
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.
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.
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.