Current Server Time: 21:10 (Central Europe)

#apertus IRC Channel Logs

2019/05/22

Timezone: UTC


00:10
Spirit532
left the channel
00:10
Spirit532
joined the channel
00:11
Davelister
joined the channel
00:11
Davelister
changed nick to: Guest41642
00:16
Guest41642
left the channel
01:09
Y_G
left the channel
01:10
Y_G
joined the channel
01:18
Y_G
left the channel
01:20
Y_G
joined the channel
02:01
Davelister
joined the channel
02:02
Davelister
changed nick to: Guest52836
02:07
Guest52836
left the channel
02:56
illwieckz_
joined the channel
02:58
illwieckz
left the channel
03:03
Davelister
joined the channel
03:03
Davelister
changed nick to: Guest55149
03:04
illwieckz_
changed nick to: illwieckz
03:07
Guest55149
left the channel
03:21
Bertl_oO
off to bed now ... have a good one everyone!
03:21
Bertl_oO
changed nick to: Bertl_zZ
03:44
apurvanandan[m]
Bertl_oO: No problem, I will go through all the messages, and ask my doubts.
04:14
Davelister
joined the channel
04:14
Davelister
changed nick to: Guest17160
04:16
BAndiT1983|away
changed nick to: BAndiT1983
04:18
Guest17160
left the channel
05:28
johnathan
left the channel
05:29
johnathan
joined the channel
05:43
BAndiT1983
changed nick to: BAndiT1983|away
06:05
Davelister
joined the channel
06:05
Davelister
changed nick to: Guest97739
07:09
Guest97739
left the channel
07:11
se6astian|away
changed nick to: se6astian
07:15
Nira|away
changed nick to: Nira
07:32
johnathan
left the channel
08: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
08: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
08:16
Y_G
left the channel
08:20
Bertl_zZ
changed nick to: Bertl
08:20
Bertl
morning folks!
08: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?
08:22
Nira
changed nick to: Nira|away
08:41
illwieckz
left the channel
09:14
illwieckz
joined the channel
11:21
illwieckz
left the channel
11:45
Bertl
off for now ... bbl
11:45
Bertl
changed nick to: Bertl_oO
12:15
Y_G
joined the channel
12:19
Nira|away
changed nick to: Nira
12:35
se6astian
changed nick to: se6astian|away
12:43
BAndiT1983|away
changed nick to: BAndiT1983
12:47
se6astian|away
changed nick to: se6astian
13:50
Y_G
left the channel
14:06
Nira
changed nick to: Nira|away
15:04
se6astian
changed nick to: se6astian|away
15:08
RexOrCine|away
changed nick to: RexOrCine
15:34
aSobhy
changed nick to: aSobhy|away
15:51
illwieckz
joined the channel
17:18
se6astian|away
changed nick to: se6astian
18:27
Davelister
joined the channel
18:27
Davelister
good evening
18:27
se6astian
hi Davelister!
18:37
Davelister
hello se6astian , how are you?
18:38
johnathan
joined the channel
18:38
se6astian
good thanks, still working my way through things that pilled up while we were in berlin
18:38
se6astian
did you have a chat with Bertl_oO already after our return?
18:48
Davelister
yes, we had a little chat, thank you
18:49
Davelister
now, I have to look at some technical details, and then I'll be able to contribute
18:51
Bertl_oO
let me know if you have any questions ...
18:52
Fares
joined the channel
18:52
Fares
Hi
18:52
Bertl_oO
Hey Fares! How's it going?
18:53
Fares
good, thank you. how about you?
18:54
Bertl_oO
everything fine ... a lot of work before me (stuff piled up during the maker faire :)
18:56
Fares
if you have free time I would like to have a chat to discuss few things.
18:56
Bertl_oO
changed nick to: Bertl
18:56
Bertl
no problem, let's chat
18: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.
18: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
18: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
18:59
Bertl
let's avoid any IP which isn't open source, otherwise I'm fine
19:00
Davelister
Bertl: thank you
19:00
Fares
for the final product or also for testing?
19:00
Fares
for the final product of course it all will be open source
19: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
19:01
Fares
okay, no problem.
19:01
Bertl
at least for code you upload somewhere to show us for evaluation
19:02
Bertl
(what you do in your 'private' tests doesn't interest much :)
19:02
Fares
okay, great :)
19:02
Fares
also the core need few registers
19:02
Fares
you mentioned in my proposal to consider BRAM
19:03
Fares
for example the encoder will need 16x16bits registers for huffman encoding and 2x16bits for width and height
19:04
Fares
is register file will be more appropriate? since they will need to be existed all together all the time.
19: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
19:05
Bertl
for example we use BRAM for the LUTs
19: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
19: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
19:10
Bertl
and see what the tools make from it depending on the access pattern
19:12
Fares
so something like axi_split8 -> register_file that is used? or memory with four ports?
19:13
Bertl
or alternatively use two smaller BRAMs, regulate the access and have them duplicate the data
19:14
Bertl
you need to use the split (or similar) if you want more than one memory region for register, etc
19:15
Bertl
but yes, a single port write, quad port read memory is probably what you want
19:16
Bertl
the main question is whether the 'write' functionality is required while the read ports are active ...
19:17
Fares
no write will happen before the read, when the encoding start, the ps can't change those values.
19:17
Fares
no, write will..*
19:17
Bertl
so two small dual port BRAM blocks should work then
19:18
Bertl
any write will go to both of them and the four ports are free during read
19: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.
19: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
19:21
Fares
there is other part I want to discuss
19:21
Bertl
okay
19:21
Fares
the header/footer and reconstruction of the frame/clip in the receiver end.
19: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).
19:23
Fares
this is relatively more complicated in the fpga side, and will limit what we able to export during the clip
19:23
Bertl
I guess they will always be needed, no?
19:23
Fares
yes sure, I mean repeatedly in the correct time
19:24
Fares
I was thinking of way to split the work between pl and ps
19:24
Bertl
okay?
19: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
19: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
19: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
19:26
Fares
the ps will write these data in shared memory with pl
19:26
Fares
the pl with CONSTANT offset read these data and send it to the receiver end
19:27
Fares
the receiver end will only read the data at constants offsets to tell it how to handle the buffered data
19:27
Bertl
I think that's not going to work well
19:27
Bertl
the problem I see is with the timing
19:28
Bertl
let's say there is a constant stream of images (30-60FPS) which gets transferred from the sensor to DDR memory
19:28
Bertl
now the readers fetch this data from DDR memory and generate a 'compressed' stream on the fly (inside the PL)
19:29
Bertl
which for example is then sent to the USB plugin module to be received by a PC
19: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
19:30
Bertl
and you can not really rely on the PS being real time (not even remotely)
19:31
Fares
actually not needed to be real time, but for example how many time can ps prepare the needed header per second?
19:31
Bertl
so what I could imagine is to process the data completely at the receiver
19: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
19:32
Fares
actually that is the same idea but more efficient, there is no need for ps to be real time
19:32
Fares
the receiver will keep buffering the data until it told how to deal with this data
19: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
19:34
Fares
the ps will not add those headers to the stream directly
19:34
Fares
the ps will put them in a shared memory with pl
19:35
Fares
then the pl will export them in known offsets, for example every 10MB
19:35
Fares
so the receiver will only need to look every 10MB to know how to handle the received data
19:37
Fares
leaving everything to the receiver would be easier and simpler but wan't that limit the fps?
19:38
Bertl
I guess you need to make a flow diagram or something similar to illustrate the concept
19: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
19:41
Bertl
okay, please go ahead
19: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
19: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.
19:44
Fares
the proposed stream is [ frame_data, frame_data, instructions, frame_data, instructions, frame_data, frame_data, frame_data, frame_data, instructions...]
19:44
Bertl
okay
19:44
Fares
those instructions will be in known offsets in the file - maybe in the middle of a frame.
19: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.
19:46
Fares
if no instruction is received the data stays in the receiver end memory until instructions arrives.
19:46
Fares
the receiver will not need to parse all stream, only the instructions in known offsets
19:46
Fares
is that more clear?
19:47
Bertl
so far it's fine, but where do those 'instruction' packets come from?
19: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
19:49
Bertl
how does the PS know what the instructions are?
19:49
Bertl
it doesn't know much about the encoder does it?
19: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.
19:53
Bertl
wouldn't it be simpler to have some start/end marker in the stream?
19:54
Fares
simpler yes, but it would require the receiver to search for them in the stream, wouldn't that limit the fps?
19:55
Bertl
okay, good point
19:56
Bertl
still there needs to be some synchronization with any transfer
19:56
Bertl
so it might not be that much overhead anyway (don't know yet)
19:56
Fares
at 400MB/s that might be fine though with processors more powerful than arm a9
19: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)
19:58
Davelister
(but VDMA is not open source I am afraid)
19: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.
19:59
Davelister
and that's very bad for the framerate
20:00
Bertl
probably the best approach is to keep it generic where possible
20:01
Bertl
i.e. have a constant block of data which can be inserted at known offsets/amount of compressed data
20: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.
20:01
Bertl
and also have a signal when the data for a frame ends
20: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
20:02
Bertl
(and update the PL buffer in time, which is not that critical_
20:03
Bertl
s/_/)
20: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?
20:06
Bertl
or maybe a buffer/fifo?
20: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?
20: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.
20:10
Fares
So if some advanced data needed to be transferred like sensors reading or something that will not be possible.
20:11
Fares
but it would be simpler and more reliable in the camera end :)
20:12
Fares
We can take the decision later
20:13
Fares
I will start by the encoder pipeline itself first, then how to handle the other data will be combined later
20:21
johnatha_
joined the channel
20:23
johnathan
left the channel
20:34
danieel
Davelister: what about using coherent memory (non-cacheable regions) instead of dropping the cache
20:44
johnatha_
left the channel
20:53
Davelister
danieel: yes, that's what I am trying to do. Except Xilinx's code for this feature is broken
20:54
Davelister
(I cannot give more details, because of NDA)
20:55
Davelister
but it looks like a lot of people asks Xilinx to fix this since some Vivado releases
20:56
Bertl
(with little to none effect, I suppose? :)
20:56
Davelister
Bertl: I suppose one day we'll get a Xilinx Answer like "fix the code by yourself"
20:58
Bertl
guess we would if we could :)
20:58
Davelister
oh I am sure we can, UG585 is our friend :-)
20:59
Davelister
(and having time to do it too...)
21:05
se6astian
off to bed, good night
21:05
Bertl
nn
21:05
se6astian
changed nick to: se6astian|away
21:07
BAndiT1983
me too, good night
21:07
BAndiT1983
changed nick to: BAndiT1983|away
21:14
illwieckz_
joined the channel
21:15
danieel
which code? the *dma driver?
21:18
illwieckz
left the channel
21:21
Fares
left the channel
21:22
Fares
joined the channel
21:23
lexano
left the channel
21:23
Fares
left the channel
21:23
Fares
joined the channel
21:27
Fares
left the channel
21:28
Fares
joined the channel
21:32
RexOrCine
changed nick to: RexOrCine|away
21:33
Davelister
good night every one
21:33
Davelister
left the channel
21:37
lexano
joined the channel
22:12
RexOrCine|away
changed nick to: RexOrCine
22:13
RexOrCine
changed nick to: RexOrCine|away
22:20
Fares
left the channel
22:30
Bertl
off to bed now ... have a good one everyone!
22:30
Bertl
changed nick to: Bertl_zZ
22:41
illwieckz_
left the channel
22:54
illwieckz_
joined the channel