kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

I will have to think about this some more and look through the code to be
sure of the impact (or lack of impact)
The connectivity algorithm generates the names (with the dots) but doesn't
necessarily need to parse the strings afterwards except for ERC checking.
The syntax of defining bus labels is important, because that is an input to
the algorithm, but the net lables that are broken out of a bus are not as
critical I think.
For netlisting and bus unfolding, the transformation always goes in one
way, so the separator character (or lack thereof) is not important.

For ERC checking, it might be fine also, since I could just check whether
the name given to the bus matches the beginning substring of the bus name
it is attached to.

For user experience, it might be a bit annoying to have to remember to
insert a separator character if you want one to appear.
So I guess one question would be: do we want to support no separator
character at all?  Or default to a dot if the user doesn't end their name
in a different non-alpha character?

-Jon

On Wed, Dec 20, 2017 at 10:29 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
wrote:

> With out a separator, how does the connection algo know when a dot is
> part of a name or the separator between the name and the sub-connection
> or rre you suggesting that there be no separator so DATA[0..7] would
> break out into DATA0, DATA1, ...?  If so, I'm not sure this would be
> feasible.  @Jon, seeing that you are the person writing this code, any
> comments?
>
> On 12/20/2017 9:01 AM, kristoffer Ödmark wrote:
> > I see no value in adding a forced separator, I am not talking about a
> > configurable, maybe this has been unclear. I am talking about no
> > separator. So that I can put a dot or whatever i feel like anyway.
> >
> >
> > On 2017-12-20 14:47, Maciej Sumiński wrote:
> >> Hi Kristoffer,
> >>
> >> No offence, but is there any added value in using a configurable
> >> separator character or is it just your preference? It seems to me that
> >> adding such feature will complicate the code a lot for a small benefit,
> >> but I may not see the full picture. Perhaps it is just a convention that
> >> we could live with.
> >>
> >> Regards,
> >> Orson
> >>
> >> On 12/20/2017 02:29 PM, kristoffer Ödmark wrote:
> >>> Then dont use a underscore? If the dot is not inserted, nothing hinders
> >>> you from not putting a underscore there?
> >>>
> >>>
> >>> On 2017-12-20 13:32, Wayne Stambaugh wrote:
> >>>> Using an underscore as a replacement for the period will add another
> >>>> reserved character which will add complexity to the parser and/or
> >>>> require quoting when saving to the file which makes the file format
> less
> >>>> readable.
> >>>>
> >>>> On 12/19/2017 4:52 PM, kristoffer Ödmark wrote:
> >>>>> 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
> >>>>> _______________________________________________
> >>>>> 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
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
>