Current Server Time: 08:25 (Central Europe)

#apertus IRC Channel Logs

2021/08/02

Timezone: UTC


01:00
tpw_rules
basically i am trying to figure out the gearing because it looks like dram takes 64 bits per cycle
01:01
tpw_rules
and how do Pipeline clocks work?
04:10
tpw_rules
hm, nmigen doesn't support gearbox fifos, does it?
04:14
tpw_rules
does fifo_chop.vhd downsample the data in some way?
04:20
Bertl_oO
off to bed now ... have a good one everyone!
04:20
Bertl_oO
changed nick to: Bertl_zZ
09:34
fredy
left the channel
09:38
fredy
joined the channel
11:29
vup
tpw_rules: what the beta currently does is use the lower 48 of the 64bits for image data from the sensor and the 16 other bits are use for a overlay one can draw onto it
11:30
vup
nmigen does not support gearbox fifos, but we have a StreamGearbox that should work
11:32
vup
I am not sure if we want to keep the part with only using 48 of the 64 bits, I think Bertl wanted to get rid of that aswell and just use the full 64 bits
11:33
vup
fifo_chop does not downnample (atleast when the input signals are setup as they are) its just a gearbox
11:33
vup
What do you mean by Pipeline clocks?
12:54
anuejn
I would also vote for packed
13:32
Bertl_zZ
changed nick to: Bertl
13:32
Bertl
morning folks!
16:06
tpw_rules
i mean what do we do with the rest of the 16 bits?
16:07
tpw_rules
the sensor is 12 bits per pixel, we could fit 5 pixels in 60 bits but that's kind of weird
16:19
tpw_rules
also i asked about the fifo_chop because it seems like it should have a clock multiplication but i can't find it
16:20
tpw_rules
like it takes in 16 pixels per cycle and outputs 4
16:21
tpw_rules
wait, maybe not
16:23
vup
tpw_rules: well you can fit 16 x 12 bits into 3 x 64 bits
16:23
vup
so that would be one way
16:25
vup
the par_clk of fifo_chop is the serdes (bit) clock, so it does not get 16 pixels every cycle
16:26
tpw_rules
ok yeah i misread that. it's roughly 16/6
16:27
tpw_rules
how does the clock domain sync between serdes_clkdiv and serdes_clk on the input to the fifo work? does it depend on the fact that they are in phase?
16:27
tpw_rules
the only thing i see is the process that sets up remap_dat
16:27
tpw_rules
remap_data
16:29
vup
yeah it seems like no "proper" CDC is done here and it relies on them being in phase
16:29
vup
that should work if you setup the cross domain constraints correctly, but its probably safer to do it with actual CDC
16:29
tpw_rules
i assume it's okay if vivado does not complain that timing is violated
16:31
vup
I think you have to be careful, but yes
16:32
vup
(the slower clock domain obviously has longer setup and hold times than the faster one, so even if they are in phase the setup time of the slower clock domain could be too long for the faster one)
16:32
tpw_rules
but then presumably timing would not pass
16:32
vup
I think vivado should handle this, but I am pretty certain for example nextpnr does not handle this
16:33
tpw_rules
is that something we should be thinking about?
16:34
vup
well maybe
16:34
vup
it would be nice to one day get rid of vivado and use a open source flow
16:35
vup
And I don't think it would hurt much to do "proper" CDC
16:35
vup
But its not *that* important.
16:35
vup
But for the very least I would study the timing report that vivado generates very carefully
16:36
tpw_rules
okay
16:40
tpw_rules
i was also thinking it might make sense to have four parallel FIFOs and a mux in the faster clock domain
16:41
tpw_rules
i'm also also thinking it might make sense to implement all the gearing and getting images into DRAM before the remapper
16:43
vup
hmm why?
16:43
tpw_rules
like i said i don't think the remapper has any gearing in it so it should be easy to drop in
16:44
vup
yes the remapper does not do any gearing it just reorders the pixel stream
16:45
vup
but would it not be more complex to put it after the DRAM, because then you need to unpack the whole packed pixel stream from the DRAM into a wide parallel one again?
16:45
tpw_rules
sorry, i mean "before" as in implementation wise. the final product would still be sensor -> remapper -> gearing -> DRAM
16:46
vup
Ahh
16:46
vup
oh
16:46
vup
yeah that seems fine
16:46
tpw_rules
but if the remapper doesn't have any gearing, then you can take it out and everything will work, just the image will look weird
16:47
vup
and yeah probably makes sense as something like the gearing and DRAM writer will be useful in debugging the remapper
16:47
tpw_rules
yes
16:49
tpw_rules
https://github.com/apertus-open-source-cinema/naps/blob/main/applets/camera.py does this applet work fully
16:51
vup
iirc yes
16:52
tpw_rules
ok
16:54
tpw_rules
https://github.com/apertus-open-source-cinema/naps/blob/903493ccf959a9e535978f154bf37de5b297ff5d/naps/cores/dram_packet_ringbuffer/cpu_if.py#L55 does this work? i think the next_buffer_ready variable is missing
16:57
vup
that indeed seems broken
17:00
BAndiT1983
MEETING TIME
17:00
Dest123
is here
17:00
BAndiT1983
as se6astian is not available at the moment, he asked me to guide through the meeting again
17:00
vup
is here
17:00
tpw_rules
is here
17:00
BAndiT1983
who is here?
17:00
eppisai
is here
17:01
BAndiT1983
Bertl: are you also there?
17:02
BAndiT1983
lets start in the following order: Dest123, tpw_rules, eppisai, vup
17:02
BAndiT1983
Dest123: please report your progress
17:02
Dest123
Hello Everyone :)
17:02
Dest123
so last week t_exp1 signal wasn't triggering the channels
17:03
Dest123
it turns out that the running script is operating with internal not external exposure
17:03
Dest123
so I modified the HDL and this time around the channels were active and the data was fully sent
17:03
Dest123
but still the image couldn't be captured
17:04
Dest123
Bertl suspects a problem with the control channel so we are going to connect the design with the logic analyzer today
17:04
Dest123
and observe the control channel for any abnormalities
17:04
Dest123
That's it for me :)
17:05
BAndiT1983
great, many thanks
17:05
BAndiT1983
tpw_rules: you are
17:06
tpw_rules
alright, i was able to make various improvements to the link training algorithm and gateware over last week
17:06
tpw_rules
everything looks good now and it got merged yesterday, which is great news. so that section is completed
17:07
tpw_rules
as i was discussing earlier i think the next step is implementing the gearbox and logic to get images into DRAM
17:07
tpw_rules
i will put off the remapper until later
17:08
tpw_rules
but i am getting a bit worried about the fact that the end of the GSoC program is approaching rapidly
17:08
tpw_rules
i guess that's it for me
17:09
BAndiT1983
thank you
17:09
BAndiT1983
eppisai: the stage is yours
17:09
eppisai
Hi...
17:10
eppisai
Last week, I was setting up the core timer in remote
17:11
eppisai
After much research I got familiar familer with pic32 development.. just to realize most of things were not needed in core timer task.. but they will definitely help me in upcoming tasks..
17:12
eppisai
With help from Andrej and bertl, I am able to run core timer in remote with interupt, which is planned to be used to optimize and measure performance in remote
17:12
eppisai
So, will be modifying it accordingly
17:13
eppisai
Also, ftp module arrived last week! :D
17:13
eppisai
Very exciting
17:13
eppisai
Andrej has helped sitting it up.. my serial console is working at last
17:13
BAndiT1983
FTP module? do we have a server on the remote now?
17:14
eppisai
Hahaha.. sorry auto correct
17:14
eppisai
or I typed wrong again
17:14
eppisai
Usb to UART ft4232h mini module arrived last week
17:15
eppisai
So, that's it, besides , I had written other transition animation (pushup, push down , push right) but not finished
17:16
eppisai
That was my last week... :)
17:16
BAndiT1983
thanks for the report
17:16
BAndiT1983
vup: you're the next
17:16
vup
I don't really have much to report, mostly worked with tpw_rules and anuejn on their gsoc projects, but was otherwise kept busy by non apertus related stuff
17:17
BAndiT1983
ah, right, the gsoc student anuejn is not here ;)
17:17
BAndiT1983
thanks for the update
17:17
BAndiT1983
seems like Bertl has also gone missing, will report and close the meeting
17:18
BAndiT1983
have mostly worked on the 3d visualiser, as time is still limited, but now it uses the real firmware code, or at least the menu system: http://apertus-open-source-cinema.github.io/AXIOM-Remote/
17:19
BAndiT1983
knob and all the required buttons do work like on the real board, next step is to adjust the firmware, so we can use same loop/logic in 2d and 3d visualiser, besides that we are still optimising the CAD data, as the original export contains quiet subpar geometry, at least not always suitable for realtime 3d and texturing
17:19
BAndiT1983
that would be it
17:20
BAndiT1983
does anybody else wants to report something?
17:20
BAndiT1983
meeting concluded, thanks everyone!
17:23
vup
great work everyone!
18:09
Bertl
sorry, there was a network outage here for a little over an hour ... but not much to report from my side anyway
18:09
Bertl
bascially we did set up the remote control shield for the remote and connected it to the remote remote ;)
18:13
vup
any progress on assembling a new beta with sensor?
18:24
Dest123
left the channel
18:25
Dest123
joined the channel
18:28
Bertl
vup: unfortunately no
18:33
vup
ok
19:00
Bertl
off for now ... bbs
19:01
Bertl
changed nick to: Bertl_oO
20:23
fredy
left the channel
21:13
Dest321
joined the channel
21:14
Dest123
left the channel
21:14
Dest321
changed nick to: Dest123
21:50
lexano
left the channel
22:06
lexano
joined the channel
23:35
fredy
joined the channel
23:52
fredy
left the channel
00:54
tpw_rules
vup: is there a way to run the pydriver with the new zip fatbitstream?
00:55
tpw_rules
also i think it would be nice to have the build/ directory be in the current directory. i don't like mixing the code with the build products
00:58
vup
tpw_rules: `./fatbitstream.zip --run` should work
00:59
tpw_rules
i thought that's what i did, let me double check...
00:59
vup
I think we all agreed on the build directory thing, so I am changing it back to a build directory at the caller site again
00:59
tpw_rules
yes, i looked back and anuejn said he did not care one way or the other
00:59
vup
yeah