#apertus IRC Channel Logs

Hi Bertl

Can you please review it?

no I didn't

probably won't hurt to have it there for others to review

yes !!

*through

s/be always/always be/

Bertl, I submitted the draft.

checking now ...

apurvanandan[m]: everything looks quite good, here a few points you might want to consider though (in timeline and proposal):

you want to plan some time for the Lattice programming interface though which can only be reached via the routing fabric (other Lattice MachXO2)

also I wouldn't focus too much on TMDS as encoding as it is quite convoluted and probably not really necessary for the transmission

as we can't do any retransmissions some kind of data protection or even better data correction should be provisioned (CRC, ECC)

that is a little tricky, but I can try to explain it to you

they are called RFE and RFW (Routing Fabric East and West)

in addition there are a few GPIOs shared between PIC and MachXO2

as this task is still open (unfortunately) a different solution is required (for now)

this way the PIC originally used to program the routing fabric can now also be used to program the plugin FPGA

hope this clarifies :)

with the same python scripts used for programming the plugin FPGA

1) switch PIC to 'direct mode'

3) switch PIC to 'indirect mode'

2) and 4) can use the same python scripts

Is the pass through code already written?

Okay, Bertl will you be available for few hours?

I'm off to bed soon, but I will check it 'in the morning' when I get up

well, soon-ish ... about 30 min or so

you can probably do the preparations even before the 'community bonding period' so I would use that time for making yourself comfortable with the test setup and the community itself

otherwise it looks quite reasonable to me

hey BAndiT1983. I have understood 3 of the 4 goals for T1121 but am still confused about the goal to move functionality of shell scripts. could you please tell what is expected for it? on moving the scripts, what kind of changes would I need to make?

afterwards replicate shell scripts in daemon, e.g. setting color matrix

ok BAndiT1983. but where can I find data about the registers?

in scripts or at our wiki, e.g. https://wiki.apertus.org/index.php/CMV12000_Register_Blocks

great! thanks

also BAndit1983: do all scripts need to be moved?

ok

> this includes evaluating how to send data in proper way to daemon

nope, to daemon

eh, i mean from CLI or webremote yes

ok, got it

hi

do i have to be professional on certain tasks or just a beginner level.

Will i be eligible to apply for this ...

yes

are you at least 18 years old?

i am 22 years old now

are you residing in a country that is not currently embargoed by the United States?

i am from Pakistan

yup i am

nope i never tried properly

well then you are elegible to apply within GSoC

i got no hope ..

well GSoC is indeed an elite program and not for beginners :)

took me a while to understand that and am going to miss my last chance..

yes

i did worked with fpgs before

stuff like making a processor , processing an image from VGA port of fpga

i was pretty much fancy to fpga stuff but since there wasnt any proper support or guideline i held back

do anything about it ..

....

hi, I have some questions about the goals of the AXIOM Remote task. I want to clarify what exactly I would have to do with the event handling implementation, because I’ve seen that the rotary knob or the button interactions already work and I would like to know what else are you planning to do

there is no actual event handling implemented yet

Hi se6astian ,It was once mentioned in the logs about implementation of sysfs being one of the tasks to be done to read temperature or voltage. But why do we need it when we can read the temperature from the CMV register 127. although it was BAndit1983 who mentioned it, but maybe you know the answer to this too

ok, thanks! And about the page setup could you explain me a little bit what do you have in mind?

"Parameters which are dependent on temperature and voltage of the sensor"

there are several temperature sensors in the AXIOM Beta hardware

so reading those is a task for the daemon

nira: pages like page_wb.c or page_wb_help.c currently all reinvent the wheel by doing everything from scratch (init_*, draw_*, etc.)

making it easier to create/maintain additional pages

in the end the axiom remote will contain a lot of pages, so we should make it easier to handle many of them

mrohit[m]: did you take a look at the image sensor datasheet already?

that's where I found that CMV Register 127 will provide temperature of the image sensor

subsampling, gain, offsets, PLR, etc.

some

that would require some tests

off now to drive to the axiom office

