[cctalk] Re: Good C to FPGA/PLA compiler

Mike An M0 will require an FPGA below it to interact with the OmniBus A BeagleBone, using the PRUs - which are ~microcoded, would be in with more of a chance Industrial grade SoCs / FPGAs should have no difficulty Martin -----Original Message----- From: Mike Katz via cctalk [mailto:cctalk@classiccmp.org] Sent: 23 September 2023 00:27 To: General Discussion: On-Topic and Off-Topic Posts &lt;cctalk(a)classiccmp.org&gt; Cc: Mike Katz &lt;bitwiz(a)12bitsbest.com&gt; Subject: [cctalk] Re: Good C to FPGA/PLA compiler I plan on controlling the gate array with an RP2040 dual core cortex M0 running at 133 MHz and 8 PIO processors. However, the Data Break (DMA) timings on the Omnibus are in the 100nS range.  The bus runs 6 different timing signals plus manipulating all of the other signals to implement Data Break. I just don't think a micro would be fast enough. That same holds for the break point.  In order to be able to respond to address, data, r/w and count for 4 breakpoints in the <1uS window to stop the CPU before the start of the next cycle would stress most embedded micros (sub  $10 micros anyway). The PDP-8/E main clocks are derived from a 20MHz crystal (That's a 50nS minimum timing). Quoting the DEC Omnibus Standard Document Memory, Address and Data must be settled within 50nS  minimum and no more than 250nS depending on what is going on on the bus. There is a boot strap board that emulates the front panel with an Arduino and an I/O expander. But to implement Data Break requires much more tight timing.  This bus was designed to handle core memory which requires a write after read because the read is destructive. On 9/22/2023 5:52 PM, Chuck Guzis via cctalk wrote: