Posts by Theo

    Dear Björn,


    thanks for the answer and the nice read =). I think your suggestion would be the right one as it is corresponding to the standard applets.

    CXP6x1Camera, CXP6x2Camera, CXP6x4Camera


    But to be honest I think this issue will never bother me again as I have learned my lesson. If you change the naming convention this would only be for all the poor guys which did not have this opportunity yet =)


    Regards,

    Theo

    Hi there,


    if I load a standard "Quad Applet" in microDisplay like "Acq_QuadCXP6x1..." I will get a configuration with four cameras (1 link each). It took ages for me to learn that Quad means the amount of cameras and x1 stand for the amount of lanes.


    However, if I use the CXPQuadCamera operator in VA I will get a configuration with one camera (four links). :P


    This is really really really confusing and I think I might have planned my current project with the wrong camera operator. In this case it will not effect the parallelism I hope but it might, correct? What is the logic behind this? Is this some kind of free of charge brain jogging? ?(


    You are correct if your answer is RTFM ( ;) ) but as I said, I thought I knew what I was doing ^^.


    Regards,
    Theo

    Hi Forum,


    its a while now but in the end I have a new question for you.


    I know that the Blob Operator can be a "pain in the ass" if the processed image has too many little blobs. The operator will slow down then and it is important to know that before starting a project.


    I suspect that the CNN Operator will behave similar and I would like to know your opinion regarding processing time. If I want to have a fast decision the question is if the CNN operator still is the best solution.


    What are the thoughts I have to take into account regarding "real time"?



    Theo

    Hi Björn and Johannes,


    many thanks for the fast answer. I can understand Björns input but I can also see the user side. Connecting parameters is a selling point of those operators :-). However, I think I have found a workaround, so I consider this topic as "closed".


    Best regards,

    Theo

    Hi,


    I have a short question regarding the parameter operators. I am currently sorting all the parameters from my applet into a parameter group. The user shall only use those parameter operators to set up his applet.


    Unfotunately I could not figure out how to connect FG_HEIGHT and FG_WIDTH to my corresponding IntParamTranslators. Is this even possible?



    best regards,
    Theo

    Goede Dag Björn,


    tested it today. Works perfect for me as it seems.


    Thank you very much. Are you planning to change the BufferSC for newer FPGA generations in the future?


    kind regards,

    Lothar


    Ps.: Johannes, I just saw that you also replied. Actually I have to admit that I oversaw those examples completely. Probably because I was fixated on solving this challenge using the BufferSC.

    Hi there,


    I am currently transferring an Applet from mE IV VD4 to Marathon VCL. The old applet supported a Mono8 Image and the user could select between "Smode_Unchanged" and "Smode_Tap2_0". As the BufferSC supports max. a parrallellism of 4 we had to increase the bitwidth to 16 in order to achieve the best performance. However, as the Marathon VCL does use shared memory and I am not allowed to increase the parrallellism I am not sure how to proceed.


    What is the best procedure to optimize performance of the BufferSC for the Marathon VCL? I already tried to increase the Bitwidth to 32 which seemed to help but is this the right way?


    Any suggestions?


    Kind Regards,

    Theo

    Hi Johannes,


    I managed, after some time and after finding your thread and a short sentence in the documentation that increasing parallelism will not increase bandwidth, to get my applet working with a CoefficientBuffer. However, I did not want to use more than one Link as this would make it much more complicated for the user. Before I used (BitWidth = 16, Par = 64) and casted to (BitWidth = 8 , Par = 16). I optimized it by starting the otherway round (BitWidth = 64, Par = 16; see attached image). So my main question is why is the Bit Width not a part of the table above? Would you still think I should use more than one link?


    Why is it not possible to improve the operator by increasing the parallelism...I have to admit that it did not quite get the explanation in the documentation.


    Best regards,

    Theo



    forum.silicon.software/index.php?attachment/207/

    Files

    • Applet.PNG

      (26.3 kB, downloaded 1 times, last: )

    Dear Björn,


    I have installed Siso RT 5.6.074339. MicroDisplay and I am currently using the Marathon VCL Framegrabber.


    microDisplay does not Show the Option "RGB36Bit"


    143-pixelformat-png












    By the way. This Format will then be "packed", right? So I will have to unpack it by Software.


    If I do want to save CPU load I think RGB48 would be better. Of course as long I do not exeed the Maximum bandwidth.


    best regars,

    Theo

    Hi Björn,


    thanks for the input. Acutally (and I missed that in my first question) I want to transfer RGB 12 Bit (RGB36) and not grayscale. I am not sure if I did forget this in my post or if I did not have the information at that time.


    However, I have made little test applet and can build it just fine (ouput is RGB 36 Bit with a parallism of two). As expected microDisplay does not support this pixel format (gray 12 bit and rgb 36 are not shown in the list).


    regards,

    Theo

    Hi there,


    I am currently thinking about a design for CXP-Cameras with 12 bit pixel format. The pixel will be handled as 12 bit value inside the VA but what happens in the DMA transfer? If I do understand the documentation of the operator DMAToPC correctly 12 bit is not allowed and therefore I would have to scale up to 16 bit.


    Is this correct or do I have an option to use 12 bit and therefore reduce the needed bandwith? In my case this would be the difference between Ironman and Marathon.


    regards,

    Theo

    Hi there,


    currently I am working with a customer who basically already solved some applications using microEnable IV AD4. Now he wants to switch to Marathon VCL with aditional functionallity, which is why we are planning to implement a VA for him.

    Of course we want to give him as much look and feel as he is used to from the standard applet (MediumLineRGB) and while I was comparing our specification with the existing applet I came up with some "questionmarks".


    The main question which popped up is how I can implement the LUT and "Processing" operator in an Applet so that the user (at best) does not feel a difference. What is the best way to do it? Can it be solved using VA?



    best regards,

    Theo

    Hi there,


    I am currently thinking about a recording application for a CXP grabber which converts the input image directly into JPEG.


    Using a CXP-Grabber datarates will be quite high so I thing the throughput will be challenging. According to the documentation I should be able to achieve approx. 300 MB / s on a Marathon VCX-QP using one JPEG-Encoder_Gray operator.


    My idea would be to split the data stream and use a second or third operator to maximize this boundary to 600 or 900 MB / s. Please see a first draft attached (untested of course =) ). Is there a better option and what do you think would be the maximum possible badwidth?


    I just noticed that the better way probably would be to split the image stream after the ImageBuffer_JPEG_Gray and not before. This would probably safe me a bunch of resources.


    However, what do you think? :)


    best regards,

    Theo

    Files

    • JPEG_Gray.PNG

      (134.8 kB, downloaded 14 times, last: )

    Hi there,


    I hope this question is in the correct part of this wonderful new forum. Please feel free to move it, if not.


    How is it possible to reset my complete applet without reloading the board? E.g. deleting image data, reseting counters, etc.


    I know that processes with an acquisition can be reseted by stopping and restarting the acquisition itself. This of course does not work with processes without an acquisition part (e.g. processes which are only ment for signals). The only other way I can think to solve this is step by step, reseting each operator by it's own reset input if available and think of an algorithm to reset the image data.


    Is there a possibility which I did not think about?


    regards,

    Theo