I'm no more willing to have to wait for several months until the last tool builder allows me to go ahead with the next release [like it was for cd2.4]. This release might be disabled for tool makers, whenever the next release is ready and the tool makers had 3 (calender) days to keep track. Should that not expedite a future release, the old version will be disabled for all users.

Read only for designs means: objects will not change their picture on mask; the directory does not change.

It does not mean no other state changes like push, pop, or certain commands on top level are made. [Read only doesn't protect the complete data structures; only an abstract concept]

Absoluteely required:

This feature is orthogonal to the class.

Immutable objects and read only designs are different concepts and not linked together at all.

The interactive user interface for this feature is not ready.

New: Objects do not need be included in directory.

As allways: Mutable objects must not be included in more than 1 design.

Directory is read back from file as written! NOT cleaned up!

These new invariants simplify [correct] implementation of classes like CDRepetitions, CDDynamicObjects, Abuts and RouteChannelObjects. I still do believe clients should not define their own classes [but I don't prevent it either].

In case ChipNDale finds out about an invariant to be broken, ChipNDale might simply call an error instead of trying to fix it.

Due to the changed directory invariants, imports can not rely on caching; caching is now a hint only. To really find all imports all instances have to be enumerated. Baah.

There is new real code behind the implementation of imports, but the user interface code is not yet completely polished for the new internals.

Cached designs are re-used when they have no indirect unbound objects and the same file would be accessed.

Indirect imports do not give the user control of the binding [Why should they?].

There are two modes of output: Truth / Cache; This allows object class and property implementors to write [cache mode] output procedures without the burden of having to support the files for ever [as in truth mode].

Warning: don't store cache mode files without also storing the truth. If cache mode files can not be read back, there will be no help from me. For truth mode files, the known service on IO problems will remain as ever [Unless non standard features have been used which interfere with the file format].

Theoretically saved 26 gfi's !!

A little more polish

This ChipNDale version 2.5 can read in files of all previous ChipNDale versions [0.0 and up], but I can't guarantee that for the next version.

The documentation is already updated.

New chapter in documentation on creation of icons.

Font size can be changed

Control panel has line for texts; used for the text editing commands.

"R" is used as a modifier key, to read data into the control panel:

Wires [only CD.commentLayer] don't disapear if scaled to small [different rounding]

Step move dist "0" will do step moves with the current viewer grid.

<space /> command has a "move selected to grid" option.

</ then "<"> double grid.

</ then ">"> half grid.

Mode switch between layout mode and schematics mode [CMos-B only]

Better error behaviour in case separately loaded commands fail. Additional loaded commands allow denial to execute [saves gfi's on browse trips]

Satellites commands changed to be easier to understand, at cost of sometimes more usage of menu.

About 4 menus and 10 commands withdrawn [I believe nobody used those].

Step moves do not feedback in Terminal viewer.

Control panel has multiple layer lines; switch by hitting the "current layer" field.

Rename object (without using mouse): <CTRL-N>.

New command: Search object by name.

Push in by name, draw, replace, and search commands do also work with an adress instead of the name of the object; this implicitely allows to replace texts.

List, or, prune directory commands can have patterns. Pattern field in panel.

PD-plot and interpress-plot can plot just the selection

Tip tables are no more reinstalled on user profile changes but only with the command tool command "CDReInstallTipTables".

Font substitution compensates different rope bounding box sizes on flip texts.

The debug command can be issued even while the design is locked.

New colormaps module offering all Cedar choices, and, swapping cursor representation mode.

Colors for splines, polygons and text overlap correctly on 8 bit per pixel displays, at least for the layers not using stipples.

Use the command tool commands to put the right colors into a checkpoint.

ChipNDale.OpenEventViewers: FALSE

ChipNDale.RunPrograms: List of Token ← NIL

CommandTool commands: use wDir and searchpaths from command tool and process

ChipNDale commands: use

wDir and searchpath must be specified explicitely by client when accessing files; they are not inherited from process [processes are light weight !]. (Clients: use CDEnvironment.FindFile or FileNames.FileWithSearchRules)

New procedures Describe, DesignName, DrawOb

DrawProc: use ob, instProperties instead of inst

Types do explicitely use notation CD.foo; to make it easier to make copies

inDirectory -> composed

ObjectClass has xDesign flag

better handling for objects crossing design boundaries

support for multiple hierarchies [physical versus icon-schematic]

new interface

withdrawn, functionality moved into CDDirectoryOps

re - exports also CommandProc, Command

New mechanism to scan convert in device coordinates

New package to share the design caching code for imports and remote

New invariants

New enumerate design procedure

ExpandByDraw more powerfull mechanism, with call back procedure

DirectoryOp type changed: Class's DirectoryOp's procedures must not fail

Object enumeration procedure has quit return value

Use SymTab instead of HashTable

ExpandProc and AnotherProc have slightly simpler type

Improved comments

Renamed EnumerateObjectsProc -> EachObjectProc

Renaming Another -> Another1; AnotherComplete -> AnotherRecursed, Expand...

AnotherRecursed, Expand.. has optional client caching parameters

more procedures, merged from CDCleanUp

RenameNRemove discarded

PruneDirectory has pattern

New procedure IncludeDescribedObjects

New procedures RegisterCommander, FindFile, GetTechnology

Replaces CDRemote

No caching; changed names to be able to merge impl with CDGenerateImportsImpl to CDGenerateSomeImpl.

Problem with read-only objects not yet solved right.

Error message now may be outside interest rect area.

Additional data to store well and interest rect informations

Withdrawn [this was taff !!]

Almost everything changed.

Truth flag.

Writes a 40% less dots to compensate for larger designs.

proc ObjectRope gone ! use CD.Describe

some procedures from CDSimpleOps

New procedure MakeImmutable

New procedure and convention: When a design is created and build, its mutability should be set using SetMutability.

Detailed with control for fields; since this means lots of new parameters, parameters are grouped in fields. All procedure identifier changed

Procedure to make sure property is NOT written to file (in any mode).

Property registration can specify whether property is not output for cache files.

Can handle wells; new class $WellRect

New procedures to querry class

Replaced by CDGenerateRemote and CDDesignCache

New; loaded on demand only. [like previous class in PWObjects, but full implementaion]

Additional rules parameter for multiple sets of design rules revisions per technology

Implementors use new package CDSimpleRulesBackdoor

MinSpace <= MinDist

withdrawn; some procedures moved into CDOps

registrationData field for command registration

change OpenDialogue -> SetEditable

FetchCommand has load optional

Font has field for pressfont.

FlipTexts will be adjusted to the side of their origin, if fontsubstitution changes size of text.

needs CDVArrow.install to run

new from CDViewerBase and CDVFurtherPainters

--> CDViewerBackdoor

--> CDViewerBackdoor

Small definition and large implementation change. Thanks to Michael Plass for simplifying the Imager and Viewer [BackdoorPrivateExtras...] interfaces needed. Still slow.

Moved to CedarChest.

New procedure: TrustedDisposeTesselation; [Giordano figured out that for 30% of the time in some drc was used in allocating border tiles for small tesselations]

No more used by ChipNDale.

I will through this package away unless somebody tells me about a need for it

ReLabel allows changing labels of existing menus

Renamed from PropertLists; better module name to avoid confusion which property package is used. New little confusion by using the other packages name is intentionally.

New procedure CopyList

Use old, loved TOS again instead of silly long name CreateStream [in analogy to IO]

handle has truth field

CDSimpleOps, CDMarks, CDCleanUp, CDOldInterestRects: are withdrawn

Ticks, CDVArrow: loaded on demand only

CDLayersImpl and CDRectsImpl are replaced by CDRectsAndLayersImpl

CDEmergencyHandling: functionality put int CDIOCommands

CDVFurtherPainters, CDViewerBase, CDVCursorImpl, CDColorsImpl and CDVScaleImpl are replaced by CDViewerBackdoor

CDVSpecialPainters merged into CDVCommands

CDVMarksAndModes merged into CDVSomeCursors

CDMenuSpecialsImpl: merged into CDPopUpMenusImpl

CDMoveCopyCommands merged into CDBasicCommands

HashTable: no more used

CMos-B: CMosBObsImpl and CMosBObjectsImpl merged; CMosBWellDifImpl removed

CDPanelImpl, CDSequencerImpl, CDImportCommands: carefully crafted to each use one slot less (proc's inline) [but I fear that the next small improvement might cause again to have one procedure too much]

CDSymbolicObjectsCommands split up and merged into CDExtraCommands and CDCellCommands

CDGenerate, CDGenerateBackdoor, CDGenerateRemote, CDGenerateImports and CDGenerateCommands loaded on demand only [3 gfi]

The previously existing 6 different ways of enumerating designs by ChipNDale have been reduced to 4.

4 remaining enumeration techniques:

2 withdrawn enumeration techniques:

Double painting when viewers are created is circumvented [oops].

Selection is painted first; this requires to go twice through the whole list, but it gives the illusion of painting faster.

Improved algorithm to fiddle names; In case of conflict through wrap around, use random number to prevent making longer names.

Use of cache mode IO

Deals with nested un-named cells

Use working directory of design

An implementation of stitched vias [in CDExtrasA%.df] registers itself with CDSimpleRules

Font cache is forget-full; [servers will not fill VM with fonts]

Fonts caching is faster: Reading Logic should be 8% faster just from this improvement alone.

Performance-bug fix: Will generate far less empty cells.

Generates signal names from CDSatellites. (Works only for satellites of simple enough instances [not p-diffusion]).

Setup command files have names starting with CDCifGen...; this is to distinguish them from the Read-Cif command files [until an identical format is defined]

Generates CIF from the selected cell only.

The object classes $C2PDifRect and $C2NDifRect are replaced by $WellRect

Small victory: CMosB does not implement ANY object class anymore without using inheritance for all CD.Objectclass procedures. [CDAtomicObjects inherit all class procedures; the classes differ in creation procedures which are NOT CD.Objectclass procedures, but exported by CDAtomicObjects]

New abstract well contact layers with well surround.

CDIO: io tells when it encounters error messages.

CDCifGen: Cif generation tells when it encounters error messages.

CDMEBES: mask generation tells when it encounters error messages.

Well's and error messages do not contribute to the interest rect of cells

Optional plot of selection only.

Better dialogue [still not nectarine].

Uses new mechanism for scan conversion in device coordinate system.

Optional plot of selection only.

Better dialogue [still not Nectarine].

Gets font and prescale from control panel.

Split up into CDMore%.df andCDExtrasA%.df

Robust extras used by clients

[Bottom up extraction; stitched vias, RoutingObjects]

Extras used by clients and interactively

[ticks, arrows on viewers]

For command level utilities and not yet debugged extras

Discarded; commands moved to CDMore%.df

n is an integer

g is size of grid [a large grid]

w is width of a wire

Unknown to ChipNDale

Unknown to ChipNDale

Unknown to ChipNDale

Use the standard menu table; decentralizing menu tables will make it hard to be consistent. Loading commands is still centralized anyway.

CDSatellites and Sisyph entries are in the standard tip tables; CDSatellites doesn't even export a tip table.

1) For all purposes, when a design is enumerated, or an object is enumerated recursively, a new algorithm must be used. Designs or objects must be enumerated quite often! [pop, other interactive commands, redraw, propagate changes, IO, clean up, error messages, expand, copy].

2) ChipNDale would not need to check and reinstall the invariants, since no malignant clients would be around. Plain bugs do not justify such hard consistency checks.

Brian generated a design with Patchwork. Then he edited his design, but the edits where made in the library. [A clear case of an object being included in two designs].

To ChipNDale:

To PWCore:

To PWCore Clients:

To the DA system as a whole:

To ChipNDale:

To PWCore:

To PWCore Clients:

To the DA system as a whole:

Peace.

The new design enumeration methods could be correct even when the directory is incomplete.

Possibility to get rid of complex clean up code, by being able to trust clients again.

Repetitions could be simplified.

You may dispute those benefits, however, but they aren't the issue for the change anyway.

The handle might be useful for more applications, e.g. it could contain information whether to make or read design from checkpoints.

Technology independence will be possible, because technology could be figured out.

Maybe speed up, because caching could work without need for indirect objects.

Caching objects will be possible.

Possibility to be more honest ChipNDale clients. [To be complete we would also need a procedure to extract CoreGeometry pins or whatever PWCore wants, from an object with ChipNDale pins].

Accessing imports will be possible.

Unknown further uses of the handle could be invented, e.g.

Two important implementations could live together friendly.

Speed up because objects will be copied less.

Possibly memory savings, but I'm not sure.

Layout is performed with a more complete state.

A natural place to specify checkpointing would exist.

Abuts and Routing-cells could make it onto ChipNDale files. [Because the weaker directory invariants would allow them to be nice citizens easier; now ChipNDale better does not write objects on files when they don't play the rules]

Thats too painful.

The current PWCore would cease functioning (See** to understand why I mustn't care.)

That concept would still have some holes and problems, however, it would be much better than the status quo. [Imports are NOT read only.]

That might be a good idea in general, independant of this proposal, unless carried to extremes, it would not solve all the problems which caused me to make this proposal.

Clients could not use all the already existing constructors. Duplication of code.

Must have one first.

In 1984 there were two performance bugs:

For any abut to be included in the directory it was tried to include it as "abut"; then as "abut@1", "abut@1@2"... until "abut@1@2..@n" was tried. This caused n2/2 tries to include objects in a design, which, because of using small SymTab's, caused O(n3) rope comparisons [ropes with length of another O[n]]. [n=number of objects]

ChipNDale's performance bug was fixed immediately after I was told about the problem... Patchwork switched over to not play the rules with the directory.

ChipNDale never allowed to make objects with interest rects larger than the bounding box. This might have been painful and not the right thing, but it was the rule. Now in the logic library this rule was violated; those objects never displayed correctly [They would even cause incorrect masks]. Then these objects did not pass the automatic conversion from CD23 to CD24. I have been told [Ed] that ChipNDale allowed the construction of those objects; therefore it should also deal with them. See, thats why I must enforce invariants; otherwise I forfeit my rights when problems occur later.

[In CD24 interest rects are treated as "stuff"; they automatically add to the area used to compute the bounding box of cells]