#apertus IRC Channel Logs

Bertl, In T871 SerDes, I have been trying a lot to increase the clock speed above 500MHz but I am just reaching there. Everything goes fine in post map simulation but all goes wrong in post route due to S/H of FFs. I have tried various timing schemes for sending data till now. I am getting this unmet timing constraint warning due to clk in IBUFG/BUFG which I am currently unable to resolve. Please give some direction

zynq-7020

you can get a report from vivado with report_pulse_width -all_violators

so you want to use the I/O buffers (DDR) to reduce your clock early

note that you can do DDR easily without any special units by sampling on both clock edges

okay, off to bed now ... have fun!

morning folks!

Hi! I am Aman Roy. I am planning to apply for GSoC this year for Management of image sensor calibration files[T720]. Working on C challange.

off for now ... bbl

Hey BAndiT1983 , Can u please check my C/C++ challenge , if u have time in hand ! , Now it bypasses the problem of calculating sizes manually using recursion

for AVI generation

when?

don't see anything

please check

final_image[count * 3] looks a bit awkward, as it repeats this calculation over and over, either do it at the beginning in a separate variable or think of different loop conditions

no need for separate lines, if you don't have line breaks

file << grayheight <<"\n";

why is it mixing up file.write() and file <<?

Actually , we have to change width into const char for writing using write

this could be replaced by ternary operator and a boolean switch, e.g. file << grayscaleOutput ? "P5" : "P6"

you have to go with some consistent way, either file.write() or file <<, but mixing them makes it hard to follow

AVISizes is really not what i expect, have you checked the frame server prototype and how to avoid this calculations? as they can result in more errors

have only checked quickly, will look a bit later into it, came not long ago from work and want to switch off a bit from development

i will remind u some other time

you AVI generation is similar to Supragyas, also told him back then, that it's not maintainable

I could able to change it with some recursion ,

i will check your prototype for more changes , actually now i was working on proposal so didn't have much time to look for it

just saying, otherwise more people will struggle with this task

have used this while implementing -> http://yaai.sourceforge.net/yaai/fileformat.html

yes , it was there in refernces , the challenge also includes recursion

if you mean the prototype, then it's not true, as it uses recursion to walk through every node, starting at the first one

Dev_, FindSize() is rather error-prone and difficult to maintain

yes , makes sense

So is my assumption is correct that , if a particular frame is requested second time , Our virtual AVI file can provide that frame itself and we don't need to find it again in buffer

also the virtual file content is stored in a 30mb buffer, which shouldn't be the case for real one later

so we have to fetch that frame again each time for real frameserving , right ?

if the RAM is big enough we could try to get multiple large pages, but for most cases we would get the frames over and over

(in one go)*

if i'm not mistaken, then we need around 60MB for 4k frame

this site even says 72MB

48bit / 3 = 16bit per channel

i think we can provide this much memory , so extracting all the frames at once can also work ,

are you sure? just multiply 25 frames by 50mb

1250 MB, more thans one GB

now imagine files of 2 minutes, this is not that simple to store in 16GB RAM, where a part is already occupied and the memory fragmented, so we have to stream to one or multiple memory blocks

yes , makes sense

and not in buffer

this was a topic some days ago

first you would iterate through source data, lets say MLV file, you would write down a last of all frame positions, maybe just of image data, as the size is always the same, then you would generate AVI info and create a second list of AVI frame positions, if the player aasks for certain offset in memory, you would check which frame is meant and send it over

i doubt that a player would request part of a frame, if the frames are not some sort of diff image

i doubt that a player would request part of a frame, if the frames are not some sort of diff image : , if it request for some part then we can transfer that many bytes

it's not about how many bytes, but the offset it requests, has to be evaluated, so we can respond with correct data there

yes , it clear now . thanks for help .

no problem