AMS-Group Meeting 24.5.2006

Mécanique/Production:

Essayer d'utiliser le plan de maquette pour mettre ça dans le TAF (ex-Frankenstein)
mieux attendre le T-crate pour voir les détails (devrait arriver cette semaine)

Téléconf demain 10h pour l'organisation

Pour finir le plan 1, il faut laisser 'traîner' les échelles un peu dans les tiroirs pour
avoir l'option de finir avant fin juin.

Réparation: Devrait être fini cette semaine (hybrides etc.)

Electronique:

Test TDR Taiwan en préparation

Production de 2 TFS additionels pour test TV à Terni en route

DSP: Philipp a mesuré les temps d'execution. Sommaire dans son mail:

	From: 	  philipp.azzarello@cern.ch
	Subject: 	code 6426_01
	Date: 	May 31, 2006 8:58:10 AM GMT+02:00
	To: 	  Daniel.Haas@cern.ch, Claude.ZURBACH@LPTA.in2p3.fr, paolo.zuccon@pg.infn.it
	Cc: 	  Giovanni.Ambrosi@pg.infn.it

Salut à tous,

Désolé pour ce long mail, mais je crois que ça valait la peine de le faire...

Ces derniers jours nous avons pris des données avec le code 6426_01, une bonne part de l'exercice ayant été de modifier dans la mémoire du DSP la calibration (flags), afin de provoquer une division plutôt qu'un shift right, lors du calcul du CN. En décalant les piedestaux, il est aussi possible de provoquer des CN toujours positifs ou toujours négatifs, utiles pour comprendre le comportement de la division.

Et finalement, nous avons utilisé les points de test 32/33 du TDR, connecté au pin 87 du DSP. Le signal de ce pin est contrôlable par les commandes SET/RESET/TOGGLE FL0 dans le code du DSP, et est donc très utile pour mesurer les temps d'execution du code.

Suivent donc quelques résultats/remarques/obervations relatifs au code 6426_01, qui me semblent pour la plupart toujours valides pour le code 6426_02 que nous n'avons pas encore installé. Ce sera fait aujourd'hui.

Pour les amateurs de versions courtes:

1. Dans le calcul du CN, le canal 64 d'un VA est systématiquement exclu.

2. Le calcul du CN pour 32 canaux nécessite un calcul sur 33 canaux,
   le calcul du dernier canal étant "inutile", mais la première
   instruction de la boucle sert à effectuer la somme cumulée qui
   sera ensuite divisée pour obtenir le CN.

3. L'algoritme de la division réelle comporte deux erreurs:
   a. Au lieu d'additionner 33 avec le compteur (à rebours) de bons
      canaux, il faut soustraire ce compteur à la valeur 32.
   b. Le registre AY1 doit contenir la valeur du registre MR1
      (sans quoi la division des nombres négatifs ne fonctionne pas).

4. Dans un mode où tous les VAs fonctionnent en mode "shift right", le
   temps de réduction est d'env. 290 us. Si l'on force tous les VAs à
   faire la division, ce temps passe à env. 340 us. Le temps effectif
   pour faire une division est de 480 ns.

Si vous voulez en savoir plus... continuez la lecture.

A+,

   Philippe

ps. A l'heure actuelle les liens mentionnés plus bas ne fonctionnent plus... problème informatique local qui devrait se résoudre
rapidement (?)

Les observations qui suivent ont d'abord été faites en utilisant le système, sans connaître le fonctionnement "interne" du code lui-même. L'examen du code a été fait suite à ces observations...

