#apertus IRC Channel Logs

the protocol contains sync words, but i am wondering if it is not easier to just use the PRBS to align the lanes

apurvanandan[m]: please do that! btw. any reason why you missed the meeting yesterday despite agreeing on the date and time last week?

good evening

hello se6astian , how are you?

good thanks, still working my way through things that pilled up while we were in berlin

yes, we had a little chat, thank you

let me know if you have any questions ...

Hi

good, thank you. how about you?

if you have free time I would like to have a chat to discuss few things.

no problem, let's chat

regarding readers and writers, if I use them I will need to add few things which will yield at the end to DMA, so I thought it would be more efficient in respect to the time to use vivado DMA

let's avoid any IP which isn't open source, otherwise I'm fine

for the final product or also for testing?

well, in my experience, you'll end up with a bug in code you can't de-bug, so yes, please also for testing

at least for code you upload somewhere to show us for evaluation

okay, great :)

you mentioned in my proposal to consider BRAM

is register file will be more appropriate? since they will need to be existed all together all the time.

for example we use BRAM for the LUTs

well, probably best to leave that to the tools then, i.e. have a generic memory interface which gets mapped to an AXI register space

so something like axi_split8 -> register_file that is used? or memory with four ports?

you need to use the split (or similar) if you want more than one memory region for register, etc

the main question is whether the 'write' functionality is required while the read ports are active ...

no, write will..*

any write will go to both of them and the four ports are free during read

actually I think if we embedded those huffman values it would be more efficient, not sure though, maybe I will try that later

okay

the first solution is to store those in bram and read them when needed, that will include (header of clip, header of frame, tail of frame).

I guess they will always be needed, no?

I was thinking of way to split the work between pl and ps

so the idea is the following, instead of exporting a long stream of valid data like [clip_header frame_header frame_data ...] and leave it to the receiver end to decode those or split them into files or do any processing in them

then the ps will read these data and determine what kind of headers needed for the receiver end to correctly set the file

the pl with CONSTANT offset read these data and send it to the receiver end

I think that's not going to work well

let's say there is a constant stream of images (30-60FPS) which gets transferred from the sensor to DDR memory

which for example is then sent to the USB plugin module to be received by a PC

and you can not really rely on the PS being real time (not even remotely)

so what I could imagine is to process the data completely at the receiver

actually that is the same idea but more efficient, there is no need for ps to be real time

so for example if the ps can do 10 preparations/second, the receiver will need a buffer of 1 second of bandwidth/10

the ps will put them in a shared memory with pl

so the receiver will only need to look every 10MB to know how to handle the received data

I guess you need to make a flow diagram or something similar to illustrate the concept

okay, please go ahead

normal stream with no headers is [ frame_data, frame_data, frame_data, ...] that will require the receiver to process them to add needed headers and separate them if needed.

okay

if the receiver end only read those instructions it will know how to parse the stream, like adding header or separate them or any other instructions.

the receiver will not need to parse all stream, only the instructions in known offsets

so far it's fine, but where do those 'instruction' packets come from?

how does the PS know what the instructions are?

will it does, the PS only need to know where every frame ends, for example if i want to produce a DNG sequence, if I know where every frame starts and ends, I will add instructions to add header in the start and tell the receiver to flush from start-index to end-index to dng file.

simpler yes, but it would require the receiver to search for them in the stream, wouldn't that limit the fps?

still there needs to be some synchronization with any transfer

at 400MB/s that might be fine though with processors more powerful than arm a9

(but VDMA is not open source I am afraid)

and that's very bad for the framerate

i.e. have a constant block of data which can be inserted at known offsets/amount of compressed data

and also have a signal when the data for a frame ends

(and update the PL buffer in time, which is not that critical_

I'm sorry I didn't understand the last part with the polling, do you think a better way is to have an interrupt to the ps for example?

but then, if the 'instructions' are reasonably simple (e.g. byte lengths for the data) then they might be simply inserted by the PL at fixed locations without bothering the PS at all?

So if some advanced data needed to be transferred like sensors reading or something that will not be possible.

We can take the decision later

Davelister: what about using coherent memory (non-cacheable regions) instead of dropping the cache

danieel: yes, that's what I am trying to do. Except Xilinx's code for this feature is broken

but it looks like a lot of people asks Xilinx to fix this since some Vivado releases

Bertl: I suppose one day we'll get a Xilinx Answer like "fix the code by yourself"

oh I am sure we can, UG585 is our friend :-)

off to bed, good night

which code? the *dma driver?

good night every one

off to bed now ... have a good one everyone!