#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

Bertl: morning!

singing contest?

Different?

(to the code, not the application :)

this will be somewhat similar to what we do during actual GSoC development, so it will give us all some idea what to expect

Hey bertl

Okay!

Yeah, it's a great idea! (And I'm grateful it's not a singing contest 😅)

Indeed.

Bertl: good idea, as this year real task were selected for challenge, was reading through FAQs of other orgs and they do it similarly, like considering contributions from student and explicitly saying that people should know their way around, so less of spoon-feeding

XD

*likely

yeah, looks okay to me, formatting needs some love

Oh okay will work on it!

Wanted to ask what all hardware will be provided ?

we will provide a remote Axiom Beta for this purpose

For the task we are expected to optimize the remapper and include more features.Do we need to build separate remapper for all the modes?

Bertl: I was going through the schematics...I was wondering what do /4.5B, /4.2C etc postfixes in the labels mean....?

A_ i mean

Bertl: did you get the camlink 4k with the stock firmware to capture video from the beta?

I found these pins at the PIC16s

Oops sorry...its all part of the main board..yes

so, on the Axiom Beta Main Board, there are two MachXO2 which we refer to as routing fabrics

the direction West/East/North/South is to make it simpler to localice parts and functions

bluez_[m]: so for example the routing fabric west also connects to the west shield place which has a north and a south connector

yes, that's what we are aiming for

all those would be good to cover in the remapper

Hello

Hey bertl, would you check my qualification task

https://github.com/Destfolk/SPI-UART-Bidirectional-Bridge

i.e. a /2.7B means page 2, grid 7B

hope that clarifies the nomenclatures

So thats what you meant by /dev/rfe before?! Gosh I should hv asked you dat... i hv been wondering what that device meant ':D

Yes it does...thanks!

Bertl: Is it possible to include all these features in single remapping code?

> the A_ and B_ originate from the Power Board where we have two I2C busses (or more precisely one which can be switched)

preetimenghwani[: but we can also use dynamic reconfiguration

(depending on the power board version)

the mux/analog switch can be controlled from the Zynq side

replacing parts of the FPGA config memory at runtime

Oh that sounds interesting! Will read more about it!

Oh okay...but what's its purpose? The switching?

Bertl Actually i was planning to include binning and subsampling for future goals

Now i guess i should include those also

> the main reason for this solution was the shortage on GPIOs from the zynq side

Bertl, did you get a chance to see the code?

bluez_[m]: there are two I2C busses controlled by the Zynq

Bertl: also I wanted to ask reading out from DDR memory is not the part of task right?

could i just make the camlink think, that the signal from the beta is YUV and then interpret it as RGB afterwards?

Dest123: url?

> one is the main control bus for the power board

Bertl: so how does the camlink know, that we do RGB?

Ohh i see...

so it is unclear, why it doesnt work?

bluez_[m]: the second I2C bus is routed and switched (mux) on the power board, but not used

and there they are connected to the PICs

there are several options for this

Bertl: ok got it...thanks :)

Bertl: please provide some examples

for real world testing there are two options

Bertl:And Reading out data from DDR memory is not a part of task right?

preetimenghwani[: no, for verification you can use the ARM cores (i.e. Linux)

i.e. to verify that the data is stored correctly

Dest123: formatting is still really bad, especially indentation and spacing

indentation and spacing

Dest123: let me give you an example here:

line 38 the typedef is at the same level as architecture

(same for the other 6 lines of course)

line 128, if(rst has a missing space

Ok

shouldn't take you long to fix them now .. about half an hour at most

personally I think proper code style and formatting are major quality aspect of programming

Bertl: I'm done, can you take a look?

Bridge.vhd line 141

181 and 183

Fixed all but 181, 183

spaces around the operator?

Fixed them 😀

Dest123: yes, still problems

still in the Bridge.vhd

make a guess

see, here is the problem with bad formatting

now line 200 looks like another if, but instead it is tied to the previous one

I see

please do so

sure about that? checked all files?

tb.vhd after line 46?

everything else perfect now?

in UART Tx.vhd (btw, bad idea to use spaces in filenames)

The space before the bracket?

indeed, a matter of consistency

Hello Bertl!

Also, my code have timing violations which I am unable to resolve, Please give me a hint on how to deal with them

well, besides that your 'ideal' is not really ideal here ...

so when you encounter 'stop' or 'MOSI' how do you know that those are two states of the same signal?

sure, I got the information I needed, tx

All the tasks are fairly interesting, but I thought about the pixel remapper at first as it is concerned with the memory, and currently I'm designing an SRAM so I thought that would help

SRAM is five lines of HDL, not sure how that relates to the remapper

(i.e. not much competition so far :)

I'll take a look at T728

When I said designing SRAM I didn't mean writing HDL code, I'm working on transistor-gate level, and I know it is not that relevant, so I didn't divulge into the information. So that's why I said it is not the idea behind what I meant

okay

sure, go ahead

Shouldn't the emulator in both cases just generate the data?

bitstream test data is probably best generated by a PRNG or similar generator

Same goes for the Fake video data?

yup

off to bed

nn

Bertl: for 32sensel 12 bit we need to build a new remapper or work on improving the existing one?

I think the existing one is a good reference and should work in simulation and for comparison (gate count, performance, etc)

strategies to decrease gate count are probably in dynamic configuration and maybe in partial separation, i.e. using cycles efficiently

probably but a more generic design is likely to be easier and more flexible

And how exactly we need to write in DDR memory? Like a particular pixel should be written on which address ?

preetimenghwani[: DDR is written via AXI high performance interface basically as a stream of words

It is mentioned that sensel and pixel are same is it so?

preetimenghwani[: we use sensel for sensor elements regardless of color and pixel for elements which can be in any color space (e.g. RGB, YUV, etc)

Then where should the still image to be sent from memory is stored?