Project

General

Profile

Bug #186

Probleme timing sur les Basic Parameters

Added by Veronique bouzid over 7 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
High
Category:
-
Target version:
-
Start date:
21/07/2014
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

Sur pc-coillot, j'ai ecrit un petit script qui se joue en normal mode (/home/validation/SCRIPT/just_normal_mode.py pour analyser le timing des Basic Parameters.

Les fichiers resultants se trouvent dans le répertoire /home/validation/2014_07_21.

Voici le timing observé des BP: 4s pour les BP1 et 20 sec pour les BP2
14:13:54.070467, TC_LFR_ENTER_MODE (CP_LFR_MODE=1)
14:13:54.165007, TM_LFR_TC_EXE_SUCCESS, TIME=0x80000000c778 - debut du mode donc de l acquisition !!!!
14:13:55.657044, TM_LFR_HK, TIME=0x8000000241c2
14:13:58.257183, TM_LFR_SCIENCE_NORMAL_BP1_F0, TIME=0x80000004c4cb - premier BP1 (4s)
14:13:58.257588, TM_LFR_SCIENCE_NORMAL_BP1_F1, TIME=0x80000004b785
14:13:58.257965, TM_LFR_SCIENCE_NORMAL_BP1_F2, TIME=0x80000003c853 mais ici c est plutot < 4s
14:13:58.657036, TM_LFR_HK, TIME=0x8000000541bc
14:14:02.257154, TM_LFR_SCIENCE_NORMAL_BP1_F0, TIME=0x80000008c4cb
14:14:02.257527, TM_LFR_SCIENCE_NORMAL_BP1_F1, TIME=0x80000008b785
14:14:02.257856, TM_LFR_SCIENCE_NORMAL_BP1_F2, TIME=0x80000007c853
14:14:02.657031, TM_LFR_HK, TIME=0x8000000941bf
14:14:06.257147, TM_LFR_SCIENCE_NORMAL_BP1_F0, TIME=0x8000000cc4cb
14:14:06.257514, TM_LFR_SCIENCE_NORMAL_BP1_F1, TIME=0x8000000cb785
14:14:06.257827, TM_LFR_SCIENCE_NORMAL_BP1_F2, TIME=0x8000000bc853
14:14:06.657034, TM_LFR_HK, TIME=0x8000000d41c0
14:14:10.257145, TM_LFR_SCIENCE_NORMAL_BP1_F0, TIME=0x80000010c4cb
14:14:10.257519, TM_LFR_SCIENCE_NORMAL_BP1_F1, TIME=0x80000010b785
14:14:10.257832, TM_LFR_SCIENCE_NORMAL_BP1_F2, TIME=0x8000000fc853
14:14:10.657037, TM_LFR_HK, TIME=0x8000001141c2
14:14:14.257321, TM_LFR_SCIENCE_NORMAL_BP1_F0, TIME=0x80000014c4cb
14:14:14.25849, TM_LFR_SCIENCE_NORMAL_BP1_F1, TIME=0x80000014b785
14:14:14.25904, TM_LFR_SCIENCE_NORMAL_BP2_F1, TIME=0x80000014b785 - premier BP2 (environ 20s)
14:14:14.259839, TM_LFR_SCIENCE_NORMAL_BP1_F2, TIME=0x80000013c853
14:14:14.26037, TM_LFR_SCIENCE_NORMAL_BP2_F2, TIME=0x80000013c853

Paul peux-tu vérifier que ces timing sont corrects. La périodicité des 4s pour les BP1 semblent etre respectées pour chaque Fx.Par contre pour le premier BP , est ce correct.

Une fois que nous serons sur que les BP sont correctement générés, on pourra
- tester la commutaion de mode
- tester l'envoi d une UPDATE_TIME

Idem

History

#1 Updated by Veronique bouzid over 7 years ago

  • Priority changed from Normal to High

#2 Updated by paul leroy about 7 years ago

  • Status changed from New to Feedback
  • Assignee changed from paul leroy to Veronique bouzid

Il faudrait remanier les outils d'analyse des paquets entrants car avec le soft 2.0.1.1 l'adresse de destination est 32 au lieu de 1 et je ne peux pas voir les résultats correctement, les paquets sont rejeté par l'outil et je n'ai rien dans le fichier Synth.txt hormis les TC.

#3 Updated by Veronique bouzid about 7 years ago

  • Status changed from Feedback to Closed

Le soft de validation a été mis à jour pour prendre en compte cette nouvelle valeur de Ttarget Logical Address non conforme par rapport à la SSS.

Avec Paul nous avons décidé d 'ajouter dans le fichier Detail, l indication de Target Logical Address de la façon suivante:
11:32:14.353262,* * 32 , TM_LFR_PARAMETER_DUMP,

