RE: [sv-bc] Deadline for detailed feedback on Data Types on Nets Proposal

From: Kevin Cameron <kcameron@altera.com>
Date: Mon Nov 15 2004 - 15:45:31 PST

On Mon, 15 Nov 2004, Mark Hartoog wrote:

> > If you view a struct as just a collection of objects then I would
> > expect the object s.a to behave the same as (say) "reg s_a",
> > so why would it be illegal?
> >
> > If you consider reg as a declaration of a driver & signal/signal-reference
> > (which I do) then I think you would have disallow associating a struct
> > with a net if it contains reg types, but I don't see a reason for not
> > allowing references to it or other variable usage.
>
> The struct is a data type that can be used to declare both nets and variables.
> Using the 'var' keyword for variables and saying 'reg' is a data type we have:
>
> typedef struct { reg a; } ST;
> var ST sv;
> wire ST sw;
>
> Now sv.a is a variable with data type reg and sw.a is a net with a
> resoultion function of a wire and a data type of reg.

With the semantics I prefer, I would say with the first case you've
created a net sv.a with a driver of type logic.

sw I would consider illegal (as below).

> On the other hand if we say that the 'reg' keyword is for variables,
> then:
>
> typedef struct { reg a; } ST;
> reg ST sv;
> wire ST sw;
>
> This makes sv.a a variable of type 'logic' (default type for variables) and
> sw.a a net with a resoultion function of a wire and a data type of 'logic'!!!
> This seems wrong to me.

With my preferred semantics I would consider those illegal since you would
be nesting a net declaration inside another net declaration (which at best
is going to be sematically messy).

> The fields of a struct are not variables unless the struct type is used in
> a variable declaration.

Agreed.

I'm just saying I don't think "reg" in a struct with its old Verilog
meaning needs to be illegal.

Personnally, I'd like to be able to do something like:

  typedef struct { reg a;
                   int metadata; } ST;

  function drive_st(var ref rst,logic d,int meta)
    rst = {d,meta};
  endfunction

  module foo (...,output o,...);

    var ST sv;

    alias sv.a = o; // bind sv.a to output wire o

    always @(clk1) drive_st(sv,1,1);

    always @(clk2) drive_st(sv,0,2);

    ...

  endmodule

- i.e. I can group net and variable data in a struct.

I'd really like to do it with classes too, so that I could make the drive
function a class member - but I'll leave that one for later :-)

Kev.

>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of Kevin Cameron
> Sent: Monday, November 15, 2004 2:35 PM
> To: Mark Hartoog
> Cc: Brad.Pierce@synopsys.COM; sv-bc@eda.org; sv-ec@eda.org
> Subject: Re: [sv-bc] Deadline for detailed feedback on Data Types on Nets Proposal
>
>
> Mark Hartoog wrote:
>
> I tend to agree that 'reg' should not be a data type and that it
> would be better to use 'reg' instead of 'var'.
>
> Could someone please remind us again of the arguments for keeping
> 'reg' as a data type that is equivalent to 'logic'?
>
>
> I think it was sloppy usage in SuperLog that got grandfathered into SV.
>
> I'm not sure what the history of arguments on this are, but this
> declaration, which is now legal would become illegal:
>
> typedef struct { reg a; } ST;
> ST s;
>
> Since the fields of a struct are not variables but only data types.
>
> I would have thought the struct is a data-type and if it is used as a variable then the individual
> fields would also be variables?
>
> If you view a struct as just a collection of objects then I would expect the object s.a to behave
> the same as (say) "reg s_a", so why would it be illegal?
>
> If you consider reg as a declaration of a driver & signal/signal-reference (which I do) then I
> think you would have disallow associating a struct with a net if it contains reg types, but I
> don't see a reason for not allowing references to it or other variable usage.
>
> Kev.
>
> --
> Altera Corp, 101 Innovation Drv, San Jose, CA 95134. T# (408) 544 7126
>
>
Received on Mon Nov 15 15:45:43 2004

This archive was generated by hypermail 2.1.8 : Mon Nov 15 2004 - 15:45:48 PST