Archives de catégorie : gbeth

Reunion_11Jan2k13

Le but de cette réunion est de définir le principe de fonctionnement, le planning et le contexte de fonctionnement du futur bloc UDP. Ce bloc devra être capable de recevoir, analyser, créer et renvoyer des trames d’informations provenant de différentes sources telles qu’un PC, une DIF, …

1 – Planning de conception

Le planning de conception se décompose en 3 étapes :

• Etape 1 : (jusqu’à Mars)

– Création d’une trame de type Ethernet et envoie vers un PC (l’ensemble des champs seront chargés en premier temps depuis des registres fixes)
– Réception d’une trame provenant du PC et lui renvoyer (principe du Ping)
– Réponse à une demande (analyse de la trame de réception et envoie d’une trame réponse)

Il est impératif de développer des blocs les plus génériques possibles et les plus réutilisables possibles pour au final créer une IP.

• Etape 2 : (jusqu’à Juin)

– Programmation de l’adresse IP à travers l’adresse MAC
– Programmation de l’adresse MAC de destination (à savoir celle du PC)
– Programmation du PORT primaire
– Programmation d’une gateway IP (si l’adresse IP est inconnue, on renvoie une trame à une adresse IP définie)
– Création d’un protocole interne LLRHCP
– 1ère Implémentation du protocole ARP (programmation de la réponse uniquement)

• Etape 3 : (jusqu’à …)

– 2ème Implémentation du protocole ARP (programmation de la question)
– Différentes fonction à définir au fur et à mesure

2 – Description d’un trame Ethernet :

Une trame Ethernet se décompose en 4 parties : |Entête Ethernet | Entête IP | Entête UDP | Data |

L’entête Ethernet est composé de 3 champs (nombre d’octets): ==> |Adresse MAC destination (6) | Adresse MAC source (6) | Type de liaison (2) |

L’entête IP est composé de 10 champs (nombre d’octets): ==> | Version + Longueur de l’entête (1) | Service (1) | Longueur_total (2) | Identifiant (2) | Flag (1) | Offset (1) |
Temps de vie (1) | Protocole (1) | Checksum_entete (2) | Adresse IP source (4) | Adresse IP destination (4) |

L’entête UDP est composé de 4 champs (nombre d’octets): ==> | Port source (2) | Port destination (2) | Longueur (2) | Checksum (2) |

2.1 – Trame Ethernet CALICE

Dans le cadre de CALICE la communication avec la carte se fait par des trames Ethernet de type « raw »

DST MAC (6) | SRC MAC (6) | ETH type (2) | GDCC/LDA Type (2) | GDCC/LDA Modifier (2) | GDCC/LDA PKT_ID (2) | GDCC/LDA Data length (2) | GDCC/LDA Data (variable) | Padding | CRC32 (4)|

ETH type est definie suivant 3 valeurs:

0x809 : Command « FAST Packet »

0x810 : Paquet de donnée normale (configuration)

0x811 : Paquet de read-out (données issues des DIFs)

Dans le cas d’une commande « FAST Packet », la trame Ethernet est la suivante :

DST MAC (6) | SRC MAC (6) | ETH type (2) | Command_word (2) | DIF_Link (2) | Comma (1) | DATA (1) | Parity (2) | PAD (padding pour la taille mini ethernet) | CRC32|

3 – Banc de test

Concernant le blanc de test, le matériel nécessaire sera :
– Une carte de développement
– Un réseau local
– Un PC
– Un oscilloscope

WikiStart – gbeth

Gigabit Ethernet

  • Le svn est accessible :
  • Avec un navigateur web : [source:/ Trac] ou ViewVC
  • Avec un client svn (eg. ‘svn’ sous unix, Tortoise sous windows) : https://llrforge.in2p3.fr/svn/gbeth
  • L’eLog

Pour avoir accès au svn, au trac ou à l’elog, merci de remplir ce formulaire et nous envoyer le mot de passe chiffré.

