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:bit...@12bitsbest.com] 
Sent: 23 September 2023 01:16
To: General Discussion: On-Topic and Off-Topic Posts <cctalk@classiccmp.org>
Cc: Martin Bishop <mjd.bis...@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@classiccmp.org>
> Cc: Mike Katz <bit...@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
>>
>>

Reply via email to