Crossing banks in an FPGA - Page 1
Forum section: electronics / general

author: MattHollands
author_rank: Frequent Contributor
timestamp: July 17, 2018, 08:34:13 pm
content: So I have done a little work with FPGAs before but I have never designed my own PCB for an FPGA before.Regarding pin assignment, should I worry about assigning similar pins to the same IO bank? For example if I have a 16 bit parallel bus into or out of the FPGA, how big a deal is it if I have to split it across two IO banks?Also, if only one of my banks has a PLL, is it an issue if I clock the FPGA from a global clock pin in another bank and then connect it to the PLL?Any other considerations to take into account would be interesting to know about...

author: ataradov
author_rank: Super Contributor
timestamp: July 17, 2018, 08:50:00 pm
content: In generalQuote from: MattHollands on July 17, 2018, 08:34:13 pmIn general it does not matter, but you still need to read the documentation for the specific FPGA and understand all the constraints. For example, MAX 10 in TQFP package does not let you have an output pin next to the cock input going into the FPGA. Limitations like this creep up all the time.In generalQuote from: MattHollands on July 17, 2018, 08:34:13 pmDepends on the FPGA architecture.In generalQuote from: MattHollands on July 17, 2018, 08:34:13 pmFPGA companies provide extensive documentation on pin allocation and possible limitation, you should definitely spend a day reading that.And when you are done with pin assignment, create a dummy project, but with correct pins configured and try to compile the project. IDE will flag if there are additional issues with your assignments. It will obviously not flag things like PLLs and their inputs automatically, but it does not take much time to put a PLL and see if it still works.

author: hamster_nz
author_rank: Super Contributor
timestamp: July 17, 2018, 09:00:41 pm
content: Quote from: MattHollands on July 17, 2018, 08:34:13 pmUsually unless you are using advanced features or have tight timing requirements it probably doesn't matter too much if pins are spread over I/O banks. It is not best practice, but it can work just fine.However for anything vaguely complex, design and implement your proposed clocking and I/O structures before you finalist your PCB design.You may discover that the desired clocking resource can't reach the desired I/O block, or that timing can't be met, or that clock pin isn't a global clock pin, or many other issues that might pop up.Maybe use a random pattern generator to produce a load to drive the pins, to prevent optimizations from hiding issues.

author: Scrts
author_rank: Frequent Contributor
timestamp: July 18, 2018, 10:23:33 am
content: One advice that ALWAYS helps me:before you do the final PCB release - do the pin assignment in the FPGA software and compile the design. If it will go successfully with all the assignments - then it is safe to release the PCB. If you're using specific blocks (e.g. DDR memory or so), remember to instantiate those blocks in the design before compile as well. Also remember to set the correct pin type (I/O, LVDS, etc) and voltage. All I/O voltages have to match the bank power voltage, unless it's a differential pair. I remember I had the bank and all the pins in the bank at 1.8V level, but routed an external oscillator to the clock input at 3.3V swing. The FPGA worked, but got really hot. Took me some time to realize what's going on.

author: asmi
author_rank: Super Contributor
timestamp: July 18, 2018, 01:07:45 pm
content: Without more details - like FPGA you're going to use and your package of choice, bus parameters (frequency, SDR/DDR), it's impossible to provide any realistic advice.

author: james_s
author_rank: Super Contributor
timestamp: July 21, 2018, 05:03:22 pm
content: Quote from: ataradov on July 17, 2018, 08:50:00 pmThat's a feature I wasn't aware of. I'm not sure I want to know what it's purpose is

author: kony
author_rank: Regular Contributor
timestamp: July 21, 2018, 06:43:03 pm
content: To avoid switching noise coupling very likely (and epsecially with TQFP packages). Nothing extraordinary in that, the additional jitter on the input won't exactly help the internal PLL function.

author: KaneTW
author_rank: Frequent Contributor
timestamp: July 21, 2018, 07:07:08 pm
content: Quote from: james_s on July 21, 2018, 05:03:22 pmObviously it's for interfacing with a high-precision rooster clock.