Final release of the M16C5x soft-core microcomputer has been uploaded to its repository on GitHUB. This last update verifies the operation of the UART's receiver. A test program has been added that polls the Receive Data Register. If valid data is received, then upper case is converted to lower case and vice-versa. Other characters are left unchanged.

The development board has been equipped with an XC3S50A-4VQG100I FPGA. The smaller Spartan 3A part has been operated to 140 MHz at 99% utilization. The UART has been tested at 921.6k baud. Hyperterminal and Tera Term (both for Windows XP) have been used to verify operation of the UART and the test program. The test program and complete M16C5x soft-core microcomputer were first simulated with ISim. The modified test bench used for simulation has been added to the repository, and so has the source code and block RAM memory initialization files for the test programs.

A programmatic validation of the results has not been created, but the converted test files appear to be complete and correct. For these tests, the M16C5x core was operated at a frequency of 117.9648 MHz, the SPI clock was set to 29.4912 MHz (58.9824 MHz max), and the UART configured for 8N1, 921.6k operation. A Keyspan USB Quad Port Serial Interface Adapter was used on the PC side, and an ADM3232 switched capacitor RS-232 transceiver was used on the M16C5x side.

It appears that my efforts to demonstrate a PIC16C5x-compatible soft-core microcomputer have been successful. Will now move back to the original basis for the development board used in this project - the M65C02 soft-core microprocessor. The peripherals ported and verified in this project will be used to boot-strap the M65C02 project. Most gratifying is that the effort to build a workable PIC16C5x-compatible soft-core microcomputer has resulted in the detection and correction of three major errors: (1) operation of the BTFSC/BTFSS instructions have been fixed; (2) correction of a race condition in the UART's status register that caused lost interrupts; and (3) correction of a race condition in the UART's Receive Data Register (RDR) that caused loss of data. These efforts have resulted in the addition of a Baud Rate Register (BRR) that improves the usefulness of the UART without increasing its "size". Furthermore, these efforts have been instrumental in the validation of the design decisions made with respect to the SPI Master Interface module. Its applicability to both standard SPI frames and NXP LPC213x/LPC214x SSP frames has been proven as a result of the M16C5x project.

Finally, that the M16C5x microcomputer fits into the XC3S50A-4VQG100I FPGA is encouraging as it is also the ultimate target for the M65C02. The effort to use the Xilinx Data2MEM utility in a stand-alone and integrated manner for patching the M16C5x Block RAMs will be very useful for the M65C02 soft-core verification/validation effort.

Michael - could you clarify the meaning of clock speed in your core. In the original post you mentioned that you use 2 clocks per cycle to ease the use of internal BRAMs or something like that. Since the PIC chips generally require 4 clocks to complete an instruction, does that mean that your core requires 8?

Ed:

The core, as implemented as a soft-core microcomputer, is a two cycle core. That is, running from BRAM, the M16C5x executes instructions at one half of the clock rate (speed) that I've reported. In contrast to the Microchip products, the M16C5x uses half the number of clock cycles per instruction. The actual core, the P16C5x module, can be operated as a single cycle core.

All:

I have posted a new release of the M16C5x soft-microcomputer to Github.

I was never satisfied with the my prior results. It seemed to me that having the core operate well beyond its period constraints indicated that there was some stylistic coding errors, or something like that. I got some help in setting up a significantly more detailed user constraints file. Multi-cycle path constraints were established to account for those paths where the two cycle clock enable signal was routed. False path constraints between independent clock domains were also added.

The effort required to establish these additional constraints was considerable. Furthermore, the additional constraints did improve the base performance levels of the core in the -4 speed grade part that I use as a reference, but not enough to satisfy me that the effort required was worth the effort and frustration required to develop the additional constraints.

I had stated that the core itself was a single cycle core, so after I determined a path forward on the M65C02 to using a single cycle implementation, I decided that I could apply the same approach to the M16C5x project. The result is the new release of M16C5x on Github. It operates in a single cycle mode. Map/PAR easily closes timing with a simple period constraint on each of the three clock domains in the project. The system clock domain is constrained for 60 MHz, and that is easily satisfied by the Mapper and PAR tools. The SPI clock domain is set for 66.666 MHz and the UART clock domain is set for 100 MHz. Both of these constraints are also easily satisfied, with the best achievable period for the UART clock domain being reported at approximately 8.8 ns.

As a result of this effort, I am now satisfied that the period constraints defined in the M16C5x UCF file are accurate. When the resulting bit file is loaded onto my XC3S50A-4VQ100I FPGA board, I can send large text files through the project without error at baud rates of 921.6 kbps. The UART can support higher data rates, but my Keyspan USB Mutli-port Serial Interface only supports that rate as its maximum on Windows.

With this new release of the M16C5x, disregard previous results published in this thread in relation to operation beyond the reported results. This latest core easily operates in a single cycle mode at 58.9824 MHz (which is 4x the 14.7456 MHz reference oscillator on my FPGA development board). This is equivalent to the 2 cycle frequency of 117.9648 MHz I've reported in previous posts.

If the combinatorial path delays in the timing reports are examined, it is clear that pushing the latest core much beyond the 60 MHz constrained is not worth the effort. However, moving to a higher speed grade part, or even to a Spartan 6, yields performance improvements that are consistent with the speed grade and architectural improvements.

(NOTE: I've used PuTTY successfully in the past with these Keyspan units, but I've never tried to use it at these rates. In performing these tests, PuTTY was a disappointment. I downloaded and used Tera Term. It worked beautifully.)

All:

Have uploaded a change to the GitHUB repo. After some effort by EEyE he was able to determine a method for assigning the BRAM data lanes in the BMM file so that the MEM file data fields are in natural, left to right order. This is preferred to the reversed order that I used in my initial BMM file. I also changed the IH2MEM utility so that it outputs the 12-bit instruction words in the natural, left to right order.