#apertus IRC Channel Logs

vedant16[m]: hi, there is also a dedicated VHDL formatter in vscode available

I guess I should start using vscode then :D

vim

<BAndiT1983 "vedant16: hi, there is also a de"> ohh, yup there is

learning vim is a waste of time as it takes a long time to learn�

vedant16[m]: now you will be punished by Bertl

yes there are

btw. have to use vim sometimes at work, as the server don't have nano, so had to learn a bit to find my way around, but for software development vscode or other IDE is more helpful, because of debugging, custom watchers etc.

now I get why vscode is suggested ��

nowadays, when microsoft has bought github, they also own atom.io, if any decision has to be met on their side, they will likely kill that off rather than vscode

and a huge dev community

hi Nishant95, yes, it is, but am not sure if it's complete or if there is some separate repo also, but maybe Bertl, vup or anuejn are available to answer that

morning folks!

morning !

which task?

here is the schematic of the shield to interface with the remote http://vserver.13thfloor.at/Stuff/AXIOM/BETA/axiom_beta_shield_remote_v0.2_r1.1.pdf

it attaches via FFC (flexible flat cables) to a 'breakout board' which is attached to the actual remote

hello. i just saw anuejn's message in #nmigen about porting some apertus gateware to nmigen? i would be interested

nice

i've never done a GSoC thing before though.

i guess first and second questions are does it apply to PhD students? and how does payment work?

I... guess it applies to PhD students (but not sure)

nice

and solve one of the challenge tasks in https://lab.apertus.org/T1228

into the repo

oh, i guess because of the master -> main switch

hm... I guess its because of some refactoring I did recently

should be good now, tpw_rules

alright i will look in more detail later. it does not look too difficult

<MEETING_TIME>

Bertl_oO? vup? anuejn? eppisai? anybody?

Its meeting time already?

I'll be attending..

Hi!

That's it.

Cscar, do you want report?

here now

We did a pre-calculation for our tax year 2020; It ends this month

We're OK, but if possible, extra expences are welcome to avoid paying taxes on money that we'd rather spend ;)

thanks

BAndiT1983: any news from your side?

was mainly guiding students regarding axiom remote development, but was also continuing to investigate same70, USB is almost there, just have to find the cause for the reboot on access, similar thing happened on the pic32mz already

interesting, many thanks!

shohei and I did some CAD review and design improvements for a part in the AXIOM Beta compact that holds together the PCBs

on the hardware production front we are still waiting for some components to arrive

one we already had in stock and one is on its way from china with DHL express, left today

a Beta dev kit was assembled and shipped out to a customer in Poland today, I assume bertl will also talk about that

thats it from my side

unless anuejn has something to report :)

okay, then

which also required a ZIF frontend and because the process so far was quite tedious, I spent some time on improving this

and before we were happy when one out of three attempts worked as intended

I also improved the ZIF pin testing approach and managed to cut the required probes in half while increasing the precision there as well

and it seems to work quite nicely

there was no problem to get it to digitize the Beta output and my preliminary tests show that we can digitize raw RGB without any compression or alteration

right, was about to ask about the "altering" verification

about the frame rate, I'm not completely sure, as it currently (with a normal viewer) maxes out at slightly above 50 FPS

will know more on that next week I guess

the alteration verification test will be mimg sample input image supplied from the camera (maybe even 10 bit?) and recorded by the device and then checked for differences?

then digitize it an verify correctness by checksumming

there might also be some hope for higher/custom resolutions

very nice

Video Engine

Deinterlace

Color Adjustment

Up/down Conversion

Mirror and Flip

well, actually it wasn't that hard to configure

great to hear, how is the linux support?

and the setup can be stored in the device, so no need to run it over and over again

on the capture side, Linux support is out of the box

fingers crossed!

not from my side, as I already stated

<MEETING CONCLUDED> thanks everyone!

thanks everyone!

Cscar: see PM

great!

which essentially meant writing the vhdl code for the register... using Flip Flops to register its value so that the output isin't affected during reconfiguration... among other things..

and I wrote the vhdl code for the register... can be found here:

work is still in progress.. somehow this doesn't work yet and is giving some issues... i'm trying to fix it with Bertl

many thanks for the update!

off to bed, good night

hello pani! please go ahead!

nope, the sensor data is directly sent to the zynq

the MachXO2 basically work as confugurable GPIO extenders

yes, the packet based implementation did take care of the higher layer protocol, but unfortunately ignored the phy level

yep, input and output pins for various purposes

but also some 'simple' GPIOs on shields and plugins

Ah so freeing up pins on the Zynq to deal directly with the sensor data, is that correct?

pin count on the zynq is quite limited and we only reserved the bare minimum for low speed I/O

So this one is expected to be an optimized PHY extension for the previous GSOC

Okay

Is there a current bandwidth for reference?

"

nope, this is just an estimate from 'knowing' the hardware

the tricky part here is that we have an asymmetric setup on the two routing frabrics (MachXO2s)

in addition, both share a single ended clock line with the zynq

the schematics :)

ah, well, we know that the MachXO2 can do LVDS at reasonably high speeds