| --- Log opened Wed Oct 21 00:00:35 2015 | ||
| -!- orsonmmz|away is now known as orsonmmz | 02:34 | |
| GeneralStupid | olofk: https://dpaste.de/hf78 | 04:10 |
|---|---|---|
| olofk | GeneralStupid: Can't find anything obvious there either :/ | 04:59 |
| olofk | GeneralStupid: You could add a LED blinker to your top-level to ensure that clocks and reset is working properly | 05:10 |
| _franck_ | andrzejr: good to hear | 05:31 |
| stekern | fwiw, https://github.com/openrisc/linux should work without atomic instruction support | 06:06 |
| stekern | it has emulation in the kernel for them | 06:06 |
| andrzejr | _franck_, the results are very confusing, though. It looks like my wrapper produces correct DDR ctrl read requests but gets data from wrong places in the memory. | 07:38 |
| olofk | andrzejr: Could it be wrong CAS/RAS latency? | 11:00 |
| andrzejr_ | olofk, will check that. it sounds plausible, especially that digilent used a "Micron-compatible" part | 11:52 |
| * olofk hates DDR* memory interfaces | 13:04 | |
| olofk | I still wonder why not high speed serial links are used more for memories. Sure, you get a higher latency, but it would surely be cheaper to smack on a SERDES instead of routing millions of parallell high speed pins | 13:06 |
| olofk | And I guess that memories are mostly read and written in blocks nowadays, so for larger block sizes, the latency will be less critical | 13:07 |
| olofk | I know there's HMC (Hybrid Memory Cubes) that uses serial links, but if I have understood this correctly, they are on-chip, or even on-die memories | 13:08 |
| poke53281 | Sooner or later you might no longer have external memory modules, but stacked RAM instead. | 13:08 |
| poke53281 | Yes, on-die memories | 13:09 |
| olofk | oh.. there's something called gigachip | 13:12 |
| olofk | Can't find any compatible memories though :) | 13:14 |
| juliusb_ | hey guys, did we get the ORCONF group photo posted anywhere yet? | 13:16 |
| poke53281 | olofk: Is there a problem with the low and high flank during a clock pulse when you try to access DDR? Wonder If you can take of this feature when you program an interface. | 13:43 |
| poke53281 | I mean rising edge and falling edge | 13:43 |
| olofk | juliusb_: Don't think so, but I got them if you want them. simoncook sent them over | 16:06 |
| olofk | poke53281: Not sure I understand what you mean | 16:07 |
| juliusb_ | olofk: ah cool. should we put it up on the site? | 16:08 |
| olofk | juliusb_: Sure thing | 16:12 |
| GeneralStupid | Hi Guys | 17:05 |
| GeneralStupid | olofk: where is the program counter - counter? :-D | 17:05 |
| olofk | GeneralStupid: pc something. You could for example try traceport_exec_pc_o or pc_execute_to_ctrl | 17:19 |
| andrzejr_ | olofk, ddr5 is going in this direction - no multi-drop buses, higher bitrates etc | 17:47 |
| robtaylor | olofk: latency, and the fact that buying HMC is like buying gold dust ;) | 17:50 |
| robtaylor | stacked DRAM is hard due to heat issues | 17:51 |
| andrzejr_ | but dram process is simply not good enough (cost!) for high speed series or low noise vco designs. few (and thin) metal layers and rubbish transistors lacking most speed optimisations | 17:51 |
| robtaylor | e.g. SpiNNacker has in-package DRAM, but it comes in at <1W | 17:52 |
| robtaylor | andrzejr_: yeah, hence HMC using TSVs | 17:52 |
| robtaylor | but TSVs are way too low yeld and expensive at the moment, as I understand it | 17:53 |
| andrzejr_ | yes, plus you don't just drill holes worth 1M transistors each in RAM. electrically they are not very different from other series channels | 17:56 |
| andrzejr_ | eh, autocorrection | 18:00 |
| robtaylor | andrzejr_: heh | 18:05 |
| robtaylor | the folk i know that have played with HMC have said the latency is too high though | 18:05 |
| andrzejr_ | afaik in HMC you talk to a (fast) proxy chip which then forwards requests to dram chips. good for bandwidth, not so for latency | 18:09 |
| andrzejr_ | also, not sure if stacking is cheaper than extending dram process | 18:10 |
| robtaylor | andrzejr_: yep | 18:22 |
| robtaylor | vagyely related http://ra.ziti.uni-heidelberg.de/cag/research/recent-research-projects/openhmc | 18:24 |
| robtaylor | olofk: good overall refernce in this http://www.extremetech.com/computing/197720-beyond-ddr4-understand-the-differences-between-wide-io-hbm-and-hybrid-memory-cube/2 | 18:25 |
| olofk | ok, I hadn't considered that DRAM processes were a bad match for high speed serial designs | 20:54 |
| olofk | But the proxy chip design sounds interesting. If latency or even bandwidth ain't critical you could save a lot of PCB area if you had a discrete DDR+SERDES IC. Still feels like that would make sense in a lot of applications | 20:57 |
| olofk | ah ok.. so HMC _is_ chip to chip, but they use TSV between the DRAM and the controller | 21:11 |
| andrzejr | it looks like it wasn't CAS latency, checking other timing parameters | 21:24 |
| andrzejr | stekern, I have pushed a small fix to diila's waveform generator: https://github.com/andrzej-r/diila.git | 23:58 |
| andrzejr | it filters out unnecessary transitions so that the waveforms look more readable in gtkwave | 23:59 |
| --- Log closed Thu Oct 22 00:00:36 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!