← Back to team overview

kicad-developers team mailing list archive

Re: [RFC] Eeschema bus upgrades and new connectivity algorithm

 

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

------------------------



Follow ups

References