- Change: In ToolEngine, adds a static method "destroyAll()" that must be
called *before* the Hurricane database destruction. This is to avoid
a mis-oredering in destruction.
ToolEngines are stored in a property, property are part of the DBo
base object so are destroyed *after* the Cell derived object has been.
Thus ToolEngine are deleted *after* the Cell components and if they
still refers to it, we are doomed.
- Change: In display.xml, color support for displaying references.
Name, Rule, Arule and Techno objects has been ported, so it is possible to read a dtr xml file from disk to get a techno and then rules' values.
DTRException object still need to be ported.
Since there is a new project that need to parse DTR xml file we've decided to set a standalone parser.
This parser will be extended with a python API (I'm gonna have a look at boost ^^)
- New: In Query, add support for Markers, although they are Go's, are stored
in a separate QuadTree directly at Cell level. In a very similar fashion
to the ExtensionGos. Sometimes should look if thoses mecanism could be
unified.
* ./hurricane/src/viewer:
- New: In CellWidget, add support for displaying References. Uses the Marker
Query. For now labels are displayed centered on the reference point,
making that point hard to see. That behavior may be changed later if
needs to be.
- Bug: In InspectorWidget, the History::push() wasn't updating the ComboBox
index. The line was strangely commented out (?).
- Bug: In buildCoriolis.py, when multiple projects where given on the command
line, only the latest was processed. Now all projects are processeds.
(in the order given on the command line so watch out!)
- Cleanup: In GCell, remove the DyKeyQueue support as it's been moved
to Katabatic level.
- Change: In NegociateWidow, increase the event stop thresold to 4M events
to be able to process the eFPGA matrix 16x16 (150K gates).
- Change: In Cyclop, now uses the GtkStyle when not under OSX and Qt is
newer or equal to Qt 4.5.0.
- Change: In the various Qt Model Table, do the rowHeigh bug correction.
- Bug: In InspectorWidget/NetlistModel, when browsing through the records
tree, the records were generated twice at each slot change. This
was due to the History ComboBox sending a index change signal then
the InspectorWidget setting the slot *again*.
When trying to explore a Slot, but this Slot is empty (like an
empty vector, for instance) do not gut the RecordModel. Because
as we find out that the new Slot is empty we go back and restore
the previous contents. Potentially slow if we comes from a Slot
with lots of records. Now we dump the contents only if there is
something to explore.
* ./hurricane/src/hurricane:
- Bug: In Record, the slots where stored in a list container, which was
making indexed accesses very very slow. This slowdown was also
affecting the destructor of Record (this is the explanation why
the RecordWidget was slow, even when *leaving* the net IntrusiveSet).
Now implemented in term of STL vector.
- Bug: In Slot/Common, still some adjustements to make the Inspection
mechanism work with all types. Correct the "IntrusiveMap<>" not
working with the NetMap. Related to templates not using the same
constness.
- Change: In Entity/DBo/Cell, Some more adjustements on Slot/Records.
- Bug: In buildCoriolis.py, io tool was both declared as belonging to io
and hurricane project. Removed from Hurricane.
- Bug: In buildCoriolis.py, exctract correctly the return status of a
command to return it to the parent process. See Python documentation
about os.wait() & os.waitpid().
- Bug: In NetlistWidget/NetlistModel, suppress the "forceRowHeight()"
method which was terribly slowing down the table display. Instead
uses the "setDefaultSectionSize()" of the vertical header to setup
the row height (much more compact display).
- Bug: In NetlistModel, strangely, although we have a "data()" and a
"headerData()" method, the "data()" is also called for the headers
potentially erasing any previous setting done with "headerData()".
This was occuring for the fonts settings. Don't known if it is
a bug or a feature of Qt...
- Thoses changes has to be ported to the others widgets some times...
- Change: Uses a map instead of a sorted vector in the layer assignment
steps. It was used to order GCells by density, and causing terrific
slowdown on big examples. Namely the eFPGA 16x16 took 1h20, now it's
down to 21 seconds...
Devellop a new object <DyKeyQueue> to handle map with elements
whose key *can* change. Next step is to normalize the key caching
mechanism and to templatize.
- Change: In LayerAssign, account the number of globals AutoSegments
moved up.
- Change: In builCoriolis.py, expand the '~' in the root path if needed.
- Bug: Do not stop if the "--no-cache" option is given but the
CMakeCache doesn't exists.
- Change: <PROJECT>_SEARCH_PATH are put back into the *first* tool of
a project.
- Bug: In HURRICANE_CHECK_MACRO(), the quiet flag was not correctly
implemented. User ARGV instead of argv (case sensitivity!).
- Change: <PROJECT>_SEARCH_PATH are put back into the *first* tool of
a project.
- Bug: In HURRICANE_CHECK_MACRO(), the quiet flag was not correctly
implemented. User ARGV instead of argv (case sensitivity!).
- Change: <PROJECT>_SEARCH_PATH are put back into the *first* tool of
a project.
- Bug: In HURRICANE_CHECK_MACRO(), the quiet flag was not correctly
implemented. User ARGV instead of argv (case sensitivity!).
- Change: <PROJECT>_SEARCH_PATH are put back into the *first* tool of
a project.
- Bug: In HURRICANE_CHECK_MACRO(), the quiet flag was not correctly
implemented. User ARGV instead of argv (case sensitivity!).
- Change: <PROJECT>_SEARCH_PATH are put back into the *first* tool of
a project.
- Bug: In HURRICANE_CHECK_MACRO(), the quiet flag was not correctly
implemented. User ARGV instead of argv (case sensitivity!).
- Change: <PROJECT>_SEARCH_PATH are put back into the *first* tool of
a project.
- Bug: In HURRICANE_CHECK_MACRO(), the quiet flag was not correctly
implemented. User ARGV instead of argv (case sensitivity!).
- Change: <PROJECT>_SEARCH_PATH are put back into the *first* tool of
a project.
- Bug: In HURRICANE_CHECK_MACRO(), the quiet flag was not correctly
implemented. User ARGV instead of argv (case sensitivity!).
- Change: <PROJECT>_SEARCH_PATH are put back into the *first* tool of
a project.
- Bug: In HURRICANE_CHECK_MACRO(), the quiet flag was not correctly
implemented. User ARGV instead of argv (case sensitivity!).
- Change: <PROJECT>_SEARCH_PATH are put back into the *first* tool of
a project.
- Bug: In HURRICANE_CHECK_MACRO(), the quiet flag was not correctly
implemented. User ARGV instead of argv (case sensitivity!).
- Change: <PROJECT>_SEARCH_PATH are put back into the *first* tool of
a project.
- Bug: In HURRICANE_CHECK_MACRO(), the quiet flag was not correctly
implemented. User ARGV instead of argv (case sensitivity!).
- Change: <PROJECT>_SEARCH_PATH are put back into the *first* tool of
a project.
- Bug: In HURRICANE_CHECK_MACRO(), the quiet flag was not correctly
implemented. User ARGV instead of argv (case sensitivity!).
- Change: New structure for the installation & CMake system.
* Tools are now grouped in "projects". There are three projects:
1. - IO: Standalones parsers/drivers (IO_USER_TOP, IO_TOP).
2. - Coriolis: Base & digital tools (CORIOLIS_USER_TOP, CORIOLIS_TOP).
3. - Chams: Analogic tools (CHAMS_USER_TOP, CHAMS_TOP).
Each *project* has a two "TOP" environement variables, for
example: IO_TOP and IO_USER_TOP. Thoses variables are the only
ones useds to locate the tool (CMake modules, headers & libraries).
The local path always takes precedence over the global one.
The localisation process occurs in each tool top CMakeLists.txt
where the macro SETUP_PROJECT_PATH is to be defined. There is no
way to put it in a shared includes file as it's the macro precisely
used to locates the includes... You have to call the macro once for
each project you wants to uses:
SETUP_PROJECT_PATHS(IO)
SETUP_PROJECT_PATHS(CORIOLIS)
* In FindTOOL.cmake, supress the <TOOL>_DIR_SEARCH and uses the
<PROJECT>_DIR_SEARCH instead (example: CORIOLIS_DIR_SEARCH).
* buildCoriolis.py modificated according to the new "TOP" scheme.
- Change: New structure for the installation & CMake system.
* Tools are now grouped in "projects". There are three projects:
1. - IO: Standalones parsers/drivers (IO_USER_TOP, IO_TOP).
2. - Coriolis: Base & digital tools (CORIOLIS_USER_TOP, CORIOLIS_TOP).
3. - Chams: Analogic tools (CHAMS_USER_TOP, CHAMS_TOP).
Each *project* has a two "TOP" environement variables, for
example: IO_TOP and IO_USER_TOP. Thoses variables are the only
ones useds to locate the tool (CMake modules, headers & libraries).
The local path always takes precedence over the global one.
The localisation process occurs in each tool top CMakeLists.txt
where the macro SETUP_PROJECT_PATH is to be defined. There is no
way to put it in a shared includes file as it's the macro precisely
used to locates the includes... You have to call the macro once for
each project you wants to uses:
SETUP_PROJECT_PATHS(IO)
SETUP_PROJECT_PATHS(CORIOLIS)
* In FindTOOL.cmake, supress the <TOOL>_DIR_SEARCH and uses the
<PROJECT>_DIR_SEARCH instead (example: CORIOLIS_DIR_SEARCH).
* buildCoriolis.py modificated according to the new "TOP" scheme.
- Change: New structure for the installation & CMake system.
* Tools are now grouped in "projects". There are three projects:
1. - IO: Standalones parsers/drivers (IO_USER_TOP, IO_TOP).
2. - Coriolis: Base & digital tools (CORIOLIS_USER_TOP, CORIOLIS_TOP).
3. - Chams: Analogic tools (CHAMS_USER_TOP, CHAMS_TOP).
Each *project* has a two "TOP" environement variables, for
example: IO_TOP and IO_USER_TOP. Thoses variables are the only
ones useds to locate the tool (CMake modules, headers & libraries).
The local path always takes precedence over the global one.
The localisation process occurs in each tool top CMakeLists.txt
where the macro SETUP_PROJECT_PATH is to be defined. There is no
way to put it in a shared includes file as it's the macro precisely
used to locates the includes... You have to call the macro once for
each project you wants to uses:
SETUP_PROJECT_PATHS(IO)
SETUP_PROJECT_PATHS(CORIOLIS)
* In FindTOOL.cmake, supress the <TOOL>_DIR_SEARCH and uses the
<PROJECT>_DIR_SEARCH instead (example: CORIOLIS_DIR_SEARCH).
* buildCoriolis.py modificated according to the new "TOP" scheme.
- Change: New structure for the installation & CMake system.
* Tools are now grouped in "projects". There are three projects:
1. - IO: Standalones parsers/drivers (IO_USER_TOP, IO_TOP).
2. - Coriolis: Base & digital tools (CORIOLIS_USER_TOP, CORIOLIS_TOP).
3. - Chams: Analogic tools (CHAMS_USER_TOP, CHAMS_TOP).
Each *project* has a two "TOP" environement variables, for
example: IO_TOP and IO_USER_TOP. Thoses variables are the only
ones useds to locate the tool (CMake modules, headers & libraries).
The local path always takes precedence over the global one.
The localisation process occurs in each tool top CMakeLists.txt
where the macro SETUP_PROJECT_PATH is to be defined. There is no
way to put it in a shared includes file as it's the macro precisely
used to locates the includes... You have to call the macro once for
each project you wants to uses:
SETUP_PROJECT_PATHS(IO)
SETUP_PROJECT_PATHS(CORIOLIS)
* In FindTOOL.cmake, supress the <TOOL>_DIR_SEARCH and uses the
<PROJECT>_DIR_SEARCH instead (example: CORIOLIS_DIR_SEARCH).
* buildCoriolis.py modificated according to the new "TOP" scheme.
- Change: New structure for the installation & CMake system.
* Tools are now grouped in "projects". There are three projects:
1. - IO: Standalones parsers/drivers (IO_USER_TOP, IO_TOP).
2. - Coriolis: Base & digital tools (CORIOLIS_USER_TOP, CORIOLIS_TOP).
3. - Chams: Analogic tools (CHAMS_USER_TOP, CHAMS_TOP).
Each *project* has a two "TOP" environement variables, for
example: IO_TOP and IO_USER_TOP. Thoses variables are the only
ones useds to locate the tool (CMake modules, headers & libraries).
The local path always takes precedence over the global one.
The localisation process occurs in each tool top CMakeLists.txt
where the macro SETUP_PROJECT_PATH is to be defined. There is no
way to put it in a shared includes file as it's the macro precisely
used to locates the includes... You have to call the macro once for
each project you wants to uses:
SETUP_PROJECT_PATHS(IO)
SETUP_PROJECT_PATHS(CORIOLIS)
* In FindTOOL.cmake, supress the <TOOL>_DIR_SEARCH and uses the
<PROJECT>_DIR_SEARCH instead (example: CORIOLIS_DIR_SEARCH).
* buildCoriolis.py modificated according to the new "TOP" scheme.
- Change: New structure for the installation & CMake system.
* Tools are now grouped in "projects". There are three projects:
1. - IO: Standalones parsers/drivers (IO_USER_TOP, IO_TOP).
2. - Coriolis: Base & digital tools (CORIOLIS_USER_TOP, CORIOLIS_TOP).
3. - Chams: Analogic tools (CHAMS_USER_TOP, CHAMS_TOP).
Each *project* has a two "TOP" environement variables, for
example: IO_TOP and IO_USER_TOP. Thoses variables are the only
ones useds to locate the tool (CMake modules, headers & libraries).
The local path always takes precedence over the global one.
The localisation process occurs in each tool top CMakeLists.txt
where the macro SETUP_PROJECT_PATH is to be defined. There is no
way to put it in a shared includes file as it's the macro precisely
used to locates the includes... You have to call the macro once for
each project you wants to uses:
SETUP_PROJECT_PATHS(IO)
SETUP_PROJECT_PATHS(CORIOLIS)
* In FindTOOL.cmake, supress the <TOOL>_DIR_SEARCH and uses the
<PROJECT>_DIR_SEARCH instead (example: CORIOLIS_DIR_SEARCH).
* buildCoriolis.py modificated according to the new "TOP" scheme.
- Change: New structure for the installation & CMake system.
* Tools are now grouped in "projects". There are three projects:
1. - IO: Standalones parsers/drivers (IO_USER_TOP, IO_TOP).
2. - Coriolis: Base & digital tools (CORIOLIS_USER_TOP, CORIOLIS_TOP).
3. - Chams: Analogic tools (CHAMS_USER_TOP, CHAMS_TOP).
Each *project* has a two "TOP" environement variables, for
example: IO_TOP and IO_USER_TOP. Thoses variables are the only
ones useds to locate the tool (CMake modules, headers & libraries).
The local path always takes precedence over the global one.
The localisation process occurs in each tool top CMakeLists.txt
where the macro SETUP_PROJECT_PATH is to be defined. There is no
way to put it in a shared includes file as it's the macro precisely
used to locates the includes... You have to call the macro once for
each project you wants to uses:
SETUP_PROJECT_PATHS(IO)
SETUP_PROJECT_PATHS(CORIOLIS)
* In FindTOOL.cmake, supress the <TOOL>_DIR_SEARCH and uses the
<PROJECT>_DIR_SEARCH instead (example: CORIOLIS_DIR_SEARCH).
* buildCoriolis.py modificated according to the new "TOP" scheme.
- Change: New structure for the installation & CMake system.
* Tools are now grouped in "projects". There are three projects:
1. - IO: Standalones parsers/drivers (IO_USER_TOP, IO_TOP).
2. - Coriolis: Base & digital tools (CORIOLIS_USER_TOP, CORIOLIS_TOP).
3. - Chams: Analogic tools (CHAMS_USER_TOP, CHAMS_TOP).
Each *project* has a two "TOP" environement variables, for
example: IO_TOP and IO_USER_TOP. Thoses variables are the only
ones useds to locate the tool (CMake modules, headers & libraries).
The local path always takes precedence over the global one.
The localisation process occurs in each tool top CMakeLists.txt
where the macro SETUP_PROJECT_PATH is to be defined. There is no
way to put it in a shared includes file as it's the macro precisely
used to locates the includes... You have to call the macro once for
each project you wants to uses:
SETUP_PROJECT_PATHS(IO)
SETUP_PROJECT_PATHS(CORIOLIS)
* In FindTOOL.cmake, supress the <TOOL>_DIR_SEARCH and uses the
<PROJECT>_DIR_SEARCH instead (example: CORIOLIS_DIR_SEARCH).
* buildCoriolis.py modificated according to the new "TOP" scheme.
- Change: New structure for the installation & CMake system.
* Tools are now grouped in "projects". There are three projects:
1. - IO: Standalones parsers/drivers (IO_USER_TOP, IO_TOP).
2. - Coriolis: Base & digital tools (CORIOLIS_USER_TOP, CORIOLIS_TOP).
3. - Chams: Analogic tools (CHAMS_USER_TOP, CHAMS_TOP).
Each *project* has a two "TOP" environement variables, for
example: IO_TOP and IO_USER_TOP. Thoses variables are the only
ones useds to locate the tool (CMake modules, headers & libraries).
The local path always takes precedence over the global one.
The localisation process occurs in each tool top CMakeLists.txt
where the macro SETUP_PROJECT_PATH is to be defined. There is no
way to put it in a shared includes file as it's the macro precisely
used to locates the includes... You have to call the macro once for
each project you wants to uses:
SETUP_PROJECT_PATHS(IO)
SETUP_PROJECT_PATHS(CORIOLIS)
* In FindTOOL.cmake, supress the <TOOL>_DIR_SEARCH and uses the
<PROJECT>_DIR_SEARCH instead (example: CORIOLIS_DIR_SEARCH).
* buildCoriolis.py modificated according to the new "TOP" scheme.
- Change: New structure for the installation & CMake system.
* Tools are now grouped in "projects". There are three projects:
1. - IO: Standalones parsers/drivers (IO_USER_TOP, IO_TOP).
2. - Coriolis: Base & digital tools (CORIOLIS_USER_TOP, CORIOLIS_TOP).
3. - Chams: Analogic tools (CHAMS_USER_TOP, CHAMS_TOP).
Each *project* has a two "TOP" environement variables, for
example: IO_TOP and IO_USER_TOP. Thoses variables are the only
ones useds to locate the tool (CMake modules, headers & libraries).
The local path always takes precedence over the global one.
The localisation process occurs in each tool top CMakeLists.txt
where the macro SETUP_PROJECT_PATH is to be defined. There is no
way to put it in a shared includes file as it's the macro precisely
used to locates the includes... You have to call the macro once for
each project you wants to uses:
SETUP_PROJECT_PATHS(IO)
SETUP_PROJECT_PATHS(CORIOLIS)
* In FindTOOL.cmake, supress the <TOOL>_DIR_SEARCH and uses the
<PROJECT>_DIR_SEARCH instead (example: CORIOLIS_DIR_SEARCH).
* buildCoriolis.py modificated according to the new "TOP" scheme.
Jean-Paul Chaput
Damien Dupuis
Ramy Iskander