kicad-developers team mailing list archive

[Ian McInerney <Ian.S.McInerney@xxxxxxxx>]

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> wrote:

>
> > On Sep 16, 2019, at 6:12 AM, Clemens Koller <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
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>