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 <ciam...@libero.it >>>> <mailto:ciam...@libero.it>> 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@lists.launchpad.net >>>> <mailto:kicad-developers@lists.launchpad.net> >>>> 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@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp