kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

Hi Marco,

Thanks a lot for your feedback.

I agree with you and others who have commented on the desire for there to
be some way to know what is going on if you make a PDF or printout from a
schematic using the alias feature.
I'll think about this, and if anyone else has ideas on this, please let me
know.
(Andy's point is another one that I failed to note previously -- anywhere
you use a bus entry to lay out a wire exiting a bus, you will see the full
net name, so you can tell what is in the bus that way already)

I see this feature as a thing that would be used in very complicated
designs in order to make them simpler to follow, so making a simple example
to demonstrate where you might use it is kind of a challenge -- if I use an
example that is very simple so that it is quick to make and quick to
explain, then it is not obvious what the benefit is.  I will work on some
more "real world" examples of where this feature could be most powerful.

Without taking the time to actually make up some fake schematics (which I
can also do when I have more time), here are some more examples:

1) Complicated bus goes many places in a hierarchical design

Let's say you have some kind of definition for a complicated bus -- some
combination of various net vectors and nets that results in a long label.
For example "A[12..0] D[15..0] OE WE RESET"

You use this bus in a hierarchical design where it connects a FPGA (on one
sheet) to multiple memory devices (on other sheets).
You can create an alias to rename this bus to just "MEMORY" and then in
your top level sheet, you'll see a pin on the FPGA sheet called "MEMORY",
connecting to pins also called "MEMORY" on the other sheets.
On the sub-sheets, the bus will be broken out into its components, so you
can see OE running to some chip, RESET running to another pin on the chip,
etc.

Benefit: your hierarchical sheet port/pins don't have huge labels for the
buses, just "MEMORY".

2) Design needs multiple copies of a similar bus with distinct net names

Say you are designing a big data collection device.  It has a large FPGA
and 8 channels of ADC.  Each ADC needs its own set of signals going
straight back to the FPGA (i.e. no shared signals between the ADC)
You could define buses going to each ADC like this:

"CH0{D[15..0] CLK_P CLK_N}"
"CH1{D[15..0] CLK_P CLK_N}"
and so on.

This would leave you with nets for each ADC like "CH0.D15", "CH0.CLK_P", etc

Now you could *optionally* also define an alias for the signals each ADC
needs:

"ADC" => "D[15..0] CLK_P CLK_N"

Then, you could name your ports/pins/buses like:

"CH0{ADC}"
"CH1{ADC}"
and so on.

Benefit 1: Even if you don't use aliases, putting a name in front of the
bus group means that each channel will get its nets automatically prefixed
with "CH0" etc.
Benefit 2: If you use aliases, your port/pin/label names get much shorter,
the same as in the first example.

Hope this helps!

Best,
Jon

On Tue, Dec 19, 2017 at 2:06 AM, Marco Ciampa <ciampix@xxxxxxxxx> wrote:

> Hi Jon,
> first of all, thanks for listening my thoughts.
>
> I waited to send this letter a few days to wait for things to clear up to
> me.
> I think that this still apply although some things might be a little
> clearer
> now, so, in a way it is a little obsolete. I am sending it the same because
> I do not want to kill its spirit...
>
> ...but please continue to keep in mind that these are my 0.00000000000002
> cents humble opinions...and really nothing more...
>
> On Thu, Dec 14, 2017 at 08:21:29AM -0500, Jon Evans wrote:
> > Hi Marco,
> >
> > The idea of aliases is to be "templates" for buses when you also give
> names
> > to a bus.
>
> Ok clear.
>
> Let's call them templates then because for me an alias is just an alias.
>
> > This is a little different than you describe, and I think is a
> > powerful feature.
>
> I do not want to be unrespectful and ungrateful especially since I am not
> a dev but... there are many powerful features that we (actually you devs)
> can concoct but not all of them would probably turn out to be of such
> usefulness even if very powerful and feasible.
>
> I think that we should always keep in mind a need to be fulfilled and
> some cases of use in witch such a feature turns out to be useful.
>
> And even if it turns out to be of some usefulness, there is always a
> trade-off between an increase in complexity of the design process
> and benefits to the designer and in the complexity of the schematics.
>
> If we are not able to find an example in witch this feature literally
> kills a big deal of work, then I am afraid that we are introducing some
> rarely used, obscure to grasp and difficult to document feature.
>
> I mean that schematics are to be understood in printed form. The meaning
> (of the syntax) of the drawings should as of immediate comprehension as
> possible. Every template/macro/alias that we add to the schematics should
> probably:
>
> 1) be documented in printed form (no, a pop-up window is not enough) on
>    the design sheets
> 2) must be easy to read (as in a paper print) even if you do not know
>    KiCad at all
>
> because this feature, if I got it right, seems to me more a kind of
> "programming" than "describing" a circuit design
>
> > If you define an alias called MEMORY, you can then define *multiple
> > different* memory buses, so they have to have different prefix names. But
> > you can also choose to use aliases *without* a prefix name, and then
> > everywhere you use that alias will be part of the same set of nets.
> >
> > So, a more realistic and simple example would be:
> >
> > Define alias "USB" containing "DP", "DM"
>
> Ok
>
> If I do not see this definition somewhere on the sheet, am I still able
> to understand the schematics just looking at a print on paper of it?
>
> If I need to see also the "alias" definition to understand the
> schematics, where can I look at this template definition on the sheets?
>
> > Now in one sheet you have a USB hub. You can define four different buses
> > with names and the alias, and get nets like "PORT1.DP" and so on.
> >
> > But on a simpler design, you might not need four ports, so you can just
> use
> > "{USB}" in your bus name and get nets without any prefix.
>
> But it seems to me that this is the same name of a net on the bus with
> name "USB"...
>
> > I think both options of how to use buses are valid and useful, and I also
> > understand your confusion when presented with all these options at once.
>
> Would you be so kind to continue with this example and show how could be
> represented, for instance, a 4 USB bus schematic? Or other examples that
> could benefit from this feature?
>
> I do not really "see" it if I haven't a real example to look at... it's
> my lack of imagination, I know...
>
> > With that in mind, do you have any thoughts on how we could preserve the
> > power of this feature while making it easier to understand?
>
> If we (you devs) find really worth, my suggestion is to:
>
> 1) clearly divide the template/class definition from the istances syntax
>    (but I do not know how though...).
>    The confusion to me arises from this "all in one" approach.
>
> 2) find a way to describe it "on paper" to make schematic sheets readable
>    to non KiCad users (normal elect. engineers)
>
> My suggestion here is to keep it as simple, and clear, as possible.
> Between powefulness and readability, if it is not really worth it, I
> personally prefer the latter.
>
> Best regards,
>
>
> --
>
>
> Marco Ciampa
>
> I know a joke about UDP, but you might not get it.
>
> ------------------------
>
>  GNU/Linux User #78271
>  FSFE fellow #364
>
> ------------------------
>
>
> _______________________________________________
> 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
>