My project involves several BGA packages, specifically Ethernet PHYs connected to a central FPGA. I’ve already planned out a preliminary layer stackup to determine which signals will run on which layers. Now, I need a solid strategy for pin assignment. While a PHY will naturally fan-out in a distinct order, I want to strategically assign pins from the FPGA to ensure an organized layout and avoid unnecessary trace rearrangements later on.
For instance, the interface I’m dealing with is standard GMII, which involves a 16-bit bus along with control signals. What are some effective methodologies for assigning FPGA pins to achieve the most logical fan-out order for traces leaving the FPGA?
I’d recommend to dive supply pins toward the center if you can. For additional guidance I suggest the BGA Breakout book I always recommend for this, the one by Charles Pfiel and published by Mentor Graphics.
2 Likes
The GMII interface is a nice pair of source synchronous interfaces where the clock is supplied with the data. As the clock is just 125 MHz, the signals associated with each clock should be fairly straightforward to constrain, and so your routing should not prove difficult. Matching the signal flight times on the PCB will be easy (it does not have to be very precise). This means that you have maximum flexibility when it comes to choosing the pinout of the FPGA.
Although the FPGA gives you a lot of choice over pin assignment, most devices have a preference for which pins you are going to use for clock inputs. It is therefore better to have your incoming clock (RXCLK) be associated with a pin that can feed a clock network. The clock going out is just a standard output pin, so this one isn’t critical.
Beyond that, look at how you are going to break out the Phy, then make the FPGA pins fit this order thus avoiding the need to cross signals over each other. The only allowance that is worth making is to make sure the RXCLK goes to a pin that can feed the internal clock network in the FPGA.
The Phy will probably give you options about how the RXCLK is generated. You need to give this a bit of thought. One option will be to make the RXCLK frequency be the sourced from the TXCLK. This means that both RXCLK and TXCLK are in the same clock domain, though the phase relationship is unknown (but constant). This makes the FPGA a bit easier to work with, but the data is coming from the Ethernet cable is at a rate that is never precisely the same as the clock on your board, therefore you will need the Phy to have a suitably sized elastic buffer (FIFO) to accommodate the rate differences. In most cases it is better to let the external data source determine the frequency of the RXCLK and include sufficient memory in the FPGA to compensate for this time discrepancy (this way it is in your control because it is in the FPGA which has more flexibility than the Phy).
If your FPGA has a lot of IO pins spare, you can turn these to good use by making some of them be 0V pins. To do this, define the pins as outputs that drive 0V and connect the pin to 0V. As the output switching elements are MOSFETs, this will conduct happily in either direction, so the 0V on the die becomes better linked to the 0V on the PCB. This makes the FPGA output signals be less noisy and improves jitter on the clocks. This is a practice that is recommended by the FPGA manufacturers.
If you have a lot of Ethernet Phys, have you considered using SGMII (the serial version of GMII)? This runs at 1.25 Gbps, but is a single differential pair in each direction. The clock is embedded in the data, so apart from the differential nature of the signals which will require specific IO_p and IO_n pairs to be used, the routing becomes trivial. With most of the FPGA IO structures available, the SGMII pairs do not need to be connected to the high-speed SERDES pins; most of the standard IO pins have mini SERDES blocks behind them. The conversion of GMII to SGMII is normally possible using free code from the FPGA vendor. This does of course use FPGA logic to perform these functions, but if you’re not stuck for space in your device this way makes for very quiet PCBs because all your ethernet signals are differential.
The book recommended by Allank is quite good. If you have some spare time take a look at the article written by Howard Johnson: BGA Crosstalk. Maybe it helps to find the optimal FPGA (at least in terms of signal integrity and EMC).
1 Like
If your design isn’t finalized and you can still change pin assignments, you have some flexibility in placing components.
Step 1: Identify Fixed Pins: First, determine which pins are fixed. For example, an FPGA might have dedicated clock inputs or high-speed transceivers that can only be used on specific pins. Some clock inputs might only connect to certain PLLs, so it’s important to decide early on where these clocks will go.
Step 2: Plan Interfaces: Next, decide where interfaces can go. Ensure that parallel interfaces use pins close to each other to avoid routing issues. For example, you don’t want one bit of an interface on the opposite side of the FPGA. Also, consider voltage requirements. FPGAs have different banks with distinct IO voltage references. Typically, you can’t mix different voltages in the same bank (e.g., 2.5V and 1.8V). Ideally, place all pins of a parallel interface in the same or adjacent banks, preferably within the same corner of the FPGA (Top-Left, Top-Right, Bottom-Left, Bottom-Right).
Step 3: Determine Interface Layers: Decide which layers the interfaces will use. Minimize the number of layer changes for high-speed signals, as vias can degrade signal quality at high frequencies.
Step 4: Begin Routing and Assign Pins: Start routing from various devices to the FPGA, focusing on the most important connections first. As you route, see if any pins need to be remapped. It’s easier to reassign pins than to add vias to resolve crossovers. If you’ve grouped your pins correctly, the FPGA can remap them as needed.
Step 5: Test Compile: After mapping your pins and routing traces, do a test compile of your FPGA design. This ensures that your pin assignments are valid and that you haven’t accidentally used a dedicated pin for an unintended purpose. A test compile will verify that your pin mapping is compatible with the FPGA, preventing issues after the board is fabricated.
By following these steps, you can effectively manage pin assignments and ensure a functional PCB design.
2 Likes