enso:

My two cents worth. I have a fundamental distrust of the routing path delays in large FPGAs. Your CHOCHI implementation targeted the much smaller Spartan 3 XC3S50-xxx parts. Connecting your internal logic through an asynchronous interface to an asynchronous SRAM has a much better chance of success in that part than in the much larger Spartan 3A XC3S700AN FPGA you are using for your new project. Since it appears to work much more reliably when you use an internal synchronous Block RAM, I suspect that the path delays for your address and control lines to the external SRAM are not controlled tightly enough.

I've never felt comfortable defining the asynchronous path delays well enough to rely on that approach to interfacing to an external SRAM. Therefore, I've always taken the performance hit, and used a registered approach for inputs and outputs (control, address, and data) to any external SRAMs.

My recommendation would be to register your control and address outputs, and data inputs. In the short term performance may suffer, but if this approach works, then you can use the on-chip DCMs/PLLs to construct a multiplied clock to handle the memory interface to achieve your target performance.

Alternatively you may try placing your core's logic within a defined region of the FPGA. I use area constraints to force the place and route tool to keep my cores and peripheral functions within defined regions of the FPGA. That approach has benefited my efforts in two ways: (1) timing variations from the logic to the I/O appears to be more consistent (although I use very few asynchronous outputs), and (2) the constrained regions force the PAR tools to compress the logic resulting in better resource utilization. I think this might help you if you place your core into a region that is located close to the SRAM interface.

_________________
Michael A.

IMO, lose the asynchronous static ram. Go with Synchronous Hi Speed Rams. I use them in my projects. The Verilog (@(posedge clk) works well with them.

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

Are there any synchronous rams without a pipeline delay? Everything I've looked at has a one-cycle delay. Or 2.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

If you suspect the problem is the timing of the paths to or from the (asynchronous) external SRAM, can you just run slower to see if that is the cause?

It doesn't seem right to me to abandon SRAM just because of difficulty in describing the timing - it must be possible to describe the timing constraints sufficiently well.

It's not a simple timing problem. I am running at 15MHz, the SRAMs are 10ns. The main clock timing constraint is met with no problems.

I think I will implement a 6502 system with 32K BRAM. That way I will be able to probe from the inside using something like Forth.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

I think I've got it. At least EhBASIC runs fine now.

I thought it would turn out to be something really dumb. Looking at the .mrp file, I noticed (duh) that the IOSTANDARD was 2.5V LVCMOS. Apparently, 700AN defaults to that. A little bit of wrestling with the .ucf file, and the RAMs are getting the 3.3V they deserve.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut