[sv-cc] SystemVerilog & SystemC PAR Request (P1800 & P1666)

Karen, Victor,

 

Something I'd like seen addressed in the next PAR(s) is SystemVerilog integration with SystemC. (I'm using the term "Verilog" interchangeably with "SystemVerilog" in this note.)

 

 

Much of this is actual implementation and thus outside the scope of the IEEE; but there are some standardization issues, including:

(1)     Mapping data types:  For example, a Verilog reg[X:0] should map to a sc_uint<X>

(2)     Big endian-ness to little endian-ness: Verilog reg[X:0] is different from reg[0:X].  SystemC doesn't make this distinction.  Would a user, when trying to connect the two models, have a way of specifying to flip the SystemC bits?  If so, how?

(3)     What SystemVerilog construct does a SystemC sc_int<> map to?

(4)     Mapping signals:

a.       Verilog wire to SystemC sc_signal<>

b.       Verilog input to sc_in<>

c.       Verilog output to sc_out<>

d.       Verilog inout to sc_inout<>

(5)     Cross model module instantiation:

a.       Format for instantiating a SystemC sc_module within the Verilog hierarchy

b.       Format for instantiating a Verilog module within the SystemC hierarchy

c.       Any special formatting necessary to add to a Verilog module or SystemC sc_module to be able to cross populate it to the other domain

(6)     Cross module object instantiation:

a.       Format for instantiating a SystemC object within SystemVerilog

b.       Format for instantiating a SystemVerilog object within SystemC

c.       Any special formatting that needs to be added to a SystemVerilog or SystemC class declaration to be able to cross populate it to the other domain

(7)     Format of glue logic needed to call SystemC methods directly from SV

(8)     Format of glue logic needed to call SV tasks & functions from SystemC

(9)     Mapping and triggering events from the SystemC domain to the SystemVerilog domain (and vice-versa), including when is the event actually reported as triggered in the other domain

(10) Scheduling schematics:

a.       Which SV region(s) do SystemC events get scheduled (and vice-versa)?

b.       If SystemC is sensitive to a Verilog signal and it is updated by a Non-Blocking assignment, when does SystemC find out about it?  What about a Blocking Assignment?

c.       If SystemVerilog is sensitive to a sc_signal<> or sc_buffer<> (e.g. in an always block), when does SystemVerilog find out about it?

d.       Can C variables be mapped to SystemVerilog so there is an equivalent to a Blocking call from SystemC to SystemVerilog?

e.       If a Verilog always block and a SystemC SC_METHOD or SC_THREAD are set to trigger in the same delta cycle, who goes first or is this left as undeterministic?  How are race conditions prevented?

 

I'm sure there are other issues.

 

 

Some of this stuff is obvious, but should be stated for the record (e.g. mapping data types); others are less obvious (scheduling of calls between domains).

 

 

Rob Slater

Freescale Semiconductor

r.slater@freescale.com <mailto:r.slater@freescale.com> 

 

  _____  

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Karen Pieper
Sent: Tuesday, January 31, 2006 01:57 AM
To: Faisal Haque (fhaque); Karen Pieper; sv-bc@eda.org; sv-ac@eda.org; sv-ec@eda.org; sv-cc@eda.org
Subject: [sv-cc] RE: [sv-ac] Opinion on merging of P1364 and P1800

 

Hi, Faisal,

 

Thanks for your question.

 

Some members of the standards community believe that the industry will be better off if we, as a standards body, spend our time merging the LRMs into a single document.  Fewer issues occurring because of references to behavior in two places, simplicity in finding a particular behavior defined, etc.  There are members of our community who believe that our time is better spent addressing issues in the current LRMs.  The P1800 is working to ensure that all of the issues on both sides of the discussion are raised and considered before making a decision.

 

Karen

 

 

  _____  

From: Faisal Haque (fhaque) [mailto:fhaque@cisco.com] 
Sent: Monday, January 30, 2006 1:46 PM
To: Karen Pieper; sv-bc@eda.org; sv-ac@eda.org; sv-ec@eda.org; sv-cc@eda.org
Subject: RE: [sv-ac] Opinion on merging of P1364 and P1800

Karen,

What is the rationale for merging the two LRMs?

Can someone explain.

-Faisal

 

 


  _____  


From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Karen Pieper
Sent: Friday, January 27, 2006 5:41 PM
To: sv-bc@eda.org; sv-ac@eda.org; sv-ec@eda.org; sv-cc@eda.org
Subject: [sv-ac] Opinion on merging of P1364 and P1800

Hi, all, 

In the P1800 meeting last week, the Working Group asked for each of the SV-* committees to provide an opinion on whether or not to merge the P1364 and the P1800 LRMs into one LRM.  They are interested in your opinions on:

1)  How much time will it take us to merge the relevant parts of the LRM 
2)  When you recommend merging the LRM (now, toward the end of the current 2 year revision cycle, next LRM, never)... 
3)  Any other questions or comments that the committees recommend the study group consider in their decision to develop the next PAR.

Committee chairs, I would appreciate it if you would develop a response reflective of your committee's opinion and forward it to me after your next committee meeting, preferably no later than the 15th of February.

Thank you, 

Karen Pieper