| --- Log opened Sun Aug 16 00:00:01 2015 | ||
| -!- asahsieh_nctu is now known as [R2]asahsieh | 03:59 | |
| juliusb | accom details and other bits and pieces up on http://orconf.org | 16:25 |
|---|---|---|
| juliusb | oh, and there's an additional day for lowRISC-stuff ) | 16:26 |
| juliusb | :) | 16:26 |
| andrzejr | Thanks juliusb | 16:51 |
| andrzejr | I may be touching a sensitive point but has anyone considered changing the default bus? At least for high bandwidth communication (mainly CPU cache<->DRAM). Wishbone is not well performing and at the same time is over-engineered for this purpose. | 21:42 |
| andrzejr | Not sure how it looks from the legal standpoint but AXI4-lite is almost as simple as it gets, probably simpler than Wishbone and better suited for the job. | 21:50 |
| andrzejr | But since this part of the system only involves CPU, DRAM and a bridge we could come up with an even simpler custom bus. | 21:51 |
| olofk | andrzejr: I have thought a lot about those things too. I have started implementing a simple custom bus intended to be used both for memory controller frontends (approximately what you say between CPU cache<->DRAM controller) as well as to make control registers in cores bus-agnostic | 21:58 |
| olofk | There are also several attempts to incorporate stuff from the AXI4 family, like WB-AXI converters, or replacing the CPU bus interface with AXI4 directly | 21:59 |
| olofk | I agree with your point that wb is boh overengineered and too simple for many cases | 22:00 |
| andrzejr | olofk, this only makes sense if both CPU and DRAM support this bus natively. The rest of the system should IMHO connect to this bus via bidirectional bridge | 22:00 |
| olofk | I think its main drawback is that it's a big penalty for clock-crossing domains | 22:00 |
| andrzejr | yup, you really need a unidirectional channels for that. | 22:01 |
| olofk | My interface consists of three channel (instead of AXI4's five channels) | 22:01 |
| andrzejr | but also the whole bust semantics are both underspecified and complicated | 22:02 |
| andrzejr | burst* :-) | 22:02 |
| olofk | One command channel (address and read/write flag). One write channel (with data and mask) and one data return channel (with just data). All channels use AXI4-semantic valid and ready signals for flow control | 22:02 |
| olofk | I have com to dislike the unspecified burst length "feature" in Wishbone. It's not very useful actually | 22:04 |
| andrzejr | as long as there is no end-to-end feedback around the single channel that's OK | 22:04 |
| andrzejr | In my DRAM interface I only support wb_bte=01, others return an error | 22:06 |
| andrzejr | do you use read return channel for signaling any write errors? | 22:07 |
| olofk | andrzejr: I have been thinking about doing that, but decided against it. | 22:07 |
| olofk | My reason for that is that the sender either has to ack every transaction (which causes a end-to-end feedback), or you get the errors after you are done | 22:08 |
| olofk | Instead I recommend to add an out-of-band error signal if the master needs to know that errors have occured, and as I assume that my interface will be hidden behind another bus interface at some point (wb, axi, whatever) we can use that bus interfaces' error mechanism | 22:10 |
| olofk | I mean, when do you really get write errors? Is that only for readonly registers? | 22:11 |
| andrzejr | I was thinking about adding a "transation ID" e.g. an auto-incrementing 4bit number and sending responses with echoing this number. So the master would have an option to handle the errors synchronously or asynchronously. | 22:11 |
| olofk | Yeah. That's a way to have several transactions in flight and still have exact error reporting | 22:12 |
| andrzejr | I guess out-of-band signal is OK. Handling exceptions synchronously (it helps in SW debugging) adds a lot of complexity and is IMHO not worth the cost. | 22:13 |
| andrzejr | also this could potentially handle transaction reordering but I guess we don't need to go that far. | 22:14 |
| olofk | If this interface is on a DRAM controller, it would be pretty easy to do some simple reordering there. I've thought about that too | 22:15 |
| olofk | My main points for my not-yet-named interface was 1. Simple, 2. CDC-friendly, 3. High-performance for read and write bursts (but not necesarily for switching between writes and reads) | 22:16 |
| andrzejr | have you got any code of that interface? I would like to experiment with it a bit. | 22:17 |
| olofk | I could talk about this for hours, but I unfortunately have to sleep now. I can send over some WIP code | 22:17 |
| olofk | Sure | 22:17 |
| andrzejr | That would be great. Good night! | 22:18 |
| olofk | It's codenamed camd right now (Command, Address, Mask, Data) | 22:19 |
| olofk | It's been a while since I worked on it last, so I don't remember what shape the code is in, but here you go https://www.dropbox.com/s/y3403ooguz6wbk7/wb_camd_bridge.tar.gz?dl=0 | 22:20 |
| olofk | good night | 22:21 |
| andrzejr | thank you | 22:23 |
| andrzejr | AFAIR the problem with imprecise exceptions is that they may arrive after an OS context switch. So we can make transactions synchronous (via read channel), not report any bus errors, or ignore the problem (target embedded applications only). | 22:31 |
| --- Log closed Mon Aug 17 00:00:03 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!