Re: gEDA-user: Christmas wishlist

[Peter Clifton <pcjc2@xxxxxxxxx>]

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@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user