cool 68k debug project, needs tricks  - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: October 09, 2015, 12:45:09 pm
content: 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

author: ale500
author_rank: Frequent Contributor
timestamp: October 09, 2015, 02:19:47 pm
content: 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 !

author: Kalvin
author_rank: Super Contributor
timestamp: October 09, 2015, 02:39:59 pm
content: 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.

author: chickenHeadKnob
author_rank: Super Contributor
timestamp: October 09, 2015, 07:28:34 pm
content: Quote from: ale500 on October 09, 2015, 02:19:47 pmI 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.

author: bitslice
author_rank: Frequent Contributor
timestamp: October 09, 2015, 08:50:47 pm
content: Why not just use a dual port RAM chip?There are plenty of 16bit wide ones

author: ale500
author_rank: Frequent Contributor
timestamp: October 10, 2015, 01:16:49 pm
content: 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)...

author: legacy
author_rank: Super Contributor
timestamp: October 11, 2015, 07:41:51 pm
content: thank you guys for your answers, I was busy but I have read them carefullyQuote from: ale500 on October 10, 2015, 01:16:49 pmyes, 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!

author: legacy
author_rank: Super Contributor
timestamp: October 11, 2015, 07:50:14 pm
content: Quote from: ale500 on October 09, 2015, 02:19:47 pmwritten in the project note as reminderoriginally I was thinking about using a 5V tolerant fpga, e.g. Spartan/2E, or a 5V tolerant CPLDjust to avoid to have other (level shifter) chips around on PCBFPGA1 3.3V not 5V tolerant <======> FPGA2 5V tolerant <======> 68k busFPGA1: handles DRAM and fast linkFPGA2: handles 68K bus and DTACK

author: ale500
author_rank: Frequent Contributor
timestamp: October 12, 2015, 05:21:26 am
content: Maybe you don't need a second fpga, just a XC95288XL, it has loads of pins...

author: ale500
author_rank: Frequent Contributor
timestamp: October 12, 2015, 05:33:31 am
content: 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...

author: legacy
author_rank: Super Contributor
timestamp: October 12, 2015, 08:31:39 pm
content: Quote from: ale500 on October 12, 2015, 05:33:31 amboth 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).

author: ale500
author_rank: Frequent Contributor
timestamp: October 13, 2015, 05:35:39 am
content: 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 ?

author: legacy
author_rank: Super Contributor
timestamp: October 13, 2015, 07:01:58 am
content: Quote from: ale500 on October 13, 2015, 05:35:39 amthere are 11 states in theIDP_BUSrequirements, but in order to make one access, the finite state machine that handle the busIOdoes not need to use all of them!Readconsumes 3 states,Writeconsume 3 states, then there are states to trap a bus error, etc.

author: legacy
author_rank: Super Contributor
timestamp: October 13, 2015, 07:17:24 am
content: a good point to remember: with the 68040 microprocessor,Motorolaradically changed its bus architecture. With the 68030 and prior processors,Mo- torolaused anasynchronous bus protocol, while The 68040, on the other hand, uses asynchronous bus protocol.The IDP BUS attempt, when you have a 040/060 CPU moduleIn order to provide an universal (you can change the cpu module on demand, without changing the motherboard) integrated development platform (I.D.P.),Motoroladesigned theIDP_busto provide a "bridge" between the cpu Synchronous Bus (68040) and Asynchronous Bus, it's physically handled by an FPGA made byQuickLogic(located on the CPU_module), unfortunately I do not have the sources, I have just replicated the schematic, handling theQuickLogicchip like it was an ASIC chip.

author: legacy
author_rank: Super Contributor
timestamp: October 13, 2015, 07:28:04 am
content: ALso it seems that the 68040/060 Cpu board always forcesCache Inhibitduring transfers, just to avoid (I guess) the timing difficulties that arise whensnoopingis enabled with a common memory subsystem,snoopingcan 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 theQuickLogicbehavior with my LA (no documentation about that fromMotorola, unfortunately)

author: legacy
author_rank: Super Contributor
timestamp: October 13, 2015, 09:15:19 am
content: Missing dynamic bus sizingthe MC68040 and MC68060 do not generate an MC68020 and MC68030-like address strobe, so a good solution might use theMC68150dynamic 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.TheQuickLogicFPGA (installed on the CPU_module) implements the same features, so, I might copy the approach