enso:
I've attached an SRAM Interface module that uses the technique for generating the SRAM control strobes that I described yesterday: ODDR2 registers to generate SRAM chip enable, output enable, and write enable. I've included a synthesizable memory tester in the attached ZIP, in addition to a self-checking functional test bench.
The functional test bench and the synthesizable memory tester have been run to verify the ChoChi_SRAM_IF.v module which I've attached. I was unable to get a DDR2 tri-state control register to join with the IOB OFD used for the the output data register, so I've had to resort to using a 2x clock to enable the data bus drivers (from FPGA to SRAM) only during the period while the data bus is being driven.
The SRAM address and SRAM write data are captured in IOB OFDs on the falling edge of the system clock. This approach minimizes data path skews from the core to the SRAM. I looked at the source for Arlet's core that you provided, and it clearly multiplexes in an asynchronous manner the address bus (
AB) and the output data bus (
DO). An asynchronous multiplexer can also be found for the the
we output.
In your SRAM interface module, you only register the data from the SRAM. The attached SRAM interface module registers the data on the way out and on the way in. The issue will be whether or not the combinatorial path delays in the AB and DO multiplexer signal paths are less than half of the clock period. If so, then the attached SRAM IF will provide deskewed address and data outputs, and retain the single cycle behavior that you would like to have.
I have not yet attached the connectors to the CHOCHI board which you sent me, so I built the SRAM Interface Test module for my M65C02 FPGA test board. (For a few minutes last night, I was frantically turning the office and house upside down trying to locate the CHOCHI board so I could check the speed of the part. I finally found it on the kitchen counter in its shipping container.
) I ran the interface tester on one of my SRAMs, on which I've been running a simple test program for the past few weeks.
Both the CHOCHI SRAM and my SRAMs are 10ns asynchronous devices. I have a 14.7456 MHz oscillator as the reference oscillator, and I use a DCM for internal clock and reset generation. (I've also attached the clock and reset generator module that I used for testing.) I had to run the clock frequency to above 66 MHz before I was able to get the tester function to detect an error. The synthesizable memory tester is performing a walking 1s and walking 0s (16 patterns) test on each memory location in my 32kB SRAM. (I only tested one of the two SRAMs on my board.) I was only able to get an error in the memory pattern when I operated at 66+ MHz and I put both scope leads on the same data line.
If I get a chance later this week, I will try building your CHOCHI code and running it on that card. I may also try and get your code running on my little board. I may also try getting your SRAM128K module to operate with the synthesizable memory tester. The synchronous nature of the test pattern generator will not be a good analog of the AB and DO multiplexer signal paths in your 6502 code. But it will provide an independent assessment of your memory interface, and perhaps help pinpoint the source of the glitches being observed.
Hope the attached code is of some use to you.
- SRAM_IF.zip
- Synchronous interface for asynchronous SRAMs.
- (14.14 KiB) Downloaded 169 times
Michael A.
