Multi-protocol interface camera simulation system and method

Abstract

The invention relates to a camera simulation system and method supporting a multi-protocol interface, and belongs to the technical field of electronic test equipment and image processing. Aiming at the problems that an existing camera test system depends on a single interface protocol, hardware needs to be replaced frequently, and test image parameters are not flexible to adjust, the invention provides a dynamic switching scheme based on FPGA local reconstruction and software driving. Multi-protocol dynamic switching: real-time switching of protocols such as Camera Link, CoaXPress and the like is realized through an FPGA (Field Programmable Gate Array) local reconstruction technology, and hardware does not need to be replaced or a test process does not need to be interrupted; the test image is dynamically generated, parameters are allowed to be adjusted in real time, and the high-precision test requirement is met. The method is suitable for simulation tests of high-speed industrial cameras, scientific imaging equipment and multi-protocol compatible systems, and particularly has remarkable advantages in an automatic test environment in which interface protocols need to be frequently switched or image features need to be adjusted in real time.

Description

Technical Field

[0001] The present invention relates to the fields of electronic testing equipment and image processing technology, and more specifically, to a system and method that supports dynamic switching of multi-protocol camera interfaces. This system is particularly suitable for simulation testing of high-speed industrial cameras and scientific imaging equipment, capable of generating vertical stripe, horizontal stripe, and Gaussian pattern test images in real time. This software-driven system achieves dynamic switching of multi-protocol interfaces, avoiding the frequent hardware replacement issues of traditional testing systems. It also provides flexible test image generation capabilities to meet the needs of different interface protocols and testing scenarios. Background Art

[0002] Existing camera test systems typically use a single interface protocol (such as Camera Link or GigE Vision), making them difficult to adapt to multi-protocol scenarios. Frequent hardware changes during testing are inefficient, and the varying electrical characteristics of different interfaces can easily lead to signal integrity degradation. For example, Camera Link uses LVDS signaling, while CoaXPress employs full-duplex transmission over coaxial cables. These two devices have significant electrical differences and require different hardware support.

[0003] Furthermore, existing test image generation methods lack flexibility, making it difficult to dynamically adjust parameters (such as fringe width and noise level) and unable to meet high-precision testing requirements. Traditional methods typically require offline parameter configuration and a system restart, making it impossible to adjust test images in real time. For example, while Gidel's CamSim camera simulator supports multiple protocols, parameter modifications require reconfiguration and restarting the data flow through the GUI or API, making it impossible to dynamically adjust fringe width or noise distribution during image generation.

[0004] Furthermore, existing technologies have the following shortcomings: 1. Protocol switching relies on hardware configuration: For example, CamSim requires external triggering or FPGA programming to switch protocols, which cannot be done dynamically in real time. Manual adjustment of hardware parameters or restarting of services are required, resulting in test interruptions. 2. High cost of multi-protocol expansion: Supporting new protocols requires redesigning FPGA logic or adding dedicated hardware modules, making system upgrades complex and costly.

[0005] Therefore, there is an urgent need for a test system that supports dynamic switching of multiple protocols and has high flexibility, which can adjust the protocol and test image parameters in real time without interrupting the test process. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this paper proposes a multi-protocol interface camera simulation system and method. This system utilizes FPGA dynamic reconfiguration technology to achieve seamless switching of multi-protocol interfaces, while also providing flexible test image generation and supporting real-time dynamic parameter adjustment.

[0007] The core of this invention lies in utilizing FPGA local dynamic reconfiguration technology to divide the FPGA into a static area and a reconfigurable area. The static area contains general control modules (such as host computer instruction parsing and external memory interfaces), while the reconfigurable area contains protocol stack modules (such as the LVDS driver for Camera Link, the 8B / 10B encoder for CoaXPress, and the TCP / IP protocol stack for GigE Vision). This allows the system to reconfigure only the protocol stack modules without disrupting other functions, enabling rapid protocol switching.

