best way to simulate multi core architecture ?

T

TheWhizKid

Guest
Hi guys, Please give me some suggestions !

1. I need to make a cycle accurate simulator for a
dual core cpu. How do I pass external events like
interrupts from one core to another during the
simulation ?

2. How does one make a "C" reference model talk to a verilog
model during a simulation ? is "PLI" the only way ?

Thanks
thewhizkid
 
TheWhizKid wrote:

1. I need to make a cycle accurate simulator for a
dual core cpu. How do I pass external events like
interrupts from one core to another during the
simulation ?
Click to expand...
Well, your simulator could step real-time a cycle or an instruction at a
time for both processors. When one processor executes an instruction
that would have an effect of the other, you would set the status of the
interrupt request or input port of the affected processor, which would
then be processed at the proper time in simulation. The key is that the
processors step through simulated time together. If you are simulating
peripherals, as well, that would also be done in parallel with the
processors.

2. How does one make a "C" reference model talk to a verilog
model during a simulation ? is "PLI" the only way ?
Click to expand...
I can't help on that one.

Thad
 
On #2 --> If you use SystemVerilog, DPI is another, easier, faster
option.
Ajeetha
www.noveldv.com
 
You didn't state this, but I will assume one of these cores in in
Software ( C / C++ ) , the other in an HDL like Verilog.

1. Pli is your best bet for moving data between these two things. If
you have an interrupt request, you can poll on it from Verilog, and
call into the C model, this will keep the two in lock step cycle wise,
and will allow you to get back information like if there is a current
interrupt pending.

2. Write a $call_ref_model in an always @(posedge clk) block. This will
make sure that you can get a call to any C source code on a cycle by
cycle boundary. Now assuming you have a cycle accurate Reference model,
you can call the clock function of that model, and keep the two designs
synchronized.

PLI is pretty much the only way. There are many PLI's tf_ , acc_, vpi_,
and now the DPI stuff coming with the SystemVerilog ( though double
check your simulator supports it, SystemVerilog support is spotty at
present ). Tf based pli tends to be very fast and well supported on
most any simulator. I would recommend using that.

-Art
 
1. If there is a direct connection between the CPUs, can a busy CPU
pass the interrupt to the other CPU? In general, can either available
CPU service the interrupt? Are external interrupts going to both CPUs?

2. PLI is very good way to have a "C" reference model talk to a
simulation. Just make sure that, if you are replacing a piece of real
multi-cycle functionality, your PLI call reflects the multi-cycle
nature of the code it is (temporarily) replacing. It is common to have
a behavioral version of a piece of code in place in a testbench before
the actual code is written.
 
One issue with adding SystemVerilog to a testbench is making sure that
the simulation tool(s) being used or considered support the language
and the feature. Even today, every feature of Verilog2001 is not fully
supported by all first tier and second tier simulators. Then, lets say
that your SystemVerilog feature is supported by your simulator tool,
are you going to always use that tool or would you switch to a
different simulator that might not support the SystemVerilog feature
that you are using? A verification coding guideline with a previous
employer was that whatever feature we used of a language was supported
by two or more tools.
 
You simulate an APIC for each processor and integrate the APIC
interruption into the Fetch/Decode part of the pipeline.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top