#apertus IRC Channel Logs

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)

i2c is represented in linux only by bus devices

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

first, note that IRC has a line limit, so your message was cut off after 'I have experien'

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.

Sure.. I would do that..

I am studying some literature regarding efficient bandwidth and power management for signal processing tasks in FPGA

sagnikbasu: so the basic concept of applying a kernel is probably nothing new to you :)

sagnikbasu: also, efficient decimation could be a very interesting topic here

and we are not really interested in a sobel of each and every sensel, but we are very much interested in high resolution information

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

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

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

that said, I'm not against such an approach, as long as you can show that it is feasable

I will look into decimation and bandwidth management part...

also please collect ideas and design strategies on the lab page

yes, the phabricator is 'the lab' i.e. lab.apertus.org

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

i'M just asking for usage cases or just a script to look at, so i can estimate which properties are important

I'd suggest to start with graphing the various busses on the Beta and how they connect

then add the 'known' devices to that and make an educated guess what 'future' devices could make sense

daemon could also approach it like i2cdetect, as it lists all the devices, at least where the driver is loaded

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

e.g. assign F1-F12 to the various layers and you can toggle them with a keystroke

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

i.e. works fine here and always is/was assigned AFAICR

feel free to convert the files to KiCad :)

want to rework my nobels midi switcher which suffered a little water damage before i got it

then kicad would be right on time

and my version is free one so it stops in the middle of conversion

also the 3d preview of the board looks very good

https://forum.kicad.info/t/kicad-import-formats-esp-eagle/363

yeah, conversion is getting better

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 .

ok.

and how should I proceed with it ?

also there is green edge directed debayering which looks rather interesting -> http://www.academia.edu/18351844/Green_Edge_Directed_Demosaicing_Algorithm

demosaicing and possibly color-grading (later) have to be done very fast, there is multi-threaded solution which we need

OK . Will go through green edge directed debayering method .

further references which can be helpful -> http://graphics.cs.williams.edu/papers/BayerJGT09/

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

I guess , i should first start with looking for implementation in OpenCL .

OpenCL comes afterwards, no need to rush in without having a plan how to integrate it

the is a base interface, i think it was called IDataProvider which should be adjusted or extended to present generic methods for usage

at the moment we can focus on the general one with with RGGB or some other derivative of it lige GBRG etc.

I have read about debayering at a basic level atleast.

material can be found here -> https://www.apertus.org/axiom-beta-uhd-raw-mode-explained-article-may-2016

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

will do it , and get back to you .

hello

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

yeah, no routing address, but we still need to identify ports

so we probably will have a number of I2C and SPI busses connected to the routing fabric (MachXO2)

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)

(this is the realtime priority)

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

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

personally I would start with a simple artifical data transfer, e.g. pseudo random numbers, which tests the basic transfer and verifies data integrity

probably some kind of CRC or even better ECC is required to ensure data integrity at 'higher' datarates

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)

yep, that is something we can, once it works, easily test on the real hardware as well

put that into counters and report via some register or uart or whatever

based on that information, we can decide on the optimal clock rate and available bandwidth as well as the protocol packetization

for simulation and testing definitely

for the MachXO2 side you will require Lattice Diamond (free version)

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)

basically boils down to http://vserver.13thfloor.at/Stuff/AXIOM/BETA/blink_fclk/vivado.tcl (older example)

do you have any FPGA based hardware at hand? (maybe I already asked that :)

got spartan 6 lx9 but that works with ise

yeah, I know

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/blink_done/

!! will simulate in the software itself and will try to upload soon

(just use read_vhdl -vhdl2008 <file>)

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