kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

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

Attachment: signature.asc
Description: OpenPGP digital signature