On 04/02/2010 08:04, rickman wrote:
> On Feb 4, 12:22 am, TSMGrizzly<sbatt...@yahoo.co.jp> wrote:
>> Hi guys.. I'm getting ready to start working on my first board layout
>> with a BGA package (FG456). First will be a prototype for sure.
>> I was just wondering a few things...
>>
>> Probably the critical part of my design will be interface to a few
>> asynchronous SRAMs.
>>
>> In a relatively low speed design (buses at 10-25MHz) do I need to
>> worry about things like termination and trace length on the RAM buses?
>> Should I dedicate address/data pins to each chip in a shared memory
>> space, or is it better to daisy chain them on a bus? (It seems to me
>> that routing will be a little easier if each chip gets its own
>> lines..)
>
> You don't say how many SRAM chips. The first thing to consider in
> evaluating SI (Signal Integrity) issues without a simulation is to
> compare the length of the traces to the length of the edges of your
> signals. The rule of thumb I have seen is that if the rising/falling
> edges of your signals are six times longer than the length of the
> trace (round trip) then you don't need to worry with reflections no
> matter how many chips are in the path. All chips will see essentially
> the same edges and there will be little ringing. Using an FPGA, you
> can control the edge rates on the address bus. But on the data bus,
> you can't control the edge rate from the SRAM chips. If it is too
> fast (very likely with fast SRAM parts) the data bus will need to be
> terminated. Terminating multipoint busses is nearly impossible and
> even a simple two point bi-directional bus is not optimal but can be
> done using series termination.
>

You have a lot more experience at this sort of thing than me, Rick, so
I'm a little wary of disagreeing with you. But I'm sure you'll tell me
if I get something wrong!

I don't see that you have to worry about any termination here. With
fast enough signal edges, you can get ringing - but that typically will
not matter because you don't sample the signals until the ringing has
subsided. When the FPGA is driving the signals, you have (as Rick says)
controllable rise and fall rates to avoid ringing. If you don't have
that, you will want to terminate critical signals like the read and
write strobes (or clock, for synchronous rams) to avoid triggering
multiple accesses. But other than that, just make sure the data and
address lines are stable before the strobes are sent. For reads, it's
possible that you will get ringing due to fast edges from the ram chips
(though that would require very over-spec'ed ram chips far away from the
FPGA), but you time your read sampling for after the lines have settled.

Ringing can cause a few problems - the overshoot/undershoot can go
outside the voltage range of the pins on the line, it can cause
interference for neighbouring signals, you can't read the signal while
it is ringing, and it can cause big trouble when connected to
edge-sensitive inputs. But most of these are not going to be a problem
in your case, I think.

If you need to access your rams in parallel, you will need multiple data
buses, and perhaps multiple address and control buses - that depends on
the application. But if you just want to access one at a time, I'd put
them all on the same bus. Routing between the chips will be easy, and
you have less lines from the FPGA to worry about. At the speeds you are
talking about, you should have no difficulties.

> If you have enough I/O pins on your FPGA to use separate data busses
> to the SRAMs, you can terminate each bus using a series resistor to
> match impedance of the driver to the impedance of the trace. This
> results in a reflection from the receiver, but the receiver sees the
> proper transition (since it is the point of reflection) and the
> reflection will not be reflected from the driver. If any other chips
> are connected in the middle of this signal, they will see a half
> voltage rise followed by a second rise to the full waveform voltage...
> not what you want. But then, if you allow time for reflections to
> settle in your timing analysis, you can ignore the SI issues on the
> data and address busses and only be concerned about the timing signals
> like the Write strobe. The address has to be stable by the leading
> edge of the write strobe and the data has to be stable by the trailing
> edge. On a read, you simply need to allow some extra time for bus
> settling before the FPGA clocks the data in.
>
>
>> If I won't be using the innermost IO pins, can I get away with a 4-
>> layer design, two signal layers and power/ground?
>
> Likely, but you will need to consider a number of thing such as your
> design rules in the layout.
>
>
>> Looking at a Xilinx app note with a suggested escape route for this
>> package, they have three signal layers with 5 mil width traces, the
>> third of which I believe I can do without...
>> And lastly, I guess that I will be needing 1.8 and 2.5V supplies, as
>> well as 3.3V for all of my I/O supplies.. should these all be routed
>> in the dedicated power layer? If the layer is mostly covered a plane,
>> which voltage is supposed to be the plane? 3.3V?
>
> Any voltage that will have switching currents on them should have a
> power plane to optimally filter out the transients... in other words,
> all of them. What family are you using that requires 2.5 volts as
> well as 1.8??? I thought the recent stuff was all at 1.2 volts for
> internal logic and the I/O voltage to match your needs. Are you
> planning on using 2.5 volts for I/O or are you looking at an old
> family? Or maybe I'm not remembering correctly???
>

There is a big difference between "optimal" and "good enough". If the
design is fairly small and slow, with low currents, then wide traces to
the power pins and some capacitors is going to be perfectly sufficient -
there is no need for dedicated power planes for each supply.

>
>> And lastly, when connecting I/Os, is there any sensible approach? My
>> tendency is to want to choose the I/Os so that everything lines up
>> nicely, but I find it to be a hassle in this case, that in Eagle we
>> have to connect nets in the schematic first and can't back-annotate
>> from the board.
>
> They why use Eagle? I do my layouts in FreePCB. It doesn't support
> back annotation actually, but I use forward annotation (updates). I
> plan my pin swaps and add them to the schematic, reload the new net
> list and then finish up the routes at the FPGA. It has been a while
> since I have done this, so it may be trickier than I am remembering.
> I find it very nice to be able to route with minimal vias. That also
> helps to minimize the number of layers needed.
>
>
>> Anything else I should be worrying about?
>
> If this is your first board layout, leave yourself plenty of time and
> do a lot of checking of your work as well as checking the tool.
> There's many a slip twixt cup and lip. I found my first board layout
> to be a real education...
>
> Rick