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

[David Bridgham]

On 11/16/19 19:56, W2HX via cctalk wrote:
> 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'd think that PRU in the BBB ought to be able to handle the QBUS
easily.  A state-machine in an FPGA seemed to me the more
straightforward way to implement bus cycles but absolutely that's not
the only possible choice.  In fact, that brings up one of the things
that I'm really enjoying about hardware development with FPGAs.  Once I
get hardware built with an FPGA in the middle, I have a wide range of
implementation options for any particular bit I'm building.  I can use
combinational logic, state-machines, micro-coding, or, with a soft
processor, I can approach it with software.  In fact, I can choose
different answers for the different pieces of the problem.  I quite
enjoy that flexibility even though it can be an excess of options at times.


> 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?


Yes, you do have to compile code for the FPGA but you have to compile
your code for the BBB too.  While I like the command-line interface to
gcc better than the GUI for Vivado (the Xilinx FPGA dev tool), I would
prefer to just be able to drive it all from a Makefile, either way
there's a compile step.  Eventually I intend to make loading new code
into the QSIC as simple as copying the binary file to an SD card or USB
thumb drive to update the flash.  Loading new code over Ethernet?  Not
sure I'll ever manage that one.