Deadlock occurs when using InsertImage with a loop

  • Hi Jesse,

    if you just want to insert the previous image above the current image, I would go for a more simple approach. Just double the input image in front of the InsertIamge and remove the first image in the second path. A buffer is needed in the first path while waiting for the insertion of path two.


    But I'm not sure if this is the answer to your question, since you have some modulo counts with divisor 15 or 16 in your design that I don't understand. So, if my approach doesn't fit your task, please give me some feedback with more details.

    Best regards,


  • Hi,

    you can find the solution for removing unwanted deadlock as a screenshot below and design here:


    Since InsertImage will only forward on a single channel, the others are in wait (blocked, inhibit, stop, ...) state and require buffering, cause by all channels being sourced by the same M-Type: "Sync" in here.
    So the RAM1 needs to be in fron of module 13.
    Please be aware that a following image is required to run the second (lower) channel of "module26".

    Best regards,

  • Hi Jesse,

    Please be aware that a following image is required to run the second (lower) channel of "module26".

    Taken from:…nization.InsertImage.html

    "The operator InsertImage multiplexes a number of n input links I[0] .. I[n-1] into the output link O. Thus the operator outputs the input images of all inputs in sequential order at O.

    The operator forwards the input images to the output one after the other. First, input link I[0] is processed, next link I[1]. After link I[n-1] the operator starts with the next image at I[0] again etc. The operator waits until an image at a currently selected input is present. Therefore it is not possible to skip inputs."...

    Best regards,


  • Hi Jesse Lin,

    Thank you for your feedback.

    And I try to use other methods to remove unwanted frames ,but the buffer will overflow. Camera line rate = 10k Hz.

    Please give me some advice.

    Based on your input the line width is 8k = 8192 pixels per line and you can see a FillLevel at a linerate of 10 kHz of 75%.
    A certain FillLevel is OK, but we need to look into it based on the resulting/required bandwidth.
    One possible bottle-neck is the parallelism within the links, and especially:

    • Memory Interface
    • DMA performance

    The CXP camera interface is focussing up to 2 GB/s:


    Since you nearly double the bandwidth due to the overlap, please consider to use a higher(up to double) paralleism in the links.

    The DMA will accept a connection of up to 16x 8 bit = theoretical 2 GB/s, practically it will be limited to 1800 MB/s.
    The memory interface can handle up to 11.2 GB/s (shared between all RAM-modules) and read/write access will add up.

    When I look into your design I would recommend the approach below to generate an overlap on basis of a single RAM:


    That would save RAM modules/FPGA ressources and you do not need to write the same data twice...

    Related VA design:

    Based on the ROI settings within BufferX2 you can reduce the overlapping part easily...
    I have seen that you use a more complex approach on when to overlap, but that is something you can adopt into this design.
    Just consider using DynamicROI operator if you require a more dynamic approach into the above functionality.
    ImageBufferMultiROIdyn would be a second valid candidate.

    Best regards,

  • Hi Björn Rudde

    Thank for your support that let me learn something.

    The VA design saves a lot of buffer resources.:thumbup::thumbup::thumbup:

    Hi Oliver

    Thank for your approach.

    We find a better way without InsertImage that can reduce the consideration of synchronization.

    You can refer this design and simulation it.

    Hope it will be helpful to your future application.


  • Hi Oliver and Jesse,

    It was a pleasure to discuss the VA design approach with both of you.

    One additional hint:

    • In case the ImageBufferMultiROI(dyn) is not flexible enough to generate additional kinds of overlapping image regions you could potentially use the FrameBufferRandomRead operator for it. One trade-off is the limitation to a single image to image relationship in between of the input and the output, but it generally enables an additional left right shift including overlap.

    One application would be auto-follow of a certain region of image.

    Best regards,