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
