← Back to team overview

kicad-developers team mailing list archive

Re: Proposed roadmap changes

 

> On Mar 7, 2018, at 9:22 PM, Ouabache Designworks <z3qmtr45@xxxxxxxxx> wrote:
> 
> 
> If you are doing a PCB with a FPGA on it then you really want that FPGA designer to be using kicad to design their padring. Kicad could fill this niche and it would make your job a lot easier.

If only it was that simple. FPGA (and to some extent, microcontroller) pin swapping during layout is a holy grail. The problem is that it’s not as simple as it seems. The layout person cannot arbitrarily assign pinouts without understanding the specific chip I/O architecture and rules and also understanding the FPGA design. Our layout guy is literally on the other side of a low wall from me, and I hear his cursing about pin selection all the time!

Some examples of why this is not so straightforward.

a) The obvious one is clock inputs. They have to be on specific pins if one wants the best routing from the pin to the internal clock buffer, and if one wants to take advantage of advanced clocking features (DLLs, PLLs, input delays).

b) FPGAs have rules about differential pairs. Pins on specific banks are differential inputs or outputs only, pins on other banks can be both. Some have internal termination on certain pairs, others don’t. Bank I/O voltage is important, so you can’t move the pair to another bank with a different supply.

c) Mind the bank supplies for your signals. You can’t put a 3.3 V signal on a 2.5 V bank. The schematic and layout tools don’t have a “net type” attribute that says, “This is an LVCMOS33 signal” which would bark at you if you tried to connect it to a pin that had an LVCMOS25 type attribute. It would be great if such a feature existed. 

d) Regional clock inputs require that all of the things that might use that clock be constrained to be in the clock region — and the region and the I/O bank don’t necessarily map to each other. And the layout person might not realize that a pin even needs to be in a specific region. And how would he know that a specific pin is in the right region?

e) Lattice MachXO2 (to use a recent example) has limitations on the total output current for pins on a bank. It’s not straightforward. The good news is that their fitter tool complains if the bank is overloaded. The less good news is that there’s no obvious way to communicate that information to the layout. Schematic and layout don’t know about pin loading, for example. While pin loading could be (and in some high-end schematic tools, is) part of the DRC, this particular Lattice constraint would need to have some code that does the test.

f) Specialist features such as gigabit serializers and deserializers, memory interfaces, and the like, simply cannot be swapped.

An obvious house rule is one we have at the day job: before a PCB is released, the FPGA tools are run on the design to ensure that you don’t get timing screw-ups and you don’t have illegal pin locations. The problem, of course, is that you need to have enough of the FPGA design done before you can do that, and there’s always someone with a schedule demanding that the board be sent out for fab before you’ve even started simulating your design.

So if we’re talking pie-in-the-sky wish-list: Kicad should have a plug-in that can read and parse FPGA constraint files and “know” the FPGA symbol pin names and attributes. And after the swapping, which will automatically update the schematic, and which has ERC of some sort enforced, Kicad will update the constraint file with the new pin assignments.

-a

Follow ups

References