Current Server Time: 22:42 (Central Europe)

#apertus IRC Channel Logs

2017/03/12

Timezone: UTC


23:07
BAndiT1983
left the channel
23:50
slikdigit
left the channel
23:57
Rex0r
left the channel
23:58
RL
left the channel
23:58
Rex0r
joined the channel
23:58
slikdigit
joined the channel
23:58
RexOrCine
left the channel
23:59
RexOrCine
joined the channel
00:08
dimaursu16
joined the channel
00:08
dimaursu16
left the channel
00:08
dimaursu16
joined the channel
00:13
RexO
joined the channel
00:20
dimaursu16
left the channel
01:12
jucar
joined the channel
01:40
dimaursu16
joined the channel
01:50
dimaursu16
left the channel
02:19
dimaursu16
joined the channel
02:19
dimaursu16
left the channel
02:19
dimaursu16
joined the channel
02:27
slikdigit
left the channel
02:27
RexOrCine
left the channel
02:28
Guest4561
joined the channel
02:29
Guest4561
left the channel
03:00
dimaursu16
left the channel
03:44
Spirit532
left the channel
03:53
dimaursu16
joined the channel
03:53
dimaursu16
left the channel
03:53
dimaursu16
joined the channel
04:16
Bertl_zZ
changed nick to: Bertl
04:16
Bertl
morning folks!
04:37
dimaursu16
left the channel
05:01
jucar
left the channel
06:13
sagnikbasu
joined the channel
06:52
sagnikbasu
left the channel
07: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)
07:10
Guest45618
joined the channel
07:11
danieel
i2c is represented in linux only by bus devices
07:16
sagnikbasu
joined the channel
07: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
07:17
Bertl
Hello sagnikbasu!
07:17
Bertl
first, note that IRC has a line limit, so your message was cut off after 'I have experien'
07: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)
07: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.
07: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
07:20
sagnikbasu
Sure.. I would do that..
07:22
Bertl
danieel: well, not sure we want that degree of HAL, it's probably more important to get the required metadata
07:22
sagnikbasu
I am studying some literature regarding efficient bandwidth and power management for signal processing tasks in FPGA
07:22
danieel
what for? e.g. the LM75 would appear in /sys/class/hwmon, or /sys/class/thermal
07:22
Bertl
sagnikbasu: so the basic concept of applying a kernel is probably nothing new to you :)
07:23
Bertl
danieel: yes, but we would like to know stuff like: the location of the sensor, the initial accuracy, the resolution, etc
07:24
Bertl
sagnikbasu: also, efficient decimation could be a very interesting topic here
07:25
Bertl
we are basically getting a huge amount of data (4k, 12bit @ 60+ FPS) from the sensor
07: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
07:26
Bertl
(hope this makes sense to you :)
07:27
Guest45618
left the channel
07: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
07: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 ..
07:33
Bertl
sounds good
07: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..
07:39
Bertl
first, the AXIOM Beta uses a MicroZed (the AXIOM Alpha was built with a Zedboard) but that doesn't change the question
07: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
07: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
07:41
Bertl
that said, I'm not against such an approach, as long as you can show that it is feasable
07: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..
07:46
sagnikbasu
I will look into decimation and bandwidth management part...
07:47
Bertl
excellent! do not hesitate to ask if something is unclear or you need more information
07:47
Bertl
also please collect ideas and design strategies on the lab page
07:48
sagnikbasu
Is the lab page one with the phabricator site ? How do I post there ?
07:49
Bertl
yes, the phabricator is 'the lab' i.e. lab.apertus.org
07:49
Bertl
you simply create an account there and then you can add comments and subscribe to changes
07:57
RL
joined the channel
07:57
RexO
left the channel
08:15
BAndiT1983
joined the channel
08:21
BAndiT1983
left the channel
08:22
BAndiT1983|away
changed nick to: BAndiT1983
08: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
08: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
08:29
Bertl
surprise me ... :)
08:30
BAndiT1983
i'M just asking for usage cases or just a script to look at, so i can estimate which properties are important
08: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
08:31
Bertl
I'd suggest to start with graphing the various busses on the Beta and how they connect
08:32
BAndiT1983
where do i find this info, in the schematics?
08:32
Bertl
then add the 'known' devices to that and make an educated guess what 'future' devices could make sense
08:33
Bertl
yes, mainly schematics, but I'm happy to double check and explain the connections
08:33
BAndiT1983
daemon could also approach it like i2cdetect, as it lists all the devices, at least where the driver is loaded
08:33
Bertl
would be nice to have something as tikz or similar anyway
08: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
08:36
Bertl
it is easy to solve with short-cuts
08:36
Bertl
e.g. assign F1-F12 to the various layers and you can toggle them with a keystroke
08:37
Bertl
anyway, no need to work with the board files for figuring out the connectivity and busses
08: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
08:38
Bertl
seems to be something specific to your installation
08:38
Bertl
i.e. works fine here and always is/was assigned AFAICR
08:38
BAndiT1983
i've just pulled the latest from autodesk, but it feels a little bit unmaintained at all
08:39
Bertl
feel free to convert the files to KiCad :)
08:41
BAndiT1983
will try when i have time, my electronic projects are postponed because of apertus work and film post-processing
08:41
BAndiT1983
want to rework my nobels midi switcher which suffered a little water damage before i got it
08:42
BAndiT1983
so i would replace big chips there with a small ARM
08:42
BAndiT1983
then kicad would be right on time
08: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
08:45
BAndiT1983
and my version is free one so it stops in the middle of conversion
08:50
BAndiT1983
changed nick to: BAndiT1983|away
08:51
BAndiT1983|away
changed nick to: BAndiT1983
08:52
BAndiT1983
oh, nice, target3001 seems to open eagle files nicely, also the free edition here
08:55
BAndiT1983
also the 3d preview of the board looks very good
09:09
BAndiT1983
Bertl, i could open eagle files, for example in pcbnew module of kicad, it shows the board
09:09
BAndiT1983
https://forum.kicad.info/t/kicad-import-formats-esp-eagle/363
09:10
ItsMeLenny
joined the channel
09:12
Bertl
yeah, conversion is getting better
09:15
sagnikbasu
left the channel
09:24
se6astian|away
changed nick to: se6astian
09:26
Bertl
off for now ... bbl
09:26
Bertl
changed nick to: Bertl_oO
09:33
se6astian
good day
10:01
dimaursu16
joined the channel
10:01
dimaursu16
left the channel
10:01
dimaursu16
joined the channel
10:25
ItsMeLenny
left the channel
13:28
RexOrCine
joined the channel
14:01
Roopal08|away
changed nick to: Roopal08
14: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 .
14:05
BAndiT1983
hi, i had no time to finish it, so we selected first and second version of it for GSoC
14:05
Roopal08
ok.
14:06
Roopal08
would you please tell me what do you expect from this project
14:06
Roopal08
and how should I proceed with it ?
14: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
14:09
BAndiT1983
also there is green edge directed debayering which looks rather interesting -> http://www.academia.edu/18351844/Green_Edge_Directed_Demosaicing_Algorithm
14: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
14:11
BAndiT1983
demosaicing and possibly color-grading (later) have to be done very fast, there is multi-threaded solution which we need
14:12
BAndiT1983
i've added just rudimentary first, through OpenMP
14:14
Roopal08
OK . Will go through green edge directed debayering method .
14:14
Roopal08
and will also look at implementation in OpenCL
14:15
BAndiT1983
further references which can be helpful -> http://graphics.cs.williams.edu/papers/BayerJGT09/
14:15
BAndiT1983
https://github.com/nevion/cldemosaic
14: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
14:16
Roopal08
okk.
14:16
Roopal08
I guess , i should first start with looking for implementation in OpenCL .
14:17
BAndiT1983
first make you comfortable with OC and debayering
14:17
BAndiT1983
OpenCL comes afterwards, no need to rush in without having a plan how to integrate it
14:18
Roopal08
by debayering , you mean different methods of it ? and understanding them
14: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
14:18
BAndiT1983
first you need general idea of it, if you haven't looked at it before
14:19
BAndiT1983
at the moment we can focus on the general one with with RGGB or some other derivative of it lige GBRG etc.
14:19
BAndiT1983
there are a lot more, some manufacturers also use cyan channel, but that's not of our concern currently
14:19
Roopal08
I have read about debayering at a basic level atleast.
14:20
BAndiT1983
try to get ProcessingTest running, as i don't remember it's state
14:21
BAndiT1983
material can be found here -> https://www.apertus.org/axiom-beta-uhd-raw-mode-explained-article-may-2016
14:21
Roopal08
okay . Will do that first .
14: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
14:22
Roopal08
Yeah , I saw that .
14:23
Roopal08
will do it , and get back to you .
14:28
Roopal08
left the channel
14:36
intracube_afk
changed nick to: intracube
14:47
Spirit532
joined the channel
15:35
jucar
joined the channel
15:50
arpu
joined the channel
16:00
Roopal08
joined the channel
16:01
Roopal08
changed nick to: Roopal08|away
16:07
Roopal08|away
left the channel
17:08
BAndiT1983
changed nick to: BAndiT1983|away
17:08
BAndiT1983|away
changed nick to: BAndiT1983
17:46
jucar
left the channel
19:02
_florent_
joined the channel
19:05
casper_
joined the channel
19:14
casper_
hello
19:18
Bertl_oO
hello casper_!
19:18
Bertl_oO
changed nick to: Bertl
19:19
casper_
left the channel
19:28
arrunM
joined the channel
20:27
arrunM
left the channel
20:28
ArrunM_
joined the channel
20:46
se6astian
changed nick to: se6astian|away
20:52
BAndiT1983
changed nick to: BAndiT1983|away
20:54
dimaursu16
left the channel
21: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
21: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?
21:46
Bertl
yeah, no routing address, but we still need to identify ports
21:46
Bertl
(or busses to be precise)
21:47
Bertl
so we probably will have a number of I2C and SPI busses connected to the routing fabric (MachXO2)
21:47
Bertl
and we want to access them remotely from the main FPGA (Zynq)
21: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)
21: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
21:50
Bertl
(this is the realtime priority)
21:51
Bertl
note that this kind of data can be very limited, probably 8 lines/ports in both directions should suffice
21: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
21:53
Bertl
and yes, don't let me stop you from digging into it
21: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
21:54
Bertl
some kind of repository (e.g. github) is a good idea as well
21: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
21:56
Bertl
this is something which can easily be simulated and we can then test on the actual hardware
21:57
Bertl
probably some kind of CRC or even better ECC is required to ensure data integrity at 'higher' datarates
21:59
ArrunM_
get every information --> store it in different priority --> switch stacks based on specific algorithm -->attach header and error check--> send
22: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)
22:03
ArrunM_
OK, will start with basic, creating packets and verifying integrity
22:03
Bertl
yep, that is something we can, once it works, easily test on the real hardware as well
22:04
Bertl
e.g. send data from the Zynq to the MachXO2 and return a modified version
22:05
Bertl
put that into counters and report via some register or uart or whatever
22:05
Bertl
we can test that with different speeds and see what is possible and how much power that draws
22:06
Bertl
based on that information, we can decide on the optimal clock rate and available bandwidth as well as the protocol packetization
22:07
ArrunM_
vhdl and vivado running on windows will be fine?
22:07
Bertl
for simulation and testing definitely
22:08
intracube
changed nick to: intracube_afk
22:08
Bertl
for the MachXO2 side you will require Lattice Diamond (free version)
22:08
Bertl
but not immediately
22: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)
22:12
ArrunM_
ok!!! working on it!!!
22:12
Bertl
basically boils down to http://vserver.13thfloor.at/Stuff/AXIOM/BETA/blink_fclk/vivado.tcl (older example)
22: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)
22:17
Bertl
do you have any FPGA based hardware at hand? (maybe I already asked that :)
22:18
ArrunM_
got 2016 vivado example commands !! no need
22:19
ArrunM_
got spartan 6 lx9 but that works with ise
22:19
ArrunM_
not supported in vivado
22:19
Bertl
yeah, I know
22:19
Bertl
only the 'newer' devices like Artix, Kintex and Zynq are supported
22:20
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/blink_done/
22:21
Bertl
just verified that this one works fine with Vivado 2016.4 and the MicroZed board definition files from AVnet
22:21
ArrunM_
!! will simulate in the software itself and will try to upload soon
22:21
Bertl
note that you can enable VHDL 2008 in vivado, which makes VHDL much more fun :)
22:22
Bertl
(just use read_vhdl -vhdl2008 <file>)
22:23
ArrunM_
sure!!
22: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
22:28
dimaursu16
joined the channel
22:28
dimaursu16
left the channel
22:28
dimaursu16
joined the channel
22:30
ArrunM_
left the channel
22:41
ArrunM
joined the channel
22:43
ArrunM
left the channel