Project

General

Profile

Actions

Task #590

closed

livraison version 3.0.0.13

Added by paul leroy about 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
-
Start date:
22/01/2016
Due date:
% Done:

0%

Estimated time:
revision:

Description

Voici une version qui évoluera mais sur laquelle vous pouvez travailler.
Ce qui marche: commutation des modes selon exigence. Le mode NORMAL n'est pas redémarré lors des transition suivantes:
NORMAL => SBM1
NORMAL => SBM2
SBM1 => NORMAL
SBM2 => NORMAL

Plusieurs champs supplémentaires liés aux timecodes sont gérés dans les paquets hk (voir issue #588).

J'ai mis un watchdog. Pour l'instant il ne sert à rien, il faut en définir le fonctionnement en cas d'utilisation.

Reste le traitement des données EDAC du cache à implémenter et tester.


Files

README (16 KB) README paul leroy, 22/01/2016 05:23 PM
fsw (4.04 MB) fsw paul leroy, 22/01/2016 05:23 PM
tests_time_VHDL-1.1.89_FSW-3.0.0.13_2016_01_25 (169 KB) tests_time_VHDL-1.1.89_FSW-3.0.0.13_2016_01_25 thomas chust, 26/01/2016 12:05 AM
tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.13_2016_01_25 (56.4 KB) tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.13_2016_01_25 thomas chust, 26/01/2016 11:39 PM
Actions #1

Updated by thomas chust about 6 years ago

Paul, une question bête. Cela marche t-il aussi pour les transitions suivantes:
SBM1 => SBM2 ?
SBM2 => SBM1 ?

Actions #2

Updated by paul leroy about 6 years ago

Normalement oui.

Actions #3

Updated by Veronique bouzid about 6 years ago

Installation de la version 3.0.0.13 sur pc-faust9.

Voici donc le nouvel environnement de test
FSW 3.0.0.13
VHDL 1.1.89
EM sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee

Le script /home/validation/SCRIPT/just_hk_survey.py a été joué.

1- La version est correctement affichée dans les TM_LFR_HK.

2- Apres la sequence de boot, les champs
HK_LFR_TIME_NOT_SYNCHRO est positionné à 1
HK_LFR_LE_CNT est incrémenté et vaut 1
--> cela me semble correct

3- le champ SY_LFR_WATCHDOG_ENABLED est toujours à DISABLED.
--> comme indiqué par Paul, on doit determiner son fonctionnement

Les fichiers de test sont dans le répertoire /home/validation/data/3.0.0.13/TESTS6UNITAIRES/just_hk

Actions #4

Updated by paul leroy about 6 years ago

C'est pas forcément sain qu'une désynchro soit repérée juste après le boot puisque c'est normal de commencer désynchronisé.

Je propose d'attendre une transition synchronisé vers désynchronisé avant de commencer à compter les désynchros.

Actions #5

Updated by thomas chust about 6 years ago

J'ai fait des tests (régularité de la période de 22 s + centrage des SWF) sur les données fournies par véro (voir son message ci-dessous). Résultats:
  • plus on va vers la fin du fichier (30 min SBM1 + 30 min SBM2) plus on s'écarte des 22 s (-3.5 s sur les swf2 et swf1) => vraiment pas régulier (alors qu'on est en mode non synchrone)
  • sur les swf0 même tendance mais en plus il y a des gros bug tout à fait similaire au Bug #548 (qui portait sur les swf0 et swf1)
  • hormis les grandes discontinuités associées au gros bug, les SWF sont bien centrées (du moins de la même manière pour tous les SWF, à 2-4 fine time près)

Je joins mon fichier récapitulatif des tests

------- Message transféré --------
Sujet : Test à depouiller
Date : Mon, 25 Jan 2016 15:08:57 +0100
De : veronique bouzid <>
Pour : Thomas Chust <>, Bruno Katra <>

Hello,
SUr pc-faust9 compte validation

Dans le répertoire
/home/validation/data/R3/3.0.0.13/TEST-UNITAIRES/sbm1-vs-sbm2
il ya les 2 fichiers obtenus en parametrant
les Snapshots à 22s
Les Asm= 4s
puis
30 mn de sbm1
30 mn de sbm2

Je vous laisse découvrir les résultats.

Véronique

Actions #6

Updated by paul leroy about 6 years ago

J'ai trouvé le bug. Finalement, je suis revenu à une solution ou je resynchronise en utilisant 1 snapshot sur 2:
1) je reçois le snapshot 2k, je mesure le temps de centre, je calcule une correction (le snapshot 2k+1 est déjà en cours d'acquisition)
2) la correction est utilisée pour le snapshot 2k+2
3) à la réception du snapshot 2k+2, je calcule une nouvelle correction
Ca fonctionne sur ma machine, ça peut corriger des dérives inférieure à 0.5 secondes sur deux périodes (2*300 secondes dans les conditions nominales)

Correction dans fsw >= 3.0.0.14

A noter, quelquechose que je viens de vérifier et que j'avais oublié:
avec VHDL 0.1.68 sur ma MINI-LFR, en l'absence de timcodes, il n'y a pas de dérive, on tombe sur des intervalles exacts (ce qui est le comportement attendu sur les vieilles version du VHDL).
avec VHDL 0.1.89 sur MINI-LFR (et donc sur les versions récentes du VHDL), même sans synchro ni timecode il y a une dérive, on ne tombe plus parfaitement sur des temps justes parce que le coarse_time et le fine_time sont basés sur l'oscillateur à 50 MHz et non plus sur l'oscillateur à 49.152 MHz (utilisé pour générer 16, 256, 4096 et 24576 Hz), donc finis les cas où tout tombait juste.

Ce dernier point est à clarifier avec Alexis peut-être.

Actions #7

Updated by paul leroy about 6 years ago

  • Assignee changed from paul leroy to Veronique bouzid
Actions #8

Updated by thomas chust about 6 years ago

Dans la même veine pour les CWF, test fait sur la régularité des paquets. Résultat dans le fichier joint. Même conclusion que Véronique. Tout semble nominale même pour les paquets CWF3. Les dérives observées sont cohérentes avec la durée des buffers de 2688 points et sont de l'ordre de 4-8 ppm. Cela confirme des observations antérieures: #441 ou #245

Actions #9

Updated by Veronique bouzid almost 6 years ago

  • Status changed from New to Closed
Actions

Also available in: Atom PDF