J'aimerais revenir un peu dans le détail du calcul du CN, si vous
le voulez bien. La procédure de calcul se déroule ainsi (je l'écris dans
un style "C", Claude voudra bien m'excuser :-) ):

int chan=64; // channel reverse counter
int good=32; // good channels reverse counter
int CN=0;    // the CN computed for a VA
int r[64];   // adc-ped for the 64 channels of a VA
int val=0;   // adc-ped for the examined channel of a VA
do {
	CN=CN+val;
	chan=chan-1;
	if (chan<=0) break; // after 63 (!) channels we exit the loop
	if (status[chan]) continue; // if bad, skip the rest,
				    // go to next channel
	if (r[chan]-threshold_sigraw>=0) continue;
	if (r[chan]+threshold_sigraw<=0) continue;

	// here all tests were successful, we can take
	// the channel for CN calculation

	good=good-1;
	val=r[chan];
} while(good>=0);

// then follows the end of CN calculation...

if (good<0) do_shift_right(5);
else do_division(good);

// etc...

Le point intéressant ici est que dans la cas où tous les canaux sont bons, on passera 33 fois dans boucle, en raison du test (good>=0), mais que la somme pour le CN comprendra 32 valeurs, car cette dernière se construit en début de boucle: le 33ème passage est seulement nécessaire pour stocker la 32ème valeur...

Mais attention: pour valider complètement l'opération, il faut que tout
le passage de la boucle soit complet, c-à-d qu'il faut 33 *bons* canaux,
de sorte que le test

while(good>=0);

soit finalement validé, et que l'on sorte de la boucle. Donc on a compté
33 bons canaux, on a une valeur CN cumulée sur 32 canaux.

Un autre effet intéressant est que de par le test

if (chan<=0) break;

le canal 64 est toujours exclu du calcul, donc il est virtuellement
toujours mauvais. Et cela se voit:

Pour faire des essais sur la question du temps que prend une division,
j'ai modifié les status des canaux de sorte que les canaux de 1 à au
moins 32 soient >0. En particulier, le canal 64 est donc toujours bon.

La division réelle ne fonctionne pas encore très bien, surtout pour les CN négatifs. Donc, lorsque la division réelle est utilisée, on le voit dès qu'un CN négatif se produit. On observe cet effet lorsqu'il y a plus
que *30* mauvais canaux dans un VA. Exprimé différemment:

30 mauvais <-> 34 bons  ==> shift right de 5
31 mauvais <-> 33 bons  ==> division réelle

Je le répète, pour faire ces essais j'ai marqué 31 mauvais canaux en
partant du canal 1. En particulier, le canal 64 est "bon". Cependant, le
canal 64 est virtuellement toujours mauvais. Vu du DSP, la situation est
donc:

30 mauvais -> 31 mauvais DSP <-> 33 bons  ==> shift right de 5
                                              de la somme
31 mauvais -> 32 mauvais DSP <-> 32 bons  ==> division réelle
                                              de la somme

Revenons à notre comptage de bons canaux. On compte 33 bons canaux, on a un CN cumulé de 32 valeurs. Dans ce cas, pas de problèmes, le code gère ça correctement, le shift right se fait, donc une division par 32.

Prenons le cas limite pour lequel il y a 32 bons canaux, mais pas 33.
Alors, la somme cumulées est bien de 32, mais le compteur good est
bloqué à 0: il faut donc examiner tous les canaux du VA (à la recherche du 33ème bon). Une fois les 64 canaux du VA examinés, on sort de la boucle.

Ainsi le test:

if (good<0) do_shift_right(5);
else do_division(good);

va lancer une vraie division par 32 alors qu'il y a un cumul de 32
valeurs, et que le shift right serait donc possible.
Ceci explique donc le comportement observé.

Maintenant, passons à la division réelle.

Pour les valeurs de CN positives, on décale les piedestaux de -20 adcs, de sorte que le CN moyen soit de 20. Il faut aussi changer les seuils de sigma raw pour prendre en compte cet effet.

J'ai pris 10000 événements mixtes, de telle sorte que l'on puisse
comparer le CN DSP avec un CN offline.
Les VAs 1, 2, 5 et 6 étaient mode "division réelle". Le fit d'une
droite, de CN(DSP)=CN(RAW)*slope+intcpt donne le résultat suivant:

 VA= 1   intcpt=-0.062435   slope=0.667062
 VA= 2   intcpt=-0.074538   slope=0.667096
 VA= 3   intcpt=-0.066905   slope=1.000239
 VA= 4   intcpt=-0.053953   slope=1.000029
 VA= 5   intcpt=-0.041239   slope=0.709966
 VA= 6   intcpt=-0.069666   slope=0.805830
 VA= 7   intcpt=-0.070108   slope=0.999965
 VA= 8   intcpt=-0.059603   slope=1.000058
 VA= 9   intcpt=-0.050909   slope=0.999988
 VA=10   intcpt=-0.055742   slope=0.999856
 VA=11   intcpt=-0.066632   slope=0.999849
 VA=12   intcpt=-0.066359   slope=1.000018
 VA=13   intcpt=-0.046324   slope=1.000061
 VA=14   intcpt=-0.065005   slope=0.999984
 VA=15   intcpt=-0.059532   slope=1.000050
 VA=16   intcpt=-0.070574   slope=1.000047

Clairement, pour les VAs en mode shift right, l'accord est très bon,
nous confirmant par ailleurs que ce sont bien 32 valeurs qui sont prises
en compte (et pas 33).
Concentrons-nous sur les VAs en mode division:
 VA= 1   intcpt=-0.062435   slope=0.667062
 VA= 2   intcpt=-0.074538   slope=0.667096
 VA= 5   intcpt=-0.041239   slope=0.709966
 VA= 6   intcpt=-0.069666   slope=0.805830

Intéressons-nous donc à la division, dont j'écris les premières lignes,
en style "C":

int numerator=CN;
int denominator=33+good; // <-- !!!!!
divide(numerator, denominator);

Je ne vais pas plus loin. Il y a un problème avec l'expression du
dénominateur. Par contre, si je la considère un instant,
elle explique parfaitement les valeurs de pente que j'observe.
Notez que la variable good vaut 32-bons_canaux_dsp

VA   bons    bons(DSP)   good   denominator
1     27        26         6       39
2     27        26         6       39
5     28        27         5       38
6     30        29         3       36

Le CN DSP a été calculé à l'aide des bons canaux-1 et donc, le rapport
bons(DSP)/denominator doit nous ramener aux valeur de pente trouvées
dans les fits:

VA  bons(DSP)/denom.   fit
1       0.667         0.667
5       0.711         0.710
6       0.806         0.806

Donc on comprend ce que l'on voit, et il faut changer l'expression du
dénominateur ainsi:

int denominator=32-good; // now should be ok...

J'ai modifié la ligne en question, et toujours en forçant un CN à 20, on
obtient désormais les bonnes valeurs:

 VA= 1   intcpt=-0.059901   slope=1.000272
 VA= 2   intcpt=-0.064887   slope=1.000646
 VA= 5   intcpt=-0.035761   slope=0.999463
 VA= 6   intcpt=-0.065733   slope=1.000786

Reste le problème des valeurs négatives. En imposant cette-fois un CN
moyen de -20, en décalant les piedestaux de +20, on obtient les
résultats suivants:

 VA= 1   intcpt=315.034460   slope=1.000846
 VA= 2   intcpt=315.032116   slope=1.000153
 VA= 5   intcpt=303.320999   slope=0.999127
 VA= 6   intcpt=282.433946   slope=1.000694

Si l'on reconstruit la valeur cumulée du CN moyen avant division, on se
rend compte qu'il y a un décalage de 8191 adc.
Ce qui laisse peu de doute sur un problème de signe.

Paolo a trouvé le bug, le registre AY1 n'était pas correctement initialisé (AY1=0 devrait être AY1=MR1). J'attache au mail la portion de code pour la division qui semble désormais marcher correctement pour les CN positifs et négatifs.

Terminons avec les mesures de temps.

Le DSP présente trois pins qui peuvent émettre un signal "Flag". L'un d'entre eux (FL0, pin 87) est connecté à un point de test de la carte TDR2: TP32 pour le TDR A, et TP33 pour le TDR B. J'ai mis une photo au bas de la page web suivante, qui permet de repérer facilement de point de test:

http://ams.pg.infn.it/~azzarel/tdr/TDRdescription.html

On active après dans le code le signal avec une commande SET/RESET/TOGGLE FL0; selon les besoins du moment. Après, il ne reste plus qu'à choisir son oscilloscope préféré et à faire les mesures de temps !

1. Temps de réduction pour un événement avec shift right pour tous les VAs: 289 us
http://ams.pg.infn.it/~azzarel/tdr/6426/redmodenormal.png

2. Temps de réduction pour un événement avec division pour tous les VAs:
env 337 us.
http://ams.pg.infn.it/~azzarel/tdr/6426/redmodealldiv.png

3. Temps pour effectuer une division: 480 ns (500ns-l'instruction du reset FL0). Le temps qui sépare le traitement entre 2 VAs
est de 8.68 us.
http://ams.pg.infn.it/~azzarel/tdr/6426/division_time.png

Clairement, ce n'est pas la division en tant que telle qui nous coûte du temps (8 us de plus, alors que le temps total supplémentaire est d'env. 50 us). En effet, pour le code 6424_01:

mauvais canal:  6 instructions
bon canal    : 12 instructions

Dans notre cas, j'ai mis arbitrairement 39 mauvais canaux par VA:

39 mauvais, 24 bons, 1 ignoré (3 instructions) = 525 instructions

Si les 33 premiers canaux sont bons: 33*12 = 396 instructions

La différence est donc: (525-396)*20ns=2580 ns

Pour 16 VAs: 41.3 us, rajoutez les 8us de la division, et on trouve une différence d'env 50us.
Notez que dans le pire des cas, i.e. 33 mauvais canaux, la différence totale passe à env. 60 us.

Donc, le paramètre important en terme de temps est le nombre de mauvais canaux, et comment ils sont répartis sur le VA, le pire des cas étant qu'il y ait 32 bons: dans ce cas, en plus du temps de recherche (on examine tout le VA pour trouver un 33ème bon), on a la division réelle qui nous augmente le temps de 500ns.

Nous n'avons pas encore testé la nouvelle version 02, mais on devrait gagner 40ns par bon canal, ie. au mieux env 20 us.

Si l'on veut gagner du temps ici, la solution la plus simple est sûrement de baisser le nombre de bons canaux à prendre en compte. Il faut par contre comprendre si il est raisonnable de faire ce choix ou non.

Maintenant, nous allons passer à la version 6426_02 .

Pour terminer, une remarque concernant la documentation du code. Dans l'exemple du calcul du CN, on constate que la somme pour le CN se fait en début de boucle, et non en fin comme indiqué dans la doc. Ce qui me semble-t-il a son importance. Si j'avais un souhait à émettre, ce serait que la doc soit plus proche la structure réelle du code, de sorte que le lecteur puisse mieux cerner les subtilités des opérations réalisées par le DSP.

A bientôt,

   Philippe

//////////////////////////////////////////////////////////////////////
// 		Procedure sDIVISION : calcul CN			    //
//		Entrées : AR, SORTIE : AR (maximum : 0x07FF	    //
//////////////////////////////////////////////////////////////////////
sDIVISION:		
//
//		SET FL0;
		AR = 0x0020;
		AR = AR - AF;
		AY0 = MR0;
		AY1 = MR1;
//
//		AR = ABS AR;
		DIVS AY1, AR;

		DIVQ AR;
		DIVQ AR;
		DIVQ AR;
		DIVQ AR;
		DIVQ AR;
		DIVQ AR;
		DIVQ AR;
		DIVQ AR;
		DIVQ AR;
		DIVQ AR;
		DIVQ AR;
		DIVQ AR;
		DIVQ AR;
		DIVQ AR;
		DIVQ AR;
		DIVQ AR;
//
		AR = AY0;
		AY1 = 0x0001;
//
sEND_DIVISION:
//
//		RESET FL0;
		RTS;
//

Analyse:

Pas de nouvelles de Mercedes

Sonia a trouvé 2 autres 'bugs' dans la reconstruction...