FW: [sv-bc] [sv-ec] module parameter assigned to specify parameter

From: Gran, Alex <alex_gran_at_.....>
Date: Fri Aug 22 2008 - 10:08:15 PDT
I think this one actually belongs over with the BC




The table in question is now Table 6-10 in section 6.20.5 in
1800-2009/D6
But it has not changed from 1354-2005

The table does still contain the entry that Parameters "May not be used
inside specify blocks"

However, I am not seeing anywhere else where that restriction is stated.

Sec 29.5 talks about Specify blocks and says "The delay values shall be
constant expressions containing literals or
specparams"  

So, I think its clear that parameters cannot be used as delays values in
a specify block.

But I don't see anywhere in Sec 29 where it says something as strong as
"Parameters cannot be used in any form or fashion between a specify and
endspecify" which is what it looks like the table is implying.

Should it be illegal to use a parameter as the value in a specparam
declaration as show in the email below?

~Alex

-----Original Message-----
From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Kakoli Bhattacharya
Sent: Friday, August 22, 2008 7:03 AM
To: sv-ec@server.eda.org
Subject: [sv-ec] module parameter assigned to specify parameter

Hello,

According to Section 4.10.3 of the Verilog LRM 1364-2005
"The value assigned to a specify parameter can be any constant
expression."

Again,as per table 4.7 of the same section
Parameters (module parameter) "May not be used inside specify blocks"

Now consider the following example:

specify
   specparam si = si1;
endspecify

where, 
parameter shortint signed si1 = -3; // declared within the module scope

The standard tools are behaving differently for the above case.
While some passes,others are giving error or warning.

What should be the correct behaviour?

Thanks,
Kakoli





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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Aug 22 10:08:51 2008

This archive was generated by hypermail 2.1.8 : Fri Aug 22 2008 - 10:09:39 PDT