VHDL syntax

Discussion in 'VHDL' started by Grumps, Apr 20, 2007.

  1. Grumps

    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.
    Grumps, Apr 20, 2007
    #1
    1. Advertising

  2. Grumps

    Slawek Guest

    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" <> wrote in message
    news:...
    > 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, Apr 20, 2007
    #2
    1. Advertising

  3. Grumps

    Grumps Guest

    Slawek wrote:
    > "Grumps" <> wrote in message
    > news:...
    >> 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.
    Grumps, Apr 20, 2007
    #3
  4. Grumps

    Slawek Guest

    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" <> wrote in message
    news:...
    > Slawek wrote:
    >> "Grumps" <> wrote in message
    >> news:...
    >>> 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.
    >
    Slawek, Apr 20, 2007
    #4
  5. Grumps

    Grumps Guest

    Slawek wrote:
    > "Grumps" <> wrote in message
    > news:...
    >> Slawek wrote:
    >>> "Grumps" <> wrote in message
    >>> news:...
    >>>> 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?


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

    > (Vendors usually talk about next release if something is not working
    > in the current one).
    Grumps, Apr 20, 2007
    #5
  6. 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.
    >
    >
    James Unterburger, Apr 20, 2007
    #6
  7. Grumps

    Grumps Guest

    "James Unterburger" <> wrote in message
    news:4628f9d1$...
    > 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?
    Grumps, Apr 20, 2007
    #7
  8. 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" <> wrote in message
    > news:4628f9d1$...
    >
    >>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?
    >
    >
    James Unterburger, Apr 23, 2007
    #8
  9. Grumps

    Grumps Guest

    "James Unterburger" <> wrote in message
    news:462cef45$...
    > Grumps wrote:
    >> "James Unterburger" <> wrote in message
    >> news:4628f9d1$...
    >>
    >>>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.


    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, Apr 23, 2007
    #9
  10. Grumps

    Jim Lewis Guest

    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
    Jim Lewis, Apr 23, 2007
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. afd
    Replies:
    1
    Views:
    8,294
    Colin Paul Gloster
    Mar 23, 2007
  2. gabriele renzi
    Replies:
    2
    Views:
    200
    gabriele renzi
    Dec 31, 2005
  3. Ken Bloom
    Replies:
    3
    Views:
    203
  4. Good Night Moon
    Replies:
    9
    Views:
    275
    Rick DeNatale
    Jul 25, 2007
  5. Jacob Grover
    Replies:
    5
    Views:
    307
    Jacob Grover
    Jul 18, 2008
Loading...

Share This Page