problem with use of aggregate in comparison, and VHDL syntax gripes 
Author Message
 problem with use of aggregate in comparison, and VHDL syntax gripes

I'm having a little trouble with aggregates in comparisons.

I tried the following, which was rejected by Cypress Warp 6.0:

1       entity fs_cntl is port (
2           clk:      in     std_logic;
3           clrcnt:   in     std_logic;
4           inccnt:   in     std_logic;
5           done:     buffer std_logic;
6           ram_addr: buffer std_logic_vector (18 downto 0)
7         );
8       end fs_cntl;
9       architecture arch_fs_cntl of fs_cntl is
10      begin
11        addr_count: process (clk)
12        begin
13          if (clk'event and clk = '1') then
14            if (clrcnt = '1') then
15              ram_addr <= (others => '0');
16            elsif (inccnt = '1') then
17              ram_addr <= ram_addr + 1;
18            end if;
19          end if;
20        end process addr_count;
21        done_flag: process (clk)
22        begin
23          if (clk'event and clk = '1') then
24            if (clrcnt = '1') then
25              done <= '0';
26            elsif ram_addr = (others => '1') then
27              done <= '1';
28            end if;
29          end if;
30        end process done_flag;
31      end arch_fs_cntl;

The compiler rejects the aggreage in the comparison on line 26,
reporting:

        (E137) Can't use OTHERS for unconstrained array 'b'

A check of the LRM (1987) suggests that Warp is right and that the
aggregate type can't be inferred in this expression, unlike the signal
assignment on line 15.  So I tried:

26            elsif ram_addr = (ram_addr'range => '1') then

Which also didn't work.  It reports:

        (E80) Value '18' out of range '0 to 0'.
        (E80) Value '17' out of range '0 to 0'.
... and so on.

Should that expression be legal?  I can't find any obvious problem with
it.  It seems to me that Warp might have a bug in its implementation of
the range attribute.

Finally I wound up with:

21.5    constant max_ram_addr: std_logic_vector (ram_addr'range) := (others => '1');
26            elsif ram_addr = (max_ram_addr) then

Which isn't terribly elegant, but it works.

That said, now I'm going to gripe about a language annoyance:

VHDL doesn't let me say:

        entity fs_cntl is
          constant ram_addr_width: integer := 19;
          port (
            ram_addr: buffer std_logic_vector (ram_addr_width - 1 downto 0)
          );
        end fs_cntl;

Is there some good reason why constant declarations can only *follow* a
port declaration inside an entity declaration, but can't precede the port
declaration?  Obviously I can say:

        entity fs_cntl is
          port (
            ram_addr: buffer std_logic_vector (18 downto 0)
          );
          constant ram_addr_width: integer := ram_addr'left + 1 - ram_addr'right;
        end fs_cntl;

But this seems less elegant.

And a syntactic gripe.  VHDL should allow a semicolon after the last
signal in a port declaration, and in other similar places.  When I add an
additional signal to the end of a port declaration, I frequently forget
to add a semicolon to the previous signal.  It would be much easier if it
was allowable to have a semicolon on the last signal; then I would simply
put a semicolon after *every* signal.



Sat, 01 Feb 2003 03:00:00 GMT  
 problem with use of aggregate in comparison, and VHDL syntax gripes
I agree with your last comment on the semicolon.
The language should be more friendly and tolerate redundant semicolons
anywhere.

about the constatnt before the port, I think you may use a "generic"

Lary

Quote:
> I'm having a little trouble with aggregates in comparisons.

> I tried the following, which was rejected by Cypress Warp 6.0:

> 1 entity fs_cntl is port (
> 2     clk:      in     std_logic;
> 3     clrcnt:   in     std_logic;
> 4     inccnt:   in     std_logic;
> 5     done:     buffer std_logic;
> 6     ram_addr: buffer std_logic_vector (18 downto 0)
> 7   );
> 8 end fs_cntl;
> 9 architecture arch_fs_cntl of fs_cntl is
> 10 begin
> 11   addr_count: process (clk)
> 12   begin
> 13     if (clk'event and clk = '1') then
> 14       if (clrcnt = '1') then
> 15 ram_addr <= (others => '0');
> 16       elsif (inccnt = '1') then
> 17         ram_addr <= ram_addr + 1;
> 18       end if;
> 19     end if;
> 20   end process addr_count;
> 21   done_flag: process (clk)
> 22   begin
> 23     if (clk'event and clk = '1') then
> 24       if (clrcnt = '1') then
> 25         done <= '0';
> 26       elsif ram_addr = (others => '1') then
> 27         done <= '1';
> 28       end if;
> 29     end if;
> 30   end process done_flag;
> 31 end arch_fs_cntl;

> The compiler rejects the aggreage in the comparison on line 26,
> reporting:

> (E137) Can't use OTHERS for unconstrained array 'b'

> A check of the LRM (1987) suggests that Warp is right and that the
> aggregate type can't be inferred in this expression, unlike the signal
> assignment on line 15.  So I tried:

> 26       elsif ram_addr = (ram_addr'range => '1') then

> Which also didn't work.  It reports:

> (E80) Value '18' out of range '0 to 0'.
> (E80) Value '17' out of range '0 to 0'.
> ... and so on.

> Should that expression be legal?  I can't find any obvious problem with
> it.  It seems to me that Warp might have a bug in its implementation of
> the range attribute.

> Finally I wound up with:

> 21.5 constant max_ram_addr: std_logic_vector (ram_addr'range) := (others
=> '1');
> 26       elsif ram_addr = (max_ram_addr) then

> Which isn't terribly elegant, but it works.

> That said, now I'm going to gripe about a language annoyance:

> VHDL doesn't let me say:

> entity fs_cntl is
>   constant ram_addr_width: integer := 19;
>   port (
>     ram_addr: buffer std_logic_vector (ram_addr_width - 1 downto 0)
>   );
> end fs_cntl;

> Is there some good reason why constant declarations can only *follow* a
> port declaration inside an entity declaration, but can't precede the port
> declaration?  Obviously I can say:

> entity fs_cntl is
>   port (
>     ram_addr: buffer std_logic_vector (18 downto 0)
>   );
>   constant ram_addr_width: integer := ram_addr'left + 1 - ram_addr'right;
> end fs_cntl;

> But this seems less elegant.

> And a syntactic gripe.  VHDL should allow a semicolon after the last
> signal in a port declaration, and in other similar places.  When I add an
> additional signal to the end of a port declaration, I frequently forget
> to add a semicolon to the previous signal.  It would be much easier if it
> was allowable to have a semicolon on the last signal; then I would simply
> put a semicolon after *every* signal.



Sun, 02 Feb 2003 03:00:00 GMT  
 problem with use of aggregate in comparison, and VHDL syntax gripes
Eric,

see the embedded comments.

Quote:

> I'm having a little trouble with aggregates in comparisons.

> I tried the following, which was rejected by Cypress Warp 6.0:

> 1       entity fs_cntl is port (
> 2           clk:      in     std_logic;
> 3           clrcnt:   in     std_logic;
> 4           inccnt:   in     std_logic;
> 5           done:     buffer std_logic;
> 6           ram_addr: buffer std_logic_vector (18 downto 0)
> 7         );
> 8       end fs_cntl;
> 9       architecture arch_fs_cntl of fs_cntl is
> 10      begin
> 11        addr_count: process (clk)
> 12        begin
> 13          if (clk'event and clk = '1') then
> 14            if (clrcnt = '1') then
> 15              ram_addr <= (others => '0');
> 16            elsif (inccnt = '1') then
> 17              ram_addr <= ram_addr + 1;
> 18            end if;
> 19          end if;
> 20        end process addr_count;
> 21        done_flag: process (clk)
> 22        begin
> 23          if (clk'event and clk = '1') then
> 24            if (clrcnt = '1') then
> 25              done <= '0';
> 26            elsif ram_addr = (others => '1') then
> 27              done <= '1';
> 28            end if;
> 29          end if;
> 30        end process done_flag;
> 31      end arch_fs_cntl;

> The compiler rejects the aggreage in the comparison on line 26,
> reporting:

>         (E137) Can't use OTHERS for unconstrained array 'b'

> A check of the LRM (1987) suggests that Warp is right and that the
> aggregate type can't be inferred in this expression, unlike the signal
> assignment on line 15.  So I tried:

> 26            elsif ram_addr = (ram_addr'range => '1') then

It depends what package you are using, i.e., if the "=" operator
is overloaded. Try to also give the type in the comparison:

   elsif ram_addr = std_logic_vector'(ram_addr'range => '1') then

- Show quoted text -

Quote:

> Which also didn't work.  It reports:

>         (E80) Value '18' out of range '0 to 0'.
>         (E80) Value '17' out of range '0 to 0'.
> ... and so on.

> Should that expression be legal?  I can't find any obvious problem with
> it.  It seems to me that Warp might have a bug in its implementation of
> the range attribute.

> Finally I wound up with:

> 21.5    constant max_ram_addr: std_logic_vector (ram_addr'range) := (others => '1');
> 26            elsif ram_addr = (max_ram_addr) then

> Which isn't terribly elegant, but it works.

> That said, now I'm going to gripe about a language annoyance:

> VHDL doesn't let me say:

>         entity fs_cntl is
>           constant ram_addr_width: integer := 19;

Use generics instead of constants:
            generic (
               ram_addr_width: integer := 19
            );

- Show quoted text -

Quote:
>           port (
>             ram_addr: buffer std_logic_vector (ram_addr_width - 1 downto 0)
>           );
>         end fs_cntl;

> Is there some good reason why constant declarations can only *follow* a
> port declaration inside an entity declaration, but can't precede the port
> declaration?  Obviously I can say:

>         entity fs_cntl is
>           port (
>             ram_addr: buffer std_logic_vector (18 downto 0)
>           );
>           constant ram_addr_width: integer := ram_addr'left + 1 - ram_addr'right;
>         end fs_cntl;

> But this seems less elegant.

> And a syntactic gripe.  VHDL should allow a semicolon after the last
> signal in a port declaration, and in other similar places.  When I add an
> additional signal to the end of a port declaration, I frequently forget
> to add a semicolon to the previous signal.  It would be much easier if it
> was allowable to have a semicolon on the last signal; then I would simply
> put a semicolon after *every* signal.

--

      _/_/_/_/     _/_/_/     Andreas Gieriet, VP R&D
     _/     _/   _/          DS Diagonal Systems
    _/     _/     _/_/      phone:+41-1-905-6060

  _/_/_/_/     _/_/_/     http://www.diagonal.com/



Sun, 02 Feb 2003 03:00:00 GMT  
 problem with use of aggregate in comparison, and VHDL syntax gripes

Quote:

> 6           ram_addr: buffer std_logic_vector (18 downto 0)
[...]
> 26            elsif ram_addr = (ram_addr'range => '1') then
> Which also didn't work.  It reports:

>         (E80) Value '18' out of range '0 to 0'.
>         (E80) Value '17' out of range '0 to 0'.
> ... and so on.

> It depends what package you are using, i.e., if the "=" operator
> is overloaded. Try to also give the type in the comparison:

>    elsif ram_addr = std_logic_vector'(ram_addr'range => '1') then

I tried that but forgot to mention it in my posting.  It gives the
same errors.  I think the problem is with the range attribute rather
than the type.  Can someone confirm that such an expression is
legal?

Quote:

> VHDL doesn't let me say:

>         entity fs_cntl is
>           constant ram_addr_width: integer := 19;

> Use generics instead of constants:
>             generic (
>                ram_addr_width: integer := 19
>             );

I'll do that.  I hadn't wanted to use generics because there is
a lot of stuff in this design that is dependent on the width
being exactly 19, and using a generic would imply to someone that
the width can be tailored to some other value.  That's why I
thought a constant would be more appropriate.

I'll use the generic and put a comment that other value will
not work.

Thanks for the suggestions!
Eric

"values of b will give rise to dom!"
      -- mv command, Sixth Edition Unix
         http://cm.bell-labs.com/cm/cs/who/dmr/odd.html



Sun, 02 Feb 2003 03:00:00 GMT  
 problem with use of aggregate in comparison, and VHDL syntax gripes
Hi,
    As usual the FAQ maintained by Edwin has the answer to your querries:
Visit

http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#aggregates

The basic problem with

Quote:
> > 6           ram_addr: buffer std_logic_vector (18 downto 0)
> [...]
> > 26            elsif ram_addr = (OTHERS => '1') then

  is  that the RHS of the "=" (equality) operator is UNCONSTRAINED. And if
you look at the Package which
 "overloads" this "=" operator to work with "std_logic_vector" (BTW, you
didn't mention which packages you are using, I presume you are using
"std_logic_arith" - for the addition purposes), it is defined with
"uncosntrained array tpes" (to make them re-usable). So the
 user when he/she uses these operators, must "constrain" all the arguments.
In your case the RHS is not a CONSTRAINED one!!.

The solution could be

Quote:
> > 26            elsif ram_addr = (ram_addr'range => '1') then

This should work as far as I understand VHDL. Also it compiles fine with
Cadence toolset. SO perhaps a BUG in WARP? Or it is possible that the
package that you are using defines/overloads "=" in some other manner.
Please have a look at that or post it.

Hope this helps,
Srini



Mon, 03 Feb 2003 03:00:00 GMT  
 problem with use of aggregate in comparison, and VHDL syntax gripes
Hi,


Quote:
> That said, now I'm going to gripe about a language annoyance:

> VHDL doesn't let me say:

> entity fs_cntl is
>   constant ram_addr_width: integer := 19;
>   port (
>     ram_addr: buffer std_logic_vector (ram_addr_width - 1 downto 0)
>   );
> end fs_cntl;

> Is there some good reason why constant declarations can only *follow* a
> port declaration inside an entity declaration, but can't precede the port
> declaration?  Obviously I can say:

  I can't comment of "Why it is so" as of now. But I feel that using
Generics in this place keeps your code re-usable and I think that's
precisely what your intention is :-)

Quote:
> And a syntactic gripe.  VHDL should allow a semicolon after the last
> signal in a port declaration, and in other similar places.  When I add an
> additional signal to the end of a port declaration, I frequently forget
> to add a semicolon to the previous signal.  It would be much easier if it
> was allowable to have a semicolon on the last signal; then I would simply
> put a semicolon after *every* signal.

  I agree with you, I too face this problem often. Wish the LRM allows it. I
think it is just a matter of "borrowing syntax" from some other S/W langaue
(perhaps ADA??)

Srini



Mon, 03 Feb 2003 03:00:00 GMT  
 problem with use of aggregate in comparison, and VHDL syntax gripes


Quote:

> <cut>



> > <cut>

> > And a syntactic gripe.  VHDL should allow a semicolon after the last
> > signal in a port declaration, and in other similar places.  When I add an
> > additional signal to the end of a port declaration, I frequently forget
> > to add a semicolon to the previous signal.  It would be much easier if it
> > was allowable to have a semicolon on the last signal; then I would simply
> > put a semicolon after *every* signal.

>   I agree with you, I too face this problem often. Wish the LRM allows it. I
> think it is just a matter of "borrowing syntax" from some other S/W langaue
> (perhaps ADA??)

:s/perhaps/specifically,/


Mon, 03 Feb 2003 03:00:00 GMT  
 problem with use of aggregate in comparison, and VHDL syntax gripes

Quote:

> Is there some good reason why constant declarations can only *follow* a
> port declaration inside an entity declaration, but can't precede the port
> declaration?  Obviously I can say:


Quote:
>   I can't comment of "Why it is so" as of now. But I feel that using
> Generics in this place keeps your code re-usable and I think that's
> precisely what your intention is :-)

I'm all in favor of using generics where code *is* reusable.  In this case,
I was bemoaning the inability to use a constant for something that was,
by design, constant.  In other words, the rest of the design was vitally
dependent on that value being exactly 19.  Using a generic gives the
impression that one could tweak that parameter to some other value and
expect the result to work.

The best solution I've seen proposed so far is to add a package spec that
defines the constant.  It seems inelegant to require an additional
top-level compilation unit, but it solves the problem.



Mon, 03 Feb 2003 03:00:00 GMT  
 problem with use of aggregate in comparison, and VHDL syntax gripes

Quote:

> I'm all in favor of using generics where code *is* reusable.  In this case,
> I was bemoaning the inability to use a constant for something that was,
> by design, constant.  In other words, the rest of the design was vitally
> dependent on that value being exactly 19.  Using a generic gives the
> impression that one could tweak that parameter to some other value and
> expect the result to work.

After all, I think generics are the best solution for your problem.
To assert the value 19, you can place an
ASSERT STATEMENT (http://www.diagonal.ch/vhdl.html#term16)
in the
ENTITY DECLARATION (http://www.diagonal.ch/vhdl.html#term86)

E.g.,

       entity fs_cntl is
         generic (
           addr_width : natural := 19
         );
         port (
           clk:      in     std_logic;
           clrcnt:   in     std_logic;
           inccnt:   in     std_logic;
           done:     buffer std_logic;
           ram_addr: buffer std_logic_vector (addr_width-1 downto 0)
         );
       begin
         assert addr_width = 19
           report "addr_width = 19 required; reason: ... (Aug 18, 2000/AG)"
           severity FAILURE;
       end fs_cntl;

--

      _/_/_/_/     _/_/_/     Andreas Gieriet, VP R&D
     _/     _/   _/          DS Diagonal Systems
    _/     _/     _/_/      phone:+41-1-905-6060

  _/_/_/_/     _/_/_/     http://www.diagonal.com/



Tue, 04 Feb 2003 13:35:13 GMT  
 problem with use of aggregate in comparison, and VHDL syntax gripes
On 15 Aug 2000 17:21:29 -0700, Eric Smith


Quote:
> I'm having a little trouble with aggregates in comparisons.
> I tried the following, which was rejected by Cypress Warp 6.0:
> ...
> 6      ram_addr: buffer std_logic_vector (18 downto 0)
> ...
> 26       elsif ram_addr = (others => '1') then
> ...
> A check of the LRM (1987) suggests that Warp is right and that the
> aggregate type can't be inferred in this expression, unlike the
> signal assignment on line 15.  So I tried:
> 26       elsif ram_addr = (ram_addr'range => '1') then
> Which also didn't work.  It reports:
>    (E80) Value '18' out of range '0 to 0'.
>    (E80) Value '17' out of range '0 to 0'.
> ... and so on.
> Should that expression be legal?  I can't find any obvious problem
> with it.  It seems to me that Warp might have a bug in its
> implementation of the range attribute.

That should work--sounds like a bug in Warp....

- Show quoted text -

Quote:
> ...
> That said, now I'm going to gripe about a language annoyance:
> VHDL doesn't let me say:
>    entity fs_cntl is
>      constant ram_addr_width: integer := 19;
>      port (
>        ram_addr: buffer std_logic_vector (ram_addr_width - 1 downto 0)
>      );
>    end fs_cntl;
> Is there some good reason why constant declarations can only
> *follow* a port declaration inside an entity declaration, but can't
> precede the port declaration?  Obviously I can say:
>    entity fs_cntl is
>      port (
>        ram_addr: buffer std_logic_vector (18 downto 0)
>      );
>      constant ram_addr_width: integer := ram_addr'left + 1 - ram_addr'right;
>    end fs_cntl;
> But this seems less elegant.

Generics are in the language for the purpose you're trying to use
ram_addr_width for.  (BTW, in the last example, you can write:

        constant ram_addr_width: integer := ram_addr'length;

if Warp allows 'length, of course.)

To answer your original question, VHDL doesn't allow constant
declarations prior to the port list as the port list is the interface
to the rest of the world, but the constant declration is visible only
within the entity and its corresponding architectures.  Again,
generics or package-resident constants are provided for your purpose.

Quote:
> And a syntactic gripe.  VHDL should allow a semicolon after the last
> signal in a port declaration, and in other similar places.  When I
> add an additional signal to the end of a port declaration, I
> frequently forget to add a semicolon to the previous signal.  It
> would be much easier if it was allowable to have a semicolon on the
> last signal; then I would simply put a semicolon after *every*
> signal.

Agreed.  If you'd like to see this, please visit
http://www.*-*-*.com/ ;Change requests
are much more effective coming from users....

Paul

--
              |"EDA tools are a cruel joke inflicted on electronics designers
Paul Menchini | by computer scientists, and stating that a software-programming
www.mench.com | language can describe hardware is the continuation of the same
              | {*filter*}ic behavior."     -- Gabe Moretti



Wed, 26 Feb 2003 04:02:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Verilog vs VHDL Syntax comparison

2. Verilog vs VHDL Syntax comparison

3. Aggregates in comparisons.

4. Implementing letrec-syntax using only let-syntax and syntax-rules

5. aggregate syntax question

6. Problem with VHDL Syntax...

7. COURSES: High Level Design Using VHDL, Advanced Techniques Using VHDL, Portland, OR

8. COURSES: High Level Design Using VHDL, Advanced Techniques Using VHDL, Portland, OR

9. COURSES: High Level Design Using VHDL, Advanced Techniques Using VHDL, Portland, OR

10. COURSES: High Level Design Using VHDL, Advanced Techniques Using VHDL, Portland, OR

11. COURSES: High Level Design Using VHDL, Advanced Techniques Using VHDL, Portland, OR

12. OT: Ultimate Language Syntax Cleanness Comparison

 

 
Powered by phpBB® Forum Software