Posts by B.Ru

    Dear Fabio,


    Thank you. I will use that target platform for your example.

    Me5 Marathon VCL

    • What camera/configuration wil be used?
      • Mode: CL BASE/MEDIUM/FULL/DECA ?
      • CL Taps: 1,2,3,8,10 ?
        • Or SFNC Tap-Geometry Name?
      • Planes: 1 = mono, 3 = color ?
      • Bit-Depth: 8,10,12,14 ?

    Best regards,

    Dear Fabio,


    I will generate an example design that controlls the sensor exposure duration on trigger pulse length.
    As soon as done I will post it here.


    Best regards

    Of course there are more online calculators...


    and Yes, Wolfram-Alpha is a good friend, too ;)

    delivering the same results in a more detailed fashion...


    Example:


    frame rate = bandwidth / size = (B * T * PXC) / (W * H * B) =

    (8 bit * 8 * 85 MHz) / (1920 * 1080 * 8 bit) =
    ((8 bit) * 8 * (85 MHz)) / (1920 * 1080 * (8 bit)) = 327.9 Hz,

    linked to wolfram-alpha calculator to place your own values.


    Fun fact: In case you earn a single $ per frame you process, what would you get per year:

    ((8 bit) * 8 * (85 MHz)) / (1920 * 1080 * (8 bit)) * 1 $ in € / year

    :saint:


    Best regards,

    Dear VA-Community,


    With this first post I would like to share a usefull approach on how to make VA related caluclations.

    The calulations itself are linked to the google calculator making the usage pretty simple...


    I think nearly everybody implementing or sketiching a VA design needs to take care of the over-all bandwidth concerning a CL/GigE/CXP/CLHS camera delivering or a PCIe DMA transfering data.


    For example related to camera interface, some general ideas:

    Bandwidth from CL camera

    CL camera is configured for CL FULL 8 bit with 8 taps and a pixel clock of 85 MHz:

    • bit depth = B = 8
    • tap count = T = 8
    • pixel clock = PXC = 85 MHz
    • bandwidth = B * T * PXC

    Theoretical maximum estimation, linked to Google:

    B * T * PXC = 8 bit * 8 * 85 MHz = (8 bit) * 8 * (85 MHz) = 680 MB / s , linked to google calculator to place your own values.

    Please be aware that this bandwidth is a theoretical value.


    While this is a camera / sensor related question, an estimation would be fine,

    Theoretical maximum frame rate on basis of bandwidth:

    • width = W = line length in pixels = 1920
    • height = H = amount of lines = 1080
    • bit depth = B = 8 bit
    • size = W * H * B = amount of data per image
    • framerate = bandwidth / size = bandwidth / (W * H * B)
      where bandwidth is B * T * PXC, see idea above

    frame rate = bandwidth / size = (B * T * PXC) / (W * H * B) =
    (8 bit * 8 * 85 MHz) / (1920 * 1080 * 8 bit) = ((8 bit) * 8 * (85 MHz)) / (1920 * 1080 * (8 bit)) = 327.9 Hz, linked to google calculator to place your own values.


    Bandwidth requirement on basis of frame dimension/size and frame rate:

    More VA related:

    Required parallelism on basis of bandwidth:

    • system clock = C = VA platform frequency = 125 MHz
      default mE5 = 125 MHz or mE4 = 62.5 MHz
    • parallelism = P = bandwidth / C = F * (W * H ) / C, where P is always integer
      ((1920 * 1080) * 210 Hz) / (125 MHz) = 3.48, where 4 is the value to use.

    If you wonder where the bit-depth has gone: it is a link property that is independent of parallelism.


    Required DMA performance for de-mosaicking a bayer-pattern and transferring color/RGB data to host system:


    bandwidth input = size * frame rate = F * S = F * (W * H * B) = 210 Hz * (1920 * 1080 * (8 bit)) = 435.5 MB / s


    DMA bandwidth output = (1920 * 1080) * (210 Hz) * (24 bit) = 1.3 GB / s


    where DMA paralleism is still ((1920 * 1080) * 210 Hz) / (125 MHz) = 3.48 = 4


    From time to time I will put some more calculations here.

    It would be handy to have these inside VA, but as long as missing: Google is a good friend.


    Best regards,




    Dear IhShin,


    Please let me know if the mentioned approach is usefull for you and what the target bandwidth looks like:

    Width * Height * BitPerPixel * Frequency
    2000 * 2000 * 8 bit * 100 Hz = 400 MB/s


    That will define the require paralleism representing the bandwidth.


    Best regards,

    Dear IhShin,


    In your design I can see that you are using the camera with 2 RAMs on the acquisition side.

    There you have chosen parallelism 32, where the processing itself is targeting a parallelism of 8.


    Please check if your design works fine with a lower frame rate.

    For example 100 Hz:

    (2000 * 2000 * (100 Hz)) / (8 * (125 MHz)) = 40 %


    Step by step you can check if the applet runs fine.

    At a certain frame rate you will start observing a buffer overflow.


    You can use the same RAM approach as in the acquisition to increase the bandwidth of the EDoF calculation.

    That approach will use 2 RAM modules.

    Please make sure that you utilize the maximum possible paralleism for each image buffer (RAM) module to get the maximum possible bandwidth.


    Best regards,

    Dear Fabio,


    While differential signals frequently use low voltages, we have to take care of the applied voltage level.

    update

    As mentioned in my previous post I talked to the people in the hardware department and as soon as I receive some more feedback on this I will post it here.


    Best regards

    Dear Fabio,


    Thank you for the additional details and espcially the resistor check ending up at 800ns bouncing time.

    But that may see some improvements with slight modifications.


    Here we have some schematics:

    Front_GPIO_GPI_SD_Extendedx_600x522.png


    -----------------


    Front_GPIO_SD2.png


    More details: InputConfigFGPIO


    Today I will join some people from the hardware department and discuss a solution of this.

    Then you will receive an update over here...


    Best regards

    Dear Fabio,


    Why it works different with the external GPIO connector is somehow unclear to me.
    I would like to understand this irritation.
    If you have some more details, please let me know...


    Best regards

    Dear Fabio,


    We used these (Front) GPI and GPO's for serial communication at pretty high frequencies.

    So in general these work even for higher frequencies.


    Best regards

    Dear Fabio,


    Ok, good to hear that the de-bounce is solving the issue itself, while 8 microSec bouncing seems pretty long to me.

    I would guess that it is simply a pull-up/down resistor issue or similar...


    Best regards

    Dear Fabio,


    Thank you for providing a screenshot of the used design.

    Only counting the Rising-Edge of the signal is fine. By default SignalEdge is set to RisingEdge. In case of using both edges it may count 0, 2, 4, 6, ...

    You expect: 0,1,2,3,4,...N

    So fo N pulses you would like to see N as a result.

    Using Gnd as direction for PulseCounter will count forward +1 per pulse.


    Your design does not seem to be the problem.


    I guess that you have a "bouncing" input, means this kind of behaviour (Wikipedia)


    To surpress this you can use VA operator SignalDebounce.

    Please configure the debouncing bits/ticks as required in your case.


    A mE5-MA-VCL used a system clock of 125 MHz, that means the signal is samples with a period of 8ns.

    So 4 ticks of de-bounce would represent a period of 32ns.


    Please let me know if this was helping you or if we have to investigate a different idea.

    Have you configured the Front GPI for a differential signal using the gpio-tool?


    Best regards