#apertus IRC Channel Logs

yes, each bit there corresponds to a successfully trained LVDS pair

so I will report now:

I discussed some problems regarding delta re-evaluation with vup

that sadly makes it impossible to go forward with the intended ergonomics of the framework

(to make everything feel less 'magic')

during that I reconsidered some other things too (event handling, some data structures)

yay

thats it from my side

thanks anuejn!

who is here?

hi i am here

great! tpw_rules would you like to start reporting?

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

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

sure, we can go through that after the meeting if you have time

i think that is all from me

any questions/comments here?

Hi

It took longer than I expected ...but I need to do some optimizations here and there before testing it on the hardware

the code is on the lattice branch here

(but should happen this week)

Apart from that

That's it from my side :)

many thanks

hi, though i don't have any personal progress to report (related to apertus)

i have setup his code and currently am testing it on my board here

great, thanks

alright

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

in the course of this feature an FPS counter was added (not committed yet), to be able to track performance via UART

besides that UART processing is planned, especially for ICSP dumping to retrieve firmware from pic16, as a test for protocol processing

many thanks!

Hi :)

There are just some timing issues with the data generation which I'm working on

that's it for me

very quick updates from me:

eppisai: messaged me he wants to wait for next week to have a bigger report to share

manav: you there?

if nobody else has anything to share please Bertl go ahead

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)

but as I plan to start assembling full Betas in the next few days, this shouldn't be a big problem

that's it from my side I guess

anyone else who wants to share/discuss/report anything?

vup: let's talk in half an hour

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

do you have a link to the current gateware source you are testing?

no, give me a minute to push it

ok

And that does not work?

ok

well there are a couple of things

there are a couple of parts to this

you can check a lot of the rails with the `axiom_pac1720_info.sh` script

after running the above two scripts you should see some power consumption on the first two rails

N_VN should be 1.8V and N_VE 3.3V, S_VS 3.0V

that should be ok

although wait

but nonetheless this camera should work with the old gateware so that should not be the problem

yes, the LVDS supply is a little on the high side

the CMV12k has some known PLL and regulator issues

yes, 1.85V is fine

tpw_rules: yeah, but I suspect that the failing link training is due to some contact issue

same camera as anuejn talked about yesterday?

Bertl: yes

yeah, but that clock is vastly slower

do i need to manually instantiate a PLL and connect it to those pads?

tpw_rules: we have abstractions for the PLL on 7series aswell

sure for example here: https://github.com/tpwrules/naps/blob/c26b2cdaa87401a2e81aa6d7782bacad300172b2/applets/camera_usb3.py#L64-L67

yes

just the same way you did for the fclk should work

off for now ... bbl

but first I would try your current gateware after executing the power init scripts

yes

yeah thats what the datasheet says

yes

sure sounds good

(also fyi the lvds_clk used by the current gateware is 250MHz)

they should not

nice

Interesting I wonder where the inversion of CS takes place

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

if i try to set cshigh = False in the spidev library it gives some puzzling error message and nothing changes

ahh

I mean yeah you should want cshigh = True

well i tried to change it to see if it adjusted the behavior

the problem is that inverting cs is pretty ugly... but i think i can clean it up some

yes I can't think of anything that should cause problems

i guess i could, but cs should not be active low

setting active low in the device tree does not work anyway

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

does anybody have any thoughts?

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

I can do that later

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

it's already there, i was talking about in naps, so i can use it in the applets

that sounds like a question for vup

(as they wont be installed on camera; there is no clean solution to that yet)

the next step should be to implement the reg_delay.vhd stuff so training works

alignment of the receiver to the bit, then alignment of the words together

yes, that is the first step

and then you need to adjust it to word boundaries

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

no, pobably not

ah ok, that was the other thing i was trying to remember

so it goes IBUFG -> IDELAYE2 -> ISERDES -> FIFOs for the remapper

and nmigen already handled the IBUFG part, right

:joy:

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

but it might be beneficial if we discuss the design of the current remapper in depth in some other format

I think it took me multiple hours of reading it with vup for me untill I got the basic idea

since it is per spec required to be 200Mhz

(our experiments showed, that some other frequencies work too but to minimize failure points it might be good to adhere to xilinx advisory)

ok

i am feeling a week or two behind on my gsoc timeline

thats life :)

ah well, thats a question to Bertl_oO

so the sensor runs at 250Mbps per channel, correct? or 4ns per bit? but the IDELAYE2 can only adjust 2.4ns or so?

but theoretically it is sufficient to have half the 4ns as wiggle

as the optimal sampling point is a maximum of 2ns away?

also arent we doing 250Mhz ddr so 500Mbps?

i am mistaken

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

ah I wanted to suggest, that you dont create a new record but rather just a new cs signal

oh huh that is some wiredness in camera.py :see_no_evil:

I think that was a debugging leftover from my side; feel free to be inconsistent to wiredness

lets ask Bertl_oO also there

well I do belive vup that he did his research ;)

One way to get a larger delay is to also shift the clock used for the sampling

that is indeed problematic

i didn't think that was true, because isn't it dependent significantly on pcb track length?

tpw_rules: https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt