FPGA_PHYSICAL vs FPGA_LOGICAL Part Builder Flows
Before the CadEnhance PartBuilder tool was created, the creation of complex multi-section FPGA symbols was quite a chore, and usually fell to a collaboration between the Board Engineer and the Part Librarian. Since resources dedicated to Schematic symbol creation were limited, one set of Library Symbols was usually built for an FPGA device, where the pins were drawn using the dedicated FPGA pin names, and they were usually broken up into seperate IO banks or pairs of IO Banks. It was then left to the design engineer to use the compiled pin report for the FPGA design as a checklist to hook up the proper signals to the proper pin. This is what CadEnhance refers to as the FPGA_PHYSICAL flow since the FPGA is drawn as a representation of its physical layout.
CadEnhance PartBuilder enables the FPGA_PHYSICAL flow by extracting the pin information from the FPGA package file and describing the layout of the physical symbols with advanced looping and pattern matching constructs in the symbolOrder file as described in BuildingHighPinCountDevices
FPGA Generic IO Banks Drawn with FPGA_PHYSICAL Flow
For example, lets say a company has the Xilinx Spartan-6 Device XC6SLX16-2FTG256 which is a 256 PIN BGA with 186 User I/O in their preferrred partlist. In one application the device might be used as a FLASH controller with an interface to a PowerPC-Host, while in another application the same device might be used as a DDR3 memory controller with another FPGA as the host.
While the part is physically exactly the same, the pin usage and connections for the 2 parts are completely different. If there is only one schematic representation of the part, it is up to the design engineer to make the proper connections between the FPGA and the other entities (memories, other FPGAs and microcontrollers) it is connecting to. This requires the engineer to interactively connect wires with the proper names to the proper pins of the device, which can become a very tedious manual process. When you look at the newer FPGAs on the market today with over 2000 pins, the problem grows even more daunting.
Now lets say the FPGA design engineer tells the Board design engineer (if they are different people) that the planned pinout was rejected by the FPGA compile tool or that some changes had to be made to move one pin to a special clock pin, which caused all the other pins in an IO bank to move. The Board design engineer now has to go back and manually move all the signals around in the schematic to correct the pinout.
CadEnhance FPGA_LOGICAL Flow
Enter the CadEnhance FPGA_LOGICAL Flow where a set of symbols is created for each design application using the same physical FPGA. Now the designers use PartBuilder to create a set of schematic symbols for the FLASH Controller FPGA and a completely different set of symbols drawn for the DDR3 MEMORY Controller FPGA.
Because PartBuilder is doing the difficult job of reading the pin information, the design engineer or librarian now just have to decide what pins they want to show on what symbols. They do that with the symbolOrder File. The Pin information is read directly by PartBuilder from the compilation report for each design. The symbolOrder file controls the display and location of the logical pin names on each symbol.
Now the symbols can be broken apart into much more meaningful blocks. For the FLASH controller FPGA, there would be a symbol all the pins related to the PowerPC host in the first design, and another one with all the FLASH interface pins. In the DDR3 Controller case, there might be one or 2 symbols to define the DDR3 Memory interface, and one symbol for the connection to the other FPGA.
The 2 sets of symbols would share the same layout for the Core Power, Ground, I/O Power and Configuration Blocks, so large portions of the symbolOrder file can be directly cut and pasted from the first design into the second design.
FPGA DDR3 Controller and connections drawn using FPGA_LOGICAL Flow
When the designer goes to connect the pins in the FPGA_LOGICAL flow, the actual pin names on the symbol guide the connections and they are no longer checking the compilation report to see what wire connects where. If the DalTools PinWire tool is used in Allegro DE-HDL, the wires can be automatically named by the pin_names that are found on the symbol, reducing the likely hood of improper connnections even further.
Furthermore, if the FPGA pinout needs to be tweaked, or even completely overhauled, PartBuilder can be run with the same symbolOrder file and the newly compiled pin report, and then the symbols in the schematic just need to be refreshed. The pins will magically move to the proper locations.
With that in mind, PartBuilder can also add pin-swapping controls into the generated symbols, which gives Allegro PCB the ability to swap pins (within enabled groups) on the fly. This can be used to reduce routing congestion and maximize the efficiency of the existing routing layers (and even allow a design to be completed in fewer routing layers). With the FPGA Pins add on tool the swaps can be read back from allegro, fed back to the FPGA design tool and to the symbols at the same time providing an error free means to optimize the FPGA pinout.
CadEnhance is excited to report the development of a new technology that works within the Allegro toolset called “virtual swap gates” which allows the designer to swap whole functions between banks of an FPGA on the fly. The new technology will be enabled with the release of the CadEnhance Packager Assistant tool.
Given a choice between the 2 flows, and taking into account the advantages described above, CadEnhance would always recommend using the FPGA_LOGICAL flow. That said, PartBuilder completely supports the FPGA_PHYSICAL flow, and provides great accuracy and efficiency boosts in creating the symbol set.