--- Log opened Wed Aug 17 00:00:29 2016 | ||
wallento | shorne: I think we were waiting for bluecmd and stekern to object | 01:48 |
---|---|---|
wallento | should merge now | 01:49 |
wallento | done | 01:49 |
shorne | wallento: thanks | 03:40 |
wallento | I have added shorne to the GNU toolchain group on github | 03:45 |
wallento | ^ stekern, blueCmd, olofk_, jeremybennett | 03:46 |
stekern | wallento: fine by me | 04:06 |
ZipCPU | Can I get a survey of clocking speeds folks run OpenRISC at? I've heard numbers of 200MHz and 50MHz so far, but I'd be curious to hear what everybody is actually using ... | 18:29 |
olofk | ZipCPU: I'm usually running between 50-70. Depends mostly on the oscillator on the particular board I'm using | 18:31 |
ZipCPU | You don't run PLL's to set the frequency to whatever you want? | 18:32 |
olofk | ZipCPU: Well, yes, but these frequencies are usually easily created by the pll from the oscillator | 18:33 |
olofk | For low-end FPGAs I think you need to disable features when you start to reach 100MHz | 18:34 |
ZipCPU | I found on line that OpenRISC runs at 200MHz. Do you know of anyone running it that fast? | 18:34 |
olofk | And raw speed isn't usually the priority | 18:34 |
olofk | I built mor1kx for a Virtex-6 a few years ago and got it up to 200MHz when disabling a lot of things like caches and MMU | 18:35 |
olofk | Never run it though | 18:35 |
ZipCPU | Really? You would disable a cache line to get higher speed, rather than suffer a stall when accessing the cache? | 18:36 |
olofk | stekern or wallento would be your best shot at finding usable high frequencies | 18:36 |
olofk | Depends on the application. If you're doing number crunching, or need to quickly communicate with a peripheral, the raw speed can be an advantage | 18:37 |
ZipCPU | stekern, wallento: Any comments on high frequency? What speed do you tend to run OpenRISC at? | 18:37 |
ZipCPU | What other priorities do you find yourself responding to? | 18:38 |
olofk | But on the other hand, I think stekern got the best benchmarking result running at a lower speed, but with caches and the store buffer enabled | 18:38 |
olofk | If you're running Linux you need the MMU enabled, and caches are probably a good idea | 18:40 |
olofk | But you might not need fast division and so on | 18:40 |
ZipCPU | Division would slow the CPU down? | 18:41 |
ZipCPU | That is, slow the clock down, rather than just stalling the CPU? | 18:41 |
olofk | Fast division is often on the critical path. A serial one isn't affected so much | 18:46 |
ZipCPU | I have a chart I intend to show at ORCONF showing how division impacts a ZipCPUs area, just ... not it's speed. | 18:46 |
olofk | But honestly, I have spent very little time doing CPU design compared to many people in here :) | 18:46 |
olofk | Got to go | 18:47 |
olofk | Good night | 18:47 |
ZipCPU | Rgr. Thanks for the quick answer. | 18:47 |
ZipCPU | stekern, wallento? Your thoughts? | 18:47 |
stekern | ZipCPU: I got around 100MHz on low-end FPGAs when disabling MMU. Around 80MHz with MMU. | 23:27 |
stekern | I never disabled any caches | 23:27 |
stekern | because, if you disable icache you at least decrase the ipc by half, and you don't gain a 2x freq increase by doing so | 23:28 |
--- Log closed Thu Aug 18 00:00:30 2016 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!