| 00:21 | arpu | left the channel |
| 00:35 | arpu | joined the channel |
| 00:35 | Elbehery | left the channel |
| 00:46 | Alvis | joined the channel |
| 01:09 | jucar | joined the channel |
| 01:46 | jucar | left the channel |
| 01:56 | jucar | joined the channel |
| 02:05 | Alvis | left the channel |
| 02:13 | mithro | Can everyone retweet https://twitter.com/TimVideosUs/status/841833734747774977 ?
|
| 02:16 | Alvis | joined the channel |
| 02:30 | RexOrCine | Two ticks
|
| 02:31 | RexOrCine | Where are you Mithro?
|
| 02:31 | RexOrCine | mithro *
|
| 02:32 | mithro | RexOrCine: hrm? Physically?
|
| 02:32 | RexOrCine | Yeah, country.
|
| 02:32 | mithro | Australia, why?
|
| 02:34 | RexOrCine | Your optimum time for tweeting is around 3pm to 5pm CET, or 4pm to 6pm GMT. 21% or GSoC students are from the US, and the other 21% India, so these are the timezones you wanna be catching. If you tweet again tomorrow at these time I'll reshare again. Copy @apertususer in if you want no worries.
|
| 02:34 | RexOrCine | 21% of *
|
| 02:43 | mithro | RexOrCine: how do you figure this out / know about this?
|
| 02:49 | RexO | The time zones? I'm well versed in traffic and numbers.
|
| 03:05 | IldarValiev | joined the channel |
| 03:06 | IldarValiev | left the channel |
| 03:48 | Alvis | left the channel |
| 05:00 | RexOrCine | left the channel |
| 05:02 | jucar | left the channel |
| 06:34 | usmankhan | joined the channel |
| 06:35 | usmankhan | left the channel |
| 06:36 | Roopal08|away | left the channel |
| 07:24 | pusle | left the channel |
| 08:04 | Spirit532 | left the channel |
| 08:26 | sagnikbasu95 | joined the channel |
| 08:36 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 08:40 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 08:48 | mithro | Yay! Bunnie tweeted about us - https://twitter.com/bunniestudios/status/841912749479366657
|
| 09:30 | niculescu_vlad | joined the channel |
| 09:40 | sagnikbasu95 | Hi Bertl_zZ..are you busy now ?
|
| 09:41 | IldarValiev | joined the channel |
| 09:41 | IldarValiev | left the channel |
| 09:52 | niculescu_vlad | left the channel |
| 09:54 | sagnikbasu95 | left the channel |
| 10:26 | niculescu_vlad | joined the channel |
| 10:26 | ItsMeLenny | joined the channel |
| 10:59 | ItsMeLenny | left the channel |
| 11:47 | Elbehery | joined the channel |
| 12:28 | dimaursu16 | left the channel |
| 12:33 | IldarValiev | joined the channel |
| 12:40 | IldarValiev | left the channel |
| 13:58 | Elbehery | left the channel |
| 14:00 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 14:02 | ArrunM | joined the channel |
| 14:05 | Alvis | joined the channel |
| 14:16 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 14:16 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 14:17 | ArrunM | left the channel |
| 14:21 | Alvis | left the channel |
| 14:46 | intracube | changed nick to: intracube_afk
|
| 15:02 | Spirit532 | joined the channel |
| 15:18 | Alvis | joined the channel |
| 15:19 | Alvis_ | joined the channel |
| 15:23 | Alvis | left the channel |
| 15:25 | Alvis_ | left the channel |
| 15:26 | Alvis | joined the channel |
| 15:31 | Alvis_ | joined the channel |
| 15:32 | Alvis | left the channel |
| 15:49 | Alvis__ | joined the channel |
| 15:52 | Alvis_ | left the channel |
| 16:06 | jucar | joined the channel |
| 16:10 | Alvis_ | joined the channel |
| 16:13 | Alvis__ | left the channel |
| 16:22 | Bertl_zZ | changed nick to: Bertl
|
| 16:22 | Bertl | morning folks!
|
| 16:25 | Elbehery | joined the channel |
| 16:26 | Alvis_ | left the channel |
| 16:28 | Bertl | ArrunM: for the west side routing fabric, the pins are
|
| 16:29 | Bertl | Clock: BANK13_SE_0 [V5] to PT17A [88]
|
| 16:30 | Bertl | LVDS: BANK13_01_N/P [U10,T9] to PB16A/B [38,39]
|
| 16:30 | Bertl | and for the east side routing fabric:
|
| 16:32 | Bertl | Clock: JX1_SE_0 [R19] to PT17A [88]
|
| 16:33 | jucar | left the channel |
| 16:33 | Bertl | LVDS: JX1_04_N/P [T15/T14] to PB16A/B [38,39] and
|
| 16:34 | Bertl | JX1_05_N/P [R14/P14] to PB11B/A [35,34]
|
| 16:42 | Elbehery | left the channel |
| 16:43 | sagnikbasu | joined the channel |
| 16:46 | sagnikbasu | Bertl : so the other day you were telling how the sobel filter will be on either the input or output of pipeline..so is there any kind of interface which when pressed by the user will send a interrupt kind of service ? I mean I am thinking of using a mux for this purpose
|
| 16:48 | MichaelH | joined the channel |
| 16:48 | derWalter | joined the channel |
| 16:48 | derWalter | is this interessting? : http://www.adapteva.com/announcements/an-open-source-8gbps-low-latency-chip-to-chip-interface/
|
| 16:48 | derWalter | left the channel |
| 16:49 | BAndiT1983 | github code link is broken for that
|
| 16:50 | sagnikbasu | or develop a finite state machine
|
| 16:51 | BAndiT1983 | right link -> https://github.com/parallella/oh/blob/master/src/elink/README.md
|
| 16:55 | dimaursu16 | joined the channel |
| 16:57 | intracube_afk | changed nick to: intracube
|
| 17:09 | Bertl | sagnikbasu: I don't understand the interrupt thing, but if you plan to make the filter optional, then this is probably not required (at least not as part of the filter)
|
| 17:10 | Bertl | but in case you want to do that for testing, the simplest way is to use one of the EMIO pins which are available in the PL fabric and can be controlled from the PS
|
| 17:14 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 17:16 | Bertl | the elink interface is quite old and uses a wide bus IIRC, so not too interesting for our cases
|
| 17:17 | ArrunM | joined the channel |
| 17:18 | Bertl | wb ArrunM! check the IRC logs for the pin information :)
|
| 17:18 | ArrunM | thanks Got it.
|
| 17:20 | ArrunM | 4 bit crc and 5 bit divisor for 32 bit packet is fine?
|
| 17:21 | Bertl | don't know, we have not done any tests yet regarding link quality
|
| 17:31 | anuditverma | joined the channel |
| 17:33 | sagnikbasu | bertl : ok..got it.BTW , check this journal https://www.hindawi.com/journals/js/2016/2654059/ . They implemented on a 1080p video
|
| 17:35 | Alvis | joined the channel |
| 17:36 | anuditverma | left the channel |
| 17:48 | ArrunM | left the channel |
| 17:49 | ArrunM | joined the channel |
| 17:49 | Bertl | nice, maybe link it on the lab task (if permitted)
|
| 17:50 | Bertl | dynamic reconfiguration is something we already considered for 'user filters' but while it works nicely in special cases, it is not that practical for a plug-in system
|
| 17:51 | Bertl | mainly because the toolchain is not able to generate netlists and bitstreams which can be inserted in an existing slot (if you don't build everything at once)
|
| 18:24 | se6astian|away | changed nick to: se6astian
|
| 18:24 | Alvis | left the channel |
| 18:31 | Alvis | joined the channel |
| 18:52 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 18:54 | BAndiT1983 | Bertl, which parts are considered for live reconfiguration on FPGAs?
|
| 18:54 | BAndiT1983 | or is this done just at start?
|
| 19:05 | Bertl | define 'parts'
|
| 19:06 | BAndiT1983 | exchangeable filters or similar, jsut thinking about hdmi settings at the moment
|
| 19:06 | BAndiT1983 | but there are much more possible things
|
| 19:12 | Bertl | basically all kind of functionality can be based on a reconfigureable design
|
| 19:12 | aombk | left the channel |
| 19:12 | Bertl | input pipeline, processing, output pipeline
|
| 19:13 | BAndiT1983 | xilinx says, that parts which are related to reconfigured area should be shut down first etc., so i was wondering what beta is using at the moment or, at least, what is planned
|
| 19:13 | Bertl | we are not using partial reconfiguration at the moment
|
| 19:14 | Bertl | there are plans for smart reconfiguration in the future\
|
| 19:19 | Alvis | left the channel |
| 19:20 | sagnikbasu | left the channel |
| 19:36 | slikdigit | joined the channel |
| 19:40 | Bertl | off for now ... bbl
|
| 19:40 | Bertl | changed nick to: Bertl_oO
|
| 19:50 | niculescu_vlad | left the channel |
| 19:59 | slikdigit | left the channel |
| 20:04 | slikdigit | joined the channel |
| 20:09 | Alvis | joined the channel |
| 20:21 | niculescu_vlad | joined the channel |
| 20:24 | usmankhan | joined the channel |
| 20:25 | usmankhan | Hello!
|
| 20:28 | usmankhan | Bertl, I have done an initial writeup on the component selection and determining open loop gain equation of the buck converter. The next steps would be to fine tune the parameters based on Bode plots, develop flow diagram in terms of Verilog modules and discuss the mixed mode simulation.
|
| 20:29 | usmankhan | Here it is: https://github.com/usmanwardag/gsoc17_proposal/blob/master/pid.pdf. I would appreciate if you can give any comments
|
| 20:29 | BAndiT1983 | you'll have to wait a bit, he has gone to sleep some time ago
|
| 20:29 | usmankhan | Sure, no problem
|
| 20:35 | RexO | He's either gone to sleep or he's out on his skateboard.
|
| 20:36 | BAndiT1983 | nah, not in the moonlight, moon burn could be the cause
|
| 20:55 | Alvis | left the channel |
| 21:00 | MichaelH | left the channel |
| 21:13 | niculescu_vlad | left the channel |
| 21:18 | niculescu_vlad | joined the channel |
| 21:19 | niculescu_vlad | left the channel |
| 21:23 | usmankhan | left the channel |
| 21:29 | aombk | joined the channel |
| 21:47 | slikdigit | left the channel |
| 22:09 | slikdigit | joined the channel |
| 22:11 | slikdigit | left the channel |
| 22:15 | ArrunM | left the channel |
| 22:16 | RexOrCine | joined the channel |
| 22:35 | Bertl_oO | changed nick to: Bertl
|
| 22:36 | Bertl | back now .,..
|
| 22:38 | Bertl | usmankhan: nice writeup, a few comments here:
|
| 22:41 | Bertl | the voltage range of the buck should at least be 1.5V - 3.6V ... with a spike current of up to 2A, so I think your LIR and inductor current will be higher
|
| 22:43 | Bertl | it might also be worth to drop the ADC in favor of one or maybe two comparators, as we already need a DAC to generate the reference voltage (i.e. the one the switcher will follow)
|
| 22:45 | Bertl | note that I don't see a problem with the ADC and I know that it provides better input for a regulation loop, but it is likely to complicate the 'follow' part
|
| 22:47 | Bertl | please let me know what you think and what 'solutions' you have in mind
|
| 22:55 | BAndiT1983 | Bertl, is there a list of memory-mapped devices of the beta?
|
| 22:55 | BAndiT1983 | currently i'm looking at CMV routines in scripts
|
| 22:56 | RexOrCine | Bertl What is the maximum number of frames beta can record continuously right now in burst mode?
|
| 22:56 | Bertl | you mean register map for the AXIOM Beta mappings?
|
| 22:56 | BAndiT1983 | yes, like CMV etc.
|
| 22:58 | BAndiT1983 | i see 4 addresses in the script, but i can only guess what the are for -> https://github.com/apertus-open-source-cinema/beta-software/blob/master/beta-scripts/cmv.func
|
| 22:58 | Bertl | https://wiki.apertus.org/index.php/CMV12000_Register_Blocks
|
| 22:58 | BAndiT1983 | ah, very good, thanks
|
| 22:58 | Bertl | note that it is probably somewhat outdated though
|
| 22:59 | Bertl | RexOrCine: really depends on the resolution
|
| 22:59 | BAndiT1983 | doesn't matter, as it should be reconfigurable easily
|
| 22:59 | RexOrCine | Full res?
|
| 22:59 | Bertl | at 4096x3072 the upper limit is around 40 FPS at the moment
|
| 23:00 | Bertl | (software limit)\
|
| 23:00 | RexOrCine | Any maybe 1080p as well because this is what most people are primarily concerned about I think.
|
| 23:01 | RexOrCine | And*
|
| 23:01 | Bertl | if you actually limit the vertical size to 1080 lines and maybe use binning in both directions, then you should be able to get four times as much, so between 140-150 FPS
|
| 23:02 | Bertl | note that this was not tested yet AFAIK
|
| 23:02 | RexOrCine | Many thanks.
|
| 23:02 | BAndiT1983 | what is the real resolution after all, as there is some area for calibration usually? and which software limit?
|
| 23:03 | Bertl | the 'real' resolution is 4096x3072, but you can 'reserve' a number of black columns on the sides
|
| 23:03 | Bertl | (details in the sensor datasheet)
|
| 23:03 | BAndiT1983 | ah, so canon just reduces the resolution
|
| 23:03 | BAndiT1983 | i have the sheet open, as i talked to se6astian about CMV registers before
|
| 23:03 | Bertl | the 'software' limits are currently the transfer rate between sensor and FPGA as well as the memory interface
|
| 23:04 | Bertl | the sensor can do up to 600MHz (for version 2, 300Mhz for version 1 sensors) but we only use around 200-240MHz currently
|
| 23:05 | BAndiT1983 | is fast enough already, is there some limitation to global shutter mode?
|
| 23:06 | Bertl | once we build a 'smart' interface board, we can also double the datarate, as we are currently only using 32 of the 64 data pairs
|
| 23:06 | Bertl | (that is a hardware limitation we have)
|
| 23:06 | Bertl | OTOH, the bandwidth to the DDR memory is also limited (we do not know the details yet as we didn't run extensive tests)
|
| 23:07 | BAndiT1983 | which ddr type is used?
|
| 23:07 | Bertl | note that we also do not transfer data during exposure
|
| 23:07 | BAndiT1983 | what is the reason?
|
| 23:08 | Bertl | so currently for 25 FPS, the 40ms per frame will be split into roughly 25ms transfer and 15ms exposure
|
| 23:09 | Bertl | the reason is that we know that concurrent readout reduces the quality and needs to be compensated (and we don't do that yet)
|
| 23:10 | Bertl | I don't understand the question regarding global shutter limits
|
| 23:10 | BAndiT1983 | is there some fast buffer involved to store the data temporarily?
|
| 23:10 | Bertl | you mean dedicated two port memory or so?
|
| 23:10 | BAndiT1983 | i was just wondering if global shutter reduces speed or something like that
|
| 23:11 | BAndiT1983 | i don't know how you call it in electronics, for me it's like cache
|
| 23:11 | Bertl | not really, there is a small amount of in sensor transfer overhead
|
| 23:11 | Bertl | when the sensel voltages are 'copied' into the back store
|
| 23:12 | Bertl | there is no dedicated frame buffer memory on the Beta
|
| 23:13 | Bertl | the Microzed features 1GB of DDR3 SDRAM
|
| 23:19 | Bertl | this is implemented in two chips from micron
|
| 23:19 | Bertl | https://www.micron.com/parts/dram/ddr3-sdram/mt41k256m16ha-125
|
| 23:20 | BAndiT1983 | which bit modes are supported for CMV?
|
| 23:21 | Bertl | they form an x32 bus with typically 533MHz clock IIRC
|
| 23:21 | Bertl | the current firmware is locked to 12bit
|
| 23:22 | BAndiT1983 | datasheet says 132 fps in that mode
|
| 23:23 | BAndiT1983 | just trying to get an overview what is used and how fast processing goes
|
| 23:27 | Bertl | that is the limitation from the sensor side at max clock rate and 64bit outputs
|
| 23:28 | Bertl | with binning you can reach up to 267 and with subsampling up to 528 FPS at full resolution
|
| 23:28 | BAndiT1983 | not bad
|
| 23:28 | Bertl | at 10bit, you can get 300FPS and 1049 FPS with subsampling
|
| 23:29 | Bertl | (according to the Cmosis datasheet that is :)
|
| 23:30 | BAndiT1983 | have just reached that part there
|
| 23:31 | se6astian | off to bed
|
| 23:31 | se6astian | good night
|
| 23:31 | se6astian | changed nick to: se6astian|away
|
| 23:31 | BAndiT1983 | night
|
| 23:41 | BAndiT1983 | which settings of CMV the user is/should be allowed to access?
|
| 23:42 | BAndiT1983 | scripts have gain and white balance
|
| 23:49 | Bertl | allowed should be any of the registers
|
| 23:50 | Bertl | we do not want to limit access, but typically there will be 'functions' to set specific 'features'
|
| 23:50 | Bertl | often a 'simple' setting will affect a bunch of registers which need to be set correctly to make it work
|
| 23:50 | BAndiT1983 | sure, was just thinking of encapsulating some calls in general methods, so it's a bit comfortable without searching for all the registers to set gain or similar
|
| 23:51 | BAndiT1983 | currently gain requires gain value of course and ADC range
|
| 23:54 | BAndiT1983 | i suppose that high value of adc range results from setting adc_range_mult bit
|
| 23:54 | Bertl | I think there are two approaches to this:
|
| 23:55 | Bertl | the first is to keep the control daemon to a bare minimum and have some kind of 'support' library which handles the dependencies and details (like limits)
|
| 23:55 | BAndiT1983 | can be done by bit fields
|
| 23:55 | Bertl | the second one is to have some kind of plugins for the control daemon
|
| 23:55 | Bertl | which do exactly that and provide a generic interface to the outside
|
| 23:56 | BAndiT1983 | there would be a memory adapter, from it i would derive CMV adapter, as it'S mapped
|
| 23:56 | BAndiT1983 | at least it's the plan, to not reinvent the wheel i would "methodize" devmem, as it has almost no methods and all is done in main()
|
| 23:57 | BAndiT1983 | for me it's a little bit of unusual thing, but i'm used to OOP development
|
| 23:59 | Bertl | devmem is just the file interface to the kernel memory map
|
| 23:59 | Bertl | once mapped, you can simply access the registers as addresses in your tasks memory
|
| 23:59 | Alvis | joined the channel |
| 23:59 | BAndiT1983 | i know, looked at the source code, wanted to integrate its functionality, to not deploy many processes, at the moment dameon prototype is slim and doesn't require much
|