[FEATURE] all the examples shows only waveform with one sample unit，But real waveform is sampled by oscilloscope may have a rise and fall

[louhaixin]

Feature Request: Realistic Waveform Generation with UI-based Processing

Is your feature request related to a problem? Please describe.

Yes. The current waveform generation in the codebase produces signals that are significantly different from real oscilloscope-captured waveforms. Specifically:

1. Bit-level sampling vs. realistic waveforms: The current implementation generates waveforms at the bit/sample level, which results in ideal rectangular signals without realistic signal characteristics.

2. Missing signal transitions: Real oscilloscope waveforms exhibit finite rise and fall times due to physical limitations of transmitters, channels, and receivers. The current code generates instantaneous transitions that don't reflect real-world behavior.

3. Lack of CDR (Clock Data Recovery) processing: Real SerDes systems require CDR to recover the clock and properly sample the data. The current implementation doesn't include CDR functionality, which is essential for accurate signal analysis.

4. Incorrect processing units for FFE: The current FFE (Feed-Forward Equalizer) implementation processes signals sample-by-sample, but real hardware FFE operates on UI (Unit Interval) boundaries. This fundamental mismatch means the equalization behavior doesn't match actual hardware implementations.

5. Missing CTLE convolution: While CTLE (Continuous-Time Linear Equalizer) can be applied via convolution, the current codebase doesn't provide this functionality in a clear, accessible manner.

These limitations make it difficult to:

• Validate equalization algorithms against real hardware behavior
• Perform accurate signal integrity analysis
• Simulate realistic channel effects
• Test CDR performance and timing recovery

Describe the solution you'd like

I would like to see the following enhancements implemented:

1. Realistic waveform generation with rise/fall times:

   • Add configurable rise time and fall time parameters to signal generation
   • Implement smooth transitions using appropriate models (e.g., exponential, linear, or RC-based)
   • Support different transition models for different signal types (NRZ, PAM4)

2. CDR (Clock Data Recovery) module:

   • Implement a CDR block that can recover clock from the data signal
   • Support different CDR algorithms (e.g., bang-bang CDR, linear CDR)
   • Provide clock recovery and data sampling functionality
   • Allow configurable CDR parameters (loop bandwidth, jitter tolerance, etc.)

3. UI-based FFE processing:

   • Refactor FFE implementation to operate on UI boundaries rather than sample-by-sample
   • Ensure FFE taps are aligned to UI intervals (multiples of samples_per_UI)
   • Match the behavior of real hardware FFE implementations
   • Maintain backward compatibility or provide clear migration path

4. CTLE convolution support:

   • Provide clear API for applying CTLE via convolution
   • Support frequency-domain and time-domain CTLE implementations
   • Allow configurable CTLE parameters (DC gain, pole/zero locations, bandwidth)

5. Comprehensive waveform processing pipeline:

   • Create a unified workflow: Signal Generation → Channel Effects → CTLE → FFE (UI-based) → CDR → Analysis
   • Ensure all processing stages work together seamlessly
   • Provide examples demonstrating the complete pipeline

Describe alternatives you've considered

1. Using external tools: Considered using commercial EDA tools (e.g., Cadence, Synopsys) or specialized SerDes simulation tools, but these are expensive and don't integrate well with the existing Python-based validation framework.

2. Post-processing existing waveforms: Attempted to add rise/fall times and CDR processing as post-processing steps, but this doesn't address the fundamental issue of UI-based FFE processing and doesn't match the natural signal generation flow.

3. Sample-based FFE with UI alignment: Considered keeping sample-based FFE but adding UI alignment logic, but this still doesn't match hardware behavior where FFE taps are inherently UI-aligned.

4. Separate modules: Thought about creating separate modules for each feature, but a unified, integrated approach would be more maintainable and user-friendly.

Additional context

Current Implementation Issues:

• data_analysis_example.py generates ideal rectangular waveforms without rise/fall times
• AdaptiveEqualizer.apply_equalization() processes signals sample-by-sample (not UI-aligned)
• No CDR functionality exists in the codebase
• CTLE application is not clearly demonstrated or accessible

Expected Behavior:

