Whoever wrote the trace length tuner , nice job . It’s nicer than the Altum tool.
How is via delay set ? does it simply use the stackup (which is fine) ?
of course depends on length traversed, IE L1 to L8 or L4 to L5.
Where are component package delays/lengths set ?
Altium has this set in the pin in the schematic symbol.
We import the length or delay by copy and paste in usually using our own scripts.
Pin information for a large chip gets imported from a CSV file so you dont have to add pins in the GUI.
I see you can do that component import with KiCad.
It uses the layer thicknesses in the board stackup setup. Obviously only the layers the signal passs through.
These are properties of the pads. (“Pad to die length” in pad properties)
In general, Kicad at the moment only calculates lengths, not time delays, so searching for “delay” won’t help you much. I think delay calculations were planned for the future.
Oh
OK, so just some reasons what setting in the pad of a footprint is not ideal.
There are always different parts that go into the same package.
These have vastly different lengths and paths back to the die pads.
Delays and lengths are COMPONENT specific so they need to go into components- IE they need ot go into schematic symbol data.
OK, I found " Working with pads" in the footprint editor.
Can we please get this moved to the schematic part- this is where users expect it to be, since it is component specific and footprint agnostic- footprints are packages and these have no delay relationship .
regards,
As a workaround / implementation method , data could be imported into the package files for the moment, but this is not ideal
Example - Xilinx - BGA, one package can have 30 different FPGAs, each with their own pinout lengths or delays.
Clearly, one package in the footprint library is sufficient , and there would be multiple schematic symbols for the different devices, each with their own delays/lengths.
The way I think Altium does it is that when the UPDATE PCB is done, those lengths or delays are copied into volatile footprint data, so the length analysis tool can just pick up the lengths from the footprints. So I propose :
So a kicad transition might be that the lengths (and or delays) need to be first permitted in a field in the schematic symbol pins.
and UPDATE PCB would then copied those into the footprint length holders that we currently have.
that wouldnt be too hard.
the schematic symbol length data would be in the plain text symbol files, and thus could be easily imported from the xilinx csv into the symbols with a little user python.
If you want to propose a change in the Software, it would be helpful to create an issue here:
(Click on new issue at the top, you might need to register or login with e.g. your Google account)
That said, I don’t think your proposal is much better. Being part of the symbol makes some sense, but it’s also possible to use one symbol with different footprints, which have different pad-to-die lengths. In that case it being part of the footprint would make more sense in my opinion.
Note that in the default library nothing uses pad-to-die lengths anyway, so in case you add your components to Kicad, it should be no problem to duplicate the default footprint and adjust the pad-to-die-lengths there for each one.
Thanks Jonathan. I’.ve had a few comments in there so far.
I’ll use kicad a bit more and think about it a bit more- since, there is a workaround currently (direct entry to footprint data)
BTW in most cases the different packages for the same device (FPGA) need quite different schematic symbols. It’s a bit of a mix. But the reference data from the MFR is by part number, that’s what you would have in the schematic . Xilinx might have 100 orderable parts with different schematic symbols (and delays) all with the same footprint.
While this is true, for anything else than a prototype one would avoid this. The reason is that schematics is the source for BOM and thus for all the backend activities (ordering, inventory, …). So currently with KiCad if you want to have your backend process in order the only solution is to have multiple symbols for the same part where the main difference is an order code (but can differ also in footprint) as also stated:
Having custom pin properties set up in schematics opens other avenues.
Pin properties would ease the implementation of unit switching within the pcbeditor.
Additionally if power out pin has a “max current out” property and power in pins on the same net have “current in” property, the schematics could additionally check for current consumption. If power out pin would also have “typ. voltage out” property and power in pins would have “min voltage in” property and if these properties would be available in pcb editor, then static power delivery analysis could be automated.
I had discussion around pin properties a couple years back and from my recollections this is/was something that developers are aware of and plan to implement.
The only time I have used different footprints , same sch symbol is when the part is something like a quad opamp that comes in TSSOP, DIP, or SO14.
Having multiple footprints linked to the same sch symbol is too troublesome for a FPGA, there is too much different.
Hence, the need to have the die package lengths in the schematic symbol
additionally : For FPGAs you can have the same footprint with different die mounting options, and they have different package delays also, - its all tied to the device partnumber- which you would tie to the schematic symbol exact part number- hence delays and lengths should in with the sch symbol.
currently, kicad has the delays in footprints, which we can work around, but its not really appropriate consider the practicalities.