[0008] Another core feature of the present invention lies in the flexible implementation of the test image generation algorithm. The system supports the generation of vertical stripes, horizontal stripes, and Gaussian pattern test images, and enables real-time dynamic adjustment of parameters through register configuration. Specifically, the present invention includes the following technical features: Multi-protocol interface support: The system supports multiple industrial camera interface protocols such as Camera Link, CoaXPress, and GigE Vision, and can flexibly meet the needs of different industrial scenarios or camera testing scenarios, and can dynamically switch according to needs.

[0009] FPGA dynamic reconfiguration mechanism: Utilizing local dynamic reconfiguration technology, the FPGA is divided into a static region and a reconfigurable region. The static region contains general control modules, while the reconfigurable region contains protocol stack modules. During protocol switching, only the reconfigurable region is reconfigured, avoiding the high latency of global reconfiguration.

[0010] Test pattern generation algorithm: The system supports generating vertical stripe, horizontal stripe, and Gaussian pattern test patterns. Vertical stripes use a horizontal counter to control column position, while horizontal stripes use a vertical counter to divide the stripes. The Gaussian pattern uses an LFSR to generate uniformly distributed pseudo-random numbers, which are then converted to a Gaussian distribution using the central limit theorem.

[0011] Dynamic parameter adjustment: All test image parameters (such as stripe width and noise intensity) can be updated in real time via the AXI4-Lite bus without restarting the system.

[0012] Low-latency design: The system uses a dual-buffer design and clock domain synchronization technology to ensure low latency during protocol switching and parameter adjustment, with end-to-end latency less than 100ms. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0014] Figure 1 This is the overall system architecture diagram, showing the connection relationship between FPGA, host computer control module and external memory.

[0015] Figure 2 It is a diagram of the internal module division of FPGA, showing the division of static area and reconfigurable area, as well as the interaction relationship between various functional modules.

[0016] Figure 3 It is a protocol switching flow chart, which shows the complete process from host computer instructions to FPGA local reconstruction.

[0017] Figure 4 It is a flow chart of dynamic parameter adjustment, showing the mechanism of real-time updating of test image parameters through the AXI bus. DETAILED DESCRIPTION

[0018] The system architecture of the present invention is as follows Figure 1 As shown in the figure, the system primarily consists of an FPGA development board, a host computer control module, and external memory. The FPGA development board is the core of the system, responsible for simulating multi-protocol interfaces and generating test images. The host computer control module provides a user interface for configuring protocols and test image parameters. The external memory is used to store bitstream files for different protocols and test image data.

[0019] The internal modules of the FPGA of the present invention are divided as follows Figure 2 As shown, it mainly includes the following modules: Protocol Parser: As the system's command processing core, the protocol parser is responsible for parsing protocol switching commands sent by the host computer and triggering the corresponding reconstruction process. This module receives configuration information via the AXI4-Lite bus, performs syntax analysis and semantic verification on the commands, and generates control signals to drive other modules to complete protocol adaptation.

[0020] Image Generation Engine: This engine integrates multiple test pattern generation algorithms to generate vertical stripes, horizontal stripes, and Gaussian pattern test images in real time based on the control unit's configuration. This engine utilizes a parametric design that supports dynamic adjustment of key parameters such as stripe width, height, and noise intensity.

[0021] Interface Adapter: Dynamically adjusts the FPGA's I / O interfaces and signal characteristics based on the current protocol configuration, ensuring electrical compatibility and timing matching with different protocols. This module supports partial reconfiguration and can switch protocols at runtime.

[0022] Control Unit: As the system's core dispatch center, it coordinates the work of various modules, manages data flow paths, and implements error detection and recovery mechanisms. This unit implements multi-task scheduling through a state machine to ensure efficient and stable system operation.

[0023] External memory interface: used to access bit stream files and test image data stored in external memory.

[0024] The multi-protocol interface switching mechanism of the present invention is based on FPGA local dynamic reconfiguration technology, such as Figure 3 The specific process is as follows: The host computer sends a protocol switching command: The user selects the target protocol (such as Camera Link or CoaXPress) through the host computer interface and sends a switching command.

[0025] The protocol parsing module receives the instruction: The protocol parsing module in the FPGA receives and parses the instruction to determine the target protocol to be switched.

