Current Server Time: 14:43 (Central Europe)

#apertus IRC Channel Logs

2021/06/28

Timezone: UTC


01:10
Bertl_oO
yes, each bit there corresponds to a successfully trained LVDS pair
01:35
fredy
left the channel
01:50
fredy
joined the channel
03:02
intrac
left the channel
03:03
intrac
joined the channel
03:12
Bertl_oO
off to bed now ... have a good one everyone!
03:12
Bertl_oO
changed nick to: Bertl_zZ
06:51
Dest123
left the channel
07:01
Dest123
joined the channel
07:27
Dest123
left the channel
07:29
Dest123
joined the channel
08:59
Dest123
left the channel
11:40
Bertl_zZ
changed nick to: Bertl
11:40
Bertl
morning folks!
12:48
fredy
left the channel
13:12
Spirit532
left the channel
13:13
Spirit532
joined the channel
13:34
anuejn
Morning !
15:53
metaldent
joined the channel
15:56
anuejn
I will not make it for todays meeting :(
15:56
anuejn
so I will report now:
15:56
anuejn
This week I had some progress on the axiom recorder ui
15:57
anuejn
I discussed some problems regarding delta re-evaluation with vup
15:58
anuejn
during that we found something that smells a lot like a rust bug: https://github.com/rust-lang/rust/issues/86675
15:58
anuejn
that sadly makes it impossible to go forward with the intended ergonomics of the framework
15:59
anuejn
however, we decided that some more explicit passing of the context in which the widgets get evaluated might be beneficiail anyway
15:59
anuejn
(to make everything feel less 'magic')
16:00
anuejn
so I started to implement that
16:00
anuejn
during that I reconsidered some other things too (event handling, some data structures)
16:01
anuejn
event handling previously had a minimum delay of one frame which should be gone after this round of refactoring
16:01
vup
yay
16: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)
16:02
anuejn
thats it from my side
16:02
vup
Nice work!
16:56
se6astian
thanks anuejn!
17:00
se6astian
MEETING TIME!
17:00
se6astian
who is here?
17:00
Bertl
is here
17:01
vup
is here
17:01
vnksnkr
is here
17:02
tpw_rules
hi i am here
17:02
BAndiT1983
is here
17:03
se6astian
great! tpw_rules would you like to start reporting?
17:03
metaldent
is present
17: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
17: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
17: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
17: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
17:05
vup
sure, we can go through that after the meeting if you have time
17:05
tpw_rules
ok, i do. let's do that
17:05
tpw_rules
i think that is all from me
17:06
se6astian
many thanks tpw_rules!
17:06
se6astian
any questions/comments here?
17:06
se6astian
otherwise vnksnkr is next
17:07
vnksnkr
Hi
17:08
vnksnkr
So last week with some help from Bertl I was able to write up some code for the jtag interface
17:09
vnksnkr
It took longer than I expected ...but I need to do some optimizations here and there before testing it on the hardware
17:09
vnksnkr
https://github.com/vnksnkr/remote-test-system.git
17:09
vnksnkr
the code is on the lattice branch here
17:09
Bertl
that's good as I haven't checked the hardware yet either ;)
17:10
Bertl
(but should happen this week)
17:11
vnksnkr
right..I hope to finish the hdl part soon too
17:11
vnksnkr
Apart from that
17:11
Dest123
joined the channel
17:12
Dest123
is here
17: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
17:12
vnksnkr
That's it from my side :)
17:13
Bertl
thanks!
17:13
se6astian
many thanks
17:14
se6astian
metaldent, your turn
17:14
metaldent
hi, though i don't have any personal progress to report (related to apertus)
17:15
metaldent
but last week i helped Aman with his obstacles
17:15
metaldent
i have setup his code and currently am testing it on my board here
17:17
metaldent
that's it from my side but surely Aman will report about it further...
17:18
se6astian
great, thanks
17:18
se6astian
BAndiT1983: your turn
17:18
BAndiT1983
alright
17:18
BAndiT1983
am mainly focussing on remote development and guiding eppisai
17: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
17: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
17:21
BAndiT1983
in the course of this feature an FPS counter was added (not committed yet), to be able to track performance via UART
17: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
17:22
BAndiT1983
besides that UART processing is planned, especially for ICSP dumping to retrieve firmware from pic16, as a test for protocol processing
17:22
BAndiT1983
that would be it from me
17:22
se6astian
many thanks!
17:23
se6astian
Dest123: please go ahead
17:23
Dest123
Hi :)
17: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
17:24
Dest123
There are just some timing issues with the data generation which I'm working on
17:24
Dest123
Once resolved, I can start with hardware testing maybe at the end of the week
17:25
Dest123
that's it for me
17:26
se6astian
many thanks
17:26
se6astian
very quick updates from me:
17: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
17:27
se6astian
eppisai: messaged me he wants to wait for next week to have a bigger report to share
17:27
se6astian
vup also has no news to report
17:27
se6astian
manav: you there?
17:28
se6astian
anuejn: reported slightly before the meeting, so you can check that out in the logs
17:28
se6astian
if nobody else has anything to share please Bertl go ahead
17:28
Bertl
thanks
17: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)
17:30
Bertl
unfortunately there is something weird with the Power Board on that one and I couldn't get it working reliably
17:31
Bertl
but as I plan to start assembling full Betas in the next few days, this shouldn't be a big problem
17:32
se6astian
was about to ask about hardware testing and rework progress
17:33
Bertl
that's it from my side I guess
17:34
se6astian
many thanks!
17:34
se6astian
anyone else who wants to share/discuss/report anything?
17:36
se6astian
ok then, many thanks everyone! MEETING CONCLUDED!
17:36
tpw_rules
vup: let's talk in half an hour
17:36
vup
ok
18: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
18:05
vup
ok, could you describe you current setup a bit more
18:05
vup
do you have a link to the current gateware source you are testing?
18:05
vup
What steps are you taking exactly to test the SPI with your gateware?
18:05
tpw_rules
no, give me a minute to push it
18:08
tpw_rules
ok here is the applet i made: https://github.com/tpwrules/naps/blob/spi-driver/applets/cmv12k/spi_test.py
18:08
vup
ok
18: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.
18:09
vup
And that does not work?
18: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
18:10
vup
ok
18:10
tpw_rules
so i wonder if the pinout is wrong, or the sensor is not actually turned on
18:10
vup
well there are a couple of things
18:10
vup
first of all, you need to enable the power rails used by the sensor
18:11
vup
there are a couple of parts to this
18:12
vup
but first running the `axiom_power_init.sh` script (as root) and then the `axiom_power_on.sh` script should suffice
18:12
vup
you can check a lot of the rails with the `axiom_pac1720_info.sh` script
18:12
vup
here the sensor uses the N_VN, N_VE and S_VS rail
18:13
vup
after running the above two scripts you should see some power consumption on the first two rails
18: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
18:14
vup
N_VN should be 1.8V and N_VE 3.3V, S_VS 3.0V
18:14
tpw_rules
ok, the latter two are 0.1v low
18:14
vup
that should be ok
18:14
tpw_rules
or were, last night
18:15
vup
although wait
18:16
vup
Bertl: the datasheet of the CM12k specifies 1.95 to 1.98V for VDD18, is that normal?
18:16
vup
but nonetheless this camera should work with the old gateware so that should not be the problem
18:16
tpw_rules
well it does not complete training. but at least that implies SPI access does work
18:16
Bertl
yes, the LVDS supply is a little on the high side
18:17
Bertl
I suspect because they had problems when all channels are active
18:17
Bertl
the CMV12k has some known PLL and regulator issues
18:18
vup
makes sense, but with half the channels 1.85V should usually work?
18:18
Bertl
yes, 1.85V is fine
18:20
Bertl
also note that the pac1720 info is usually a little on the low side
18:20
vup
tpw_rules: yeah, but I suspect that the failing link training is due to some contact issue
18:20
tpw_rules
me too
18:20
Bertl
same camera as anuejn talked about yesterday?
18:22
vup
ok, so the other thing is generating the clock for the sensor directly with the fclk
18:22
vup
Bertl: yes
18:22
tpw_rules
i figured that should work as that's done with the hispi sensor
18:23
vup
yeah, but that clock is vastly slower
18:23
tpw_rules
true
18:23
tpw_rules
do i need to manually instantiate a PLL and connect it to those pads?
18: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
18:24
vup
tpw_rules: we have abstractions for the PLL on 7series aswell
18:24
tpw_rules
ok, do you have any pointers?
18:26
vup
sure for example here: https://github.com/tpwrules/naps/blob/c26b2cdaa87401a2e81aa6d7782bacad300172b2/applets/camera_usb3.py#L64-L67
18:26
tpw_rules
is that multiply by 60, divide by 1?
18:26
vup
yes
18: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?
18:27
vup
just the same way you did for the fclk should work
18:27
Bertl
vup: then it is very likely a contact issue
18:28
Bertl
off for now ... bbl
18:28
Bertl
changed nick to: Bertl_oO
18:28
vup
but first I would try your current gateware after executing the power init scripts
18:29
tpw_rules
okay, maybe i will lower the frequency to be sure. 100MHz was the datasheet minimum iirc, right
18:29
vup
yes
18: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
18:30
vup
yeah thats what the datasheet says
18:31
tpw_rules
does the regular firmware supply this clock?
18:32
vup
yes
18: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
18:32
vup
sure sounds good
18:33
vup
maybe Bertl_oO can also confirm if the clk is necessary for normal operation or not
18:33
vup
(also fyi the lvds_clk used by the current gateware is 250MHz)
18:39
tpw_rules
do the two power on scripts rely on anything in the gateware?
18:40
vup
they should not
18:45
metaldent
changed nick to: metaldent_Sss
18:45
metaldent_Sss
left the channel
18:50
tpw_rules
ah, it's alive!!!
18:50
vup
nice
18:51
tpw_rules
looks like the problem was power, and i got CS backwards
18:57
vup
Interesting I wonder where the inversion of CS takes place
19: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
19: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
19:03
vup
Yeah thats what I assumed aswell, but quickly scrolling through it made me think it did not invert it either
19:03
tpw_rules
if i try to set cshigh = False in the spidev library it gives some puzzling error message and nothing changes
19:03
tpw_rules
but either way, i should want cshigh to be True so...?
19:03
vup
ahh
19:04
vup
you are setting cshigh externally?
19:04
vup
I mean yeah you should want cshigh = True
19:04
tpw_rules
https://github.com/raspberrypi/linux/issues/3745#issuecomment-663078159
19:04
tpw_rules
well i tried to change it to see if it adjusted the behavior
19:06
vup
well as long as it works :)
19:06
tpw_rules
the problem is that inverting cs is pretty ugly... but i think i can clean it up some
19:07
tpw_rules
also, is it safe to run the power on scripts multiple times?
19:10
vup
yes I can't think of anything that should cause problems
19:10
vup
tpw_rules: can you not just specify that cs is active low in the devicetree?
19:11
tpw_rules
i guess i could, but cs should not be active low
19:14
vup
I mean yes, but it seems the cleanest hack sofar :)
19:18
tpw_rules
setting active low in the device tree does not work anyway
19:25
vup
interesting
19: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
19:33
Dest123
left the channel
19:36
tpw_rules
does anybody have any thoughts?
19:43
tpw_rules
anuejn: ?
19: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
20:00
vup
The kernel module not being there by default and the missing spidev python module can easily be added to the firmware images
20:00
vup
I can do that later
20:00
tpw_rules
okay. i can send a PR for the kernel module. and add the spidev to the requirements for naps
20: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
20: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
20:04
tpw_rules
it's already there, i was talking about in naps, so i can use it in the applets
20:05
tpw_rules
btw, do you know how to label in the device tree the particular spi port as belonging to the sensor?
21:22
anuejn
that sounds like a question for vup
21:22
anuejn
you dont have to specify the dependencies for naps driver code in the naps requirements
21:23
anuejn
(as they wont be installed on camera; there is no clean solution to that yet)
21:27
tpw_rules
well in any case i submitted PRs
21:27
tpw_rules
the next step should be to implement the reg_delay.vhd stuff so training works
21: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
21:28
tpw_rules
alignment of the receiver to the bit, then alignment of the words together
21:30
anuejn
well you need to adjust the "sample point" for each bit
21:30
tpw_rules
yes, that is the first step
21:30
anuejn
(a fer ns sooner or later)
21:30
anuejn
and then you need to adjust it to word boundaries
21:31
anuejn
there are many (more or less smart) techniques you could use
21: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
21:34
tpw_rules
does the IDELAYE2 provide enough wiggle room for alignment to word boundaries?
21:35
anuejn
no, pobably not
21:39
anuejn
for that you need bitslip of the iserdes
21:39
tpw_rules
ah ok, that was the other thing i was trying to remember
21:40
anuejn
(or a barrel shifter; but that would consume much more logic)
21:40
tpw_rules
so it goes IBUFG -> IDELAYE2 -> ISERDES -> FIFOs for the remapper
21:41
anuejn
yup
21:41
tpw_rules
and nmigen already handled the IBUFG part, right
21:41
anuejn
while the IBUFG is probably generated by nmigen
21:41
anuejn
:joy:
21:43
anuejn
probably you want your word / bit alignment detection logic to be at the same place where the fifos are
21: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
21:44
anuejn
I guess the FIFOs cross domains (and the remapper does some up-gearing)
21:45
anuejn
but it might be beneficial if we discuss the design of the current remapper in depth in some other format
21:45
tpw_rules
what do you mean in some other format
21:46
anuejn
I think it took me multiple hours of reading it with vup for me untill I got the basic idea
21:46
anuejn
for the IDELAYCTRL you probably want to internally generate a 200Mhz clock
21:47
anuejn
since it is per spec required to be 200Mhz
21: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?
21: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)
21:50
anuejn
yup the IDELAYCTRL clock is rather a method to calibrate the delay taps of the IDELAY (as i understand it)
21:50
tpw_rules
ok
21:51
tpw_rules
is there a block diagram of all this available anywhere?
21:52
tpw_rules
i am feeling a week or two behind on my gsoc timeline
21:55
anuejn
UG471 is rather helpful but does not provide any high level diagrams
21:55
anuejn
thats life :)
21:57
tpw_rules
i mean of the current gateware
21:59
anuejn
ah well, thats a question to Bertl_oO
21:59
anuejn
but I guess no :(
22: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?
22:22
anuejn
hm.. sounds bad?
22:23
anuejn
but theoretically it is sufficient to have half the 4ns as wiggle
22: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
22:23
anuejn
as the optimal sampling point is a maximum of 2ns away?
22: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
22:25
anuejn
also arent we doing 250Mhz ddr so 500Mbps?
22:25
anuejn
tpw_rules: you are right
22:25
anuejn
i am mistaken
22: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
22: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
22: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
22:29
anuejn
ah I wanted to suggest, that you dont create a new record but rather just a new cs signal
22:30
tpw_rules
oh, duh...
22:31
anuejn
oh huh that is some wiredness in camera.py :see_no_evil:
22:31
tpw_rules
yeah i am not sure. i would prefer it to not be _n but i made it that way for consistency
22:32
anuejn
I think that was a debugging leftover from my side; feel free to be inconsistent to wiredness
22:38
anuejn
re clocking: you also seem to be right
22:39
anuejn
lets ask Bertl_oO also there
22:39
tpw_rules
so you are not sure which data rate it runs at?
22:42
anuejn
well I do belive vup that he did his research ;)
22:44
tpw_rules
ok. maybe i can just ask Bertl_oO to explain the whole algorithm. it does not look much like xilinx's
22:56
vup
One way to get a larger delay is to also shift the clock used for the sampling
22:58
tpw_rules
how can you do that for each of the 32 channels?
22:59
vup
that is indeed problematic
22:59
anuejn
but most likely the delay needed is similiar?
23:00
tpw_rules
i didn't think that was true, because isn't it dependent significantly on pcb track length?
23:01
anuejn
but 4ns * 0.6 * c = approx. 719.5018 millimeter
23:17
vup
tpw_rules: https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt