High Speed Shared Memory Bus Issues?

[jeffr]

Hi All,

I'm designing a PCB that has an FPGA connected to two SRAM chips in order to double the RAM.
To keep the number of IO on the FPGA to a minimum, the address and data buses are shared between the two SRAM chips (shown in attached picture).

The memory runs at 800MHz which is higher speed than what I'm used to designing PCBs for.
Will sharing the buses cause impedance or capacitive issues at this frequency?

Any advice on the topic will be helpful.

Thanks

[T3sl4co1l]

What signaling standard? LVCMOS, SSTL?

SSTL has termination options.  They're, well, optional, but situations like this make them necessary.

You're not looking at impedance or inductance or capacitance, but transmission lines and pulse edges!  Needless to say, you need at least a 4 layer board to get the controlled impedances, though that's probably a given with the FPGA and RAM, which I'm guessing are probably BGA packages.

Tim

[jeffr]

Thanks for your reply Tim.

From what I've read on the datasheet the standard is 1.8V CMOS but the SRAM has "Programmable Impedance":

An external resistor, RQ, must be connected between the ZQ pin on the SRAM and VSS to allow the SRAM to adjust its output driver impedance. The value of RQ must be 5x the value of the intended line impedance driven by the SRAM. The allowable range of RQ to guarantee impedance matching with a tolerance of ±15% is between 175 Ohm and 350 Ohm.

You're right about the 4 layer PCB and BGA packages.
Because of the BGA packages, the traces are limited to 5mil width. OSH Park will probably be used to make the PCBs and using their 4 layer stackup description (attached), an online impedance calculator estimates 80 Ohm for a 5mil trace which is within the 15% tolerance for the SRAM(attached).
What is confusing me is these calculators don't take into consideration the length of the traces.


Jeff

[T3sl4co1l]

Is that not FR-4?  e_r is usually 4.2-4.8, and higher for prepreg than core material.

IIRC, 1.8V LPCMOS is intended for low power, and is a little different from SSTL, and using the SDRAM controller (at least) required an extra license..  whereas the SSTL version didn't...

Length is not a parameter in the characteristic impedance of a transmission line, only the cross section matters.  Read up on transmission lines!

The short of it is, a true electrical delay looks like series inductance or parallel capacitance at low frequencies (indeed, most of the time this is what real capacitors and inductors are composed of), but the impedance becomes complicated at frequencies having a wavelength near the electrical length of the transmission line.  When the line is properly terminated at one end, it looks like a perfect resistor at the other end; at other matches, the impedance is reflected or transformed, depending on length and mismatch.

If you think about impedance, versus time rather than frequency, then a transmission line looks like its characteristic impedance until a reflection comes back.  A pin driving the trace from the end, with source matching (typical for CMOS pin drivers), makes a voltage divider of equal resistances, and therefore the pulse (as seen at the source) has a flat spot at VDD/2 for twice the line length.  When the wave reflects off the end and comes back (hence twice the delay), if it's the same amplitude (i.e., wasn't terminated at the load end), it adds to the existing voltage (superposition), and stabilizes at VDD.  If the load end is terminated, then no wave comes back, and it stabilizes at VDD/2 at both ends (which is what you expect at DC, because it has source and load resistors which act as dividers).  Or you can use a low impedance unmatched source and a matched load, in which case the steady voltage is a little less than VDD.

For a source in the middle of the line, the two halves of the line act in parallel, and the source initially sees half Zo.  When the nearer (stub) reflection comes back, it reinforces the source and it acts like a regular (end) driver.  It's not possible to have full CMOS logic levels, and have sources connected this way, because CMOS pin drivers cannot deliver full VDD/GND to such a low impedance.  This is basically why SSTL exists: a small, well defined logic threshold around VREF (which is held near VDD/2), and using source and load termination resistors (which still can't prevent stub loading effects -- indeed, all sources and loads see Zo/2 -- but do prevent reflections, so signal quality is still good).

Needless to say, to verify the signal quality, you need an oscilloscope with bandwidth that includes the electrical length of the traces, and the edge speed of the devices.  Which I guess is several GHz in this case.  And you need probes and testpoints capable of connecting to it with similar fidelity.

Tim

[nctnico]