[0026] The FPGA's reconfigurable host loads the protocol-specific bitstream file from external memory (DDR3). The bitstream file is pre-generated and stored at a fixed address in the external memory. The bitstream file contains configuration data for the reconfigurable region (such as logic gates and routing information) and the reserved configuration for the static region. The bitstream file's storage address is located based on the target protocol identifier (such as Camera Link). AXI bus transfers: The bitstream file is loaded using burst reads over the AXI4-Full bus. After loading, the integrity of the bitstream file is verified (e.g., hash checksum). Hash checksums are a technique used to verify data integrity. They generate a unique hash value (also called a digest) from the bitstream file. A hash value is a fixed-length string generated by a hash function (such as MD5, SHA-1, or SHA-256). The same input data always generates the same hash value, and even slight changes to the input data will result in a completely different hash value. Regardless of the input data size, the hash value has a fixed length (e.g., 128 bits for MD5 and 256 bits for SHA-256). By calculating the hash value and comparing it with the official hash value, the integrity of the file (i.e., it has not been tampered with or damaged) is confirmed. Finally, the bitstream file is cached in the FPGA's configuration RAM.

[0027] Local Reconfiguration Region Update: Updates only the reconfigurable region in the FPGA, leaving the logic in the static region unchanged. Sending a RECONFIGURE command via the ICAP interface freezes the logic in the target RP region, then writing the new configuration: Writing the bitstream file to the RP region's configuration memory (e.g., block RAM). Release: Releases the freeze, allowing the RP region to be reinitialized with the new configuration. Incremental placement and routing, along with timing closure checks, ensures reconfiguration time is ≤ 5ms. Data flow through the static region's buffers remains uninterrupted during reconfiguration.

[0028] Interface adapter parameter adjustment: Adjust the FPGA's I / O interface and signal characteristics (such as clock frequency, voltage level, and encoding method) based on the new protocol requirements. Clock adjustment: Use PLLs or clock management IP cores (such as Xilinx's MMCM) to adjust clock frequencies (e.g., 85MHz for Camera Link vs. 6.25Gbps for CoaXPress). Voltage level: Use I / O bank configuration to adjust voltage standards (e.g., 3.3V for LVDS vs. 1.8V for CMOS). Encoding method: Switch encoding methods based on protocol requirements (e.g., LVDS driver vs. 8B / 10B encoding).

[0029] In addition, an asynchronous FIFO is inserted. Asynchronous FIFO is a hardware structure used for data transmission across clock domains. It can effectively solve data synchronization issues between different clock domains, ensuring data integrity and system stability. Inserting an asynchronous FIFO between the static area and the reconfigurable area avoids metastability issues.

[0030] The ready / valid signals also ensure data accuracy during cross-clock domain transmission. The sender sets the valid signal high when data is ready, indicating that the data is valid. The receiver sets the ready signal high when it is ready to receive data. Data is transmitted on the clock edge only when both the valid and ready signals are high. This mechanism avoids unexpected data changes between clock domains, ensures data accuracy and consistency, and prevents deadlock.

[0031] Protocol Switch Complete: The system completes the protocol switch and operates in the new protocol mode without interrupting data flow. The reconfig_done signal is detected to confirm the success of the partial reconstruction. Interface Signal Integrity: Physical layer signal quality is verified through eye diagram testing or bit error rate testing (BERT). Double Buffer Mechanism: During the reconstruction period, data streams are temporarily stored in a buffer in the static area, allowing a seamless switch to the new protocol after the reconstruction is complete. Pipeline Processing: A pipeline design minimizes the impact of the reconstruction on real-time data flow. After the protocol switch is completed, the system continues to operate in the new protocol mode without interrupting data flow.

[0032] In addition, the test image generation algorithm of the present invention includes the following three modes: Vertical stripe generation algorithm: The column position is controlled by a horizontal counter (h_counter), for example, switching colors every 40 columns. The stripe width is dynamically controlled by register configuration parameters (such as strip_width). Colors can be set using RGB values ​​or a predefined palette. The resulting vertical stripe image can be used to test the camera's horizontal resolution and color reproduction capabilities.

