kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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