5.5 KiB
🧠 PS Subsystem (Control + Capture + Processing)
Overview
The PS subsystem is responsible for:
- System initialization
- Configuring PL subsystems
- Triggering captures
- Receiving data via DMA
- Preparing data for processing and visualization
The subsystem now includes an initial FrFT-based processing chain implemented in Simulink and targeted to the RFSoC Processing System (PS).
Current work focuses on:
- Algorithm validation
- Code generation
- Hardware integration
- Performance characterization
while maintaining reliable data acquisition and host interaction.
Responsibilities
Control & Initialization
-
Configure PL parameters:
- Tx waveform configuration
- Capture parameters (nFrames, etc.)
-
Initialize DMA and memory buffers
-
Manage system startup
Trigger & Capture
- Generates capture trigger (software-controlled)
- Controls DPW acquisition timing
- Each trigger initiates one DPW capture
DMA Handling
- AXI4-Stream → DMA (S2MM)
- Receives 128-bit stream (4 samples per clock)
- Stores data in PS DDR memory
Configuration:
- Frame size: 512 samples
- nFrames: configurable (validated up to 1024)
Data Format
Raw DMA Data
- Packed complex samples
- 16-bit real + 16-bit imag per sample
- 4 samples per 128-bit word
Processing Representation
Data is unpacked and reshaped into:
[FrameSize x nFrames x nTriggers]
or, for processing purposes,
[FrameSize x nFrames]
representing a single DPW.
Processing Pipeline (Current)
DMA
↓
Unpack samples (I/Q separation)
↓
Convert to complex representation
↓
Reshape into DPW matrix
↓
Processing Path Selection
Path A:
Polyphase Filter Bank (PFB)
↓
Power Spectrum
Path B:
FFT
↓
Power Spectrum
Path C:
FrFT
↓
Mean Power Spectrum
↓
Visualization / Analysis
FrFT Processing Status
A first FrFT processing implementation has been integrated into the PS subsystem.
Processing Flow
DPW [512 x nFrames]
↓
Halfband Interpolation (2x)
↓
FrFT Coefficient Generation
↓
DPW-Aware FrFT Processing
↓
Mean Power Spectrum
Software Structure
codegen_fracFdpw/
│
├── fracF_init.m
├── fracF_dpw.m
├── TBc_fracFdpw.m
└── TBm_fracFdpw.slx
Validation Completed
- DPW-aware FrFT implementation created
- Verified against original
fracF_cg - Bit-identical equivalence achieved
- MATLAB testbench (TBc) created
- Simulink model testbench (TBm) created
- TBc ↔ TBm comparison automated
- Bit-identical TBc ↔ TBm validation achieved
- Standalone subsystem code generation validated
- RFSoC PS integration completed
Current Status
The implementation is functionally correct and integrated into the RFSoC processing chain.
Current work is focused on:
- Performance characterization
- FrFT parameter optimization
- Realistic pulse processing scenarios
Open Technical Questions
The matched-order formulation used in the SPL simulations assumed:
Observation Window = Pulse Duration
The receiver currently operates under a different condition:
Observation Window < Pulse Duration
where only a portion of the pulse is processed by the FrFT.
Additional investigation is required to determine:
- Optimal FrFT order for partial-pulse observations
- Practical DPW sizes
- Trade-off between concentration and processing load
- Deviation from idealized SPL simulation conditions
Current Limitations
- Coefficients are regenerated every execution
- No coefficient caching implemented
- No NEON-specific optimization
- Generated FFT kernels are used
- Performance scales strongly with DPW size
Validation Support
Uses counter-based validation:
- Real part → sample counter
- Imag part → frame index
Enables verification of:
- Data continuity
- Frame alignment
- Correct ordering from DMA
Execution Model
- Triggered (event-based)
- Burst capture (DPW)
- Not continuous real-time streaming
Performance Notes
Current implementation prioritizes correctness and validation over optimization.
Observations from RFSoC integration:
- FrFT processing successfully executes on the RFSoC PS
- nFrames = 64 executes responsively
- nFrames = 1024 remains computationally expensive
- Processing load scales approximately linearly with DPW size
- Code generation and subsystem integration have been validated
Current optimization candidates:
- Coefficient caching when FrFT order remains unchanged
- NEON vectorization
- Alternative FFT implementations
- DPW size optimization
Role in System
The PS currently serves as:
- Control interface
- Data acquisition manager
- Signal processing platform
- Algorithm development and validation environment
Current processing capabilities include:
- PFB-based spectral analysis
- FFT-based spectral analysis
- FrFT-based spectral analysis
Future Work
FrFT
- Matched-order optimization for realistic pulse captures
- Performance profiling on RFSoC PS
- Coefficient caching
- NEON optimization
- Detection processing after FrFT concentration
System
- Timestamp integration
- UDP streaming
- Metadata extraction
- Migration of computationally intensive functions to PL where appropriate