| --- Log opened Tue Dec 13 00:00:25 2016 | ||
| stekern | shorne: great work! | 02:06 |
|---|---|---|
| olofk | ZipCPU: Great. Do you know if it works with non-pipelined slaves too? | 02:38 |
| olofk | With reduced performance of course | 02:38 |
| olofk | bandvig: Managed to miss your messages this weekend. Thanks for trying. Python packaging is a mess, which is probably why you couldn't find pip | 02:44 |
| olofk | There 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 i2c | 02:47 |
| olofk | I recently did a change so that windows users don't need to have the 'patch' command installed | 02:48 |
| bandvig | olofk: 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 |
| bandvig | Ah. I googled and found https://www.python.org/downloads/windows/ | 02:53 |
| bandvig | Should I install 2.7 or 3.5 ? | 02:53 |
| bandvig | But any case I haven't got git-fot-windows, only under Cygwin. | 02:55 |
| shorne | stekern: 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 |
| shorne | then more drivers and smp stuff down the line | 05:38 |
| ZipCPU | olofk: Let's start at the top: do I know if it works (at all)? No, and not yet. | 07:24 |
| ZipCPU | Will 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 |
| ZipCPU | There'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 |
| ZipCPU | But 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 |
| olofk | shorne: Sounds good. The mem{set,cpy} patches does quite a bit for decreasing the boot time at least | 07:47 |
| olofk | And most important, I will finally have my name in the kernel :) | 07:47 |
| olofk | ZipCPU: 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 working | 07:48 |
| ZipCPU | Well ... 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 |
| olofk | And 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 cores | 07:50 |
| ZipCPU | Depending 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 |
| kc5tja | Does picorv32 have an AXI4 bridge? Ithought it just exposed its own interface. | 11:05 |
| kc5tja | I am in a similar situation with my 64-16-bit Furcula bridge. | 11:06 |
| kc5tja | Just wrapped up the Verilog for it last night. (And SMG) | 11:06 |
| kc5tja | No idea if it'll work in practice. | 11:07 |
| kc5tja | One thing is for sure though; I think I'd rather work with AXI4 than Wishbone when compounding more than one bridge. | 11:12 |
| kc5tja | I think this will be the last system design I build with a Wishbone B3 interface. | 11:13 |
| kc5tja | Next 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 |
| ZipCPU | kc5tja: You'd *rather* work with AXI4 than WB? Why? My experience leads me to the opposite conclusion. | 11:14 |
| ZipCPU | Is it because of how slow B3 is? | 11:16 |
| kc5tja | No, 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 |
| ZipCPU | Ok. I can understand that. | 11:22 |
| kc5tja | The 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 |
| kc5tja | So even though you're pipelined, that interconnect is seized until all transactions have been resolved. | 11:22 |
| ZipCPU | I'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 |
| kc5tja | For 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 |
| ZipCPU | Oh ... wait, is that your issue? That one master can hold the whole interconnect locked while others might wish access to it? | 11:23 |
| kc5tja | Yes. | 11:23 |
| kc5tja | In particular, the path to RAM. | 11:24 |
| kc5tja | (Don't much care about anything else.) | 11:24 |
| ZipCPU | I don't think you'll find B4 fixing that. | 11:24 |
| kc5tja | On its own, no. You'd need a proper wormhole-routed switch. | 11:25 |
| kc5tja | That way, CYC_O asserts inside its own domain and ONLY in its own domain. | 11:25 |
| kc5tja | But when you have that, you *basically* have AXI4. | 11:25 |
| kc5tja | Which is what led me to my reasoning. | 11:25 |
| kc5tja | I was planning on writing up a blog article on this topic at some point. | 11:25 |
| kc5tja | Hard to explain in an IRC chat. :) This involves a whiteboard. | 11:26 |
| ZipCPU | No, I think I grasp what you are saying, and I understand your criticism. | 11:26 |
| ZipCPU | It helps that we discussed it a touch a couple days ago. | 11:26 |
| kc5tja | Don't get me wrong. Still *love* WB. :) | 11:27 |
| kc5tja | Wondering 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 |
| ZipCPU | I'd hate to answer that question: my answer could never be considered authoritative--especially when concerning others. | 11:29 |
| ZipCPU | I 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 |
| ZipCPU | From my standpoint, while I *love* WB and use it nearly exclusively, I'm not immune to noticing problems. | 11:31 |
| ZipCPU | One 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 |
| kc5tja | What do you mean? Can you explain the issue? | 11:32 |
| ZipCPU | Well, 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 |
| ZipCPU | The error then gets returned (or can get returned) before the first bus command completes. | 11:33 |
| ZipCPU | It could be just an issue associated with how I am implementing my interconnect. | 11:33 |
| kc5tja | I 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 |
| ZipCPU | I 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 |
| ZipCPU | Must it count how many transactions are outstanding, and wait to insert the error in the return stream? | 11:35 |
| kc5tja | It would have to, yeah. | 11:35 |
| ZipCPU | None of my interconnects do that. | 11:36 |
| kc5tja | AXI4 doesn't solve this issue either; every stage in its interconnect needs proper queueing as well. | 11:36 |
| kc5tja | AXI3 "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 |
| ZipCPU | Yeah, I see your point regarding AXI4. | 11:38 |
| ZipCPU | Maybe I just need to figure out how to build a better interconnect. | 11:38 |
| ZipCPU | So 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 |
| kc5tja | Nothing wrong with moving on; the question is, are you allowed to re-load from the stored address before the write commits? ;) | 12:02 |
| kc5tja | Not 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 |
| kc5tja | E.g., an incomplete load actually delivers a future, rather than an actual value. | 12:02 |
| kc5tja | The CPU would wait on the future only when it was actually referenced/used. | 12:03 |
| stekern | ZipCPU: mor1kx does that as well (move on on stores) | 14:21 |
| --- Log closed Wed Dec 14 00:00:26 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!