← Back to team overview

kicad-developers team mailing list archive

Re: [RFC] Eeschema bus upgrades and new connectivity algorithm

 

Why would this be problematic for users like you to be able to chose whichever character you fancy instead?


On 2017-12-19 22:03, Wayne Stambaugh wrote:
This would be problematic for users like me who use the underscore
character in names for readability.

On 12/19/2017 3:57 PM, kristoffer Ödmark wrote:
Another thing, maybe not force the usage of the dot ".", I would rather
like to force the dot myself, or be able to use "_" or whatever i fancy.
So instead putting CH0.{ADC}, or CH0_{ADC}.

- Kristoffer


On 2017-12-19 21:28, Jon Evans wrote:
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
<mailto: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
     <https://launchpad.net/%7Ekicad-developers>
     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
     Unsubscribe : https://launchpad.net/~kicad-developers
     <https://launchpad.net/%7Ekicad-developers>
     More help   : https://help.launchpad.net/ListHelp
     <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


_______________________________________________
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

_______________________________________________
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



Follow ups

References