[Oberon] Emulators

Skulski, Wojciech skulski at pas.rochester.edu
Mon Jul 20 23:27:11 CEST 2020


thank you for posting it. FYI, I published a web page on Oberon emulators. I tried to pull all info which I saw floating around. I also discovered some gems or would be gems, which I tried to dust off on this page. This is a kind of reference info which is most useful if it is available, or it gets easily forgotten if not.

Open www.RiskFive.com and find the Emulators section in the left column. Then click on it. I apologize for the heavy style. It was meant to confuse the enemy and to scare away the friends.

Concerning possible modifications.

> Perhaps we should start discussing, WHAT you want to change. At the moment I see three different levels of HW modifications:  easy, more difficult, impossible.

> Basically, see an emulator as virtualization. In virtualization you have a host machine (where the emulator runs on) and a guest machine (this is the FPGA board). I ignore „containers“ at the moment

What are "containers" for my reference?

> Easy: if you want to extend the RISC-5 instruction set in Verilog (eg add an autoincrement instruction) the modification of the emulator is rather straight forward. I neglect the fact that you have to modify the Oberon-07 compiler to use this new instruction, because this is not important for the emulator.

This is "easy"? Oh my goodness.

> More difficult: if you want to add IO mapped HW (eg Ethernet or Wifi) or memory mapped HW (eg color display) to your FPGA and the host machine has an equivalent of this HW, with a little bit of effort the emulator can be modified to map the IO register commands or new memory layout to the corresponding host HW.

Sounds a bit difficult. 

> Impossible: if you want to add HW to your FPGA and the host machine does not have an equivalent HW (eg a neutrino sensor) then it‘s impossible for the emulator to mimic the new FPGA HW.

This is actually the easiest part. We do it all the time in physics. We assume a certain characteristics of the detector, generate simulated data (using GEANT, for example), and we read the simulated data into the analysis chain as if it was real.

I would not go that far. My goals are modest. I can write a fake input buffer which generates some Monte Carlo numbers, and pass these along the SW as if it was coming from the actual hardware. With a bit of detector knowledge it is quite easy to generate a semi-realistic Monte Carlo. Some folks try to make it look very realistic, but I would not go that far. My goal is to develop some display routines and UI software. The super-duper realism is not needed for this. The "sort of" realism is entirely sufficient.

Now I need to figure out which emulator is running well, and which one would be the easiest to modify by a dummy like myself. These two need not be the same. I have some sense from the offline conversations, but not a solid understanding yet.

Thank you,

More information about the Oberon mailing list