[Oberon] oberonnet of things

[skulski at pas.rochester.edu]

Juerg:

thank you for the message. Let me start with a general comment concerning
the Oberon language and its environment. Oberon has never been
application-neutral. It always had an underlying hardware model that it
was targeting. This HW was not the centerpiece of the discussion because
it was sort of obvious. It was a workstation, and everyone agreed that the
"workstation" meant a computer whose HW was briefly discussed and then it
was swept under the rug. Neither the HW schematics nor the assembly
language HW drivers were published in the original Project Oberon series,
because they were considered inconsequential (which IMHO was one of the
reasons why this project was never commercialized on a larger scale). The
focus of the original Project Oberon was high-level operating system
running on a typical HW of that day.

This same philosophy continues to this day. The FPGA Project Oberon has
built a workstation on chip. This part of the present project has now been
published in detail, but it is still considered a necessary evil that is
only important as a means of running the operating system. In other words,
the main focus is still the OS, with HW being out of focus as much as
possible.

My point is that it could (should?) be the opposite. Who needs a
workstation on chip these days, if you can buy rPi or BeagleBone for $50?
They are running tons of applications that Project Oberon is not even
dreaming of. There is no hope to catch up with those boards. The Oberon
community has no manpower. Even if the Oberon manpower was more abundant,
the present HW design is just too weak to compete with the GPUs
implemented in silicon by Broadcom or Texas Instruments. Yes, we can enjoy
our nice demo. But we cannot provide a modern workstation coming anywhere
close to the BeagleBone and other such. Going in this direction is
becoming a hobby rather than having real value.

IMHO, the real strength of the FPGA-based computing is the FPGA itself.
The main value is the reconfigurable hardware that we can configure to run
embedded DSP in silicon. Neither rPi nor BeagleBone can do that. (Note
that Texas Instruments is trying to do just that with their silicon PRUs
-- these guys know what they are doing!). So the point that I am trying to
make is this: stop pretending that HW is only a necessary evil. Think the
other way around. The main value is the HW that we can reconfigure, and
then put dependable software on top of it.

If you agree with this proposition, then means of interfacing the HW
should become a centerpiece of the Project. Stop sweeping these means
under the rug with a few registers hidden somewhere in the guts. These
registers are not even documented. We discovered them while studying the
SW. That is wrong. Stop thinking this way. Realize that Project Oberon is
a marginal workstation. At the same time, Project Oberon is a very good
embedded system that can be enormously useful in embedded applications,
whose main strength is customizable HW. If so, then the means of
interfacing with the user-defined HW should become well defined, well
documented, and supported in the system design. Present 64 registers are
nowhere near a general approach that is needed.

So what I am proposing is not a Wojteron, but a shift of focus.

Thank you,
Wojtek


