Current Server Time: 02:14 (Central Europe)

#apertus IRC Channel Logs

2021/03/29

Timezone: UTC


03:06
vnksnkr
joined the channel
03:22
BAndiT1983
changed nick to: BAndiT1983|away
05:03
Bertl
off to bed now ... have a good one everyone!
05:03
Bertl
changed nick to: Bertl_zZ
05:11
BAndiT1983|away
changed nick to: BAndiT1983
05:31
vnksnkr
left the channel
05:36
vnksnkr
joined the channel
06:01
vnksnkr
left the channel
06:31
vedant16[m]
vnksnkr: use a formatter (prettier on vscode)
06:48
mumptai
joined the channel
06:53
lambamansha
joined the channel
06:58
BAndiT1983
vedant16[m]: hi, there is also a dedicated VHDL formatter in vscode available
07:43
vnksnkr
joined the channel
08:01
vnksnkr
I guess I should start using vscode then :D
08:10
BAndiT1983
what are you using at the moment?
08:17
vnksnkr
vim
08:27
vedant16[m]
uffff
08:27
vedant16[m]
<BAndiT1983 "vedant16: hi, there is also a de"> ohh, yup there is
08:27
BAndiT1983
Bertls favourite ;)
08:28
vedant16[m]
learning vim is a waste of time as it takes a long time to learnð
08:28
vedant16[m]
you can achieve the same functionality with vscode lol
08:28
BAndiT1983
vedant16[m]: now you will be punished by Bertl
08:28
BAndiT1983
there are actually formatters for VHDL and vim also
08:29
vedant16[m]
yes there are
08:29
vnksnkr
i never really had a preference..have only tried out vim and sublime
08:29
BAndiT1983
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.
08:33
vnksnkr
I did like like sublime which was the editor I was using for my python projects but for VHDL and C I never really thought of going going beyond Vim
08:33
vnksnkr
now I get why vscode is suggested ð¬ï¸
08:35
BAndiT1983
you can probably do same things in sublime, was using atom.io several years ago, but it was fairly slow back then
08:35
BAndiT1983
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
09:19
vedant16[m]
sublime atom is good but vscode has grater plugin integration.
09:19
vedant16[m]
and a huge dev community
09:29
lambamansha
left the channel
09:32
RexOrCine
left the channel
09:32
RexOrCine
joined the channel
09:47
nerdynikhil
joined the channel
10:30
nerdynikhil
left the channel
10:50
Nishant95
joined the channel
10:54
Nishant95
Hi this is Nishant here, Is this the VHDL codebase for the AXIOM Beta? https://github.com/apertus-open-source-cinema/axiom-firmware/tree/master/peripherals/soc_main)
10:56
BAndiT1983
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
11:10
Bertl_zZ
changed nick to: Bertl
11:10
Bertl
morning folks!
11:13
BAndiT1983
hi
11:27
vnksnkr
morning !
11:29
vnksnkr
I was hoping to work on the Remote Test System ? ..would like to know more about the shield that has already been designed
11:36
Bertl
which task?
11:37
vnksnkr
T1233
11:50
Bertl
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
11:51
Bertl
it is basically a number of mosfets (electronic switches) which can actuate the various buttons and encoders on the remote
11:52
Bertl
it attaches via FFC (flexible flat cables) to a 'breakout board' which is attached to the actual remote
12:06
Bertl
let me know if you need anything else
12:17
Nishant95
left the channel
13:20
mumptai
left the channel
13:59
futarisIRCcloud
joined the channel
13:59
Bertl
off for now ... bbl
13:59
Bertl
changed nick to: Bertl_oO
14:01
tpw_rules
joined the channel
14:01
tpw_rules
hello. i just saw anuejn's message in #nmigen about porting some apertus gateware to nmigen? i would be interested
14:02
anuejn
hey :)
14:02
anuejn
nice
14:03
anuejn
are you familiar with gsoc?
14:03
tpw_rules
i've never done a GSoC thing before though.
14:03
tpw_rules
no :)
14:04
tpw_rules
i guess first and second questions are does it apply to PhD students? and how does payment work?
14:04
anuejn
ok so best thing would be to read up on that (like formal requirements & such)
14:04
anuejn
I... guess it applies to PhD students (but not sure)
14:05
tpw_rules
i found the gsoc faq and it says yes
14:05
anuejn
nice
14:07
anuejn
next thing would probably to familiarize yourself a bit with our existing nMigen codebase
14:07
anuejn
and solve one of the challenge tasks in https://lab.apertus.org/T1228
14:07
tpw_rules
FTR the links on that page are broken
14:07
tpw_rules
into the repo
14:08
anuejn
oh sorry
14:08
tpw_rules
oh, i guess because of the master -> main switch
14:09
tpw_rules
hm even then it doesn't work.
14:09
anuejn
hm... I guess its because of some refactoring I did recently
14:09
anuejn
let me fix that real quick
14:16
anuejn
should be good now, tpw_rules
14:16
anuejn
thanks for the report
14:20
tpw_rules
alright i will look in more detail later. it does not look too difficult
14:23
anuejn
nice :)
16:00
BAndiT1983
<MEETING_TIME>
16:00
BAndiT1983
who is attending today?
16:01
BAndiT1983
Bertl_oO? vup? anuejn? eppisai? anybody?
16:01
eppisai
Hi!
16:01
eppisai
Its meeting time already?
16:02
BAndiT1983
18:00 CET here, so usual meeting time
16:02
eppisai
I'll be attending..
16:02
BAndiT1983
as you're the first one, please go on with your report
16:05
Cscar
joined the channel
16:05
eppisai
So, last week, I worked on cmake file, tried reading work done by Andrej on cmake of opencine, cause it crossplatform, and very well written. And worked on my pull request. My approch was wrong, so BAndiT1983 helped me with it.
16:05
Cscar
Hi!
16:05
BAndiT1983
hi Cscar
16:05
Bertl_oO
changed nick to: Bertl
16:05
Bertl
is here ...
16:05
eppisai
That's it.
16:06
BAndiT1983
just as clarification, BAndiT1983 = Andrej
16:06
BAndiT1983
Cscar, do you want report?
16:06
BAndiT1983
*to report
16:08
se6ast1an
here now
16:08
Cscar
I only have company stuff to report.
16:09
Cscar
We did a pre-calculation for our tax year 2020; It ends this month
16:09
Cscar
So not december.
16:10
Cscar
We're OK, but if possible, extra expences are welcome to avoid paying taxes on money that we'd rather spend ;)
16:11
Cscar
That's about it unless someone has a question about it?
16:12
se6ast1an
thanks
16:12
se6ast1an
bluez & metal_dent[m] are you available?
16:13
se6ast1an
BAndiT1983: any news from your side?
16:14
BAndiT1983
just a bit, but nevertheless
16:15
BAndiT1983
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
16:15
BAndiT1983
that would be it
16:15
se6ast1an
interesting, many thanks!
16:15
se6ast1an
quick updates from me:
16:16
se6ast1an
shohei and I did some CAD review and design improvements for a part in the AXIOM Beta compact that holds together the PCBs
16:16
se6ast1an
work will continue but is progressing nicely
16:17
se6ast1an
on the hardware production front we are still waiting for some components to arrive
16:17
se6ast1an
I took over sourcing of 2 components that Tele did not get from any "normal" distributor anymore
16:17
se6ast1an
one we already had in stock and one is on its way from china with DHL express, left today
16:18
se6ast1an
hope I can hand those over on friday
16:18
se6ast1an
a Beta dev kit was assembled and shipped out to a customer in Poland today, I assume bertl will also talk about that
16:18
anuejn
is here
16:19
se6ast1an
thats it from my side
16:20
se6ast1an
Bertl: you closing words?
16:20
Bertl
unless anuejn has something to report :)
16:22
se6ast1an
anuejn doesn't
16:22
Bertl
okay, then
16:23
Bertl
last week we were, as se6ast1an already hinted, mostly woring on finishing _another_ manually assembled Beta
16:24
Bertl
which also required a ZIF frontend and because the process so far was quite tedious, I spent some time on improving this
16:25
Bertl
the new setup now has way better yield, the ZIF reflow process is problematic in several ways (temperature, planarity, via-in-pad, alignment, ...)
16:25
Bertl
and before we were happy when one out of three attempts worked as intended
16:26
Bertl
now we achieved three out of five and one of the failed attempts only has a single missing connection
16:27
Bertl
I also improved the ZIF pin testing approach and managed to cut the required probes in half while increasing the precision there as well
16:27
Bertl
finally I got some time to test out the new HDMI digitizer from Magewell we received recently
16:28
Bertl
and it seems to work quite nicely
16:28
se6ast1an
excellent
16:28
Bertl
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
16:29
Bertl
(currently working on a test setup for this)
16:29
se6ast1an
right, was about to ask about the "altering" verification
16:29
se6ast1an
sounds very good
16:29
Bertl
about the frame rate, I'm not completely sure, as it currently (with a normal viewer) maxes out at slightly above 50 FPS
16:30
Bertl
but this might be a problem with the current USB 3 setup as well as a software issue
16:30
Bertl
will know more on that next week I guess
16:30
Bertl
that's it from my side for this week
16:30
se6ast1an
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?
16:31
Bertl
kind of, I'm currently planning to generate a PRNG image in memory
16:31
Bertl
then digitize it an verify correctness by checksumming
16:32
Bertl
first on an 8-bit basis and later on the full 12-bit setup
16:32
Bertl
there might also be some hope for higher/custom resolutions
16:32
Bertl
the device is quite flexible and configurable
16:33
se6ast1an
very nice
16:33
se6ast1an
the website says it does:
16:33
se6ast1an
Video Engine
16:33
se6ast1an
8-bit video processing
16:33
se6ast1an
Deinterlace
16:33
se6ast1an
Cropping
16:33
se6ast1an
Color Adjustment
16:33
se6ast1an
Color Space Conversion
16:33
se6ast1an
Up/down Conversion
16:33
se6ast1an
Aspect Ratio Conversion
16:33
se6ast1an
Mirror and Flip
16:33
se6ast1an
so it might require some fiddling to turn all these off
16:33
Bertl
well, actually it wasn't that hard to configure
16:33
se6ast1an
especially the color conversion/adjustment?
16:34
se6ast1an
great to hear, how is the linux support?
16:34
Bertl
there is a tool for this, which works on all major platforms (including Linux)
16:34
Bertl
and the setup can be stored in the device, so no need to run it over and over again
16:35
se6ast1an
sounds very promisng indeed!
16:35
Bertl
on the capture side, Linux support is out of the box
16:35
Bertl
i.e. no special capture tool required
16:36
se6ast1an
fingers crossed!
16:37
se6ast1an
anything else?
16:37
Bertl
not from my side, as I already stated
16:38
se6ast1an
anyone else then ? :)
16:40
se6ast1an
<MEETING CONCLUDED> thanks everyone!
16:40
eppisai
Thanks!
16:40
Bertl
thanks everyone!
16:41
Cscar
Thanks!
16:41
se6ast1an
Cscar: see PM
16:52
bluez
Hello everyone! Sry I couldn't make it in time for the meeting... so finally after a few weeks of leave for my exams I made some progress last week.. here are some updates from me:
16:55
se6ast1an
great!
16:56
bluez
after the partial dynamic reconfiguration working correctly, and after I was able to update an LUT at an arbitrary location, my next task was to implement a test 32-bit register with a bunch of LUTs with a proper "structure"
16:58
bluez
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..
16:59
bluez
I was able to write a script to access certain debug registers in the zynq for ease of debugging.. where Bertl helped
16:59
bluez
and I wrote the vhdl code for the register... can be found here:
16:59
bluez
https://github.com/Swaraj1998/reg-test
17:00
bluez
work is still in progress.. somehow this doesn't work yet and is giving some issues... i'm trying to fix it with Bertl
17:01
bluez
Thats it from me for now :)
17:05
se6ast1an
many thanks for the update!
17:07
bluez
thanks for moderating! :)
17:19
mumptai_
joined the channel
17:19
mumptai
joined the channel
17:19
mumptai
left the channel
18:12
Nishant95
joined the channel
18:18
Nishant95
left the channel
18:39
vnksnkr
left the channel
18:49
comradekingu
left the channel
18:58
mumptai_
left the channel
18:58
mumptai
joined the channel
19:39
kbeckmann
left the channel
19:45
kbeckmann
joined the channel
21:06
mumptai
left the channel
21:24
se6ast1an
off to bed, good night
21:26
eppisai
gn :)
22:04
pani
joined the channel
22:16
pani
left the channel
22:19
BAndiT1983
changed nick to: BAndiT1983|away
22:27
Cscar
left the channel
23:47
pani
joined the channel
23:49
pani
Hi I am interested in the Bidirectional FPGA communication project, and am still going through documentation and code to come up with a proposal. I have a few questions to ask to clarify my broad understanding
23:50
Bertl
hello pani! please go ahead!
23:51
pani
So in the BETA setup, the Mach XO2s role is to take in the data from the image sensors and send it to the Zynq for image processing is that the correct model ?
23:51
Bertl
nope, the sensor data is directly sent to the zynq
23:51
pani
Also previous GSOC there was a packet based implementation of Bidirectional
23:51
Bertl
the MachXO2 basically work as confugurable GPIO extenders
23:52
pani
Is the expected project an improvement over the previous one or a replacement?
23:52
Bertl
yes, the packet based implementation did take care of the higher layer protocol, but unfortunately ignored the phy level
23:52
pani
So what does the GPIO extenders do basically more input pins for the Zynq?
23:52
Bertl
yep, input and output pins for various purposes
23:53
Bertl
mostly I2C and SPI for shields, center solder on, plugins etc
23:53
Bertl
but also some 'simple' GPIOs on shields and plugins
23:53
Bertl
(i.e. low speed IOs)
23:53
pani
Ah so freeing up pins on the Zynq to deal directly with the sensor data, is that correct?
23:53
Bertl
yep, that's it
23:54
Bertl
pin count on the zynq is quite limited and we only reserved the bare minimum for low speed I/O
23:54
Bertl
sensor input as well as plugin and shield output (high-speed) is handled by the zynq directly
23:54
pani
So this one is expected to be an optimized PHY extension for the previous GSOC
23:55
Bertl
ideally yes, but the main focus is here on the phy layer
23:55
pani
Okay
23:55
Bertl
so it doesn't really need to 'work' with the higher layers
23:55
pani
Is there a current bandwidth for reference?
23:55
pani
"Optimize communication with encoding and SERDES, target bandwidth is 500Mbit/s.
23:55
pani
"
23:56
pani
In contet to this
23:56
Bertl
nope, this is just an estimate from 'knowing' the hardware
23:56
pani
Ok
23:56
Bertl
the tricky part here is that we have an asymmetric setup on the two routing frabrics (MachXO2s)
23:56
Bertl
one has two LVDS pairs connected, the other only a single LVDS pair
23:57
Bertl
in addition, both share a single ended clock line with the zynq
23:57
pani
Okay is there any part of the documentation that explains this?
23:57
Bertl
the schematics :)
23:58
pani
I meant more on the reasoning, but I will check the schematics too
23:58
Bertl
ah, well, we know that the MachXO2 can do LVDS at reasonably high speeds
23:58
Bertl
we also know that the Zynq can do LVDS at above 1Gigabit