Hello,

I have a project where I'm attempting to interface a Xilinx Zynq FPGA with a real WDC65C816S. Most Verilog projects discussed here implement a 65816 or 6502 core on an FPGA, but this project is different since I am using a real, physical 65816, and turning the FPGA into an external device.

The FPGA will be a bus master, providing all memory and I/O devices to the 65816. The Zynq contains a DDR RAM interface, that I plan to use to provide memory to the 65816. Since DDR accesses are, in this case, often not fast enough for a 65816 running at full speed, the FPGA will control the RDY line to implement delayed accesses.

My FPGA is a Zynq Artix-A7 running on a Pynq-Z1 board. This board has an HDMI video output that I intend to use to implement a video system for the 65816.

Here is what I've accomplished so far!

The 65816 is attached to a breadboard, with 30 jumper wires attached from it to the FPGA board. Since breadboards are known to have electrical issues at high speeds, I drive the clock from the FPGA at the lowest speed it can go: 400 kHz.

At 400 kHz, there is no need to implement delayed accesses via the RDY line, since all accesses complete in well under 2500 ns. However, I intend to make this faster and move away from a breadboard eventually.

Synchronizing between the PHI2 clock and the Zynq internal clock is difficult. I use a cycle counter that counts up when PHI2 falls, and carefully switch the signals only when it is safe to do so according to the timing diagrams in the datasheet.

Address lines work. I am able to detect the bootup reads at addresses FFFC, FFFD when the chip is brought out of reset.

Unfortunately, the D pins seem to be stuck at 0 in both directions. The FPGA never reads anything other than 0 on these lines, and the 65816 enters the IRQB interrupt which probably means it can only see the BRK instruction. Yes, I am sending a high signal to the IRQB and NMIB pins.

I suspect the reason for D being stuck at 0 is electrical problems, so I'm getting an oscilloscope to investigate. A tricky issue is that the D lines are supposed to transmit the bank address when PHI2 is low, and only transmit data when PHI2 is high. Both chips might be seeing the bank address instead of the data they're supposed to see. According to the datasheet, the Read Data signal must be held stable for 40 ns after PHI2 falls (tDHR), so there's a chance the FPGA is switching too fast.

Has anyone else used an FPGA to drive a real 65816 chip?

First up, I don't have any code to give you, but if my experience with CUPL(targeting a CPLD) is any indication, it shouldn't be too hard to write.

It sounds as if you aren't driving any data from the FPGA.
$00 is BRK, so if you're just leaving the lines alone, the '816 is probably reading in what it's just driven onto the data lines, due to the capacitance of those lines.
I would suggest a NOP test. If you drive $EA(the NOP instruction) onto the data bus whenever the '816 reads, you should see a count-up on the address bus.

Welcome, beholdnec! An interesting project. I'd agree - try a NOP test.

For the clock synchronisation difficulty: are you driving the 816's clock input from the FPGA? That would put everything under control of the FPGA. Otherwise, yes, you're probably obliged to sample the clock at a much higher frequency so you can respond shortly after each clock edge. If the FPGA's PLLs will sync to the '816 clock, that's another way to tie the fast and slow clocks together.

But first, the bus!

I had a similar problem with another CPLD, but I found that using a bus driver like the SN74LVC4245 (which has a directional pin) solved it. Avoid using drivers with autodetection features, they tend to mess things up.

Thanks for the tip. I tried sending NOPs to the chip on all data reads. The chip reads incrementing addresses, as expected. Success!

So, then I tried running a simple program on the chip. The program is designed to write some values to memory and loop indefinitely. The first instruction is LDY 123. The chip reads the opcode 0xa4, then the operand 123, and then immediately enters the IRQB interrupt. We're far from problem-free.

The clock is driven by the Zynq. The current design has two clocks: the main clock, which runs at 100 MHz, is internal to the FPGA and controls RAM accesses; and the PHI2 clock, which runs at 400 kHz and drives the 65816.

Do you have an oscilloscope? If you do, look at the data lines when they switch.

How do you generate the 400kHz clock?

Both clocks are driven by Zynq PLL's.

I don't have access to an oscilloscope yet, but I will soon!

After reading the opcode and the zp-address there should be one more read - the read from the given zp-address. Then an IRQ processing may start for various reasons.

How long after raising PHI2 does your FPGA drive the data bus with the old contents? They must not change immediately.

After some experimenting, it looks like there's a problem with syncing. The data sent out to the 65816 belongs to an earlier clock cycle than the current read cycle.

It's possible my timing constraints are incorrect. Since I don't have an oscilloscope yet, I rely on the Zynq's internal logic analyzer to see what's going on.

The 816's clock can be totally stopped, in either phase, so you can poke around and read the pins, carrying out the function of a logic analyzer (albeit very slowly).

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I've made some progress. The data lines weren't reading properly because the FPGA was misconfigured. After fixing this issue, I can read actual data coming in from the 65816 to the FPGA.

Timing issues are still present. Data is arriving late to the 816. I suspect the reason is electrical/timing issues.

According to the datasheet, the rise and fall times of PHI2 must be 5ns or less. Measuring on an oscilloscope, the PHI2 signals takes 120ns to rise. That'll definitely cause problems.

Update: with better probe calibration, I measured a 30-40ns rise and fall time on the PHI2 pin. This is still a far cry from the datasheet's figure of 5ns max.

Here is an oscilloscope trace of the PHI2 signal going from the FPGA to the 65816. The frequency is 390625 MHz = 100MHz / 256. Voltage is 3.3V.

The rise and fall times are about 20ns, measured from 20%-80%. Some ringing is visible- could that cause issues?

Basically, I want to reduce the rise and fall time to 5ns, if possible. But I'm not sure if it's possible to achieve this speed on my breadboard. Any guidance is appreciated.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I don't believe that the 816 won't work properly only because the clock edges are "only" 10 or 20 ns steep. If you take a look at some scope shots I took from the 816 SBX board http://forum.6502.org/viewtopic.php?f=4&t=4448&hilit=265&p=52362#p51954 you can recognize that they rise/fall somewhere between 5..10 ns.

What sort of probe do you use? It should be qualified for >50MHz and scaling 10:1. If it is 1:1 you will only measure garbage - the capacitive load would be too much a burden.

Garth already said the clock is static and can be stopped at any time. Perhaps you implement a delay (one or more internal clocks) between setup address and data bus and RWB and then clock. Remember that when PHI2 changes from high to low it doesn't take long and the databus may get used to sent the bank address. So you need to turn off any data bus drivers before that. If that appears to be difficult you can try inserting some series resistors (1K should work for a slow overall clock) to prevent excessive currents, which may cause a supply voltage drop and then strange things will follow

-- I just noticed Garth had already answered. Try his suggestion - insert a schmitt trigger - use short cables as told. Check the signal again.

Cheers

edit(1)
I just noted that the scope shot I referred says rise and fall time of PHI2 is around 3 ns
Nevertheless I don't believe that clean (= monotonous rising or falling ) but slow(er) edges are critical.