Interfacing real 65C02 to an FPGA

Topics relating to PALs, CPLDs, FPGAs, and other PLDs used for the support or creation of 65-family processors, both hardware and HDL.
fachat
Posts: 1124
Joined: 05 Jul 2005
Location: near Heidelberg, Germany
Contact:

Re: Interfacing real 65C02 to an FPGA

Post by fachat »

jfoucher wrote:
Hi all,
I would like to be able to interface a WDC65C02 to an FPGA, specifically write to the FPGA block ram from the 6502.
The FPGA is presented to the 6502 as an IO device at address $FF80 (for example). One chip select line, 3 address lines, the 8 data lines, the PHI2 line and the RWB line are all inputs to the FPGA.

I am trying to make the FPGA save the data received in it's block ram when I am writing to it from the 6502. I have tried at least 5 different ways, and I always get unreliable data. I have looked at many timing diagrams for the 6502 write cycles and it seems that my verilog code conforms to that. The address is latched on a clock positive edge, and the data on the clock negative edge.
Without having read the full thread, but on the C64 you cannot latch the address lines on the clock positive edge. The C64 clock cycle is divided into the low phase, where the VIC owns the bus, and the high phase where the CPU owns the bus. Latching at the positive edge of the clock, you will most likely rather use the VIC address, or some mixup between CPU and VIC addresses.

André

Edit: Pls ignore this post. The C64 reference mentally spilled over from the previous topic I was reading... I should probably just go to bed...
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/
User avatar
Sheep64
In Memoriam
Posts: 311
Joined: 11 Aug 2020
Location: A magnetic field

Re: Interfacing real 65C02 to an FPGA

Post by Sheep64 »

BigEd recommends unidirectional streams. In this case, make video display write only. Indeed, a write only display also improves security.

BigDumbDinosaur recommends a qualified write strobe. In this case, make address and data latches level triggered when clock HIGH, R/W LOW and negative logic address strobe LOW.

In the other clock domain, video RAM may continuously alternate between read and write. Reads are sent to screen. Writes are from the level triggered latches. This arrangement continuously hammers RAM with needless writes. Regardless, the intention is to continuously write stable data where the maximum frequency of writes from processor to latch is less than half of the frequency of writes from latch to RAM. Consider it as a one word deep, clock domain crossing, FIFO which never empties.

Ah, you may say, cases exist where random data may be scribbled to random locations! Well, we have the luxury of operating any number of cycles behind the processor. Therefore, in the video clock domain, we may have a conveyer of two or more sets of edge triggered latch. If contents differ then direct writes to the last byte of the video buffer or otherwise modulate writes.

If it looks wrong then you are doing it correctly. plasmo, responding to jds, notes "The complexity of WRITING to video memory will rapidly overwhelm the simple VGA displaying logic."
User avatar
Sheep64
In Memoriam
Posts: 311
Joined: 11 Aug 2020
Location: A magnetic field

Re: Interfacing real 65C02 to an FPGA

Post by Sheep64 »

Apparently, I downloaded a legal PDF of the book Advanced FPGA Design by Steve Kilts from Wiley in Feb 2012. In Oct 2021, I actually bothered to read it. (I also downloaded your circuit CAD files in Jan 2021 and looked at them in Aug 2021 after I had learned enough about KiCAD to be helpful to your project.)

In my message from Sun 16 May 2021, I suggested having one critical bit of signal and delaying the data path by two or three clock cycles. I probably gleaned this from reading the forum archive in full which contains relevant information about FPGA design and UART FIFO. A "double flop" is the established technique to handle clock domain crossing. A third flip-flop is a luxury which adds reliability in the edge case when a CMOS input has not settled. The third flip-flop is often skipped when latency is critical or resources are tight. For your case, always include the third flip-flop.
Post Reply