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.