let me know if you have any more comments or suggestions regarding my proposal

Hii how can i join apertus

Hey, did anyone get time to go through my proposal?

I didnt see anything that would justify a comment/change suggestion, but then I am not mentoring this task :)

morning folks!

morning

thanks se6astian, I will wait for BAndiT1983 to review it :)

let's hear then

really depends on how the data is fetched and what data is required for compression

random memory access is probably way too slow

the data to be compressed are the frames

hi saurabh_raj

should I send google docs link to you email?

or through the gsoc draft proposal

yes google doc link

saurabh_raj: because it is very close now, you are probably best off submitting it as draft proposal to GSoC

Hey se6astian I have sent the link to google docs on the team email id. It would be great if you could go though them.

ok. the encoder actually support both. as far as the encoder is concern, the inputs are sequential pixels and the output is encoded pixels, so no need for reading from different places, the pattern problem is related to the format/container ie DNG or MLV.

correct, that is another task this year

which one open cine or image calibration?

hello Bertl

can you check my draft proposal :)

I have Sent a new mail

no its still a draft

cool, so if an encoder is placed between the memory readers and the usb3 module, taking the sequence from memory and provide encoded data to usb3, how many pixels should be encoded per cycle? the problem is that the encoding is a sequential operation, which mean we can't put two cores to handle the same frame and combine the results, either the parallelism to be implemented in the core itself, or splitting the frame into subframes can

Ok 1 min :)

which would be more complex, so I think the question is what is the maximum fps to be supported? at 100Mhz for example if only one pixel is encoded per cycle it would be maximum of 100 million pixels/second which is around 11fps.

Fares: from a filmmakers perspective full resolution at 24/25/30 FPS would be the minimum requirement for it to be useful

So 377487360 pixels/second. then 4 input pixels per cycle, great.

more input pixels per cycle = more fabric consumptions. for usb 3.0 I think 4 pixels/cycle on 100Mhz clk will be sufficient for 4096x3072 at 30fps.

faster IO ports are not planned for the immediate future

(assuming no compression of course)

but we can have two USB 3.x plugin modules on the Beta

yes of course

did I say that?

apurvanandan[m]: btw, aSobhy has just submitted a proposal for the bidirectional protocol, so you might want to chat about JTAG as one use case for programming the plugin module :)

yeah I saw the chat of yesterday :)

also this way other community members can chime in and (sometimes) provide useful input

if you two have nothing against it i think doing the discussion in the main channel would good as it gives others a way to follow the discussion and possibly contribute to it

ah well Bertl beat me to it

so for example some way to alternatively stream it to memory could be helpful

aSobhy: I looked at your proposal, please consider adding technical details about how you plan to solve the task

aSobhy: but it general it looks okay ... also consider reserving some time for bandwidth and error rate testing on the Zynq - MachXO2 connection

Fares: makes sense to me and as the USB solution would just connect to the memory reader itself that would be a good place

(fetching memory twice is probably not an option)

isnt that the task for the entire project?

I am not saying that it has to be that long or that longer than necessary is better

the CV is a little short as well ... i.e. could use some more personal information (but it is sufficient)

it is definitely beneficial when the mentors can see that you have spent some time and thought on the problem and already have an idea and plan how to tackle it

for the CV I eliminate all unnecessarily data and I'll add personal information sure :)

Fares: do you mind sharing your proposal?

ah nvm, got the mail xD

ok :) I tried to keep it as simple as possible so if you have any questions, please ask.

Fares: btw do you now about nmigen

off for now

https://github.com/m-labs/nmigen/blob/master/doc/PROPOSAL.md

and while it provides a compatability layer for backwards compatability with migen the new "syntax" and other things provide substantial improvement over migen

Hi aSobhy

Could you brief me out how will you implement JTAG protocol

Fares: sounds good

Bertl: please check BNC, cannot conenct from my normal IRC client

(and has a nice mobile client)

Bertl: on the two usb 3 plugings for more bandwidth: do the root ports of an xhci controller share bandwith or does each root port provide full 5gbit/s? sure, one ft60x doesn't use the full 5gbit/s, but more than the half