> The Oberon language with its compiler does not provide the memory
> requirements you have. Although the compiler could be extended to do so,
> but then it's not Oberon anymore it's rather "Wojteron" :-)
>
> The Oberon system however allows for a certain amount of memory allocation
> scheme you ask for. For example - as you mentioned - the HW registers to
> program HW are defined as the 16 high memory addresses (4 bytes each)
> beginning at memory adress -4 to memory address -64.
> The Verilog code has to be seen as kind of HAL. So, whenever you add new
> HW to your (Oberon) systen, you should adopt the Verilog code, so the
> mentioned address space is mapped to your new HW registers.
>
> br. Jörg
>
>> Am 24.08.2015 um 16:36 schrieb <skulski at pas.rochester.edu>
>> <skulski at pas.rochester.edu>:
>>
>> Chris:
>>
>>  thank you for the clarification. I still think that there is need to
>> direct the loader to use a particular address range. Automatic address
>> assignment is good for desktop PCs that pretend to have a large and
>> uniform memory implemented in SDRAM, with the virtual memory management
>> and caching performed under the hood without us even knowing the
>> details.
>> All this is very far away from the reality of embedded systems. Here we
>> may have very little fast memory (BRAM) and somewhat more slow memory
>> (SRAM, SDRAM, or even flash mapped as RAM). It is essential for the
>> system
>> performance to locate the frequently used code in fast BRAM. The system
>> should allow for telling it which code and which variables are located
>> at
>> which addresses.
>>
>> Assigning variables to physical addresses is also needed for yet another
>> reason: it is a common practice to assign a register to control some
>> hardware. Reading/writing to such a variable is used to turn on/off some
>> bits that control some hardware behaviors. This is done in Oberon System
>> too, but I do not see a consistent mechanism in the language for doing
>> so.
>> (Maybe I missed it.) Something like
>>
>> VAR my_register : INTEGER AT ADDRESS "address value";
>>
>> These facilities are not needed for a workstation where the OS is
>> maintaining hardware via system calls. This is not our case. Oberon
>> System
>> is an embedded system and it needs embedded approach to its design. I am
>> speaking from experience. We need all this.
>>
>> Thank you for your effort with Astrobe. I will subscribe to the forums.
>>
>> Regards,
>> Wojtek
>>
>>
>>
>>
>>
>>>> -----Original Message-----
>>>> From: skulski at pas.rochester.edu [mailto:skulski at pas.rochester.edu]
>> Sent: Monday, 24 August 2015 11:56 AM
>>>> To: chris at cfbsoftware.com; ETH Oberon and related systems
>>>> Subject: Re: [Oberon] oberonnet of things
>>>> Chris:
>>>>> Instead of then loading Oberon I'll be loading a simple command-
>>>> line
>>>>> processor that will allow you to:
>>>>> 1. Upload compiled Oberon object (*.rsc) files
>>>>>  via a fast (115200 Baud) RS232 link
>>>>> 2. Store them to the SD card
>>>>> 3. Execute them from the SD card
>>>> This is great. Here I would like to see one more bullet:
>>>>  1a. After uploading, execute *.rsc directly from RAM without
>>>>      storing to the SD card.
>>>> This will allow to test the *.rsc without steps 2 and 3. Only tested
>> programs would then go to the SD card. Development version need not to
>> be stored.
>>> The process of uploading actually writes it to a file on the SD card -
>> it
>>> doesn't yet exist in RAM. If you have an older version on the SD card
>> that
>>> you do not want to overwrite then you will be able to rename it first
>>> or
>> give the newer version a different name while it is being tested. Note
>> that when you upload the code the older version might already be loaded
>>> in memory. It might have been loaded as part of the startup process or
>> you
>>> might have already executed it in the current session. In that case you
>> would need to call System.Free to unload it from RAM before you could
>> execute the new version.
>>> Note also that you would have all the source code of the modules
>>> running on
>>> the target - you could modify these to suit your requirements.
>>>>> Eventually I hope to be able to eliminate the external SRAM and
>>>> target
>>>>> FPGA devices with sufficient BRAM (e.g. 128 KBytes?).
>>>> Eliminating external SRAM is not a good idea. BRAM is a very
>>>> expensive form of RAM. If you need lots of RAM, and BRAM is the only
>> option, then you need to use a high end FPGA only because it has
>> sufficient BRAM. These high end FPGA are not only expensive, but they
>> also come in larger footprints than the lower end FPGAs. This
>>>> translates to larger boards, more layers, higher power, and more
>> difficult PCB routing.
>>> You have different requirements to me so my solution is unlikely to
>> correspond with yours. In my case I am using and supporting existing
>> tried
>>> and tested off-the-shelf boards e.g. the Pipistrello. It uses an FPGA
>> device
>>> which I believe has enough BRAM for what I want to do - I figured I
>> might
>>> as
>>> well use it than just have it sitting there doing nothing. I can then
>> save
>>> $US 40 by not having to buy the add-on board with the SRAM.
>>> In your case, if you are designing and manufacturing your own boards
>>> and
>> can
>>> implement the Verilog code to make it all work, you might well be able
>> to
>>> come up with something simpler and less expensive. If you succeed in
>> producing a board which runs the RISC5 processor, and has external SRAM,
>> an
>>> RS232 serial link, SD card and the core-OS that you can sell for less
>> than
>>> $US 150 and still make a profit then I'd be very interested to hear
>> about
>>> it.
>>>> I am very interested in your tools.
>>> Great! Make sure that you have registered your details in advance if
>> want
>>> the initial release:
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cfbsoftware.com_astrobe_RISC5Register.aspx&d=BQICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=fm9Otz364tb5wVybokffPI-h6PUXGFBnBuYBf_vNQIk&s=VrxvyfjV7UqfHUIWalQo6qXSxcQjehtm0MhB0jjOimw&e=
>> Also, subscribe to the 'Astrobe for FPGA RISC5' forum if you want to be
>> notified of progress reports:
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.astrobe.com_forum_viewforum.php-3Ff-3D13&d=BQICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=fm9Otz364tb5wVybokffPI-h6PUXGFBnBuYBf_vNQIk&s=26n3xDD70CuVv-XnDlNotNjnBTZ7p_TjvkbTw-2ekO8&e=
>> Regards,
>>> Chris
>>> Chris Burrows
>>> CFB Software
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.astrobe.com&d=BQICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=fm9Otz364tb5wVybokffPI-h6PUXGFBnBuYBf_vNQIk&s=nZgCMnn9wsX6vXEMzbd8bZnbb2rZskTIe3U0w2JfeFM&e=
>> --
>>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
>>> systems
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=BQICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=fm9Otz364tb5wVybokffPI-h6PUXGFBnBuYBf_vNQIk&s=YeOkAohGxOztVhjigYSmDhAS-20IEEcvC5ilElXIeRM&e=
>>
>>
>>
>>
>>
>> --
>> 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
>