Current Server Time: 13:01 (Central Europe)

#apertus IRC Channel Logs

2017/03/12

Timezone: UTC


00:07
BAndiT1983
left the channel
00:50
slikdigit
left the channel
00:57
Rex0r
left the channel
00:58
RL
left the channel
00:58
Rex0r
joined the channel
00:58
slikdigit
joined the channel
00:58
RexOrCine
left the channel
00:59
RexOrCine
joined the channel
01:08
dimaursu16
joined the channel
01:08
dimaursu16
left the channel
01:08
dimaursu16
joined the channel
01:13
RexO
joined the channel
01:20
dimaursu16
left the channel
02:12
jucar
joined the channel
02:40
dimaursu16
joined the channel
02:50
dimaursu16
left the channel
03:19
dimaursu16
joined the channel
03:19
dimaursu16
left the channel
03:19
dimaursu16
joined the channel
03:27
slikdigit
left the channel
03:27
RexOrCine
left the channel
03:28
Guest4561
joined the channel
03:29
Guest4561
left the channel
04:00
dimaursu16
left the channel
04:44
Spirit532
left the channel
04:53
dimaursu16
joined the channel
04:53
dimaursu16
left the channel
04:53
dimaursu16
joined the channel
05:16
Bertl_zZ
changed nick to: Bertl
05:16
Bertl
morning folks!
05:37
dimaursu16
left the channel
06:01
jucar
left the channel
07:13
sagnikbasu
joined the channel
07:52
sagnikbasu
left the channel
08:10
danieel
Bertl: mornin.. what is that i2c hell above? I think you miss the drivers portion - which provide the required HAL (moving stuff between busses, changing chip models)
08:10
Guest45618
joined the channel
08:11
danieel
i2c is represented in linux only by bus devices
08:16
sagnikbasu
joined the channel
08:16
sagnikbasu
Hello, everyone.I am Sagnik, a potential GSOC candidate.I have introduced myself in the apertus's Google Group page.I am interested in the project "Real-time implementation of Sobel Filter in FPGA".First of all, I like to apologise for posting too late in the IRC channel.But I have looked into previous logs and is very much excited to discuss with the mentors regarding this project.Also . I would like to add that I have experien
08:17
Bertl
Hello sagnikbasu!
08:17
Bertl
first, note that IRC has a line limit, so your message was cut off after 'I have experien'
08:19
Bertl
There are already a number of GSoC applicants which are interested in the Sobel Filter (which is a good thing) so you might want to get in contact with them (probably best via the lab task)
08:19
sagnikbasu
oops! sorry ....As I was saying ,I would like to add that I have experience in computer vision/image processing as well as Reconfigurable System Design using FPGA.As of now, I am currently doing a project on image segmentation on Zedboard and Xilinx Vivado environment.
08:20
Bertl
there are a number of challenges to this task, especially from the bandwidth and resource side, so different approaches would make sense here
08:20
sagnikbasu
Sure.. I would do that..
08:22
Bertl
danieel: well, not sure we want that degree of HAL, it's probably more important to get the required metadata
08:22
sagnikbasu
I am studying some literature regarding efficient bandwidth and power management for signal processing tasks in FPGA
08:22
danieel
what for? e.g. the LM75 would appear in /sys/class/hwmon, or /sys/class/thermal
08:22
Bertl
sagnikbasu: so the basic concept of applying a kernel is probably nothing new to you :)
08:23
Bertl
danieel: yes, but we would like to know stuff like: the location of the sensor, the initial accuracy, the resolution, etc
08:24
Bertl
sagnikbasu: also, efficient decimation could be a very interesting topic here
08:25
Bertl
we are basically getting a huge amount of data (4k, 12bit @ 60+ FPS) from the sensor
08:25
Bertl
and we are not really interested in a sobel of each and every sensel, but we are very much interested in high resolution information
08:26
Bertl
(hope this makes sense to you :)
08:27
Guest45618
left the channel
08:28
Bertl
there are also a number of other related tasks which deal with high bandwidth data, so if you are interested in such challenges, there is a lot more to do, like for example efficient reordering of pixel data and similar
08:31
sagnikbasu
Bertl:interesting..we can implement this during the image pre-processing stage.Also , if we study some hybrid pipeline-parallel architecture to our design , we can meet our high bandwidth demand ..
08:33
Bertl
sounds good
08:38
sagnikbasu
Bertl:So as axiom using a zedboard ... I would like to ask...if we use ARM NEON SIMD instruction set in PS for processing part ..would there be any performance improvement?Of course , I assume you want this project to be implemented in PL of zynq..
08:39
Bertl
first, the AXIOM Beta uses a MicroZed (the AXIOM Alpha was built with a Zedboard) but that doesn't change the question
08:40
Bertl
The thing with NEON SIMD is that the ARM cores are not very fast in the Zynq (at least in the Zynq 7020) so typically processing data there is way slower than in the FPGA
08:41
Bertl
the second point is that the memory bandwidth on the Zynq is limited, and accessing the data from both, PL and PS will probably make things worse
08:41
Bertl
that said, I'm not against such an approach, as long as you can show that it is feasable
08:45
sagnikbasu
I see...of course nothing beats the flexibility , speed and efficiency if you design it right using a FPGA , as far as I know..Thanks by the way..
08:46
sagnikbasu
I will look into decimation and bandwidth management part...
08:47
Bertl
excellent! do not hesitate to ask if something is unclear or you need more information
08:47
Bertl
also please collect ideas and design strategies on the lab page
08:48
sagnikbasu
Is the lab page one with the phabricator site ? How do I post there ?
08:49
Bertl
yes, the phabricator is 'the lab' i.e. lab.apertus.org
08:49
Bertl
you simply create an account there and then you can add comments and subscribe to changes
08:57
RL
joined the channel
08:57
RexO
left the channel
09:15
BAndiT1983
joined the channel
09:21
BAndiT1983
left the channel
09:22
BAndiT1983|away
changed nick to: BAndiT1983
09:27
BAndiT1983
i still doesn't understand what speaks against flexible JSON descirption, which can be extended with properties for specific devices, this can also be requested by the client, so the user sees all the properties in the map/hash map
09:28
BAndiT1983
if you put this whole thing into the code, then you approach maintenance hell very fast, i know what i'M talking about, as there is a lot of it in every company i worked for
09:29
Bertl
surprise me ... :)
09:30
BAndiT1983
i'M just asking for usage cases or just a script to look at, so i can estimate which properties are important
09:30
BAndiT1983
when i woke up i had an idea about pre-setting things if you have special cases to handle, so the things can be chained
09:31
Bertl
I'd suggest to start with graphing the various busses on the Beta and how they connect
09:32
BAndiT1983
where do i find this info, in the schematics?
09:32
Bertl
then add the 'known' devices to that and make an educated guess what 'future' devices could make sense
09:33
Bertl
yes, mainly schematics, but I'm happy to double check and explain the connections
09:33
BAndiT1983
daemon could also approach it like i2cdetect, as it lists all the devices, at least where the driver is loaded
09:33
Bertl
would be nice to have something as tikz or similar anyway
09:35
BAndiT1983
tikz? we need a list of busses anyway, hard to guess everytime from the schematics, especially without deeper knowledge in eagle, and no it'S not user-friendly, the layer option is very awkward, instead of a pane to deactivate or activate one, you have to open extra window which is additionaly modal
09:36
Bertl
it is easy to solve with short-cuts
09:36
Bertl
e.g. assign F1-F12 to the various layers and you can toggle them with a keystroke
09:37
Bertl
anyway, no need to work with the board files for figuring out the connectivity and busses
09:37
BAndiT1983
i've checked shortcuts, somehow it just has a couple of the assigned, so ctrl+f we talked last time about is not there at all
09:38
Bertl
seems to be something specific to your installation
09:38
Bertl
i.e. works fine here and always is/was assigned AFAICR
09:38
BAndiT1983
i've just pulled the latest from autodesk, but it feels a little bit unmaintained at all
09:39
Bertl
feel free to convert the files to KiCad :)
09:41
BAndiT1983
will try when i have time, my electronic projects are postponed because of apertus work and film post-processing
09:41
BAndiT1983
want to rework my nobels midi switcher which suffered a little water damage before i got it
09:42
BAndiT1983
so i would replace big chips there with a small ARM
09:42
BAndiT1983
then kicad would be right on time
09:45
BAndiT1983
quick try shows that there are still ERC/DRC problems, the guide says they should be fixed -> https://github.com/lachlanA/eagle-to-kicad
09:45
BAndiT1983
and my version is free one so it stops in the middle of conversion
09:50
BAndiT1983
changed nick to: BAndiT1983|away
09:51
BAndiT1983|away
changed nick to: BAndiT1983
09:52
BAndiT1983
oh, nice, target3001 seems to open eagle files nicely, also the free edition here
09:55
BAndiT1983
also the 3d preview of the board looks very good
10:09
BAndiT1983
Bertl, i could open eagle files, for example in pcbnew module of kicad, it shows the board
10:09
BAndiT1983
https://forum.kicad.info/t/kicad-import-formats-esp-eagle/363
10:10
ItsMeLenny
joined the channel
10:12
Bertl
yeah, conversion is getting better
10:15
sagnikbasu
left the channel
10:24
se6astian|away
changed nick to: se6astian
10:26
Bertl
off for now ... bbl
10:26
Bertl
changed nick to: Bertl_oO
10:33
se6astian
good day
11:01
dimaursu16
joined the channel
11:01
dimaursu16
left the channel
11:01
dimaursu16
joined the channel
11:25
ItsMeLenny
left the channel
14:28
RexOrCine
joined the channel
15:01
Roopal08|away
changed nick to: Roopal08
15:04
Roopal08
Hey <BAndiT1983> , I have gone through the code of ProcessingTest and have also seen BilinearDebayer implementation . I could also see that implementation of SHOODAKDebayer is incomplete .
15:05
BAndiT1983
hi, i had no time to finish it, so we selected first and second version of it for GSoC
15:05
Roopal08
ok.
15:06
Roopal08
would you please tell me what do you expect from this project
15:06
Roopal08
and how should I proceed with it ?
15:08
BAndiT1983
check the code of OC to learn how it is structured first, it still has some rough edges, but they will be fixed when needed, investigate on debayering, for example how to do it in OpenCL
15:09
BAndiT1983
also there is green edge directed debayering which looks rather interesting -> http://www.academia.edu/18351844/Green_Edge_Directed_Demosaicing_Algorithm
15:10
BAndiT1983
there are a couple of things we should investigate especially GPU processing and OpenCL for this things, as we decided to add frame server to OC, for applications which do not support RAW (or other exotic) formats
15:11
BAndiT1983
demosaicing and possibly color-grading (later) have to be done very fast, there is multi-threaded solution which we need
15:12
BAndiT1983
i've added just rudimentary first, through OpenMP
15:14
Roopal08
OK . Will go through green edge directed debayering method .
15:14
Roopal08
and will also look at implementation in OpenCL
15:15
BAndiT1983
further references which can be helpful -> http://graphics.cs.williams.edu/papers/BayerJGT09/
15:15
BAndiT1983
https://github.com/nevion/cldemosaic
15:15
BAndiT1983
we should also focus on SHOODAK at some point, but i have to talk to the guy who developed it first, because some details are still not clear to me
15:16
Roopal08
okk.
15:16
Roopal08
I guess , i should first start with looking for implementation in OpenCL .
15:17
BAndiT1983
first make you comfortable with OC and debayering
15:17
BAndiT1983
OpenCL comes afterwards, no need to rush in without having a plan how to integrate it
15:18
Roopal08
by debayering , you mean different methods of it ? and understanding them
15:18
BAndiT1983
the is a base interface, i think it was called IDataProvider which should be adjusted or extended to present generic methods for usage
15:18
BAndiT1983
first you need general idea of it, if you haven't looked at it before
15:19
BAndiT1983
at the moment we can focus on the general one with with RGGB or some other derivative of it lige GBRG etc.
15:19
BAndiT1983
there are a lot more, some manufacturers also use cyan channel, but that's not of our concern currently
15:19
Roopal08
I have read about debayering at a basic level atleast.
15:20
BAndiT1983
try to get ProcessingTest running, as i don't remember it's state
15:21
BAndiT1983
material can be found here -> https://www.apertus.org/axiom-beta-uhd-raw-mode-explained-article-may-2016
15:21
Roopal08
okay . Will do that first .
15:21
BAndiT1983
just take a DNG file and try to get it to display, methods for it are already implemented in OCcore, as i'Ve used them also in OCBackup
15:22
Roopal08
Yeah , I saw that .
15:23
Roopal08
will do it , and get back to you .
15:28
Roopal08
left the channel
15:36
intracube_afk
changed nick to: intracube
15:47
Spirit532
joined the channel
16:35
jucar
joined the channel
16:50
arpu
joined the channel
17:00
Roopal08
joined the channel
17:01
Roopal08
changed nick to: Roopal08|away
17:07
Roopal08|away
left the channel
18:08
BAndiT1983
changed nick to: BAndiT1983|away
18:08
BAndiT1983|away
changed nick to: BAndiT1983
18:46
jucar
left the channel
20:02
_florent_
joined the channel
20:05
casper_
joined the channel
20:14
casper_
hello
20:18
Bertl_oO
hello casper_!
20:18
Bertl_oO
changed nick to: Bertl
20:19
casper_
left the channel
20:28
arrunM
joined the channel
21:27
arrunM
left the channel
21:28
ArrunM_
joined the channel
21:46
se6astian
changed nick to: se6astian|away
21:52
BAndiT1983
changed nick to: BAndiT1983|away
21:54
dimaursu16
left the channel
22:35
ArrunM_
Hello bertl , I am new to gsoc and open source projects , but I love everything about fpga, 3rd year ip university India doing b.tech in computer science .I'm interested in every fpga related work but like to start with Bidirectional Packet Protocol
22:35
ArrunM_
As you commented its only between two devices and should be ATM like, so I assume no addressing required short header with priority information, anything that should be kept in mind? Am I late for this whole project ? How do I start , make a prototype for this or something?
22:46
Bertl
yeah, no routing address, but we still need to identify ports
22:46
Bertl
(or busses to be precise)
22:47
Bertl
so we probably will have a number of I2C and SPI busses connected to the routing fabric (MachXO2)
22:47
Bertl
and we want to access them remotely from the main FPGA (Zynq)
22:48
Bertl
we also need to map GPIO features (similar to an GPIO extender, which could actually be implemented as device on one of the I2C busses as well)
22:49
Bertl
and we have special pins/ports which need to be 'mapped' i.e. transfered from one FPGA to the other with precisely known delays
22:50
Bertl
(this is the realtime priority)
22:51
Bertl
note that this kind of data can be very limited, probably 8 lines/ports in both directions should suffice
22:51
Bertl
I would also reserve a fixed amount of 'packets' for this, e.g. every odd packet or so to prevent starvation of the non-realtime traffic
22:53
Bertl
and yes, don't let me stop you from digging into it
22:54
Bertl
note that potentially others will be interested in this task as well, so it is a good idea to coordinate and collect information on the lab page
22:54
Bertl
some kind of repository (e.g. github) is a good idea as well
22:55
Bertl
personally I would start with a simple artifical data transfer, e.g. pseudo random numbers, which tests the basic transfer and verifies data integrity
22:56
Bertl
this is something which can easily be simulated and we can then test on the actual hardware
22:57
Bertl
probably some kind of CRC or even better ECC is required to ensure data integrity at 'higher' datarates
22:59
ArrunM_
get every information --> store it in different priority --> switch stacks based on specific algorithm -->attach header and error check--> send
23:02
Bertl
it might make sense to have protocol specific information transfer, but it might also work to simply transfer wire transitions (given that the data exchange is efficent enough)
23:03
ArrunM_
OK, will start with basic, creating packets and verifying integrity
23:03
Bertl
yep, that is something we can, once it works, easily test on the real hardware as well
23:04
Bertl
e.g. send data from the Zynq to the MachXO2 and return a modified version
23:05
Bertl
put that into counters and report via some register or uart or whatever
23:05
Bertl
we can test that with different speeds and see what is possible and how much power that draws
23:06
Bertl
based on that information, we can decide on the optimal clock rate and available bandwidth as well as the protocol packetization
23:07
ArrunM_
vhdl and vivado running on windows will be fine?
23:07
Bertl
for simulation and testing definitely
23:08
intracube
changed nick to: intracube_afk
23:08
Bertl
for the MachXO2 side you will require Lattice Diamond (free version)
23:08
Bertl
but not immediately
23:09
Bertl
I also suggest to use the commandline build instead of the GUI build, because it makes results more consistent (works fine on Windows as well)
23:12
ArrunM_
ok!!! working on it!!!
23:12
Bertl
basically boils down to http://vserver.13thfloor.at/Stuff/AXIOM/BETA/blink_fclk/vivado.tcl (older example)
23:13
Bertl
I can upload a more recent version as well, this one won't work with Vivado 2016.4 (because of missing board definitions, etc)
23:17
Bertl
do you have any FPGA based hardware at hand? (maybe I already asked that :)
23:18
ArrunM_
got 2016 vivado example commands !! no need
23:19
ArrunM_
got spartan 6 lx9 but that works with ise
23:19
ArrunM_
not supported in vivado
23:19
Bertl
yeah, I know
23:19
Bertl
only the 'newer' devices like Artix, Kintex and Zynq are supported
23:20
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/blink_done/
23:21
Bertl
just verified that this one works fine with Vivado 2016.4 and the MicroZed board definition files from AVnet
23:21
ArrunM_
!! will simulate in the software itself and will try to upload soon
23:21
Bertl
note that you can enable VHDL 2008 in vivado, which makes VHDL much more fun :)
23:22
Bertl
(just use read_vhdl -vhdl2008 <file>)
23:23
ArrunM_
sure!!
23:25
Bertl
and do not hesitate to ask if something is unclear, even when I'm not around or asleep, I will read up (channel is logged) and answer as soon as possible
23:28
dimaursu16
joined the channel
23:28
dimaursu16
left the channel
23:28
dimaursu16
joined the channel
23:30
ArrunM_
left the channel
23:41
ArrunM
joined the channel
23:43
ArrunM
left the channel