IRC logs for #openrisc Tuesday, 2016-12-13

--- Log opened Tue Dec 13 00:00:25 2016
stekernshorne: great work!02:06
olofkZipCPU: Great. Do you know if it works with non-pipelined slaves too?02:38
olofkWith reduced performance of course02:38
olofkbandvig: Managed to miss your messages this weekend. Thanks for trying. Python packaging is a mess, which is probably why you couldn't find pip02:44
olofkThere is however a specific test I'm interested in trying out on Windows. I would like to see if it's possible to install fusesoc (+ git) from a branch called git-apply natively in Windows (not in cygwin) and then run fusesoc fetch i2c02:47
olofkI recently did a change so that windows users don't need to have the 'patch' command installed02:48
bandvigolofk:  I'm just not familiar with scripting languages support in Windows. Should I have to find and install python for Win or python is a part of Win by default?02:51
bandvigAh. I googled and found
bandvigShould I install 2.7 or 3.5 ?02:53
bandvigBut any case I haven't got git-fot-windows, only under Cygwin.02:55
shornestekern: olofk: nor next series of changes I am thinking the memcpy memset funcs, some change from sebastien macke and getting our gpio driver into staging (and updated to latest gpio api)05:37
shornethen more drivers and smp stuff down the line05:38
ZipCPUolofk: Let's start at the top: do I know if it works (at all)?  No, and not yet.07:24
ZipCPUWill it work with non-pipeline slaves?  To that question, allow me to ask, Wouldn't it be more appropriate to build an AXI4-Lite bridge for non-pipelined slaves?07:25
ZipCPUThere's a lot of difficulties in the current implementation to get pipelining to work.  By backing off, and only allowing a single transaction to be in flight at any one time ... isn't that both AXI4-Lite and your non-pipelined wishbone?07:26
ZipCPUBut let me ask a question: Does the non-pipelined wishbone negate STB after ACK?  (How about CYC?)  If you don't need that extra wait state, then just set STALL_I = !ACK_I and it should work.07:28
olofkshorne: Sounds good. The mem{set,cpy} patches does quite a bit for decreasing the boot time at least07:47
olofkAnd most important, I will finally have my name in the kernel :)07:47
olofkZipCPU: Yes, I think it's written in the spec how to handle non-pipelined slaves. Was just curious if you had done anything funky that would prevent it from working07:48
ZipCPUWell ... I haven't done "anything funky that would prevent it from working", but neither have I done "anything funky" to get it to work.  ;)07:49
olofkAnd as for tests, proper BFMs would be best, but also try it with some CPU using AXI (most RISC-V CPUs, for example picorv32, vscale) with some wb cores07:50
ZipCPUDepending on how you define the non-pipeline version, just a line or two change in the always block driving the wishbone wires would be sufficient.07:51
kc5tjaDoes picorv32 have an AXI4 bridge?  Ithought it just exposed its own interface.11:05
kc5tjaI am in a similar situation with my 64-16-bit Furcula bridge.11:06
kc5tjaJust wrapped up the Verilog for it last night.  (And SMG)11:06
kc5tjaNo idea if it'll work in practice.11:07
kc5tjaOne thing is for sure though; I think I'd rather work with AXI4 than Wishbone when compounding more than one bridge.11:12
kc5tjaI think this will be the last system design I build with a Wishbone B3 interface.11:13
kc5tjaNext one will be B4 at the very least.11:13
kc5tja(Well, it'll have to be anyway; the next system design will involve a cache controller.)11:14
ZipCPUkc5tja: You'd *rather* work with AXI4 than WB?  Why?  My experience leads me to the opposite conclusion.11:14
ZipCPUIs it because of how slow B3 is?11:16
kc5tjaNo, it's because of timing closure.  There are asynchronous paths from one end of the interconnect to the other end that have to be met.11:21
ZipCPUOk.  I can understand that.11:22
kc5tjaThe other reason is that, over a single interconnect, Wishbone asserts CYC_O for as long as there remain unresolved transactions, which means it locks the interconnect.11:22
kc5tjaSo even though you're pipelined, that interconnect is seized until all transactions have been resolved.11:22
ZipCPUI've had to build multiple various bus delay elements for WB to achieve timing closure over the course of my experience with it.  One such element had to break the stall line spec, so that it was buffered to be successful.11:23
kc5tjaFor what it's worth, when I said WB, I was referring to WB B3 specifically.  I have no idea how WB B4 will fare for my own application.  I'll definitely give it a shot though.11:23
ZipCPUOh ... wait, is that your issue?  That one master can hold the whole interconnect locked while others might wish access to it?11:23
kc5tjaIn particular, the path to RAM.11:24
kc5tja(Don't much care about anything else.)11:24
ZipCPUI don't think you'll find B4 fixing that.11:24
kc5tjaOn its own, no.  You'd need a proper wormhole-routed switch.11:25
kc5tjaThat way, CYC_O asserts inside its own domain and ONLY in its own domain.11:25
kc5tjaBut when you have that, you *basically* have AXI4.11:25
kc5tjaWhich is what led me to my reasoning.11:25
kc5tjaI was planning on writing up a blog article on this topic at some point.11:25
kc5tjaHard to explain in an IRC chat.  :)  This involves a whiteboard.11:26
ZipCPUNo, I think I grasp what you are saying, and I understand your criticism.11:26
ZipCPUIt helps that we discussed it a touch a couple days ago.11:26
kc5tjaDon't get me wrong.  Still *love* WB.  :)11:27
kc5tjaWondering if there's been any movement in the WB community to move it to a more packet-routing friendly direction?  Or, are people in the FOSH community happy with just using AXI4 as-is?11:28
ZipCPUI'd hate to answer that question: my answer could never be considered authoritative--especially when concerning others.11:29
ZipCPUI have not personally seen any such work, but I know others have worked on making multicore platforms work--things that would need a proper NOC.  I'm not sure if they used WB, AXI, or other.11:30
ZipCPUFrom my standpoint, while I *love* WB and use it nearly exclusively, I'm not immune to noticing problems.11:31
ZipCPUOne problem I'm struggling to think my way through is synchronous error handling.  I was almost wondering if this was going to be the problem you were going to mention.11:32
kc5tjaWhat do you mean?  Can you explain the issue?11:32
ZipCPUWell, imagine you issue four commands to the bus.  The interconnect routes them.  The first one goes successfully.  The second one generates an error (missing address or some such).11:33
ZipCPUThe error then gets returned (or can get returned) before the first bus command completes.11:33
ZipCPUIt could be just an issue associated with how I am implementing my interconnect.11:33
kc5tjaI need to re-read the B4 specs, but I thought ERR_I was asserted during the period that you'd normally assert ACK_I?  So the master always associates the error with the correct transaction.  Am I mis-remembering?11:34
ZipCPUI know LM32 insists that every transaction receive either an ACK, an ERR, or a RETRY in response.  My problem is ... what happens if/when the interconnect wishes to generate an error?11:35
ZipCPUMust it count how many transactions are outstanding, and wait to insert the error in the return stream?11:35
kc5tjaIt would have to, yeah.11:35
ZipCPUNone of my interconnects do that.11:36
kc5tjaAXI4 doesn't solve this issue either; every stage in its interconnect needs proper queueing as well.11:36
kc5tjaAXI3 "allows" for out-of-order responses, but then you have other synchronization issues to deal with, which is why AXI4 no longer allows them.11:37
ZipCPUYeah, I see your point regarding AXI4.11:38
ZipCPUMaybe I just need to figure out how to build a better interconnect.11:38
ZipCPUSo far it hasn't been too much of a problem for me: any process that gets a bus error needs to terminate anyway.  I just don't always stop on the right dime--especially in the case of STOre instructions, where I move on before the ACK returns.11:40
kc5tjaNothing wrong with moving on; the question is, are you allowed to re-load from the stored address before the write commits?  ;)12:02
kc5tjaNot sure if it was you who brought it up or not, but I seem to recall an interesting discussion about moving on with *loads* as well.12:02
kc5tjaE.g., an incomplete load actually delivers a future, rather than an actual value.12:02
kc5tjaThe CPU would wait on the future only when it was actually referenced/used.12:03
stekernZipCPU: mor1kx does that as well (move on on stores)14:21
--- Log closed Wed Dec 14 00:00:26 2016

Generated by 2.15.2 by Marius Gedminas - find it at!