[Oberon] Project Oberon Workstation in BRAM

Skulski, Wojciech skulski at pas.rochester.edu
Sat Aug 11 14:45:48 CEST 2018

Chris wrote:
>It is only a matter of time before an affordable FPGA development board
>becomes available that will allow the entire Project Oberon Workstation code
>to run in BRAM. The latest Arty A7-100T board from Digilent has 607.5 Kbytes
>of BRAM, though it is still a bit pricey at $US 249 ...

First, BRAM is a terribly expensive kind of RAM. The designer usually has more pressing uses for BRAM than running some rarely executed code. In our case, we need BRAM for signal waveforms. Assigning the valuable BRAM to code is justified if there is a substantial improvement in system performance. This is the case of the core modules, interrupt handlers, networking code, or data processing code. Using BRAM for less critical code is bad engineering.

Second, define "affordable". It always amazes me that any developer pays any attention to the price difference ($249 - $99). Lets assume that you value your time at $5 per hour. Then (249 - 99)/5 = 30 hours. Are you going to complete any project in 30 hours? If you value your time at a more realistic $50/hour, then the difference pays off after 3 hours.

I do understand the difference between the development system versus a deployed product. The latter must be "affordable" in mass market, though the acceptable price point depends on the application. However, trying to impose a price cap on the *development* system is misdirected in my opinion.

>Another intriguing product is the Digilent Cora Z7. For $US 99 you get a
>Zynq FPGA with 225 KB of BRAM, an integrated 667 MHz ARM Cortex-A9 processor
>and Arduino shield and Pmod connectivity. It would make for an interesting
>embedded Project Oberon target but I would imagine that adapting Project
>Oberon Workstation to that configuration would be a significant challenge.

I steer clear of Zynq despite massive advertising by Xilinx. Just look at the manuals. Look at application notes. With Zynq, you will get chained to a particular vendor, particular toolchain, and even to a particular tool release. Going Zynq is a one way street. One day we may be tempted to do it, but I am acutely aware of the consequences.


More information about the Oberon mailing list