Pour toutes les TM, juste après la date on on rajoute * 32 * , ce qui correspond au target logical_id=0x20 au lieu de la valeur 0x01.

Ensuite il a fallu adapter le script verif_fields pour tenir compte de l'ajout de cette information.

Au final , voici la liste des fichiers modifiés:
/opt/VALIDATION_R2/lfrverif/common/param.py (définition de la constante SY_DPU_LFR_LA1 )
/opt/VALIDATION_R2/lfrverif/common/test_monitor.py (traitement tm_logical_id=SY_DPU_LFR_LA1
/opt/VALIDATION_R2/lfrverif/common/tm_analyze.py (Autorise les 2 valeurs SY_DPU_LFR_LA et SY_DPU_LFR_LA1 comme Target Logical Address)

Le script verif_fields.py est actuellement dans le répertoire de test /home/validation/2014_10_13, il faudra le copier dans /opt/VALIDATION_R2/lfrverif/common.

#4 Updated by bruno katra about 7 years ago

  • Status changed from Closed to Feedback
  • Assignee changed from Veronique bouzid to paul leroy

#5 Updated by paul leroy almost 7 years ago

  • Status changed from Feedback to Resolved
  • Assignee changed from paul leroy to bruno katra

Modifications majeures effectuées sur le VHDL et sur le soft de vol, rejouer les tests sur:

FSW >= 2.0.2.1
VHDL >= x.1.57

#6 Updated by Veronique bouzid about 6 years ago

  • Assignee changed from bruno katra to paul leroy

Le script /home/validation/SCRIPT/just_normal_mode.py a été rejoué sur les dernieres versions

Voici maintenant ce que l on obtient (extrait du fichier 2015_09_24-13_35_10-Synth.txt)
13:28:56.194317, TC_LFR_ENTER_MODE (CP_LFR_MODE=1)
13:28:56.216847, TM_LFR_TC_EXE_SUCCESS, TIME=0x800000095d62
13:28:57.054079, TM_LFR_HK, TIME=0x8000000a33ba
13:28:58.054064, TM_LFR_HK, TIME=0x8000000b33ba
13:28:59.054158, TM_LFR_HK, TIME=0x8000000c33ba
13:29:00.054099, TM_LFR_HK, TIME=0x8000000d33ba
13:29:00.273602, TM_LFR_SCIENCE_NORMAL_BP1_F0, TIME=0x800000095d5e
13:29:00.295441, TM_LFR_SCIENCE_NORMAL_BP1_F1, TIME=0x800000095d66
13:29:00.300184, TM_LFR_SCIENCE_NORMAL_BP1_F2, TIME=0x800000095e4c
13:29:01.054012, TM_LFR_HK, TIME=0x8000000e33ba
13:29:02.054076, TM_LFR_HK, TIME=0x8000000f33ba
13:29:03.053966, TM_LFR_HK, TIME=0x8000001033ba
13:29:04.053869, TM_LFR_HK, TIME=0x8000001133ba
13:29:04.273776, TM_LFR_SCIENCE_NORMAL_BP1_F0, TIME=0x8000000d5d5c
13:29:04.28724, TM_LFR_SCIENCE_NORMAL_BP1_F1, TIME=0x8000000d5d64
13:29:04.300085, TM_LFR_SCIENCE_NORMAL_BP1_F2, TIME=0x8000000d5e49
13:29:05.05387, TM_LFR_HK, TIME=0x8000001233ba
13:29:06.053878, TM_LFR_HK, TIME=0x8000001333ba
13:29:07.053905, TM_LFR_HK, TIME=0x8000001433ba
13:29:08.053917, TM_LFR_HK, TIME=0x8000001533ba
13:29:08.273623, TM_LFR_SCIENCE_NORMAL_BP1_F0, TIME=0x800000115d5a
13:29:08.287083, TM_LFR_SCIENCE_NORMAL_BP1_F1, TIME=0x800000115d62
13:29:08.299258, TM_LFR_SCIENCE_NORMAL_BP1_F2, TIME=0x800000115e47

On observe donc que le premier echantillon utilisé pour le premier BP1 a un temps
précedent celui de l'acquittement de la commutation de mode. Dans notre cas, 4 fine time.
Jean-christophe a expliqué le pourquoi, l'échantillon est daté à l'entrée du FPGA.
--> Paul il faut l'ecrire

Ensuite il faut vérifier le timimg des BP.

Les fichiers de test sont accessibles dans le répertoire
/home/validation/data/R3/TEST-UNITAIRES/3.0.0.8/1.8.89/BUG-186

La vérification des timing des BP1 et BP2 est satisfaisantes
T(TM_LFR_SCIENCE_NORMAL_BP1_F0): nom=4.0s, Nb(T)=86.0, min=3.996918s, mean=3.99996297674s, max=4.002812s, Nb(T<3.6s)=0.0%, Nb(T>4.4s)=0.0%
T(.../PA_LFR_ACQUISITION_TIME): min=3.99995422363s, mean=3.99996593387s, max=3.99996948242, Nb(T<3.6s)=0.0%, Nb(T>4.4s)=0.0%

T(TM_LFR_SCIENCE_NORMAL_BP1_F1): nom=4.0s, Nb(T)=86.0, min=3.983894s, mean=3.99984804651s, max=4.015951s, Nb(T<3.6s)=0.0%, Nb(T>4.4s)=0.0%
T(.../PA_LFR_ACQUISITION_TIME): min=3.99995422363s, mean=3.99996593387s, max=3.99996948242, Nb(T<3.6s)=0.0%, Nb(T>4.4s)=0.0%

T(TM_LFR_SCIENCE_NORMAL_BP1_F2): nom=4.0s, Nb(T)=86.0, min=3.975918s, mean=3.99993347674s, max=4.024025s, Nb(T<3.6s)=0.0%, Nb(T>4.4s)=0.0%
T(.../PA_LFR_ACQUISITION_TIME): min=3.99995422363s, mean=3.99996593387s, max=3.99998474121, Nb(T<3.6s)=0.0%, Nb(T>4.4s)=0.0%

T(TM_LFR_SCIENCE_NORMAL_BP2_F0): nom=20.0s, Nb(T)=16.0, min=19.98938s, mean=19.999799s, max=20.010209s, Nb(T<18.0s)=0.0%, Nb(T>22.0s)=0.0%
T(.../PA_LFR_ACQUISITION_TIME): min=19.9998168945s, mean=19.999830246s, max=19.9998474121, Nb(T<18.0s)=0.0%, Nb(T>22.0s)=0.0%

T(TM_LFR_SCIENCE_NORMAL_BP2_F1): nom=20.0s, Nb(T)=16.0, min=19.998065s, mean=19.9997895625s, max=20.002557s, Nb(T<18.0s)=0.0%, Nb(T>22.0s)=0.0%
T(.../PA_LFR_ACQUISITION_TIME): min=19.9998168945s, mean=19.999830246s, max=19.9998474121, Nb(T<18.0s)=0.0%, Nb(T>22.0s)=0.0%

T(TM_LFR_SCIENCE_NORMAL_BP2_F2): nom=20.0s, Nb(T)=16.0, min=19.991486s, mean=19.9998288125s, max=20.004903s, Nb(T<18.0s)=0.0%, Nb(T>22.0s)=0.0%
T(.../PA_LFR_ACQUISITION_TIME): min=19.9998016357s, mean=19.999830246s, max=19.9998474121, Nb(T<18.0s)=0.0%, Nb(T>22.0s)=0.0%

Contexte du test
----------------
FSW 3.0.0.8
VHDL 1.1.89
EM sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee

#7 Updated by paul leroy about 6 years ago

  • Status changed from Resolved to Feedback
  • Assignee changed from paul leroy to Veronique bouzid

Attention, il faut distinguer la date d'acquittement de la date de transistion à proprement dite. Qu'avais-tu mis comme date de transition?

Ceci étant dis, avec la bonne date de transition, tu devrais noter que le temps du premier échantillon est effectivement antérieur à la date de commutation, ce qui s'explique par le fait qu'au moment où tu commutes, il y a forcément un échantillon qui attend d'être utilisé: au transition time demandé, la porte s'ouvre. Le delai max observé devrait être < temps entre deux échantillons du canal considéré (f0, f1, f2 ou f3).

Cette information pourrait être répercutée dans le user manual, pour que les utilisateurs ne soient pas étonnés, ou dans le software detailed design. Qu'en penses-tu?

#8 Updated by Veronique bouzid about 6 years ago

  • Assignee changed from Veronique bouzid to paul leroy

la date d'entrée dans le mode est instantanée.

#9 Updated by paul leroy about 6 years ago

  • Assignee changed from paul leroy to Veronique bouzid

En condition de commutation instantanée, tu ne connais pas la date exacte de démarrage. Il faut configurer timegen avec la date locale du pc de test, attendre que le temps soit propagé à LFR, puis lancer un mode avec un transition_time compatible. Le scenario de cwf3_vs_hk utilise une fonction qui fait ça (définie dans le module misc).

enterModeTime = misc.enterMode( report, tcEnterMode, soc, NORMAL )

#10 Updated by Veronique bouzid almost 6 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF