Cyclone III or IV footprints

[Altera_Forum]

Hi, 

Long time ago, Altera FPGA based boards could be designed in a way that the same PCB could support multiple footprints. Is this something that Altera dropped and no longer supports?  We are designing a board that would benefit from this function a lot so we can deliver a low end and a high end design using the same PCB with alternative FPGA (choosing between F256, F484 and/or F672).  Best regards Farhad

[Altera_Forum]

--- Quote Start ---   Long time ago, Altera FPGA based boards could be designed in a way that the same PCB could support multiple footprints. Is this something that Altera dropped and no longer supports?   --- Quote End ---  I vaguely recall someone (perhaps Altera) having BGA footprints that were able to take different pin counts, but I have not seen this lately, so you can assume it is gone.    --- Quote Start ---   We are designing a board that would benefit from this function a lot so we can deliver a low end and a high end design using the same PCB with alternative FPGA (choosing between F256, F484 and/or F672).   --- Quote End ---  Even on FPGAs with the same BGA pin count, there are pins that are inconsistent. For a design I did for the Stratix II EP2S60/90/130 FPGAs in 1020-pin packages, I first had to make a spreadsheet of all 1020 pins, and then enter the pin function for each package type, then where there was a mismatch, decide whether to just mark the pin as a no-connect, or make sure there was a stuff resistor option, eg. for VREF pins that must be tied to ground or VCC. The stuff resistor options need a via on one of the pins next to the BGA pad that needs to be tied to VCC or GND, so you need to 'reserve' some I/O pins that become the location of a via.  Altera has spreadsheets of the pin functions, its just that they're not necessarily in the format or order you want. I wrote Tcl scripts to read their spreadsheets and reformat them, so its not too much of a pain to reformat the tables.  Cheers, Dave

[Altera_Forum]

Dave, did turning on the Device Migration feature not result in an accurate .pin file?

[Altera_Forum]

Hi, 

  --- Quote Start ---   did turning on the Device Migration feature not result in an accurate .pin file?  --- Quote End ---  I was taking a more system-level approach in that I wanted to make sure I could physically layout the PCB with decoupling capacitors, termination resistors, and stuff-resistors soldered directly on the BGA vias on the bottom of the board using via-in-pads. Because I always needed a GND via next to a power pin, or next to a VREF pin, I had to look carefully at the BGA package and the fixed pin functions, to decide where I wanted to assign signals; some I/O pads become inaccessible due to the fact I want a GND via in the I/O pins nominal via location.  Check out the pin assignment BGA diagrams on p53, p64, p65  http://www.ovro.caltech.edu/~dwh/carma_board/engineering_specification.pdf (http://www.ovro.caltech.edu/%7edwh/carma_board/engineering_specification.pdf)  The PCB files and a link to a viewer can be found here;  http://www.ovro.caltech.edu/~dwh/carma_board/index.html (http://www.ovro.caltech.edu/%7edwh/carma_board/index.html)  if you wanted to look at the PCB layout.  The bottom of the BGAs on the boards are pretty cool as 0402 capacitors and resistors are pretty darn small!   I did not use the Device Migration manager to implement this. Do you think it would have been able to incorporate all of these design decisions? Perhaps I'll look at it for the Stratix IV GX project I am working on.  Cheers, Dave

[Altera_Forum]

wow, that is very thorough. thank you for sharing

[Altera_Forum]

--- Quote Start ---  We are designing a board that would benefit from this function a lot so we can deliver a low end and a high end design using the same PCB with alternative FPGA (choosing between F256, F484 and/or F672).  --- Quote End ---   Cyclone family FPGAs have the dedicated clock inputs at the two outermost BGA rows, so a migration across different package sizes is effectively impossible considering this detail.  But you have vertical migration within the same package, which should basically fulfill your intention. Most of the FPGA price is paid for the chip size, the differences between small and large packages are moderate.

[Altera_Forum]

Hi everyone, 

Thank you very much for excellent responds. I think we will go ahead and work on the F484 package that gives us plenty of devices to choose. I have to create a new symbol to only use the pins commonly available for all the device.  Best regards, Farhad