[0033] Horizontal stripe generation algorithm: The stripes are divided by a vertical counter (v_counter), for example, switching colors every 80 lines. The stripe height is dynamically controlled by register configuration parameters (such as strip_height). Colors can be set using RGB values ​​or a predefined palette. The resulting horizontal stripe image can be used to test the camera's vertical resolution and dynamic range.

[0034] Gaussian pattern generation algorithm: Gaussian noise superposition: LFSR is used to generate uniformly distributed pseudo-random numbers, and 12-level random numbers are superimposed through the central limit theorem to generate an approximate Gaussian distribution.

[0035] FSR generates uniform random numbers ( ).

[0036] Box-Muller transform: , , , (X, Y are independent Gaussian distributed random numbers with mean 0 and variance 1).

[0037] 12-level superposition: Superposition of uniform random numbers via the central limit theorem to approximate a Gaussian distribution.

[0038] Parameter: Noise intensity (configured via AXI4-Lite real-time).

[0039] Gaussian blur: A one-dimensional Gaussian filter based on row-column separation. The blur level is adjusted using a programmable σ value (e.g., gaussSigma). The noise intensity (σ²) is controlled by a register parameter (e.g., noiseVariance) and supports dynamic adjustment.

[0040] All test image parameters can be updated in real time via the AXI4-Lite bus, such as Figure 4 For example, after changing the stripe width, the system takes effect within milliseconds without having to restart.

[0041] The parameter dynamic adjustment method of the present invention combines register configuration and local reconstruction technology, such as Figure 4The specific implementation is as follows: Register Configuration: All test image parameters (such as stripe width, noise intensity, and blur level) are written to FPGA registers via the AXI4-Lite bus. These registers directly control the operating parameters of the image generation engine, and modifications take effect immediately.

[0042] Protocol-related parameter adjustments: When switching protocols, some parameters (such as resolution and frame rate) need to be adjusted according to the characteristics of the new protocol. These parameters are also configured through registers to ensure that the image generation matches the protocol characteristics.

[0043] Algorithm Logic Switching: If the algorithm logic needs to be modified (e.g., switching from Gaussian noise to salt and pepper noise), a new bitstream file must be loaded using a local reconstruction technique. This reconstruction only affects the reconfigurable area and does not affect other parts of the image generation engine, ensuring that the system maintains basic functionality during the reconstruction.

[0044] Parameter synchronization mechanism: The system adds timestamps to image data through the PTP protocol to ensure that image parameters and noise / fringe parameters under different protocol interfaces are dynamically matched to avoid timing conflicts.

[0045] Example The following is a specific embodiment, showing the workflow of the system of the present invention: Hardware configuration: - FPGA chip: Xilinx Kintex-7 XC7K325T - Supported protocols: Camera LinkFull, CoaXPress 2.0, GigE Vision - Supported resolution: Up to 16K×1080 (24-bit) - Supported frame rate: Up to 1000fps - External memory: 16GB DDR3 Workflow: Initial configuration: The host computer selects the CoaXPress protocol through the GUI, configures a vertical stripe width of 20 pixels, Gaussian noise σ = 5, and a frame rate of 100 fps. The FPGA dynamically loads the CoaXPress protocol stack bitstream, adjusts the GTH transceiver parameters to 12.5 Gbps, and generates an initial test image.

[0046] Parameter adjustment during operation: When a user changes the stripe width to 30 pixels during runtime, the system updates register values ​​via the AXI bus, adjusting the image stream in real time without interruption. When a user switches the noise pattern from Gaussian to salt and pepper, the system generates the bitstream by loading the new noise through local reconstruction. The entire process takes just 5ms.

[0047] Protocol switching: When the user switches the protocol to Camera Link, the system loads the Camera Link protocol stack bitstream through a partial reconfiguration of the FPGA. The interface adapter adjusts the LVDS signal parameters to ensure compatibility with the Camera Link protocol. The system continues to operate in Camera Link mode at a frame rate of 60 fps (based on the bandwidth limitations of Camera Link Full mode).

[0048] Performance Verification: Monitor signal timing with a logic analyzer to verify the pixel clock (85MHz) and LVDS signal quality in Camera Link mode.

[0049] The end-to-end latency was measured using a high-speed acquisition card and the result was 72ms, meeting the real-time requirements of a high-speed camera at a frame rate of 1000fps.