Documentation

Liens

Documents issues de la collaboration DHCAL Calice

Stages

  • Stage Benoit : projet UDP

Projet GDCC

Projet UDP

documentation

Page contenant les informations sur la GDCC:

1 – GDCC-DIF Registers

the format is done via the following packet

address = 2 bytes
data = 4 bytes

Adress is 16 bits, data is 32 bits.
Currently the registers are 16 bits.
this is to allow future expansion

Lower bits of data are used first, so a register that returns < 32 bits will return in the lower bits of data space, this is the same for the writes.

When performing a read, the packet must still include the space for the data, even though it will be over written by the GDCC internal processing.
The advantage is the things are symmetric for both reads and writes.

Block 0x1

—-
Reg 0 + 2

Name: TX/RX Enable
Access from PC: R/W
Description: Bitmap, 1 bit for each DIF channel, set to 1 to enable it in TX (Reg0) + RX (Reg 2) direction.

—-
Reg 4

Name: Link RTT
Access from PC: R/W (W on link restart only)
Description: Bitmap, 1 bit for each DIF channel.

Set the bits to 1 to prepare to measure RTT on the selected channels. Setting from 0 to 1 is taken into account at next restart link. To end RTT operation, set it to 0 any time.

The RTT is taking the link delay module into account (DCC firmware >= r1425): this means that changing values in the Link Delay registers should impact the RTT measures (also note that changing these delays while in RTT measurement will cause a transient restart of the RTT measurement because the serializer [parallel to RTT, but impacting it] loses RX sync during a few cycles). When all the RTT of all the connected lines are the same, then chances are that the links are synchronized (modulo 1 period on the link).

Link status registers (0xa + 0xb) affected.
To start a RTT measure session:

Write Link RTT register bitmap with bits set = channels to measure
Write Link Restart register bitmap with bits set = channels to measure. This will start a new RTT measure session
The Link status registers should oscillate between 0b010 and 0b011
Wait for the LINK_RTT_DONE of the channels you want to measure to be set to 1. This signals that at least one measure has been performed on the corresponding channel, such that the corresponding LINK_RTTx value is valid
Do nothing or periodically check the LINK_RTTx values of the channel whose LINK_RTT_DONE is 1: this is refreshed continuously while the RTT session is running. Do some stats with these sampled values, etc.

To stop a RTT session:

Clear the Link RTT register bits you want to stop to measure
The Link status registers should be back to 0b101
The Link Done bit for the cleared channels should be clear
The LINK_RTTx values should reflect the last sampled RTT value for the channels that have been stopped

—-
Reg 6

Name: Link Autoneg Pause
Access from PC: R/W (W 1 on link restart only)
Description: Bitmap, 1 bit for each DIF channel, set to 1 to switch off the selected channels. Setting it from 0 to 1 is taken into account at next restart link. To resume normal operation, set it to 0 any time.
Link status registers (0xa + 0xb) affected.

—-
Reg 8

Name: Link Restart
Access from PC: W (R should always return 0)
Description: Bitmap, 1 bit for each DIF channel, to restart the link negotiation FSM (lda_protocol_sm.vhd) for the given channels. Will take Regs 4 and 6 into account: Reg 4 first when set, Reg 6 otherwise

—-
Reg 0xa + 0xb

Name: Link Status
Access from PC: R
Description: Array of 3 bits blocks, 1 block per channel (1st block = lsb of Reg 0xa). Possible values:

« 000 » = starting up
« 001 » = sending_idle_stream
« 010 » = sending loopback command. Waiting for loopback to ack.
« 011 » = sending random data. Shows Remote is looped.
« 100 » = sending link start.
« 101 » = Link is up
« 111 » = Has all gone wrong.

—-
Reg 0xe

