sync or async SRAM?
Stefan Rave
asynchronous SRAM? What's the advantage of synchronous SRAM, anyway?
Bob Perlman
Synchronous, hands down. You don't have to generate write pulses.
(As an exercise, try generating a write pulse that is guaranteed to
meet all RAM timing requirements.)
Synch SRAM was a wonderful addition to Xilinx parts; let's thank
Xilinx by using it.
Take care,
Bob Perlman
Stefan Rave
thanks for the pointer, it is helpful for my understanding. But I don't
quite understand your remark,
> Synch SRAM was a wonderful addition to Xilinx parts; let's thank
> Xilinx by using it.
Are you talking about internal SRAM cells (using CLBs)? Or does Xilinx
provide synch SRAM? -- My original question referred to _external_
memory.
Stefan
Stefan Ludwig
Bob was talking about INTERNAL SRAM in the CLBs. His comments about write
pulses hold also for external SRAM. Sync RAMs (S or D) are much more
convenient than async RAMs. With sync RAMs, you (only) have to
handle the clock signal carefully, whereas with async RAMs, there are the
write pulses, ras/cas and the address lines, which have to be delay matched.
Regards,
Stefan Ludwig
Systems Research Center
Compaq Computer Corporation
130 Lytton Ave
Palo Alto, CA 94301-1044
USA
Tel: ++1 650 853 2227 Fax: ++1 650 853 2235
mailto:lud...@pa.dec.com http://www.research.digital.com/SRC
msi...@tefbbs.com
On the other hand if you are writing code in C++ 64MB may not be
enough.
Simon
=================================================================
lud...@pa.dec.com (Stefan Ludwig) wrote:
Opinions expressed herein are solely my own and may or may not reflect my opinion at this particular time or any other.
msi...@tefbbs.com
Ray Andraka
to use the Async modes other than in porting an old design. Newer
devices (eg Spartan) do not even support the async modes.
I rather suspect you were referring to external ram, and that really
works out to a big depends. Let's assume SRAM for the time being. If you
need to do interleaved reads and writes, you will get more memory
bandwidth from asynchronous parts because there is a dead cycle between a
read and write cycle using the synchronous parts. If your application
requires interleaved reads and writes, you'll waste a lot of clocks in
dead time.
On the other hand, using synchronous SRAMs provides a considerably higher
burst access rate than async parts due to the pipelining achieved. This
means that as long as you are not switching between reads and writes all
the time, the sync part will do much better (and is easier to interface
too). It also costs more.
Stefan Rave wrote:
> What is the best choice for use with an XC4000XL FPGA: synchronous or
> asynchronous SRAM? What's the advantage of synchronous SRAM, anyway?
--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email rand...@ids.net
http://users.ids.net/~randraka
Stefan Ludwig
> works out to a big depends. Let's assume SRAM for the time being. If you
> need to do interleaved reads and writes, you will get more memory
> bandwidth from asynchronous parts because there is a dead cycle between a
> read and write cycle using the synchronous parts. If your application
> requires interleaved reads and writes, you'll waste a lot of clocks in
> dead time.
You can use ZBT (zero bus turnaround) sync SRAMs. They have no dead cycles
and are just wonderful. Micron, Motorola and IDT make them.
Stefan
Edward Moore
<lud...@pa.dec.com> writes
>You can use ZBT (zero bus turnaround) sync SRAMs. They have no dead cycles
>and are just wonderful. Micron, Motorola and IDT make them.
>
Interfacing to ZBT rams using Xilinx 4000 series FPGA's is complicated
by possible data bus contention when changing from a write to a read
cycle. The Xilinx tristates the data bus much later (clock to hi-Z)
about 10 ns) than the ram drives the bus (clock to lo-Z about 2 ns). The
Micron web-site has articles about this, and the implications on
increased power-dissipation.
In the new 4000XLA devices, the IOB's have a registered tri-state, which
helps a lot.
NB, Cypress make almost pin-compatible versions called NOBL (NO Bus
Latency), and i think also ISSI.
--
Edward Moore
Ray Andraka
writes there was an issue on the timing. I don't recall for sure, but I think
there was a dead cycle caused by the way I needed to access it. I'll look into
my notes and let you know what the issue was. Whatever it was, in that
particular case it was an expensive solution that didn't quite fix the
problem. (I was looking at the IDT parts, and that was right after they were
introduced).
Stefan Ludwig wrote:
> You can use ZBT (zero bus turnaround) sync SRAMs. They have no dead cycles
> and are just wonderful. Micron, Motorola and IDT make them.
>
> Stefan
Simon Ramirez
>What is the best choice for use with an XC4000XL FPGA: synchronous or
>asynchronous SRAM? What's the advantage of synchronous SRAM, anyway?
Stefan,
The best choice of SRAM can only be answered by you, because only you
know what the application is. You have constraints and parameters that we
do not know about; therefore, only you are capable of answering that
question.
The advantage of synchronous SRAM is that it breaks up the total path of
delays into two paths of delay. These two paths have less time associated
with them than the longer path used by asynchronous SRAM, which makes the
design faster.
For example, assume that in your design the FPGA is generating the
address and using the data provided by the SRAM during a read cycle. If you
are using asynchronous SRAM, you have the clock to address out time (FGPA),
then the access time of the SRAM (data valid after address valid), then the
setup time of the FPGA to capture the data.
If you use a synchronous SRAM, you have the clock to address out time
(FPGA) and setup time (SRAM) for the first clock cycle. This path is less
than the path described in the above paragraph for the asynchronous SRAM.
The second path is clock to data valid out (SRAM) and setup time (FPGA) for
the second clock cycle. This path also is less than the path described
above.
While you can run the clock cycles faster, it takes two clock cycles to
get one piece of data out, right? What if you want burst data out of the
SRAM? Then it takes three clock cycles to get two pieces of data, four
cycles to get three pieces of data, etc. So if you burst 256 pieces of
data, you need 257 clock cycles. The advantage of synchronous SRAM is that
these clock cycles are much faster than clock cycles of the asynchronous
clock cycles.
Also, the reason that Bob Perlman thought that you were talking about
synchronous SRAMs in FPGAs is because this is an FPGA newsgroup!
Fortunately for all of us, Xilinx and others gave us the ability to use
internal SRAM, synchronous and asynchronous. So naturally I can see where
he assumed that you were talking about internal SRAM.
I hope this helps.
-Simon Ramirez
Stefan Rave
topic. It helped a lot for my fundamental understanding of the matter.
Meanwhile I've gathered data on Micron ZBT SRAMs, and I intend to use
this type. For this reason, Ray, if you happen to come across those
notes you mentioned, I'd still be interested in information on a problem
with using ZBT. Presently, I don't see any.
Thanks again,
Stefan
Ray Andraka wrote:
>
> When I last looked at the ZBT's for an application where I had interleaved read
> writes there was an issue on the timing. I don't recall for sure, but I think
> there was a dead cycle caused by the way I needed to access it. I'll look into
> my notes and let you know what the issue was. Whatever it was, in that
> particular case it was an expensive solution that didn't quite fix the
> problem. (I was looking at the IDT parts, and that was right after they were
> introduced).
>
> Stefan Ludwig wrote:
>
> > You can use ZBT (zero bus turnaround) sync SRAMs. They have no dead cycles
> > and are just wonderful. Micron, Motorola and IDT make them.
--
Stefan Rave
Dept. of Computer Science
University of Dortmund, Germany
ra...@LS12.cs.uni-dortmund.de
Ray Andraka
issue with timing of data in a certain sequence of reads and writes, but I sure don't
see it now looking at the data sheet. I can't find the reason I rejected the part in
my notes either. Now I'm wondering if it was just an availability or real-estate
problem (I needed two banks of 64kx16 on each of 4 FPGAs). I wound up using 12ns
64Kx16 SRAMs running at 42 MHz interleaved read/write with a 4025E-2 in that
application. It's possible I was recalling the original sync SRAMs that required a
dead cycle. I must be getting old!
In any event, looking again at the ZBT data sheet, I see no reason not to use them if
you speed requirements justify the extra expense. You will have to be careful about
clock skew because of the relatively fast clock to Q of the memory (you may need to
turn on the input delay on xilinx, which will diminish the performance advantage).
Stefan Rave wrote:
> First of all, thanks a lot to everybody who gave me advice on this
> topic. It helped a lot for my fundamental understanding of the matter.
>
> Meanwhile I've gathered data on Micron ZBT SRAMs, and I intend to use
> this type. For this reason, Ray, if you happen to come across those
> notes you mentioned, I'd still be interested in information on a problem
> with using ZBT. Presently, I don't see any.
>
> Thanks again,
> Stefan
--
lakshman...@gmail.com
lakshman...@gmail.com
edmoore
> What is the best choice for use with an XC4000XL FPGA: synchronous or
> asynchronous SRAM? What's the advantage of synchronous SRAM, anyway?