1. Home
  2. Field-Programmable Gate Arrays
  3. digilent spartan-3 board sram timing

digilent spartan-3 board sram timing

Hi,

This is a question about digilent spartan-3 starter board , which has a simple 10ns sram and 20ns clock. I am using a simple controller to access the sram. During a read operation, the address is stored into a register and oe is activated at the first rising edge of the clock and data is retrieved at the next edge. The 20 ns period seems not large enough to accommodate the pad delay and external loading. A simple testing circuit shows that about 0.2% read errors. There is no error if the reading period is extended to 2 clocks.

Is it possible to put some timing or other constraints in the ucf file to help timing? Thanks.

Reply to
Anonyma
Loading thread data ...

One thing to check is that your final output flops are being mapped to pad registers, and not internal registers. That will eliminate any variability in prop delay due to different paths in the fabric, presenting a stable address more quickly. As a general rule, you should always register outputs at the pad, unless you have some good reason not to, especially for busses.

I'm not sure how to do that in ISE, though - I use mostly Altera at the moment.

Reply to
radarman

Follow the bouncing links from this old post for some notes about write strobe generation timing, and some SRAM test code for the S3 starter kit.

formatting link

Brian

Reply to
Brian Davis

Very important. In addition to eliminating variability, in Xilinx parts it can eliminate about 4ns of routing delay in each path ( = 8ns for the round trip ).

To check what's going on in this respect, look at the .mrp (Map Report) file in ISE. The IOB section (near the end) lists INFF, OUTFF (or OFF) and ENBFF for input, output and tristate flipflops in the IPB respectively.

To modify what's happening, there are a number of hoops to jump through. The first is to enable "map FFs into IOBs" settings in the tools; most of the others relate to preventing ISE from optimising away useful signals, like the FFs you need (e.g. if they are shared with internal logic). Apply "keep" attributes to prevent signals disappearing, and "equivalent_register_removal" = "false" attributes to appropriate registers. And keep trying until the right behaviour is reported in the .mrp file.

- Brian

Reply to
Brian Drummond

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.