Snippets Groups Projects

com_bpm

feat:Separate clock domains

BRONES Romain authored Feb 1, 2023

* One clock domain for AXI-MM
* One for COM BPM logic
* Xilinx CDC in between (control and status registers).
* Also move component declaration in a package

eaabf330

eaabf330 Feb 1, 2023

Name	Last commit	Last update
doc
hdl
rdl
tcl
test
.gitignore
README.adoc

README.adoc

COMBPM module documentation

Description

This module provides several logic blocks to allow communication with BPM (Beam Position Monitor) electronics. This has been built for a very precise situation (libera electron, damc-fmc2zup), but the architecture should allow modification and portability.

For now, it only provides RX communication from the DLS CC protocol (ITech libera electron). The module has been designed for DAMC-FMC2ZUP targets, populated with a 4SFP+ FMC board (CAENels).

Overview

Main operation: Top level

The basics of this module is in three blocs that are essentials for the application.

Transceiver bloc. Used to deserialize the communication stream from the BPM.
For now it is a Xilinx GTWizard, configured for the Libera Electron DLS CC protocol specs (2Gbps, 16b words…). This is tied to a specific transceiver input of the FPGA.
Protocol decoder bloc. From the deserialized words, it decode the stream and get the essential data (BPM number, position, timestamp…). It outputs it on a AXI-Stream interface.
For now, it parses Libera Electron DLS CC.
AXI-MM register interface. Used to configure and monitor everything from an AXI-MM interface (CPU).

These three blocs are depicted in the image below. It is to note that the clock domain used is the data clock, even for the register interface. This clock is provided and can be used to clock the rest of the application and/or clock CDC on the AXI-MM and AXIS interface.
The actual top_combpm_electron.vhd file provides these three blocs configured and connected for the Libera Electron and damc-fmc2zup application.

Figure 1. Basic overview of combpm module

Additionnal blocs

The module provide additionnal blocs usefull for the application.

Packet filter

Package

A package describing the AXIS packet at the module output is present. It helps to automatically pack or unpack the packet (functions bpmpacket2slv() or slv2bpmpacket() ). A zero packet (_C_BPMPACKET_ZERO) is also declared.

Table 1. t_bpmpacket record type
Member name	Type	Description
pos_x	std_logic_vector(31 downto 0)	X position
pos_y	std_logic_vector(31 downto 0)	Y position
bpm_id	std_logic_vector(15 downto 0)	ID of the source BPM
mc_timestamp	std_logic_vector(39 downto 0)	Timestamp at machine clock frequency
fa_seq	std_logic_vector(7 downto 0)	FA sequence number, LSB only

Some usage of pkg_bpmpacket.vhd

    signal my_packet    : t_bpmpacket;

(...)

    my_packet  <= slv2bpmpacket(axis_tdata);  -- Convert from AXIS tdata to a BPM packet

    id      <= my_packet.bpm_id;             -- Access packet fields
    pos_x   <= my_packet.pos_x;

    axis_tdata_o <= bpmpacket(my_packet); -- Convert back to logic vector for AXIS tdata

Details

Protocol decoder (electron)

CRC check. If fails: drop the frame, pulse frame_error output and increase the error counter.
Counts and gives the number of frame in the last DLS CC sequence receive.
DLS CC Sequence number check. If discontinuous: pulse seq_discontinuity output and increase

BPM packet AXIS stream

The AXIS data provided by the protocol decoder is descibed in the file pkg_bpmpacket_stream.vhd. See this file to have up to date fields info.

Packets are not cut into packets (TLAST always '1').
No FIFO on output (TREADY is not used). The application needs to either implement FIFO or accepts every packet (AXIS packet). The packet rate depends on the signal input.

Transceivers

The TCL script combpm_gtwizard.tcl is used to create the GTWizard IP, wich is instanciated in the top level.

AXI-MM register interface

We use DESYRDL to generate a AXI4L slave decoder.

Packet filter

This block can drop BPM packets from the AXIS by looking up their BPM_ID field. A simple memory block is used and programmed via the AXI-MM interface. The block is adressed by the BPM ID (0 to 255).

The msb (bit 7) gives the forward signal. If '1' then the packet is transfered, else it is blocked.

The 6 lsb (bit 6-0) is filled into the TDEST field of the AXIS stream. This can be used to further routing.

Figure 2. Structural schematic of combpm_packet_filter.

Registers map

Table 2. Registers
Name	N	bits	type	RW	Description
ID	1	32	uint	RO	Module identifier.
VERSION	1	32	uint	RO	Module version.
SFP	1	2	bitfields	RO	SFP module status - RXLOS [0:0] sw:RO uint : RX lost signal - MODABS [1:1] sw:RO uint : Module is absent
GT	1	11	bitfields	RW	GT transceivers status and control - POWERGOOD [0:0] sw:RO uint : Powergood signal - QPLLLOCK [1:1] sw:RO uint : PLL lock signal - RXCLKACTIVE [2:2] sw:RO uint : RX clk active signal - RXCDRLOCK [3:3] sw:RO uint : RX CDR lock signal - RXRESETDONE [4:4] sw:RO uint : RX reset done signal - RXBYTEISALIGNED [5:5] sw:RO uint : RX byte is aligned signal - RXBYTEREALIGN [6:6] sw:RO uint : RX byte realign signal - RXCOMMADET [7:7] sw:RO uint : RX comma detected signal - RXCOMMADETEN [8:8] sw:RW uint : RX comma detection enable signal - RXRSTDATAPATH [9:9] sw:RW uint : Reset RX datapath - RXRSTPLLDATAPATH [10:10] sw:RW uint : Reset RX PLL and datapath
PROTOCOL	1	4	bitfields	RW	BPM protocol status and control - FRAMEERROR [0:0] sw:RO uint : Frame error - SEQFRAMECNTERROR [1:1] sw:RO uint : Sequence frame count mismatch - SEQFRAMEDISCONT [2:2] sw:RO uint : Sequence frame discontinuity - SOFTRESET [3:3] sw:RW uint : Soft reset
VALIDFRAMECNT	1	32	uint	RO	BPM protocol valid frame counters
INVALIDFRAMECNT	1	32	uint	RO	BPM protocol invalid frame counters
VALIDFRAMERATE	1	32	uint	RO	BPM protocol valid frame rate
INVALIDFRAMERATE	1	32	uint	RO	BPM protocol invalid frame rate
FRAMESEQ	1	16	uint	RO	BPM protocol frame sequence

TODO/Future of this module

Add configuration feature to allow the choice of the transceiver (for now only X0Y4 GTH).
The application should be able to instanciate several transceiver interface, with one decoder for each.
At SOLEIL, the BPM electronics will change by 2025. At that point, it will be necessary to change the Transceivers and Protocol decoder blocs to match the new equipments.

The place to be for your source code