I just looked through Paul's examples, and it looks just like what I'm proposing except for the GUI details and where in the flow they're converted. Paul's examples even look like mine.
I reused the existing BUS graphic to represent a bus, so that the NET graphic could remain a net, where Paul used the NET graphic for both nets and busses, and the BUS graphic still does nothing. If you reuse nets for busses, you still must use a bus graphic to connect the nets, because connected nets have to have the same name, which means you *must* name all the nets - the connection to the bus doesn't provide a default name. In my proposal, it's possible to have an unnamed bus as long as all the bus pins have the same number of nets. While I applaud his results (yay!) I think it would be better if a bus were a bus and a net were a net, so that DRC and gnetlist could be a little smarter about detecting errors and resolving conflicts. One example: a single-signal net with two name attributes is an error, but a multi-signal bus with two name attributes is intentional, as long as (in my examples) there's at least one N>2-way intersection between them. Also, it means that you can have an unfettered syntax for net names, and a separate fettered syntax for nets that are in busses. I think it would also be useful to the user if single-signal nets and multi-signal busses were visually distinct. It would help them understand the schematic faster. Also, my proposal is to have the busses converted to multiple independent nets in the common parts of gnetlist, so that you don't have to tweak every single backend to add support for them. You can still support "magic" net names that the backends understand, if you want, but it seems to me a common concept like "bus" should be done in common code and be consistently applied across all the backends. _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
