For all high-speed signals, the printed circuit board (PCB) layout must ensure that connections are made using short PCB traces. Refer to the manufacturer's PCB design recommendations for additional information.
The aQFN94 package has 94 pins in addition to four corner pads and a die pad.
Recommended usage | ||||
---|---|---|---|---|
A5 | VBUS | Power | 5 V input for USB 3.3 V regulator | |
A13 | DECA | Power | Analog regulator supply decoupling | |
A15 | DECD | Power | Digital regulator supply decoupling | |
A17 | P1.13 | Digital I/O | General purpose I/O | |
A19 | VDD | Power | Power supply | |
A21 | DCC | Power | DC/DC converter output | |
A23 | DECN | Power | Regulator supply decoupling | |
A25 | N.C. | |||
A27 | DECR | Power | Regulator supply decoupling | |
B2 | D+ | USB | USB D+ | |
B4 | D- | USB | USB D- | |
B6 | DECUSB | Power | USB 3.3 V regulator supply decoupling | |
B8 | VDD | Power | Power supply | |
B10 | DCCD | Power | DC/DC converter output | |
B12 | N.C. | |||
B14 | P1.15 | Digital I/O | General purpose I/O | |
B16 | P1.14 | Digital I/O | General purpose I/O | |
B18 | P1.12 | Digital I/O | General purpose I/O | |
B20 | P1.11 | Digital I/O | General purpose I/O | |
B22 | P0.31 | Digital I/O | General purpose I/O | |
B24 | P0.30 | Digital I/O | General purpose I/O | |
B26 | N.C. | |||
B28 | VDD | Power | Power supply | |
B30 | XC2 | Analog input | Connection for 32 MHz crystal | |
C1 | VDD | Power | Power supply | |
C31 | XC1 | Analog input | Connection for 32 MHz crystal | |
D2 | N.C. | |||
E1 | VDDH | Power | Power supply | |
E31 | VDD | Power | Power supply | |
F2 | N.C. | |||
G1 | N.C. | |||
G31 | DECRF | Power | RADIO power supply decoupling | |
H2 | N.C. | |||
J1 | DCCH | Power | DC/DC converter output | |
J31 | N.C. | |||
K2 | N.C. | |||
L1 | VDD | Power | Power supply | |
L31 | ANT | RF | Single-ended antenna connection | |
M2 | P1.00 | Digital I/O | General purpose I/O | |
N1 | P0.00 | Digital I/O | General purpose I/O | |
N31 | VDD | Power | Power supply | |
P2 | P1.01 | Digital I/O | General purpose I/O | |
R1 | P0.01 | Digital I/O | General purpose I/O | |
R31 | P1.10 | Digital I/O | General purpose I/O | |
T2 | N.C. | |||
U1 | VDD | Power | Power supply | |
U31 | P0.29 | Digital I/O | General purpose I/O | |
V2 | P0.04 | Digital I/O | General purpose I/O | |
W1 | P0.02 | Digital I/O | General purpose I/O | |
W31 | SWDCLK | Debug | Serial wire debug clock input for debug and programming | |
Y2 | P0.05 | Digital I/O | General purpose I/O | |
AA1 | P0.03 | Digital I/O | General purpose I/O | |
AA31 | SWDIO | Debug | Serial wire debug I/O for debug and programming | |
AB2 | P0.06 | Digital I/O | General purpose I/O | |
AC1 | VDD | Power | Power supply | |
AC31 | nRESET | Reset | Pin RESET with internal pull-up resistor | |
AD2 | P0.07 | Digital I/O | General purpose I/O | |
AE1 | P1.02 | Digital I/O | General purpose I/O | TWI |
AE31 | P0.28 | Digital I/O | General purpose I/O | |
AF2 | P1.03 | Digital I/O | General purpose I/O | TWI |
AG1 | VDD | Power | Power supply | |
AG31 | N.C. | |||
AH2 | P0.08 | Digital I/O | General purpose I/O | Trace, SPIM4 |
AJ1 | P0.09 | Digital I/O | General purpose I/O | Trace, SPIM4 |
AJ31 | VDD | Power | Power supply | |
AK2 | P0.10 | Digital I/O | General purpose I/O | Trace, SPIM4 |
AK4 | P0.11 | Digital I/O | General purpose I/O | Trace, SPIM4 |
AK6 | P0.12 | Digital I/O | General purpose I/O | Trace, SPIM4 |
AK8 | P0.14 | Digital I/O | General purpose I/O | QSPI |
AK10 | P0.15 | Digital I/O | General purpose I/O | QSPI |
AK12 | P0.17 | Digital I/O | General purpose I/O | QSPI |
AK14 | P0.18 | Digital I/O | General purpose I/O | QSPI |
AK16 | P0.20 | Digital I/O | General purpose I/O | |
AK18 | P0.22 | Digital I/O | General purpose I/O | |
AK20 | P0.23 | Digital I/O | General purpose I/O | |
AK22 | P1.05 | Digital I/O | General purpose I/O | |
AK24 | P1.07 | Digital I/O | General purpose I/O | |
AK26 | P1.09 | Digital I/O | General purpose I/O | |
AK28 | P0.25 | Digital I/O | General purpose I/O | |
AK30 | P0.27 | Digital I/O | General purpose I/O | |
AL3 | VDD | Power | Power supply | |
AL5 | P0.13 | Digital I/O | General purpose I/O | QSPI |
AL7 | VDD | Power | Power supply | |
AL9 | P0.16 | Digital I/O | General purpose I/O | QSPI |
AL11 | VDD | Power | Power supply | |
AL13 | P0.19 | Digital I/O | General purpose I/O | |
AL15 | P0.21 | Digital I/O | General purpose I/O | |
AL17 | VDD | Power | Power supply | |
AL19 | P1.04 | Digital I/O | General purpose I/O | |
AL21 | P1.06 | Digital I/O | General purpose I/O | |
AL23 | P1.08 | Digital I/O | General purpose I/O | |
AL25 | VDD | Power | Power supply | |
AL27 | P0.24 | Digital I/O | General purpose I/O | |
AL29 | P0.26 | Digital I/O | General purpose I/O | |
A1 | N.C. | |||
A31 | N.C. | |||
AL1 | N.C. | |||
AL31 | N.C. | |||
Die pad | VSS | Power | Ground pad. Exposed die pad must be connected to ground (VSS) for proper device operation. |
A1 | XC1 | Analog input | Connection for 32 MHz crystal | |
A2 | XC2 | Analog input | Connection for 32 MHz crystal | |
A3 | VDD | Power | Power supply | |
A5 | VSS | Power | Ground | |
A7 | DECD | Power | Regulator supply decoupling | |
A9 | DCCD | Power | DC/DC converter output | |
A11 | D- | USB | USB D- | |
A12 | D+ | USB | USB D+ | |
B1 | DECRF | Power | RADIO power supply decoupling | |
B2 | VSS | Power | Ground | |
B4 | DECR | Power | Regulator supply decoupling | |
B5 | DECN | Power | Regulator supply decoupling | |
B6 | DCC | Power | DC/DC converter output | |
B7 | VDD | Power | Power supply | |
B8 | DECA | Power | Regulator supply decoupling | |
B9 | VSS | Power | Ground | |
B10 | VDD | Power | Power supply | |
B11 | VBUS | Power | Power | |
B12 | VDDH | Power | Power supply | |
C2 | VSS | Power | Ground | |
C4 | P0.30 | Digital I/O | General purpose I/O | |
C5 | P0.31 | Digital I/O | General purpose I/O | |
C6 | P1.11 | Digital I/O | General purpose I/O | |
C7 | P1.12 | Digital I/O | General purpose I/O | |
C8 | P1.13 | Digital I/O | General purpose I/O | |
C9 | P1.14 | Digital I/O | General purpose I/O | |
C10 | P1.15 | Digital I/O | General purpose I/O | |
C11 | DECUSB | Power | USB 3.3 V regulator supply decoupling | |
D1 | ANT | RF | Single-ended antenna connection | |
D2 | VDD | Power | Power supply | |
D10 | P1.00 | Digital I/O | General purpose I/O | |
D11 | DCCH | Power | DC/DC converter output | |
D12 | VSS | Power | Ground | |
E2 | P0.29 | Digital I/O | General purpose I/O | |
E3 | P0.28 | Digital I/O | General purpose I/O | |
E4 | P1.10 | Digital I/O | General purpose I/O | |
E5 | VSS | Power | Ground | |
E6 | VSS | Power | Ground | |
E7 | VSS | Power | Ground | |
E8 | VSS | Power | Ground | |
E10 | P1.01 | Digital I/O | General purpose I/O | |
E11 | VDD | Power | Power supply | |
F1 | SWDIO | Debug | Serial wire debug I/O for debug and programming | |
F2 | SWDCLK | Debug | Serial wire debug clock input for debug and programming | |
F3 | P1.08 | Digital I/O | General purpose I/O | |
F5 | VSS | Power | Ground | |
F6 | VSS | Power | Ground | |
F7 | VSS | Power | Ground | |
F8 | VSS | Power | Ground | |
F10 | P0.05 | Digital I/O | General purpose I/O | |
F11 | P0.00 | Digital I/O | General purpose I/O | |
F12 | P0.01 | Digital I/O | General purpose I/O | |
G2 | nRESET | Reset | Pin RESET with internal pull-up resistor | |
G3 | P1.07 | Digital I/O | General purpose I/O | |
G5 | AVSS | Power | Ground | |
G6 | VSS | Power | Ground | |
G7 | VSS | Power | Ground | |
G8 | VSS | Power | Ground | |
G10 | P0.04 | Digital I/O | General purpose I/O | |
G11 | P0.02 | Digital I/O | General purpose I/O | |
H1 | P0.27 | Digital I/O | General purpose I/O | |
H2 | P1.09 | Digital I/O | General purpose I/O | |
H3 | P0.23 | Digital I/O | General purpose I/O | |
H10 | P0.06 | Digital I/O | General purpose I/O | |
H11 | VDD | Power | Power supply | |
H12 | P0.03 | Digital I/O | General purpose I/O | |
J2 | P0.26 | Digital I/O | General purpose I/O | |
J3 | P1.06 | Digital I/O | General purpose I/O | |
J4 | P0.21 | Digital I/O | General purpose I/O | |
J5 | P0.19 | Digital I/O | General purpose I/O | |
J6 | P0.12 | Digital I/O | General purpose I/O | |
J7 | P0.11 | Digital I/O | General purpose I/O | Trace, SPIM4 |
J8 | P0.10 | Digital I/O | General purpose I/O | Trace, SPIM4 |
J9 | P0.09 | Digital I/O | General purpose I/O | Trace, SPIM4 |
J10 | P0.07 | Digital I/O | General purpose I/O | |
J11 | P1.02 | Digital I/O | General purpose I/O | TWI |
K1 | VDD | Power | Power supply | |
K2 | P0.24 | Digital I/O | General purpose I/O | |
K3 | P1.04 | Digital I/O | General purpose I/O | |
K4 | P0.22 | Digital I/O | General purpose I/O | |
K5 | P0.20 | Digital I/O | General purpose I/O | |
K6 | AVSS | Power | Ground | |
K7 | P0.18 | Digital I/O | General purpose I/O | QSPI |
K8 | P0.16 | Digital I/O | General purpose I/O | QSPI |
K9 | P0.14 | Digital I/O | General purpose I/O | QSPI |
K10 | P0.13 | Digital I/O | General purpose I/O | QSPI |
K11 | AVSS | Power | Ground | |
K12 | P1.03 | Digital I/O | General purpose I/O | TWI |
L1 | P0.25 | Digital I/O | General purpose I/O | |
L3 | P1.05 | Digital I/O | General purpose I/O | |
L5 | VDD | Power | Power supply | |
L7 | P0.17 | Digital I/O | General purpose I/O | QSPI |
L9 | P0.15 | Digital I/O | General purpose I/O | QSPI |
L11 | VDD | Power | Power supply | |
L12 | P0.08 | Digital I/O | General purpose I/O | Trace, SPIM4 |
Component placement ignored (bad layout)
Component placement considered (good layout)
DDR3 and QDR II SRAM, FPGA tool-derived pin assignments
One board in a large ASIC prototyping system
Using FPGA knowledge to guide the PCB pin-swapping process
Predicting that IC density and complexity will continue to increase is kind of like predicting that the sun will come up in the morning-you'd literally have to be living under a rock to not be aware of this. And so it is with FPGAs, which are getting more, not less, complex; whose pin counts are going up, not down; and for which the available silicon seems to grow faster than many engineers can figure out how to use it. The only thing that steadfastly refuses to change is design schedules, which bewilderingly remain as constant as the sun.
Integrating these ever-more complicated devices into their host PCBs has proven to be extraordinarily challenging. FPGA designers, schematic engineers, and PCB designers find themselves locked in a divergent battle, struggling to create device pin assignments that satisfy both the FPGA and the PCB. Traditional tools almost encourage each specialist to "throw the design over the wall." As the design progresses, this tool-mandated "not my job" mentality dooms the team to wasting precious time, often late in the project, iterating between the FPGA and PCB design, searching in vain for common ground in pin assignments.
Regrettably, it's the PCB that usually suffers, with more layers and vias being added to accommodate the FPGA. To make matters worse, this typically manual round-trip process introduces errors that may not be exposed until the first prototype is powered up in the lab.
Take an average FPGA-based PCB design containing two or three FPGAs. Most processes let the FPGA designer have all of the pin assignment fun (as in ,"It's fun to hit my thumb with a hammer"), using the FPGA tools, scripts, text files, spreadsheets, home-grown utilities, and whatever other tricks are at his/her disposal. Those pin assignments are then passed to the schematic engineer who gets the fun (see above for the definition of "fun") of creating symbols and wiring up the schematic using precisely the same pins as the FPGA designer, including all of the power pins that can number in the hundreds. Not to mention the lingering fear lurking in the back of his/her mind that if anything is misconnected, the system won't work. Or even worse, on first power up the prototype will do nothing more than radiate lots of heat until it melts into a useless pile of expensive FPGAs and fiberglass.
And this doesn't even begin to address the PCB designer, that poor soul at the bottom of the design food chain who just happens to have had all of his/her allotted time chewed up by everyone else, who has little say in the design process, and whois told to "fix it but don't change anything" on a board where the PCB routing was never considered for a fleeting µ-second!
That this situation sets the stage for a lot of hand wringing, late nights, finger pointing, heated battles, and endless loops through the flow-usually at the end of the design cycle, when it can least be afforded-is only too predictable. Oh, and don't forget that all FPGA pin assignment changes have to propagate through the entire flow, every time, with flawless accuracy.
This, with a little embellishment, is what happens with manyaverage FPGA-based boards. Just imagine ASIC prototyping designs, which can contain dozens of FPGAs. The problems listed above become practically unmanageable, and it is a testament to the engineers'-and PCB designers'-skill that any of these prototyping systems are ever made to work correctly in a time frame that ensures the ASIC is taped out before the market renders it obsolete.
Take the following two screenshots ( Fig. 1 and Fig. 2 ), which are admittedly an exaggeration but nevertheless highlight what can happen while picking pins if component placement is either ignored (bad) or considered (good):
Assuming both designs satisfy the needs of the FPGA (the large device in the middle), which one would most likely inspire the PCB designer to request an unpleasant chit-chat with engineering? True, only the rat's nests are represented here. But their implication is clear: the tangled mass of connections scattered across the FPGA in Figure 1 are destined to cause a routing nightmare. To understand the roots of this issue, you need to look no further than the techniques that are generally deployed, and the data that is normally acknowledged, during the FPGA pin assignment process.
Regardless of how FPGA I/O pins are selected (automatically, manually, or a combination of the two), if the pin assignments have any hope of working well for the entire system, three factors must be considered-and these must be considered by the designer and any tools used in the process:
An additional factor that is often disregarded but that needs to be addressed is the link between the FPGA and the schematics. Getting the FPGA connectivity captured in the schematic wouldn't be too painful if it were done only once. But that never happens. In fact, the connectivity changes constantly and radiates from two main sources: the FPGA designer, optimizing the pin outs for performance reasons, and the PCB designer, trying to reduce layer counts or routing time. As far as the hardware engineer is concerned, the source of the change is irrelevant-the FPGA connectivity still has to be updated accurately and reflected in the schematics.
Since the classic FPGA vendor tools already deal with the first two constraints mentioned above, it's the third one that any new tools or techniques need to focus on if the goal really is system-optimized pin assignments that work well for the FPGA and the board.
Before jumping to the conclusion that the easy answer is just to force FPGA designers to think outside the FPGA box, look at the problem from their perspective. Tasked with writing, simulating, and synthesizing the RTL; deliberating over the timing (both inside and outside the FPGA); selecting the proper I/O standards; assessing routing and clocking resources; sizing the I/O buffers;floorplanning the device; and, generating the programming files, FPGA designers have their own set of headaches to contend with. Throwing PCB routing into the mix does not help.
And for some sections of the design, FPGA designers may not have much say in the matter-for the FPGA to work, they could be forced (or at least implored) to use pin assignments derived algorithmically by the FPGA tools. These tools can assist the designer in interfacing the FPGA to DDR3s, QDR II+ SRAMs, RLDRAMs, etc. (Fig. 3) , and in producing soft IP cores. Testing an FPGA designer's patience then entails nothing more than proposing modifications to these hard- fought, "golden" pin assignments.
There are a multitude of other pin allocation decisions that can elicit thoughts of "What are they thinking?!" from those not intimately familiar with the FPGA's requirements, but that make perfect sense to FPGA designers. Some devices, for example, contain hard cores carefully constructed to communicate with specific types of external logic such as DSPs or Ethernet PHYs, and the silicon that implements that logic prefers certain I/O pins. So when FPGA designers rigidly insist that pin assignments are fixed, many times they're absolutely right.
So what happens when all of this makes its way to the board? This is where the pin assignment rubber meets the PCB routing road. It's at this point that the team is given its first real glimpse of how early design-cycle choices will actually affect the physical system. Signal integrity, mechanical and thermal qualities, manufacturing cost, packaging, reliability, power delivery and consumption-all the things whose effects and tradeoffs have been carefully evaluated throughout the design process-now begin to come together and their interactions play out.
High-speed components like DDR3 have not only stringent FPGA integration requirements but rigorous PCB requirements as well: distances between parts, maximum allowed signal length, number of layers and vias, crosstalk, etc. For each of the 240 nets on every DDR3 (and of course for every part), the PCB designer has to group the nets into bundles, merge those bundles onto their appropriate layers, and then flowplan and route them around any impeding obstructions-all with an eye toward meeting multiple, often conflicting, design objectives. Poorly chosen FPGA pin locations can turn this process into a veritable nightmare, resulting in round after round of impassioned team-wide negotiations that inevitably push the project's timeline right to its unforgiving edge. Worse, it can add layers to the PCB, which drives up the end product costs.
Any tools that claim to improve this situation have to be conversant in multiple design-space languages. They also have to be able to integrate, or at least easily communicate, with a range of other products, databases, and file formats. And as much as engineers enjoy deriding the EDA industry, EDA companies have developed new tools and flows to help design teams cope with integrating FPGAs onto PCBs.
Each of these products approach the problem in unique ways, but the bottom line is that all of them exploit component placement as a constraint in establishing FPGA pin assignments that complement the entire design, not just the FPGA. And all of them have been used effectively by engineers across the globe to reduce design cycles and increase product quality. However, first-generation tools have some limitations. They may require that PCB placement be done first, which implies that un-optimized (manual) pin assignment is also done first. Or, FPGA pin assignment rules may be missing in the PCB layout space, so that pin assignment is done manually.
A more advanced approach would assemble the FPGA rules, signaling, and part placement data (the 3 constraints listed above) into one location and then, through a "connectivity intent definition" mechanism, utilize I/O synthesis technology to automatically select the best FPGA pins across the entire design. Because the tool asks the designer to supply the connectivity intent instead of the actual pin assignments, the designer enjoys the luxury of knowing that no matter where the components are placed or oriented, the actual connectivity can be re-established by simply re-running synthesis. (Moving or rotating components implies a change only to the actual connectivity, not the connectivity intent.)
Cadence Allegro FPGA System Planner takes just such a "connectivity intent" approach. One customer was able to take full advantage of this capability when, at the last minute, it was discovered that an FPGA had to be flipped to the opposite side of the board. Using the "connectivity intent with synthesis" functionality, days of re-work was trimmed to a few hours. Another customerproduced a 48-FPGA ASIC prototyping system in half the time of their previous 15-FPGA single-board system (Fig. 4) .
However, as with any product, FPGA pin planning tools are not a panacea. They will not, nor are they intended to, replace the FPGA vendor's tools. They can use, and ideally improve, pin assignments selected by the vendor tools-but in some designs, or for a host of other reasons, engineers may want to use existing FPGAtool-defined I/O locations. Again, because the FPGA tools cannot spell "PCB," these pin assignments are often not optimal, at least for the board.
In these circumstances the EDA tools, just like a machete or a screwdriver or a chainsaw, have to be used as they were intended to be, in the right place and at the right time in the design process. As such, any sufficiently advanced FPGA-PCB planning tool must be able to optimize, or guide the engineer in optimizing, FPGAtool-defined pin locations within an FPGA-constrained boundary, using algorithms that understand and adhere to the original, vendor-driven pin assignment rules.
There are other restrictions that these tools suffer from as well: they all view the PCB as a two-dimensional object and the routing as a point-to-point Manhattan connection, neither of which is true. (How drastically these assumptions affect I/O assignment quality is directly related to the PCB topology.) But perceiving the PCB to be two dimensional is certainly a lot better than not perceiving the PCB at all. Worse, some of these products, in some cases, view the FPGA as a fixed-pin device, which spawns a rash of problems downstream when swapping pins in the PCB.
An FPGA is a programmable device. By their very design, an FPGA's pins are dynamic-how one is used immediately and directly affects the others. This cannot be determined or orchestrated through a simple mechanism like a static swap matrix, which has none of this intelligence.Created too coarsely, a swap matrix will allow PCB designers to screw up the FPGA drastically. Too fine and they will be hamstrung, unable to swap anything of any significance.
One way to get beyond this would be to instill FPGA expertise into the PCB tool, perhaps through an underlying "engine," to lead the PCB designer in the right direction by suggesting FPGA-compliant pin swap candidates. Bringing FPGA awareness to the PCB designer's desktop would help ensure that they are continually steered toward a more predictable (and routable) solution (Fig. 5) . So it's not a single tool, but how well the tool flow understands FPGA-based designs that ultimately determines the team's fate and their ability to realize the completed system.
With better FPGA design-in tools that communicate in several languages (FPGA, schematic, and PCB), FPGA design-in can be a faster, less frustrating endeavor. But to properly solve the problems touched on in this article, these tools are going to have to take responsibility for their long-standing inability to adequately endorse the PCB-up front. Tools (and processes) that do not will continue to subject the entire team to a series of time-consuming, exasperating iterations, forcing the team to choose between the lesser of two evils: slip the schedule to allow for more iterations, or increase PCB layer counts (and potentially decrease system performance) to account for inferior FPGA pin assignments.
Sponsored recommendations, to join the conversation, and become an exclusive member of electronic design, create an account today.
Success! Subscription added.
Success! Subscription removed.
Sorry, you must verify to complete this action. Please click the verification link in your email. You may re-send via your profile .
Link Copied
Community support is provided Monday to Friday. Other contact methods are available here .
Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
For more complete information about compiler optimizations, see our Optimization Notice .
I have notice a (probably) new feature: alternate pin assignment. I have created a new device and noticed that there is an “alternate pin assignments” tab when I open the symbol properties. Then I thought I have to add the alternate pin definitions when creating the symbol. Back to the symbol editor, I noticed that it’s possible for every pin to add alternate defintions, and I tried to do it. Example: Pin 1 was defined as P6.4 / A4. Port IO or analog input. So I left P6.4 as default and added A4 for alternate. Saved, updated in the schematic editor. Now when I open the symbol properdies, I was expecting to see P6.2 on the base name column, and A4 as an alternate, but it didn’t change. Here are a few questions:
Thanks for any hint!
I haven’t investigated this feature but could you be misinterpreting the purpose? Could it be for representing devices that come in say 40 pin DIP and 44 pin TQFP?
@retiredfeline It is just to assign alternate pin texts. Comes in handy for e.g. MCUs, where a pin can be GPIO/UART/SPI/Analog5, you get it. You can choose which pin name you want displayed. [EDIT] Electrical type and graphical style change as well
There will be a dropdown list with the alternates available. Initially, you see an empty field. Only after clicking it does the dropdown list appear.
It’s there since 6.0 .
Thanks, that’s exactly what I expected. Instead of displaying up to 5 ~ 6 different options, it would be a lot better to display tje pin I’m actually using, for instance only UART_TX as in your example. And I would also like to add an NC option.
Anyway I must be missing something. I configured it my lib and it doesn’t reflect in the schematic even if I update the lib.
Now in the schematic I had started, if I update the library, I can be sure that it has actually been upgraded since the corner pin 1 is now P6.4, and the A4 has disappeared.
Now my problem is: how can I do in the schematic to show the alternate pin name, A4 only?
Thanks for any hint.
Update: I found the trick!
Oopsy Daisy, I never realized that…
You are mis-using or mis interpreting the feature. It’s not used for all schematic symbols. KiCad’s libraries are a bit behind. The intention is that all sensible pin names are pre-defined in the library, and you choose one of the names for use in your schematic. To see how it works put one of the STM32 IC’s on your schematic, and then edit it’s properties. Then you can select a name from the Alternate Pin Assignments tab page.
This seems to work quite nicely for microcontrollers and other IC’s that have a limited number of pre-defined functions per pin. It does not work for FPGA’s or PLD’s where pins can be “anything”. But I don’t see much room for improvement there, except for just improving the symbol editor itself. It’s easy enough to pop a symbol into the symbol editor and change pin texts to your liking. And having a pre-defined symbol already defines the power pins, maybe clock and other dedicated pins and just leaves the I/O pins to change for you.
For me it seems finally a problem for the database approach. Pin names (and pin numbers) should be possible to override either from database or manually by schematic entry. Swapping rules should be either connected to in number or pin name or any new identifier therefore.
I don’t think so. By the way, my post above was maybe a bit confusing with the latest picture showing a chip with only pin 1 using this feature. I’m in the process of changing them all, but it takes time. With, say, 3 different configs for each pin in an average, it means 300 editions for this QFP100. Beside this, since it’s now able to define not only the alternate pin name, but also its nature (input / output / bidirectional, etc…), I think Kicad is now able to detect errors that could not be detected earlier. I’m aware of how STM32 cube works, and I remember having asked for this feature, maybe a couple of years ago. Anyway, to summarize, it’s perfect, and the only possible improvement would add a text when no alternate name is selected, as mentioned above. Like “select alternate name”. And while we are at it, it’s not realy a matter of name, but also functionality, so “select alt pin function” could be even better.
Back after some time. I’m trying to use what I did earlier, and in fact I’m not sure that this new functionality is an advantage. The problem is that now I have a symbol with a single label (I mean the functionality, like P6.5). This means that if I want to use for instance the A5 functionality (analog 5. which is on the same pin as P6.5), then I have to know where it is. This one is simple, Port6 is analog for all the MSP430s. So P6.x van also be remap tp A6. Now what should I do if I don’ t know for instance the location of UART2? Opening a pdf is certainly a solution, but It would be good if I could search from the schematic editor. For instance, right click on the component, have a “find” menu in which I would key in “UART2”
Is there an existing method? The alternate pin panel is apparently not searchable. At least not with the standard cmd-F.
Thanks for your reply. Yes, that’s what I ended up doing. I have also added a NC option for all the pins so that the schematic better retlects what I do.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
IMAGES
VIDEO
COMMENTS
1. Use the Intel® Quartus® Prime Pin Planner to make pin assignments. 2. Use Intel® Quartus® Prime Fitter messages and reports for sign-off of pin assignments. 3. Verify that the Intel® Quartus® Prime pin assignments match those in the schematic and board layout tools. With the Intel® Quartus® Prime Pin Planner GUI, you can identify I/O ...
Checklist Item. 1. Use the Intel® Quartus® Prime Pin Planner to make pin assignments. 2. Use Intel® Quartus® Prime Fitter messages and reports for sign-off of pin assignments. 3. Verify that the Intel® Quartus® Prime pin assignments match those in the schematic and board layout tools. 4.
There are two ways of specifying PIN assignment — you can either use PinPlanner or set_location_assignment to specify the PIN along with set_instance_assignment to specify the IO standard.. I recommend you read I/O Management documentation from Altera. But here are few examples: These are location assignments for 1 GbE RGMII Ethernet Interface:
make pin assignments. To assign th e device, perform the following steps. 1. Choose Assignments > Device. 2. Under Family, choose the device family that corresponds to the device on the development board you are using. 3. Under Available devices, choose the device given in Table 1-1 . Table 1-1. Available Device Settings
Figure 1 - Typical DDR3 pin assignments received by a PCB designer. The result is that system design processes continue to suffer from a lack of the right knowledge at the right point in the process. For example, consider a simple, two component design -- two FPGAs connected through a 32-bit data bus. Suppose that the FPGA designer has used the ...
Learn how to use the Pin Planner tool to create and manage pin assignments for your FPGA design. This document provides a step-by-step guide on how to use the Pin Planner features, such as importing and exporting pin assignments, viewing pin information, and creating pin groups. You can also find tips and tricks on how to optimize your pin assignments for performance and routing.
FPGA pins can be assigned by importing a pin assignment file from the web page. DE10_Lite.qsf. download the file from the website and save it to a central location so that you can easily import it each time you create a new project. select save as, change the file types to all files, and make sure the file name extension is .qsf and not .txt.
You can (optionally) customize the pin assignments that were imported by going to the "Assignments" menu and selecting "Assignment Editor". Additional information on the GPIO headers can be found in the DE0-Nano PDF manual (pages 18-20). A mapping of FPGA pins to GPIO headers can also be found in the de0-nano/DE0_Nano.qsf file (open it with a text editor).
The pin assignment process for multi-FPGA systems assigns all signals to traces, and logic pins to IOBs. Specifically, each signal S , which is connected to partitions P1 …. Pn , must be assigned to exactly one trace T . This trace must be connected to chips C ={ C1 …. Cm } such that each partition P ∈{P1 ….
Yes, the tool will utilize the internal IP constraints (which are demo board specific) and assign them to its pins. Naturally the part selected for the project should be the correct demonstration board. You can verify the pin assignments by opening up the implementation and reviewing the I/O assignments and compare them to the constraint files.
You'll learn to compile Verilog code, make pin assignments, create timing constraints, and then program the FPGA to blink one of the eight green user LEDs on the board. You'll use a 50 MHz clock input (from the on-board oscillator) to drive a counter, and assign an LED to one of the counter output bits. Level: beginner. Materials Hardware
Step 5: Exporting the I/O Pinout. You can export the I/O port list and package pin information from PlanAhead software into a CSV format file, HDL header, or UCF file. The CSV file includes information about all of the package pins in the device, as well as design-specific I/O port assignments and their configurations.
To compile a design or make pin assignments, you must first create a project. 2.1 Assign The Device 1. In the Quartus II software, select File > New Project Wizard. The Introduction page opens. See Figure 2-1 Figure 2-1 New Project Wizard introduction . 9 2. Click Next. 3. Enter the following information about your project:
Pin assignments. This section describes the pin assignment and the pin functions. This device provides flexibility when it comes to routing and configuration of the GPIO pins. However, some pins have recommendations for how the pin should be configured or what it should be used for. In addition to the information in the pinout tables for the ...
Those pin assignments are then passed to the schematic engineer who gets the fun (see above for the definition of "fun") of creating symbols and wiring up the schematic using precisely the same ...
Checklist Item. 1. Use the Intel® Quartus® Prime Pin Planner to make pin assignments. 2. Use Intel® Quartus® Prime Fitter messages and reports for sign-off of pin assignments. 3. Verify that the Intel® Quartus® Prime pin assignments match those in the schematic and board layout tools. 4.
In the scripts I create (key,value) pairs for pin assignments, and then loop over them and convert them to Altera synthesis directives. Its a little more complicated to understand the first time you read the script, however, creating the script is a lot easier for the next board. Read the scripts and ask questions. Cheers, Dave.
Pin assignments can be done even before you write your RTL code, if you know the name of the interfacing signals. Pin assignment can be done independent of the implementation logic. When you are creating a new project, you can select "Io Pin Planning project" to do the pin assignments. This will be written to an XDC file which should be used ...
Pin Assignment. 2.6.1. Pin Assignment. When you integrate your Interlaken IP instance in your design, you must make appropriate pin assignments. You do not need to specify pin assignments for simulation. However, you should make the pin assignments before you compile. Pin assignments provide direction to the Fitter and specify the signals that ...
Schematic. roboya February 21, 2023, 1:01am 1. Hello! I have notice a (probably) new feature: alternate pin assignment. I have created a new device and noticed that there is an "alternate pin assignments" tab. when I open the symbol properties. Then I thought I have to add the alternate pin definitions when creating the symbol.
From the Intel® Quartus® Prime menu, select Assignments > Pin Planner. Under the Node Name column in the All Pins box, look for the pin that you want to configure. Under the Location column, select the specific pin location. The I/O Bank column displays the I/O bank name where the pin resides. The Top View - Flip Chip diagram shows the I/O ...
The following simple procedure makes all pins in your design virtual I/O pins. First, the design is synthesized to determine which nodes are pins. Next, a collection of name IDs is set to correspond to the pins in the design, then a VIRTUAL_PIN assignment is applied to every pin. Finally, the export_assignments command writes all new ...