Current Server Time: 20:57 (Central Europe)

#apertus IRC Channel Logs

2020/03/29

Timezone: UTC


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