Unfortunately, no I don't agree that the grouping should be by
peripheral. The purpose of a schematic is to capture the electrical
connections of a circuit, and allow the designer to reason about it.
On most chips, the electrical specifications of the same peripheral
type can differ between instances (e.g. I2C0 has different specs than
I2C1 because they use different pins).
The most useful grouping for capturing these differences are the ports
(since those map to the raw pins). The electrical characteristics are
usually defined on a per-port basis (so all pins of a port will
usually share the same Vcc, contribute to a per-port current
limitation, have the same voltage tolerance, etc). If you abstract the
IC into the peripheral functions, it becomes a lot harder to analyze
the electrical characteristics when doing a proper design. For
instance, say you want to use the STM32F413ZH. This chip has multiple
SPI ports, but one of them (SPI1) has pins that are not 5v tolerant,
and are only 3.3v tolerant. It becomes easier to analyze and work with
when you group by port/pins because the datasheet doesn't tell you
that SPI1 as a whole is not 5v tolerant only that pins PA4/PA5 (which
it uses) are not 5v tolerant. This limitation is also present for all
other peripherals that share those pins.
This same reasoning also applies to FPGAs, and I think it is better to
keep the same reasoning across device types so people don't have to
learn multiple ways of using the symbols and analyzing the design.
As for the generation of pin constraints to map into the embedded
software, I have been thinking of ways to do that but I haven't had
time to write up a full RFC for it. I am approaching it from an FPGA
viewpoint first though, since those pin constraint maps can be very
tedious to write and it would be nice to ensure there is consistency
between the schematic and the options (such as pull-up/down status,
CMOS voltage level, etc). Initially I am thinking of just introducing
text fields the user fills in, but I am also going to investigate if
we can define a new properties field type for selecting values from a
discrete set. Then the symbol can define the valid field values and
the user can choose from them. This will be a long time in
development, since it will rely on the new file format and also
Eeschema Python bindings for generating the constraint files.
-Ian
On Mon, Sep 16, 2019 at 7:51 PM Andy Peters <devel@xxxxxxxxx
<mailto:devel@xxxxxxxxx>> wrote:
> On Sep 16, 2019, at 6:12 AM, Clemens Koller <cko@xxxxxxxxx
<mailto:cko@xxxxxxxxx>> wrote:
>
> Hello, Tim!
>
> I agree that in the near future, the demand for (I'd call it)
"Table Based Design Entry" will rise tremendously,
> when we reach pincounts in the high hundreds and thousands.
>
> It is a lot of work to draw and maintain complex MCUs/SoCs/FPGAs
in some schematic when pins can have 8 different functions which
might change during product development. A current example: i.MX8
[1] with i.e. 625 pins.
> So, it might not even be sufficient to be able to import (and
export) .CSVs. It might be a good idea to prepare for some
automatism to be able to update and version control pin
multiplexing changes!
How about this?
We can all agree that grouping MCU pins by peripheral makes the
most sense. So rather than having a big box symbol (or symbols)
with pins in a default order, why not have each part of a
component be a peripheral? Instead of having a multisymbol part
with one or two or three boxes for my EFM32GG11B820F2408GL192 in
the library, instead of EFM32GG11B820F2048GL192 as the part name
and within the part have all of the valid peripherals for that
device?
Here’s the cool thing. This device has, say, I2C0, I2C1, I2C2,
UART0, UART1, USART0, USART1, TIMER0, TIMER1, all of it, and there
are a fixed number of peripherals for a given device. Each
peripheral is a symbol (a sub-part of the device) you can place on
your schematic. Need a UART? Place the EFM32GG11_UART0 symbol on
the schematic. Since this particular chip family gives you several
choices for each pin, the symbols are “Smart” and have a drop-down
menu you use to assign the pin. Those assignments also
automatically set pin direction and the other ERC stuff. For
peripherals which have one location for their pins obviously this
drop-down doesn’t exist.
Cool, right? It can be better. Any pin not explicitly designated
for a peripheral that can be used as GPIO gets enabled in the GPIO
symbol. In that symbol then you set the direction, etc after you
place it on the schematic.
Since all of the ARM vendors these days have some kind of software
tool that handles peripheral setup including pin assignments,
having the ability to read that output (whatever it is) and then
parse it and set up the individual blocks would be very cool.
Right now I just rely on sensible net names to keep my MCU pinouts
straight. I used to make a custom symbol for each MCU in a design
but that got to be too much.
FPGAs are a different can of worms.
-a
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
<mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
