| 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 |