SystemC framework for architecture modelling of electronic systems in future particle detectors

The prototyping cost in advanced technology nodes and the complexity of future detectors require the adoption of a system design approach common in the industry: design space exploration through high-level architectural studies to achieve clear and optimized specifications. This contribution proposes a configurable SystemC framework to simulate the readout chain from the front-end chips to the detector back-end. The model is transaction accurate, includes an event generator, interfaces with real physics events, and provides metrics such as readout efficiency, latency, and average queue occupancy. This contribution details the structure of the framework and describes a case study based on the LHCb VeLo upgrade II.


Introduction
The CERN EP department has launched a strategic R&D programme [1] on technologies for future experiments.In this context, the IC technology work package, also called WP5, is developing a simulation framework, called PixESL, for the architectural modelling of future particle detectors.This work focuses on modelling pixel-based detectors, from front-end to back-end, at a high level of abstraction to perform architectural studies.The objective is to study the readout network efficiency and provide the metrics to compare different solutions to satisfy functional and non-functional requirements, such as data throughput, data quality, downlink material cost, and other parameters detector-wise and at the ASIC level.At the same time, it can provide a reference model for system design, which includes several ASICs and some components of the back-end system.
The proposed framework adopts ESL, or Electronic System-Level design, a methodology for modelling and simulating complex electronic systems.It focuses on designing at a higher level of abstraction than traditional hardware description languages (HDLs) like VHDL or Verilog.ESL design is particularly useful for designing System-on-Chip (SoC), complex integrated circuits, and embedded systems.The key aspects of the PixESL framework are: • Abstraction: the design starts at a higher level of abstraction, capturing the system's functionality and behavior rather than low-level hardware details.This allows designers to work with functional blocks, interfaces, and data flow before diving into specific hardware components.
• System-Level Perspective: the design takes a holistic view of the entire system, including hardware and software components.It enables the design and verification of the entire system, not just individual hardware modules.
• Modelling: designers create high-level models and abstractions of the system's behavior.The models are based on SystemC, a system-level description language.
• Simulation and Analysis: the readout chips' models are used for simulation and analysis to verify system functionality, performance, and other characteristics.Designers can explore different design options and configurations at this stage.
• Performance Estimation: the framework allows for early system performance estimation, such as power consumption, execution time, and resource utilization.This helps in making design decisions that meet performance goals.
-1 - • Design Space Exploration: designers can explore different architectural choices, configurations, and trade-offs to optimize the system's performance and cost.This exploration is critical for achieving design objectives efficiently.
• Validation: the design helps validate the system's requirements early, ensuring that the final product will meet its intended purpose.Identifying and addressing issues before they become costly can save time and resources.
In summary, the PixESL framework proposes a system-level approach to the electronic system design of particle detectors that focuses on abstraction, modelling, simulation, and the concurrent development of hardware and software.It facilitates a top-down design approach and helps designers create efficient, well-optimized electronic systems by providing a high-level perspective and enabling early validation of design choices.This paper presents a preliminary implementation of the framework and a proof-of-concept study based on the LHCb VeLo upgrade II.

Framework description
The framework is composed by three main modules, a SystemC modelling environment, an event generator, and a Python analysis toolset.They are used together to simulate a given architecture and evaluate its performance.SystemC modelling environment.SystemC [2] is a C++ library that provides a discrete-event simulation kernel along with C++ classes to simulate concurrent processes.It provides a way to model the behavior of a system at various abstraction levels and allows encapsulations of components as modules, which can be reused in different parts of the framework.This modularity promotes code reusability and reduces development time.SystemC's abstraction allows for a functional description of modules rather than a description of the connections between registers and logic gates, to study the system without the burden of a hardware description language at the Register Transfer Level (RTL) abstraction.
The readout architecture of pixel detectors is a regular network of nodes whose goal is to concentrate digitized data from a large number of sources, the pixels, into a limited amount of output channels.This readout network can be modeled as a tree-like hierarchy of nodes, based on the order followed by packets going from leaves, the pixels, to the root, the system output.The nodes belonging to the same hierarchical level called layer, are identical and include: • communication methods to exchange packets with nearby nodes; • arbitration and routing functions to decide from where to receive data and where to send it; • memory elements to act as temporary storage.
A readout architecture model is created by describing a network of these nodes that defines the connections between elements in the same layer and between parent and children layers.Currently, this model is implemented in SystemC with TLM-2.0 [3] non-blocking transport and follows a pull-based communication semantics with clock-based timing.Each layer's function or element describes processes sensitive to a clock signal representing the node's functions.Whenever a node has -2 - storage available, it issues pull requests through a forward transport call to the other connected nodes on a clock event.Upon receiving a request, each node waits for a simulation delta cycle to accumulate other possible requests.Then, the routing function selects the request with the higher priority and sends data to that node, ending the transaction with a backward transport call.
To model this system, a description of a generic layer with communication, memory, arbitration, and routing functions has been developed and then specialized based on the specific layers.For example, the generic layer is designed to communicate with other modules using a pull-based protocol, but in the case of the pixel-superpixel links, a special protocol was added because of the asynchronous nature of pixels in the model.

Input stimuli and event generator.
To simulate the detector model, input stimuli can be provided externally as a list of pixel hits, or can be generated internally by a configurable event generator that provides several classes of cluster types and spatial distributions.
The input stimuli are comma-separated value files containing a list of pixel hits, each carrying at least the pixel coordinate, the Time-of-Arrival (ToA), and the Time-over-Threshold (ToT) information.Otherwise, a built-in event generator is bundled with the model: it provides different event types, enabling the user to configure the rate and patterns of possible particle hits on the detector.These types include single-pixel, diamond-shaped, or straight clusters, which can be uniformly distributed over the detector or follow Gaussian or exponential spatial distributions.

Python-based results and metrics analyzer.
The framework includes a Python3-based results and metrics analyzer to help process and interpret the output data generated by visualizing the results, assessing the performance, automatizing the process of collecting and analyzing metrics, and adding alerting and reporting features.
Python, among the open-source languages, is chosen because of its ease of learning and use, its rich ecosystem, and community support.The results and metrics analyzer should also be accessible to framework users who might not have any expertise in SystemC.Since the model aims to evaluate readout architectures and configurations, data and statistics are logged in each SystemC node and then processed and analyzed by the Python analyzer.
These results can be scalar values, such as the readout efficiency or the average packet latency, which allow a quick comparison of different systems or plots and maps, such as memory occupancy or data loss, to spot architecture limitations such as bandwidth bottlenecks.
-3 -  able to sustain such a high input rate and present drastic congestion of data packets.To counteract this issue, the proposed architecture doubles the region columns, EoC nodes, and output channels as shown in table 1: this doubles the maximum throughput of the system from 64 to 128 packets/cycle.On the other hand, to mitigate the hardware overhead, the number of regions per column has been halved.The proposed architecture presents a 100% readout efficiency, meaning no event is lost, and an average latency of 17 cycles, seven times lower than the Velopix architecture.

Figure 1 .
Figure 1.Block diagram of two nodes including the associated transport functions.

Figure 3 .
Figure 3. Map of the injected pixel hits.Figure 4. Map of the lost pixel hits for VeloPix.

Figure 4 .
Figure 3. Map of the injected pixel hits.Figure 4. Map of the lost pixel hits for VeloPix.