| *** tpb has joined #timvideos | 00:00 | |
| *** rohitksingh has quit IRC | 00:58 | |
| shenki | pusher? http://babyology.com.au/wp-content/uploads/2012/07/lowresimage00039.jpg | 01:28 |
|---|---|---|
| mithro | CARAM_: sure? | 03:16 |
| mithro | shenki: I think thats very Australian :P | 03:16 |
| mithro | ayush3504: ping? | 03:21 |
| ayush3504 | mithro: pong | 03:21 |
| mithro | ayush3504: why are the slot hierarchical pins passive? | 03:21 |
| ayush3504 | mithro: they're neither input or output, i could choose tristate or passive | 03:22 |
| mithro | okay, so you should understand the different types of wires | 03:23 |
| mithro | s/wires/"ports"/ | 03:23 |
| ayush3504 | mithro: passive is more flexible, that's why i chose it | 03:23 |
| ayush3504 | mithro: from the isolator's side the pins shouldn't be tristate | 03:24 |
| mithro | Passive == Analog / Power / etc - Should never be used by a digital pins | 03:24 |
| ayush3504 | mithro: ok, then tristate? | 03:24 |
| mithro | Digital pins should *always* be one of, In, Out, Bidirectional, Tri-State | 03:24 |
| ayush3504 | mithro: ok | 03:24 |
| mithro | In and Out should be pretty clear | 03:24 |
| mithro | Bidirectional means that the signal can be in or out. | 03:25 |
| ayush3504 | mithro: but the bus can't be in or out right, so i'm left with tristate | 03:25 |
| ayush3504 | mithro: and bidirectional | 03:25 |
| *** sarwarc has joined #timvideos | 03:25 | |
| mithro | Tri-state means that the signal can be "In", "Out" or "High Impedance" | 03:25 |
| ayush3504 | mithro: yes, the fpga and pic18 supports that, but the middle block doesnt | 03:26 |
| ayush3504 | mithro: how about bidirectional? | 03:26 |
| mithro | Well, the outputs from the PIC / VHDCI should definitely be tristate | 03:27 |
| ayush3504 | mithro: ok, i've done made the middle one bidi and the pic18 and vhdci pins tristate | 03:28 |
| mithro | ayush3504: okay - I think that makes sense | 03:29 |
| mithro | the tri-state stuff is important as it allows the PIC and the FPGA to both be connected to the same wires | 03:30 |
| ayush3504 | mithro: got it | 03:33 |
| mithro | ayush3504: connecting two out pins together should cause a DRC error | 03:33 |
| ayush3504 | mithro: yes it should case, but it seems ERC doesn't check hierarchical pins | 03:34 |
| ayush3504 | cause | 03:34 |
| mithro | You can test by making the PIC and VHDCI both as output and do the check | 03:35 |
| mithro | Wow, digital isolators are expensive.... | 03:36 |
| ayush3504 | mithro: tried, did not show an error | 03:36 |
| ayush3504 | mithro: i think hierarchical pin type is just for the symbols | 03:37 |
| mithro | ayush3504: interesting | 03:39 |
| mithro | ayush3504: I'm trying to remember the justification for the data-isolation from motherboard to the daughterboard | 03:45 |
| ayush3504 | mithro: ground loops, protecting fpga | 03:45 |
| mithro | ayush3504: but most serial drivers have inbuilt isolation? | 03:45 |
| ayush3504 | mithro: not most | 03:46 |
| ayush3504 | mithro: the ones which have cost extra 2$ | 03:46 |
| ayush3504 | mithro: they start from $4 | 03:46 |
| mithro | ISL32433E <-- for the RS422 that is isolated right? | 03:47 |
| ayush3504 | mithro: no, we aren't using this, we're using the pin compativle ISL8491E | 03:48 |
| mithro | the ISL8491E isn't isolated? | 03:48 |
| ayush3504 | mithro: ISL32433E is more robust for ESD and overvoltages, and supports 3.3V | 03:48 |
| ayush3504 | mithro: none of them | 03:48 |
| mithro | ayush3504: it just has ESD protection rather than isolation | 03:49 |
| ayush3504 | mithro: so i'm leaving an option to use ISL32433E ($3.68) or ISL8491E ($0.97) | 03:49 |
| ayush3504 | mithro: and 3.3V support | 03:50 |
| ayush3504 | mithro: if any one needs 3.3V then ISL324... can be used otherwise ISL8491 works good as well | 03:50 |
| ayush3504 | mithro: both are pin compatible | 03:50 |
| mithro | ayush3504: it looks like with IO isolation we are stuck with exactly the serial interface rather then it being general | 04:00 |
| ayush3504 | mithro: yes, but this is serial expansion board right? we can't be general beyond that :p | 04:02 |
| mithro | ayush3504: sure, but I was hoping to cover GPIO at the same time | 04:04 |
| ayush3504 | mithro: yeah, the workaround for that is having a micro in daughterboards | 04:05 |
| mithro | yeah | 04:07 |
| mithro | ayush3504: I guess continue that way for now then | 04:12 |
| ayush3504 | mithro: ok | 04:12 |
| mithro | ayush3504: how are the PCBs going? | 04:18 |
| ayush3504 | mithro: had to ask one thing, should I lay out components on the slot area? | 04:19 |
| ayush3504 | mithro: like the isolator chips | 04:20 |
| mithro | ayush3504: you want to be able to "drop" the PCB from a daughterboard into the slot area | 04:20 |
| ayush3504 | mithro: oh okay | 04:20 |
| ayush3504 | mithro: i'm solving a few issues, should begin with cvpcb in a couple hours. | 04:21 |
| ayush3504 | mithro: hopefully I'll be able to give a preview in a snippet post this evening | 04:27 |
| shenki | tija: hello | 04:37 |
| tija | shenki: Hi | 04:37 |
| shenki | tija: hey! hows things? | 04:38 |
| tija | shenki: the report is almost done.After that I will study about DDR | 04:38 |
| shenki | tija: cool. are you doing the report in google docs? | 04:39 |
| tija | shenki: yes | 04:39 |
| shenki | tija: feel free to paste the link in here, even if it isn't done | 04:39 |
| shenki | tija: did you speak with mithro about a time for a vc? | 04:39 |
| tija | shenki: no I haven't | 04:40 |
| shenki | he's a busy man, you should get onto that asap | 04:40 |
| tija | shenki: 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 |
| shenki | hah. yeah, we can spin it up | 04:43 |
| shenki | what is the night time temp where you live? | 04:43 |
| tija | +30 C | 04:43 |
| shenki | yeah, you don't really need a heater then | 04:43 |
| shenki | tija: are you familiar with using ssh? | 04:44 |
| tija | My laptop is working good in an air conditioned environment. But I can't be always in AC, it is expensive. | 04:44 |
| tija | shenki: ssh yes! | 04:44 |
| shenki | tija: cool. can you please send me your pubkey so i can give you access? | 04:45 |
| tija | shenki: okay | 04:49 |
| shenki | tija: are you sending it now? | 04:59 |
| shenki | the VM is running, and we pay for it by the hour | 04:59 |
| tija | okay I need to switch to ubuntu. | 05:07 |
| tija | shenki: sorry | 05:08 |
| tija | shenki: but I currently don't have any use. | 05:08 |
| shenki | tija: you don't need it for now? | 05:09 |
| shenki | tija: you can use ssh from windows :) | 05:09 |
| shenki | i'll shut it down then | 05:09 |
| tija | shenki: yeah I managed yesterday by switching between windows and ubuntu. | 05:10 |
| shenki | ok | 05:10 |
| *** sarwarc_ has joined #timvideos | 05:20 | |
| tija | Mid term report: https://docs.google.com/document/d/1YwD7ZuVogUXlRbBu8hCpQkHv_tboYZGei7_H4wEErDg/edit# | 05:22 |
| tpb | Title: Google Docs - create and edit documents online, for free. (at docs.google.com) | 05:22 |
| *** sarwarc has quit IRC | 05:23 | |
| mithro | shenki: when you get a moment I wanted to continue chatting with you about DDR? Would a normal DDR controller look something like -> http://www.altera.com.cn/products/ip/images/nwestlogic-diagram-pop.pdf ? | 05:42 |
| mithro | http://www.altera.com/products/ip/iup/images/m-nwl-ddr2-sdram-diagram.jpg | 05:43 |
| shenki | mithro: yeah, im in the middle of stuff thisafternoon. can chat thisevening | 05:47 |
| mithro | shenki: okay | 05:47 |
| shenki | tija: you have studied the DDR a bit. Do the links mithro pasted describe the DDR and controller in our system | 05:48 |
| shenki | mithro: i think the answer is "yes" | 05:48 |
| shenki | mithro: did you see tija's report ^ | 05:48 |
| mithro | haven't had a chance to read it yet | 05:48 |
| tija | mithro: The one used in our system is this one http://www.xilinx.com/support/documentation/ip_documentation/mig/v3_8/ug416.pdf | 05:51 |
| shenki | tija: what is the transfer size between the jpeg core and the DDR? | 05:55 |
| tija | shenki: 24 bits | 05:56 |
| tija | mithro: sorry, this is the real thing http://www.xilinx.com/support/documentation/user_guides/ug388.pdf | 05:56 |
| tija | mithro: on Page 16 you can see the architechture | 05:57 |
| shenki | tija: have you considered doing larger transfers? | 05:58 |
| tija | shenki: larger transfer won't change the encoding time | 06:01 |
| shenki | right, because all that we would do would have the jpeg core sitting there idle for longer? | 06:07 |
| tija | shenki: 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 |
| shenki | right | 06:10 |
| shenki | tija: and can we do that by feeding the jpeg core every 16-lines, instead of every frame? | 06:11 |
| mithro | just a random comment - we should think of this as a pipeline with leaky buffers in between | 06:11 |
| shenki | tija: do you know how the RLE time compares to the amount of time to encode one 16 line chunk? | 06:11 |
| shenki | s/encode/write from hdmi to DDR/ | 06:12 |
| shenki | mithro: what is the pipeline in your analogy? | 06:12 |
| shenki | mithro: we should think of it as a CPU pipeline with bubbles due to memory salls | 06:12 |
| shenki | mithro: becase that's exactly what it is ;) | 06:13 |
| mithro | shenki: IE, the HDMI interface produces frames and stuffs them into a buffer | 06:13 |
| mithro | shenki: the encoder takes a frame from the buffer and does encoding for it and stuffs it into a buffer for the usb to send | 06:14 |
| mithro | shenki: then the usb takes the frame and sends it out | 06:14 |
| shenki | right. 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 frame | 06:14 |
| shenki | alternativly, you could have many buffers in the DDR | 06:14 |
| shenki | that would increase latency by some percentage of one frame | 06:15 |
| mithro | shenki: no, currently the HDMI interfaces takes a frame puts it into the buffer then stops | 06:15 |
| shenki | it might be a simpler solution, however you will always be bound by the jpeg core speed for an entire frame | 06:15 |
| mithro | shenki: it should keep putting stuff into buffers, using something like a double/triple buffering type system | 06:15 |
| shenki | 15:44 <+shenki> alternativly, you could have many buffers in the DDR | 06:15 |
| shenki | :) | 06:16 |
| tija | shenki: 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 fps | 06:16 |
| mithro | shenki: buffers also should never cause a stall | 06:16 |
| mithro | shenki: you should just update the information | 06:16 |
| shenki | mithro: explain what you mean | 06:17 |
| mithro | so, we have clear "units" of information right | 06:18 |
| mithro | a single frame | 06:18 |
| shenki | tija: yeah, that's one way to solve it | 06:18 |
| shenki | tija: it's what mithro is describing | 06:18 |
| mithro | If you have triple buffering | 06:18 |
| mithro | you always have | 06:18 |
| mithro | a buffer your currently filling | 06:18 |
| mithro | a buffer that is currently ready to be read from | 06:19 |
| mithro | a buffer that you are currently reading from | 06:19 |
| shenki | yep | 06:20 |
| mithro | when 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 reading | 06:20 |
| mithro | when a write has finished filling a buffer, it finds the oldest buffer which isn't being read from and starts writing to it | 06:20 |
| shenki | yes | 06:21 |
| mithro | Image 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 frames | 06:21 |
| mithro | With double buffering you have to wait for the writer to finish a frame before you can start the next frame | 06:21 |
| mithro | where as with triple buffering there is always a buffer ready to start reading from | 06:22 |
| shenki | assuming your consumer is consuming at the same rate as the writer | 06:22 |
| shenki | but yes | 06:22 |
| mithro | if the reader if faster then the writer, and the writer can't be "throttled", you end up repeating frames (with triple buffering) | 06:23 |
| shenki | other way around | 06:24 |
| shenki | our writer is faster than the read | 06:24 |
| shenki | so you end up dropping frames | 06:24 |
| shenki | but yes, i follow | 06:24 |
| shenki | I don't understand what you are getting at though | 06:24 |
| shenki | oh, now i do | 06:25 |
| shenki | when i said that the encoder was stalling | 06:25 |
| shenki | it's never stalling on an entire frame | 06:25 |
| shenki | it's stalling on a memory read | 06:25 |
| shenki | anyway, you don't need to convince me, you need to make sure tija is on the same page :P | 06:26 |
| shenki | tija: is what we're describing here agreeing with what you think the soltuion is? | 06:26 |
| tija | shenki: no encoder is stalling there is no frame to read from. | 06:26 |
| shenki | tija: in the current system, sure | 06:26 |
| shenki | tija: so do you think you would be better off chunking the frame into 16-line blocks | 06:27 |
| tija | mithro: the thing is that DDR unlike BRAM does not allow simultaneous read and write. | 06:27 |
| shenki | tija: or would it be easier to do multiple buffers | 06:27 |
| shenki | tija: you're right, but are there any buffers in between? does the MPMC do scheduling of read/writes? | 06:28 |
| tija | shenki: yes read and writes are sechduled | 06:29 |
| mithro | the 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 |
| shenki | tija: ok. so even though in practice you can't do reads and writes at the same time, in effect you can | 06:29 |
| tija | mithro: but if the reader is slow then there will be a time when the read buffer, the write buffer are both full. | 06:31 |
| mithro | tija: with triple buffering you just overwrite the oldest buffer | 06:31 |
| mithro | tija: which is effectively "dropping frames" | 06:32 |
| shenki | mithro: yeah, but what tija is saying is you're currently using the oldest buffer | 06:32 |
| shenki | the reader is reading from it | 06:32 |
| mithro | shenki: ? | 06:32 |
| shenki | so you end up with half of frame n, and half of frame n+3 | 06:32 |
| mithro | shenki: not with triple buffering | 06:32 |
| tija | shenki: yes I am reading from one buffer and the other two are full. then? | 06:33 |
| shenki | consider this: | 06:33 |
| shenki | fill buffer 1 | 06:33 |
| shenki | fill buffer 2 | 06:33 |
| shenki | fill buffer 3 | 06:33 |
| shenki | reader begins reading from buffer 1 | 06:33 |
| mithro | no! | 06:33 |
| shenki | what does the writer do now? | 06:33 |
| shenki | does it fill buffer 3? | 06:33 |
| mithro | lets consider the case without a reader at all | 06:33 |
| mithro | you end up with a circular buffer | 06:34 |
| shenki | i think we both understand how the buffers get filled | 06:34 |
| shenki | so it's a fifo | 06:34 |
| mithro | fill b1, fill b2, fill b3 | 06:34 |
| mithro | all good | 06:34 |
| mithro | now we add a reader | 06:34 |
| mithro | with a simple circular buffer system, things go pair shaped like you suggest | 06:35 |
| mithro | but with triple buffering, each buffer has a "read lock" and "write lock" | 06:35 |
| mithro | so | 06:35 |
| mithro | you get this behaviour | 06:35 |
| mithro | gah, this is hard to do without proper diagram | 06:36 |
| mithro | actually scrub that | 06:36 |
| shenki | is this what you were about to say: | 06:36 |
| shenki | fill buffer 1 | 06:37 |
| shenki | fill beffer 2 | 06:37 |
| shenki | fill buffer 3 | 06:37 |
| shenki | read from buffer 1 | 06:37 |
| shenki | fill buffer 2 | 06:37 |
| shenki | fill buffer 3 | 06:37 |
| shenki | fill buffer 2 | 06:37 |
| mithro | nope | 06:37 |
| shenki | read buffer 3 | 06:37 |
| mithro | you have already broken the concept :) | 06:37 |
| mithro | each buffer has a "lock" and "age" | 06:37 |
| shenki | mithro: i think your world view is broken by the concept that the writer is faster than the reader | 06:37 |
| mithro | for reading you always choose the buffer which is the youngest which isn't locked | 06:38 |
| mithro | for writing you always choose the oldest buffer which isn't locked | 06:38 |
| shenki | right. so how does that work differenly from what i just described? | 06:38 |
| shenki | oh, you read from buffer 3 | 06:38 |
| mithro | let me do a diagram, the start/end points are important | 06:38 |
| shenki | nvm, i understand | 06:39 |
| shenki | this is useful for v2 of tija's project | 06:39 |
| tija | okay I got it | 06:39 |
| shenki | but for v2, we can get a huge frame rate increase by removing the requirement that a single buffer is full before starting encoding | 06:39 |
| mithro | triple buffering has a lot of great things, sadly memory consumption is not one of them :( | 06:40 |
| shenki | mithro: it's not so much the memory, we have bucket loads of that | 06:41 |
| shenki | mithro: it's the memory bandwith, given that we only have one reader or writer at a time | 06:41 |
| mithro | but 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 either | 06:42 |
| tija | mithro: yeah bandwith is a problem | 06:42 |
| shenki | i suspect that issue won't cripple us, just limit the extent to which a queue/buffer mechanism like you suggested will help | 06:42 |
| mithro | (or you care about latency) | 06:42 |
| shenki | "best"? | 06:42 |
| shenki | ; | 06:42 |
| shenki | :) | 06:42 |
| mithro | shenki: s/"best"/only system which guarantees block integrity/ | 06:43 |
| mithro | okay, I've broken my concentration on work - let me take a look at these DDR diagrams | 06:43 |
| mithro | I should be looking at ug388 right? | 06:43 |
| tija | mithro: yes page 16 | 06:44 |
| mithro | do we have a resolution / pixel bandwidth spreadsheet somewhere? | 06:45 |
| shenki | oh, our open source firmware for POWER8 just got published | 06:45 |
| mithro | shenki: \o/ - what is the "firmware" for? | 06:46 |
| shenki | mithro: it's the bit that sits between the really low level "make the processor go" and "bootloader" | 06:47 |
| mithro | Just -> https://github.com/timvideos/HDMI2USB/wiki/Resolutions ? | 06:47 |
| tpb | <http://ln-s.net/-k$b> (at github.com) | 06:47 |
| shenki | mithro: so in x86 land it's the same as coreboot | 06:47 |
| mithro | shenki: above my head I think :P | 06:49 |
| *** slomo has joined #timvideos | 06:50 | |
| *** slomo has joined #timvideos | 06:50 | |
| shenki | mithro: you would have heard of coreboot. it used to be called linuxBIOS | 06:50 |
| shenki | mithro: if nothing else, a certain online advertising company you are familiar with uses it on their servers | 06:50 |
| mithro | shenki: no comment | 06:51 |
| shenki | :) | 06:51 |
| tija | mithro: comrpession ratio of 15 is not true. For 100% encoding quality, the output frame is greater than input :D. | 06:52 |
| mithro | tija: for JPEG? | 06:53 |
| tija | mithro: yes | 06:53 |
| shenki | heh oops | 06:53 |
| mithro | tija: then raw RGB888 encoding? | 06:53 |
| tija | mithro: I guess this is because of RLE encoding step. http://en.wikipedia.org/wiki/Run-length_encoding | 06:54 |
| tpb | Title: Run-length encoding - Wikipedia, the free encyclopedia (at en.wikipedia.org) | 06:54 |
| tija | This is the limitation of RLE without quantisation. | 06:55 |
| mithro | How many bits are we using per pixel? | 06:55 |
| tija | That's why the frame rate is slow for 100% quality. | 06:55 |
| tija | 24 bits | 06:55 |
| shenki | too many! | 06:55 |
| shenki | but that's out of scope for tija, until we get these bigger issues sorted | 06:56 |
| shenki | once we get the throughput fixed, we can switch to 4:2:0 | 06:56 |
| mithro | shenki: no, trying to understand the bandwidth requirement for writing / reading from RAM | 06:56 |
| shenki | tija: 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 |
| tija | the jpeg encoder takes RGB, converts it into YCrCb and then does 4:2:2 subsampling ie takes 16x8 blocks and converts it into 8x8 blocks | 06:57 |
| tija | In Cr and Cb, it takes every alternate sample | 06:58 |
| mithro | so, 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 IRC | 07:06 | |
| mithro | tija / 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 |
| mithro | and it looks like you basically queue up a bunch of operations and then some time later you get the result? | 07:12 |
| tija | mithro: correct | 07:12 |
| tija | mithro: 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 one | 07:14 |
| mithro | the cmd is something like "read from address XXXX and put it in port X", "write data in port X to address XXXX" ? | 07:17 |
| tija | each port has its own cmd fifo | 07:19 |
| mithro | okay | 07:24 |
| mithro | ahh the arbiter is what decided which command is executed next | 07:25 |
| mithro | what 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 |
| mithro | tija / shenki: what am I missing? there doesn't look to be any complexity with writing/reading from DDR at the same time? | 07:28 |
| tija | Everytime a burst read is done, there should be 64 bytes in the data fifo, no more no less. | 07:29 |
| mithro | tija: that data comes out one of the MCB's ports right? | 07:30 |
| tija | yes | 07:30 |
| mithro | tija: 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 |
| tija | mithro:yes, as long as bandwidth is not a problem we can read and write in same time using multiple ports | 07:34 |
| mithro | tija: we can also control the burst length right? | 07:34 |
| tija | mithro: yes | 07:34 |
| mithro | longer bursts are better for performance, but worse for latency, right? | 07:35 |
| tija | mithro: but a higher burst length means more efficiency | 07:35 |
| tija | mithro: yes | 07:35 |
| mithro | tija: okay, so my next question is - do you know where we find the *actual* bandwidth to/from the DDD2? | 07:36 |
| mithro | tija: IE if we where to write at 1 byte at a time, how fast can we write? | 07:37 |
| tija | mithro: page 58? | 07:38 |
| mithro | You mean - Table 4-4: MCB Read Latency ? | 07:38 |
| mithro | that is latency rather than bandwidth | 07:38 |
| tija | mithro: oh sorry,not sure then | 07:41 |
| tija | mithro: going for lunch. brb in 20 mins | 07:44 |
| mithro | Joelw: ping? | 07:53 |
| Joelw | mithro: Hi! | 08:06 |
| mithro | http://www.joelw.id.au/FPGA/XilinxMIGTutorial <- :P | 08:06 |
| tpb | Title: Xilinx MIG Tutorial | Joel's Compendium of Total Knowledge (at www.joelw.id.au) | 08:06 |
| Joelw | Looks legit! | 08:07 |
| mithro | Joelw: did you ever find out about how fast you could push data to/from the RAM on the Atlys? | 08:07 |
| Joelw | No, never tried! | 08:07 |
| Joelw | I think someone on the Xilinx forum did some extensive tests to work out the best way to do it though | 08:07 |
| Joelw | http://forums.xilinx.com/t5/Spartan-Family-FPGAs/Spartan-6-MCB-Performance/td-p/244006 | 08:09 |
| tpb | Title: Spartan 6 MCB Performance - Xilinx User Community Forums (at forums.xilinx.com) | 08:09 |
| Joelw | Classy bonus - it's about video | 08:09 |
| mithro | Joelw: yeah | 08:13 |
| shenki | mithro: some dude wrote an report on it a few years ago: jms.id.au/~joel/final_report.pdf | 08:13 |
| shenki | that is looking at using a PLB though. im not sure what we use in our design | 08:15 |
| mithro | https://docs.google.com/a/mithis.com/spreadsheets/d/1JvBYgGgWN35BF30zXw76Jp7c4_SLcykoOMWNcuDTUv4/edit#gid=720646227 | 08:17 |
| tpb | Title: Graphics Resolutions and Bandwidth - Google Tabellen (at docs.google.com) | 08:17 |
| mithro | shenki: fail you straight away for not having a table of contents :P | 08:18 |
| shenki | if you use a real pdf reader, it has an index | 08:18 |
| shenki | mithro: you want page 15 onwards, where it talks about the benchmarks | 08:19 |
| shenki | 6.4 PLB attached SDRAM | 08:19 |
| shenki | to answer your question about "how if we write 1 byte at a time, how fast can we write": slow | 08:20 |
| shenki | but if you write a word at at time, it goes faster | 08:20 |
| mithro | shenki: I don't care about latency, I care about *bandwidth*? | 08:20 |
| shenki | bandwidth depends. if you're doing one byte accesses, you can do latency*time byes per time interval | 08:21 |
| mithro | shenki: you are assuming a non-pipelined system there | 08:22 |
| shenki | that's why you can't find numbers, except for the extreme theoretical throughput of the physcial interface (the pin wiggling speed) | 08:23 |
| shenki | mithro: nah, it's not really. it's the average of 50 accesses | 08:24 |
| shenki | mithro: so you kinda get benefits of things being batched by the DDR controller | 08:24 |
| mithro | shenki: with DDR, it seems the latency depends on a whole bunch of things like if you are reading from sequential addresses? | 08:26 |
| shenki | yeah | 08:29 |
| shenki | well, kinda | 08:30 |
| shenki | not in the same way as on a pc | 08:30 |
| shenki | where you have associtave caches, so linear accesses result in better cache locality | 08:31 |
| mithro | shenki: say I want to read byte 0, byte 1, byte 3 - that seems to be faster than reading byte 3, byte 199, byte 0 | 08:32 |
| shenki | well, that's a bad example, as your first 4 bytes will be in the same word | 08:33 |
| shenki | but yeah, reading from address 0, 4 and 8 will probably be quicker than reading from address 0, 40000 and 8000000 | 08:33 |
| shenki | coz physics | 08:34 |
| shenki | ddr throughput isn't our issue, the problem we need to sovle is making sure the jpeg encoder is running at maximum utilisation | 08:35 |
| shenki | that will be the biggest speed gain | 08:36 |
| shenki | then we look at making sure data is delivered faster (dma to prefetch?), and frames are buffered so we lose fewer, etc | 08:36 |
| mithro | I'm not 100% sure that DDR throughput isn't an issue if we do triple buffering | 08:52 |
| mithro | 1920x1080 x 32bits @ 60Hz is 498Megabits/s | 08:53 |
| mithro | and if doing interleave reads/writes drops the bandwidth down to 200Megabits/s that is a serious issue | 09:00 |
| *** rohitksingh has joined #timvideos | 10:25 | |
| *** rohitksingh has quit IRC | 11:17 | |
| *** FeltonChris_ has joined #timvideos | 11:55 | |
| *** rohitksingh has joined #timvideos | 12:19 | |
| *** FeltonChris_ has quit IRC | 12:29 | |
| *** FeltonChris_ has joined #timvideos | 12:30 | |
| *** goober has joined #timvideos | 12:30 | |
| *** FeltonChris_ has quit IRC | 12:30 | |
| *** goober is now known as Guest72474 | 12:31 | |
| *** FeltonChris_ has joined #timvideos | 13:03 | |
| rohitksingh | tija: ping | 13:29 |
| rohitksingh | Joelw: ping | 13:39 |
| rohitksingh | shenki / mithro: ping | 13:43 |
| *** gurudev has joined #timvideos | 13:46 | |
| gurudev | hi | 13:46 |
| gurudev | i tried hdmi2usb on my atlys board 2-3 months back | 13:47 |
| gurudev | at that time it was giving very low frame rate | 13:48 |
| gurudev | i was wondering have you guys fixed that | 13:48 |
| rohitksingh | gurudev: Hi! tija is working on improving frame rate this summer | 13:50 |
| gurudev | okay gsoc? | 13:52 |
| rohitksingh | yeah! | 13:52 |
| gurudev | tija == ajit? | 13:53 |
| rohitksingh | yes! :) | 13:55 |
| gurudev | tija: any success? | 13:55 |
| *** rohitksingh has quit IRC | 14:05 | |
| shenki | gurudev: if you're interested in the details, you can have a read of his mid-project report | 14:07 |
| shenki | gurudev: https://docs.google.com/document/d/1YwD7ZuVogUXlRbBu8hCpQkHv_tboYZGei7_H4wEErDg/edit# | 14:07 |
| tpb | Title: Mid Term Report - Google Docs (at docs.google.com) | 14:07 |
| shenki | in summary: the work to make the improvements is just starting, to date we've spent time identifying the issue | 14:08 |
| gurudev | shenki: i was planing to work on the same issue | 14:09 |
| gurudev | but i cant afford to switch to linux at the moment | 14:09 |
| gurudev | is there anything which cant be done on windows? | 14:10 |
| shenki | i imagine you could use windows | 14:10 |
| gurudev | earlier i could not find windows based utility to load the cypress chip | 14:11 |
| shenki | ah interesting | 14:11 |
| shenki | i imagine such a thing would exist | 14:12 |
| gurudev | okay let me try i will ask if i get stuck at some point | 14:13 |
| *** rohitksingh has joined #timvideos | 14:30 | |
| tija | rohitksingh:pong | 14:54 |
| rohitksingh | tija: kindly see this PLL of DDR module https://drive.google.com/file/d/0B7Sp1NskALPdVG5ZRU5ONF9ySDQ/edit?usp=sharing | 14:55 |
| tpb | Title: Screenshot from 2014-07-02 19:07:06.png - Google Drive (at drive.google.com) | 14:55 |
| rohitksingh | tija: and these are its settings https://drive.google.com/file/d/0B7Sp1NskALPdVDRBbU9IcmV4MFU/edit?usp=sharing | 14:56 |
| tpb | Title: Screenshot from 2014-07-02 19:12:38.png - Google Drive (at drive.google.com) | 14:56 |
| tija | rohitksingh: okay.so? | 14:57 |
| rohitksingh | tija: 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 |
| tija | rohitksingh: yes it is 78 Mhz | 14:59 |
| rohitksingh | tija: okay many thanks! :) its the img_clk which is used everywhere else. So, I needed to confirm | 15:00 |
| tija | rohitksingh: yes this is the img_clk. | 15:01 |
| rohitksingh | tija: thanks so much! | 15:01 |
| *** rohitksingh has quit IRC | 17:07 | |
| *** rohitksingh has joined #timvideos | 17:54 | |
| *** tariq786 has quit IRC | 18:31 | |
| *** tariq786 has joined #timvideos | 18:34 | |
| *** rohitksingh has quit IRC | 20:02 | |
| *** slomo_ has joined #timvideos | 20:06 | |
| *** slomo has quit IRC | 20:09 | |
| *** slomo__ has joined #timvideos | 20:13 | |
| *** slomo_ has quit IRC | 20:16 | |
| *** rohitksingh has joined #timvideos | 20:27 | |
| *** mparuszewski has joined #timvideos | 20:33 | |
| *** CarlFK has quit IRC | 20:34 | |
| *** slomo__ has quit IRC | 21:18 | |
| *** CarlFK has joined #timvideos | 21:20 | |
| *** ChanServ sets mode: +v CarlFK | 21:20 | |
| *** tija has quit IRC | 22:23 | |
| *** mparuszewski has quit IRC | 23:32 | |
| *** rohitksingh has quit IRC | 23:42 | |
Generated by irclog2html.py 2.12.1 by Marius Gedminas - find it at mg.pov.lt!
