Go Back   Velocity Reviews > Newsgroups > VHDL
User Name
Password
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

Reply

VHDL - if-then vs. if-generate

 
Thread Tools Search this Thread
Old 02-21-2004, 12:11 PM   #1
Default if-then vs. if-generate


Why lables are mandatory for generate statemente? Why *else* cannot be used
with *generate*? For example, it should be quite typical situation, you have
two different implementations of the same block depending on a generic.

B1: if Param1 generate
...
end generate;

B2: if not Param1 generate
...
end generate;



Wouldn't it be more neat to allow the following implementation of generate
block:

B1: if Param1 generate
...
else
...
end generate;

???? Thanks.




valentin tihomirov
  Reply With Quote
Old 02-21-2004, 01:29 PM   #2
Allan Herriman
 
Posts: n/a
Default Re: if-then vs. if-generate
On Sat, 21 Feb 2004 14:11:46 +0200, "valentin tihomirov"
<> wrote:

> Why *else* cannot be used
>with *generate*?


This is a mistake in the language, and will be fixed in VHDL 200x.
You will also be able to use 'case-generate'.

Expect tool support sometime this decade.

Regards,
Allan.


Allan Herriman
  Reply With Quote
Old 02-23-2004, 10:16 AM   #3
Edwin Naroska
 
Posts: n/a
Default Re: if-then vs. if-generate
Hi,

valentin tihomirov wrote:
> Why lables are mandatory for generate statemente?


I am not sure about the motivation for this restriction
but I think the reason might be as follows:

Any components instantiated in the design must get a unique
instance name. E.g., the VHDL code

B1: if Param1 generate
mycomp: entity test port map (....);
end generate;

mycomp: entity test port map (....);

will generate two components named ":B1:mycomp" and ":mycomp".
If you were allowed to omit "B1" then both components would
receive the same instance name.

Of course, one might argue that the LRM could forbid creating
the same instance name for both components. However, note that
the generate statement creates a new declarative region.
E.g., one can write


architecture test of test is
constant myconst : integer := 11;
begin

B1: if Param1 generate
-- declares a new constant myconst that
-- is only visible within the "generate"
-- region (and overloads the previously
-- declared constant "myconst").
-- This is legal in VHDL.
constant myconst : bit := '1';
begin
mycomp: entity test port map (....);
end generate;

mycomp: entity test port map (....);

end test;

I.e., within the generate statement, new objects/types/... may
be created that "overload" other declarations with the same
name. So, defining "mycomp" to be illegal while declaration of
"myconst" is ok would create some kind of inconsistency.
Perhaps, this is the reason to make a label mandatory for the
generate statement.

Please note that I wasn't involved in the definition of
the VHDL LRM. So, I'm just guessing...

--
Edwin


>
> B1: if Param1 generate
> ...
> end generate;
>
> B2: if not Param1 generate
> ...
> end generate;
>
>
>
> Wouldn't it be more neat to allow the following implementation of generate
> block:
>
> B1: if Param1 generate
> ...
> else
> ...
> end generate;
>
> ???? Thanks.
>
>




Edwin Naroska
  Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Generate .aspx file and .cs file behind it jyoti.bannigidad@gmail.co Software 0 09-18-2008 07:54 AM
As growth slows, Hollywood faces a DVD standoff. Allan DVD Video 0 07-11-2005 02:10 PM
alt.video.dvd Frequently Asked Questions altvideodvd FAQ DVD Video 18 03-11-2005 12:10 AM
Nobody misses guys like Norm Dunf DVD Video 183 02-08-2004 11:21 AM




SEO by vBSEO 3.3.2 ©2009, Crawlability, Inc.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46