LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

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.

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.

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

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

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?

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

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 )