On Sat, 2010-12-25 at 16:06 +0100, Karl Hammar wrote: > If a macro is a sub-layout, why not just call it a sublayout. > > > COW ... > > What is "COW"?
Copy On Write I would guess. (It is a common idea in operating system internals). Presumably the intention is just that an individual sub-instance could be cloned and altered to replace some of the instantiations. > Like, here is a led and resistor, we want to feed it with 12V, 5V etc., > or is that more a job for gschem? That is beyond what we probably want to teach gschem. Explicit parameter passing between hierarchy modules is probably a good idea though, as it allows tools to view / present the parameters being passed, and allows code sharing for the parameter passing mechanism rather than requiring each netlist back-end to re-implement nearly the same thing. And having subtly different implementations between (say), netlist extraction for simulation, and for driving a layout tool. Interpretation of equations or value definitions would almost without doubt need to live in a modular back-end, as the mathematical descriptions, primitives may vary between usage fields. It might be good to keep such back-ends distinct from our concept of a gnetlist back-end though, as one might presume SOME calculation / substitution / back-annotation could be shared between a number of target gnetlist back-ends. It would probably be possible to parametrise the required component values like this in VHDL / verilog(-ams): LED1.vf = 2.7v LED1.if = 23mA R1.value = ( module.supply_voltage - LED1.vf ) / LED1.if The modular backend handling maths expansion would be used the process the attribute references and compute the value. (And perhaps back-annotate to the schematic). For some targets, this might also involve post-processing to identify preferred component values, add data from a parts library - whatever. Personally, I see this kind of tool as more of a pre-schematic stage, since at some point it is likely you will want to nail down the part data explicitly - but that is perhaps me coming at the problem from a PCB work-flow mind-set. Perhaps there is even scope at some level for a two-way flow.. Imagine a filter block which is parametrised by a cutoff frequency. The component values are chosen based upon the user-specified cut-off when inputting a design requirement. Similarly, if the user chooses to modify one of the component values.. it could reflect that change by updating the module's specified cutoff frequency. (This would require either a lot of special casing per sub-circuit, or some fancy equation solving engine which can operate with arbitrary variables in an equations being known or free to vary as outputs). > Another cases could be: > . here is a sub-layout, but we want 1 mm clearance > . drill/thickness ratio should be 2.4 for this connector > . ohh, you cannot have 5 mm clearance for the connector > . here are five output relays, it should be a relay every 13 mm > along this line. > . here is a trace, we want it to be able to handle 12 A > . this stripline should be 50 Ohm > . this serpentine should have a trace length of 27.4 mm All good examples. First step is to record the engineer's design goal in some kind of explicit manner. A logical step is requiring a report of a given design to see what the actual characteristic of the designed trace / whatever meets. Then as a first cut, you have a more advanced DRC test which determines whether the layout / schematic meets the stated design goals. As a more advanced step (either a complement or alternative to the DRC addition), you could introduce a solver which constrains the layout being created to comply with the design goals - either through placement rules, locking a particular track thickness, or whatever. Track_width = Automatic (all design goals) Track_width = Automatic (for design impedance) Track_width = Automatic (for design current density) Track_width = Automatic (based on net class) Track_width = 20mil Track_width = 30mil ... ... All ideas.. I'm not coding anything on this in the foreseeable future ;) -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user