VHDL syntax

G

Grumps

Guest
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.
 
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" <grummps@hotmail.com> wrote in message
news:58reoeF2hj35mU1@mid.individual.net...
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.
Click to expand...
 
Slawek wrote:
"Grumps" <grummps@hotmail.com> wrote in message
news:58reoeF2hj35mU1@mid.individual.net...
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.

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.
Click to expand...
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.
 
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" <grummps@hotmail.com> wrote in message
news:58rqi3F2i297bU1@mid.individual.net...
Slawek wrote:
"Grumps" <grummps@hotmail.com> wrote in message
news:58reoeF2hj35mU1@mid.individual.net...
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.

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.
Click to expand...
 
Slawek wrote:
"Grumps" <grummps@hotmail.com> wrote in message
news:58rqi3F2i297bU1@mid.individual.net...
Slawek wrote:
"Grumps" <grummps@hotmail.com> wrote in message
news:58reoeF2hj35mU1@mid.individual.net...
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.

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.

Did you check the post-synthesis simulation?
Click to expand...
No, not yet.

The workaround with a variable may not work correctly.
The parsers may not notice something suspicious but netlist can be
incorrect.
Click to expand...
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).

(Vendors usually talk about next release if something is not working
in the current one).
Click to expand...
 
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 wrote:
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.
Click to expand...
 
"James Unterburger" <jamesu@europa.com> wrote in message
news:4628f9d1$1@solnews.wv.mentorg.com...
Grumps wrote:
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.

Just for the record, there is nothing wrong with the syntax here,
so the subject line is misleading.
Click to expand...
Thanks. I just couldn't think of a sensible subject.

All compliant simulators will
be able to simulate this, ... <snip
Click to expand...
What synthesiser feature/specification suggests compliance?
 
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 wrote:
"James Unterburger" <jamesu@europa.com> wrote in message
news:4628f9d1$1@solnews.wv.mentorg.com...

Grumps wrote:

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.


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?
Click to expand...
 
"James Unterburger" <jamesu@europa.com> wrote in message
news:462cef45$1@solnews.wv.mentorg.com...
Grumps wrote:
"James Unterburger" <jamesu@europa.com> wrote in message
news:4628f9d1$1@solnews.wv.mentorg.com...

Grumps wrote:

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.


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?

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.
Click to expand...
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.
 
Grumps,
What synthesiser feature/specification suggests compliance?
Click to expand...
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
 
On Apr 23, 4:36 pm, Jim Lewis <j...@synthworks.com> wrote:
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
Click to expand...
While most synthesis tools will accept non-static expression in
ranges, they also usually must implement the computational circuitry
for those expressions in hardware.

If it is possible to code it in a for loop with an if statement,
comparing the unadulterated signal to an expression of the index, then
the index is treated as if "static" when the loop is unrolled, and the
computation of the expression is not done in hardware. Therefore such
expressions are also not limited by what is implementable in hardware
(i.e. divide/modulo by non-integral-powers of two, etc.).

Andy
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top