[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: random project idea



I have routed a 900 pin bga 1mm pitch on 4 signal layers.

30x30

using Larry's math

30/2 - 2 = 13 layers.... this seems pessimistic. 

for details see
 
http://archives.seul.org/geda/user/Jan-2005/msg00196.html


Steve M.

On Thu, 2008-03-27 at 17:21 -0700, Larry Doolittle wrote:
> Guys -
> 
> On Thu, Mar 27, 2008 at 04:22:34PM -0700, Jesse Gordon wrote:
> > DJ Delorie wrote:
> >>>   http://www.xilinx.com/products/boards/ml410/index.html
> >> They have a lot of support chips on that board, though.  Like the
> >> south bridge, CF controller, PCI bridge, etc.  I was thinking more
> >> like "every connector goes directly to an FPGA pin".  Maybe one fpga
> >> for the cpu core and one for the peripherals, though.
> >>   
> > I like the idea. If the main FPGA was big enough, maybe it'd only need  
> > one, but I guess we're trying to avoid
> > more then 4 layers, and big bga=more then 4 layers.
> >
> > But if two fpgas were sitting right besides eachother, with about 25  
> > pins lining up, and just connected right together, (with qfp) the run  
> > would be short, straight, and all the same length, it could be over  
> > ground-plane layer there. I think considerable fpga-fpga speeds could be  
> > attained. If the run was short enough, it may
> > /work/ without termination. By having several such fpgas in a row, each  
> > connected likewise to the one near it, or maybe having 1 in the middle  
> > then 4 around it, one on each side, I'm sure enough pins could be  
> > attained to feed all the peripherals.
> >
> > It may even be doable on a 2 layer board, but four is much more then  
> > twice as good as 2.
> > (I think it's more then twice the cost too :-)
> >
> > Interfacing to the ram at high speeds could be tricky, so it might be  
> > better to have the ram in parallel (wider data bus) rather then longer  
> > address space,
> > to allow faster byte/sec without faster addresses/second.
> 
> All interesting ideas, but fundamentally not new.  The bigger/faster/cheaper
> FPGAs get, the more interesting it gets.  A few comments on details:
> 
> 1. Self-reconfigurable FPGAs have been promised for years, but aren't
> ready, and probably never will be.  Think carefully about the boot
> sequence, and how one FPGA can boot the next.  Having more than one
> FPGA is probably a good thing.
> 
> 2. For Ethernet, you don't want a PHY+MAC, just a PHY.  The pin count
> is lower and the result is more FPGA-like.  I have a demo of
> Gigabit-compatible IP/ARP/UDP in 200 cells plus 32 kbits RAM.
> I will probably even work on making it useful for real-time
> communications in the next year.
> 
> 3. A large BGA can be useful even without a lot of board layers.
> Assume 1mm pitch and 5/5 space/trace.  In concept, reaching all
> n^2 pads can take approximately n/2-2 routing layers, although that's
> an overestimate because many interior pads are power and ground.
> Practically, it takes six layers for 170 user I/O on a 256-pad BGA,
> and the layer count rises rapidly for those 600 to 1200 pad monsters.
> If you only route the outer four rows, however, you get 16*(n-4)
> pads with two routing layers (four physical layers with power/ground).
> A 676-pad package (26x26) gives you 352 routable pads like that.
> 
> 4. You can do a lot with FPGA plus DDR SDRAM, outside of traditional
> CPU design.  Just look at Elphel's model 333 camera.
>   http://www3.elphel.com/
> Ogg Theora _en_coding faster than most PC's can _de_code it.
> 
> 5. I have always been impressed by Jan Gray's CPU in FPGA designs.
>   http://fpgacpu.org/
> Jan himself has moved on to other work.  If anyone wants to talk shop
> about CPUs in FPGA, like how to add Cache, MMU, and SDRAM to a 32-bit
> Gray-esque processor, let's find a better list.
> 
>   - Larry
> 
> 
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user