| 23:02 | Alvis_ | left the channel |
| 23:06 | Bertl | off to bed now ... have a good one everyone!
|
| 23:06 | Bertl | changed nick to: Bertl_zZ
|
| 23:11 | Alvis_ | joined the channel |
| 23:18 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 23:23 | arpu | left the channel |
| 23:36 | arpu | joined the channel |
| 00:31 | Elbehery | left the channel |
| 00:54 | usmankhan | left the channel |
| 01:16 | Alvis__ | joined the channel |
| 01:16 | Alvis_ | left the channel |
| 01:23 | jucar | joined the channel |
| 01:43 | Rex0r | joined the channel |
| 01:59 | RexOrCine | joined the channel |
| 01:59 | RexOrCine | left the channel |
| 02:06 | RexOrCine | joined the channel |
| 02:17 | usmankhan | joined the channel |
| 02:25 | usmankhan | left the channel |
| 02:48 | usmankhan | joined the channel |
| 02:51 | Spirit532 | left the channel |
| 03:07 | usmankhan | left the channel |
| 03:21 | jucar | left the channel |
| 03:27 | usmankhan | joined the channel |
| 03:37 | usmankhan | left the channel |
| 05:02 | Bertl_zZ | changed nick to: Bertl
|
| 05:02 | Bertl | morning folks!
|
| 05:12 | Alvis__ | left the channel |
| 05:13 | usmankhan | joined the channel |
| 05:14 | usmankhan | Hello Bertl, good morning
|
| 05:15 | usmankhan | I am wondering if we can use a multiplexer to manage all sensors using a single adc (I am guessing our switching frequency is high enough so this won't be a problem)?
|
| 05:22 | Bertl | we probably could use a 4 or 8 channel ADC, yes
|
| 05:23 | Bertl | i.e. a device with integrated mux
|
| 05:24 | Bertl | the main question for me is, do we need to digitize the reference signal (DAC) as well to know what we want to follow?
|
| 05:25 | Bertl | or do we add some kind of low ohm power switch and use the switching output for the reference voltage as well
|
| 05:35 | Bertl | http://vserver.13thfloor.at/Stuff/AXIOM/BETA/axiom_beta_sensor_cmv12000_zif_v0.18_r1.2.pdf is one example of the sensor frontend
|
| 05:35 | Bertl | on the second page, you see that we have a bunch of voltage related connections
|
| 05:36 | Bertl | first there is the block of *_CV, *_UV, *_OV pins
|
| 05:37 | Bertl | they are designed to provide some means to check if a given voltage for a rail is within limits
|
| 05:38 | Bertl | *_CV (check voltage) is compared to the low (min) and high (max) voltage for that rail and *_UV (undervoltage) and *_OV (overvoltage) is set accordingly
|
| 05:38 | Bertl | the we have the rails themselves like N_VW, N_VN, N_VE and similar for S_*
|
| 05:39 | Bertl | and what you do not see in this schematic (only in the interface schematic) is that one of each of the power rail pins is not a supply, but a feedback connection instead
|
| 05:40 | Bertl | i.e. the actual voltage on the SFE (sensor frontend) power rails is connected back to the power board for verification
|
| 06:13 | usmankhan | left the channel |
| 06:13 | RexOrCine | Bertl are you able to make an estimate on timescale Re V2 Beta SW?
|
| 06:13 | Bertl | not at the moment
|
| 06:16 | RexOrCine | Is there a chance that a Beta II would ship without it?
|
| 06:17 | Bertl | well, if the current firmware/software can be polished up enough, why not
|
| 06:17 | Bertl | although I would prefer to see a solid redesign on a 'product'
|
| 06:18 | RexOrCine | I'd imagine you'd have a better idea Re timescale going into Q3 or over the summer.
|
| 06:18 | Bertl | yes, I hope so
|
| 06:19 | RexOrCine | Thanks.
|
| 07:01 | se6astian|away | changed nick to: se6astian
|
| 07:01 | Bertl | morning se6astian!
|
| 07:06 | Spirit532 | joined the channel |
| 07:07 | se6astian | good day!
|
| 07:10 | RexOrCine | What's going on today?
|
| 07:11 | Bertl | weird stuff, obviously :)
|
| 07:12 | RexOrCine | Allied Vision? yeah.
|
| 07:57 | pusle | joined the channel |
| 08:10 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 08:34 | sagnikbasu95 | joined the channel |
| 08:35 | sagnikbasu95 | Hi Bertl. Could you please check this link : https://github.com/sagniknitr/Real-time-sobel-filter-in-FPGA/blob/master/FPGA_acceleration.md
|
| 08:42 | Bertl | I see where you're going with that ... let me add a few comments here:
|
| 08:43 | Bertl | first, we should make the kernel generic, i.e. NxN or NxM with 'arbitrary' multipliers
|
| 08:43 | Bertl | i.e. have a factor Fxy and use that for weighting
|
| 08:45 | Bertl | then, fetching data from DDR memory is not an option anyway, because we don't have the bandwidth for that
|
| 08:46 | Bertl | so what you call accelerator store will most likely be a dual port memory inside the FPGA
|
| 08:47 | Bertl | pipelining is essential to reach the required throughput
|
| 08:48 | sagnikbasu95 | ok..so instead of storing in memory..we will directly use signals from the cmos sensor...so how many lvds banks from the cmos sensor will be connected to the FPGA?
|
| 08:49 | sagnikbasu95 | I read in the datasheet there were 7-8 lvds banks
|
| 08:52 | Bertl | either from the sensor, or from the DDR memory when it is retrieved to be displayed via HDMI, but it will not be random acccess, it will be fetched in some kind of chunks
|
| 08:53 | RL | joined the channel |
| 08:53 | Bertl | i.e. I'd say it safe to assume, that the data arrives in 'pixels' per line, for each line from top to bottom
|
| 08:58 | Bertl | so there needs to be a line buffer with at least N-1 lines to apply an NxN kernel
|
| 09:03 | sagnikbasu95 | ok..got it...one question: In the axiom beta wiki , there was a color cinversion block mentioned in the signal datapth..i assume this is for RGB/YUV conversion ?
|
| 09:03 | sagnikbasu95 | *conversion..
|
| 09:05 | Bertl | I guess you are referring to the Image Processing Pipeline, yes?
|
| 09:05 | Bertl | https://wiki.apertus.org/images/c/cc/Image01.png
|
| 09:08 | LordVan | joined the channel |
| 09:10 | sagnikbasu95 | yes exactly..
|
| 09:10 | Bertl | the problem there is that it is somewhat outdated (i.e. it was copied from the Axiom Alpha)
|
| 09:10 | Bertl | the entire HDMI Encoder part was a solution from Analog Devices back then
|
| 09:11 | Bertl | but now, in the Beta, we generate the HDMI ourselves
|
| 09:11 | Bertl | so currently, it is 'limited' to RGB, but in the future, we will also do YCrCb for which we will require a color space converter
|
| 09:12 | Bertl | (this is mainly to get higher frame rates by utilizing subsampling)
|
| 09:12 | Bertl | but none of this should affect the kernel or filter, as it doesn't make much sense to put it after any color conversion
|
| 09:13 | sagnikbasu95 | yes of course..
|
| 09:14 | sagnikbasu95 | Thanks Bertl
|
| 09:14 | Bertl | no problem
|
| 09:14 | Bertl | so to sum up, the main challenges for the filter are:
|
| 09:14 | Bertl | - high bandwidth throughput
|
| 09:15 | Bertl | - line store with generic number of lines
|
| 09:15 | Bertl | - pipelining to reduce resources and improve performance
|
| 09:16 | Bertl | the generic weighting should also be done in such a way that it can be optimized out for a given kernel
|
| 09:17 | Bertl | i.e. fields with weight 0 will not get computed at all and fields with weigth 1 will not be multiplied just added
|
| 09:18 | Bertl | I would also suggest to start with a simple design and build a more generic/complex one based on the results and ideas
|
| 09:21 | sagnikbasu95 | left the channel |
| 09:36 | intracube_afk | changed nick to: intracube
|
| 09:48 | usmankhan | joined the channel |
| 09:49 | usmankhan | I would like to point out to this useful resource for carrying out pipelined convolution: https://daim.idi.ntnu.no/masteroppgaver/013/13656/masteroppgave.pdf
|
| 09:49 | usmankhan | See page 37 for convolution implementation
|
| 09:50 | Bertl | excellent! please add it to the apropriate lab task
|
| 09:51 | usmankhan | Sure! just to be clear, I am talking about section 4.4.4
|
| 11:04 | usmankhan | left the channel |
| 11:38 | dimaursu16 | left the channel |
| 11:48 | dimaursu16 | joined the channel |
| 12:11 | Bertl | off for now .. bbl
|
| 12:11 | Bertl | changed nick to: Bertl_oO
|
| 12:12 | dimaursu16 | left the channel |
| 12:28 | tyrone | joined the channel |
| 12:42 | RL | left the channel |
| 12:43 | ljmocic | joined the channel |
| 12:48 | LordVan | left the channel |
| 13:01 | anuditverma | joined the channel |
| 13:01 | anuditverma | left the channel |
| 13:27 | niculescu_vlad | joined the channel |
| 13:42 | dimaursu16 | joined the channel |
| 13:55 | ljmocic | left the channel |
| 14:39 | tyrone_ | joined the channel |
| 14:40 | tyrone | left the channel |
| 14:50 | RexOrCine | left the channel |
| 14:52 | se6astian | changed nick to: se6astian|away
|
| 14:57 | jucar | joined the channel |
| 15:06 | arpu | left the channel |
| 15:11 | arpu | joined the channel |
| 15:22 | jucar | left the channel |
| 15:42 | tyrone_ | left the channel |
| 15:47 | tyrone | joined the channel |
| 16:05 | tyrone | left the channel |
| 18:05 | se6astian|away | changed nick to: se6astian
|
| 18:22 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 18:23 | derWalter | joined the channel |
| 18:30 | derWalter | left the channel |
| 18:42 | slikdigit | joined the channel |
| 19:11 | Rex0r | left the channel |
| 19:12 | RexOrCine | joined the channel |
| 19:26 | comradekingu | left the channel |
| 19:27 | comradekingu | joined the channel |
| 20:06 | se6astian | off to bed
|
| 20:06 | se6astian | good night
|
| 20:07 | se6astian | changed nick to: se6astian|away
|
| 20:51 | niculescu_vlad | left the channel |
| 20:57 | slikdigit | left the channel |
| 21:12 | slikdigit | joined the channel |
| 22:56 | slikdigit__ | joined the channel |
| 22:57 | slikdigit | left the channel |