[0050] Compared with traditional solutions (such as CamSim, which requires manual protocol configuration and a switching time of approximately 100ms), this system only takes 5ms to partially reconfigure, significantly improving test efficiency.

[0051] Parameter adjustment range: Stripe width: 1-200 pixels; Noise intensity: 0-20 (σ value); Blur degree: 1-10 (σ value); Frame rate: 1-1000fps (depending on protocol bandwidth limit); Resolution: configurable to multiple standard resolutions (such as 640×480, 1280×1024, 1920×1080, etc.).

[0052] Advantage verification data: Protocol switching time: 5ms (traditional solutions are about 100ms); end-to-end latency: 72ms (supporting 1000fps frame rate); resource usage: approximately 30% less than traditional solutions (through modular design and resource reuse).

Claims

1. A multi-protocol interface camera simulation system, characterized in that: include: FPGA chip, which is divided into static area and reconfigurable area; The static area contains the general control module and external memory interface, and the reconfigurable area contains the protocol stack module; An image generation engine, which includes a vertical stripe generator, a horizontal stripe generator, and a Gaussian pattern generator; Vertical stripe images are used to test the camera's horizontal resolution and color reproduction capabilities; The horizontal stripe image can be used to test the vertical resolution and dynamic range of the camera; the Gaussian pattern image is used to test the camera's pixel sensitivity uniformity and noise level under different light intensities; The protocol parsing module receives and parses the protocol switching instructions sent by the host computer; The control unit is used to coordinate the work of each module, manage the data flow path, and implement error detection and recovery mechanisms. It implements multi-task scheduling through a state machine to ensure efficient and stable operation of the system. An interface adapter is used to adjust the I / O interface and signal characteristics of the FPGA according to the current protocol configuration.

2. The multi-protocol interface camera simulation system according to claim 1, characterized in that: The image generation engine supports real-time generation of vertical stripes, horizontal stripes and Gaussian pattern test images, and supports dynamic adjustment of stripe width, height and noise intensity.

3. The multi-protocol interface camera simulation system according to claim 1, wherein: The protocol parsing module is used to parse the protocol switching instruction sent by the host computer and trigger the corresponding reconstruction process; the protocol parsing module receives configuration information through the AXI4-Lite bus, performs syntax analysis and semantic verification on the instruction, and generates a control signal.

4. The multi-protocol interface camera simulation system according to claim 3, characterized in that: The reconstruction process loads a bit stream file of the corresponding protocol from an external memory; the bit stream file contains configuration data of the reconfigurable area and the reserved configuration of the static area; The FPGA is used to load the bit stream file in a burst read mode through the AXI4-Full bus, and cache the bit stream file into the configuration RAM after verifying the integrity of the bit stream file.

5. The multi-protocol interface camera simulation system according to claim 1, wherein: The system supports CameraLink, CoaXPress, and GigEVision interfaces.

6. The multi-protocol interface camera simulation system according to claim 5, characterized in that: Adjust the FPGA's I / O interface and signal characteristics.

7. The multi-protocol interface camera simulation system according to claim 2, characterized in that: All test image parameters are written to FPGA registers via the AXI4-Lite bus. Modifications to the image generation engine's operating parameters take effect immediately. When protocols are switched, the resolution and frame rate need to be adjusted based on the characteristics of the new protocol. Register configuration ensures that image generation matches the protocol characteristics.

8. The multi-protocol interface camera simulation system according to claim 7, characterized in that: The system adds timestamps to image data through the PTP protocol to ensure dynamic matching of image parameters and noise / fringe parameters under different protocol interfaces to avoid timing conflicts.

9. A multi-protocol interface camera simulation method, characterized in that: The following steps are involved: (1) The host computer sends a protocol switching instruction; (2) The FPGA protocol parsing module receives and parses the instructions; (3) Reconstruct the host to load the bit stream file of the corresponding protocol from the external memory; (4) Partially reconfigure the reconfigurable area of ​​the FPGA; (5) The interface adapter adjusts the FPGA's I / O interface and signal characteristics; (6) The image generation engine generates test images based on the current protocol characteristics.

Images