nero/src/MDefs.h,
nero/src/RMBK.cpp :
- Ajout d'une prise en compte limitee du pre-routage. Ceci implique de
pouvoir fusionner deux CTerm au cours de la construction d'un CNet.
D'ou l'introduction d'une nouvelle exception "merge_term" qui est
relachee par "CNet::newaccess()" pour etre attrapee par
"CNet::newaccess()".
nero/src/AAstar.cpp,
nero/src/ADefs.h,
nero/src/MNet.h,
nero/src/MPri.h,
nero/src/MDRGrid.cpp,
nero/src/MDefs.h,
nero/src/RBox.cpp,
nero/src/RMBK.cpp,
nero/src/RDefs.cpp,
nero/src/nero.cpp :
- Ajout d'un "serial" (affiche) pour que l'utilisateur puisse savoir
simplement quant le programme a ete reinstalle (a numero de version
invariant). Suggestion Patricia.
- Bug : CAStar::CNodeASSet::reset() : lorsqu'exactement 4097 elements
CNodeAS etaient utilises, le reset ne reinitialisait pas le
4097 ieme (index := 4096). Ce qui explique les "coredumps"
residuels (mort aux modulos !).
- Bug : pour les ALU superieurs ou egaux a 5, respecter la distance
minimale bab de 8 n'oblige pas seulement a invalider une piste
sur deux, mais aussi a controler qu'au sein d'une meme piste
deux segments consecutifs respectent cet espacement. On implemente
cet effet dans "CAStar::CNodeAS::successors()" et
"CAStar::backtrack()".
- Modification : ajout d'un membre "zupper" a CDRGrid qui contient
l'index "z" a partir duquel on passe en double pitch. Actuellement
il n'est pas modifiable depuis la ligne de commande de nero.
On rend se membre accessible au travers des iterateurs de
CDRGrid : membre "::zupper()" (remarque : il faudra generaliser
l'acces aux membres de la matrice au travers de l'iterateur,
c'est pratique).
- Modification : CTerm::lockalone() : quant "zupper" vaut 4 (ALU5)
on ajoute un "dog leg vertical" aux terminaux n'ayant qu'un acces
pour que la transition vers le double pitch se passe bien.
Symptome : si cette ce deport n'est pas fait, l'Hadamard ne
converge pas (boucle du routage global sur "init", "c2i" et
??)
- Modification : CRBox::mbksave() : nouvelle facon de sauvegarder
les VIAs : au lieu de balayer la matrice puis de faire une boucle
verticale pour chercher les VIAs on balaye piste par piste dans
la direction prerentielle de routage. Ceci permet d'eviter qu'a
l'interface 1pitch / 2pitch on ne mette deux VIAs sur des pitchs
successifs (cas des segments superposes d'un meme signal en
train de s'ajuster au nouveau pitch).
- Bug : ne pas refaire systematiquement l'autostuff (on ne le regenere
que si le $TOOL/Makefile.in dans alliance/src n'est pas present).
De plus on s'arrange pour que le configure, genere par autostuff
le soit toujours sous Linux. De cette facon les scripts libtool
sont genere sous Linux avec la version 1.4 et ne sont pas
recrees sous Solaris (qui utilise la version 1.3 incompatible).
Ceci resout les curieuses differences a l'edition de lien qui
apparaissaient entre Linux & Solaris.
Simptome d'un configure genere sous Solaris : il se plaint de
ne pas trouver le fichier "ltconfig" dans la racine et plante
sur la configuration de libtool. Pour resoudre le probleme :
regenerer le configure sous Linux (avec autostuff).
- Dans les section "%files" j'ai oublie les ".conf" : i.e. le fichier
de configuration d'attila (donc les RPMs distribues n'ont pas un
attila operationnel, mais ca ne derange que les developpeurs).
attila/src/MDefs.h,
attila/src/MNet.cpp,
attila/src/MPri.cpp,
attila/src/RMBK.cpp :
- Bug : la modification pour router les RAMs (segments de taille nulle)
a introduit un bug : pleins de petits segments de taille nulle
apparaissaient superposes aux segments normaux. C'etait produit
par le balayage dans la direction perpendiculaire a la direction
preferentielle quant elle rencontrait un segment.
Conclusion : pour l'instant on ne peut pas router une RAM seule.
- Bug : dans "::newaccess()" je ne verifiait pas si le noeud etait
deja pris par un autre signal. J'espere que c'est ce qui provo-
quait les SIGABRT (du a un auto-ecrasement du programme...)
- Bug : Et les VIAs patate ! Prise en compte des VIAs des alimentations
et transformation en obstacles.
- L'espacement des pistes de routage ALU5 et superieures est
desormait de 2 pitchs (10 lambdas) pour faire plaisir a druc.
- Quant on utilise une librairie dynamique qui est genere a l'interieur
d'un outil, il faut utiliser le "-libCst.la" au lieu de "-lCst"
avec libtool (j'en suis pas super sur, mais ca a le merite de
marcher...)
- Reorganisation de la facon dont les chemins d'acces aux librairies
aux includes Alliance sont founis aux configure.in/Makefile.am.
Jusqu'a present ils etaient fournis par l'intermediaires des
variables ALLIANCE_CFLAGS et ALLIANCE_LIBS qui etaient ensuite
substituees dans les Makefile.in par configure. De plus il
fallait explicitement les ajouter dans AM_CFLAGS et _LDADD
(Makefile.am). On avait donc le parcourt suivant :
alliance.m4 : ALLIANCE_INCLUDE + AC_SUBST
Makefile.am : AM_CFLAGS
Maintenant, dans le alliance.m4, ALLIANCE_INCLUDE est ajoute a
CFLAGS et ALLIANCE_LIB a LDFLAGS. De cette facon, tous les
programmes auront ces chemins systematiquement positionnes par
defaut (les @ALLIANCE_INCLUDE@ et @ALLIANCE_LIB@ disparaissent
des Makefile.am)
- Nouveaux switchs pour configure : --enable-devel et
--enable-alc-shared. Comme ils sont ajoutes dans le alliance.m4,
ils seront present automatiquement dans les configures des
outils sans que les configure.in de ceux ci aie a etre
modifies.
- Utilisation des libraries locales de l'utilisateur : un nouveau
switch a ete ajoute a configure (toujours avec une macro dans
alliance.m4) : --enable-devel.
Quant il est present, il intercale dans CFLAGS et LDFLAGS les
chemins d'acces aux librairies developpees localement par
l'utilisateur. Exemple typique : utiliser une version locale
de MBK.
- Activation des libraries dynamiques : switch --enable-alc-shared
de configure. Si ce switch est present, le makefile tentera
d'utiliser les versions dynamiques des librairies. Par defaut
ce sont les versions statiques qui seront utilisees (comme
auparavant).
- Generation de librairies dynamiques : AC_PROG_LIBTOOL est inclu
automatiquement par alliance.m4, il n'est donc pas necessaire
de le remettre dans le configure.in des outils (mais ce ne
genera pas). En revanche, il faut supprimmer la macro
AC_PROG_RANLIB.
* mbk/src/Makefile.am :
- Passage en librairies dynamiques.
* attila/src/attila.sh,
attila/doc/man_attila.sgm :
- Changement de syntaxe de la ligne de commande. On peut maintenant
passer n'importe quels arguments a configure et a make par
le biais de "-c-" et "-m".
- Reorganisation de la facon dont les chemins d'acces aux librairies
aux includes Alliance sont founis aux configure.in/Makefile.am.
Jusqu'a present ils etaient fournis par l'intermediaires des
variables ALLIANCE_CFLAGS et ALLIANCE_LIBS qui etaient ensuite
substituees dans les Makefile.in par configure. De plus il
fallait explicitement les ajouter dans AM_CFLAGS et _LDADD
(Makefile.am). On avait donc le parcourt suivant :
alliance.m4 : ALLIANCE_INCLUDE + AC_SUBST
Makefile.am : AM_CFLAGS
Maintenant, dans le alliance.m4, ALLIANCE_INCLUDE est ajoute a
CFLAGS et ALLIANCE_LIB a LDFLAGS. De cette facon, tous les
programmes auront ces chemins systematiquement positionnes par
defaut (les @ALLIANCE_INCLUDE@ et @ALLIANCE_LIB@ disparaissent
des Makefile.am)
- Nouveaux switchs pour configure : --enable-devel et
--enable-alc-shared. Comme ils sont ajoutes dans le alliance.m4,
ils seront present automatiquement dans les configures des
outils sans que les configure.in de ceux ci aie a etre
modifies.
- Utilisation des libraries locales de l'utilisateur : un nouveau
switch a ete ajoute a configure (toujours avec une macro dans
alliance.m4) : --enable-devel.
Quant il est present, il intercale dans CFLAGS et LDFLAGS les
chemins d'acces aux librairies developpees localement par
l'utilisateur. Exemple typique : utiliser une version locale
de MBK.
- Activation des libraries dynamiques : switch --enable-alc-shared
de configure. Si ce switch est present, le makefile tentera
d'utiliser les versions dynamiques des librairies. Par defaut
ce sont les versions statiques qui seront utilisees (comme
auparavant).
- Generation de librairies dynamiques : AC_PROG_LIBTOOL est inclu
automatiquement par alliance.m4, il n'est donc pas necessaire
de le remettre dans le configure.in des outils (mais ce ne
genera pas). En revanche, il faut supprimmer la macro
AC_PROG_RANLIB.
* mbk/src/Makefile.am :
- Passage en librairies dynamiques.
* attila/src/attila.sh,
attila/doc/man_attila.sgm :
- Changement de syntaxe de la ligne de commande. On peut maintenant
passer n'importe quels arguments a configure et a make par
le biais de "-c-" et "-m".
- Fichier inutile faisant partie d'une vieille implementation.
A detruire tout de suite.
* nero/src/MPri.cpp,
nero/src/AAstar.cpp,
nero/src/RMBK.cpp :
- Bug (suite) : contrecoup de la modification faite pour les RAMs :
le test de blocage d'un terminal (dans la phase de routage global)
etait faux. Il detectait les obstacles mais pas si un AUTRE
connecteur etait au dessus.
- Bug : dans CMatrixPri::findfree(), lorsqu'on atteignait le bord du
circuit, on se considerait libere, ce qui n'etait pas le cas.
Maintenant on detecte si on sort (coord.outside()).
- Bug : Les segments etaient nommes a partir des noms de signaux.
Dans le cas des connecteurs, il faut les nommer a partir du
connecteur (generalement, ils sont identiques, ce qui explique
cette detection tardive.
nero/src/UConst.cpp,
nero/src/ADefs.h,
nero/src/AAstar.cpp,
nero/src/nero.cpp :
- Bug : J'autorisait 6 niveaux de routage dans la grille (donc, comme
l'ALU1 ne compte pas, jusqu'a l'ALU7) mais je n'avais parametre
les fonctions de traduction vers MBK que jusqu'a l'ALU6.
- Bug : quant un bug (une exception) se produisait dans la fonction
de sauvegarde "emergency()" il n'etait pas catche et provoquait
un coredump de mauvais aloi. Maintenant il les erreurs sont
re-catchee et la sauvegarde est interrompue.
- La non-convergence de l'algorithme ASimple/AAstar est detectee :
quant la priorite sur un net depasse la valeur max (2^7), on
arrete tout...
- Bug : on n'assurait pas l'exclusivite terminal/obstacle (un
terminal pouvait etre un obstacle). Ceci avait l'inconvenient
d'autoriser des noeuds a la fois connecteurs et obstacles.
Consequence : comme lors de l'examen des successeurs d'un
noeud on regarde d'abord si on a affaire a un obstacle, certains
connecteurs ne pouvaient jamais etre ateint (cas d'un connecteur
CALU2 noye dans du TALU2 dans les RAMs).
Maintenant l'exclusivite est garantie (un obstacle ne peut
inclure de terminal et un terminal desactive obligatoirement
l'obstacle).
- Bug/2 : Je n'autorisait pas les segments de longueur nulle, or
ca existe : connecteur "ad3" de la cellule "sensedecad".
Christophe Alexandre
Jean-Paul Chaput