Monday, 2014-06-23

*** tpb has joined #timvideos00:00
*** mparuszewski has quit IRC01:01
*** puck has quit IRC01:02
mithromorning people03:00
aps-sidsmorning mithro03:03
tijaCan anybody help me out with frame rates? If I am using my laptop as hdmi source, how can I know the frame rate of the video streaming from my laptop?04:04
shenkitija: hello04:58
shenkitija: i didn't hear from you for our vc?04:58
shenkitija: re: framerate, have you considered measuring it on the fpga?05:00
shenkiyou could have a counter that is exposed via the serial port comms05:00
*** xfxf has joined #timvideos05:04
tijashenki: wait for 2 mins. a blog post is coming05:11
shenkitija: ok05:11
tijashenki: Have you read my previos blog?05:12
shenkiI think you're converging on answering the correct questions05:12
shenkithe same goes for your methadology; getting down to testing different parts in isolation is a good way to solve the problem05:13
tijashenki: another blog post. Read it and then we can have a VC05:14
shenkitija: ok. do you mind if we just chat? i'm sick05:14
tijashenki: it answers a lot of question05:14
tijashenki: no problem05:14
shenkitija: hrm, interesting05:17
shenkitija: my brain is working slowly today. can you explain to me where the frames are being dropped?05:19
shenkido we skip reading in frames from the HDMI source into our DDR?05:19
tijashenki: After a frame is read into DDR, it is send for processing. The next frame is read only when processing is complete which means all the frames in between were dropped.05:21
shenkithat's how i understood it too05:22
tijashenki: At 60Hz it means two frames05:22
tijaare dropped05:22
shenkitija: so what if we have multiple buffers in the DDR?05:22
shenkione for the current frame, and one for the next?05:22
shenkiwriting a frame takes longer than processing it, so we should be able to keep up05:22
tija"one for the current frame, and one for the next?" I didn't get you05:23
shenkihave two input frames buffered05:24
shenkin, and n+105:24
shenkiwhile we are procesing n, n+1 is written05:24
shenkiwhen we have processed (encoded) n, we start processing n+1 while n is filled with frame n+305:24
tijaddr2 does not allow simulatneous read and write05:24
shenkierr, s/n+3/n+2/05:24
shenkia question I had from yesterdays blog post: you said that we cannot read and write from the DDR. Isn't our memory controller multi-ported?05:24
tijaYes they are but one port can be written at a time.05:25
tija*written/read at a time05:25
shenkithat's seems strange; it defeats the purpose of having a multi-ported controller05:26
tijathe way it works is that if you have two ports to read from you send a command to the command fifo and the arbiter then reads them one by one05:27
mithrotija: I want to talk to you/shenki and get a better idea on where we are at. However I really need to finish some other stuff before I can do that05:29
shenkimithro: sure05:30
tijamithro: sure, meanwhile you can read my latest blog post. I think I have figured out the reason for difference in frame rates for different encoding quality.05:30
mithroI agree with shenki is that we should put frame counters into each part of the system and then have a way to report them via the serial port05:31
shenkitija: right, but i would imagine the latency of the bus would be reduced if we had a seperate read/write bus05:31
mithrosome information about other things like byte throughput would be useful too05:31
shenkieven if the actual controller cannot issue simultanious read/write commands05:31
shenkitija: okay, so from where05:36
shenkitija: okay, so from here05:36
shenkitija: where do you think we should go?05:36
shenkitija: i would suggest we add a few counters to the design; count each full frame that ends up in DDR from the HDMI, count each frame that is output by the JPEG decoder05:37
shenkitija: these counters then need to be made accessable. I suggest reporting them via the usb-cdc serial device on the fx205:37
tijashenki: to improve the frame rate one of the two thing has to be done. Either reduce the processing time or reduce the write time.05:38
shenkii agree. but first you need to confirm your suspicions05:39
shenkiwith real numbers from the design05:39
shenkinot so much because we don't understand your explaination, but because you need to be able to show the effects that changes have as you improve the frame rate05:40
tijaWhat ever is input in DDR is processed by encoder and sent to usb. I don't get why we need counter?05:40
mithroshenki: I'd like things like bytes/bits too05:40
shenkimithro: yep05:40
shenkitija: right, but if it was that straight forward then we wouldn't be here working on improving the frame rate05:41
shenkitija: it's a matter of confirming your analysis from today's blog post05:42
tijashenki: The state machine works that way. I am not making it up :D05:42
shenkithink of it the same way as a science experiment (because it is!): you come up with a hypothesis, and then test it through observation05:43
shenkitija: yeah, i'm not debating weather or not the state machine works. what i'm suggesting is that we need to know exact numbers, from a real-life situation05:43
shenkiwe want to confirm your 17ms number, as well as the 25ms05:44
mithrotija: You never know what strange things the Xilinx compiler might be doing to your code, or the real world hardware, or any other part of the system05:45
mithrotija: or is if something else in the system is adversly effecting this part05:46
mithrotija: A good Engineer / Computer Scientist confirms things with real world, repeatable, *data*05:47
tijafine then, I guess then I need to get the UART working on linux.05:47
mithrotija: It's the same way if you find a bug, you should write a test which confirms the bug before you try and fix it.05:48
shenkitija: we already have a working uart05:48
shenkitija: it is exposed via the fx205:49
shenkialso, i fixed the driver for the other UART so it works now05:49
*** Palash has joined #timvideos05:50
tijashenki: oh then its all good. Rohit was using my UART for debugging in windows and he reported the code is working fine.05:51
shenkii can't remember if i tested it - but i did find a heap more changes to make to the driver to have it work with newer kernels05:51
mithroayush3504: ping me when you are about05:57
tijashenki: okay. So I will test the UART and then validate the data. Also I guess we have to find an optimum encoding quality 'cause 100% encoding quality is too much for fx2's bandwidth05:58
mithrotija / shenki: I think we need to rationalize (and actually design) the debugging / serial / etc infrastructure inside the firmware05:59
shenkitija: yeah, i think once we have all of these numbers we can start making educated decisions about things like the quality06:01
ayush3504mithro: ping06:01
shenkitija: once you have the numbers coming out, do a blog post with them, and we can decide the next task to attack06:02
shenkitija: how long do you estimate it will take?06:02
mithroayush3504: once shenki / tija are finished discussing stuff can you update me on your current status, where we are at, anything you need help with, etc. I'll reply as soon as I can.06:03
ayush3504mithro: ok06:03
tijashenki: should not take long.06:05
tija1-2 days maybe.06:07
shenkitija: okay, so lets say end of Wednesday?06:07
mithrotija / shenki: Would it be useful to have a shared Google Doc to do some "Design" in this area?06:07
tijamithro: are you talking about debugging design?06:10
shenkitija: yeah, i think he is06:11
shenkitija: i think a simple block diagram of the different parts06:11
shenkiinput, DDR, encoder, USB06:12
shenkiand indicate where the counters will be, what they are counting06:12
shenkiand where they are exposed06:12
tijashenki: okay I  got the idea06:14
ayush3504mithro: got the motherboard schematics ready, figured out auto-detection, doing the daughterboards.06:20
*** slomo has joined #timvideos06:26
*** tija has quit IRC07:19
*** rohitksingh has joined #timvideos09:40
*** rohitksingh has quit IRC10:28
mithroayush3504: okay - I'm around now11:34
mithrobah, both ajit and rohitksingh are not about11:38
shenkiajit works strange hours (for someone in his timezone) as he doesn't have reliable power during the day12:21
mithroshenki: I was pondering the writing into DDR12:34
mithroshenki: any idea what width our DDR is? 1 byte?12:35
shenkii would imagine 32bit12:43
shenkiusually you can also do burst transfers of 64 or more12:43
shenkibut it's more involved to interface with12:43
shenkii assume that HDMI is a continual stream of pixels?12:44
shenkior does it send a frame as fast as it can, and then wait to send the next one?12:44
mithroshenki: you get a full set of pixel data per clock12:46
mithroshenki: no HDMI is source synchronous12:46
shenkia full set of pixel data?12:46
shenkithat's one frame?12:46
mithrono, as in the full RBG (or other format) values for a pixel12:47
mithroactually that might be wrong12:47
tpbTitle: Digital Visual Interface - Wikipedia, the free encyclopedia (at
mithroThinking about the values at a pixel level is probably the right level12:48
mithroAccording to wikipedia, you get "1 pixel per clock cycle"12:49
mithro24 bits per pixel support is mandatory in all resolutions supported.12:49
mithroLess than 24 bits per pixel is optional..12:49
mithroThe DVI data channel operates at a bit-rate that is 10 times the frequency of the clock signal. In other words, in each DVI clock period there is a 10 bit symbol per channel. The set of three 10 bit symbols represents one complete pixel in single link mode and can represent either one or two complete pixels as a set of six 10 bit symbols in dual link mode.12:50
mithroI assume you'd had a pixel buffer in the VHDL, the HDMI -> pixel buffer -> DDR12:51
mithroI'd think the DDR should be much faster than the HDMI, so the pixel buffer is going to be mostly empty?12:52
mithroand the DDR is probably going to be doing nothing a lot of the time12:52
*** Palash has quit IRC12:53
*** tvCommitBot has joined #timvideos13:02
tvCommitBot[HDMI2USB-vmodvga] none pushed 3 new commits to master:
tvCommitBotHDMI2USB-vmodvga/master 059816d Jahanzeb Ahmad: PDF files updated.13:02
tvCommitBotHDMI2USB-vmodvga/master e08deca Tim 'mithro' Ansell: Renaming the README file and adding symlink.13:02
tvCommitBotHDMI2USB-vmodvga/master e2c2dd8 Tim 'mithro' Ansell: Adding a LICENSE file.13:02
*** tvCommitBot has left #timvideos13:02
*** tvCommitBot has joined #timvideos13:03
tvCommitBot[HDMI2USB-vmodserial] none pushed 3 new commits to master:
tvCommitBotHDMI2USB-vmodserial/master e5c304b ayushsagar: Added ISL83387E, deleted discarded daughterboard.sch13:03
tvCommitBotHDMI2USB-vmodserial/master ca638c3 ayushsagar: Changed project name Main to Motherboard to avoid confusion with independent daughterboard projects to be created13:03
tvCommitBotHDMI2USB-vmodserial/master c5da82b ayushsagar: Fixed major flaw in autodetection circuit - daughterboard header pinout changed to set address of ROMs depending on slot13:03
*** tvCommitBot has left #timvideos13:03
*** FeltonChris has quit IRC13:10
shenkispamy spam spam13:21
shenkimithro: ok13:21
shenkimithro: yes, the DDR shouldn't take long13:21
*** rohitksingh has joined #timvideos13:21
shenkimithro: my understanding was that it clocks in the entire frame before starting to encode13:22
mithroshenki: 128Mbyte DDR2 16-bit wide data13:22
shenkithat's the chip? i don't think that describes the bus we're talking to on13:22
mithroshenki:  The whole point of using the DDR ram was to not store large amounts of pixels on the FPGA.13:23
shenkithe FPGA has a memory interface that i assume we're connecting to a AXI or simialr13:23
shenkiwell, i think that's the design you've paid for ;)13:23
mithroMany Spartan-6's have dedicated memory controller I/O blocks13:24
shenkiyeah, you have a memory controller that is part hardware part software13:24
shenkithat sits between the DDR and the fabric13:24
shenkiand on the fabric you connect your IP to ports on the controller13:24
shenkiAXI is a modern bus standardised by ARM13:25
mithroA single 1Gbit DDR2 memory chip is driven from the memory controller block in the Spartan-6 FGPA. Previous versions of the Atlys were loaded with a Micron MT47H64M16-25E DDR2 component, however, newly manufactured Atlys boards now carry an MIRA P3R1GE3EGF G8E DDR2 component. The datasheet for the MIRA device can be found be performing an internet search for13:25
mithroP3R1GE3JGF, which is an equivalent part. Both of these chips provide a 16-bit data bus and 64M locations and have been tested for DDR2 operation at up to an 800MHz data rate.13:25
shenkiright, that's the DDR specs. that doesn't tell us about the memory interface in the FPGA13:25
mithroFrom a bandwidth point of view, that would be 16-bit * 800MHz * 2(DDR) - or 3.2 gigabit/s13:27
shenkii doubt our system can run at 800MHz13:27
mithroshenki: my bet is we are using the memory controller code Xilinx provides13:28
shenkiyes, we are13:28
shenkithe MIG controll13:28
shenkimemory interface generator13:28
mithrolooking at the docs that are in ipcore_dir/ddr2ram/docs13:29
mithroThey say a peak bandwidth of 12.8 Gb/s is possible with 16-Bit wide interface13:30
mithroipcore_dir/ddr2ram/user_design/datasheet.txt seems to contain the details on the interface we asked to be generated....13:32
shenkiwe have one read port and one write port13:34
mithroshenki: I just figured out the Atlys jumpers :P13:36
shenkimithro: yeah? anything interesting?13:36
tpbTitle: Compare Revisions · timvideos/HDMI2USB Wiki · GitHub (at
shenkiah, so just EDID13:56
shenkithat's probably why no one has cared a whole heap13:56
mithroshenki: yeah, but also might be why people are getting different / unreliable EDID detection13:59
mithroshenki: if our firmware is thinking it has control over the EDID and hence stomping on the other signals, etc13:59
mithroCarlFK: please check out the jumper instructions! It might help with the deteciton issue14:00
mithroshenki: Could you take a look over this document -> and add some comments?14:05
tpbTitle: I2C VHDL Cores & their comparison - Google Docs (at
shenkimithro: yep14:06
shenkimithro: what kind of feedback? spelling/grammar? or just overall?14:06
shenkishall i edit it?14:06
mithroshenki: I don't think you have edit permissions?14:06
mithroshenki: more on your expert opinon on the I2C controllers and the analysis14:07
mithroshenki: IE what have they missed?14:07
mithrohey rohitksingh! When did you sneak in?14:07
shenki"expert" hah14:07
rohitksinghmithro: around 1 hour before :)14:08
shenki"using about the same FPGA resources as a Picoblaze processor."14:09
shenkiexcept we program the picoblaze in c14:10
shenkiah, im confusing picoblaze with microblaze14:10
rohitksinghshenki: the I3C2 has a custom assembler which translates the assembly code to VHDL14:11
CarlFKmithro: URL14:11
shenkihrm. my gut reaction is that these things introduce extra complexity into our system, and we would be better off implementing it in HDL14:11
mithroSee above14:11
shenkiwhat is the i2c controller going to be doing?14:12
shenkiis it just EDID?14:12
shenkioh, nvm.14:12
shenkithe AD9984A VGA capture chip uses I2C interface for initialization, configuration and current status monitoring14:12
shenkiso we need to init/config the ADC14:12
mithroshenki: yeah14:12
CarlFKmithro: ah, I was expecting an image. jp2 6 7 .. got it.14:13
shenkiif we didn't already have the EDID stuff there, i would suggest this is worth looking ito14:13
mithroCarlFK: an image would be awesome! :P14:13
rohitksinghshenkiL yes for AD9984A init14:13
shenkibut i think it would be more straight forward to code the hdl to init the ADC14:13
shenkias introducing a new system... now you have two problems14:13
mithroshenki: it also looked like we'll need an I2C controller for the expansion board auto-detection :P14:13
mithroshenki: your thoughts on would be good too14:14
tpbTitle: Guidelines for Auto-Detection compliant Expansion Board - Google Docs (at
rohitksinghshenki: then the second core is more suited for that..just one-off init14:14
shenkirohitksingh: one-off init is well suited to coding in HDL, from my perspective :)14:14
shenkiour system is rapidly bloating14:14
shenkiso yeah, those i2c controllers look cool. they both have decent looking websites14:16
rohitksinghshenki: yeah...but if we decide on adding a I2C based auto-detection,  then I think we would need some more powerful controller14:16
CarlFKcan someone write scripts to do  ( and personally I would not use udev for dev/testing at this point)14:16
tpbTitle: libFPGALink · timvideos/HDMI2USB Wiki · GitHub (at
mithroCarlFK: that comments makes no-sense14:16
CarlFK I think those were right at some point14:16
tpbTitle: Firmware load scripts · timvideos/HDMI2USB Wiki · GitHub (at
mithroCarlFK: those still use udev14:17
mithrowget <-- installing that installs udev rules14:17
shenkirohitksingh: hrm. it's still just a state machine. it would detect what the board is, and start clocking the correct periperhal lines into the IP that talks to it14:17
CarlFKmithro: udev is to run things when usb events happen, right?14:17
shenkirohitksingh: i'm not against the i2c as an idea, it's more in the context of our entire system, and the complexity it adds for maintainance, testing, etc14:18
mithroCarlFK: yeah, those udev rules are just to make sure the device nodes in /dev/XXXX have permissions that allow people to access them14:18
* shenki doesnt use the udev scripts. sudo make-me-a-sandwich14:18
rohitksinghshenki: yeah...valid point!14:18
mithroI think we already have some type of minimal controller in the design which takes the input from the CDC serial input and acts on it14:18
shenkirohitksingh: are you looking at the i2c controller as you want to do less HDL, or is there another motivation for using it?14:19
shenkisorry, i have to go to bed. recovering from a cold. i'll read scrollback in 8 hours or so :)14:20
CarlFKi don't have time today to translate docs into a script, but if someone else does I'll be happy to run the script.  so   whatever is needed to run, put it in the script.14:20
rohitksinghshenki: i wanted greater flexibility. But for AD9984A init, i can directly integrate the init code to the project14:20
rohitksinghshenki: okay...have a nice sleep! :)14:20
rohitksinghshenki: for example using a flexible core, the user can dynamically adjust the brightness and contrast settings for AD9984A instead of Auto-Adjustment..14:23
mithrorohitksingh: did you see my email about enabling the github issues?14:26
rohitksinghyeah...will do it right now14:28
rohitksinghmithro: done14:31
mithrorohitksingh: added a heap of issues to your repositories14:48
rohitksinghmithro: yeah! resolving them one by one! :)14:50
mithrorohitksingh: great!14:51
mithrorohitksingh: sent you another email too14:51
rohitksinghmithro: got that! I'll merge that15:00
mithrowell, I should have been in bed 1.5 hours ago15:19
mithrorohitksingh: talk to you tomorrow!15:19
mithrorohitksingh: I have some ideas on how to do testing15:19
rohitksinghmithro: Sure! Eager to learn! :)15:21
rohitksinghmithro: have a nice sleep!15:21
*** mparuszewski has joined #timvideos15:50
*** Palash has joined #timvideos15:53
ayush3504mithro: sorry, went asleep16:03
*** CarlFK has quit IRC16:12
*** sarwarc has joined #timvideos16:38
*** CarlFK has joined #timvideos17:24
*** ChanServ sets mode: +v CarlFK17:24
*** rohitksingh1 has joined #timvideos18:27
*** rohitksingh has quit IRC18:29
*** slomo_ has joined #timvideos19:02
*** slomo has quit IRC19:03
*** slomo__ has joined #timvideos20:01
*** slomo_ has quit IRC20:04
*** tija has joined #timvideos20:18
*** techdragon has quit IRC20:40
*** Joelw has quit IRC20:40
*** Palash has quit IRC21:01
*** Joelw has joined #timvideos21:04
*** techdragon has joined #timvideos21:04
*** slomo__ has quit IRC21:31
*** CarlFK has quit IRC22:23
*** rohitksingh1 has quit IRC22:35
*** sarwarc has quit IRC23:30
*** FeltonChris has joined #timvideos23:47

Generated by 2.12.1 by Marius Gedminas - find it at!