| --- Log opened Sat Aug 03 00:00:55 2013 | ||
| olofk | aha! There was a bug in ram_wb_b3.v | 00:25 |
|---|---|---|
| olofk | hmmm... why does my orpsocv3 version look so different from the one in orpsocv2. Mine should just be a copy | 00:28 |
| -!- heroux_ is now known as heroux | 03:37 | |
| mor1kx | [mor1kx] skristiansson pushed 4 new commits to master: https://github.com/openrisc/mor1kx/compare/8290544d7e9f...cde70705cf9e | 06:45 |
| mor1kx | mor1kx/master 8cae823 Stefan Kristiansson: add avalon bus interface | 06:45 |
| mor1kx | mor1kx/master 1d021a2 Stefan Kristiansson: mmu: hardware reload pte changes... | 06:45 |
| mor1kx | mor1kx/master 32f9c34 Stefan Kristiansson: immu: move spr accesses to the first port of tlb dprams... | 06:45 |
| * juliusb just wrote his first line of RTL for the mor1kx for a while... | 10:40 | |
| stekern | juliusb: yay! | 14:09 |
| stekern | what are you working on? | 14:09 |
| juliusb | finishing my mor1kx + TCM fetcher | 14:09 |
| juliusb | basically, allowing you to attach a RAM (tightly-couple memory) externally for all instruction and some data fetches | 14:10 |
| juliusb | and also a wishbone data port | 14:10 |
| stekern | I almost got this PL1 stuff working, just some problem with using a true dpram in the dmmu | 14:11 |
| juliusb | I have the fetcher working with a hacky orpsoc_top which instantiates the mor1kx_cpu directly and adds some glue logic, so I'm going to make a new mor1kx top-level called mor1kx_tcm which will have a plain RAM port and and wishbone data port, and allowing you to parameterise the address range for the TCM for data accesses | 14:12 |
| juliusb | this is a fairly standard way of doing things when CPUs such as these are used in ASICs | 14:12 |
| stekern | why do you need to have a seperate fetcher and seperate top level? | 14:12 |
| stekern | why not just extend the current fetcher to include the TCM fetcher and add the seperate RAM port to mor1kx? | 14:13 |
| juliusb | the cortex m3 has a similar bus set up - basically a ROM interface (writable, though, incase you have a RAM) which is all single-cycle access, and then a "system" port which is basically all the peripherals (and potentially more data memory - you can execute out of that too on the M3 but it's slower I believe) | 14:13 |
| stekern | like the avalon bus I (accidently) pushed today | 14:13 |
| juliusb | well, on the fetcher point - you could just use the "TCM" fetcher as the normal one actually | 14:13 |
| stekern | I was working ontop of that branch and forgot about it... but I reckon it's fine out there | 14:14 |
| juliusb | and why aren't I using the normal top-level? well, I didn't want ports sitting there unused (Wishbone ibus interface in case of when it's configured to execute from TCM, and TCM in case of other way around) | 14:14 |
| juliusb | oh yeah no worries about the avalon I think (haven't seen it though..) | 14:15 |
| stekern | haven't gone through the amount of testing I wanted before pushing it... | 14:15 |
| juliusb | so, if we're not going to have defines to set the configuration, we're going to need a separate top-level depending on the bus interface. I wouldn't oppose a mor1kx_amba etc. and really, the current mor1kx should be mor1kx_wb I think | 14:16 |
| juliusb | there's also some bus logic to arbitrate accesses to the TCM port I'd want to put at the top-level | 14:16 |
| stekern | it's going to be a nightmare to maintain all of those... | 14:17 |
| juliusb | (avalon bus) ah yes, fair enough - I don't like pushing stuff unless it's properly tested, too, but as long as it's done eventually :) | 14:17 |
| juliusb | that's a good point | 14:17 |
| juliusb | but are you saying that from the point of view of the development you've been doing lately, where you have only dealt with a single top-level? | 14:18 |
| juliusb | and by that I mean the TCM set up is one where you wouldn't have caches+mmu | 14:18 |
| stekern | let's say I want to use this mor1kx_tcm with cappuccino and use the avalon bus as data bus, would that be possible (easily)? | 14:23 |
| juliusb | haha | 14:23 |
| juliusb | good point. I would say, no. | 14:23 |
| stekern | would it be easier if you'd add the tcm port to the current top level module alongside the avalon bus? | 14:24 |
| stekern | (leading questions, I know) =P | 14:24 |
| juliusb | so we can just have ports which are not used I guess | 14:24 |
| juliusb | it does make the top-level more convoluted | 14:24 |
| stekern | yeah, I completely agree it's ugly with unused ports hanging around, but I think it's still the better choice between two evils | 14:26 |
| juliusb | ok, agreed | 14:26 |
| stekern | fwiw, I asked you about this about a month ago =) | 14:26 |
| juliusb | oh... did I answer? | 14:26 |
| stekern | not really | 14:26 |
| juliusb | haha sorry | 14:26 |
| juliusb | well It was always a plan to support various buses, obviously, I guess I never thought about the impact of having multiple top-levels | 14:27 |
| stekern | np, we're having the discussion now, that's good enough for me | 14:27 |
| juliusb | but I agree, that's a pain | 14:27 |
| juliusb | so, if we discuss the TCM thing... | 14:27 |
| juliusb | I would argue it's a feature requirement for the fetcher in the pipeline | 14:28 |
| juliusb | but, if your fetcher can use the cache, then that's basically the same thing | 14:28 |
| juliusb | the main thing is that it can handle quick responses (it seems funny but I noticed there were all sorts of assumptions of "I'm not going to get the instruction immediately so I can register signals etc" when doing a fetcher which was accessing the system bus only) | 14:29 |
| stekern | yah, in the long run I'm interested in adding that to the cappuccino fetcher (tcm interface) | 14:29 |
| juliusb | OK, cool, I think at the top-level then we just allow an address range where all accesses are mapped to the TCM | 14:30 |
| juliusb | and then otherwise default to the external bus | 14:30 |
| juliusb | that then leads me to question of how the TCM is loaded -whether the CPU can control the mapping | 14:32 |
| juliusb | actually, no, you would just have it set at synthesis time | 14:33 |
| stekern | yeah, I think that is sufficient | 14:44 |
| stekern | either you are just running from ROM or have a small fast RAM at a given address | 14:46 |
| juliusb | yes, those are the two things you'll potentially have on the TCM port? | 14:47 |
| juliusb | s/?/you mean?/ | 14:47 |
| stekern | yes, as a response to "cpu can control the mapping vs synthesis tim" | 14:47 |
| juliusb | nice | 14:49 |
| juliusb | ok so my distraction of developing this TCM interface may soon be over :) | 14:51 |
| juliusb | it's only been a few months | 14:51 |
| juliusb | so probably only a month more | 14:51 |
| juliusb | :P | 14:52 |
| stekern | a month passes quickly | 15:02 |
| stekern | ok, I've got PL1 implemented in both immu and dmmu | 15:04 |
| juliusb | Oh yes, I meant ot ask - PL1? I haven't closely followed the discussions of late regarding the hardware TBL reload | 15:06 |
| stekern | page level 1 | 15:08 |
| stekern | allowing for 16 MB pages together with the normal 8 KB | 15:09 |
| stekern | according to jonibo, 16 MB is to large, so he's trying to come up with a way to use 2MB or something, but the "framework" for PL1 needs to be there anyway | 15:10 |
| stekern | and PL1 is a bit in the tlb match registers, indicating if it's a 16MB page or 8KB page | 15:17 |
| juliusb | ah ok cool | 15:31 |
| stekern | so, basically it's not related to the hw tlb reload (except it has to fill the bit when reloading), but a feature that is missing in all of our implementations | 15:34 |
| stekern | a non-optional feature | 15:34 |
| stekern | well, now it's soon to be not missing in one implementation at least | 15:34 |
| juliusb | :) | 15:34 |
| mor1kx | [mor1kx] skristiansson pushed 2 new commits to master: https://github.com/openrisc/mor1kx/compare/cde70705cf9e...968c57ef2935 | 17:56 |
| mor1kx | mor1kx/master 611f6a6 Stefan Kristiansson: mmu: remove AUTOINST from match/translate RAMs... | 17:56 |
| mor1kx | mor1kx/master 968c57e Stefan Kristiansson: mmu: add support for PL1 (aka HUGE) bit... | 17:56 |
| olofk | MicroBlaze has a weird bus-structure. They are using separate ports for cached and non-cached accesses. | 18:19 |
| stekern | you mean, the caches has seperate bus ports? | 18:20 |
| olofk | yep | 18:20 |
| olofk | And it's a pain in the ass when you have a RAM where you only want parts of it cached | 18:21 |
| stekern | the cpu designers were lazy and put the job of muxing the bus outside the cpu ;) | 18:22 |
| olofk | I had to add some weird interconnects to route the requests to the RAM | 18:22 |
| olofk | I think the idea is to have peripherals and memory on different buses, so that slow peripherals won't lock up the memory bus | 18:22 |
| stekern | yeah, it's not all crazy | 18:24 |
| stekern | (except for the pita you experienced) | 18:24 |
| juliusb | there's timing wins there, too. a smaller bus (in terms of things on it, thus muxing) means shorter paths back to the logic in the CPU's fetch/lsu unit | 18:25 |
| olofk | Yeah, I liked the idea, but dealing with those stupid fucking Xilinx GUI tools took all the fun away from doing SoC design | 18:26 |
| juliusb | hear, hear! | 18:26 |
| olofk | They refused to let me connect two arbiters in series, so I had to put in a dummy bus converter between them | 18:26 |
| olofk | Oh well. Enough complaining now. I'm on vacation :) | 18:27 |
| olofk | Hey, is google down? | 18:27 |
| stekern | another situation where it help is where you do a RAM access, which will cause a cache refill. Now, if you have a perhipheral access right after that access, the peripheral access has to wait for the refill to finish before it can even start | 18:28 |
| olofk | That's true | 18:29 |
| olofk | Hmm.. can anyone give me an IP to some common server. I think my DNS just broke down | 18:31 |
| olofk | google.com would be great, so I can google for a solution :) | 18:31 |
| olofk | Addded 8.8.8.8 to my DNS providers. Seems to work now | 18:35 |
| --- Log closed Sun Aug 04 00:00:56 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!