#apertus IRC Channel Logs

and how do Pipeline clocks work?

does fifo_chop.vhd downsample the data in some way?

nmigen does not support gearbox fifos, but we have a StreamGearbox that should work

fifo_chop does not downnample (atleast when the input signals are setup as they are) its just a gearbox

I would also vote for packed

morning folks!

the sensor is 12 bits per pixel, we could fit 5 pixels in 60 bits but that's kind of weird

like it takes in 16 pixels per cycle and outputs 4

tpw_rules: well you can fit 16 x 12 bits into 3 x 64 bits

the par_clk of fifo_chop is the serdes (bit) clock, so it does not get 16 pixels every cycle

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?

remap_data

that should work if you setup the cross domain constraints correctly, but its probably safer to do it with actual CDC

I think you have to be careful, but yes

but then presumably timing would not pass

is that something we should be thinking about?

it would be nice to one day get rid of vivado and use a open source flow

But its not *that* important.

okay

i'm also also thinking it might make sense to implement all the gearing and getting images into DRAM before the remapper

like i said i don't think the remapper has any gearing in it so it should be easy to drop in

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?

Ahh

yeah that seems fine

and yeah probably makes sense as something like the gearing and DRAM writer will be useful in debugging the remapper

https://github.com/apertus-open-source-cinema/naps/blob/main/applets/camera.py does this applet work fully

ok

that indeed seems broken

who is here?

Bertl: are you also there?

Dest123: please report your progress

so last week t_exp1 signal wasn't triggering the channels

so I modified the HDL and this time around the channels were active and the data was fully sent

Bertl suspects a problem with the control channel so we are going to connect the design with the logic analyzer today

That's it for me :)

tpw_rules: you are

everything looks good now and it got merged yesterday, which is great news. so that section is completed

i will put off the remapper until later

i guess that's it for me

eppisai: the stage is yours

Last week, I was setting up the core timer in remote

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

Also, ftp module arrived last week! :D

Andrej has helped sitting it up.. my serial console is working at last

Hahaha.. sorry auto correct

Usb to UART ft4232h mini module arrived last week

That was my last week... :)

vup: you're the next

ah, right, the gsoc student anuejn is not here ;)

seems like Bertl has also gone missing, will report and close the meeting

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

does anybody else wants to report something?

great work everyone!

bascially we did set up the remote control shield for the remote and connected it to the remote remote ;)

vup: unfortunately no

off for now ... bbs

vup: is there a way to run the pydriver with the new zip fatbitstream?

tpw_rules: `./fatbitstream.zip --run` should work

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

yeah