cool 68k debug project, needs tricks

[legacy]

I am designing a debug-cartridge for an homebrew 68K board which has 32 data lines and 28 address lines, with the purpose of providing a dual port ram, one side is connected to the 68k bus, the other side is controller by an MPU which provides a fast USB link to the host.

It's an extremely useful debug tool, but, as it has to interface a DDR ram, a datalink, and the m68k_bus, (= a lot of signals) itself the fpga has no free I/O pins, and all internal data paths are only 16 bits wide, since my homebrew system will not have to deal with low-latency DMA cycles, I could alter the memory controller to always do two-word bursts, giving 32 bits, but I'd still need to design or otherwise acquire an FPGA board with sufficient I/Os to externalise that 32-bit data bus. This is doable but the FPGAs having many I/Os tend to be provided in BGA packages, which (although, in the theory, possible to solder at home) are much more more difficult to work with.
So I am asking for a few tricks, we are talking about 4 layers PCB, and I am absolutely not skilled enough about dual FPGA cooperation and PCB design.

all tricks are welcome

[ale500]

How may IOs do you really need ?. For example, some still available PQFP208 parts have like 140 IOs (EP2C8). Another possibility could be to divide the problem in two: one FPGA takes care (or CPLD) of the memory control for two ports, the other one does the fast IO. That way you avoid 1 big device, don't forget the level shifters !

[Kalvin]

If you can make the RAM as static RAM, you wouldn't have to worry about the refresh etc. ugly stuff. Then you could stop the 68K while your MCU accesses the SRAM, and you could implement the dual-port interface using simple muxes and tristate buffers. Maybe a small FPGA or CPLD for a glue logic. Or, you want to have some sort of break point functionality, you could still use quite small FPGA which could monitor the address lines etc.

[chickenHeadKnob]

How may IOs do you really need ?. For example, some still available PQFP208 parts have like 140 IOs (EP2C8). Another possibility could be to divide the problem in two: one FPGA takes care (or CPLD) of the memory control for two ports, the other one does the fast IO. That way you avoid 1 big device, don't forget the level shifters !

I was at one point considering a design that put me in the same corner as Legacy, lots of parallel bus lines and an aversion to BGA's. Altera cyclone III EP3C16 in a 240 pin qfp with 160 net I/O is maximum I could find. I would stick with a single qfp package FPGA combined with external latches or similar low scale logic for the address lines as others suggest, the 68000 isn't all that fast.

[bitslice]

Why not just use a dual port RAM chip?

There are plenty of 16bit wide ones

[ale500]

Depending on exactly what you want to achieve a dual-port memory may not be really needed. If your target processor is the 68k with its asynchronous bus, just hanging the bus for a little while while you access the ram may be all what you need. Say you have 10 ns RAM... that is so fast in comparison with the slow 68k BUS of 4 clocks per access. OTOH if you are talking about the 68040's synchronous BUS you may be have to do things faster, as it expects 4 accesses in a row (burst mode)...

[legacy]

thank you guys for your answers, I was busy but I have read them carefully 

burst mode

yes, I wonder if I'd better remove this constraints from my project (I have to deal with two CPU, with a 68000 on board A, and with a 68060 on board B), with the purpose of making things simpler, but I absolutely need 16Mbyte of dual port ram.

Using /dtack is a good trick!

[legacy]

don't forget the level shifters !

written in the project note as reminder 
originally I was thinking about using a 5V tolerant fpga, e.g. Spartan/2E, or a 5V tolerant CPLD
just to avoid to have other (level shifter) chips around on PCB

FPGA1 3.3V not 5V tolerant <======> FPGA2 5V tolerant <======> 68k bus

FPGA1: handles DRAM and fast link
FPGA2: handles 68K bus and DTACK

[ale500]

Maybe you don't need a second fpga, just a XC95288XL, it has loads of pins...

[ale500]

And how are you planning on connecting to the target board ?
Because if you want 16 MBytes x32 plus DTACK... (the 060's BUS is a bit more complicated than that...) those are quite a bus...

[legacy]

And how are you planning on connecting to the target board ?

both the two boards already have an interface bus, called "IDP", but I need a lot of extra logic inside the fpga in order to implement devices (uart, timers, etc) and a few logic to handle the bus, which requires a finite state machine with 11 states, this, plus the debugger TAP I have to implement, which require the dual ram port in order to access the ram without stopping (like happens with a gdb-stub) the cpu. I have designed a TAP, it requires 45 states, and a dedicated fast uart (1Mbit/sec).

[ale500]

And does it have to go through all 11 states to make one access ? that may not be that fast then... can you explain a bit how this bus work ?

[legacy]

And does it have to go through all 11 states to make one access ? that may not be that fast then... can you explain a bit how this bus work ?

there are 11 states in the IDP_BUS requirements, but in order to make one access, the finite state machine that handle the bus IO does not need to use all of them! Read consumes 3 states, Write consume 3 states, then there are states to trap a bus error, etc.

[legacy]

a good point to remember: with the 68040 microprocessor, Motorola radically changed its bus architecture. With the 68030 and prior processors, Mo- torola used an asynchronous bus protocol, while The 68040, on the other hand, uses a synchronous bus protocol.

The IDP BUS attempt, when you have a 040/060 CPU module

In order to provide an universal (you can change the cpu module on demand, without changing the motherboard) integrated development platform (I.D.P.),Motorola designed the IDP_bus to provide a "bridge" between the cpu Synchronous Bus (68040) and Asynchronous Bus, it's physically handled by an FPGA made by QuickLogic (located on the CPU_module), unfortunately I do not have the sources, I have just replicated the schematic, handling the QuickLogic chip like it was an ASIC chip.

[legacy]

ALso it seems that the 68040/060 Cpu board always forces Cache Inhibit during transfers, just to avoid (I guess) the timing difficulties that arise when snooping is enabled with a common memory subsystem, snooping can be disabled! This would also require that data areas on the board accessed by the a device cannot be cached internally by the 68040/060, but I have to study more in details, and I need to reverse the QuickLogic behavior with my LA (no documentation about that from Motorola, unfortunately) 

[legacy]

Missing dynamic bus sizing

the MC68040 and MC68060 do not generate an MC68020 and MC68030-like address strobe, so a good solution might use the MC68150 dynamic bus sizer. This part generates an AS*-like signal from the signals asserted by the MC68040/060 and provides dynamic bus sizing capability. The MC68150 is designed to allow the 32-bit MC68/LC/EC040 bus, or other 16- to 32-bit processors, to communicate bi-directionally with 32-, 16-, or 8-bit peripherals and memories. It dynamically recognizes the size of the selected peripheral/memory and then writes or reads the appropriate data to or from that location.

The QuickLogic FPGA (installed on the CPU_module) implements the same features, so, I might copy the approach