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
