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.

Anonyma wrote:
> 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.

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.

Anonyma wrote:
> 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.

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.

http://groups.google.com/group/comp....222450bf8e47c8

Brian

On 3 Nov 2006 05:05:24 -0800, "radarman" <[email protected]> wrote:

>Anonyma wrote:
>> Hi,
>>
>> This is a question about digilent spartan-3 starter board ,
>> which has a simple 10ns sram and 20ns clock.
>> ... A simple testing
>> circuit shows that about 0.2% read errors.

>> Is it possible to put some timing or other constraints
>> in the ucf file to help timing? Thanks.
>
>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,

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 ).

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

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