| --- Log opened Mon Aug 01 00:00:05 2016 | ||
| stekern | SMDhome1: it's an or1200 not mor1kx in the allwinner chips | 01:44 |
|---|---|---|
| SMDhome1 | stekern: yep, but does or1200 differ from mor1kx too much that it could clock max to 400-600 mhz? | 02:08 |
| stekern | well, mor1kx *do* have a longer pipeline, so a slightly higher fmax could probably be expected | 02:09 |
| stekern | but all your other points are valid | 02:10 |
| SMDhome1 | ok, but I had a feeling that nowadays it's possible to make openrisc or other not-so-complicated project to reach 1ghz freq even on 130nm process | 02:11 |
| SMDhome1 | http://www.heise.de/newsticker/meldung/Neuer-VISC-Prozessor-von-Soft-Machines-2840028.html but they've managed to get only ~500 mhz with 28nm though | 02:12 |
| SMDhome1 | or 40nm | 02:14 |
| stekern | critical paths is probably more related to the fmax than the complexity | 02:26 |
| stekern | although a less complex core might have less critical paths | 02:26 |
| stefanct | what's the approximate deadline for submissions to orconf2016? | 04:27 |
| olofk | stefanct: No deadline set up yet. We've been lucky enough the previous years to be able to fit all proper submissions that we have received | 07:02 |
| olofk | Though we did have to extend the conference to an extra day last year to manage that :) | 07:03 |
| stefanct | olofk, ok... ill try to get my boss approve the traveling then i could present our (yet unreleased) tool for automatic fault injection instrumentation into existing netlists based on verilog-perl | 15:20 |
| stefanct | or alternatively something coreboot-related | 15:21 |
| olofk | stefanct: Both sound very interesting. Hope to see a submission soon :) | 16:54 |
| olofk | Hmm... that looked like a sarcastic smiley. It wasn't meant like that. Just that I hope you manage to convince your boss soon | 17:27 |
| olofk | Smileys are hard | 17:27 |
| ZipCPU | Woohoo!!! After a week of hard work, my Wishbone-DDR3 controller passes its test bench, *and* builds within Vivado, *and* doesn't break my 200MHz clock/timing requirement! | 17:46 |
| ZipCPU | (I haven't had the guts to actually try it on my hardware yet ...) | 17:46 |
| olofk | ZipCPU: Congratulations! Is it written completely from scratch or based on Xilinx MIG controller? | 18:03 |
| ZipCPU | olofk: Written completely from scratch. No dependencies on the MIG at all. | 18:10 |
| olofk | ZipCPU: Great! What kind of primitives are you using for the I/O? | 18:16 |
| ZipCPU | olofk: The controller itself doesn't include the I/O primitives (yet). I've thought of including them, since I do have them, they're just ... not yet part of the project. | 18:25 |
| ZipCPU | The Xilinx primitives I'm using include: IDDR, ODDR, OBUFDS and IBUFDS. Everything else is (currently) inferred. | 18:27 |
| ZipCPU | These are part of the connection(s) between the FPGA vendor-agnostic code and the vendor-specific code. | 18:28 |
| kc5tja | ZipCPU: Can your core be used for DDR and DDR2 memories as well? | 19:15 |
| ZipCPU | kc5tja: Good question. I'm not doing anything with those memories right now, so it's hard to say. | 19:53 |
| ZipCPU | I guess my best answer would be simply this: it is open source. All of the timing parameters are buried within it, and you are welcome to modify any other timing parameters as you see fit. | 19:53 |
| ZipCPU | Other than the timing parameters, there are only a couple of commands being used: | 19:53 |
| ZipCPU | READ, WRITE, PRECHARGE, ACTIVATE, NOOP, PRECHARGE-ALL, and ... let's see, there's a calibration command as well. | 19:54 |
| ZipCPU | One of the things I like about the implementation is that the RESET sequence and the refresh sequence are both easily adjustable. | 19:55 |
| ZipCPU | They consist of simply a list of instructions, sort of like a ROM memory, where one bit in the instruction specifies whether or not a timer is to be run during the instruction. | 19:55 |
| ZipCPU | Hence, when you start the memory, you are supposed to hold the reset_n line low (active) for 40us. | 19:55 |
| ZipCPU | One line in that table specifies a NOOP for 40us. One bit in every table entry specifies whether or not the reset_n line is to be high or low. | 19:56 |
| ZipCPU | That makes reset logic simple. | 19:56 |
| ZipCPU | The refresh logic is done in a very similar fashion. Sadly, as a result, the refresh logic isn't "optimal". I mean, it always waits for the last write operation to complete (regardless of whether one was in progress), then issues a PRECHARGE-ALL command (regardless of whether or not any banks are open, and so forth. | 19:57 |
| ZipCPU | I already have another controller for an SDRAM memory, I've just never done DDR or DDR2 memories. | 19:58 |
| ZipCPU | I just looked up the other commands: MRSET (set mode register) and REFRESH. | 20:05 |
| kc5tja | I was just wondering, because at some point, I would like the Kestrel to have more than 16MB of memory. ;) | 20:45 |
| ZipCPU | Glad to help! | 20:47 |
| -!- sandeep is now known as Guest90964 | 22:24 | |
| --- Log closed Tue Aug 02 00:00:06 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!