View Single Post
Old 29 July 2014, 01:42   #7
Registered User

Join Date: Jul 2014
Location: Ottawa/Canada
Posts: 49
I am going to do ignoring the other 16-bit memory bus until I get the rest of the board going. Even getting a network driver going would have a much higher priority than that. It is a chicken & egg problem to get a 32-bit datapath in the FPGA core developed. So I decided to do that first step.

I can't use DDR memory on a double sided and very crammed PCB anyways. DDR pretty much need a 4 layers board, controlled impedance and more board space for matching the PCB traces. On the other hand, Altera (and Xilinx) have DDR/DDR2 core available.

That's a 166MHz SDRAM part, but I don't know if the FPGA/PCB can go that fast. I did make the cleanest layout I can as well as stuffing 1 decouple cap per power pin to make sure thing are as good as they can be given the double side PCB limitation. I think there are around 100 decoupling caps on that board alone.

Originally I did plan to give the FPGA full access to the SD card (as in 4-bit acess and not slow SPI), but I had to change the connection to my CPLD which is responsible for the Ethernet/ATA. The outcome of that is that I had to widen that bus to 16-bit, which used up all those FPGA I/O pins. So now only the ARM has access to the SD and the 16M bytes SPI FLASH (last minute, but hey it is only around $2). The FPGA is a slave on the SPI bus.

On the other hand, the FPGA has a direct 16-bit data path to ATA via the CPLD. I am going to map the ATA interface to the same address as the one in the A1200 and let the 68000 get full access to it. That should be speedy for a change. At some point might write a driver and update the FPGA/CPLD and Amiga driver to allow for UDMA-33 which is as high as it would go. (Different ATA command set and also requires a hardware CRC for UDMA.)

Last edited by K.C.Lee; 29 July 2014 at 01:57.
K.C.Lee is offline  
Page generated in 0.03930 seconds with 10 queries