By the way, the SPI Flash configuration is based on Figure 2-12 from UG380, but I don't have the resistors to terminate the CCLK signal. It's just a straight connection (but less than 0.5 inch, so pretty short). Picture from scope shows the CCLK signal on the header pins next to the SPI flash, set to the highest speed it will go (26 MHz according to spec, but closer to 30 MHz on actual silicon). At this speed, configuration is near-instantaneous.

So, if you are thinking about doing SPI Flash configuration instead of Xilinx PROMs for any future projects, you can keep that in mind.

26MHz eh? Now that is a fast FPGA config! I believe that part is cheaper than the Xilinx FPGA PROM too.

From memory I thought my FPGA was being programmed at a 6MHz cclk. I just checked and the config clock is only running @ 2MHz. Almost a full second before I see any action. Do you have a schematic for your SPI flash setup?

EDIT: Also one more question: Are you using the WDC65C02 or your softcore 6502 using the FPGA blockRAM?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

The CCLK speed is programmable. Using BitGen, you can change the CCLK speed. The initial bits of the bit stream provide information regarding the configuration options, the target FPGA of the bitstream, configuration stage in which several signals are released, etc.

The BitGen properties can be changed like the synthesizer and PAR options: right-click the Generate Programming File process. If I remember correctly, unless you set a specific speed for CCLK, it will use the default, or 1 MHz. The internal oscillator's tolerance is such that it may actually run faster than 1 MHz.

On the Spartan-3AN, the VS[2:0] pins configure the clock to the internal SPI configuration memory bonded to the FPGA.

On the Spartan 3A, the VS pins define the read command for the SPI memory. In this way, the SPI configuration option can support various SPI devices from different vendors, and various SPI read modes for those parts.

Xilinx has indicated to me that they may not continue manufacturing the Platform Flash products; they can't compete in price or density with the SPI Flash offerings from several vendors. Further, since they have added the SPI configuration mode to all of their more recent FPGA families, it appears that they may not continue supporting their proprietary configuration products. Thus, their proprietary devices, XC17xx, Platform Flash (XCFxx), etc., may soon go the same way as my favorite FPGAs: Spartan-II.

BTW: Arlet, great project. Looking forward to hearing about its progress. Will follow along here.

_________________
Michael A.

I'm attaching a pdf.

I'm using the attached WDC65C02. The FPGA only implements the memory interface and other hardware, but does not have a core running.

Okay - feature creep! An idea that's been floating around my head for a while is to make a board very similar to this but with the following changes:-

1) Provide hardware SPI support using something akin to Daryl's 65SPI chip http://sbc.rictor.org/65spi.html. Daryl's design (and I apologise for not having spoken to him about this first) uses a 44 pin FPGA and I wonder if there's space in the FPGA on this board to include the functionality?

2) Provide some 'arduino' spaced connectors. This would allow a lot of 'shields' (particularly those that at 'bit-bashed' or driven via SPI) to be hardware compatible. Okay, the analog support would be missing but... Since the Arduino boards are mainly 8-bit it's not as though it would be trying to shoehorn 16-bit support from an 8-bit micro. Sure, there are voltage levels to consider but it would allow use of boards like this https://www.olimex.com/Products/Modules/Video/MOD-VGA-32MB video card card that includes keyboard support.

Just an idea to throw in...

Simon

The SPI interface for the flash is already available on header pins, so if I add one extra select signal, it could be used for controlling external peripherals. There's no problem fitting the logic in the FPGA.

A full blown shield would involve too many I/O pins, I'm afraid. Bigger FPGAs exist, but only in BGA packages.

Edit:By the way, for the next revision I have video output planned to be integrated on the board, but with a PAL/NTSC encoder for connection to a TV set. I'm planning to do component/rgb, composite, and probably s-video. In addition, there will be a stereo audio output, dual USB, and a micro SD card slot.

If there's enough interest, I could also make a version that has VGA instead of TV.

