Mike
I shall focus a few specifics
I did 30+ years of software, with occasional hardware toys, before I added 20 years of Hw,
FPGA & Sw : old dogs can learn.
FPGA logic source has more in common with software than old school (SSI / MSI / LSI)
hardware. With the bonus that it all happens in parallel. Essentially you instantiate
lots of little processors / state machines, with some interconnect and some IO knitting.
It has not got any better since the OmiBus data break spec, the AXI spec is sufficiently
complex that testing DMA interfaces is done at a minimum with verification IP. Although
AXI busses do at least have a "global" synchronous clock. Interface complexity
/ verification is just one of those little challenges.
I appreciate that OmniBus is not a multiplexed bus, like Q-bus. I was suggesting that you
could multiplex the bus signals to/fr your processing hardware to enable the use of
cheaper/simpler hardware. Of course, YMMV.
The data being on either memory or data bus would not defeat an FPGA, as it would know the
state of RnW and make the appropriate comparison. And, in VHDL it would all read like
"parallel" Ada.
Down to 0.5 mm pitch gull wing legs can be readily hand soldered by a wireman. Surface
mount double sided PCBs can be hand assembled (by me), in small quantities, by restricting
the components to 0603 and 0.65 mm pitch using an under board heater and hot air. The
fine pitch stuff goes on first. OTOH a good wireman can hand solder 0402 components. So,
don't back off completely from SMD. You "only" need: a quartz heater, a hot
air wand, and a solder paste dispenser (you spit it on by hand). Note that surface
tension squares everything up and moves the solder onto the pads; which need to be (hand
assembly) oversize. NB this approach is for very low volume / zero budget / assemble
tonight work; for serious boards / volumes you send the kit to the assembler.
BGAs are another story - dodge them; e.g. use
https://digilent.com/shop/cmod-a7-35t-breadboardable-artix-7-fpga-module/ or similar to
apply FPGAs in a 0.1" DIL form factor, at LVTTL levels. You could build an OmniBus
interface with two of these, some bus interface chips 74LVC for Rx, something OD (and not
too fast) for Tx, and a "host" processor.
Best Regards
Martin
-----Original Message-----
From: Mike Katz [mailto:bitwiz@12bitsbest.com]
Sent: 23 September 2023 01:16
To: General Discussion: On-Topic and Off-Topic Posts <cctalk(a)classiccmp.org>
Cc: Martin Bishop <mjd.bishop(a)emeritus-solutions.com>
Subject: Re: [cctalk] Re: Good C to FPGA/PLA compiler
Martin,
Thank you for all of your suggestions.
I am a software guy who has dabbled in hardware since I built my first Heathkit in 1972.
I have designed simple 6809 single boards in my past professional life but the Omnibus is
several orders of magnitude more complicated than a 6809.
Just reading the Single Cycle Data Break documentation in the Omnibus spec is enough to
give me a headache.
I think in C much better than I think in logic gates. I can write parallel C to describe
parallel circuits. The last time I programmed any programmable logic it was FPGA's of
the 10L8/16V10 variety.
Sometimes the data is on the memory bus, sometimes it is on the data bus, depending on
whether you are reading or writing to memory, for example.
There is no bus multplexing between address and data or data and memory busses.
Here is the basic definition of the Omnibus:
Memory Address: 15 Signals
Memory Data: 12 Signals
Memory Direction: 1 Signal
Data Bus: 12 Signals I/O Control Signals: 10 Signals DMA
Control Signals: 8 Signals Timing Signals: 9 Signals CPU State:
6 Signals Memory Timing: 5 Signals Misc Signals:
18 Signals (Mostly used by the front panel)
One of my goals here is to use thru hole parts and sockets so the average person can
assemble it. I realize this may be impossible bit I'm trying.
I have a good surface mount contract manufacturer close to my home that I have a business
relationship will so I can go to full surface mount if I have to but that will increase
the cost of the boards.
On 9/22/2023 6:53 PM, Martin Bishop via cctalk wrote:
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
<cctalk(a)classiccmp.org>
Cc: Mike Katz <bitwiz(a)12bitsbest.com>
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:
> Stupid question, I know, but someone has to ask it.
>
> Is there some overwhelming reason that the FPGA and associated logic
> couldn't be subsumed into an inexpensive 32-bit MCU running at, oh,
> 200 MHz? I can't believe that a PDP8 is all that fast...
>
> --Chuck
>
>