IRC logs for #openrisc Wednesday, 2016-06-29

--- Log opened Wed Jun 29 00:00:15 2016
stekernolof: yeah, perhaps03:22
olofI've been meaning to make a memory-to-memory DMA from my wb_streamer components06:25
olofI just realized that by connecting them the other way around, I can make a FIFO that stores data in a memory with a wishbone port06:26
ZipCPU|Laptopolof: Sounds like fun.  Did you ever get a chance to look at the DMA I built a while back?  It's most definitely a memory to memory DMA, although unlike what I think you are suggesting, both ends are on the same WB bus.06:53
olofZipCPU|Laptop: No, I didn't look at that one. Is it part of ZipCPU or do you have it in a separate repo?08:20
ZipCPUIt's in the ZipCPU repo on OpenCores, in trunk/rtl/peripherals/wbdmac.v.  Don't let that dissuade you, other things depend upon it rather than it depending upon other things.08:22
ZipCPUThe other big dependence it has on the ZipCPU repo is that the documentation for how to use it is found within the ZipCPU Spec.08:22
olofI have no problem with dependencies. That was one of the reasons why I started FuseSoC after all :)08:27
ZipCPUolof: One thing kind of special about it--it uses an internal buffer, and works in stages.  The first stage copies memory into its internal buffer, the second stage copies it out.08:35
ZipCPUThe size of the internal buffer is fixed, although you can choose how much to transfer in any given "burst".08:35
ZipCPUInterrupts can be used to trigger each "burst" of transfers.08:36
olofYeah, I guess you need an internal buffer to get some effiency08:39
ZipCPUEffeciency: all transfers use WB pipeline mode, so aside from setting up and tearing down the bus, transfers are accomplished in two clocks each--one for reading, one for writing.08:41
ZipCPUYes, this is using the B4 version of the WB spec, not the B3 version.  I never heard back from you on the legalities of B4 after I asked on OpenCores ...08:42
olofZipCPU: Sorry about that. I try to do too many things at the same time. Forgot about that08:43
olofI would like to resolve this at orconf actually. Richard Herveille, who is listed as the keeper of the standard will be there08:43
ZipCPUNot bad--I look forward to meeting everyone there.  I head out this afternoon to get my passport ...08:44
ZipCPUStill need to figure out hotel reservations ... but, like I said, I look forward to meeting everyone there.08:44
olofThe problem is that ORSoC, who owns OpenCores, put out a new version of the standard. When they did that, they ripped out the text that said that the specification is free, and replaced it with text that says that you're not allowed to copy parts of the spec and other things08:44
SMDwrkZipCPU you can check airbnb for a place to stay08:45
ZipCPUSMDwrk: Nice ... that's the response I was fishing for ;)08:45
olofSo, to sort things out, I would like to have a new version of the spec, based on b3, probably with the changes from b4, but keeping it as an open standard08:46
ZipCPUSMDwrk: Wait, though ... Airbnb is a site not a place ... I was looking for an ideal place where I wouldn't necessarily need to order a cab to commute.08:46
olofAnd let the b4 spec die08:46
ZipCPUolof: Really?  Let the B4 spec die??08:46
olofZipCPU: Yes. As long as we have an alternative spec that is free to use08:47
ZipCPUOk, I suppose, but can I at least keep the single clock transfers?  I *love* that pipeline mode.08:47
SMDwrkZipCPU but you can choose a place to stay there08:47
olofYes, that's what I'm saying. We keep the additions, but we make a new spec based on the free b3 spec08:47
olofWe can't use b4 for anything, since ORSoC claims that they own it08:48
ZipCPUOther things for updating: STB should imply CYC, so that if (STB) would be identical to if ((STB)&&(CYC)) ...08:48
olofI don't agree with that08:49
olofIt makes it hard to do bursts through an arbiter08:49
olofUnless you also add an id tag08:49
olofcyc means that you own the bus08:49
olofstb means that the data in this cycle is valid08:49
ZipCPUOh, I think I get the problem: I'm not suggesting that you get rid of CYC.  Yes, it is needed by the bus arbiter to know when to open and close the bus.08:50
ZipCPUI'm just suggesting that the arbiter, interconnect, and masters make certain that STB is always low unless CYC is also high.08:50
ZipCPUIt's just a performance issue in the slave--I can get my slaves to run faster if I don't need to also check CYC at the same time.08:50
olofThat's what I usually do :)08:51
olofOnly act on cyc08:51
olofor wait08:51
olofwhat would the difference be?08:51
ZipCPUAhm ... no.  A slave should act on STB.  An arbiter should act on CYC.08:51
ZipCPUThe difference is in performance.  If STB implies CYC as well, so that STB will never be high when CYC is low, then I can use less logic in the slave.08:52
ZipCPUAs an example, in a memory you might write: if (STB)&&(WE)  mem <= DATA;08:52
olofone gate :)08:52
ZipCPUThis is simpler than, if ((CYC)&&(STB)&&(WE)) mem <= DATA;08:53
ZipCPUOr, also in the same memory, ACK <= STB rather than ACK <= (CYC)&&(STB);08:53
ZipCPUWhile you might argue the performance difference isn't that much in this memory example, checking for both CYC and STB can become prohibitive in more complex designs.08:54
olofWell, you would still need to to the and-ing in the arbiter instead. Any smart synthesis tool would end up with the same logic08:54
ZipCPULet's see ... in my arbiter, I have a line "assign o_stb = (r_a_owner) ? i_a_stb : i_b_stb;"  ... no reference to CYC there, except elsewhere where I determine whether A is the owner or not.08:55
olofI just duplicate my stb to all slaves08:56
olofNo need for a mux, since I control the gating with cyc instead08:56
olofI think we will end up with basically the same code whichever way we do it08:57
ZipCPUREALLY???  I've been doing the opposite: duplicating CYC to all of the slaves, and gating the STB with whether or not the slave device is being addressed.08:57
olofI'm not surprised actually. We have had a lot of discussions trying to interpret the wishbone spec in this channel over the years :)08:58
olofLet's just say that there is more than one way to read it08:58
olofHonestly, I think the bus is severely underspecified and not all corner cases are thought of08:58
ZipCPUPerhaps I should share one?08:58
ZipCPUWhat happens when you address a device, issue a bus command for the device, and then address a second one with a different delay requirement?08:59
olofFor example, you're not allowed to change sel during a burst. I turned out that this made it impossible to write a efficient bus resizer08:59
ZipCPUThe "ACKs" might come back at different delays, and land on top of each other.08:59
olofThis is where cyc should help you. You shouldn't drop cyc until the ack has returned, right?09:00
olofI won!09:00
ZipCPUBut ... if you have multiple requests flying through the fabric, one right after another, pipelined mode, then CYC stays high until all are complete.09:01
ZipCPUIf those requests cross devices, you might end up with multiple ACKs coming back on the same clock.09:01
olofI have to be honest and say that I've stayed away from pipelined mode. It's a necessary addition, since wishbone is total crap as soon as you need to do a CDC, but I still haven't done designs with it09:02
ZipCPUOk.  Fair enough.  I've been using it extensively and have fallen in love with it.09:03
olofBut there is an interesting side note here. Are you allowed to do two bursts without lowering cyc between them?09:03
olofIIRC we discovered some nasty case around this area about a year ago09:04
ZipCPUGood question.09:05
ZipCPUHere's a corrollary: What defines the limits of a burst?  What if the master wants to execute a 16 burst request, but does so with various stalls between the bursts?09:05
ZipCPUSTB might look like:  10010010001001001000011 ... just as a fun example, with CYC valid from the beginning until the last ACK.  Is that valid?  I think it should be.09:06
ZipCPUAt the same time, I've restricted the burst modes I've dealt with to those where the address lines are either constant or incrementing.  I've also limited the bursts to one device at a time, never crossing slave devices.09:09
olofYes, that's how I would use cyc and stb. Just raise cyc until it's all done, and lower stb in case I don't have a next valid data to send09:12
ZipCPUI'm also dealing with some devices with rather long pipelines.  For these, I use ((STB_O)&&(~STALL_I)) as the condition to determine whether I should move on to the next request.09:14
ZipCPUAs I recall, sending multiple requests in flight at once was a problem under B3 ... I'm just not familiar enough with B3 to state what that problem was (or is).09:15
ZipCPUYeah, here it is: block READ as an example, the master cannot start the cycle for the next word of data until ACK is asserted by the slave.09:19
ZipCPUThe slave cannot assert ACK, however, until it's output DATA is valid.09:19
ZipCPUHence, when I try to get a SDRAM chip up and running, I can run the SDRAM in a pipelined mode to read/write one word every clock cycle.09:20
ZipCPUBut, if I need to wait from one request to the next, I can't start reading the second word until I've responded to the first read request.09:20
olofZipCPU: I found parts of a wishbone discussion that stekern and I had 1.5 years ago. It's incredibly confusing and I'm not sure we worked everything out09:21
ZipCPUHence the CAS latency would be applied to every word I tried to read, rather than just the first word.09:21
olofAlso the day before09:21
olofZipCPU: Yes, this is one area where wishbone (b3) is horrible09:22
ZipCPUI got a point!09:22
olofstekern worked around this in our usual SDRAM controller by introducing a small multiport cache in front of the RAM09:22
olofSo everytime read a word, we ask the SDRAM for a larger chunk09:23
ZipCPUSo let's remember, then, for our discussion at ORCONF that we want a pipelined mode that can transfer one datum per clock, and that allows multiple transactions to be in flight at any given time.09:24
olofAs I said before, we want the additions from b4 (I guess), but having it as a free standard09:25
ZipCPUSo that's the beginning outline of the discussion.  I look forward to being a part of it!09:25
olofI hope that the CERN guys show up. They were the ones originally requesting this update to the spec09:26
ZipCPUstekern: I'm looking for the most recent/up to date OpenRisc architecture spec.  Would I find that at
SMDhomeZipCPU I think so16:53
SMDhomeZipCPU also check this
ZipCPUI thought you guys had left opencores ...?  That's why I was asking about the most "up to date" spec.16:56
SMDhomeZipCPU Olof or wallento could answer more precisely, but 1.1 specification is the latest afaik17:01
SMDhomeplus opencores is the only place I could find proposals about 1.2 revision17:01
ZipCPUOk ... it took me a while to find it there, but I eventually found an ODT file to look through.17:03
ZipCPUThe OpenRISC ISA specifies floating point instructions for both single and double precision floating point.  Is this an extension to the basic processor, or a requirement of any OpenRISC processor?18:38
--- Log closed Thu Jun 30 00:00:17 2016

Generated by 2.15.2 by Marius Gedminas - find it at!