Current Server Time: 03:47 (Central Europe)

#apertus IRC Channel Logs

2021/03/29

Timezone: UTC


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