VHDL syntax

[Grumps]

Hi
I have an issue with a synthesiser and I'm not entirely sure of the response
I recevied from the vendor's support team.

One particular line of code reads:
i(7+(8*c) downto 8*c) := ip;
Where c is a signal.

One of our synethesisers flags this as an error and says the bounds must be
constants. The solution is to declare c as a variable.
Two other synthesisers (inc. Synplify) don't flag this as an error.

If we are declaring c incorrectly, then fair enough. But we are thinking
about moving to using FPGA devices which are supported by their free
software. If we have to re-write a lot of our code, then we won't make the
move.
Thanks for any comments.

 

[Slawek]

Hi,
the slice range should be constant. Dynamically changed slice range
used to be reported as error even in Synplify (year or two ago).
I am not using Synplify recently and I am not sure if it is really supported
in the latest version. I am quite sure that it is not supported in XST or
similar free FPGA synthesis tools.

Best Regards,
Slawek

 

[Grumps]

Hi,
the slice range should be constant. Dynamically changed slice range
used to be reported as error even in Synplify (year or two ago).
I am not using Synplify recently and I am not sure if it is really
supported in the latest version. I am quite sure that it is not
supported in XST or similar free FPGA synthesis tools.

Thanks for the reply.
But surely neither a signal nor a variable are constants. Yet defining c as
a variable prevents the error.
Ah well. The vendor in question has replied and said that they will see if a
change can be made to the next release.

 

[Slawek]

Did you check the post-synthesis simulation?
The workaround with a variable may not work correctly.
The parsers may not notice something suspicious but netlist can be
incorrect.
(Vendors usually talk about next release if something is not working in the
current one).

Best Regards,
Slawek

 

[Grumps]

Did you check the post-synthesis simulation?

No, not yet.

The workaround with a variable may not work correctly.
The parsers may not notice something suspicious but netlist can be
incorrect.

Synplify, a couple of years ago, would flag this as an error. The latest
version does not. I'd hope that this is because they now handle it correctly
and generate a proper netlist. I know Xilinx's ISE9 produces the correct
output (it works in simulation and in a real device).

 

[James Unterburger]

Just for the record, there is nothing wrong with the syntax here,
so the subject line is misleading. All compliant simulators will
be able to simulate this, given that "c" (constant, variable, or signal)
is of some integer type the same as the index subtype of the base type
of "i", and that its value results in a valid slice
of "i" having the same number of array elements as "ip".

What synthesis tools can or can't do is not related to how the
language is defined.

 

[Grumps]

Just for the record, there is nothing wrong with the syntax here,
so the subject line is misleading.

Thanks. I just couldn't think of a sensible subject.

All compliant simulators will
be able to simulate this, ... <snip>

What synthesiser feature/specification suggests compliance?

 

[James Unterburger]

In general, a synthesis tool will handle only a subset of
the language definition as described in the LRM, so in a
strict sense, there is no such thing as a compliant systhesis
tool. Such a synthesis tool should at least recognize its own
limitations, however, and report that such and such a feature
of the language is not supported by it, in a sense pointing
a finger at itself, rather than at the user (whose VHDL code
is in fact legal but not synthesizable).

A simulator, on the other hand, has a duty to implement as
much of the LRM as possible (noting that there are ambiguities),
and as above, report that such and such, though legal, is not
supported when such a feature of the language has not been
implemented. I would wager that there is no such thing
as a 100%-compliant compiler/simulator tool either.

 

[Grumps]

In general, a synthesis tool will handle only a subset of
the language definition as described in the LRM, so in a
strict sense, there is no such thing as a compliant systhesis
tool. Such a synthesis tool should at least recognize its own
limitations, however, and report that such and such a feature
of the language is not supported by it, in a sense pointing
a finger at itself, rather than at the user (whose VHDL code
is in fact legal but not synthesizable).

A simulator, on the other hand, has a duty to implement as
much of the LRM as possible (noting that there are ambiguities),
and as above, report that such and such, though legal, is not
supported when such a feature of the language has not been
implemented. I would wager that there is no such thing
as a 100%-compliant compiler/simulator tool either.

Which would all seem to mean that you cannot guarantee that your VHDL code
is fully transportable between different compilers.
Thank heavens that the VHDL code that I write is very simple.

 

[Jim Lewis]

Grumps,

What synthesiser feature/specification suggests compliance?

IEEE 1076.6 specifies VHDL RTL Coding. Unfortunately 1076.6-2004
(the most current) states:
For a discrete range that appears as part of a slice name,
the bounds of the discrete range shall be specified
directly or indirectly as static values belonging to an
integer type.

I am not sure about your application, but for some of mine,
this needs to be updated.

In general, if you have issues of language compliance, in which
different vendors disagree or you and a vendor disagree, and
you can get cooperation from the vendor, you can
also get an official language resolution from the VHDL Issues
Screening and Analysis Committee (ISAC). Please make sure to
keep the vendor's name out of the issue report - the ISAC worries
about compliance - once you receive the compliance report, you
can deal with the vendor. =You can report issues to ISAC at:
http://www.eda-stds.org/vasg/#Enhancements

For synthesis issues click on: "Report a BUG on an IEEE VHDL revision"


Best Regards,
Jim Lewis
IEEE VHDL and Analysis Standards Group (VASG) Chair
SynthWorks VHDL Training