[gta02-core] KiCad wish list

[Álvaro Lopes]

Rene Harder wrote:
> Werner Almesberger wrote:
>> I made a little example:
>> http://svn.openmoko.org/developers/werner/gta02-core/foo/
>>
>> That's basically an NPN transistor. (Just kidding about the triple
>> inversion.)
>>
>>   
> Thanks for the example.
> 
> That's not exactly what i was looking for but i do now understand what
> you mean with function-specific footprint. You are right, we should
> never do anything like this.
> I thought something more like you have symbol without pin numbers same
> as yours in the example. The footprint has ordinary numbers though.
> I was looking for a way to link the pin depending their function e.g.
> pin E -> pin 1 (pin in symbol -> pin in footprint), B->2 and C->3 and
> for different a footprint maybe E->3, B->2, C->1 and so on.

This is exactly what I wanted, ie, devices.

Each device maps symbol pins to footprint pins. Might also define pin functions (but see below)

> 
>> Yup, but we have three places where we can solve this:
>>
>> - the symbol, as we do now
>> - the footprint
>> - or by introducing a mapping layer

Which I call the "device". Well not me, eagle does :P

>> The problem is that you don't only want to make the association,
>> but you also need to be able to verify it. If it's "hidden" in
>> the footprint definition, you need to check schematics, data
>> sheet, and the footprint to be sure things are right. If at least
>> the footprint is generic, you don't need to look up that one.

We have another problem here. Many devices have pins that can be configured to be I/O/IO. So concrete pin operation depends not on symbol, not on device and not
on footprint.

How would you define FPGA user pins without knowing what it runs inside ? You can't. So we actually need some extra level of indirection here, if we are to
reuse that "device" in other designs. We actually have already one such device, in which pin function depends on the firmware.

> Although we could make more generic symbols and footprints where more
> people would benefit from, I think to wait for a feature like this would
> probably take ages.

Agreed.

Now, we only want this "pin functions" for validation. But I think that for most of them, and since there is only one or two instances of each, we can annotate
pin function in the schematic. I also want to do this for other values, like Imin, Imax, Vmin, Vmax so we can validate a simple netlist to check for "shorts",
high current drains, and such. Not easy, but I'll try to do it (if I have time of course). I also want to get a glimpse of how much power it drains on best and
worst scenarios, ignoring switching if needed or using worst-case values for our known frequencies.

Álvaro