A selection of information and links to resources that could be useful for a new hire (from a TID-ID-ECS perspective).

General

SLAC

TID-ID

Stanford

Computer accounts and resources

Firmware

Ruckus - Vivado build system

SURF ("SLAC Ultimate RTL Framework") - RTL library

Example project: Simple-PGPv4-KCU105-Example

Hardware

PCB design

ASICs

GenerationASIC nameInformationCamerasReferences
1stCSPAD
  • "Cornell-SLAC Pixel Array Detector"
  • Timeframe: 2010-2014
  • 110x110 µm pixel pitch
  • 185x194 pixels
  • Framerate: 120 Hz
  • Front-end configurable for low and high gain
  • CSPAD-140k (2x2)
  • CSPAD-570k (4x4)
  • CSPAD-2.3M (8x8)
2ndePix
  • Timeframe: 2013-2018
  • Framerate: 120 Hz
  • Variants:
    • ePix100 (50x50 µm, 352x384 pixels)
      • Dedicated to ultra low noise applications
    • ePix100a (50x50 µm, 352x384 pixels)
      • Intermediate analog version of ePix100
      • No ADCs on-chip
      • See IEEE reference
    • ePix10k (100x100 µm, 176x192 pixels)
      • For high dynamic range applications
  • ADC approach: Off-chip
  • ePix100-540k (2x2)
  • ePix10k-135k (2x2)
  • ePix10k-2M (8x8)
3rdePixHR
  • "High Rate"
  • 100x100 µm pixel pitch
  • Framerate: 7 kHz - 35 kHz
  • Variants:
    • ePix10kHR
  • ADC approach: Column-parallel

(question)

ePixM
  • "Monolithic"
  • Early prototype in 2017
  • Two separate ASICs bump-bonded together:
    • Front-end: Analog pixel front-ends
    • Back-end: ADCs and readout
  • 50x50 µm pixel pitch
  • 192x384 pixels
  • Framerate: 7.5 kHz
  • ePixM-260k (question)
4thePixUHR
  • "Ultra High Rate"
  • Framerate: 100kHz - 1MHz
  • 100x100 µm pixel pitch
  • 192x168 pixels
  • ePixUHR-35 kHz
    • Framerate: 35 kHz
    • 1 Gb/s I/O
    • 1st prototype in 2022
    • 2nd iteration in Q4 2023 / Q1 2024
  • ePixUHR-100kHz
    • Framerate: 100 kHz
    • 5 Gb/s I/O
    • 1st prototype in mid Q2024
  • ADC approach: Cluster
  • Still in development (as of August 2023)

(question)

SparkPix
  • Framerate: 1 MHz - 1 GHz
  • 100x100 µm pixel pitch
  • 176x192 pixels
  • Variants:
    • SparkPix-ED (Event Driven)
      • High-resolution readout triggered from low-resolution data
    • SparkPix-RT (Real Time)
      • Using real-time data compression
    • SparkPix-S (Sparse)
      • sparse/data-driven readout using "sparsification engine"
    • SparkPix-T (Timing)
      • Operation mode: Time of Arrival (+ Time over Threshold)
  • Still in development (as of August 2023)
(question)

Software

Rogue

Readout topology

Overview

There are four parts in the readout chain (from left to right in the diagram below):

  • Detector ASIC: A specific pixel detector ASIC that should be controlled and read out through custom electrical interfaces.
  • Front-end: FPGA board located near the detector (see below for details).
  • Back-end: PCIe board mounted inside the PC that communicate with the front-end over fiber(s) with the PGP protocol.
  • PC: Generic PC where the Rogue software runs

readout-overview

Front-end

The front-end firmware consists of a generic Core module and a specific Application module. The communication between the Application and the Core is through an AXI-lite interface and an AXI-Stream.

  • Core: has several modules related to the PGP communication with the back-end and generic system monitoring and information.
  • Application: Contains custom modules that interface with the detector ASIC for control and data processing.

front-end-overview

Mapping between firmware and software

The mapping between the registers on the AXI bus in the firmware and the software is handled as part of the repository structure and the Ruckus file structure (see slide 6).

Structure from the Simple-PGPv4-KCU105-Example repository:

An example is the mapping of the SYSMON module inside the Core module to the Python description of the target. The different Python scripts and GUIs in the software directory are loading the simple_pgp4_kcu105_example as a package (DevGUI.py, fileReader.py, etc.) which brings the mapping of the different modules in the firmware into the software.

The following mapping is used for the Simple-PGPv4-KCU105-Example design:

Root modulePeripheral moduleBase address
Core

0x0000_0000


AxiVersion

0x0000_0000


AxiSysMonUltraScale

0x0001_0000


AxiMicronN25Q(0)

0x0002_0000


AxiMicronN25Q(1)

0x0003_0000


Pgp4AxiL0x0010_0000

AxiStreamMonAxiL0x0011_0000

Sfp0x0020_2000
App
0x8000_0000

AppTx0x8000_0000

AppMem0x8001_0000

Firmware software mapping in SURF library

Many of the firmware modules that are available in SURF have Python classes with the register-variable mapping already done. These can be found in the python/surf directory in the SURF repository.

An example of this from the Simple-PGPv4-KCU105-Example design is the AxiVersion class which is defined in SURF under python/surf/axi/_AxiVersion.py.

The registers that are part of the AxiVersion module use the RemoteVariable class that is part of pyrogue. Similarly, the AppTx module in the example design has its registers defined as RemoteVariable class instances.

Adding new registers

The steps to add a new register in an application module and expose it to the Rogue software are:

  • Add the register in the HDL module in the firmware (e.g. here in AppTx.vhd, also need to add the AXI logic for the register with axiSlaveRegister())
  • Update the Python description of the firmware (e.g. here in _AppTx.py)
  • Done


  • No labels