kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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
>