spartan-3 sram

Hi,

Can you provide me a code piece to use async. sram e.g. in spartan-3 starter kit ? I could not get it work.

Thanks in advance.

Mete

Reply to
mete
Loading thread data ...

mete wrote: : Hi,

: Can you provide me a code piece to use async. sram e.g. in spartan-3 : starter kit ? I could not get it work.

You can't use BRAM as asynchronous memory.

A clock is always needed for the BRAMS

Bye

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

Good information, but perhaps not the information pursued. I was thinking the same thing when I first read the post.

Does anyone have experience with the "1M-byte of Fast Asynchronous SRAM (512Kx16 or 256Kx32)" that's included on the Spartan-3 starter board to help the original poster?

Reply to
John_H

You may have found these already, but there are a few example applications available for download from the Xilinx Spartan-3 Starter Kit Board web site.

formatting link

In specific, the Digital Clock PCB Monitor design and the MicroBlaze Master System both read and write to the 1Mbyte of external SRAM on the board. The PCB Monitor design uses the free PicoBlaze 8-bit controller core.

--------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/II/IIE FPGAs

formatting link

--------------------------------- Spartan-3: Make it Your ASIC

Reply to
Steven K. Knapp

Hi,

Thank you for the answers. I am talking about the fast async sram manufactured by ISSI on the board.

I have following code to read/write to/from async. sram on spartan-3 starter kit. However, it is not working correctly. Does it seem to work ? (then I may trace the bug anywhere else, this code is just a piece of the whole project) or is there a problem on it ?

Thanks in advance.

Mete

-----------------------------------------------------------------

clk is clock input (50Mhz) ub, lb, oe, ce and we are sram control. mdata sram bidirectional data. maddr sram address. udatain user data input. udataout user data output. uaddr user address. addrvalid indicates the address on the uaddr is valid. en indicates this address is for sram. done indicates read or write operation has been completed.

-- Uncontrolled Pins lb

Reply to
mete

Are you shure you can meet the timing with the single cycle access? With

50 MHz you have 20 ns, you can easily loose perhaps 10ns on tco for the address lines and the setup time for your input registers. I also would not use an input latch, try to use the clocked FFs. About write timing: Some SRAMS need a data hold after rising edge of nwe. Your timing between data out and nwe depends on the routing. To not waste an additional clock cycle on write I've used a neg-edge triggered FF for the nwe signal.

In general, I would first try to get the interface running with relaxed timing, i.e. use wait states. For an example you can find the VHDL code I'm using for SRAM interfacing at my website (under download in jop.zip): mem.vhdl is for a simple 8 bit memory, mem32.vhdl (as the name implies) for 32 bit. Just delete the stuff for Flash and NAND access from the code, than it's straight forward to use.

Martin

---------------------------------------------- JOP - a Java Processor core for FPGAs:

formatting link

"mete" schrieb im Newsbeitrag news: snipped-for-privacy@posting.google.com...

Reply to
Martin Schoeberl

Check the fine print in the data sheet.

If you just advance the we signal by clocking on the other edge, (that is move it earlier without changing the duration) you may not meet address setup times. (Which means the chip might write something to the wrong address(es).)

I agree that it would probably be simpler to get something working slowly at first. Writes generally work cleanly at 3 cycles: one for setup, one for active, and one for hold.

(Add a dead cycle between reads and writes to turn the bus around.)

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
 Click to see the full signature
Reply to
Hal Murray

If you pack the output flip flops into IOBs the timing is very well defined.

Or with spartan-3 use a second clock that is a few nanoseconds earlier compared to the global clock to output the WE.

Kolja Sulimma

Reply to
Kolja Sulimma

That fixes the trailing edge problems (hold times), but it might break the other/leading edge, the setup times.

I haven't checked the details on any data sheets lately. Most older SRAMs had 0 setup and 0 hold (maybe worse) for WE so just moving the WE pulse didn't solve the problem, just pushed it to someplace else.

What particular SRAM is on the board that started this thread?

Can the DDR logic be used to generate a 1/2 clock pulse? That would work with a slightly advanced clock.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
 Click to see the full signature
Reply to
Hal Murray

It is ISSI IS61LV25616AL.

Mete

Reply to
mete

Good to hear.

You might get down to 2 cycles by using the other edge of the clock for WE and putting it in the middle of the pair. OE would go on the second cycle. (Probablby work fine in the middle too - bus would just float a half cycle.)

Data sheet is at

formatting link

The timing diagram for WE controlled writes is on page 9. Numbers are back on page 8. Looks like pretty standard SRAM - 0 setup, 0 hold.

You can't do a single cycle write with simple/clean digital logic. The problem is skew - you can't guarantee that address will get there before WE to meet setup and also guarantee that it will get there after WE to meet hold times. (Or at least I can't see how to do it.)

One solution is to make WE slightly less than a whole cycle. You could do something like generate WE as the AND of a WriteEnable and the first half of the cycle. That AND will be in a CLB. There will be delays (relative to clocking the address and data in IOBs) so WE will come out in the middle of the cycle, right where you want it. That's if all the delays work out. I don't know if this is interesting for the initial question.

FPGAs may not be friendly for this sort of hacking - clocks don't get routed to CLB inputs. Better/cleaner to use a 2X clock.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
 Click to see the full signature
Reply to
Hal Murray

Indeed, is the technique I used in the XSOC/xr16 interface to async SRAM

formatting link
page 19 and 24), where I demonstrate how to issue two back to back writes, each in 3 clock edges (1.5 clock cycles), total 3 cycles.

Jan Gray

Reply to
Jan Gray

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.