[Oberon] ProjectOberon on FPGA

Walter Gallegos walter at waltergallegos.com
Sat Aug 29 00:21:05 CEST 2015


enso :

I work with FPGA since many years my business is change the hardware.

Spinoff comment.
We can continue this by private email.

>This may not be the best example.  I've built an IO-port-based circuit
>to write the PicoBlaze BRAM specifically to be able to write a monitor
>and use a software solution to load code via a serial port into a
>PicoBlaze system (to avoid using JTAG and Xilinx tools).

Every FPGA have a TAP controller, a generic USB=>JTAG adapter is cheap, 
write a JTAG loader application is not a big challenge.
So, why not use a generic solution -available in every FPGA project- to load 
data into an FPGA?

Regards,

-----Mensaje original----- 
From: enso
Sent: Friday, August 28, 2015 6:14 PM
To: ETH Oberon and related systems
Subject: Re: [Oberon] ProjectOberon on FPGA

On 08/28/2015 01:26 PM, Walter Gallegos wrote:
> I read several post about RISC5, FPGA, BRAM, FLASH, etc.
>
> My point is, software guys need redirect your minds when in FPGA arena due
> the new resources available; new issues and challenges too.
>
> We are in the programmable logic world; so, limit our horizon to software
> only solutions is a big mistake.
>
> Trying to illustrate with an example, a bootloader is a typical software
> solution.  The usual way to do this in FPGA is by JTAG, the TAP
> controller -available in any FPGA- is connected to the BRAMs, or to a 
> FLASH
> controller, to load new memory contents. This is the way how are working
> JTAGLoader in PicoBlaze and indirect programming in XILINX.
>
> Regards,
This may not be the best example.  I've built an IO-port-based circuit
to write the PicoBlaze BRAM specifically to be able to write a monitor
and use a software solution to load code via a serial port into a
PicoBlaze system (to avoid using JTAG and Xilinx tools).

Programmable hardware is wonderful, but there is the potential for yet
another level of version hell.  It is wise to stick to one working
hardware system and leave as much as possible to software, whenever
possible.  Developing code for a fixed platform is a joy; developing
code for a platform that is changed every time someone needs some new
hardware feature is a nightmare.  Given that anyone can change hardware
any time they feel like it, resisting the urge to do so is very wise.

It may be worth seriously thinking how to create hardware modules that
integrate in a sensible way, much like the rest of Oberon. Hardware that
is 'loaded' as needed, perhaps.  But that's a whole other project, isn't
it...

--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon 




More information about the Oberon mailing list