UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Jörg Hoppe]

The question "FPGA or not?" keeps me still awake at night, so some 
rambling here!

 > Is the BBB not fast enough to do Qbus? Meaning, for qbus, would a 
FPGA be necessary?
 > Or was this just the op's choice among many possible options?

I was considering a FPGA solution first, even had a Xilinx ZYNQ training 
for that.
But switched to BeagleBone PRU soon for several reasons (many 
non-technical ones).

Speed is essential. OK, UniBus/QBus are asynchronuous, so you can delay 
bus cycles
when your emulated devices need processing time.
But the emulator has to watch bus activity in realtime for register 
accesses to emulated devices.
Problem here is not ARM processing power (1+ GHz is fast enough), but 
delays in the GPIO
access and random code delays by Linux task switching and RAM refreshes 
and the like.
So you need to have some realtime logic on the bottom of all the C code.

UniBone should be "community friendly", a FPGA would mean:
- code developers need VHDL/Verilog skills and a special tool chain
- kit builders need to program the FPGA and solder these damn fine pitch 
parts.
- Technically, a interface between ARM core and FPGA is time-critical,
would not work on RPi FPGA shields. So either you implement EVERYTHING
in FPGA, or you are bound to some FPGA SoC demo boards.

As the BeagleBone has these realtime PRUs:
- all development is done in C/C++, familiar cross platform debugging in 
Eclipse.
- the edit-compile-debug cycle is very fast: 10 seconds for a partial 
recompile & program start when
developing remote from a modern PC.
- The whole toolchain (gnu gcc and PRU C commpiler) also runs on the BBB 
itself, so you can
develop new code immediately.
- BBB is slim enough to fit in a DEC card slot, is cheap (down to $60 
now) and will be available for years.
- big Debian/BeagleBone community behind,

Drawbacks of the ARM+PRU approach were:
- the realtime stuff is done with sequential code, so manual 
optimization was needed.
- the PRU code&RAM space is limited, design can not be scaled up endlessly.
- limited pin count available, a GPIO multiplier was needed.


UniBone is a success because indeed several contributors accepted it.

Despite choosing BBB, I wasn't sure for long wether that ARM+PRU 
approach wouldn't be a dead end technology.
There was not much development on the BeagleBones for 5 years, but with 
the new
BBONE-AI, everything has changed.
TI followed the "Linux ARM + coprocessors" road here in a spectacular way.
The mandatory move to "multi core, GHz, RAM, WiFi, GBit Ethernet, USB3" 
has been done too.


 > It does seem useful to have this thing run linux and ethernet and be 
able to pass
 > files (data and programs) back and forth very easily.
 > the FPGA approach seems more technically challenging but seems less 
universal (to my limited mind).
 > It would seem a BBB you could load software, test, and reload as 
easily as
 > copying some executable code (I dont know if that is correct or an 
over simplification).
 > whereas the FPGA sounds like it needs to be recompiled/re-burned each 
time?
All true, see above.
 >
 > I dont know whether an RPi could work or if the BBB is needed for 
speed etc.
RPi's are faster and have more ARM cores than BBB, but thats in fact not 
needed.
"Realtime determinism" is the keyword here, as well as GPIO speed.
BBB PRUs can toggle GPIOs with 50+MHz.

regards,
Joerg