RE: [sv-bc] streaming operator: svlog LRM

Hi Jonathan,

 

I read the docs you had suggested. It surely removed a lot of my doubts.
Thanks!!

 

However, there was one statement in the doc, which says:

When a streaming_concatenation is used as the source of an assignment,
the target of that assignment shall be either a data object of
bit-stream type or a streaming_concatenation.

 

If the target is a data object of bit-stream type, the stream created by
the source streaming_concatenation shall be implicitly cast to the type
of the target.

 

Now, the case for a bit-stream type on the target side is fine, but what
happens if the target side is also a streaming_concatenation? Do we need
to do some explicit cast in that case?

 

Regards,

Kapil

 

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Kapil Kaushik
Sent: Thursday, July 19, 2007 5:24 PM
To: Jonathan Bromley; sv-ec@eda-stds.org; sv-bc@eda-stds.org
Subject: [sv-ec] RE: [sv-bc] streaming operator: svlog LRM

 

Hi Jonthan,

 

I am very sorry for the confusion. What I had actually meant was the

following:

 

Typdef Struct{

            logic a;

            logic b;

} myType

 

Typdef Struct{

            logic a;

            logic b;

            logic c;

            logic d;

} myType1

 

Module test( input myType in1, input myType in2, output myType out1

[1:0], output logic[3:0] out2, output myType1 out3);

 

            assign out1 = {>>{in1, in2}}; 

            assign out2 = {>>{in1, in2}};

            assign out3 = {>>{in1, in2}};

endmodule

 

What this would mean is that all assignments are 4 bit assignments

{in1.a, in1.b, in2.a, in2.b}. So, as you said all these three should be

perfectly fine, right?

 

I will also go through the link you have given and get back to you if I

have any doubts. 

 

Thanks a lot for your help.

 

Regards,

Kapil

 

 

 

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

From: Jonathan Bromley [mailto:jonathan.bromley@doulos.com] 

Sent: Thursday, July 19, 2007 5:01 PM

To: Kapil Kaushik; sv-ec@eda-stds.org; sv-bc@eda-stds.org

Subject: RE: [sv-bc] streaming operator: svlog LRM

 

hi Kapil

 

In your example....

 

Typdef Struct{

            logic a;

            logic b;

} myType

 

Typdef Struct{

            logic a;

            logic b;

            logic c;

            logic d;

} myType

 

I'm guessing you meant these two typedefs to have different names?

 

 

  Module test( input myType in1, input myType in2, 

 

and in1, in2 should be of the two different types???

 

    output myType out1 [1:0], output logic[3:0] out2, output out3);

 

            assign out1 = {>>{in1, in2}}; 

            assign out2 = {>>{in1, in2}};

            assign out3 = {>>{in1, in2}};

 

I think that *all* these assignments are illegal, because 

the streaming concatenation {>>{in1,in2}} contains six bits -

it's effectively {in1.a,in1.b,in2.a,in2.b,in2.c,in2.d} -

and the targets are smaller than 6 bits.  However, if you

provided a 6-bit or larger target, then the assignments 

would be fine.  The bitstream resulting from the {>>{}} 

operation is automatically cast to the type of the target.

What you *cannot* do is use the bitstream in a situation 

where it has a type of its own.  For example, if A is an

integer variable,

 

   A = {>>{in1, in2}} + 1;

 

would be illegal.

 

Mantis item 1707 covers this area.  I've recently written

a new proposal for it; I'd be very interested to know if

that new proposal answers your concerns.  The whole

Mantis item is at

  http://www.eda-stds.org/svdb/view.php?id=1707

(log on as username guest, password guest)

 

and here is the modified LRM text as a PDF for convenience.

--

Jonathan Bromley, Consultant

 

DOULOS - Developing Design Know-how

VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

 

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24

1AW, UK

Tel: +44 (0)1425 471223                   Email:

jonathan.bromley@doulos.com

Fax: +44 (0)1425 471573                           Web:

http://www.doulos.com

 

The contents of this message may contain personal views which

are not the views of Doulos Ltd., unless specifically stated.

 

-- 

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.