kicad-developers team mailing list archive

[Jon Evans <cdawzrd@xxxxxxxxx>]

Hi Marco,

The idea of aliases is to be "templates" for buses when you also give names
to a bus. This is a little different than you describe, and I think is a
powerful feature.

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"

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.

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.

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?

Thanks,
Jon

On Dec 14, 2017 08:08, "Marco Ciampa" <ciampix@xxxxxxxxx> wrote:

> First of all: awesome Jon! A really nice feature and video!
>
> My 0.000000002 cents here...
>
> On Thu, Dec 14, 2017 at 12:43:45PM +0100, Clemens Koller wrote:
> > Hello, Jon!
> >
> > Thank you for your work! I just watched your video and want to give you
> > some feedback:
> >
> > I would prefer not to use the term "Bus Vector". A bus is simply a list
> > (or a collection) of arbitrarily named nets. A bus group would be - in my
> > understanding - a group of (different) busses.
> >
> > I like your syntax to represent the list (or collection) {} as well as
> an array of nets [].
>
> > You first had a bus containing arbitrary nets: MEMORY{A{7..0] D[15..0]
> > OE WE} and you refer to single nets as i.e. MEMORY.A3 or MEMORY.OE -
> > fine.
> >
> > But when you add aliases I run into troubles to keep things
> separate/clear:
> > {RAM} appears to me as an unnamed bus containing the net RAM. WTF is
> that?
> > MEMORY{RAM} appears as a bus named MEMORY containing the single net RAM.
> > I would expect to access that net via MEMORY.RAM - Oops.
> >
> > I am definitely irritated by a net MEMORY.OE pulled out of an bus named
> MEMORY{RAM}. 8-(
> > It's impossible to distinguish bus aliases from nets of a bus.
>
> Apart from the _very_ unpolite expression, I agree here.
>
> Based on the example: if MEMORY is the bus name, the RAM alias should
> have the same syntax, so you should have this equivalence:
>
> MEMORY = RAM
>
> and so you should be able to write:
>
> RAM.OE as an alias of MEMORY.OE
>
> > Idea: It might be nice to virtually allow folding/unfolding of the net
> > collection contained in a bus, i.e. by showing MEMORY{*} or MEMORY{..} or
> > MEMORY{+}, whereas the '*' or '..' or '+' is shown in a different colour.
> > If that's still to long, I would not mind renaming the bus to MEM{..} or
> > even M{..}.
>
> The idea that Clemens is describing here (IIUIC) is that what you really
> nead is _not_ a bus alias (although is a good idea anyway...) but a more
> compact equivalent syntax for a BUS name.
>
> Once you have defined bus names like MEMORY{something} and MEMORY.OE for
> the single bus entity, you should be able to write something for just the
> bus name like MEMORY{+} or MEMORY{*} or MEMORY{..} (may I add my 2 cents
> here? Why not MEMORY{...} tree dots to distinguish it from the vector
> syntax?) instead of have to specify always all the bus elements in the
> bus name.
>
> So you should have on the bus name just this label MEMORY{...} (three
> dots ... I like it!) as a bus description and MEMORY.OE and such as
> connections outputting from the bus.
>
> > A simple mouseover M{..} could pop-up to show all nets and arrays the
> > bus contains.
>
> ... and that could be a really nice plus ...
>
> > Side note: For big designs, table-based design entry (as well as design
> > entry by importing tons of generated connections) seems to get more and
> > more important. It might be wise to consider how busses (and collections
> > of <something>) are represented there as well.
>
> Exactly.
>
> Having a compact syntax for the bus (i.e. a syntax that do not describe
> it completely) on the schematics, make it necessary to have a way do
> describe it completely somewherelse. It should be possible to create
> easily some bus descriptions list of nets (tables) somewhere on the
> schematic.
>
> Something like this:
>
> -------------
> |Bus: MEMORY|
> -------------
> |    A[7..0]|
> |   D[15..0]|
> |         OE|
> |         WE|
> -------------
>
> Anyway, awesome!
>
> --
>
>
> 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
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>