Current Server Time: 18:51 (Central Europe)

#apertus IRC Channel Logs

2019/05/22

Timezone: UTC


01:10
Spirit532
left the channel
01:10
Spirit532
joined the channel
01:11
Davelister
joined the channel
01:11
Davelister
changed nick to: Guest41642
01:16
Guest41642
left the channel
02:09
Y_G
left the channel
02:10
Y_G
joined the channel
02:18
Y_G
left the channel
02:20
Y_G
joined the channel
03:01
Davelister
joined the channel
03:02
Davelister
changed nick to: Guest52836
03:07
Guest52836
left the channel
03:56
illwieckz_
joined the channel
03:58
illwieckz
left the channel
04:03
Davelister
joined the channel
04:03
Davelister
changed nick to: Guest55149
04:04
illwieckz_
changed nick to: illwieckz
04:07
Guest55149
left the channel
04:21
Bertl_oO
off to bed now ... have a good one everyone!
04:21
Bertl_oO
changed nick to: Bertl_zZ
04:44
apurvanandan[m]
Bertl_oO: No problem, I will go through all the messages, and ask my doubts.
05:14
Davelister
joined the channel
05:14
Davelister
changed nick to: Guest17160
05:16
BAndiT1983|away
changed nick to: BAndiT1983
05:18
Guest17160
left the channel
06:28
johnathan
left the channel
06:29
johnathan
joined the channel
06:43
BAndiT1983
changed nick to: BAndiT1983|away
07:05
Davelister
joined the channel
07:05
Davelister
changed nick to: Guest97739
08:09
Guest97739
left the channel
08:11
se6astian|away
changed nick to: se6astian
08:15
Nira|away
changed nick to: Nira
08:32
johnathan
left the channel
09:06
vup
felix_: that all makes sense, but unfortunately i only control the receiving side for my application and the transmitter does not support custom patterns beyond 010101, 00110011, constant 1, constant 0 and a PRBS
09:08
vup
the protocol contains sync words, but i am wondering if it is not easier to just use the PRBS to align the lanes
09:16
Y_G
left the channel
09:20
Bertl_zZ
changed nick to: Bertl
09:20
Bertl
morning folks!
09:22
Bertl
apurvanandan[m]: please do that! btw. any reason why you missed the meeting yesterday despite agreeing on the date and time last week?
09:22
Nira
changed nick to: Nira|away
09:41
illwieckz
left the channel
10:14
illwieckz
joined the channel
12:21
illwieckz
left the channel
12:45
Bertl
off for now ... bbl
12:45
Bertl
changed nick to: Bertl_oO
13:15
Y_G
joined the channel
13:19
Nira|away
changed nick to: Nira
13:35
se6astian
changed nick to: se6astian|away
13:43
BAndiT1983|away
changed nick to: BAndiT1983
13:47
se6astian|away
changed nick to: se6astian
14:50
Y_G
left the channel
15:06
Nira
changed nick to: Nira|away
16:04
se6astian
changed nick to: se6astian|away
16:08
RexOrCine|away
changed nick to: RexOrCine
16:34
aSobhy
changed nick to: aSobhy|away
16:51
illwieckz
joined the channel
18:18
se6astian|away
changed nick to: se6astian
19:27
Davelister
joined the channel
19:27
Davelister
good evening
19:27
se6astian
hi Davelister!
19:37
Davelister
hello se6astian , how are you?
19:38
johnathan
joined the channel
19:38
se6astian
good thanks, still working my way through things that pilled up while we were in berlin
19:38
se6astian
did you have a chat with Bertl_oO already after our return?
19:48
Davelister
yes, we had a little chat, thank you
19:49
Davelister
now, I have to look at some technical details, and then I'll be able to contribute
19:51
Bertl_oO
let me know if you have any questions ...
19:52
Fares
joined the channel
19:52
Fares
Hi
19:52
Bertl_oO
Hey Fares! How's it going?
19:53
Fares
good, thank you. how about you?
19:54
Bertl_oO
everything fine ... a lot of work before me (stuff piled up during the maker faire :)
19:56
Fares
if you have free time I would like to have a chat to discuss few things.
19:56
Bertl_oO
changed nick to: Bertl
19:56
Bertl
no problem, let's chat
19:57
Fares
Okay, so at first I spend some quality time on the vhdl code of the beta .. I get myself more familiar with it.
19:58
Fares
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
19:59
Fares
when the final core will be merged with the current pipeline, the only part need to modify is the reader -> hdmi_fifo to support two fifos, one to hdmi and the other to the core
19:59
Bertl
let's avoid any IP which isn't open source, otherwise I'm fine
20:00
Davelister
Bertl: thank you
20:00
Fares
for the final product or also for testing?
20:00
Fares
for the final product of course it all will be open source
20:00
Bertl
well, in my experience, you'll end up with a bug in code you can't de-bug, so yes, please also for testing
20:01
Fares
okay, no problem.
20:01
Bertl
at least for code you upload somewhere to show us for evaluation
20:02
Bertl
(what you do in your 'private' tests doesn't interest much :)
20:02
Fares
okay, great :)
20:02
Fares
also the core need few registers
20:02
Fares
you mentioned in my proposal to consider BRAM
20:03
Fares
for example the encoder will need 16x16bits registers for huffman encoding and 2x16bits for width and height
20:04
Fares
is register file will be more appropriate? since they will need to be existed all together all the time.
20:05
Bertl
for data which exceeds a few 32bit registers a BRAM block is probably better and easier to handle than local memory conencted to some registers
20:05
Bertl
for example we use BRAM for the LUTs
20:08
Fares
then read those from bram to registers? the idea is there are four parallel values that needed to be matched against some pattern, then based on the matching every value will read different registers and bram only have two ports per block
20:10
Bertl
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
20:10
Bertl
and see what the tools make from it depending on the access pattern
20:12
Fares
so something like axi_split8 -> register_file that is used? or memory with four ports?
20:13
Bertl
or alternatively use two smaller BRAMs, regulate the access and have them duplicate the data
20:14
Bertl
you need to use the split (or similar) if you want more than one memory region for register, etc
20:15
Bertl
but yes, a single port write, quad port read memory is probably what you want
20:16
Bertl
the main question is whether the 'write' functionality is required while the read ports are active ...
20:17
Fares
no write will happen before the read, when the encoding start, the ps can't change those values.
20:17
Fares
no, write will..*
20:17
Bertl
so two small dual port BRAM blocks should work then
20:18
Bertl
any write will go to both of them and the four ports are free during read
20:19
Fares
that seem good, I will look into how to make the best use out of them if I can offload some parts of the algorithm in them.
20:20
Fares
actually I think if we embedded those huffman values it would be more efficient, not sure though, maybe I will try that later
20:21
Fares
there is other part I want to discuss
20:21
Bertl
okay
20:21
Fares
the header/footer and reconstruction of the frame/clip in the receiver end.
20:22
Fares
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).
20:23
Fares
this is relatively more complicated in the fpga side, and will limit what we able to export during the clip
20:23
Bertl
I guess they will always be needed, no?
20:23
Fares
yes sure, I mean repeatedly in the correct time
20:24
Fares
I was thinking of way to split the work between pl and ps
20:24
Bertl
okay?
20:25
Fares
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
20:25
Fares
the pl would put some data in shared memory with ps, for example when every frame finished, the pl will put the number of bytes consumed
20:26
Fares
then the ps will read these data and determine what kind of headers needed for the receiver end to correctly set the file
20:26
Fares
the ps will write these data in shared memory with pl
20:26
Fares
the pl with CONSTANT offset read these data and send it to the receiver end
20:27
Fares
the receiver end will only read the data at constants offsets to tell it how to handle the buffered data
20:27
Bertl
I think that's not going to work well
20:27
Bertl
the problem I see is with the timing
20:28
Bertl
let's say there is a constant stream of images (30-60FPS) which gets transferred from the sensor to DDR memory
20:28
Bertl
now the readers fetch this data from DDR memory and generate a 'compressed' stream on the fly (inside the PL)
20:29
Bertl
which for example is then sent to the USB plugin module to be received by a PC
20:29
Bertl
the PS would basically need to 'read the relevant data', prepare a header, 'write it back to PL' while the stream is already being compressed
20:30
Bertl
and you can not really rely on the PS being real time (not even remotely)
20:31
Fares
actually not needed to be real time, but for example how many time can ps prepare the needed header per second?
20:31
Bertl
so what I could imagine is to process the data completely at the receiver
20:32
Bertl
i.e. read some 'magic' values added to the stream and create whatever headers/footers required on the fly at the receiver side before actually storing the data
20:32
Fares
actually that is the same idea but more efficient, there is no need for ps to be real time
20:32
Fares
the receiver will keep buffering the data until it told how to deal with this data
20:33
Fares
so for example if the ps can do 10 preparations/second, the receiver will need a buffer of 1 second of bandwidth/10
20:34
Fares
the ps will not add those headers to the stream directly
20:34
Fares
the ps will put them in a shared memory with pl
20:35
Fares
then the pl will export them in known offsets, for example every 10MB
20:35
Fares
so the receiver will only need to look every 10MB to know how to handle the received data
20:37
Fares
leaving everything to the receiver would be easier and simpler but wan't that limit the fps?
20:38
Bertl
I guess you need to make a flow diagram or something similar to illustrate the concept
20:41
Fares
okay I will do that but let me explain one last time how the result stream would look like maybe that would clear things
20:41
Bertl
okay, please go ahead
20:42
Fares
the normal stream with headers is [clip_header, frame_header, frame_data, frame_header, frame_data, ...] that will require the receiver to separate them to store them as DNG or store them with no processing at all in something like MLV format
20:43
Fares
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.
20:44
Fares
the proposed stream is [ frame_data, frame_data, instructions, frame_data, instructions, frame_data, frame_data, frame_data, frame_data, instructions...]
20:44
Bertl
okay
20:44
Fares
those instructions will be in known offsets in the file - maybe in the middle of a frame.
20:45
Fares
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.
20:46
Fares
if no instruction is received the data stays in the receiver end memory until instructions arrives.
20:46
Fares
the receiver will not need to parse all stream, only the instructions in known offsets
20:46
Fares
is that more clear?
20:47
Bertl
so far it's fine, but where do those 'instruction' packets come from?
20:48
Fares
the ps will put them for example in a shared bram, every 10MB of streamed data from usb, the pl will check if there are any new instructions or not, if there are, pl will export it, if not it will continue with the encoder stream
20:49
Bertl
how does the PS know what the instructions are?
20:49
Bertl
it doesn't know much about the encoder does it?
20:51
Fares
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.
20:53
Bertl
wouldn't it be simpler to have some start/end marker in the stream?
20:54
Fares
simpler yes, but it would require the receiver to search for them in the stream, wouldn't that limit the fps?
20:55
Bertl
okay, good point
20:56
Bertl
still there needs to be some synchronization with any transfer
20:56
Bertl
so it might not be that much overhead anyway (don't know yet)
20:56
Fares
at 400MB/s that might be fine though with processors more powerful than arm a9
20:58
Davelister
(my 2 cents: when using the VDMA, I use the master/slave mode signals to establish a mutex for the PS, blocking the VDMA to write into the same frame address space)
20:58
Davelister
(but VDMA is not open source I am afraid)
20:59
Davelister
Fares: depends on :-/ Code from Xilinx for the L1 cache (BSP) is broken, hence you have to flush the cache before reading each frame.
20:59
Davelister
and that's very bad for the framerate
21:00
Bertl
probably the best approach is to keep it generic where possible
21:01
Bertl
i.e. have a constant block of data which can be inserted at known offsets/amount of compressed data
21:01
Fares
in this method pl and ps are sync in a way that the data should not get corrupted, but no hard limit on when the ps response, if ps didn't respond for so long time it will result in buffer overflow in the receiver end.
21:01
Bertl
and also have a signal when the data for a frame ends
21:02
Bertl
yes, I get what you mean, and I think it is kind-of okay, except for the part that the PS needs to constantly poll the frame data from the PL
21:02
Bertl
(and update the PL buffer in time, which is not that critical_
21:03
Bertl
s/_/)
21:05
Fares
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?
21:06
Bertl
or maybe a buffer/fifo?
21:07
Bertl
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?
21:10
Fares
yes that might be better in the camera side, the software logic will be implemented either in camera side or receiver side .. although that will limit the amount of information from camera to the receiver and leave all the logic there.
21:10
Fares
So if some advanced data needed to be transferred like sensors reading or something that will not be possible.
21:11
Fares
but it would be simpler and more reliable in the camera end :)
21:12
Fares
We can take the decision later
21:13
Fares
I will start by the encoder pipeline itself first, then how to handle the other data will be combined later
21:21
johnatha_
joined the channel
21:23
johnathan
left the channel
21:34
danieel
Davelister: what about using coherent memory (non-cacheable regions) instead of dropping the cache
21:44
johnatha_
left the channel
21:53
Davelister
danieel: yes, that's what I am trying to do. Except Xilinx's code for this feature is broken
21:54
Davelister
(I cannot give more details, because of NDA)
21:55
Davelister
but it looks like a lot of people asks Xilinx to fix this since some Vivado releases
21:56
Bertl
(with little to none effect, I suppose? :)
21:56
Davelister
Bertl: I suppose one day we'll get a Xilinx Answer like "fix the code by yourself"
21:58
Bertl
guess we would if we could :)
21:58
Davelister
oh I am sure we can, UG585 is our friend :-)
21:59
Davelister
(and having time to do it too...)
22:05
se6astian
off to bed, good night
22:05
Bertl
nn
22:05
se6astian
changed nick to: se6astian|away
22:07
BAndiT1983
me too, good night
22:07
BAndiT1983
changed nick to: BAndiT1983|away
22:14
illwieckz_
joined the channel
22:15
danieel
which code? the *dma driver?
22:18
illwieckz
left the channel
22:21
Fares
left the channel
22:22
Fares
joined the channel
22:23
lexano
left the channel
22:23
Fares
left the channel
22:23
Fares
joined the channel
22:27
Fares
left the channel
22:28
Fares
joined the channel
22:32
RexOrCine
changed nick to: RexOrCine|away
22:33
Davelister
good night every one
22:33
Davelister
left the channel
22:37
lexano
joined the channel
23:12
RexOrCine|away
changed nick to: RexOrCine
23:13
RexOrCine
changed nick to: RexOrCine|away
23:20
Fares
left the channel
23:30
Bertl
off to bed now ... have a good one everyone!
23:30
Bertl
changed nick to: Bertl_zZ
23:41
illwieckz_
left the channel
23:54
illwieckz_
joined the channel