Current Server Time: 17:38 (Central Europe)

#apertus IRC Channel Logs

2021/06/28

Timezone: UTC


00:10
Bertl_oO
yes, each bit there corresponds to a successfully trained LVDS pair
00:35
fredy
left the channel
00:50
fredy
joined the channel
02:02
intrac
left the channel
02:03
intrac
joined the channel
02:12
Bertl_oO
off to bed now ... have a good one everyone!
02:12
Bertl_oO
changed nick to: Bertl_zZ
05:51
Dest123
left the channel
06:01
Dest123
joined the channel
06:27
Dest123
left the channel
06:29
Dest123
joined the channel
07:59
Dest123
left the channel
10:40
Bertl_zZ
changed nick to: Bertl
10:40
Bertl
morning folks!
11:48
fredy
left the channel
12:12
Spirit532
left the channel
12:13
Spirit532
joined the channel
12:34
anuejn
Morning !
14:53
metaldent
joined the channel
14:56
anuejn
I will not make it for todays meeting :(
14:56
anuejn
so I will report now:
14:56
anuejn
This week I had some progress on the axiom recorder ui
14:57
anuejn
I discussed some problems regarding delta re-evaluation with vup
14:58
anuejn
during that we found something that smells a lot like a rust bug: https://github.com/rust-lang/rust/issues/86675
14:58
anuejn
that sadly makes it impossible to go forward with the intended ergonomics of the framework
14:59
anuejn
however, we decided that some more explicit passing of the context in which the widgets get evaluated might be beneficiail anyway
14:59
anuejn
(to make everything feel less 'magic')
15:00
anuejn
so I started to implement that
15:00
anuejn
during that I reconsidered some other things too (event handling, some data structures)
15:01
anuejn
event handling previously had a minimum delay of one frame which should be gone after this round of refactoring
15:01
vup
yay
15:01
anuejn
also I build a solution for remotely powering on / off the beta I currently have for tpw_rules to use (via etherpad :D)
15:02
anuejn
thats it from my side
15:02
vup
Nice work!
15:56
se6astian
thanks anuejn!
16:00
se6astian
MEETING TIME!
16:00
se6astian
who is here?
16:00
Bertl
is here
16:01
vup
is here
16:01
vnksnkr
is here
16:02
tpw_rules
hi i am here
16:02
BAndiT1983
is here
16:03
se6astian
great! tpw_rules would you like to start reporting?
16:03
metaldent
is present
16:04
tpw_rules
i suppose i can. i have been having difficulty getting my code working. i was able to access anuejn's beta remotely and try it there, but it did not work. partially i think i am missing some steps in powering up the sensor correctly to get it ready to talk
16:04
tpw_rules
but also there is a hardware issue and it does not fully complete initialization using the existing firmware. anuejn is currently troubleshooting that i believe
16:04
tpw_rules
i am not sure who is the best authority but i think i will need to work with vup on identifying power management controllers, etc, and listing the steps to turn on the sensor and what all needs to be done
16:05
tpw_rules
but i do have the linux spi driver compiled for the beta and successfully talking to the gateware, as far as i can tell. it is a problem between the gateware and the sensor
16:05
vup
sure, we can go through that after the meeting if you have time
16:05
tpw_rules
ok, i do. let's do that
16:05
tpw_rules
i think that is all from me
16:06
se6astian
many thanks tpw_rules!
16:06
se6astian
any questions/comments here?
16:06
se6astian
otherwise vnksnkr is next
16:07
vnksnkr
Hi
16:08
vnksnkr
So last week with some help from Bertl I was able to write up some code for the jtag interface
16:09
vnksnkr
It took longer than I expected ...but I need to do some optimizations here and there before testing it on the hardware
16:09
vnksnkr
https://github.com/vnksnkr/remote-test-system.git
16:09
vnksnkr
the code is on the lattice branch here
16:09
Bertl
that's good as I haven't checked the hardware yet either ;)
16:10
Bertl
(but should happen this week)
16:11
vnksnkr
right..I hope to finish the hdl part soon too
16:11
vnksnkr
Apart from that
16:11
Dest123
joined the channel
16:12
Dest123
is here
16:12
vnksnkr
I'm having my end semester exams in 2 weeks..now that the covid condition has lowered in my area..so my progress might slow down..but still I will try my best keep up with my timeline
16:12
vnksnkr
That's it from my side :)
16:13
Bertl
thanks!
16:13
se6astian
many thanks
16:14
se6astian
metaldent, your turn
16:14
metaldent
hi, though i don't have any personal progress to report (related to apertus)
16:15
metaldent
but last week i helped Aman with his obstacles
16:15
metaldent
i have setup his code and currently am testing it on my board here
16:17
metaldent
that's it from my side but surely Aman will report about it further...
16:18
se6astian
great, thanks
16:18
se6astian
BAndiT1983: your turn
16:18
BAndiT1983
alright
16:18
BAndiT1983
am mainly focussing on remote development and guiding eppisai
16:19
BAndiT1983
regarding remote, have added custom area drawing, this means, that we can transfer selected area to the display, avoiding the need to transfer full framebuffer
16:20
BAndiT1983
what's missing now is some logic to select such area automatically, e.g. if 2 list entries change their state, then also only trasnfer this area, as display memory is non-volatile and does not need refresh over and over
16:21
BAndiT1983
in the course of this feature an FPS counter was added (not committed yet), to be able to track performance via UART
16:21
BAndiT1983
exception handling was adjusted and already helped to track down problems with crashes, e.g. in menu transition code, but awaiting my FT4232H adapter soon to try JTAG too
16:22
BAndiT1983
besides that UART processing is planned, especially for ICSP dumping to retrieve firmware from pic16, as a test for protocol processing
16:22
BAndiT1983
that would be it from me
16:22
se6astian
many thanks!
16:23
se6astian
Dest123: please go ahead
16:23
Dest123
Hi :)
16:24
Dest123
So I've completed the sensor's output channels and they're ready to be connected to the parallel interface for a test
16:24
Dest123
There are just some timing issues with the data generation which I'm working on
16:24
Dest123
Once resolved, I can start with hardware testing maybe at the end of the week
16:25
Dest123
that's it for me
16:26
se6astian
many thanks
16:26
se6astian
very quick updates from me:
16:27
se6astian
I didnt get to contribute much in the last week unfortuantely but helped test axiom remote related tasks and communication a bit, also the tele hardware assembly bookkeeping is now finished after a meeting to coordinate the last remaining rework steps was concluded
16:27
se6astian
eppisai: messaged me he wants to wait for next week to have a bigger report to share
16:27
se6astian
vup also has no news to report
16:27
se6astian
manav: you there?
16:28
se6astian
anuejn: reported slightly before the meeting, so you can check that out in the logs
16:28
se6astian
if nobody else has anything to share please Bertl go ahead
16:28
Bertl
thanks
16:29
Bertl
well, I tried to get a fourth partial Beta up and running to connect it to the CamLink4k so that Bluez has something to test the dynamic reconfiguration in a real world setup (adjusting HDMI registers)
16:30
Bertl
unfortunately there is something weird with the Power Board on that one and I couldn't get it working reliably
16:31
Bertl
but as I plan to start assembling full Betas in the next few days, this shouldn't be a big problem
16:32
se6astian
was about to ask about hardware testing and rework progress
16:33
Bertl
that's it from my side I guess
16:34
se6astian
many thanks!
16:34
se6astian
anyone else who wants to share/discuss/report anything?
16:36
se6astian
ok then, many thanks everyone! MEETING CONCLUDED!
16:36
tpw_rules
vup: let's talk in half an hour
16:36
vup
ok
17:04
tpw_rules
vup: hello. so i read the sensor datasheet and it looks like the LVDS 600MHz clock needs to be running for the SPI to work, and the sensor needs to be reset. but i just get 0s from the SPI port when trying to read any of the registers. like i said it does work with the firmware scripts but they use a different gateware and there is some power management stuff i don't know about
17:05
vup
ok, could you describe you current setup a bit more
17:05
vup
do you have a link to the current gateware source you are testing?
17:05
vup
What steps are you taking exactly to test the SPI with your gateware?
17:05
tpw_rules
no, give me a minute to push it
17:08
tpw_rules
ok here is the applet i made: https://github.com/tpwrules/naps/blob/spi-driver/applets/cmv12k/spi_test.py
17:08
vup
ok
17:08
tpw_rules
i compile the applet and run the fatbistream, then use the spidev python library to access the spi port in /dev which is created by the BitbangSPI device tree overlay.
17:09
vup
And that does not work?
17:09
tpw_rules
i can reset the sensor with the ControlSignal and verify that the spi access is working from linux by monitoring spi_clks and actual_cs StatusSignals. but the transaction always reads back 0s
17:10
vup
ok
17:10
tpw_rules
so i wonder if the pinout is wrong, or the sensor is not actually turned on
17:10
vup
well there are a couple of things
17:10
vup
first of all, you need to enable the power rails used by the sensor
17:11
vup
there are a couple of parts to this
17:12
vup
but first running the `axiom_power_init.sh` script (as root) and then the `axiom_power_on.sh` script should suffice
17:12
vup
you can check a lot of the rails with the `axiom_pac1720_info.sh` script
17:12
vup
here the sensor uses the N_VN, N_VE and S_VS rail
17:13
vup
after running the above two scripts you should see some power consumption on the first two rails
17:13
tpw_rules
what should those voltages be? i have a log from anuejn's beta of those voltages, but some of them looked wrong
17:14
vup
N_VN should be 1.8V and N_VE 3.3V, S_VS 3.0V
17:14
tpw_rules
ok, the latter two are 0.1v low
17:14
vup
that should be ok
17:14
tpw_rules
or were, last night
17:15
vup
although wait
17:16
vup
Bertl: the datasheet of the CM12k specifies 1.95 to 1.98V for VDD18, is that normal?
17:16
vup
but nonetheless this camera should work with the old gateware so that should not be the problem
17:16
tpw_rules
well it does not complete training. but at least that implies SPI access does work
17:16
Bertl
yes, the LVDS supply is a little on the high side
17:17
Bertl
I suspect because they had problems when all channels are active
17:17
Bertl
the CMV12k has some known PLL and regulator issues
17:18
vup
makes sense, but with half the channels 1.85V should usually work?
17:18
Bertl
yes, 1.85V is fine
17:20
Bertl
also note that the pac1720 info is usually a little on the low side
17:20
vup
tpw_rules: yeah, but I suspect that the failing link training is due to some contact issue
17:20
tpw_rules
me too
17:20
Bertl
same camera as anuejn talked about yesterday?
17:22
vup
ok, so the other thing is generating the clock for the sensor directly with the fclk
17:22
vup
Bertl: yes
17:22
tpw_rules
i figured that should work as that's done with the hispi sensor
17:23
vup
yeah, but that clock is vastly slower
17:23
tpw_rules
true
17:23
tpw_rules
do i need to manually instantiate a PLL and connect it to those pads?
17:23
vup
I am not sure how good the quality of fclk is, it might be worth it to try either a PLL or starting slower with only 100MHz
17:24
vup
tpw_rules: we have abstractions for the PLL on 7series aswell
17:24
tpw_rules
ok, do you have any pointers?
17:26
vup
sure for example here: https://github.com/tpwrules/naps/blob/c26b2cdaa87401a2e81aa6d7782bacad300172b2/applets/camera_usb3.py#L64-L67
17:26
tpw_rules
is that multiply by 60, divide by 1?
17:26
vup
yes
17:26
tpw_rules
how do you attach the PLL output to a pin? is there some internal routing to a specific clock pad on the FPGA? will vivado do that automatically?
17:27
vup
just the same way you did for the fclk should work
17:27
Bertl
vup: then it is very likely a contact issue
17:28
Bertl
off for now ... bbl
17:28
Bertl
changed nick to: Bertl_oO
17:28
vup
but first I would try your current gateware after executing the power init scripts
17:29
tpw_rules
okay, maybe i will lower the frequency to be sure. 100MHz was the datasheet minimum iirc, right
17:29
vup
yes
17:29
tpw_rules
and the `clk` input does not have to be running for SPI, correct? the datasheet said that was just for the temperature sensor
17:30
vup
yeah thats what the datasheet says
17:31
tpw_rules
does the regular firmware supply this clock?
17:32
vup
yes
17:32
tpw_rules
maybe the datasheet is wrong about that point then, i will double check if i cannot get it working without. thank you for the help, i will give it a try in a minute
17:32
vup
sure sounds good
17:33
vup
maybe Bertl_oO can also confirm if the clk is necessary for normal operation or not
17:33
vup
(also fyi the lvds_clk used by the current gateware is 250MHz)
17:39
tpw_rules
do the two power on scripts rely on anything in the gateware?
17:40
vup
they should not
17:45
metaldent
changed nick to: metaldent_Sss
17:45
metaldent_Sss
left the channel
17:50
tpw_rules
ah, it's alive!!!
17:50
vup
nice
17:51
tpw_rules
looks like the problem was power, and i got CS backwards
17:57
vup
Interesting I wonder where the inversion of CS takes place
18:00
tpw_rules
yeah idk why it gets inverted, i don't think it should be. i think the problem is in the drivers somewhere
18:03
tpw_rules
like according to random git comments, CS being active high is the new standard and you need to spec the gpio pins as active low deliberately. but they are not set that way so
18:03
vup
Yeah thats what I assumed aswell, but quickly scrolling through it made me think it did not invert it either
18:03
tpw_rules
if i try to set cshigh = False in the spidev library it gives some puzzling error message and nothing changes
18:03
tpw_rules
but either way, i should want cshigh to be True so...?
18:03
vup
ahh
18:04
vup
you are setting cshigh externally?
18:04
vup
I mean yeah you should want cshigh = True
18:04
tpw_rules
https://github.com/raspberrypi/linux/issues/3745#issuecomment-663078159
18:04
tpw_rules
well i tried to change it to see if it adjusted the behavior
18:06
vup
well as long as it works :)
18:06
tpw_rules
the problem is that inverting cs is pretty ugly... but i think i can clean it up some
18:07
tpw_rules
also, is it safe to run the power on scripts multiple times?
18:10
vup
yes I can't think of anything that should cause problems
18:10
vup
tpw_rules: can you not just specify that cs is active low in the devicetree?
18:11
tpw_rules
i guess i could, but cs should not be active low
18:14
vup
I mean yes, but it seems the cleanest hack sofar :)
18:18
tpw_rules
setting active low in the device tree does not work anyway
18:25
vup
interesting
18:31
tpw_rules
i am wondering the value of using bitbang spi at this point anyway. i had to specially compile the kernel module because it's not in the axiom firmware, the CS is working weirdly, and the spidev python library is not a part of naps either. i wonder if it would be better to just use MMIO
18:33
Dest123
left the channel
18:36
tpw_rules
does anybody have any thoughts?
18:43
tpw_rules
anuejn: ?
18:59
vup
Well using the bitbang kernel module has the aduantage of 1. Needing less code and 2. Providing the standard spidev interface, so hopefully most programs can use it ootb
19:00
vup
The kernel module not being there by default and the missing spidev python module can easily be added to the firmware images
19:00
vup
I can do that later
19:00
tpw_rules
okay. i can send a PR for the kernel module. and add the spidev to the requirements for naps
19:01
vup
The CS thing sucks, but I think its fine to leave it for now and invest some time in it when less interesting stuff awaits
19:04
vup
tpw_rules: PR for kernel module sounds good, you can add the python module here: https://github.com/apertus-open-source-cinema/axiom-firmware/blob/main/makefiles/in_chroot/requirements_pip.txt#L5
19:04
tpw_rules
it's already there, i was talking about in naps, so i can use it in the applets
19:05
tpw_rules
btw, do you know how to label in the device tree the particular spi port as belonging to the sensor?
20:22
anuejn
that sounds like a question for vup
20:22
anuejn
you dont have to specify the dependencies for naps driver code in the naps requirements
20:23
anuejn
(as they wont be installed on camera; there is no clean solution to that yet)
20:27
tpw_rules
well in any case i submitted PRs
20:27
tpw_rules
the next step should be to implement the reg_delay.vhd stuff so training works
20:28
tpw_rules
i need to read up somewhere on techniques for doing that. there is the IDELAYE2 modules; is that the only way delay is applied? i remember reading that there is alignment for each bit, then alignment of each word
20:28
tpw_rules
alignment of the receiver to the bit, then alignment of the words together
20:30
anuejn
well you need to adjust the "sample point" for each bit
20:30
tpw_rules
yes, that is the first step
20:30
anuejn
(a fer ns sooner or later)
20:30
anuejn
and then you need to adjust it to word boundaries
20:31
anuejn
there are many (more or less smart) techniques you could use
20:34
anuejn
for a not very smart approach you can see this: https://github.com/apertus-open-source-cinema/naps/blob/main/naps/cores/plugin_module_streamer/rx.py
20:34
tpw_rules
does the IDELAYE2 provide enough wiggle room for alignment to word boundaries?
20:35
anuejn
no, pobably not
20:39
anuejn
for that you need bitslip of the iserdes
20:39
tpw_rules
ah ok, that was the other thing i was trying to remember
20:40
anuejn
(or a barrel shifter; but that would consume much more logic)
20:40
tpw_rules
so it goes IBUFG -> IDELAYE2 -> ISERDES -> FIFOs for the remapper
20:41
anuejn
yup
20:41
tpw_rules
and nmigen already handled the IBUFG part, right
20:41
anuejn
while the IBUFG is probably generated by nmigen
20:41
anuejn
:joy:
20:43
anuejn
probably you want your word / bit alignment detection logic to be at the same place where the fifos are
20:43
tpw_rules
and the refclk coming back from the sensor is 125MHz right, half the input speed. and that goes to the IDELAYCTRL block and all the SERDESes. do the FIFOs cross domains? or does the refclk run the remapper logic too
20:44
anuejn
I guess the FIFOs cross domains (and the remapper does some up-gearing)
20:45
anuejn
but it might be beneficial if we discuss the design of the current remapper in depth in some other format
20:45
tpw_rules
what do you mean in some other format
20:46
anuejn
I think it took me multiple hours of reading it with vup for me untill I got the basic idea
20:46
anuejn
for the IDELAYCTRL you probably want to internally generate a 200Mhz clock
20:47
anuejn
since it is per spec required to be 200Mhz
20:47
tpw_rules
ah, i couldn't quite tell what that meant. but isn't the input clocked at 125MHz? or does the refclk from the sensor not clock any logic?
20:48
anuejn
(our experiments showed, that some other frequencies work too but to minimize failure points it might be good to adhere to xilinx advisory)
20:50
anuejn
yup the IDELAYCTRL clock is rather a method to calibrate the delay taps of the IDELAY (as i understand it)
20:50
tpw_rules
ok
20:51
tpw_rules
is there a block diagram of all this available anywhere?
20:52
tpw_rules
i am feeling a week or two behind on my gsoc timeline
20:55
anuejn
UG471 is rather helpful but does not provide any high level diagrams
20:55
anuejn
thats life :)
20:57
tpw_rules
i mean of the current gateware
20:59
anuejn
ah well, thats a question to Bertl_oO
20:59
anuejn
but I guess no :(
21:15
tpw_rules
so the sensor runs at 250Mbps per channel, correct? or 4ns per bit? but the IDELAYE2 can only adjust 2.4ns or so?
21:22
anuejn
hm.. sounds bad?
21:23
anuejn
but theoretically it is sufficient to have half the 4ns as wiggle
21:23
tpw_rules
i guess it must work, maybe Bertl_oO can explain. i found https://www.xilinx.com/support/documentation/application_notes/xapp855.pdf but their algorithm seems to need all 4ns of wiggle
21:23
anuejn
as the optimal sampling point is a maximum of 2ns away?
21:24
tpw_rules
how can that be true? suppose the optimal sampling point is -0.1ns, you would have to add 3.9ns of delay because you cannot subtract any
21:25
anuejn
also arent we doing 250Mhz ddr so 500Mbps?
21:25
anuejn
tpw_rules: you are right
21:25
anuejn
i am mistaken
21:26
tpw_rules
also re your git review, i inverted the reset because that's how it is here: https://github.com/apertus-open-source-cinema/naps/blob/main/applets/camera.py i am not sure why
21:26
tpw_rules
i am not sure, it seems the sensor needs to be supplied a 500MHz clock to get 500Mbps. but you said earlier you ran it at 250 when i tried 500
21:27
tpw_rules
and i am not sure what you mean by "why add that level of indirection to all pins?". i tried a simple m.d.comb += pins.eq(self.pins) but that caused an assertionerror somewhere in nmigen so i figured i must be doing it wrong
21:29
anuejn
ah I wanted to suggest, that you dont create a new record but rather just a new cs signal
21:30
tpw_rules
oh, duh...
21:31
anuejn
oh huh that is some wiredness in camera.py :see_no_evil:
21:31
tpw_rules
yeah i am not sure. i would prefer it to not be _n but i made it that way for consistency
21:32
anuejn
I think that was a debugging leftover from my side; feel free to be inconsistent to wiredness
21:38
anuejn
re clocking: you also seem to be right
21:39
anuejn
lets ask Bertl_oO also there
21:39
tpw_rules
so you are not sure which data rate it runs at?
21:42
anuejn
well I do belive vup that he did his research ;)
21:44
tpw_rules
ok. maybe i can just ask Bertl_oO to explain the whole algorithm. it does not look much like xilinx's
21:56
vup
One way to get a larger delay is to also shift the clock used for the sampling
21:58
tpw_rules
how can you do that for each of the 32 channels?
21:59
vup
that is indeed problematic
21:59
anuejn
but most likely the delay needed is similiar?
22:00
tpw_rules
i didn't think that was true, because isn't it dependent significantly on pcb track length?
22:01
anuejn
but 4ns * 0.6 * c = approx. 719.5018 millimeter
22:17
vup
tpw_rules: https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt