kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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
>