← Back to team overview

kicad-developers team 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:
>>
>> http://een.iust.ac.ir/profs/mirzakuchaki/Synthesis/Lectures-pdf/DigitalICdesignCourse_session03.pdf
>>
>> 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.
>
> Wayne



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.


Dick





Follow ups

References