Current Server Time: 18:39 (Central Europe)

#apertus IRC Channel Logs

2019/04/04

Timezone: UTC


00:15
futarisIRCcloud
joined the channel
00:18
intrac
left the channel
00:20
intrac
joined the channel
00:24
intrac
left the channel
00:25
intrac
joined the channel
03:17
GC
joined the channel
04:08
GC
left the channel
05:21
BAndiT1983|away
changed nick to: BAndiT1983
05:40
aSobhy
left the channel
05:41
BAndiT1983
changed nick to: BAndiT1983|away
05:55
GC
joined the channel
06:26
Bertl_zZ
changed nick to: Bertl
06:26
Bertl
morning folks!
06:41
GC
morning! Its Gabe...
06:45
dcz_
joined the channel
06:49
Bertl
hey GC! you made it!
06:52
GC
Yeah I did! I actually need to head to bed. I flashed the new firmware and booted it up. Ran the axiom-start.sh script and trying to check the HDMI feed but it isn't displaying right on this particular monitor...
06:57
Bertl
did it work before?
06:58
Bertl
if so, compare the setup scripts with your previous settings
06:58
GC
I haven't tested it with this monitor before. It's a new monitor
06:58
Bertl
I'm on my way to the hub now, but we can chat after you had some sleep ...
06:59
GC
Sounds good. Talk to you later.
06:59
Bertl
cya
06:59
GC
left the channel
06:59
Bertl
changed nick to: Bertl_oO
07:08
illwieckz
left the channel
07:20
illwieckz
joined the channel
07:22
se6astian|away
changed nick to: se6astian
07:23
se6astian
good day
07:46
sebix
joined the channel
07:48
azfoo
joined the channel
07:48
azfoo
Hi everyone! Can I get some information anout FPGA based projects?
07:51
azfoo
left the channel
08:05
RexOrCine|away
changed nick to: RexOrCine
08:35
RexOrCine
changed nick to: RexOrCine|away
08:43
RexOrCine|away
changed nick to: RexOrCine
09:24
aSobhy
joined the channel
09:32
apurvanandan[m]
Hi Bertl, yesterday night I fixed a small bug, now it is working normal with keep hierarchy option
09:32
apurvanandan[m]
I have attached the new VCD fiie. You can take a look :)
09:43
illwieckz
left the channel
09:44
apurvanandan[m]
Also what is the priority of T728 Image sensor simulation
09:45
apurvanandan[m]
Yesterday you did't mention that.
09:56
RexOrCine
changed nick to: RexOrCine|away
10:02
shivamgoyal
joined the channel
10:52
apurvanandan[m]
Could anyone tell that in our CV we going to submit, do we need to mention only the points relevant to your organisation?
10:55
aSobhy
Hello Bertl :)
10:55
aSobhy
in T731 "Bidirectional Packet Protocol"
10:55
aSobhy
what is meant by "support various bus protocols on the Lattice FPGAs (I2C, SPI, GPIO ...)" I didn't catch how we can switch between the protocols and who will control which protocol to communicate with ?
11:04
vup2
the lattice FPGAs are used as io expanders
11:06
vup2
so the lattice FPGAs would implement things like I2C, SPI or GPIO
11:06
vup2
which would then be controlled / readout over the packet protocol
11:12
shivamgoyal
left the channel
11:28
aSobhy
as I understood: the ZYNQ will communicate with the two MachXO2 with a fixed protocol over the LVDS and in the header of that packet it will tell the MachXO2 which protocol ( I2C, SPI, ...) to communicate with the sensors ?
11:28
aSobhy
am I right ?
11:30
vup2
yes something like that
11:30
danieel
or you can just transfer register access and interrupts :)
11:30
vup2
did you read the comments below the task? there is some more information you can find there
11:32
vup2
danieel: well that is just terminology imho: when mapping it something like register access the address you access effectively serves as the header...
11:33
danieel
vup2: nope, it is transparent to any protocol then, instead of making a more semantic protocol aware transport
11:34
vup2
nothing in what aSobhy said indicates to anything protocol specific in the transport
11:36
vup2
but i agree, making the transport independent of the actual protocol used at the machxo2 side has certain benefits
11:36
danieel
the comments on the task indicate a preference towards protocol aware protocol :)
11:37
vup2
sure
11:38
vup2
you probably have to find a balance between the two
11:39
danieel
its hard to do when the people do not know what it shall be used for exactly.. so I miss a more precise definition, and maybe the architecture shall be set by who requested such thing to be made
11:40
danieel
in my experience, leaving this to the implementor, the result will be hard to maintain, when they just dont have the whole picture
11:40
vup2
well there are some more specific examples in the comments
11:41
danieel
yes i see now
11:42
vup2
but yes they should probably be added to the task description
11:42
vup2
also Bertl might be able to give more examples
11:44
vup2
but the general idea is, that the the `routing fpga's` act as io expanders mainly for the plugin modules and the shields
11:45
vup2
the plugin modules are exchangeable modules that contain for example a hdmi connector / the ic's to generate a hdmi signal, a usb3 connection, a sata connection, a sdi connection
11:46
vup2
there are direct connections between the plugin modules and the zynq for high speed data transfer (for example for the hdmi plugin module: the actual video signal)
11:47
vup2
but there are also `low speed` connections between the plugin modules and the routing fpga's
11:48
vup2
they are for example used to communicate with the hdmi ic on the hdmi plugin module over i2c to set various parameters
11:48
vup2
or to program the fpga on the usb3 module
11:49
vup2
and similar tasks
11:49
vup2
these are all somewhat timing insensitive tasks
11:50
vup2
but there could for example be a plugin module that is connected to a external shutter
11:50
vup2
which would then need a low latency way to control the shutter
11:50
vup2
hope that helps a bit to see how this ties in into the whole system
11:52
RexOrCine|away
changed nick to: RexOrCine
12:24
futarisIRCcloud
left the channel
13:22
anuejn
https://twitter.com/ApertusOSCinema/status/1112710029562527744
13:22
anuejn
where are they from?
13:27
se6astian
camvate and lanparte (other brand not in picture)
13:27
se6astian
ah no both are in the picture
13:27
se6astian
left lanparte, right camvate
13:42
Bertl_oO
azfoo: check out the GSoC 2019 workboard, specifically the first column: https://lab.apertus.org/project/view/20/
13:42
Bertl_oO
apurvanandan[m]: excellent! will check it soon ...
13:44
Bertl_oO
aSobhy: the challenge with the routing fabric protocol is that it needs to be generic or flexible enough to handle various plugins or shields or even CSOs but also able to generate deterministic events for things like shutter or exposure
14:57
dcz_
left the channel
14:57
dcz_
joined the channel
16:01
BAndiT1983|away
changed nick to: BAndiT1983
16:03
aSobhy
Yeah i began to catch :)
16:05
aSobhy
should i use an existing ip's for I2C, SPI,... or write it from scratch ?
16:07
sebix
left the channel
16:08
aSobhy
and on the machXo2 what if their a slower device than the machXO2 should the machXO2 slower itself to match its speed ?
16:23
BAndiT1983
changed nick to: BAndiT1983|away
16:38
se6astian
leaving the axiom office now
16:39
se6astian
changed nick to: se6astian|away
16:48
RexOrCine
changed nick to: RexOrCine|away
17:10
illwieckz
joined the channel
17:24
apurvanandan[m]
Bertl, In my implementation of task I have kept the connection between the serializer and deserializer inside the fabric only. Does violate the task guideline?
17:25
apurvanandan[m]
Should the link be sent to IOBUF?
18:23
BAndiT1983|away
changed nick to: BAndiT1983
18:24
niemand
joined the channel
18:24
Dev_
joined the channel
18:28
Dev_
Hey BAndiT1983 , In Context to "add dokany to fuse", For proting the fuse based frameserver to windows we will be using dokany, right
18:28
Dev_
But OC dosen't support in windows , so how we will test it
18:29
Dev_
?
18:33
BAndiT1983
OC supports windows
18:33
BAndiT1983
OC even supports mac, tested it long time ago in a virtualbox
18:38
Dev_
I should try build it into windows, i will see this ,thanks
18:40
se6astian|away
changed nick to: se6astian
18:41
Dev_
left the channel
19:03
intrac
left the channel
19:21
intrac
joined the channel
19:28
nafizzz
joined the channel
19:29
nafizzz
Hi! I submitted a draft proposal on the GSoC submit page along with the link to my CV and challenge task inside. Would be great if i got some feedback on it!
19:29
nafizzz
left the channel
20:24
se6astian
changed nick to: se6astian|away
20:38
BAndiT1983
changed nick to: BAndiT1983|away
20:40
niemand
left the channel
20:49
Bertl_oO
aSobhy: both is fine, the important part is to make it obvious which parts are incorporated (by crediting the sources in the code) and what you've added
20:50
Bertl_oO
also note that the coding style should be uniform and the incorporated IP needs to be FOSS
20:51
Bertl_oO
hint: incorporating existing IP properly is not as trivial as it may look at first glance :)
20:51
Bertl_oO
apurvanandan[m]: it doesn't 'violate' the task guideline, but it would be more realistic (and thus show more potential problems) if you do an 'external' loopback
20:53
AntGeorge
joined the channel
20:53
AntGeorge
Hello
20:53
Bertl_oO
Hello AntGeorge!
20:54
AntGeorge
Can i ask a question here about T1140 C Challenge?
20:54
Bertl_oO
sure
20:55
AntGeorge
Can i use threads to minimize the execution time?
20:55
AntGeorge
Because armv7 has 2 cores
20:55
Bertl_oO
yes, you may
20:56
AntGeorge
and one more question...
20:56
Bertl_oO
go ahead
20:57
AntGeorge
I am checking my code with checkpatch to find if is follow the linux kernel coding style
20:57
AntGeorge
but some lines is more than 80 chars
20:57
AntGeorge
should i split it?
20:58
Bertl_oO
yep
20:58
AntGeorge
ok thanks
20:58
Bertl_oO
no problem!
21:20
AntGeorge
left the channel
21:28
comradekingu
left the channel
21:41
dcz_
left the channel
22:35
aSobhy
sorry Bertl : "and on the machXo2 what if their a slower device than the machXO2 should the machXO2 slower itself to match its speed ?"
22:37
Bertl_oO
as mentioned, there are a number of different data pathes between the routing fabrics (MachXO2) and 'other' parts of the AXIOM Beta
22:38
Bertl_oO
and depending on the type the data can be categorized somewhere between 'best efford' and 'real time'
22:38
Bertl_oO
for example, the RFs (routing fabrics) connect to the CSO (center solder on area)
22:39
Bertl_oO
this is the perfect place to put IMUs (Inertial Measurement Units) to figure out the camera orientation or movement/turning/tilting
22:40
Bertl_oO
this information is transferred either via SPI or via I2C (or maybe both if different sensors are used)
22:40
Bertl_oO
when you are 'just' interested in camera orientation, it might be enough to get a few readings per second
22:41
Bertl_oO
if you want to do some kind of image stabilization or 3D tracking, you want to get a few hundred measurements per second and they require very acurate time stamps
22:49
aSobhy
Ok thats more clear :)
22:52
aSobhy
now for the ZYNQ I didn't understand what danieel means "or you can just transfer register access and interrupts "
22:53
Bertl_oO
well, you have to take all the comments you get from the community with a grain of salt ... it is always easy to drop a comment, but it is certainly one approach
22:53
Bertl_oO
PCIe for example goes that route quite successfully
22:54
Bertl_oO
some kind of packetization is required to separate the different 'channels' for different protocols
22:55
Bertl_oO
this can happen in one 'very' generic type or in several layers depending on the priority
22:56
Bertl_oO
very similar to various image formats and compression algorithms there are advantages and disadvantages in each approach
23:04
aSobhy
Okay :)
23:05
aSobhy
is it possible to have a look on an old document with the specs required for that project from the previous years ?!
23:07
futarisIRCcloud
joined the channel
23:08
Bertl_oO
you can check the history for each task, that is all what we have as far as I know
23:09
Bertl_oO
there have been some discussions on the IRC channel as well and you should find those in the logs
23:14
aSobhy
thanks Bertl :)
23:15
Bertl_oO
you're welcome!
23:16
aSobhy
I'll write the initial proposal and send you to check it :)
23:18
Bertl_oO
sure, drop me a note when it is ready for checking
23:19
aSobhy
yeah ASAP :)
23:28
apurvanandan[m]
Bertl did you check my task?
23:29
Bertl_oO
I'm on it
23:29
apurvanandan[m]
Yes thanks
23:40
danieel
Bertl_oO: an imu over spi or i2c does not guarantee much synchronicity nor timestamping. A good imu has a fifo... yet I did not found one that can be fed with a clock yet :/
23:43
Bertl_oO
correct, but if done properly, the necessary timing information can be added by the FPGAs
23:43
danieel
a good choice should be a fixed packet length - single register operation, with reserved fields for realtime signals (being that timing critical gpio, or interrupts)
23:44
danieel
the PCIe allows pipelining/multithreading, which is quite an overkill, maybe that aspect should be specified - that how many concurrent operations shall be open at one time
23:48
Bertl_oO
fixed packet lengths simplify handling a lot but also increase latency for high priority stuff
23:49
danieel
high priority would be "immediate" values in each packet
23:49
Bertl_oO
for example a single real-time GPIO signal would require at least a packet with header to be transferred
23:49
Bertl_oO
while it might otherwise be handled with a few bits
23:51
Bertl_oO
but I'm not arguing for one over the other, I'm just pointing out that a good balance needs to be found
23:57
danieel
if the latency is the target, then a very simple bit vector synchronization, with difference and compression can be used :) it might need one sideband signal for training/syncing though
23:57
danieel
not sure if a junior comes up with such scheme :)