BAndiT1983|away: will do

Please also check timeline and "Breif tentaive work " section. It would be great if i get some technical feedback from you

Bertl, what improvements on Lattice programming interface are required ?

nah, once you reach the 'bonus material' phase we might already have the Zynq - MachXO2 bridge working

:D

Ok :)

between Zynq and MachXO2?

well, you control both ends, so basically anything you can come up with :)

Can the one used in task be used, like 0xBAF for training, as in 10b not all symbols are used ^^'

hey BAndiT1983_webcl , I did the changes which u have suggested for proposal and challenge (about variable names etc) , Can u please check my timeline and "breif tentative working " sections of proposal

hi Dev_, will try later when i have time

BAndiT1983_webcl : can you spare 5 minutes right now. I just sent you a mail. wanted to clarify some things.

back again

hi rohan_

it's daemon <-> WSServer <-> WebRemote

devserver is something that Francis has implemented and uses for quick tests without daemon, although it's not hard to start daemon, if build with ENABLE_MOCK=1 to prevent memory access on normal PC

currently the descriptions are retrieved from daemon through certain command: e.g. DaemonCLI general get available_methods

this should give back a list, which is based on description.json from daemon, but current values are filled in before sending it to the requester

so for handshake, is the task to pass descriptions retrieved from daemon to the WebRemote through the WSServer?

but adjustments in web remote need to be done, if not already there

okay okay, but for the new parameters, we would have to save them in description.json so that Daemon can read them also right?

daemon doesn't care for description.json much, as it's providing certain functionality, using the file primarily for web UI

at least to the web UI

or is there more to it?

hi parimal, no, as i had not much time, trying to look through proposals and comment on them one by one

we don't have that many active repos, try to guess ;)

Hi BAndiT1983, I sent you a mail regarding the c++ task , please check whenever you have time

do you want a reply by mail or here?

will check more tomorrow, if i have time, but my work occupies a lot currently

BAndiT1983 <we don't have that many active repos, try to guess ;)> is the the Adapter in control-daemon

rohan_: which repos were updated lately?

and this thing is the easiest

am I right?

both firmware and control-daemon repos were updated recently

*control daemon

hey rohan_ , maybe this is what you are looking for :

this is control daemon repo? really? then someone has changed it recently

<this is control daemon repo? really? then someone has changed it recently>?

<rohan_> so is handshake only about adjustments in web remote, if not already present? [01:00] <rohan_> or is there more to it? [01:02] <BAndiT1983> only web UI at the moment, if you find other usage areas, then you can propose how to apply it

it was exactly what I meant to say here when I said web remote

there was a push recently, so the first step would be to evaluate current state of it

but I couldn't understand what you meant by your message after that. I thought you tried to mean I that I was saying something wrong

off for today, good night

Hi,

and also other additions are there

their are 2 reports the FMax = 665 MHz and the Restricted Speed = 250

and the post-implementation is restricted to 250 MHz

Are you asking me?

Hi :)

Ok

And i have seen your question to me but as you see

It very simple, you just need to send data at both clock edges

I am switching between the Q.T and proposal

Or there is much simple way as far as I know, if you want to give a try it won't take much time. Take the IDDR and ODDR primitives connect them to the IOB as the pins are inout type you could use hardware loopback.

But the problem will be the same since the path between the pins and the cells will be the same so doubling the read rate will end with reducing the freq to half

What is your FPGA?

Beyond this only Bertl can help.

Can you explain me in short after completion of your project , how will the plugin modules be programmed

The PLL, MMCM, ISERDES, OSERDES

as per my knowloedge

Sure, I want to finished the task to be free to think :D

Good luck! :D

Actually, that isn't that much issue. I just wanted to learn programming the plugin modules using the bidirectional packet protocol'

(and didn't notice)

aSobhy: what is the part you are currently using?

i tried on both max10 and Cyclone

well, the cyclone IV can certainly do more than 250MHz

it reports FMAX: 680 MHZ and restricted 250

yes

(which is a problem of your design)