apertus° IRC logs

2021/04/26

Timezone: UTC

06:27

Bertl

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

06:28

Bertl

changed nick to: Bertl_zZ

06:32

BAndiT1983|away

changed nick to: BAndiT1983

13:58

RexOrCine

left the channel

14:12

Bertl_zZ

changed nick to: Bertl

14:12

Bertl

morning folks!

14:14

BAndiT1983

changed nick to: BAndiT1983|away

14:33

RexOrCine

joined the channel

14:54

RexOrCine

left the channel

15:11

RexOrCine

joined the channel

15:31

RexOrCine

left the channel

15:38

RexOrCine

joined the channel

15:47

RexOrCine

left the channel

16:04

danieel

left the channel

16:05

danieel

joined the channel

16:05

RexOrCine

joined the channel

16:13

RexOrCine

left the channel

16:26

RexOrCine

joined the channel

16:43

vnksnkr

joined the channel

17:00

Bertl

meeting time!

17:00

vup

is here

17:00

Bertl

se6ast1an is busy today with a shooting (let's hope he will not get arrested ;)

17:00

Bertl

and he asked me to moderate the meeting for today, so please /msg me instead

17:02

Bertl

seems that it will be a very short meeting today ...

17:02

Bertl

vup: do you want to report anything?

17:03

vup

I have a small bit to report

17:03

Bertl

then please go right ahead ...

17:03

vup

I have started thinking about the (hopefully final :) redesign of the control daemon, which incorporates all the lessons learned from the last two (three) versions :)

17:04

vup

The general idea is to have much stricter types and work more with the rust type system, to avoid the confusing mess some parts of the current control daemon is

17:05

vup

furthermore I want to switch away from fuse to a (semi custom) self documenting tcp rpc protocol

17:05

Bertl

interesting ... care to elaborate?

17:06

vup

The way I currently envision implementing that should easily allow atleast rust, c++, go, python, typescript, java and c# clients, which covers most bases

17:06

vup

Bertl: sure

17:06

vup

I guess the main points are:

17:06

vup

1. Transport over tcp

17:08

vup

2. Each rpc function / object providing rpc functions is self documenting, meaning it generates (at runtime) a list of available functions and their argument types / return value. The Argument types / return types are serialized into a generic description, which allows clients to dynamically generate serializers and deserializers for the argument values / return values

17:09

vup

This dynamic generation of the serializer / deserializer will probably only be done in the more dynamic languages like python, while rust / c++ / go and the like will probably use a description of the rpc functions generated in a preprocessing step

17:10

vup

3. Serialization uses something called serde bincode, which already has implementations in all the languages mentioned above

17:10

vup

I think thats the main points of the RPC thingy

17:10

Bertl

nice

17:11

Bertl

well, looking forward to that ...

17:11

Bertl

anything else you would like to report?

17:11

vup

Especially the dynamic generation part will hopefully nicely integrate into some existing workflows which for example anuejn is using, where he generates a python driver code piece together with a bitstream / with the gateware

17:11

vup

Which brings me to the final point:

17:12

vup

We already played a bit with embedding a more dynamic "scripting" language into the control daemon and (I think atleast) all liked it, so going further than lua the plan is currently to allow embedding python

17:12

vup

There is a rough (rust centric) sketch of all of this here: https://codimd.niemo.de/Jv9uOS8pTeufU0_MwUsDjA?both

17:13

vup

(please don't mess with the document too much :)

17:13

vup

I think thats it, if anybody has some feedback or ideas for the control daemon, feel free to message me, I am looking forward to discuss

17:13

Bertl

excellent idea!

17:13

bluez

is late..

17:14

Bertl

bluez: you want to go next?

17:14

bluez

sure!

17:14

Bertl

then please do so ;)

17:14

anuejn

is late but here

17:15

bluez

so last week i was trying to put some constraints so that our logic only ends up in SLICEL and not in SLICEM(which contains dynamic component)

17:16

bluez

this way we can make sure that our (re)configuration frames do not also modify any dynamic resources

17:16

bluez

https://forums.xilinx.com/t5/Implementation/Map-logic-only-to-SLICEL-and-not-SLICEM-in-7-Series-FPGA/td-p/1234083#M30348

17:17

bluez

posted on the fourm and got the solution for that... we have to use plbocks here.. so I'll use that soon

17:18

bluez

other than this... i tried to generalize the structure of the design... so that we can create any type of register (boolean, constant etc.) of any width

17:18

bluez

https://github.com/Swaraj1998/reg-test

17:18

bluez

code can be found here ^

17:19

bluez

The build script also now writes out the register to slice mappings to a file

17:20

Bertl

excellent!

17:20

vup

bluez: nice, is there / are you planning to write some documenation about how this all works together in the end? I think anuejn and me would be very interested to port this to the nmigen gateware someday

17:20

bluez

so that we can identify which frames modify which register instance... for this I have used a custom attribute called REG_NAME...

17:21

bluez

vup: sure! I already have a midterm report that i sent to my univ.. I can send you that for now... but yea I will document it later as well I think

17:22

vup

bluez: sure feel free to send it to me when you get the chance

17:23

bluez

okay, I'll dm you in a while

17:23

Bertl

wouldn't mind to receive a copy either ;)

17:23

bluez

yes sure! ':D

17:23

bluez

i forgot to send it to you.. there wasn't much time and it was for official univ purposes anyway...

17:24

Bertl

yeah, no problem

17:24

bluez

so that's it from me!

17:24

Bertl

great work! thanks!

17:24

Bertl

anuejn: anything you want to report?

17:25

anuejn

yup

17:25

Bertl

then please go ahead

17:25

anuejn

I did some more work on the ui framework for the axiom recorder

17:26

anuejn

I can now handle input and render text and sliders :) (https://files.niemo.de/Peek%202021-04-20%2023-50.mp4)

17:26

anuejn

Currently I am in progress of improving performance / lowering cpu usage by caching layout & tesselation results

17:27

anuejn

Also I am thinking about other ways to improve performance and add how to add custom shaders for ui elements and clipping (needed for example for scroll containers)

17:28

anuejn

thats it from my side

17:28

Bertl

great! thanks!

17:29

Bertl

anybody else who wants to report something?

17:30

Bertl

from my side, there is not too much to report this week, I've been mostly busy with unrelated stuff as well as reviewing the GSoC student proposals

17:31

Bertl

but I found some more time to play with the magewell hdmi capture card, which is really a beautifull design

17:31

Bertl

http://vserver.13thfloor.at/Stuff/MAGEWELL/magewell.jpg

17:32

vup

Love to see the ECP5 :)

17:32

Bertl

besdies seeing a number of good old friends on the PCB there it is really nice to work with and it seems to do exactly what we want

17:32

Bertl

I tried to configure a number of custom modes and even succeeded to get a full sensor compatible format

17:33

Bertl

(2048x1536 pixel) of course at a lower than desired frame rate

17:33

Bertl

that said, I have a bunch of ideas to make generic data transfer via HDMI work there which might allow for an intermediate solution for the 'data transfer problem'

17:34

vup

nice

17:34

Bertl

i.e. something which works without writing new gateware or firmware for a cypress/FPGA solution

17:35

Bertl

of course, ultimately we want to drop the HDMI intermediate and replace it with a direct USB solution

17:35

Bertl

that's it from my side for this week