Project

General

Profile

Task #492

Implementation Timing LFR

Added by Veronique bouzid about 6 years ago. Updated about 6 years ago.

Status:
New
Priority:
Normal
Category:
-
Target version:
-
Start date:
10/09/2015
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

Ces informations sont extraites du document RPW-SYS-SSS-00013-LES_Issue3_rev3_Software_System_Specification_bars.pdf

1- Liste des requirements liés au Timing (section Time management 4.1.4)

SSS-CP-FS-340 REQ-LFR-SRS-5300 SVS-0020
SSS-CP-FS-350 REQ-LFR-SRS-5217 Design
SSS-CP-FS-360 REQ-LFR-SRS-5218 SVS-0011
SSS-CP-FS-370 REQ-LFR-SRS-5219 SVS-0012
SSS-CP-FS-376 REQ-LFR-SRS-5237 noté Design mais on a un test
SSS-CP-FS-380 REQ-LFR-SRS-5220 SVS-0013
SSS-CP-FS-390 REQ-LFR-SRS-5301 Design
SSS-CP-FS-400 REQ-LFR-SRS-5221 Design
SSS-CP-FS-405 REQ-LFR-SRS-5238 SVS-0014
SSS-CP-FS-410 REQ-LFR-SRS-5222 SVS-0076

Résumé de ma compréhension du timing LFR

le développement du software est axé principalement sur le fonctionnement nominal :
- toutes les secondes, LFR recoit du DAS le couple suivant
- une commande TC_LFR_UPDATE_TIME ( CTR Time Update command ou bien CTR SpaceWire command packet)
- 300ms aprés un timecode valide (SpaceWire time code)

History

#1 Updated by Veronique bouzid about 6 years ago

Cas ou LFR est synchronisé (bit 15 = 0)

1- Cas nominal
Reception d'une TC_LFR_UPDATE_TIME + timecode valide 300ms après

Si aucune TC_LFR_UPDATE_TIME n'est envoyée et que l'envoi des timecode est opérationnel, le bit 15 ne sera pas positionné à 0.
Ce cas de figure arrive
- apres le démarrage de LFR, le bit 15 = 1 et si l'envoi des timecode est lancé, LFR restera non synchronisé.
- après une perte de synchronisation (plus de timecode durant 60 sec).

Reception d'un timecode valide
Je dis timecode valide mais le VHDL n'a pas notion de timecode mais recoit un signal (tick_out).
A chaque tick_out, si pas de TC_LFR_UPDATE_TIME (registre COARSE TIME LOAD non mis à jour) , le VHDL incremente de 1 son registre COARSE TIME.

Conclusion:
Lors des tests,
- si j envoie un timecode tous les 500ms, je vais incrementer le COARSE TIME 2 fois plus vite.
Le VHDL est implementé pour le cas nominal, les autres cas n"étant spécifiés clairement, il est important de les documenter.

Envoi d'une TC_LFR_UPDATE_TIME et d'un timecode valide
J'ai déroulé le test suivant
- Envoi d'une TC_LFR_UPDATE_TIME et d'un timecode valide 2 s aprés, le soft se mettra à jour avec la date demandée par le TC_LFR_UPDATE_TIME.
En effet, quand le registre COARSE TIME LOAD est écrit, il n y a pas de durée de validée donc si le timecode arrive 2s après, le VHDL
voit qu'une valeur est stockée et donc le met dans son registre COARSE TIME.

Ce cas de figure n'est pas nominal. Faut il que le soft de vol le gère (ajout d'une tempo sur la demande d'UPDATE_TIME et effacement du registre COARSE TIME LOAD si tempo
expire)

Also available in: Atom PDF