Home > Community > Forums > Functional Verification > System verilog and System C

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

 System verilog and System C 

Last post Thu, Jan 26 2006 1:21 AM by archive. 7 replies.
Started by archive 26 Jan 2006 01:21 AM. Topic has 7 replies and 4107 views
Page 1 of 1 (8 items)
Sort Posts:
  • Thu, Jan 26 2006 1:21 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    System verilog and System C Reply

    is there any resource showing how to write a verification environmentment mixing Sytem verilog and System C? A complex application example would be great

    Cheers


    Originally posted in cdnusers.org by marco.stanzani
    • Post Points: 0
  • Fri, Jan 27 2006 9:31 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: System verilog and System C Reply

    I'm working on finding/creating an example for you that I will post soon.

    Tim


    Originally posted in cdnusers.org by tpylant
    • Post Points: 0
  • Fri, Jan 27 2006 10:32 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: System verilog and System C Reply

    Before working on an example, can you clarify what types of SV constructs or objects you'd like to access. Are you refering to classes, structures, and/or enums or did you have something else in mind?


    Originally posted in cdnusers.org by tpylant
    • Post Points: 0
  • Fri, Jan 27 2006 12:23 PM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: System verilog and System C Reply

    Here's an excerpt from a paper that will be delivered by Leena Singh at DVCon next month:

    A. Interfacing to SystemC at Signal Level

    Port/signal connectivity is required between the verification environment and the DUT for driving or monitoring or both. A DUT TLM written in SystemC must be connected to a testbench written in SV or e or any other verification language.

    Following is a simple example of a SystemC signal declaration in the TLM.

    1. SC_MODULE(my_module){
    2. ...
    3. sc_inout my_sig;
    4. ...
    5. };
    6. NCSC_MODULE_EXPORT(my_module);

    Taking an example of SV with SC, a Verilog shell module must be defined for the purpose of instantiating the SC module (this shell can also be automatically generated by tools or scripts for example ncsc_run from Cadence generates it during compilation). This shell defines the ports whose name and type match the SystemC ports. The
    following Verilog shell must be created.

    1. // Module name must match exactly the name of
    2. // sc_module class in SC
    3. module my_module(...,inout [31:0] my_sig, …)
    4. (* integer foreign = “SystemC”; *);
    5. //port declarations for my_sig etc.
    6. endmodule

    The foreign attribute string value in line number 3 must be SystemC. The data types in both languages must match. Using this Verilog shell for SC, the SV testbench can communicate to any of the SC ports. For the data type communication, the values from the type in one language are mapped to an appropriate type in the other language.

    B. Interfacing to SystemC via Method Calls

    SystemC models define the methods the testbench must communicate with. Here is an example of a method in a SC model that is used for sending a packet:

    1. sc_module (my_module) {
    2. ...
    3. xbus_response send_packet(xbus_request & req);
    4. ...
    5. };

    The SV Direct Programming Interface (DPI) can be used for connecting an SV testbench to SC method ports. The DPI enables direct calling of SC functions in the SV testbench code. For example:

    1. import “DPI” function response send_packet(request req);
    2. // “xbus_response” and “xbus_request” are packed structs

    Once the SystemC method is imported into the SV testbench, it can be used in the same way as any other SV function or task.

    Some essential guidelines for composing a verification environment to connect to any DUT abstraction are:

    · Connectivity must be established with either the RTL or the SystemC model.

    · For reusability, the BFMs and monitors connected to the DUT interface should support all abstraction levels. The injection mechanism used in the transaction level BFM is simple. It does not have to implement the entire bus protocol. It need only transport the transaction to the model.

    · There should be an option to easily switch between various configurations supporting different abstractions.

    · Compatible data types should be used to communicate between language interfaces. For complex data types, a conversion utility is
    necessary for converting from one language to another. Verilog or VHDL ports of vector type of any direction or size can be mapped to SC data types of the same size.

    o Avoid the use of SC ports of type long or unsigned long, as they could lead to behavioral differences between 32-bit and 64-bit installations. You can use int or int64.

    o Connection of SV packed array or packed struct objects must have matching vector widths.

    o User-defined data types must be defined using the source code that is appropriate for each language.

    o If a type mismatch occurs between a port conected to a SystemC port, data might be truncated during simulation.

    · Each transaction level model can have a different API. It is better not to connect the VE directly to the model. Instead create a wrapper between the BFM/monitor and the model API. If the model API changes, data conversion can be done in the wrapper.

    · Special attention must be paid to the synchronization of events shared between the model and the VE monitors.


    Originally posted in cdnusers.org by tpylant
    • Post Points: 0
  • Thu, Feb 2 2006 9:57 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: System verilog and System C Reply

    Hi,
    As far as I can read from LRM, class is not allowed through DPI, but I can see that to be a very good value addition. Is there an enhancement to IEEE 1800 on this? BTW, will NC support class sharing across SV and SystemC?

    Regards
    Ajeetha, CVC
    www.noveldv.com


    Originally posted in cdnusers.org by ajeetha
    • Post Points: 0
  • Fri, Dec 1 2006 2:03 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: System verilog and System C Reply

    I am curios to know if there is an effective tool available which can convert System C code into verilog/vhdl code?


    Originally posted in cdnusers.org by sharib.khan@hp.com
    • Post Points: 0
  • Fri, Dec 1 2006 4:34 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: System verilog and System C Reply

    Hi Sharib,

    As far as I know, even if there is a tool to convert SYstemC into verilog, it would only convert the synthesisable subset of systemC into verilog (and this could have severe restriction on SystemC coding styles). Doing a web search, I could find:

    http://www.opencores.org/projects.cgi/web/sc2v

    I also know that there are some companies which synthesis SystemC. I do not know if they can produce verilog.

    Nitin


    Originally posted in cdnusers.org by nitin_sharma
    • Post Points: 0
  • Thu, May 17 2007 2:18 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: System verilog and System C Reply

    Hi tpylant,

    I have searched the forum throughly and found your post. I am very interested in the paper you mentioned. Could you share it on the forum?

    Best regards,
    Davy


    Originally posted in cdnusers.org by davyzhu
    • Post Points: 0
Page 1 of 1 (8 items)
Sort Posts:
Started by archive at 26 Jan 2006 01:21 AM. Topic has 7 replies.