* New: In Katana::TrackCost, the TrackElement and it's optional
symmetric are now kept as attribute of a TrackCost. The cost
is completly computed inside the constructor.
TrackCost now support any mix of symmetric event and wide
segments.
The cost is now computed by adding directly to the current
one instead of creating secondaries that are merged afterwards.
As a consequence, remove all copy construction and merge
capabilities.
All the various methods used to compute the cost are renamed
"addOverlapcost()" in all the various related objects.
As a reminder, the overal cost method call is as follow:
1. TrackCost constructor on a TrackElement.
2. Call TrackElement::addOverlapcost()
3. For all Track under the TrackElement, call
Track::addOverlapCost()
4. For all other TrackElement intersecting with
the overlap interval call:
TrackElement::incOverlapCost()
5. The callback overlap function for segments
is called (defined in NegociateWidow).
Don't confuse:
- TrackElement::addOverlapCost(), which compute the cost of
inserting the segment inside a track (or a set of).
- TrackElement::incOverlapCost(), which compute the cost of
overlaping with this already inserted segment. It is the
other way around of the previous one.
* Change: In Katana::SegmentFsm, use a vector of pointer to TrackCost
instead of an object to avoid copy construction.
* Change: In all top CMakeLists.txt, force the use of Python 2.7 as
we do not compile against 3.x flavors. Do not use the "EXACT"
flags as it will not recognize 2.7.x versions.
* Change: In Katana::RoutingEvent::Key::Compare(), preliminary
experiments shows that the best sorting order is:
- Lower layer first (i.e. M2 -> M3 -> M4 -> ... )
- Longer segments first.
The later seems to be counter-intuitive. Guess is that placing
the small ones first generate a more important fragmentation of
the big ones. They are placed too early and are difficult to move
afterwards.
Another feature to test is *not* inserting pushed left/right
segments if they are not *already* routed.
* Change: In PyKatanaEngine.runNegociate() now takes a flag argument,
provided through the new PyKatanaFlags exported object.
(doChip.py must be changed accordingly)
* Change: In Hurricane::BaseFlags, store flags in uint64_t instead of
unsigned int because we start to need more than 32 different flags
in some tools.
* New: In ::getString() & ::getRecord() templates, add support for
std::array<>.
* Change: In CRL::ToolEngine, add support for timer (time & memory
measurements) displaced from Katabatic. This way all ToolEngine
can use this feature. The _postCreate() method display the
memory just after ToolEngine allocation.
* Change: In Etesian::EtesianEngine, make use of the ToolEngine
builtin timer (remove the local one). Forgot to call the base
class _postCreate() and _preDestroy().
* Change: In Anabatic::AnabaticEngine, make use of the ToolEngine
builtin timer (remove the local one).
* New: In Anabatic, new AutoSegments_Connecteds() collection. This
Collection allows a deterministic walkthough *all* the AutoSegments
connected either to source or target of one AutoSegment.
* New: In Anabatic::AutoContactTerminal::isEndPoint() to check if an
AutoContactTerminal is the *only one* anchored on a RoutingPad,
thus being a true "end point" and not a kind of feed-through.
* New: In Katana::KatanaEngine, added support for symmetric nets.
Created new class DataSymmetric to store symmetric information
of a net (mainly the paired AutoSegments).
Added KatanaEngine::runSymmetricRouter(), for now only build
the DataSymmetric informations. More to come...
* Change: In Katana::GraphicKatanaEngine::_runTest(), now perform
symmetric information building the non-symmetric routing.
* Bug: In Hurricane, in StaticObservable::getObserver(), if the slot
pointer is NULL, do not try to access the owner. Returns NULL, so
the caller can be aware of the situation...
* Change: In Hurricane, in BreakpointWidget & ExceptionWidget some
cosmetic changes (fonts and window sizes).
* Bug: In Anabatic, In AutoHorizontal::getConstraints(), take into account
the constraints from the source AutoContact, as it holds the constraints
transmitted by the RoutingPads and sets up by propageConstraintsFromRp().
It is likely to be a bug affecting the original Katabatic as well.
* Change: In Anabatic, in RawGCellsUnder(), check that the segment is not
completly oustside the cell abutment box and truncate the coordinates
to the part that is inside. Use the "shrink" if we reach the east/north
border.
* Change: In Anabatic, in Configuration, no more decorator because we will
use a true derived relationship. Katana *derives* from *Anabatic* and do
not *decorate* it, so the Configuration can do the same. It also implies
that we directly create a Katana engine, not an Anabatic one.
* Change: In Anabatic, in Session, do not allow the opening of the Session
in a standalone fashion (with a static method). Instead it must be opened
using the relevant method of the Anabatic/Katana engine. This ensure we
are opening the right Session type.
* Change: In Anabatic, in AutoSegment_Aligneds() collection the seed segment
is not part of the collection by default, but will be included if the
Flags::WithSelf is set.
* Change: In Configuration, all the flags value are now defined in two steps.
Declared in the header and initialized in the module. This is to prevent
the fact that on some cases, in relation with the Python "extern C" part
modules, we need a true allocated variable. It was causing weird linking
problems.
A side effect is that they can no longer be used as entry is switches,
have to replace them by if/else.
* New: In Anabatic, new GCell::getNeighborAt() utility function.
* Bug: In Anabatic, in GCell::doGrid(), tag all the GCells of the grid with
the grid type... Back annote all the edges capacity (north & east) with
the reserved local capacity.
* New: Complete portage of Kite over Anabatic. The new engine is christened
"Katana" for Kite-Analogic. When it's capabilities and performances
will be on a part with Kite, it is to completly replace it (and take
back the "Kite" name). Preliminary tests seems to show that, contrary
to intuition (because built on a more complex/slower grid), it is even
slightly faster than Kite 8-).
Jean-Paul Chaput