Re: [vhdl-200x] Relax locally static restrictions?

On 2 April 2015 at 12:24, David Koontz <diogratia@gmail.com> wrote:

> Well, there's 9.3.3.1 paragraph 6:
>
> Each element of the value defined by an aggregate shall be represented
> once and only once in the aggregate.
>
>  --
>
> The restrictions have been in place since -1987.
>
> Yes, David. That's why I'm asking why we have these restrictions in the
first place? And could we possibly relax them in our next LRM revision?

At least one simulator I know just gives a warning regarding these
restrictions, because they figured that they can determine the expressions
unambiguously, either during analysis or elaboration of the design. I think
it was very clever for them to do so. Certain LRM restrictions are in
place, but the simulator vendor decided that they can give users a better
experience by relaxing these restrictions and only issue warnings instead
of hard errors.

Because there have been no side effects so far (or none that I have heard
of) from having these restrictions relaxed - my design worked well in both
simulation and synthesis until I recently migrated to a different
toolchain. The new toolchain I'm using seems to be more strict in complying
with the LRM - which is mostly a good thing, except in cases where the LRM
becomes too restrictive to be reasonably usable.


On 2 April 2015 at 14:09, Tristan Gingold <tgingold@free.fr> wrote:
On 01/04/15 19:54, Ostler, Farrell wrote:

> I’ve had my hands tied many times over the years by restrictions
> requiring locally static expressions.
>
> These situations are annoying and don’t always have a low-impact work
> around.
>
> I am not sure that whatever advantages accrue from having a two-step
> translation process (Analysis, Elaboration) outweigh the cost of these
> limitations.
>

There aren't that many restrictions about locally static expression.
They are mostly required when all values of a range must be present.

Examples of 'annoying situations' would be welcome to start a
discussion!


Just like what Farrell said, there are quite a few situations where we had
to workaround these restrictions. One example is the one I provided in my
first post:

E.g., 'width' and 'lanes' are generics:
    generic(width: integer := 10; lanes: integer := 8);

    -- here, the intent is very clear and unambiguous
    constant mask: std_ulogic_vector(width*lanes-1 downto 0) :=
(width*lanes-1 downto width => '0', others => '1');

However, because the expression (width*lanes-1) is not locally static (it
is globally static nonetheless), some simulators issue an error to comply
with the LRM.

We had to hack our code to get it to work, an example was using Tristan's
suggestion:
    constant mask: std_ulogic_vector(width*lanes-1 downto 0) :=
(width*lanes-1 downto width => '0') & (width-1 downto 0 => '1');

I feel the earlier expression is simpler and unambiguous as compared to
concatenating single-association array aggregates.

When we have many generics that determine the slices or array aggregates,
then it can get really annoying.

Imagine a scenario where 'others' becomes not locally static. We then have
to explicitly list all the ranges of the 'others', which I feel is
unnecessary and makes the code less readable.

E.g. (assume width := 10 is a generic, hence globally static but not
locally static):
    constant s: std_ulogic_vector(width-1 downto 0) := ( 8 downto 5 => '0',
others => '1');

this is very clear as compared to:
    constant s: std_ulogic_vector(width-1 downto 0) := ( 8 downto 5 => '0',
9 => '1', 4 downto 0 => '1');

The question is: why can't the tool be allowed to determine the globally
static expression for (width*lanes-1) or 'others', and use the value to
determine the associations of the aggregate?

Existing tools are already capable of doing this. It's just a matter of
whether we want to make this legal, or continue imposing the restrictions,
in which case tool vendors can decide to issue errors just to comply with
these restrictions.

-Daniel

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.