* Bug: In ClockTree plugin, only the logical view of the clock buffer
was loaded, so no external components where found on the I/O nets.
The external components are loaded only when the *physical* view
is loaded. Didn't show on sxlib because the buffer was fulled
loaded *before* running the ClockTree.
* Bug: In PyHurricane, in the various LocatorNextMethod() macros,
sometimes an empty collection can be returned by Hurricane
(GenericCollection()), which has a NULL locator. So check
if the locator is *not* NULL before trying to access it...
* Change: In Chip, more accurate error messages related to the clock
detecttion.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
- Change: In PyHurricane, add type object for all subtype of Component, then
we can use the Python "isinstance()" function to know the true type of a
component. Useful when looping over a collection of Component.
Name clash: We have used the class name as the name of the constructor
inside the Hurricane module, at a time we where less acquainted with
Python, so the real class are named 'PyVertical' for example, while
'Hurricane' is the constructor function. Should correct this in the
future but it's a huge work as all the Python scripts must be editeds...
- Change: In PyNet, adds the "getComponents()" Collection accessor.
- New: In Occurrence, added method getCompactString() to display a more
compact version of the occurrence.
- New: PyQuery & PyQueryMask expose the Query classe. Only partially implemented,
and with the start of the template based interface disabled.
- A complete sweep of cleanup to suppress allmost all compiler warnings.
* ./hurricane/doc/hurricane:
- New: Documentation cleanup and update, particularly on the new Layer
derived classes.
* ./hurricane/src/hurricane,
./hurricane/src/isobar,
./hurricane/src/viewer:
- New: Creation of new methods, more explicit on DbU. Based on a to/from
naming scheme.
- New: Python support extented to include all objects needed to configure
through python scripts.
- Change: Finally understood what's causing the _XOPEN_SOURCE redefinition.
Basically the Python.h must be included first before any other
include. The type-puned problem will remains still (that is a Python
problem, not our own).
- Change: In DisplayStyle, uses shared_ptr for DrawingStyle instead of
custom made reference count.
I rewrited everything like it was in Coriolis-1 (PyType_create) and reuse the precedent hierarchical system (PyTypeInheritedObjectDefinition)
With all these changes Pharos is able to run the same script several times without any error (and not only 7 times before crash)
Maybe there are still some bugs but it seems ok for the moment :D.
Jean-Paul Chaput
Damien Dupuis