[Oberon] RiskFive; was Oberon on ULX3S explanation

Wed Nov 13 22:20:23 CET 2019

Wojtek

As RiscFive is in the title, I just want to point out that RISC-V
https://en.m.wikipedia.org/wiki/RISC-V ) is a completely different CPU than NW‘s RISC-5 ( https://inf.ethz.ch/personal/wirth/FPGA-relatedWork/RISC-Arch.pdf)

To compile the Oberon system, the FPGA has to implement the RISC-5 CPU not the RISC-V

br
Jörg

> Am 13.11.2019 um 22:04 schrieb Joerg <joerg.straube at iaeth.ch>:
> 
> Wojtek
> 
> Porting the system to a new board is mainly a task of understanding and adapting the .v files.
> 
> There are hardly any .Mod files you ever have to touch.
> The Oberon system can be compiled as is if the FPGA implements NW’s CPU and offers 1MB of memory, and the IOs and video framebuffer are mapped to the documented memory addresses.
> 
> The first step in porting the system is: make the FPGA behave like the HW architecture as defined and documented by NW (His CPU, his 1MB memory layout with defined IO and framebuffer addresses.)
> 
> AFTER you did that, you can take the second step and add new features to NW‘s machine like
> - adding more memory
> - adding color
> - adding Ethernet
> .... 
> In this second step you might need to adapt 1 to 2 modules. Mainly BootLoad.Mod to adapt the memory layout (In Kernel.Mod the „stackSize“ is hardcoded. Unfortunately, Modules.Mod does not import stackSize from Kernel but hard codes it again😩)
> In case of color graphics Display.Mod has to be adapted. I might be wrong but that’s it.
> 
> br
> Jörg
> 
>>> Am 13.11.2019 um 21:23 schrieb Joerg <joerg.straube at iaeth.ch>:
>>> 
>> Wojtek
>> 
>> I admit that the address fixing is not the easiest part of a compiler and module loader, but it is not undocumented.
>> The first paragraph of  chapter 12.7.9 in this document https://inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf explains what the compiler generates, why its doing it and what fields the module loader has to extract so he can modify the instruction while loading the module from disk to memory.
>> 
>> BTW: The CPU instruction set of NW’s RISC-5 is documented here:
>> https://inf.ethz.ch/personal/wirth/FPGA-relatedWork/RISC-Arch.pdf
>> After reading it, you might understand that 0F7000000H is the assembler code for „BL always“
>> 
>> This Oberon code is totally agnostic to the used FPGA as long as the FPGA implements NW’s CPU called RISC-5. (to be found in RISC5.v)
>> You can leave this Oberon code untouched.
>> You „only“ have to make sure RISC5.v and more importantly RISC5Top.v is adapted to your FPGA and especially memory (address and timing)
>> 
>> Jörg
>> 
>>>> Am 13.11.2019 um 20:33 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
>>>> 
>>> Peter:
>>> 
>>>  thank you for asking. RiskFive is low priority because it is at the sidelines of our funded work. Vedant is using one of these boards and I have four more piled on my desk. As of now Vedant has implemented Wiznet W5500 and he is now working on W5300. All this work was MicroBlaze and C because he is following Pong P. Chu firmware. My tentative plan is to let him complete this work, after which one of us will wrap RISC5 the same way as the MicroBlaze Controller System (MCS) from Xilinx. If RISC5 becomes a drop-in replacement for the MCS, then all the other firmware can stay in place. 
>>> 
>>> Implementing the W5300 reqired changing the address map from Pong P. Chu to wider address chunks per module, because PP.Chu provides for only 32 memory locations, while W5300 needs 32 kB. This is a minor change, which is greatly facilitated by the modular structure of P.P.Chu bus. Interestingly enough, NW/PR bus is basically the same as the P.P.Chu bus, but it is documented in a different way. It turns out that the "bus" does not really exist inside the FPGA. All that exists is its documentation. You can read the WishBone document where they clearly say that WishBone is a specification rather than a firmware component. Much the same is true about NW/PR, P.P.Chu, and other such buses. I tentatively decided to adopt FPro by P.P.Chu because it is both simple and extensively documented. After changing the memory map we will rename it to SPro to avoid confusion with his FPro specs. 
>>> 
>>> All this is firmware. My aim is development of a firmware framework with larger memory address range per chunk than FPro is providing, and then adopting P.P.Chu components to build a system on chip for our needs. Part of this work which of general interest can be open sourced, after writing and releasing sufficient documentation.
>>> 
>>> I reviewed the current Oberon System software from the point of view of porting it to a future SoC. I found that the low level modules such as Kernel, Display, Files, 
>>> or a boot loader, will all need to be factored into a low level driver layer with the HW addresses, and the upper layer without. This is perhaps stated in the NW book, but this book does not accurately describe the Oberon System reality. In reality there are numbers literally hardcoded inside the modules in more than one place. For example, at the end of the BootLoader, the locations 12 and 24 are loaded with values. Now imagine porting this software to another SoC. How do you make sure that these values are properly interfaced with hardware if it is not clear what is going on. It happens in many places in the low level drivers.
>>> 
>>> My favorite lines of code in Modules.Mod are:
>>> 
>>>          mno := inst DIV 100000H MOD 10H;
>>>          pno := inst DIV 1000H MOD 100H;
>>>          disp := inst MOD 1000H;
>>>          ....
>>>          SYSTEM.PUT(adr, (offset MOD 1000000H) + 0F7000000H);
>>> 
>>> Now imagine porting such undocumented code to range of different SoCs with different memory arrangements. It looks like a recipe for a disaster to me. It will be necessary to rewrite portions of low-level Oberon System code to factor out such pieces, before porting the system to other boards which are substantially different from the present boards. Documentation will be crucial. None of such literal values should be allowed in the portable code without extensive comments describing the mechanics. Such structural fixes would be needed before this software is portable to a different SoC. 
>>> 
>>> It would be helpful if this community formed a task force to start modernizing the FPGA Oberon System. The first modest task of the task force could be commenting and documenting the low level code, as well as moving all the hardcoded locations into the definition module SysDef.Mod corresponding to the firmware memory locations. (Consult the P.P.Chu book where he is doing exactly that.)
>>> 
>>> Forming a task force could be contrary to the culture of this group. We seem to be very individualistic. And we do not seem to have a clear common goal. 
>>> 
>>> I can circulate a draft review of the low level Oberon System if there is interest. 
>>> 
>>> Thank you again for asking. And I want to profusely apologize to anyone who could read this e-mail as being unduly critical.
>>> 
>>> Wojtek
>>> ________________________________________
>>> From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of peter at easthope.ca [peter at easthope.ca]
>>> Sent: Wednesday, November 13, 2019 12:55 PM
>>> To: oberon at lists.inf.ethz.ch
>>> Subject: [Oberon]  RiskFive; was Oberon on ULX3S explanation
>>> 
>>> Wojciech,
>>> is RiskFive still viable?  The last news on your site is 2018,
>>> November.  Not criticizing; just wondering.
>>> 
>>> Thanks            ... L.
>>> 
>>> --
>>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20191113/1f9687e2/attachment-0001.html>