RE: [sv-bc] RE: [sv-ec] svlog enum function usage & maven query

From: Kapil Kaushik <kkapil_at_.....>
Date: Fri Apr 25 2008 - 03:22:35 PDT
Hi All, 

 

Thank you for your feedback. I think one thing which should determine
whether the statement "my_color.next.prev.prev" is valid or not, is the
return value of "my_color.next", i.e. does it return an "enum value" or
a handle to the object?

 

".next", ".prev" etc. are not defined on enum values, for e.g.
"blue.next" is not defined. So, in case that my_color.next returns an
enum value (which it ideally should be doing), then should the behavior
not follow the same?

 

Also, in case the above statements are valid, then as mentioned by Greg,
primary can also be a function or subroutine call. Then is the following
statement also valid?

 

My_color = func(in1).next;

 

Where func is:

 

function color func

input color in

function1 = in.first

endfunction

 

Thanks,

Kapil

 

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Brad
Pierce
Sent: Thursday, April 24, 2008 11:44 PM
To: sv-ec@eda.org; sv-bc@eda.org; sv-ac@eda-stds.org
Subject: RE: [sv-bc] RE: [sv-ec] svlog enum function usage & maven query

 

Greg,

 

   primary ::= function_subroutine_call

           ::= subroutine_call

           ::= method_call

 

The LRM says "The next() method returns the Nth next enumeration value

(default is the next one) starting from the current value of the given

VARIABLE."

 

However, this is probably a mistake and in fact, the method can be used

with any enumeration value, even an anonymous one, and Kapil's example

is actually legal.

 

-- Brad

 

-----Original Message-----

From: Greg Jaxon [mailto:Jaxon@synopsys.COM] 

Sent: Thursday, April 24, 2008 11:02 AM

To: Brad Pierce

Cc: sv-ec@eda.org; sv-bc@eda.org; sv-ac@eda-stds.org

Subject: Re: [sv-bc] RE: [sv-ec] svlog enum function usage & maven query

 

My copy of P1800-2008 shows Mantis 1480 making the correction that

a method_call_root cannot be an expression but only a primary.

Primarys* can be function_calls, but I don't see method_calls in the

list.

Primary_literal is also a possible method_call_root, so I think the

enum labels can be used here, but not the method results.

 

I don't understand why this restriction exists, if it really does.

 

Greg

 

Brad Pierce wrote:

> I think an enum method can only be used with a variable, not with an

> anonymous value returned by some expression.

> 

>  

> 

> n  Brad

> 

>  

> 

> *From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On Behalf Of

> *Kapil Kaushik

> *Sent:* Thursday, April 24, 2008 9:57 AM

> *To:* sv-ec@eda.org; sv-bc@eda.org; sv-ac@eda-stds.org

> *Subject:* [sv-ec] svlog enum function usage

> 

>  

> 

> Hi,

> 

>  

> 

> System Verilog provides some enum functions(section 4.10) like: next,

> prev, last, first etc. for use. I have a doubt whether the following

> statement (highlighted) is valid:

> 

>  

> 

> module test(input clk, input in, output out);

> 

>  

> 

> typedef enum {red, yellow, blue, green} color;

> 

> color my_color

> 

>  

> 

> always @(clk)

> 

> begin

> 

>  

> 

> my_color = blue;

> 

> *my_color = my_color.prev.next.next*

> 

>  

> 

> end

> 

> endmodule

> 

>  

> 

> i.e. are stacked up function calls valid? SVlog LRM does not mention

> anything about this, so it would be great to have some feedback on

this.

> 

>  

> 

> Thanks,

> 

> Kapil

> 

> 

> -- 

> This message has been scanned for viruses and

> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and

is

> believed to be clean.

> 

> 

> -- 

> This message has been scanned for viruses and

> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and

is

> believed to be clean.

 

 

-- 

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 Apr 25 03:24:08 2008

This archive was generated by hypermail 2.1.8 : Fri Apr 25 2008 - 03:28:08 PDT