Name: Ling No Signal
Access: R
Description: Bitmap, 1 bit for each DIF channel. Set to 1 when the DIF didn’t do any transition to the DCC for at least 512 clock periods. Could be because the link is not electrically valid, or the DIF didn’t send any 8b/10b idle/k/d transitions for at least 512 clocks.

—-
Reg 0x10 + 0x11 + 0x12 + 0x13

Name: Link Delay 1..4
Access from PC: R/W
Description: Array of 5 bits blocks, 1 block per channel (1st block = lsb of Reg 0x18). Each value = delay (in number of link periods) to add at TX level. Use this to compensate for non-uniform RTT measurements from DIF channel to channel (see RTT register above).

—-
Reg 0x18 + 0x19 + 0x1a + 0x1b

Name: Link RTT 1..4
Access from PC: R
Description: Array of 5 bits blocks, 1 block per channel (1st block = lsb of Reg 0x18). Each value = RTT measured, valid during a RTT measurement session when corresponding RTT Link Done is set, and valid after an RTT measurement session. Each value = delay (in number of link periods) measured to transfer data to DIF and back, taking into account the delay added by the link delay register above.

—-
Reg 0x20

Name: RTT Done
Access: R
Description: Bitmap, 1 bit for each DIF channel. During a RTT measurement session: set to 1 when at least 1 RTT measure has been performed on the corresponding channel (and measure stored in the RTT_LINKx register). Otherwise should be 0.

—-
Reg 0x22

Name: GET_LNKS_LOCKED
Access: R
Description: Bitmap, 1 bit for each DIF channel, set to 1 when the corresponding DIF channel is known to be connected and locked

—-
Reg 0x24

Name: Link DCM
Access: R/W
Description: R access = should always be 1, but in effect bit 0 means « DCM locked ». W access = bit 1 (not 0 !) to force the DCM to relock itself (auto-clearing), bit 2 to restart the word clock counter from fresh (auto-clearing, but meaning not fully understood).

2 – GDCC internal registers

This block contain all registers for the GDCC only.
The block is the block 4.(0x4)
Currently, it based on 17 address.

—-
Reg 0x000

Name : LDA/GDCC enables

—-
Reg 0x001

Name : LDA/GDCC tx_mux_count

—-
Reg 0x002

Name : LDA/GDCC reg_pktdelay
Access : R/W
property : expert only
The data is on 16 bits, only 6 lsb bit are used. It corresponds at the delay between each packets at the output of round robin function. The configuration must be:
– 000000 : no delay
– 000001 : 20 ns
– 000010 : 200 ns
– 000100 : 2µs
– 001000 : 20 µs
– 010000 : 200 µs
– 100000 : 2 ms

—-
Reg 0x006

Name : LDA/GDCC dif_data_mac_l
access : R/W
This is the LSB octet of the PC Mac adress (0–15)

—-
Reg 0x007

Name : LDA/GDCC dif_data_mac_m
access : R/W
This is the medium octet of the PC Mac adress (16–31)

—-
Reg 0x008

Name : LDA/GDCC dif_data_mac_h
access : R/W
This is the MSB octet of the PC Mac adress (32–47)

—-

—-
Reg 0x00e

Name : LDA/GDCC revision

—-
Reg 0x00f

Name : LDA/GDCC version

—-
Reg 0x010

Name : LDA/GDCC pktgen_control

—-
Reg 0x011

Name : LDA/GDCC pktgen_size

—-
Reg 0x012

Name : LDA/GDCC pktgen_count

—-
Reg 0x013

Name : LDA/GDCC pktgen_delay

—-
Reg 0x014

Name : LDA/GDCC pktgen_seed

—-
Reg 0x015

Name : LDA/GDCC pktgen_txcount

—-
Reg 0x016

Name : LDA/GDCC pktgen_mac_l

—-
Reg 0x017

Name : LDA/GDCC pktgen_mac_m

—-
Reg 0x018

Name : LDA/GDCC pktgen_mach

SFP

Fabricants de modules
[http://www.sfplustransceiver.com/sfp-transceivers]