Once upon a time, PLD pinouts were an easy thing. Oh, yeah, sorry… for you neophytes, that’s “Programmable Logic Device,” a term once ubiquitous, and still relevant, except that FPGAs are the overwhelmingly dominant survivor. So much so that some people think of PLDs as just the small non-volatile glue-mop-up devices, to paint an ugly mixed-metaphorical picture, even though an FPGA is no less programmable a device. Back in the day, when you were writing your Boolean equations in PALASM for your PAL16L8 (OK, I know I’ve lost a generation of you now), you simply listed the mnemonics you were going to use for the pin names on all 20 pins in order. Yeah, only 20… remember SKINNYDIP packages? (You youngsters can stop blushing now; we were a wild generation, work it out with your therapists.)
Contrast that with today’s megamonolithic monster FPGAminators that have over 1000 pins. List those babies. Oh, and there’s no obvious pin order; they’re in a grid. And they may operate at various voltages. Or they may have different I/O standards. And they’re organized in banks. And each bank may be associated with a specific power level. And you can’t necessarily mix arbitrary I/O types in a bank. Oh, and depending on the I/O standard being used, you can only have so many outputs within a bank, and they have to be within a certain number of pins of a ground to avoid issues with simultaneously switching outputs (variously called SSO, ground bounce, silent low by the various generations that thought they invented the concept). (No, you young whippersnappers, I’m not having a maturity meltdown…)
Bottom line: you now have <cue scary music> design rules for your pin assignments. It’s like a bad game of Twister, and by the time you try manually to figure out where everything should go, you’re tied up in knots, practically paralyzed in an unflattering pose. Add to the problem the fact that an FPGA place-and-route tool needs flexibility and room to breathe, and one solution becomes not to assign pins at all; let the FPGA tool do it. This can make it easier to achieve a good fit and meet the various timing requirements of the design. Once you’ve done a first fit, you can lock those pins down for subsequent changes to the design. And it’s all good, right?
Oh crap! One minor detail. This thing has to go onto a board, and the pins have to be routed around. Well that’s annoying. And the FPGA tools have absolutely no respect for where the signals have to go when they assign the pins. OK, that’s because the tools have no idea what else is on the board. Some board design tools try to help with this, but they typically do their work later in the design flow, when making changes to the FPGA pinouts may be infelicitous (to put it mildly). So we’re back to having to assign pins (or at least constrain them) manually (or partially manually), working with the FPGA tools – perhaps iteratively – to get a suitable pinout. And this is really embarrassing, folks; apparently many of you have resorted to using desktop productivity tools – programs like Excel and Visio – to define pinouts, and then scripting this into the flow. Not a pretty picture.
A startup company called Taray is trying to untangle this tortured Twister tableau by inserting a new point tool called 7Ciruits at the start of the design flow, before logic is synthesized. Their idea is to have the tool work at the very beginning, generating a pinout that can then be used in parallel by both the board designer and the FPGA designer. This is a higher level of abstraction, where interfaces and busses can be defined, and which will result in low-level FPGA constraints once the process is complete.
The flow works by first assembling a layout of chips as they will appear on the board. 7Circuits comes with a library of models built-in; users can generate new models as well. FPGA pinout rules are comprehended by the models. Pin characteristics are sensitive to layout, so if, for example, a header strip is laid out horizontally, then pins will be characterized as “top” and “bottom”; if laid out vertically, they will be “left” and “right.” Taray’s GUI can be used to define signals hierarchically in that signals can be grouped into busses and interfaces. The design itself can also be generated hierarchically in that very large designs can be split into subdesigns under the aegis of a master design; likewise individual smaller designs can be merged into a large design. Multiple FPGAs can be instantiated on the board.
Once interfaces and signals on the various devices are established, the pin-assignment portion can begin. And, amazingly enough, this one-time byproduct of the FPGA fitting process now itself bears a striking resemblance to the FPGA fitting process. There are three types of constraint that must be met: logical constraints (groupings of signals with respect to banks, for example); electrical constraints (association with power levels and ground pins, for example), and physical constraints (the standard challenges of routing given a limited number of planar layers). 7Circuits deals with this by first creating all possible combinations of pinout that satisfy the logical and electrical requirements consistent with relative chip placement. Each of these possible pinouts can have multiple physical implementations, and a cost-based simulated annealing process is then used to settle on a final pinout that will satisfy all three sets of constraints. From this, FPGA pin constraints are automatically generated in a format appropriate to the FPGA vendor or tool being used.
Taray appears to have taken into account some of the realities of board and FPGA design – you can’t expect to do a pin assignment up front and have it stick for the rest of the design. Chips may change, interfaces may change – even the FPGA may change. Taray literature addresses examples of making such late-in-the-flow changes. The real test will be how the Taray-selected pinouts wash with the FPGA fitting process. While the pins can be assigned in a manner that is guaranteed to satisfy the pinout requirements for the FPGAs, it cannot take into account what the internal logic requirements for the FPGA are (just as the FPGA tool can’t take into account the board design). There is a possibility of a pinout being chosen that doesn’t mesh well with the fitting requirements of the logic. This becomes even more true for late-flow changes. Presumably experience will indicate whether or not this is an issue. And perhaps some level of iteration is possible here. Even so, Taray’s hope would be that their tool will make managing any such issues easier than using old methodologies.
As to the 7Circuits name, it’s an allusion to Seven Circles. Which most appropriately is a famous mathematical theorem (“famous” being relative in mathematical circles) but, as Google will readily show, is also a name ascribed to various mystical concepts that appear to have been adopted by a number of cultures, both in the eastern and western hemispheres, as well as the name of a rock song by one band, and the name of yet another rock band. So take your pick.
