Feature request: transplanting architectural state into OpenSPARC

Question

Hi All,
This is a follow-up from our conversation at FCRC/ISCA last week.
I have a feature request for the OpenSPARC RTL, and potentially the FPGA model, which would help researchers experiment with real workloads on OpenSPARC:
I would like to see a process for transplanting checkpointed architectural state of a booted and running T1000/T2000 system (arch. registers, MMU, and memory values) into the OpenSPARC RTL model.
Ideally, this would happen over a socket so the transplant doesn't depend on a particular full-system simulator (e.g., we use Simics/Niagara at CMU, but I expect that many people would like to interface with SAM).
I attempted this on my own a few months ago, with limited success. I wrote Verilog PLI/socket code that 1. slams many of the architectural registers and MMU and 2. replaces the interface in dimm.v with socket calls to a remote Simics instance (non-trivial code, has to reconstruct the phys addr and ECC bits to work properly). Much of this actually worked. I was not, however, able to redirect the core's PC to a new location and properly initiate an i-cache miss.
Perhaps someone with a better understanding of the fetch/thread select stages knows the right combination of registers, valid bits, fetch/miss queue entries could make this work...
Brainstorm:
An alternative approach (which avoids many, but not all, dependencies on the specific RTL revision and is arguably superior to my first approach) might be to write a hyper-privileged "context switch" ASM routine to load architectural state and get the processor boostrapped at a new PC.
This program could be like the usual validation test program, except it loads registers/MMU state from the hijacked DRAM model. Once these values have been loaded into the core, the caches can be invalidated to remove these temporary values (trivial with PLI code), and the full-system memory image can be enabled in the DRAM model.
I can make my code available, if desired.
Thanks!
Jared

Answer 1

Hi Jared,
Thanks for following up on this.
There could be wider interesting in this work and we feel that it makes a very good OpenSPARC based community project that can be hosted on opensparc.net.
If you are interested in contributing the code and taking it forward then we can get it hosted and have right people from Sun help you in making it a successsful one.
I will send you separate email on this topic.
Thank You.
Hi All,
This is a follow-up from our conversation at
FCRC/ISCA last week.
I have a feature request for the OpenSPARC RTL, and
potentially the FPGA model, which would help
researchers experiment with real workloads on
OpenSPARC:
I would like to see a process for transplanting
checkpointed architectural state of a booted and
running T1000/T2000 system (arch. registers, MMU, and
memory values) into the OpenSPARC RTL model.
Ideally, this would happen over a socket so the
transplant doesn't depend on a particular full-system
simulator (e.g., we use Simics/Niagara at CMU, but I
expect that many people would like to interface with
SAM).
I attempted this on my own a few months ago, with
limited success. I wrote Verilog PLI/socket code
that 1. slams many of the architectural registers
and MMU and 2. replaces the interface in dimm.v with
socket calls to a remote Simics instance (non-trivial
code, has to reconstruct the phys addr and ECC bits
to work properly). Much of this actually worked. I
was not, however, able to redirect the core's PC to a
new location and properly initiate an i-cache miss.
Perhaps someone with a better understanding of the
fetch/thread select stages knows the right
combination of registers, valid bits, fetch/miss
queue entries could make this work...
Brainstorm:
An alternative approach (which avoids many, but not
all, dependencies on the specific RTL revision and is
arguably superior to my first approach) might be to
write a hyper-privileged "context switch" ASM routine
to load architectural state and get the processor
boostrapped at a new PC.
This program could be like the usual validation test
program, except it loads registers/MMU state from the
hijacked DRAM model. Once these values have been
loaded into the core, the caches can be invalidated
to remove these temporary values (trivial with PLI
code), and the full-system memory image can be
enabled in the DRAM model.
I can make my code available, if desired.
Thanks!
Jared