Stephan Boettcher wrote:
Stefan Salewski <mail@xxxxxxxxxxxx> writes:On Mon, 2010-08-16 at 10:09 +0200, Stephan Boettcher wrote:John Griessen <john@xxxxxxxxxxxxxx> writes: If there is work put into partitioning a layout, can't we please have hierarchical layout instead?I have still problems to understand the goals and benefits of partitioning hierarchical layout on PCB board level. Can you give an example, when possible with a picture?I usually have hierarchical schematics with multiple instances of the same subcircuits referenced from the main page. The deepest until now were three layers of hierarchy. All the cutting, sed-ing and pasting of the subcircuits to multiple instances, with replication of later changes on all copies is pretty unflexible. Hierarchical sub-cells (like with ASIC layouts) would allow to make and maintain such circuits much easier. What I am asking for here is, when you now talk about layout zones/partitions/whatever it's called in the end, please consider the application of the concept for this kind of hierarchy. Maybe the new concepts can be easily applied for that as well, with a little vision into that direction. Maybe it is trivial to allow multiple copies of a layout zone on a board, with a common netname/refdes prefix substituted on the copies. When you edit the layout of any copy, all instances follow the change.
Using blocks in mechanical CAD has some issues with this. In principle there are 2 ways to use a block: a) copy and paste b) reference Naturally the "edit one modify all" can only work with referencing. Sometimes in a single construction this is not desired, so when duplicating one has the choice between reference and copy. With mechanical constructions this goes as far as changing the appearance of a referenced block, when when an external block is changed independently. This can be useful, if the interface of the block is well understood. With pcb-layouts I strongly advise against this procedure: if a block getsinserted in a layout, a local copy has to be made (that is positioned nowhere) and references to this comprise the physical instances. Any attempt to modify
a block with backpropagation to external data that is used in other boards will almost certainly break those layouts. When modifying a reference/instance of the (local) block one must get asked if opening the block is meant to change all instances or copy on write shall be used. About refdes-usage in this scenario: I find it hard to see an application of a block without using a corresponding sub-schematic.I would btw. like to be able to see only the "basename" of a refdes on the silk layer
if it is made like <schematic_name>/<schematic_local_identifier>. _______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user