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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
