kicad-developers team mailing list archive
Mailing list archive
Re: SWEET pin_merge
On 04/14/2011 02:36 PM, Wayne Stambaugh wrote:
> On 4/14/2011 11:01 AM, Dick Hollenbeck wrote:
>> The first several pages of the above are helpful to understand what verilog does
>> in terms of
>> a) module definition
>> b) module instantiation
>> c) wires
>> I'm still wondering, if we could make the bridge into s-expression syntax, that
>> there could not be some re-usable concepts, or parallels between:
>> 1) our "sheet" and a verilog "module".
>> 2) our "net" and a verilog "wire", although a verilog wire has local, module
>> specific scope.
> I have no issues with borrowing someones ideas if we can't come up with a
> better one ourselves. The verilog abstraction levels are interesting but I'm
> not sure how they would fit into the schematic sheet concept.
>> If this gets any legs, perhaps a better name than sheet is available. (If you
>> sheet on my schematic, I kill you.)
> Holy sheet Batman! Feel free to insert your sheet here :)
>> Whatever sheet with a better name is, it has symbolic "ports" or "pins", and
>> this then becomes a potential building block for yet a higher up client.
> Aren't sheets as we currently define them really just instances of a schematic
> with hierarchical or global labels? Why not treat them the same way we treat
> parts in SWEET. You could have a schematic that represents a functional block
> (single NAND gate in SWEET), a group of functional blocks (7400 standard body
> style definition in SWEET), or a complete stand alone design (complete 7400
> with alternate body styles, foot prints, etc. in SWEET). It seems to me there
> are a lot of similarities between the two concepts. Inheritance would work in
> almost the same way with schematics as it does with parts. Labels could be
> remapped the same way pins are remapped and schematic properties could be
> overridden just like SWEET. You could even extend the part library source
> concept for schematics. Just food for thought.
Wow. Only the inheritance sounds tricky, due to the cumbersome nature of
removing anything already declared in a base 'sheet with a better name'.
The rest sounds good. I will want to play a less active role in defining this,
so that I can focus on getting things already committed to working.
For my HTTP_LIB_SOURCE, I stumbled across WEBDAV, and am thinking in terms of an
apache module using this protocol on the other side of the wire of this
HTTP_LIB_SOURCE class, and of course maybe a HTTP_LIB_SINK class to use the
writable aspects of it too. But HTTP_LIB_SINK is not mandatory, since only
ADMINs should be able to modify a shared repo like this. WEBDAV apparently has
some form of versioning.
For me, the parts_list is and always has been the most important aspect of the
new design, and so I will be very involved there. The required discipline
there is to not revert to what we have, but rather keep the COMP class
minimalistic, so that the parts_list ends up being a BOM without quantities.
The rest is too much for me now, since this thing is right now a bottom up
design and implementation. I only get about 5 hours per week to code. The rest
seems spoken for.