• Waveforms should show realistic transitions with configurable rise/fall times (e.g., 10-20% of UI)
• FFE should process signals with taps aligned to UI boundaries (e.g., pre-cursor at -1 UI, cursor at 0 UI, post-cursor at +1 UI)
• CDR should recover clock and provide properly sampled data
• CTLE should be easily applicable via convolution or frequency-domain filtering

Use Cases:

• Validating equalization algorithms against hardware measurements
• Simulating channel effects and equalization performance
• Testing signal integrity under various conditions
• Educational purposes to understand SerDes signal processing

Technical Notes:

• Sample rate: 100 GSa/s (current implementation)
• Symbol rate: 32 Gbps (current implementation)
• Samples per UI: ~3.125 samples/UI (current implementation)
• For UI-based FFE, taps should be spaced at integer multiples of samples_per_UI

Related Files:

• examples/data_analysis_example.py - Current waveform generation
• src/serdes_validation_framework/protocols/pcie/equalization.py - Current FFE implementation
• src/serdes_validation_framework/protocols/pcie/tx_waveform_generator.py - Waveform generation utilities

[muditbhargava66]

Your intuition is likely correct.

Thank you for opening this issue.

To investigate this further, I need to verify the specific test environment where this behavior is occurring. Please provide the following:

1. The Debug Traceback: Re-run your validation script with the environment variable SVF_LOG_LEVEL=DEBUG and paste the full output here. I need to see the initialization sequence for the USB4Validator class.
2. Configuration Settings: Please attach or paste the contents of your ~/.svf/usb4_config.yaml file (specifically the signal_mode and voltage_swing parameters).
3. Execution Mode: Are you seeing this issue while running in SVF_MOCK_MODE or with a live instrument connection?

Once you provide these logs, I can proceed with the analysis.

[louhaixin]

I did't use any "export **" commands before running *example.py file.
Since I don't have a live intrument connection beside, I alter the pcie_example.py a litter to generate a trapezoidal waveform, I put this waveform with the original waveform generated by the master together to illustrate more.
The waveform captured by a intrument is more closely to the trapezoidal waveform while the waveform master code generated likes a bit flapping one（meaning the signal UI is the sample interval.）

I would like to see a waveform validation（including eye diagram） for the trapezoidal waveform not the NRZ Simple Radom sampling showed in the picture.
I would like to see an eye diagram like the following picture

not the one generated by the master code like the following:

[muditbhargava66]

@louhaixin, thank you for the explanation and the comparison with your trapezoidal waveform.

However, after reviewing your comment and the codebase, it appears there is a misunderstanding regarding the scope of the current MockInstrumentController.

1. Scope of Mock Mode: The current mock implementation is designed primarily for functional verification of the protocol state machines (PCIe, Ethernet, USB4) and API logic. It uses simplified ideal symbols (rectangular/flapping) to validate that the software handles data, not to serve as a high-fidelity Signal Integrity (SI) physics simulator.
2. Feature Request vs. Bug: Your requests for finite rise/fall times, Clock Data Recovery (CDR), and Continuous Time Linear Equalization (CTLE) are valid feature requests for an advanced "Physics Simulation Mode," but they are not bugs in the current logic. The framework is behaving exactly as designed for its current version.
3. Modified Code: You mentioned: "I alter the pcie_example.py... to generate a trapezoidal waveform". Since you are reporting an issue based on your modified code rather than the functionality of the main branch, this confirms that the "bug" is not present in the released codebase.

Conclusion from my side: This issue describes a desire for higher-fidelity simulation features, not a defect in the current code. Since you did not provide the requested logs (SVF_LOG_LEVEL=DEBUG) or configuration files to show a failure in the unmodified code, I recommend closing this Issue.

If you would like to contribute a "High-Fidelity Simulation" module (implementing CDR, CTLE, and realistic pulse shaping), please open a Feature Request or submit a Pull Request.

[louhaixin]

Sorry， # @muditbhargava66
I actually submitted a feature request, not a bug report.
The misunderstanding may have been caused by a typo in the title

The purpose of my request is indeed to propose developing a new feature. hope you can reopen this issue and do this enhancement in the future