Exporting tasks to 'C using DPI

Question

I have an verilog based test-bench, interfaced to 'C source using DPI. Now using DPI I am planning to write my whole firmware. To do this I need 3 things

• Register Read
• Register Write
• Interrupt handler As I understand, register reads and writes are tasks that I need to export from the RTL test-bench. And Interrupt handler (I implemented by importing a function from 'C).

I checked most the cadence documentation and found no useful hints. I have also registered with cadence users community but it seems that I cannot ask question till they approve my registration.

Just in case someone is aware of this, would appreciate their help.

Answer 1

Actually I figured it out something like this.

//--From RTL ---
export "DPI" task reg_read;

task reg_read;
   input int nAddr;
   output int nVal;

 // -- read implementation --

endtask

// -- From C code
extern void reg_read (int nAddr, int *pVal);

void test_read (void)
{
   int nRegVal;

   // Dummy checking !!
   reg_read (0x100, &nRegVal);
}

// -- Again in RTL --
import "DPI" context task test_read ();

This works for me using ncverilog.

Answer 2

http://www.testbench.in/DP_00_INDEX.html

Check the above link. Lot of ready to run SystemVerilog DIP examples are there.

Answer 3

Cool...I actually wrote an article on this topic. link

The paper is actually exporting register reads and writes and stuff across the DPI and then adding a TCL interpreter to it so that you can use TCL to control your sim. This was something the lab dudes loved since all their tools are already in Tcl.

You can just follow the instructions to integrate your function calls from C to SV across the DPI, and then stop when the TCL stuff comes into play.

Answer 4

Alphaneo,

I would like to hear about your expeience with your above apprach.

I imagine that all firmware would execute in zero time with the exception of the reg_read and reg_write functions. So, looking at the resulting waveforms, I would expect to see many back to back reads and writes (since all other code executes in zero time).

Since you used this to develop your firmware, you would loose the timiing that an embedded processor would provide. Did this cause any problems?

Look forward to your response.

Regards, -philip