Posts by B.Ru

  • MA-VCX-QP performance problem when using CoefficientBuffer

    Hi Pierre,


    Thank you for your input.

    Quote from Pierre Chatelier

    I think that here again, this is a documentation problem :

    I have juste checked that indeed, the CoefficientsBuffer ROI seems to be taken into account (regarding the fps), after writing 1 into UpdateROI *even if the value is already 1*

    Do you confirm ?

    Should it be the case, I also heavily suggest that the documentation of UpdateROI is updated to explain that !

    I forwarded your hint concerning the CoefficientBuffer in order to improve and extend our documentation.

  • MA-VCX-QP performance problem when using CoefficientBuffer

    Hi Pierre,


    When using the CoefficienBuffer please make sure that only the required image dimension is read out of it before synchronizing the coefficients with the real image data. In case the amount of read data is more than required bandwidth is getting "wasted".


    You need to write a 1 into its parameter UpdateROI to apply the changes during runtime.


    In case you want to optimize or simplify the parameter access and the configuration itself feel free to think of using the Parameter Library. By this you can implement a single parameter that handles all width/height for example.


    Only the maximum buffer width and height are static. The ROI values can be either static/dynamic depending on your preset during design time. If you set them to dynamic, these can be changed during runtime. Then you can adopt required changes concerning the ROI during runtime and reach the requested bandwidth without rebuilding.

  • MA-VCX-QP performance problem when using CoefficientBuffer

    Hi Pierre,


    Congratulations, that is fantastic!

    Quote from Pierre Chatelier

    Success !


    Setting the CoefficientBuffers to 8x(64b@2x) is OK. Now I have my 50 fps. (and I have already made and tested the program to split my Coefficent .tif files into 128b block parts).


    But I still don't understand why SyncToMax is needed instead of SyncToMin since all image sizes are identical.

    SyncToMin / SyncToMax is identical in case of images of same size, but:

    In case one of the image sources is delivering a larger image the output link is only supporting the minimum image dimension required. Due to that I went into my testing issue yesterday: I did not see that the CoefficientImage was too large...

    So I always prefer SyncToMax in case of identical sizes...

  • MA-VCX-QP performance problem when using CoefficientBuffer

    Hi Pierre,


    Concerning your first question. If you want to run mDisplay without camera,

    mDisplay -> Tools -> Settings -> Check "Ignore Camclock status" and apply:

    pasted-from-clipboard.png

    By this the connection to a camera is not checked before starting the acquisition.


    Concerning your second question:


    The ImageBuffer FillLevel needs to be below 75% (better 0%) to investigate the maximum bandwidth supported.

    Otherwise the delivered data can not be processed/transferred fast enough.


    Please use the way the Coefficient buffer in my VA design QuadCXP_Shading_BRudde_FakeCAM.va is used.

    The reason for this is the internal memory bandwidth handling of that operator.

    More details on that can be found in a different thread.

    We need full performance of 12.2 GB/s here, so the link needs to be:


    8 Link, Par 2 12201 MB/s 512 MiB

  • CXPSingleCamera output empty image when no trigger signal input.

    Hi Jesse,


    I looked through the camera manual and I found no mentioned reason why the camera should send unmotivated lines in external trigger mode, while no trigger is send.

    You have to contact the camera manufacturers support for more details on this.


    From the VA design perspective I do not see an obvious reason for these unmotivate lines.

  • CXPSingleCamera output empty image when no trigger signal input.

    Thank you.

    Quote from Jesse Lin

    This is your design result [Test video].

    1. Yes. It is external trigger mode.

    2. In your design trigger signal is period.

    3. TriggerMismatch.Status is jumping between of 9 and 10.

    In this video we can see that the external line trigger is working as expected, in case we are sending it.

    This is showing that the line trigger and the camera response work together.


    But there are two questions now:

    • Why there is there a mismatch of 9 to 10 lines?
      • What kind of sensor (Dual-Line, Multi-Line, TDI, ...) is used?
        For example a TDI with 8 stages could be the reason for 8 triggers being required for the first line feedback...
    • Why do we receive lines while not sending triggers?
      • This may be a camera feature, but I have no explanation for that.

    From my point of view both questions are something where the camera manual or the camera manufacturer support can give an answer. Is it possible to mention the camera name/manufacturer?

  • CXPSingleCamera output empty image when no trigger signal input.

    Dear Jesse,


    Thank you for your efforts.

    Quote from Jesse Lin

    In this design mE5MA_VCX-QP_Single_EncoderTest.va , the received lines counter still increase [Test video].

    I watched the video and the camera is sending lines, while no trigger is send.

    If you want, you can use Select operator and Gnd to detatch the trigger completely in front of the camera.


    Since the VA design is receiving lines at a certain rate - from the video I would suggest around 1 Hz - this seems to be a feature of the camera.

    So the camera configuration needs to be investigated.

  • CXPSingleCamera output empty image when no trigger signal input.

    Dear Jesse,

    Quote from Jesse Lin

    Why is there no trigger signal input but the camera still outputs the image?

    Please check with the VA design I posted above, if the line scan camera and the line trigger work as expected.

    1. Configure the line scan camera for external trigger.
    2. Send CXP trigger signals to the line scan camera.
    3. Check if Amount of triggers matches the received number of lines.

    If the line trigger works as expected, then we can go one step further.

    Then we can use the ShaftEncoder direction and use this as a mask for the image trigger and/or transfer.

  • MA-VCX-QP performance problem when using CoefficientBuffer

    Dear Pierre,


    After the synthesis a runtime investigation was done by using our Runtime/SDK 5.7.0 x64 Windows.

    Some more details on the used hardware can be seen in the screenshot below:

    pasted-from-clipboard.png


    Especially the DMA/PCIe details are of interest in order to see if all conditions are met to expect a maximum DMA performance. In case the DMA performance would be limited this could lead to a resticted performance.


    In microDiagnostics the Performance dialog is showing the maximum bandwidth's for severalk image resolutions:

    pasted-from-clipboard.png

    Since the test design is based on 1024 x 1024 x 8 bit = 1 MB images I would expect a theoretical maximum of 1800 frames/s in the real test.


    After flashing the synthesized applet into the hardware, activating it and loading in microDisplay a simple test acquisition was started. For the tests a "fake" camera (that was designed into this applet you can download below) was used.


    During first testing attempts the number of frames per second received that did not match the discussed expectations.

    So a quick review was done and a good reason for this limitation could be found:

    The coefficient images were much too large, and that was slowing down the overall performance.

    Because the large images need to be read out of the RAM, wasting the bandwidth...


    So the VA design default preset was modified, the SYNC changed "toMax", so that this issue will not arise without notification again.


    Then the performance reached at least 1600 Hz = (1600 Hz) * 1024 * 1024 * (8 bit) = 1 677.7216 MB / s


    pasted-from-clipboard.png


    A maximum bandwidth of 1800 Hz at a resolution of 1024 * 1024 * 8 bit = 1 MB per image would require a slight trick.

    Please add several image to each other by using AppendImage since "small" DMA transfers reduce the efficiency.

    Please have a look at the DMA bandwidth performance dialog (resolution and 48bit per pixel), where you can see what transfer size you require for reaching 1800 MB/s.


    Thank you for your patience...


    Here you can download the IMPROVED/FIXED design.

    QuadCXP_Shading_BRudde_FakeCAM.va

  • MA-VCX-QP performance problem when using CoefficientBuffer

    Dear Pierre,


    Thank you for your precise description.


    Below you can see a stripped down design that is showing the aspects of the shared memory setup for shading correction:

    pasted-from-clipboard.png

    Download VA design sources: QuadCXP_Shading_BRudde.va (Please download the fixed version in the post below... ;-)


    Here the design has to take care of shared memory.

    So we increase to maximum bandwidth for ALL buffers:

    64 * 8 bit = 512 bit

    As soon as we use 512 bit (mE5-MA-VCX-QP) for all buffers, we can receive maximum performance.

    The 512 bit are based on the memory interface and can be found in the appendix of the VA documentation.

    In case we do not take care of this side effect over here:

    This will slow down all other memory buffers,

    even if those are connected at higher bandwidth option.


    Around the ImageBuffer:

    ParallelUP to get the maximum performance...

    ParallelDN is taking care of mean target bandwidth.


    So far I did not check this in hardware, but the synthesis is running right now.



    I will update my measurement results in the next post...