I'd go for DDRx memory and an FPGA which has a dedicate DDR memory interface. That will be much easier to get working reliably than two seperate SRAMs on an 800MHz memory interface. With DDR memory the timing between the memory and FPGA are strictly specified so you really have to mess up the routing for it not to work.

[marshallh]

OP must be using some type of SSRAM, maybe QDR. In this case I woudl refer to the mfg's reference designs for interfacing with this type of external memory.

And as others said, use DDRx when you can. The latency is minimal but not quite as low as sram.

[DutchGert]

I'd go for DDRx memory and an FPGA which has a dedicate DDR memory interface. That will be much easier to get working reliably than two seperate SRAMs on an 800MHz memory interface. With DDR memory the timing between the memory and FPGA are strictly specified so you really have to mess up the routing for it not to work.

Uhm what? Due to the very tight timing constrains of DDR memory on of the hardest things is the actual routing.

Bu i totally agree, go for an FPGA with a dedicated memory controller and use DDRx memory. Probably cheaper as well

[nctnico]

I'd go for DDRx memory and an FPGA which has a dedicate DDR memory interface. That will be much easier to get working reliably than two seperate SRAMs on an 800MHz memory interface. With DDR memory the timing between the memory and FPGA are strictly specified so you really have to mess up the routing for it not to work.

Uhm what? Due to the very tight timing constrains of DDR memory on of the hardest things is the actual routing.

No. As long as you keep the length of the data + data clock traces equal to in each byte lane things will be OK; up to some limit the routing delay is pretty much taken out of the equation. The address and control lines on a DDR memory interface effectively run at half the clock rate so they are much more forgiving when it comes to routing them. No matter how you look at it, routing a DDR interface will be much easier than a parallel SRAM at high frequencies.

[DutchGert]

I'd go for DDRx memory and an FPGA which has a dedicate DDR memory interface. That will be much easier to get working reliably than two seperate SRAMs on an 800MHz memory interface. With DDR memory the timing between the memory and FPGA are strictly specified so you really have to mess up the routing for it not to work.

Uhm what? Due to the very tight timing constrains of DDR memory on of the hardest things is the actual routing.

No. As long as you keep the length of the data + data clock traces equal to in each byte lane things will be OK; up to some limit the routing delay is pretty much taken out of the equation. The address and control lines on a DDR memory interface effectively run at half the clock rate so they are much more forgiving when it comes to routing them. No matter how you look at it, routing a DDR interface will be much easier than a parallel SRAM at high frequencies.

I agree with you that DDRx will be better to contain than SRAM at this frequencies but I won't go as far as calling a DDRx layout trivial .

Doing a DDR3 layout with fly-by architecture where u have to make sure the whole address/command/control/clock bus is matched to 5ps (~0.8mm) including internal package delays can be a pain. So don't underestimate it.

[jeffr]

Thanks for the explanation Tim and every one else for your suggestions.
I wanted to use DDR2 because the FPGA I'm using has a built in controller but was put off by all the different latencies that are mentioned in the data sheet.
I don't know if the overhead of DRAM will cause timing problems for this project  . I apologize in advance for my lack of DRAM knowledge.

The project requires very low latency and constant alternation between reading and writing to RAM at different addresses.
The FPGA needs to write in to RAM at a constant 300MHz BUT it also needs to read from RAM at a constant 300MHz from a different address than what is being written to.
Minimum buffering is important to keep latency low.

If I use 400MHz DDR2 memory (800MHz DDR Rate), is it possible to achieve the required timings I described?


Thanks

PS. AS4C64M16D2 is a DDR2 memory in consideration if that helps anyone.

[nctnico]

I'd stick to memory from Micron since that is what most of these interfaces are tested with. Regarding routing: there should be a memory layout guide which should guide you through the process of getting routing of the traces right.
I don't know which FPGA you are going to use but the Xilinx Spartan 6 DDR interface allows multiple memory interfaces towards the FPGA fabric so you can read and write at the same time to different addresses. The memory controller sorts out how to do the actual transfers. With a 16 bit memory you have 800MB/s with a 400MHz DDR rate (200MHz clock). Wanting to read & write at 600MB/s in total could work but I'd try to keep margin in the design to increase the DDR clock frequency in case you run out of memory bandwidth. Also keep in mind that DDR memory works in bursts so you'll need to pipeline commands towards the DDR interface to keep the data flowing.