Current Server Time: 20:10 (Central Europe)

#apertus IRC Channel Logs

2020/03/29

Timezone: UTC


00:06
Spirit532
left the channel
00:06
Spirit532
joined the channel
03:22
illwieckz
left the channel
03:39
illwieckz
joined the channel
04:41
illwieckz
left the channel
04:50
ReginaRus
joined the channel
04:53
ReginaRus
left the channel
05:16
illwieckz
joined the channel
06:09
guest9624
joined the channel
06:10
guest9624
changed nick to: megora
06:47
megora
left the channel
08:18
BAndiT1983|away
changed nick to: BAndiT1983
08:23
Bertl_oO
off to bed now ... have a good one everyone!
08:23
Bertl_oO
changed nick to: Bertl_zZ
08:40
Shashwat
joined the channel
09:50
Shashwat
left the channel
10:41
Harry
joined the channel
11:45
Harry
left the channel
13:10
RexOrCine
joined the channel
13:57
omar31
joined the channel
14:15
Bertl_zZ
changed nick to: Bertl
14:15
Bertl
morning folks!
14:19
metal_dent[m]
Bertl: morning!
14:21
Bertl
the student application period is coming to an end (on March 31st) so make sure you got your application (including a CV and a challenge task) finished till then
14:22
shashwat
joined the channel
14:22
Bertl
because we got some more time this year to decide about those applications (an additional week) we (or at least I) will do it a little different this year
14:23
BAndiT1983
singing contest?
14:23
Bertl
kind of ...
14:23
metal_dent[m]
Different?
14:23
Bertl
during those three weeks, I will go through the submitted challenge tasks and applications and ask the students to make some changes or explain some details on the designs
14:24
Bertl
(to the code, not the application :)
14:24
BAndiT1983
ah, a re-call
14:25
Bertl
this will be somewhat similar to what we do during actual GSoC development, so it will give us all some idea what to expect
14:27
metal_dent[m]
Okay
14:28
preetimenghwani[
Hey bertl
14:28
preetimenghwani[
Please check my qualification task
14:28
bluez_[m]
Okay!
14:29
Bertl
not sure how the other mentors will spend their three weeks, but I consider this a good use for the time and we can already focus on the actual task as well
14:30
metal_dent[m]
Yeah, it's a great idea! (And I'm grateful it's not a singing contest ð)
14:30
bluez_[m]
> not sure how the other mentors will spend their three weeks, but I consider this a good use for the time and we can already focus on the actual task as well
14:30
bluez_[m]
Indeed.
14:30
Bertl
note that participation from the student is of course voluntary and I will make sure that you do not spend too much time coding on the challenge tasks
14:30
BAndiT1983
Bertl: good idea, as this year real task were selected for challenge, was reading through FAQs of other orgs and they do it similarly, like considering contributions from student and explicitly saying that people should know their way around, so less of spoon-feeding
14:31
bluez_[m]
> Yeah, it's a great idea! (And I'm grateful it's not a singing contest ð)
14:31
bluez_[m]
XD
14:31
BAndiT1983
and if the student is active and shows proper skills, then it's more like to be a success in the end
14:32
BAndiT1983
*likely
14:47
preetimenghwani[
Bertl: I had sent you the github link for the qualification task on DM please review itð
14:54
Bertl
yeah, looks okay to me, formatting needs some love
14:55
Bertl
indentation of 2 is a little extreme, would prefer 4 there, maximum line width should be below 80, you might want to fill in the automatic header, etc ...
14:57
preetimenghwani[
Oh okay will work on it!
14:57
preetimenghwani[
I have started drafting the proposal.
14:57
preetimenghwani[
Wanted to ask what all hardware will be provided ?
14:58
preetimenghwani[
For Pixel Remapper task
15:01
Bertl
we will provide a remote Axiom Beta for this purpose
15:04
preetimenghwani[
Okay
15:04
preetimenghwani[
For the task we are expected to optimize the remapper and include more features.Do we need to build separate remapper for all the modes?
15:09
preetimenghwani[
*remappers
15:19
bluez_[m]
Bertl: I was going through the schematics...I was wondering what do /4.5B, /4.2C etc postfixes in the labels mean....?
15:20
bluez_[m]
Also in "A_SCL"...what does "A_" stand for?
15:21
bluez_[m]
A_ i mean
15:35
Bertl
main board schematic?
15:39
anuejn
Bertl: did you get the camlink 4k with the stock firmware to capture video from the beta?
15:46
bluez_[m]
> main board schematic?
15:46
bluez_[m]
I found these pins at the PIC16s
15:49
bluez_[m]
These postfixes are in all other schematics not just main board
15:51
bluez_[m]
Oops sorry...its all part of the main board..yes
15:53
bluez_[m]
':D
15:54
Bertl
so, on the Axiom Beta Main Board, there are two MachXO2 which we refer to as routing fabrics
15:54
Bertl
the names there are RFW and RFE which stand for Routing Fabric West and East
15:55
Bertl
the direction West/East/North/South is to make it simpler to localice parts and functions
15:55
preetimenghwani[
Bertl: I was planning to optimize the remapper and extend it for 8bit, 10bit as well
15:56
Bertl
bluez_[m]: so for example the routing fabric west also connects to the west shield place which has a north and a south connector
15:56
preetimenghwani[
Is that what is expected?
15:56
Bertl
yes, that's what we are aiming for
15:57
Bertl
if you check the CMV12k datasheet, you will also see a bunch of configuration options like binning, subsampling, reduced interface, etc
15:57
Bertl
all those would be good to cover in the remapper
15:57
Dest123
joined the channel
15:58
Dest123
Hello
15:58
Bertl
anuejn: no, problem is we generate RGB and it only does YUV
15:58
Dest123
Hey bertl, would you check my qualification task
15:58
preetimenghwani[
Bertl: do we need build separate remappers for that?
15:58
Dest123
https://github.com/Destfolk/SPI-UART-Bidirectional-Bridge
15:58
Bertl
bluez_[m]: now for the postfixes, those are generated by Eagle to reference a page
15:59
Bertl
i.e. a /2.7B means page 2, grid 7B
16:00
Bertl
the A_ and B_ originate from the Power Board where we have two I2C busses (or more precisely one which can be switched)
16:01
Bertl
hope that clarifies the nomenclatures
16:01
bluez_[m]
> the names there are RFW and RFE which stand for Routing Fabric West and East
16:01
bluez_[m]
So thats what you meant by /dev/rfe before?! Gosh I should hv asked you dat... i hv been wondering what that device meant ':D
16:03
bluez_[m]
> hope that clarifies the nomenclatures
16:03
bluez_[m]
Yes it does...thanks!
16:03
Bertl
ah, yes, that was one example
16:04
preetimenghwani[
Bertl: Is it possible to include all these features in single remapping code?
16:05
Bertl
maybe, if so it would be great
16:05
bluez_[m]
> the A_ and B_ originate from the Power Board where we have two I2C busses (or more precisely one which can be switched)
16:05
bluez_[m]
Switched as in switched by our fpga's right?
16:06
Bertl
preetimenghwani[: but we can also use dynamic reconfiguration
16:06
Bertl
bluez_[m]: no, they are actually switched by an I2C mux or analog switch under I2C port expander control
16:06
Bertl
(depending on the power board version)
16:07
shashwat
left the channel
16:07
Bertl
the mux/analog switch can be controlled from the Zynq side
16:08
preetimenghwani[
Bertl What do you exactly mean by dynamic reconfiguration in this context?
16:08
Bertl
replacing parts of the FPGA config memory at runtime
16:09
Bertl
(there are different levels at which this can be done though)
16:09
preetimenghwani[
Oh that sounds interesting! Will read more about it!
16:10
bluez_[m]
> the mux/analog switch can be controlled from the Zynq side
16:10
bluez_[m]
Oh okay...but what's its purpose? The switching?
16:11
Bertl
the main reason for this solution was the shortage on GPIOs from the zynq side
16:11
preetimenghwani[
Bertl Actually i was planning to include binning and subsampling for future goals
16:12
preetimenghwani[
Now i was planning of extending it to 64sensel and 8bit, 10bit
16:13
preetimenghwani[
Now i guess i should include those also
16:14
preetimenghwani[
What are your suggestions for future work?
16:17
bluez_[m]
> the main reason for this solution was the shortage on GPIOs from the zynq side
16:17
bluez_[m]
I do get that... but can you once explain these i2c busses are switched between what? And why is it not the same as routing through the fpga's..? I clearly hv a knowledge gap here...just looking for right resources to u understand these....
16:27
ashok_singh[m]
left the channel
16:28
Bertl
preetimenghwani[: at least make sure to consider them
16:28
Dest123
Bertl, did you get a chance to see the code?
16:30
preetimenghwani[
Bertl: yes definitely will!
16:30
Bertl
bluez_[m]: there are two I2C busses controlled by the Zynq
16:30
Bertl
one is the main control bus for the power board
16:32
preetimenghwani[
Bertl: also I wanted to ask reading out from DDR memory is not the part of task right?
16:33
anuejn
Bertl: is that only negotiated via DCC?
16:34
anuejn
could i just make the camlink think, that the signal from the beta is YUV and then interpret it as RGB afterwards?
16:34
Bertl
bluez_[m]: which handles most GPIO expanders (power control), the instrumentation (current and voltage measurements), etc
16:34
IrinaMats
joined the channel
16:35
Bertl
anuejn: yes, in theory that should work, but we don't do DCC yet :)
16:35
Bertl
Dest123: url?
16:36
Dest123
https://github.com/Destfolk/SPI-UART-Bidirectional-Bridge
16:36
bluez_[m]
> one is the main control bus for the power board
16:36
bluez_[m]
And the other is for comm with pic16s?
16:37
anuejn
Bertl: so how does the camlink know, that we do RGB?
16:37
bluez_[m]
> bluez_: which handles most GPIO expanders (power control), the instrumentation (current and voltage measurements), etc
16:37
bluez_[m]
Ohh i see...
16:37
Bertl
anuejn: it doesn't it just doesn't capture anything (for whatever reason)
16:37
IrinaMats
left the channel
16:38
anuejn
ah ok
16:38
anuejn
so it is unclear, why it doesnt work?
16:44
Bertl
yup
16:45
Bertl
bluez_[m]: the second I2C bus is routed and switched (mux) on the power board, but not used
16:45
Bertl
the switched I2C busses (A and B) connect to the main board
16:45
Bertl
and there they are connected to the PICs
16:46
preetimenghwani[
Bertl: to test the remapper we need test stream does it imply we should test it using an image ?
16:46
Bertl
there are several options for this
16:47
anuejn
Bertl: thanks :)
16:49
bluez_[m]
Bertl: ok got it...thanks :)
16:51
Shashwat1
joined the channel
16:54
preetimenghwani[
Bertl: please provide some examples
16:56
Bertl
for simulation, it should be trivial to write a functional model for the sensor data stream
16:56
Bertl
for real world testing there are two options
16:57
Bertl
first, a sensor model (early stages) and then the actual sensor data on a Remote Beta
16:58
Shashwat1
left the channel
17:00
Dest123
Bertl: what do you think?
17:03
preetimenghwani[
Bertl:And Reading out data from DDR memory is not a part of task right?
17:03
Bertl
Dest123: checking now ...
17:04
Bertl
preetimenghwani[: no, for verification you can use the ARM cores (i.e. Linux)
17:04
preetimenghwani[
Okay thanks a lot Bertl :)
17:07
Bertl
i.e. to verify that the data is stored correctly
17:09
Shashwat
joined the channel
17:14
Bertl
Dest123: formatting is still really bad, especially indentation and spacing
17:17
Dest123
Bertl: Can you please specify what is wrong? I've spent so much time on that
17:18
BAndiT1983
indentation and spacing
17:18
Dest123
Can you provide an example of how it should be?
17:18
Bertl
Dest123: let me give you an example here:
17:19
Bertl
Bridge.vhd
17:19
Bertl
line 38 the typedef is at the same level as architecture
17:20
Bertl
line 80, generic map has two levels of indentation
17:20
Bertl
(same for the other 6 lines of course)
17:20
BAndiT1983
multiple empty lines
17:20
Bertl
line 128, if(rst has a missing space
17:21
Bertl
guess that should give you some ideas where to start cleaning up
17:29
Dest123
Ok
17:30
Dest123
can I fix those formats after the deadline so I can focus on the proposal?
17:43
Bertl
shouldn't take you long to fix them now .. about half an hour at most
17:50
Bertl
and it would be unfair to the other students who already spent some quality time on getting the formatting right :)
17:52
Bertl
personally I think proper code style and formatting are major quality aspect of programming
17:54
Dest123
I'm right on it
18:29
Davis
joined the channel
18:29
Davis
left the channel
18:53
Dest123
Bertl: I'm done, can you take a look?
18:53
Dest123
https://github.com/Destfolk/SPI-UART-Bidirectional-Bridge
18:54
Bertl
Bridge.vhd line 141
18:55
Bertl
line 156
18:55
Bertl
181 and 183
18:56
Bertl
209/213 (just a few examples)
18:59
Dest123
Fixed all but 181, 183
18:59
Dest123
I don't see the problem there
19:02
Bertl
spaces around the operator?
19:03
Bertl
note that those are only examples, i.e. please fix all simmilar issues as well :)
19:12
Dest123
Fixed them ð
19:27
Dest123
Any problems?
19:37
schmoggie1
joined the channel
19:39
schmoggie
left the channel
19:42
Bertl
Dest123: yes, still problems
19:44
Dest321
joined the channel
19:47
Dest123
left the channel
19:47
Dest321
left the channel
19:48
Dest123
joined the channel
19:48
Dest123
Which module?
19:50
Bertl
still in the Bridge.vhd
19:51
Dest123
Which line?
19:52
Bertl
make a guess
19:55
Dest123
Can't find it actually
19:57
Bertl
see, here is the problem with bad formatting
19:57
Bertl
look at line 197, there starts an if
19:58
Bertl
now line 200 looks like another if, but instead it is tied to the previous one
19:58
Bertl
and you can't tell because of the misleading indentation
20:02
Dest123
I see
20:02
Dest123
Give me 10 minutes to double check on the remaining modules
20:02
Bertl
please do so
20:10
Dest123
Everything supposed to be perfect now
20:13
Bertl
sure about that? checked all files?
20:15
Dest123
Yes, every problem you mentioned I fixed it and then went through the other modules to check it
20:17
Bertl
tb.vhd after line 46?
20:20
Dest123
Yes, the testbench is just modified
20:23
Bertl
everything else perfect now?
20:26
Dest123
Yes
20:27
Bertl
in UART Tx.vhd (btw, bad idea to use spaces in filenames)
20:28
Bertl
line 24/25 what might be the problem here?
20:30
Dest123
The space before the bracket?
20:30
BAndiT1983
changed nick to: BAndiT1983|away
20:31
Bertl
indeed, a matter of consistency
20:33
Bertl
like for example in Bridge.vhd line 37
20:36
Dest321
joined the channel
20:36
Dest123
left the channel
20:37
omar31
Hello Bertl!
20:37
omar31
Please take a look at task 3 here: https://github.com/omar-joudi/high_speed_link
20:38
omar31
Also, my code have timing violations which I am unable to resolve, Please give me a hint on how to deal with them
20:39
Dest321
left the channel
20:40
Dest123
joined the channel
20:46
Dest123
Fixed the inconsistencies, but can't see what is wrong with Bridge.vhd line 37
20:55
Bertl
well, besides that your 'ideal' is not really ideal here ...
20:55
Bertl
there is a mix of lower and upper case and no hint that those are states
20:56
Bertl
so when you encounter 'stop' or 'MOSI' how do you know that those are two states of the same signal?
20:56
Bertl
how do you know that those are states at all?
21:04
BAndiT1983|away
changed nick to: BAndiT1983
21:13
Dest123
Can I just fix those later? I really need to start working on the proposal and I need to ask you a few questions
21:15
Bertl
sure, I got the information I needed, tx
21:19
megora
joined the channel
21:24
Dest123
All the tasks are fairly interesting, but I thought about the pixel remapper at first as it is concerned with the memory, and currently I'm designing an SRAM so I thought that would help
21:24
Dest123
What's your take on that?
21:25
Bertl
SRAM is five lines of HDL, not sure how that relates to the remapper
21:26
Bertl
there has been little interest in T728 this year, so that might be a good choice
21:27
Bertl
(i.e. not much competition so far :)
21:35
Dest123
That's not the idea behind what I meant but no problem
21:35
Dest123
I'll take a look at T728
21:37
BAndiT1983
beggars can't be choosers ;)
21:43
Dest123
When I said designing SRAM I didn't mean writing HDL code, I'm working on transistor-gate level, and I know it is not that relevant, so I didn't divulge into the information. So that's why I said it is not the idea behind what I meant
21:43
Dest123
Sorry for confusion
21:45
Bertl
okay
22:00
omar31
left the channel
22:26
BAndiT1983
changed nick to: BAndiT1983|away
22:26
Dest123
I'm sorry but I have a question regarding T728
22:27
Bertl
sure, go ahead
22:27
Dest123
What's the difference between the bitstream test data and the fake still image data
22:28
Dest123
Shouldn't the emulator in both cases just generate the data?
22:28
Bertl
the main difference is the content and where it comes from
22:29
Bertl
bitstream test data is probably best generated by a PRNG or similar generator
22:30
Bertl
while the still image data requires some kind of meaningful image data, may it be a 'generated' test image or data from memory
22:32
Dest123
Same goes for the Fake video data?
22:35
Dest123
It can be generated or sent from memory directly?
22:46
Bertl
yup
22:47
Bertl
think of it as 'animated' still image
22:50
se6ast1an
off to bed
22:50
se6ast1an
good night
22:50
Bertl
nn
22:51
Dest123
Should the generated image be Black and white or RGB?
23:09
illwieckz
left the channel
23:15
Spirit532
left the channel
23:15
Spirit532
joined the channel
23:16
illwieckz
joined the channel
00:28
preetimenghwani[
Bertl: for 32sensel 12 bit we need to build a new remapper or work on improving the existing one?
00:29
preetimenghwani[
Also what could be the strategies to decrease gate count?
00:30
Bertl
I think the existing one is a good reference and should work in simulation and for comparison (gate count, performance, etc)
00:30
Bertl
but I wouldn't really use it as base for further improvements as it lacks the flexibility
00:31
Bertl
strategies to decrease gate count are probably in dynamic configuration and maybe in partial separation, i.e. using cycles efficiently
00:31
preetimenghwani[
Can the existing one be made more flexible?
00:32
Bertl
probably but a more generic design is likely to be easier and more flexible
00:35
preetimenghwani[
Okay
00:35
preetimenghwani[
And how exactly we need to write in DDR memory? Like a particular pixel should be written on which address ?
00:44
Dest123
Bertl: should the generated image be RGB?
00:45
Bertl
preetimenghwani[: DDR is written via AXI high performance interface basically as a stream of words
00:46
Bertl
Dest123: as the sensor is monochrome or RG/GB the image data should be also in this format
00:51
preetimenghwani[
It is mentioned that sensel and pixel are same is it so?
00:53
Dest123
Do the sensor registers store only the input data to be sent as as still image data and video data, or do they have another functionality?
00:55
Bertl
preetimenghwani[: we use sensel for sensor elements regardless of color and pixel for elements which can be in any color space (e.g. RGB, YUV, etc)
00:56
Bertl
Dest123: the sensor registers control how the sensor behaves and what data it sends
00:58
Dest123
Then where should the still image to be sent from memory is stored?
00:59
Bertl
both generated and stored image information has to be controlled by an additional side channel interface