IRC logs for #openrisc Saturday, 2013-08-03

--- Log opened Sat Aug 03 00:00:55 2013
olofkaha! There was a bug in ram_wb_b3.v00:25
olofkhmmm... why does my orpsocv3 version look so different from the one in orpsocv2. Mine should just be a copy00:28
-!- heroux_ is now known as heroux03:37
mor1kx[mor1kx] skristiansson pushed 4 new commits to master:
mor1kxmor1kx/master 8cae823 Stefan Kristiansson: add avalon bus interface06:45
mor1kxmor1kx/master 1d021a2 Stefan Kristiansson: mmu: hardware reload pte changes...06:45
mor1kxmor1kx/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
stekernjuliusb: yay!14:09
stekernwhat are you working on?14:09
juliusbfinishing my mor1kx + TCM fetcher14:09
juliusbbasically, allowing you to attach a RAM (tightly-couple memory) externally for all instruction and some data fetches14:10
juliusband also a wishbone data port14:10
stekernI almost got this PL1 stuff working, just some problem with using a true dpram in the dmmu14:11
juliusbI 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 accesses14:12
juliusbthis is a fairly standard way of doing things when CPUs such as these are used in ASICs14:12
stekernwhy do you need to have a seperate fetcher and seperate top level?14:12
stekernwhy not just extend the current fetcher to include the TCM fetcher and add the seperate RAM port to mor1kx?14:13
juliusbthe 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
stekernlike the avalon bus I (accidently) pushed today14:13
juliusbwell, on the fetcher point - you could just use the "TCM" fetcher as the normal one actually14:13
stekernI was working ontop of that branch and forgot about it... but I reckon it's fine out there14:14
juliusband 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
juliusboh yeah no worries about the avalon I think (haven't seen it though..)14:15
stekernhaven't gone through the amount of testing I wanted before pushing it...14:15
juliusbso, 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 think14:16
juliusbthere's also some bus logic to arbitrate accesses to the TCM port I'd want to put at the top-level14:16
stekernit'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
juliusbthat's a good point14:17
juliusbbut 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
juliusband by that I mean the TCM set up is one where you wouldn't have caches+mmu14:18
stekernlet'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
juliusbgood point. I would say, no.14:23
stekernwould 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) =P14:24
juliusbso we can just have ports which are not used I guess14:24
juliusbit does make the top-level more convoluted14:24
stekernyeah, I completely agree it's ugly with unused ports hanging around, but I think it's still the better choice between two evils14:26
juliusbok, agreed14:26
stekernfwiw, I asked you about this about a month ago =)14:26
juliusboh... did I answer?14:26
stekernnot really14:26
juliusbhaha sorry14:26
juliusbwell It was always a plan to support various buses, obviously, I guess I never thought about the impact of having multiple top-levels14:27
stekernnp, we're having the discussion now, that's good enough for me14:27
juliusbbut I agree, that's a pain14:27
juliusbso, if we discuss the TCM thing...14:27
juliusbI would argue it's a feature requirement for the fetcher in the pipeline14:28
juliusbbut, if your fetcher can use the cache, then that's basically the same thing14:28
juliusbthe 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
stekernyah, in the long run I'm interested in adding that to the cappuccino fetcher (tcm interface)14:29
juliusbOK, cool, I think at the top-level then we just allow an address range where all accesses are mapped to the TCM14:30
juliusband then otherwise default to the external bus14:30
juliusbthat then leads me to question of how the TCM is loaded -whether the CPU can control the mapping14:32
juliusbactually, no, you would just have it set at synthesis time14:33
stekernyeah, I think that is sufficient14:44
stekerneither you are just running from ROM or have a small fast RAM at a given address14:46
juliusbyes, those are the two things you'll potentially have on the TCM port?14:47
juliusbs/?/you mean?/14:47
stekernyes, as a response to "cpu can control the mapping vs synthesis tim"14:47
juliusbok so my distraction of developing this TCM interface may soon be over :)14:51
juliusbit's only been a few months14:51
juliusbso probably only a month more14:51
stekerna month passes quickly15:02
stekernok, I've got PL1 implemented in both immu and dmmu15:04
juliusbOh yes, I meant ot ask - PL1? I haven't closely followed the discussions of late regarding the hardware TBL reload15:06
stekernpage level 115:08
stekernallowing for 16 MB pages together with the normal 8 KB15:09
stekernaccording 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 anyway15:10
stekernand PL1 is a bit in the tlb match registers, indicating if it's a 16MB page or 8KB page15:17
juliusbah ok cool15:31
stekernso, 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 implementations15:34
stekerna non-optional feature15:34
stekernwell, now it's soon to be not missing in one implementation at least15:34
mor1kx[mor1kx] skristiansson pushed 2 new commits to master:
mor1kxmor1kx/master 611f6a6 Stefan Kristiansson: mmu: remove AUTOINST from match/translate RAMs...17:56
mor1kxmor1kx/master 968c57e Stefan Kristiansson: mmu: add support for PL1 (aka HUGE) bit...17:56
olofkMicroBlaze has a weird bus-structure. They are using separate ports for cached and non-cached accesses.18:19
stekernyou mean, the caches has seperate bus ports?18:20
olofkAnd it's a pain in the ass when you have a RAM where you only want parts of it cached18:21
stekernthe cpu designers were lazy and put the job of muxing the bus outside the cpu ;)18:22
olofkI had to add some weird interconnects to route the requests to the RAM18:22
olofkI think the idea is to have peripherals and memory on different buses, so that slow peripherals won't lock up the memory bus18:22
stekernyeah, it's not all crazy18:24
stekern(except for the pita you experienced)18:24
juliusbthere'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 unit18:25
olofkYeah, I liked the idea, but dealing with those stupid fucking Xilinx GUI tools took all the fun away from doing SoC design18:26
juliusbhear, hear!18:26
olofkThey refused to let me connect two arbiters in series, so I had to put in a dummy bus converter between them18:26
olofkOh well. Enough complaining now. I'm on vacation :)18:27
olofkHey, is google down?18:27
stekernanother 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 start18:28
olofkThat's true18:29
olofkHmm.. can anyone give me an IP to some common server. I think my DNS just broke down18:31 would be great, so I can google for a solution :)18:31
olofkAddded to my DNS providers. Seems to work now18:35
--- Log closed Sun Aug 04 00:00:56 2013

Generated by 2.15.2 by Marius Gedminas - find it at!