Wednesday, 2014-07-02

*** tpb has joined #timvideos00:00
*** rohitksingh has quit IRC00:58
mithroCARAM_: sure?03:16
mithroshenki: I think thats very Australian :P03:16
mithroayush3504: ping?03:21
ayush3504mithro: pong03:21
mithroayush3504: why are the slot hierarchical pins passive?03:21
ayush3504mithro: they're neither input or output, i could choose tristate or passive03:22
mithrookay, so you should understand the different types of wires03:23
ayush3504mithro: passive is more flexible, that's why i chose it03:23
ayush3504mithro: from the isolator's side the pins shouldn't be tristate03:24
mithroPassive == Analog / Power / etc - Should never be used by a digital pins03:24
ayush3504mithro: ok, then tristate?03:24
mithroDigital pins should *always* be one of, In, Out, Bidirectional, Tri-State03:24
ayush3504mithro: ok03:24
mithroIn and Out should be pretty clear03:24
mithroBidirectional means that the signal can be in or out.03:25
ayush3504mithro: but the bus can't be in or out right, so i'm left with tristate03:25
ayush3504mithro: and bidirectional03:25
*** sarwarc has joined #timvideos03:25
mithroTri-state means that the signal can be "In", "Out" or "High Impedance"03:25
ayush3504mithro: yes, the fpga and pic18 supports that, but the middle block doesnt03:26
ayush3504mithro: how about bidirectional?03:26
mithroWell, the outputs from the PIC / VHDCI should definitely be tristate03:27
ayush3504mithro: ok, i've done made the middle one bidi and the pic18 and vhdci pins tristate03:28
mithroayush3504: okay - I think that makes sense03:29
mithrothe tri-state stuff is important as it allows the PIC and the FPGA to both be connected to the same wires03:30
ayush3504mithro: got it03:33
mithroayush3504: connecting two out pins together should cause a DRC error03:33
ayush3504mithro: yes it should case, but it seems ERC doesn't check hierarchical pins03:34
mithroYou can test by making the PIC and VHDCI both as output and do the check03:35
mithroWow, digital isolators are expensive....03:36
ayush3504mithro: tried, did not show an error03:36
ayush3504mithro: i think hierarchical pin type is just for the symbols03:37
mithroayush3504: interesting03:39
mithroayush3504: I'm trying to remember the justification for the data-isolation from motherboard to the daughterboard03:45
ayush3504mithro: ground loops, protecting fpga03:45
mithroayush3504: but most serial drivers have inbuilt isolation?03:45
ayush3504mithro: not most03:46
ayush3504mithro: the ones which have cost extra 2$03:46
ayush3504mithro: they start from $403:46
mithroISL32433E <-- for the RS422 that is isolated right?03:47
ayush3504mithro: no, we aren't using this, we're using the pin compativle ISL8491E03:48
mithrothe ISL8491E isn't isolated?03:48
ayush3504mithro: ISL32433E is more robust for ESD and overvoltages, and supports 3.3V03:48
ayush3504mithro: none of them03:48
mithroayush3504: it just has ESD protection rather than isolation03:49
ayush3504mithro: so i'm leaving an option to use ISL32433E ($3.68) or ISL8491E ($0.97)03:49
ayush3504mithro: and 3.3V support03:50
ayush3504mithro: if any one needs 3.3V then ISL324... can be used otherwise ISL8491 works good as well03:50
ayush3504mithro: both are pin compatible03:50
mithroayush3504: it looks like with IO isolation we are stuck with exactly the serial interface rather then it being general04:00
ayush3504mithro: yes, but this is serial expansion board right? we can't be general beyond that :p04:02
mithroayush3504: sure, but I was hoping to cover GPIO at the same time04:04
ayush3504mithro: yeah, the workaround for that is having a micro in daughterboards04:05
mithroayush3504: I guess continue that way for now then04:12
ayush3504mithro: ok04:12
mithroayush3504: how are the PCBs going?04:18
ayush3504mithro: had to ask one thing, should I lay out components on the slot area?04:19
ayush3504mithro: like the isolator chips04:20
mithroayush3504: you want to be able to "drop" the PCB from a daughterboard into the slot area04:20
ayush3504mithro: oh okay04:20
ayush3504mithro: i'm solving a few issues, should begin with cvpcb in a couple hours.04:21
ayush3504mithro: hopefully I'll be able to give a preview in a snippet post this evening04:27
shenkitija: hello04:37
tijashenki: Hi04:37
shenkitija: hey! hows things?04:38
tijashenki: the report is almost done.After that I will study about DDR04:38
shenkitija: cool. are you doing the report in google docs?04:39
tijashenki: yes04:39
shenkitija: feel free to paste the link in here, even if it isn't done04:39
shenkitija: did you speak with mithro about a time for a vc?04:39
tijashenki: no I haven't04:40
shenkihe's a busy man, you should get onto that asap04:40
tijashenki: okay will do that. Do you still have access to server machine for building firmware. My laptop is overheating when I am building the firmware.04:42
shenkihah. yeah, we can spin it up04:43
shenkiwhat is the night time temp where you live?04:43
tija+30 C04:43
shenkiyeah, you don't really need a heater then04:43
shenkitija: are you familiar with using ssh?04:44
tijaMy laptop is working good in an air conditioned environment. But I can't be always in AC, it is expensive.04:44
tijashenki: ssh yes!04:44
shenkitija: cool. can you please send me your pubkey so i can give you access?04:45
tijashenki: okay04:49
shenkitija: are you sending it now?04:59
shenkithe VM is running, and we pay for it by the hour04:59
tijaokay I need to switch to ubuntu.05:07
tijashenki: sorry05:08
tijashenki: but I currently don't have any use.05:08
shenkitija: you don't need it for now?05:09
shenkitija: you can use ssh from windows :)05:09
shenkii'll shut it down then05:09
tijashenki: yeah I managed yesterday by switching between windows and ubuntu.05:10
*** sarwarc_ has joined #timvideos05:20
tijaMid term report:
tpbTitle: Google Docs - create and edit documents online, for free. (at
*** sarwarc has quit IRC05:23
mithroshenki: when you get a moment I wanted to continue chatting with you about DDR? Would a normal DDR controller look something like -> ?05:42
shenkimithro: yeah, im in the middle of stuff thisafternoon. can chat thisevening05:47
mithroshenki: okay05:47
shenkitija: you have studied the DDR a bit. Do the links mithro pasted describe the DDR and controller in our system05:48
shenkimithro: i think the answer is "yes"05:48
shenkimithro: did you see tija's report ^05:48
mithrohaven't had a chance to read it yet05:48
tijamithro: The one used in our system is this one
shenkitija: what is the transfer size between the jpeg core and the DDR?05:55
tijashenki: 24 bits05:56
tijamithro: sorry, this is the real thing
tijamithro: on Page 16 you can see the architechture05:57
shenkitija: have you considered doing larger transfers?05:58
tijashenki: larger transfer won't change the encoding time06:01
shenkiright, because all that we would do would have the jpeg core sitting there idle for longer?06:07
tijashenki: true, currently there is a period where the encoder is doing nothing(After encoding is complete and frame Y is in the input), we have to make the encoder busy at that period. Then we can reach 40 fps.06:09
shenkitija: and can we do that by feeding the jpeg core every 16-lines, instead of every frame?06:11
mithrojust a random comment - we should think of this as a pipeline with leaky buffers in between06:11
shenkitija: do you know how the RLE time compares to the amount of time to encode one 16 line chunk?06:11
shenkis/encode/write from hdmi to DDR/06:12
shenkimithro: what is the pipeline in your analogy?06:12
shenkimithro: we should think of it as a CPU pipeline with bubbles due to memory salls06:12
shenkimithro: becase that's exactly what it is ;)06:13
mithroshenki: IE, the HDMI interface produces frames and stuffs them into a buffer06:13
mithroshenki: the encoder takes a frame from the buffer and does encoding for it and stuffs it into a buffer for the usb to send06:14
mithroshenki: then the usb takes the frame and sends it out06:14
shenkiright. that's how it currently works. we want it to work on more of a frame basis, as otherwise we're waiting for too long for the next frame06:14
shenkialternativly, you could have many buffers in the DDR06:14
shenkithat would increase latency by some percentage of one frame06:15
mithroshenki: no, currently the HDMI interfaces takes a frame puts it into the buffer then stops06:15
shenkiit might be a simpler solution, however you will always be bound by the jpeg core speed for an entire frame06:15
mithroshenki: it should keep putting stuff into buffers, using something like a double/triple buffering type system06:15
shenki15:44 <+shenki> alternativly, you could have many buffers in the DDR06:15
tijashenki: How about this? Store first frame> start encoding>meanwhile start storing frame X(if that is possible). So after encoding finishes another frame is waiting to be encoded. We drop frame Y. this way we have 40 fps06:16
mithroshenki: buffers also should never cause a stall06:16
mithroshenki: you should just update the information06:16
shenkimithro: explain what you mean06:17
mithroso, we have clear "units" of information right06:18
mithroa single frame06:18
shenkitija: yeah, that's one way to solve it06:18
shenkitija: it's what mithro is describing06:18
mithroIf you have triple buffering06:18
mithroyou always have06:18
mithroa buffer your currently filling06:18
mithroa buffer that is currently ready to be read from06:19
mithroa buffer that you are currently reading from06:19
mithrowhen a reader is finishes reading from a buffer, it marks it as a candidate to be filled and finds a buffer which is currently full, marks it as being read from and then starts reading06:20
mithrowhen a write has finished filling a buffer, it finds the oldest buffer which isn't being read from and starts writing to it06:20
mithroImage your encoder ran at 1fps, while your reader ran at 5fps - with this system when you start encoding you always choose the most recent frame - effectively skipping the 4 frames06:21
mithroWith double buffering you have to wait for the writer to finish a frame before you can start the next frame06:21
mithrowhere as with triple buffering there is always a buffer ready to start reading from06:22
shenkiassuming your consumer is consuming at the same rate as the writer06:22
shenkibut yes06:22
mithroif the reader if faster then the writer, and the writer can't be "throttled", you end up repeating frames (with triple buffering)06:23
shenkiother way around06:24
shenkiour writer is faster than the read06:24
shenkiso you end up dropping frames06:24
shenkibut yes, i follow06:24
shenkiI don't understand what you are getting at though06:24
shenkioh, now i do06:25
shenkiwhen i said that the encoder was stalling06:25
shenkiit's never stalling on an entire frame06:25
shenkiit's stalling on a memory read06:25
shenkianyway, you don't need to convince me, you need to make sure tija is on the same page :P06:26
shenkitija: is what we're describing here agreeing with what you think the soltuion is?06:26
tijashenki: no encoder is stalling there is no frame to read from.06:26
shenkitija: in the current system, sure06:26
shenkitija: so do you think you would be better off chunking the frame into 16-line blocks06:27
tijamithro: the thing is that DDR unlike BRAM does not allow simultaneous read and write.06:27
shenkitija: or would it be easier to do multiple buffers06:27
shenkitija: you're right, but are there any buffers in between? does the MPMC do scheduling of read/writes?06:28
tijashenki: yes read and writes are sechduled06:29
mithrothe great thing about a triple-buffering structure is that it deals with any scenario the right way (a fast reader / slow writer, matched reader/writer, slower reader / faster writer)06:29
shenkitija: ok. so even though in practice you can't do reads and writes at the same time, in effect you can06:29
tijamithro: but if the reader is slow then there will be a time when the read buffer, the write buffer are both full.06:31
mithrotija: with triple buffering you just overwrite the oldest buffer06:31
mithrotija: which is effectively "dropping frames"06:32
shenkimithro: yeah, but what tija is saying is you're currently using the oldest buffer06:32
shenkithe reader is reading from it06:32
mithroshenki: ?06:32
shenkiso you end up with half of frame n, and half of frame n+306:32
mithroshenki: not with triple buffering06:32
tijashenki: yes I am reading from one buffer and the other two are full. then?06:33
shenkiconsider this:06:33
shenkifill buffer 106:33
shenkifill buffer 206:33
shenkifill buffer 306:33
shenkireader begins reading from buffer 106:33
shenkiwhat does the writer do now?06:33
shenkidoes it fill buffer 3?06:33
mithrolets consider the case without a reader at all06:33
mithroyou end up with a circular buffer06:34
shenkii think we both understand how the buffers get filled06:34
shenkiso it's a fifo06:34
mithrofill b1, fill b2, fill b306:34
mithroall good06:34
mithronow we add a reader06:34
mithrowith a simple circular buffer system, things go pair shaped like you suggest06:35
mithrobut with triple buffering, each buffer has a "read lock" and "write lock"06:35
mithroyou get this behaviour06:35
mithrogah, this is hard to do without proper diagram06:36
mithroactually scrub that06:36
shenkiis this what you were about to say:06:36
shenkifill buffer 106:37
shenkifill beffer 206:37
shenkifill buffer 306:37
shenkiread from buffer 106:37
shenkifill buffer 206:37
shenkifill buffer 306:37
shenkifill buffer 206:37
shenkiread buffer 306:37
mithroyou have already broken the concept :)06:37
mithroeach buffer has a "lock" and "age"06:37
shenkimithro: i think your world view is broken by the concept that the writer is faster than the reader06:37
mithrofor reading you always choose the buffer which is the youngest which isn't locked06:38
mithrofor writing you always choose the oldest buffer which isn't locked06:38
shenkiright. so how does that work differenly from what i just described?06:38
shenkioh, you read from buffer 306:38
mithrolet me do a diagram, the start/end points are important06:38
shenkinvm, i understand06:39
shenkithis is useful for v2 of tija's project06:39
tijaokay I got it06:39
shenkibut for v2, we can get a huge frame rate increase by removing the requirement that a single buffer is full before starting encoding06:39
mithrotriple buffering has a lot of great things, sadly memory consumption is not one of them :(06:40
shenkimithro: it's not so much the memory, we have bucket loads of that06:41
shenkimithro: it's the memory bandwith, given that we only have one reader or writer at a time06:41
mithrobut it is by far the best method when you require transferring "whole" blocks of data between consumer/writer which are different speeds and you can't throttle either06:42
tijamithro: yeah bandwith is a problem06:42
shenkii suspect that issue won't cripple us, just limit the extent to which a queue/buffer mechanism like you suggested will help06:42
mithro(or you care about latency)06:42
mithroshenki: s/"best"/only system which guarantees block integrity/06:43
mithrookay, I've broken my concentration on work - let me take a look at these DDR diagrams06:43
mithroI should be looking at ug388 right?06:43
tijamithro: yes page 1606:44
mithrodo we have a resolution / pixel bandwidth spreadsheet somewhere?06:45
shenkioh, our open source firmware for POWER8 just got published06:45
mithroshenki: \o/ - what is the "firmware" for?06:46
shenkimithro: it's the bit that sits between the really low level "make the processor go" and "bootloader"06:47
mithroJust -> ?06:47
tpb<$b> (at
shenkimithro: so in x86 land it's the same as coreboot06:47
mithroshenki: above my head I think :P06:49
*** slomo has joined #timvideos06:50
*** slomo has joined #timvideos06:50
shenkimithro: you would have heard of coreboot. it used to be called linuxBIOS06:50
shenkimithro: if nothing else, a certain online advertising company you are familiar with uses it on their servers06:50
mithroshenki: no comment06:51
tijamithro: comrpession ratio of 15 is not true. For 100% encoding quality, the output frame is greater than input :D.06:52
mithrotija: for JPEG?06:53
tijamithro: yes06:53
shenkiheh oops06:53
mithrotija: then raw RGB888 encoding?06:53
tijamithro: I guess this is because of RLE encoding step.
tpbTitle: Run-length encoding - Wikipedia, the free encyclopedia (at
tijaThis is the limitation of RLE without quantisation.06:55
mithroHow many bits are we using per pixel?06:55
tijaThat's why the frame rate is slow for 100% quality.06:55
tija24 bits06:55
shenkitoo many!06:55
shenkibut that's out of scope for tija, until we get these bigger issues sorted06:56
shenkionce we get the throughput fixed, we can switch to 4:2:006:56
mithroshenki: no, trying to understand the bandwidth requirement for writing / reading from RAM06:56
shenkitija: hang on, can we. does the jpeg encoder support input at 4:2:0? or is it just that it can output in that format?06:56
tijathe jpeg encoder takes RGB, converts it into YCrCb and then does 4:2:2 subsampling ie takes 16x8 blocks and converts it into 8x8 blocks06:57
tijaIn Cr and Cb, it takes every alternate sample06:58
mithroso, with our 16bit wide, DDR2 - the table on ug388 page 12 says we have a "peak bandwidth of 12.8 Gb/s" ?07:00
*** sarwarc_ has quit IRC07:06
mithrotija / shenki: you still here? I'm looking at the controller block diagram "Figure 1-1: Spartan-6 FPGA Memory Controller Block (IP Wrapper View)"07:11
mithroand it looks like you basically queue up a bunch of operations and then some time later you get the result?07:12
tijamithro: correct07:12
tijamithro: say you want to write from port 1 and port 2. you push the write cmd to respective command fifo. The arbiter decides what goes first and write the ports one by one07:14
mithrothe cmd is something like "read from address XXXX and put it in port X", "write data in port X to address XXXX" ?07:17
tijaeach port has its own cmd fifo07:19
mithroahh the arbiter is what decided which command is executed next07:25
mithrowhat is preventing you from loading a bunch of read commands into the first cmd fifo and a bunch of write commands into the second cmd fifo?07:26
mithrotija / shenki: what am I missing? there doesn't look to be any complexity with writing/reading from DDR at the same time?07:28
tijaEverytime a burst read is done, there should be 64 bytes in the data fifo, no more no less.07:29
mithrotija: that data comes out one of the MCB's ports right?07:30
mithrotija: the burst read is going to block the MCB for 64 bytes read, but you can still queue up write commands during that time right?07:32
tijamithro:yes, as long as bandwidth is not a problem we can read and write in same time using multiple ports07:34
mithrotija: we can also control the burst length right?07:34
tijamithro: yes07:34
mithrolonger bursts are better for performance, but worse for latency, right?07:35
tijamithro: but a higher burst length means more efficiency07:35
tijamithro: yes07:35
mithrotija: okay, so my next question is - do you know where we find the *actual* bandwidth to/from the DDD2?07:36
mithrotija: IE if we where to write at 1 byte at a time, how fast can we write?07:37
tijamithro: page 58?07:38
mithroYou mean - Table 4-4: MCB Read Latency ?07:38
mithrothat is latency rather than bandwidth07:38
tijamithro: oh sorry,not sure then07:41
tijamithro: going for lunch. brb in 20 mins07:44
mithroJoelw: ping?07:53
Joelwmithro: Hi!08:06
mithro <- :P08:06
tpbTitle: Xilinx MIG Tutorial | Joel's Compendium of Total Knowledge (at
JoelwLooks legit!08:07
mithroJoelw: did you ever find out about how fast you could push data to/from the RAM on the Atlys?08:07
JoelwNo, never tried!08:07
JoelwI think someone on the Xilinx forum did some extensive tests to work out the best way to do it though08:07
tpbTitle: Spartan 6 MCB Performance - Xilinx User Community Forums (at
JoelwClassy bonus - it's about video08:09
mithroJoelw: yeah08:13
shenkimithro: some dude wrote an report on it a few years ago:
shenkithat is looking at using a PLB though. im not sure what we use in our design08:15
tpbTitle: Graphics Resolutions and Bandwidth - Google Tabellen (at
mithroshenki: fail you straight away for not having a table of contents :P08:18
shenkiif you use a real pdf reader, it has an index08:18
shenkimithro: you want page 15 onwards, where it talks about the benchmarks08:19
shenki6.4 PLB attached SDRAM08:19
shenkito answer your question about "how if we write 1 byte at a time, how fast can we write": slow08:20
shenkibut if you write a word at at time, it goes faster08:20
mithroshenki: I don't care about latency, I care about *bandwidth*?08:20
shenkibandwidth depends. if you're doing one byte accesses, you can do latency*time byes per time interval08:21
mithroshenki: you are assuming a non-pipelined system there08:22
shenkithat's why you can't find numbers, except for the extreme theoretical throughput of the physcial interface (the pin wiggling speed)08:23
shenkimithro: nah, it's not really. it's the average of 50 accesses08:24
shenkimithro: so you kinda get benefits of things being batched by the DDR controller08:24
mithroshenki: with DDR, it seems the latency depends on a whole bunch of things like if you are reading from sequential addresses?08:26
shenkiwell, kinda08:30
shenkinot in the same way as on a pc08:30
shenkiwhere you have associtave caches, so linear accesses result in better cache locality08:31
mithroshenki: say I want to read byte 0, byte 1, byte 3 - that seems to be faster than reading byte 3, byte 199, byte 008:32
shenkiwell, that's a bad example, as your first 4 bytes will be in the same word08:33
shenkibut yeah, reading from address 0, 4 and 8 will probably be quicker than reading from address 0, 40000 and 800000008:33
shenkicoz physics08:34
shenkiddr throughput isn't our issue, the problem we need to sovle is making sure the jpeg encoder is running at maximum utilisation08:35
shenkithat will be the biggest speed gain08:36
shenkithen we look at making sure data is delivered faster (dma to prefetch?), and frames are buffered so we lose fewer, etc08:36
mithroI'm not 100% sure that DDR throughput isn't an issue if we do triple buffering08:52
mithro1920x1080 x 32bits @ 60Hz is 498Megabits/s08:53
mithroand if doing interleave reads/writes drops the bandwidth down to 200Megabits/s that is a serious issue09:00
*** rohitksingh has joined #timvideos10:25
*** rohitksingh has quit IRC11:17
*** FeltonChris_ has joined #timvideos11:55
*** rohitksingh has joined #timvideos12:19
*** FeltonChris_ has quit IRC12:29
*** FeltonChris_ has joined #timvideos12:30
*** goober has joined #timvideos12:30
*** FeltonChris_ has quit IRC12:30
*** goober is now known as Guest7247412:31
*** FeltonChris_ has joined #timvideos13:03
rohitksinghtija: ping13:29
rohitksinghJoelw: ping13:39
rohitksinghshenki / mithro: ping13:43
*** gurudev has joined #timvideos13:46
gurudevi tried hdmi2usb on my atlys board 2-3 months back13:47
gurudevat that time it was giving very low frame rate13:48
gurudevi was wondering have you guys fixed that13:48
rohitksinghgurudev: Hi! tija is working on improving frame rate this summer13:50
gurudevokay gsoc?13:52
gurudevtija == ajit?13:53
rohitksinghyes! :)13:55
gurudevtija: any success?13:55
*** rohitksingh has quit IRC14:05
shenkigurudev: if you're interested in the details, you can have a read of his mid-project report14:07
tpbTitle: Mid Term Report - Google Docs (at
shenkiin summary: the work to make the improvements is just starting, to date we've spent time identifying the issue14:08
gurudevshenki: i was planing to work on the same issue14:09
gurudevbut i cant afford to switch to linux at the moment14:09
gurudevis there anything which cant be done on windows?14:10
shenkii imagine you could use windows14:10
gurudevearlier i could not find windows based utility to load the cypress chip14:11
shenkiah interesting14:11
shenkii imagine such a thing would exist14:12
gurudevokay let me try i will ask if i get stuck at some point14:13
*** rohitksingh has joined #timvideos14:30
rohitksinghtija: kindly see this PLL of DDR module
tpbTitle: Screenshot from 2014-07-02 19:07:06.png - Google Drive (at
rohitksinghtija: and these are its settings
tpbTitle: Screenshot from 2014-07-02 19:12:38.png - Google Drive (at
rohitksinghtija: Now, the CLKIN1 is 10ns == 100MHz clock, so am i correct in stating that the clkout2's frequency is (100*25)/(8*4) ie 78.125MHz?14:59
tijarohitksingh: yes it is 78 Mhz14:59
rohitksinghtija: okay many thanks! :) its the img_clk which is used everywhere else. So, I needed to confirm15:00
tijarohitksingh: yes this is the img_clk.15:01
rohitksinghtija: thanks so much!15:01
*** rohitksingh has quit IRC17:07
*** rohitksingh has joined #timvideos17:54
*** tariq786 has quit IRC18:31
*** tariq786 has joined #timvideos18:34
*** rohitksingh has quit IRC20:02
*** slomo_ has joined #timvideos20:06
*** slomo has quit IRC20:09
*** slomo__ has joined #timvideos20:13
*** slomo_ has quit IRC20:16
*** rohitksingh has joined #timvideos20:27
*** mparuszewski has joined #timvideos20:33
*** CarlFK has quit IRC20:34
*** slomo__ has quit IRC21:18
*** CarlFK has joined #timvideos21:20
*** ChanServ sets mode: +v CarlFK21:20
*** tija has quit IRC22:23
*** mparuszewski has quit IRC23:32
*** rohitksingh has quit IRC23:42

Generated by 2.12.1 by Marius Gedminas - find it at!