* New: In Hurricane, added first support for DataBase native import/export
using JSON.
We choose RapidJSON, in SAX mode, to manage the JSON format low level
Read/Write. Thus, it's Git repository http://github.com/miloyip/rapidjson
must be added under ~/coriolis-2.x/src and manually build and installed
in the Coriolis installation tree (to be integrated in ccb later).
Two mode are being supported:
1. Cell mode: one Cell only is saved. In that mode, Entities
referred by Occurrences are "outside" the file. They are coded
through their "signature" (mostly, all the values of their
attributes). The ids saved in the file cannot be restored
identically as we cannot predict when and in which context the
Cell will be reloaded.
2. Design Blob mode: the whole design hierarchy, down and including
the standard cells is saved. This way the design is completly
self contained and Entities ared referred through their ids.
A design blob can only be loaded immediatly after starting cgt
as the DataBase *must* be empty. This way we restore the whole
design hierarchy with *exactly* the same ids.
Now, Hurricane object should provide a "toJson()" method for driving
JSON, and be associated with a JsonObject derived class for parsing.
* New: In Hurricane, ability to force the next id that will be used for a
DBo (used by Design Blob Mode).
* New: In Hurricane, in DataBase, added getCell() and getLibrary() functions
to allow the hierarchical access of a Cell/Library in native mode
(i.e. whithout the requirement of AllianceFramework).
* New: In Hurricane, In CellViewer, added menu entry for Save/Load of
JSON Design Blobs. Added at this level because we consider it as the
"native" format of Hurricane.
* New: In Unicorn, added support of import/export of JSON Cell.
* Bug: In Hurricane, in Instance, when cloning an Instance or uniquifying
it's master Cell, we forgot about the Occurrences (through shared pathes).
When an instance is cloned the Shared pathes still points toward the
original Instance. And when it's the master Cell that is uniquifyed
it's the Entities pointed to that remains in the original Cell.
This is a software design problem. It is difficult to define what
policy to adopt when uniquifying: basically that means that one
Occurence is either moved onto the clone or duplicated. Furthermore,
it is not trivial to known what Occurrence is pointing on the
uniquifyed/cloned item. Have to think about it a little more.
* Bug: In Etesian, in EtesianEngine, build the flattened nets and their
RoutingPads *after* uniquifying (through slaving bounding boxes).
This way we avoid the Occurrences problem described above.
* Bug: In Etesian, in EtesianEngine, invalidate the RoutingPad after
processing the placement so they are put into the right quadtree.
This problem is due to the fact that the RoutingPads do not belong
to the Instance that they refer. And when this instance is moved
around, she doesn't inform the RoutingPad that is has moved.
More software architecture design to review...
f537a10d45