IRC logs for #openrisc Sunday, 2015-08-16

--- Log opened Sun Aug 16 00:00:01 2015
-!- asahsieh_nctu is now known as [R2]asahsieh03:59
juliusbaccom details and other bits and pieces up on http://orconf.org16:25
juliusboh, and there's an additional day for lowRISC-stuff )16:26
andrzejrThanks juliusb16:51
andrzejrI 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
andrzejrNot 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
andrzejrBut 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
olofkandrzejr: 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-agnostic21:58
olofkThere are also several attempts to incorporate stuff from the AXI4 family, like WB-AXI converters, or replacing the CPU bus interface with AXI4 directly21:59
olofkI agree with your point that wb is boh overengineered and too simple for many cases22:00
andrzejrolofk, 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 bridge22:00
olofkI think its main drawback is that it's a big penalty for clock-crossing domains22:00
andrzejryup, you really need a unidirectional channels for that.22:01
olofkMy interface consists of three channel (instead of AXI4's five channels)22:01
andrzejrbut also the whole bust semantics are both underspecified and complicated22:02
andrzejrburst* :-)22:02
olofkOne 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 control22:02
olofkI have com to dislike the unspecified burst length "feature" in Wishbone. It's not very useful actually22:04
andrzejras long as there is no end-to-end feedback around the single channel that's OK22:04
andrzejrIn my DRAM interface I only support wb_bte=01, others return an error22:06
andrzejrdo you use read return channel for signaling any write errors?22:07
olofkandrzejr: I have been thinking about doing that, but decided against it.22:07
olofkMy 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 done22:08
olofkInstead 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 mechanism22:10
olofkI mean, when do you really get write errors? Is that only for readonly registers?22:11
andrzejrI 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
olofkYeah. That's a way to have several transactions in flight and still have exact error reporting22:12
andrzejrI 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
andrzejralso this could potentially handle transaction reordering but I guess we don't need to go that far.22:14
olofkIf this interface is on a DRAM controller, it would be pretty easy to do some simple reordering there. I've thought about that too22:15
olofkMy 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
andrzejrhave you got any code of that interface? I would like to experiment with it a bit.22:17
olofkI could talk about this for hours, but I unfortunately have to sleep now. I can send over some WIP code22:17
andrzejrThat would be great. Good night!22:18
olofkIt's codenamed camd right now (Command, Address, Mask, Data)22:19
olofkIt'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
olofkgood night22:21
andrzejrthank you22:23
andrzejrAFAIR 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 2.15.2 by Marius Gedminas - find it at!