Mike

A key factor is that 60 years have passed:

-       the PDP8/E (and its chums) were core store machines

-       the bus time slots are 300 + 250 + 350 + 300 ns = 1200 ns [T1 T2 T3 T4 
phases of core access]

-       FPGA fabric can trivially run at 100 MHz, and talk to an AXI bus + Arm 
Core

-       SoCs have 32 / 64 bit “external” data busses

-       Arm cores run at 666 MHz and above

-       consequently the test hardware is ~3 orders of magnitude faster than 
the old iron, wider and capable of performing lots of (hardware) logic in 10 ns 
– a cascade of 10 LUT6’s is not unreasonable on a mid range FPGA.

To cut to the chase, a clone of the UniBone should be possible and largely a 
software project – there is a large body of code and experience to build on and 
the Omni and Uni / Q Busses are similar.

The 96 signals need not define the scale of the FPGA / SoC hardware.  There is 
probably scope for multiplexing / serialising the lines to / from the OmniBus – 
I should think the RetroCmp designs use this technology – unfortunately I have 
not had the time to read them sufficiently carefully to say.

Interfacing between the omnibus and an FPGA / SoC will require debouncing and a 
metastable hardened synchronisers (~3 stages of FFs) to bring the signals into 
the FPGA/SoC synchronous domain.  Beyond a Schmidt trigger / equivalent front 
end this is a job for modern digits, in the input FPGA/CPLD(s).

Re your specific requirements:

1)    Was a hardware task 60 years ago, It would now be trivial to do it with 
an FPGA controlled by any reasonable processor

2)    You should be able to this by bit banging over JTAG, maybe with a little 
hardware assist

3)    Sequencer breakpoints in FPGAs are straightforward, provide the condition 
and it pulls the stop line; all that is required are condition register sets 
and comparison logic

4)    see comment above re Mux/Serial

5)    I should think avoiding stubs will be more important than the specific 
input devices

I would restate your needs / the design as:

a)    bus interface

b)    FPGA interface

c)    bus receiving, driving, uC demand (e.g. DMA, FP emulation, breakpoint 
conditions) and reactive logic

d)    uC code

HtH; Best Regards

Martin

From: Mike Katz [mailto:bit...@12bitsbest.com]
Sent: 22 September 2023 22:17
To: General Discussion: On-Topic and Off-Topic Posts 
<cctalk@classiccmp.org<mailto:cctalk@classiccmp.org>>
Cc: Martin Bishop 
<mjd.bis...@emeritus-solutions.com<mailto:mjd.bis...@emeritus-solutions.com>>
Subject: Re: [cctalk] Re: Good C to FPGA/PLA compiler

Martin,

The debug board will need to have the following functionality:

  1.  Read and write to/from memory when the CPU is running using one cycle 
data break (DEC's version of DMA for the PDP-8).  Single Cycle DMA requires 
some interesting signaling, including putting the priority on the data bus 
during part of the cycle.
  2.  Read and write to/from memory when the CPU is halted using front panel 
emulation (something totally different than one cycle data break unfortunately)
  3.  Handle 4 breakpoints (based on address, data, R/W and count) and signal 
the cpu to stop.  I don't know, yet, if there will be enough time in the CPU's 
instruction cycle to top the CPU before the fetch of the next instruction.  If 
this cannot be done in hardware than a much more crude break point system can 
be done in software.
  4.  There are 96 active signals on the PDP-8/E's Omnibus.  I expect to need 
most or all of them for this project.
  5.  The Omnibus is an open drain, active low bus where +2.7V to +4.5V is a 
zero and -0.5 to +0.4V is a one.  I don't necessarily need a 5V tolerant gate 
array but what ever I use to interface to the bus will need to be.

A full description of the Omnibus can be found here:  
https://bitsavers.org/pdf/dec/standards/EL-00157_00_A_DEC_STD_157_OMNIBUS_Specification_Aug76.pdf
Coding the break point system in some kind of parallel C like language seems 
way easier to me than to write this in gates.  I don't have a clue how to 
design the count registers.

I need to get #'s 1 and 2 working first and then I can dive into #3.

Thanks.

Reply via email to