| --- Log opened Fri Aug 05 00:00:11 2016 | ||
| ZipCPU | olofk: You said you had some experience working with DDR2, or anyone else familiar with reading timings, ... got a moment for a question? | 10:27 |
|---|---|---|
| ZipCPU | The chip I'm working with lists its timings as: tRCD-tRP-CL as 11-11-11. Then it states that tRCD is 13.75ns, tRP=13.75ns, and CL=13.75ns. | 10:28 |
| ZipCPU | My interpretation was that, if CL=13.75ns, and my clock is 5ns, then I have a CAS latency of 5 clocks (the minimum). | 10:28 |
| ZipCPU | However, there's a note in the spec that CAS latency's of 11 clocks were specifically created to support this chip. | 10:29 |
| ZipCPU | Further, I note that, when given a READ command, the chip doesn't respond until 11-clocks after the read--consistent with a CAS read latency of 11 clocks (55ns), rather than 5 clocks (25ns which is greater than the 13.75 specified ... right?) | 10:30 |
| ZipCPU|Laptop | Looks like I got the clock rate off by a factor of four. Lots of rework to do now. | 14:56 |
| ZipCPU|Laptop | Turns out the memory doesn't support a clock of 5ns. Thus, when it lists tCL as 13.75ns, that's 11 clocks assuming a 1.25ns clock. My 5ns clock was ... inappropriate for the device. | 15:55 |
| ZipCPU|Laptop | According to the DDR3 spec, my clock is allowed to be anywhere between 1.25 and 1.5ns for this latency, so I'll need to bump my device clock speed up from 200MHz to 800MHz. | 15:56 |
| ZipCPU|Laptop | Only problem is, I doubt I can bump up the internal FPGA clock frequency, so ... the memory will simply be able to transfer more data than I can handle. | 15:57 |
| olofk | ZipCPU|Laptop: You could go for a burst cache then perhaps? | 16:31 |
| kc5tja | That is one thing I find that's pervasive in hardware description languages. | 16:42 |
| kc5tja | "Oh shoot, I screwed up this --><-- tiny bit here, now I have to redesign EVERYTHING." | 16:43 |
| ZipCPU | olofk: Burst cache? Perhaps. Perhaps mostly because I'm not exactly certain what that means. | 17:01 |
| ZipCPU | I do know this: I'll be doing 128-bit transfers to/from the memory. | 17:02 |
| ZipCPU | If my bus to the rest of the FPGA is only 32-bits wide, that makes something sort of like a burst cache make more sense, now, doesn't it? | 17:02 |
| ZipCPU | I mean, if I can only read/write in 128-bit bursts, and nothing is really using 128-bits at a time, then reading 128-bits and having those available for the next 3-clocks makes perfect sense, while going on to service... another customer? | 17:03 |
| ZipCPU | kc5tja: Yeah, you understand my feelings exactly. | 17:03 |
| ZipCPU | kc5tja: At the same time, this is why I love this field *so* much. It's difficult, it's a struggle to get things working, you get very | 17:04 |
| ZipCPU | little feedback regarding if things are working, or if they aren't why they aren't, and so it is very satisfying when you at last get that *ah*ha* moment. | 17:04 |
| ZipCPU | olofk: I take that back, I do know what a burst cache is. | 17:05 |
| ZipCPU | olofk: I'm just not sure I'm ready to add the additional logic to the back end. | 17:06 |
| kc5tja | ZipCPU: Yep. Know that feeling well too. I remember the day I got a hello world app running on the Kestrel-2 for the first time. I was almost in tears from joy. | 17:26 |
| ZipCPU | Or the time I taught my first emulated/soft-core CPU to play unbeatable tic-tac-toe. | 17:26 |
| ZipCPU | (It was a toy computer used to teach us assembly language/computer engineering principles in college--and never existed in hardware.) | 17:27 |
| ZipCPU | Here's a good example: debugging a computer across continents, with only the little green light on the front panel to know if you did it right. | 17:29 |
| --- Log closed Sat Aug 06 00:00:12 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!