#apertus IRC Channel Logs

hu

vup: do you have some time to talk in about an hour?

Hi

hi

yes

sure, Ill try to answer them

do you have an existing PHY in VHDL for the sensor? i'm a little unsure of what you mean by the bit and word alignment; is that that the PHY will sync to the datastream appropriately?

the existing VHDL stuff can be found here: https://github.com/apertus-open-source-cinema/axiom-firmware/tree/45cca29/peripherals/soc_main

the existing phy is mainly cmv_pll.vhd + cmv_serdes.vhd combined in top.vhd

bit alignment means, figuring out the correct delay taps for the delay element of the fpga to sample the data at the right point

ok it looks like all that logic is in top.vhd

yeah

(the zynq fpga we are using is a combination of an fpga and two arm cores, connected over axi)

this is the code driving the bit and word alignment: https://github.com/apertus-open-source-cinema/axiom-firmware/tree/2abfb84/software/sensor_tools/train

so i guess that more "with bit and word alignment" is "with the appropriate registers for that algorithm"?

you can of course try and reuse the existing training software, but you can also write your own

as someone who doesn't know much about high speed serdes, how often does training need to occur? the delay is a physical thing, so it should be more or less fixed per camera right? maybe it changes if you unplug and reinsert the sensor

ok. i actually just saw a section in the datasheet that says it is in fact temperature dependent. but it suggests also it's designed to be done while the sensor is operating

tpw_rules: yeah, long term one goal is to continuously monitor the link (as it also transmits the training pattern during normal readout), and retrain as needed

okay. the datasheet also says the maximum total skew is around 4560ps. that's several clock cycles, can the serdes delay taps accommodate that, or have you compensated with routing and/or flip flop delays somehow?

ah, that's cool. if a bit mysterious :)

the general idea is to use the delay element to sample in the middle of the eye and then align the bits relative to each other using the bit-slip

correct, the bit slip block works using the bit clock you provide to the serdes ip block,

yeah, that makes sense

do you use 32 or 64 channels from the sensor?

the remapper will mostly be a translation of the existing VHDL one, with hopefully some simplification using the expanded meta programming possibilities of python / nmigen

a general plus would be if the core would in theory work with 2 / 4 / 8 / 16 / 32 / 64 channels

what do you mean by that?

yes

two remappers get used

then what is the need for the remapper itself to handle 64 channels? an 8192 pixel wide sensor?

sorry that was unclear, I meant the whole core as in the combination of PHYs + remapper cores

note that it makes sense to have less than 64 channels for data transfer and that the sensor can do any 2^n down to 2 IIRC

yeah i got that. we can nail down the exact details once the project starts

tpw_rules: its gpio to the fpga

ok. are there any particular performance requirements or do you just need something that works? it seems like it would be better to just memory map the pins to economize fpga space

there is an SPI peripherial in the Zynq SoC, so that could be used here and would probably reduce the FPGA footprint to a few wires

(this is an example for a bitbanging driver for i2c: https://github.com/apertus-open-source-cinema/nmigen-gateware/blob/bd60e66/naps/cores/peripherals/bitbang_i2c.py)

It doesn't have glitch filters, so you need to implement those yourself

atleast that was my experience, last I used it

tpw_rules: with the code I linked?

vup: hmm, we are using the I2C without any filters and it works just fine ...

tpw_rules: that create a proper i2c device on the linux side, so just accessing `/dev/i2c-n`

oh, yeah ok

might also be a problem of noise introduced by unfortunate routing :)

ah, yes, well, with 100k the noise on the wires must be terrible

well the bitbanging driver has been working quite well so far

tpw_rules: also I don't want to interrupt you, so if you have more questions, just ask

oh, i'm not feeling interrupted. just thinking

I think Bertl can answer that one best

well, the thing is, the student last year was tasked to improve and generalize the existing pixel remapper

i'm a bit confused by how you wrote that. do you think they did a good job on their work and correctly concluded there's not much improvement to make?

yes, it was a successful GSoC project

okay cool. just the way you wrote it sounded to me a bit shaky

probably a language problem, not a native english speaker ;)

rather than interpolate to four color pixels

the current setup is RGB based and the 4K to FullHD debayering is what we do for the preview

tpw_rules: these are the debayering cores currently existing in the nmigen gateware: https://github.com/apertus-open-source-cinema/nmigen-gateware/blob/bd60e66e4e36f21a11899ac6226d089db989c94e/naps/cores/video/debayer.py

nope

does an imagestream know its own resolution?

it has a line_last and a frame_last, which (obviously) mark the end of a line / row and the end of a frame

well yes, its a low pass filter in the sense, that one simply combines the neighbouring pixels of the bayer pattern into one

or do you just need something like (R, G, B) = (p[0, 0], (p[0, 1] + p[1, 0])/2, p[1, 1])

ok cool

here is an example of how these blocks can be connected: https://github.com/apertus-open-source-cinema/nmigen-gateware/blob/bd60e66/applets/camera.py, you see, currently for example the modeline of the hdmi output is not automatically determined from the input image stream, but needs to be manually specified. I think some stream negotiation stuff could be interesting, but thats later down the line.

ok, so i would just be reimplementing that with my new blocks more or less?

for simulation, the existing vhdl gateware unfortunately does not have much in terms of simulation, but for the nmigen gateware there are a lot of smaller and bigger simulation tests

this for example is a test of a hispi input core (some other protocol used by some image sensors): https://github.com/apertus-open-source-cinema/nmigen-gateware/blob/bd60e66e4e36f21a11899ac6226d089db989c94e/naps/cores/hispi/hispi_rx_test.py,

exactly

presumably it's hard because the adjustments are done in the xilinx block

yeah

hmm, what kind of recording?

without word alignment

I do not think we ever did that

what is the metric of optimality for the remapper by the way? logic use?

tpw_rules: mostly bram use + logic use, while being able to run at the required clock speed

the metric depends on the use case, in general it will be FPGA footprint and performance (i.e. throughput)

or is the test just to make sure improving it doesn't break it

Ah I thought you asked, how you test it hase the required performance

is there a way to do that automatically? it's certainly not anything nmigen knows about

hmm

so how exactly does the GSoC submission stuff work in detail? I see i have to have an application submitted by april 13

it is advisable to have the mentors review any application, but it is not a requirement

slots?

off for now ... bbl