I remember that discussion. It started here. BTW that is a nice speed increase! Using blockRAM right? or are you using external RAM?

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

EEyE:

The short answer is that, as implemented, the M65C02 soft-processor works in a four cycle mode with external memory. A more complete discussion follows.

The M65C02 soft-processor uses the M65C02_Core. The core itself can operate in single cycle mode if tied to fully asynchronous memory, whether internal or external. As Arlet has discussed elsewhere, there is a fundamental penalty that must be accommodated in the IOB input and output signal paths. The Spartan 3A family targeted in this application, by virtue of the test board implementation, does not have the same level of delay control as the Spartan 6 family.

Thus, in the M65C02, all I/O signals are registered. Most of the registers are in the IOBs of the FPGA. Furthermore, I made an effort to implement a 65C02-style external memory interface. This means that the M65C02 use the M65C02_Core in a four cycle mode to account for the register delays off and back onto the FPGA for external memory accesses.

The fundamental combinatorial path that limits performance of the core with external memories is the path through the address generator. That is generally composed of an adder and two operand multiplexers. Measurements of that path delay on the core by itself showed that the combinatorial path delay in the output address path was around 15ns.

Since it's my opinion that the off chip skew in the address and data lines should be minimized, I have chosen to register that address path in the IOB. That action aligns all of the address lines and generally lowers the skew between the signals to the skew that's inherent between registered IOB signals. Additional skew can be added by differing signal loading and path lengths outside of the FPGA, but in my opinion, the external signal path skews are less than the internal signal path skews.

With that original 15ns combinatorial address path delay figure in mind, the v2.7 M65C02 soft-processor exhibited an operational frequency limit of ~60 MHz. This most recent effort in decreasing the address path combinatorial path delay has resulted in a decrease of the delay in that path from 15ns to ~13.5ns. There may be a few more optimizations that may be able to reduce the delays even further, but they will require significant changes to the structure of the microprogram, and that's not something I want to pursue at this time.

In developing the core, the microprogram control fields are generally encoded into small fields which require an external logic-based decoder to define individual control signals to the logic of the core. Pulling the decoders into the microprogram would reduce the combinatorial path delays, but it would make the microprogram more difficult to maintain. The symbolic MCP_Tool microprogram assembler that I've provided can be used to make maintenance less of an issue.

Finally, I wanted to include a memory interface such as the one found on a real 65C02 like the W65C02S. This means that the memory interface needs to be able to assert wait states and not affect the duty cycle of Phi1 and Phi2. Since my core is a single clock clock rather than a two phase design like the 6502, I decided to simply bolt on a fixed four cycle memory interface, and generate a Phi2 whose active high width is approximately equal to the memory access time of the commercially available asynchronous memories that I wanted to support.

Thus, these design decisions drive the implementation of the M65C02 soft-processor. The limitations represented by these decisions may lead some to incorrectly assume that the underlying processor core, provided by the M65C02_Core module, has the same limitations. The core still retains the ability to operate as a single or two cycle core, so the instruction execution rate can be raised to 73.728 MHz (in a -4 Spartan 3A FPGA) or higher in other FPGAs or with a -5 speed grade Spartan 3A.

With the reduction in the address path combinatorial delays, the M65C02 soft-processor can reliably operate at 73.728 MHz which yields an effective single cycle instruction rate of 18.432 MHz. Read and write access times are approximately 27.125ns. This allows the use of "slow" and inexpensive asynchronous SRAM with 0 wait states, and inexpensive 70ns Flash EPROM with one wait state. Larger SRAMs (45ns or 55ns types) and Flash EPROMs (90ns or higher) can be used without sacrificing too much speed. The M65C02 make provisions for supporting these larger components, but the present release does not include the necessary MMU hardware.

_________________
Michael A.

The M65C02 lives. I thought I had lost my touch. ISim indicated it should work, but no blinking lights. A bit of reflection and some sleep has brought it to life.

The board with the XC3S50A-4VQG100 installed is running a simple test program from internal block RAM (still four cycles for simplicity) at a clock rate of 73.728 MHz. LEDs are blinking at the expected rate on the board, and the ISim simulation supports the results.

Still have a bit of work to tie in my SPI Master interface and a UART. I expect that my efforts on my other core will pay off, since I am simply going to port the peripherals that I tested with the M16C5x soft-microcomputer to the M65C02 bus.

Below is a picture of my little board. It has a small switching regulator to generate +3.3V (I/O and memory) and +1.2V (FPGA core). The regulator also produce +1.8V for the core of a Coolrunner II CPLD. There is 64kB of asynchronous SRAM installed, 512 kB of Flash, and two serial Flash devices. Using the CPLD, either can be set as the configuration PROM, and the other as user accessible serial Flash ROM. JTAG and serial Flash configuration are operational.

There are two stacked RS-232/RS-485 ports on the card. Using the UART with the M16C5x core, have been able to operate the serial ports in either RS-232 or RS-485 to 1.8432 Mbaud. Rates to 7.3728 Mbaud or higher are possible using the RS-485 transceiver. Finally, three logic analyzer test headers are included. It's possible to build expansion cards to plug into these headers for future projects.

BTW - I did none of the soldering, but the board was all hand soldered. Hand soldering the switching switching regulator (LP3906SQ-JXXI) is a challenge.

_________________
Michael A.

(Just to note, and to re-answer the original question as to whether there are 65c02 cores available, there is I think another: Alan Daly has extended an existing core to 65C02. See the repo at
https://github.com/hoglet67/CoPro6502/b ... R65Cx2.vhd
)

Hi all,

I've just done a few bug fixed to this core, and it now passes the Dormann and Bruce Clark test suites. The code on github now contains these fixes. This is the specific change set, for anyone who is interested:
https://github.com/hoglet67/CoPro6502/c ... 2bd5a48c8a

I had previously used Jens Gutschmidt's 65C02 core in this project, but for some reason it was failing to run reliably Tube Elite. Specifically, pressing F6 would cause a crash (it should bring up the long range star chart).

Jens' 65C02 core passes both the above test suites, so there must be some behaviour Elite relies on that is not tested by these.

Is anyone aware of any gaps in these tests, or any known issue with Jens' 65C02 core:
http://opencores.org/project,cpu65c02_true_cycle

I'm assuming opencores has the latest version of this core. Anyone know otherwise?

Dave

hoglet:

I have not read of any issues with Jen's core(s), but I also don't know if the version on Opencores is his latest. Have you tried PMing him from this forum. It's been a while since I communicated with him, but he did respond to my PM last year.

I had a look at the latest core that you are using in your project, Alan Daly's R65Cx2.vhd. A very nice implementation. I have noted a four warnings in the synthesis report that you may want to look into:


and

The first three are of no concern unless you plan on building a simulation, but the third may be something that you need to resolve. It's importance will depend on whether external logic is using the SYNC output for tracing/tracking instruction execution. When SYNC is implemented as a latch, it may or may not correctly indicate the instruction fetch cycle.

_________________
Michael A.