I added the SRAM device. On the scope, it looks like it's working, but I still need to check the data in the FPGA/CPU. Right now, only the CPU has access to the SRAM, so I can set up really slow and easy access cycles, spread out over several clocks.

Completed SRAM/6502 interface, and successfully ran some simple read/write tests. I also added feature to switch UART tracing on/off. By typing 't' on the UART, single stepping is enabled, and UART shows trace log of addr/data/control buses. When you hit 'g', execution continues at full speed. SRAM interface is still really simple, without any other access than the 6502's. I'll worry about a proper memory controller/arbiter when I need it for video.

All 64KB of the memory is routed to the SRAM, except the F000-FFFF area goes to internal block RAM, with serves as a boot ROM.

Next steps: add UART interface for 6502, and run some bigger programs.

I've added the UART interface (with IRQ handler), and wrote a simple monitor program that I can use to dump memory, fill memory, load programs (binary and Intel hex), and jump to them. The UART interface is configurable between the CPU and the FPGA trace logic. If you now type ^C, the UART is disconnected from the CPU, UART interrupts are disabled, single stepping is enabled, and the UART shows the memory trace instead. Typing ^D switches it back to CPU control, and lets the CPU run full speed again.

Using the intel hex loader, I loaded Klaus' test suite in external SRAM, and ran it. I had to set ROM_vectors to 0, otherwise the hex loader would overwrite the IRQ vector, and that would mess up my UART interrupts, and I had to move the zeropage data a little bit to avoid collision with my own data, but apart from that, I ran it unmodified. Every few seconds I would use the trace logic to see where it was, and after a few times, it was stuck in the 'success' loop.

Cool... I moved my monitor code from F000-FFFF to E000-EFFF, so it wouldn't interfere with other software that might want to load in the Fxxx space. However, because I still want to use IRQ in my monitor, I have added a feature based on the "Vector Pull" signal. During a fetch of any of the vectors, the address is quietly rerouted to my internal monitor code. Works great... and much easier to do this on an FPGA instead of discrete logic.

I modified the Atom OS ROM to perform read/write character I/O through the UART instead of the keyboard/screen, and loaded it into the sandbox board. The software designers did a pretty good job of keeping the BASIC separated from the operating system. The only violation of the abstraction I found in the basic ROM where it directly polls the ESC key by looking at a PIA register.

Demo program from the manual, running on the board: (note how the code only works for 20th century)


Of course, without video, the number of things you can do is rather limited

Working on SPI flash interface for CPU now. I'm making a very simple CPU interface with a memory mapped data register. Writing to the data register causes a byte to be shifted out over the SPI interface, and another byte to be shifted in at the same time. Later, I'll also add a read-only register that will cause $FF to be shifted out, and another byte to be shifted in, just by reading the register.

I'm using a 24 MHz SPI clock (main clock divided by 4), and because the CPU clock is 8 MHz, it takes less than 3 CPU cycles to shift a byte in or out. So, basically, the CPU can read serial flash data just as fast as it can access SRAM. Of course, you still need to set up the starting address, but as long as you read, say, 256 bytes at a time, that's not going to cost much.

Here's a picture from the scope (top=data, bottom= clock), as a result of this code:

A write to $b110 causes the SPI byte to be written, and it's no problem to do back to back writes. I could even map the register in zero page.

Why did you choose this speed for the FLASH device? I've not looked at the Numonyx datasheet for the IC you're using, but surely it goes up to 80MHz like it's competitors.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

You are right, I have a copy of an older version of the datasheet that only mentions 25 MHz operation. The newer ones go to 75 MHz. I'll modify the code to use a 48 MHz SPI clock instead.

Here's the same thing, but now running with 48 MHz SPI clock. I've added the PHI2 signal for reference. Of course, when the 65C02 is driving the SPI interface, the higher speed is pointless, but it could become useful when the FPGA is driving the flash directly.

Flash is responding to read ID command:

Top trace is clock, middle is MOSI, bottom is MISO. Flash responds with $20, $20, $14, as stated in datasheet. I don't have a CPU interface for read data yet, so this is just hand decoded from the scope screen