IRC logs for #openrisc Thursday, 2013-11-28

--- Log opened Thu Nov 28 00:00:44 2013
maxpalnHi - I work for Lattice the FPGA Company. I am new to IRC (and relatively new to the ORSOC solution) but working on a port of the ORSOC to our ECP3 family of FPGAs and have a few questions on the wishbone operation of the OR1200 processor. No idea if this is how to ask questions (apologies - I'll get the hang of IRC soon I hope). Is anyone there to receive this?13:54
rahmaxpaln: there are people around14:15
rahmaxpaln: ask your question and wait14:15
rahmaxpaln: someone should answer eventually14:15
rahmaxpaln: also, that is very good news if Lattice is sponsoring work on porting openrisc14:17
rahmaxpaln: please congratulate your employers for taking a step in the right direction :-)14:17
maxpaln:-)14:46
maxpalnthanks - good to hear there are people out there.14:46
maxpalnI have made a lot of progress, it works in general -14:46
maxpalnhowever, one of the key features I am trying to implement is a DDR3 interface (our ECP3 Versa board has DDR3 fitted and I have a specific customer who wants this memory interface)14:47
maxpalnas such, I am running simulations to try and get the wishbone interface to the DDR3 component working. However, I have come across an apparent anomoly in the way the OR1200 is executing an incrementing burst. The problem can be seen on the uart-simple simulation testbench provided with the orpsocv2 distribution.14:48
maxpalnCTI_I="010" indicating an incrementing burst. BTE_I is "01" indicating a 'wrap 4' style increment14:49
maxpalnbut the address order from the OR1200 is as follows:14:50
maxpaln254C14:50
maxpaln254014:50
maxpaln254414:50
maxpaln254814:50
maxpalnall hex values14:50
maxpalnThis is causing me no end of problems because the non-contiguous nature of the addresses is something that can't be easily handled. I am wondering firstly if this is correct (I am just peering into the wishbone spec to see if this is how it should be - I am not convinced one way or the other yet) and secondly I am wondering if there is a way to control this behaviour -14:52
maxpalnideally I'd like to set the burst type to linear and I'd have no more problems.14:52
_franck_w_hi maxpaln14:54
maxpalnhi14:56
_franck_w_this is how it works: you just ask your question and wait for the answer....14:56
_franck_w_most of us are reading the backlogs and answer questions14:56
maxpalnok - apologies if I get it wrong! :-O Hopefully I can be a helpful resource rather than a hinderance soon enough! :-)14:57
_franck_w_so what do you plan to do ?14:58
_franck_w_include one of the lattice dev board to orpsocv3 ?14:59
maxpalnprovide a distribution of the ORSOC that is supported on one of our lowish cost eval boards for our ECP3 family14:59
maxpalnthe driver is a specific customer request that has allowed me to do set time aside for the work14:59
_franck_w_ok great15:00
maxpalnI am an FAE for Lattice - so the FPAG side of things is straight forward and we already use the wishbone bus on all our devices so it isn't such a learning curce15:00
maxpalncurve15:00
_franck_w_orpsocv3 doesn't support lattice workflow for now but that would be great if you can do the job15:01
maxpalnI have a lot of the design working - but the burst reads are not working at all15:01
maxpalnyeah - agreed15:01
_franck_w_what's the problem with burst read ? did you simulate it ?15:04
maxpalnyep, a LOT of simulation - in fact pretty much exclusively in simulatoin although I have confirmned the problem in HW too15:05
maxpalnthe problem is that the DDR3 memory can't easily jump around memory accesses - our IP expects a starting address then a burst read incrementing from that address15:05
maxpalnso a wishbone burst read that goes something like this is fine: 0x2540, 0x2544, 0x2548, 0x254C15:06
maxpalnHowever, when running the uart-simple simulation that ships with the distribution (and I am guessing thie behaviour is a feature of the OR1200) the burst reads are occuring with a non-contiguous sequence of memory addresses15:07
maxpaln0x254c, 0x2540, 0x2544, 0x254815:07
maxpalnthis is fundamentally incompatible with the way our DDR3 IP works. So I need a way to either change the burst addressing to linear or I need to modify the wishbone wrapper to detect when the burst address is non-consecutive and deassert the ACK (although this is stretching my knowledge of the wishbone spec so I will really need to revise this before implemeting it)15:09
* _franck_w_ is goinf to look in the or1200 to see where burst type is defined15:12
_franck_w_burst are used to refill cache line that's why it uses 4 or 8 bytes address wrap (to fit the cache line size) (stekern am I true ?)15:27
_franck_w_you should handle this, I don't know15:27
_franck_w_may be that you should implement some cache memory in your DDR controller and support burst wrap on this cached memory15:28
maxpalnwell, there is already a FIFO to handle the different clock domains (wishbone vs DDR3). Maybe the solution is to implement a version of the wrap-4 address locations.15:30
maxpalnI could switch the FIFO to a dual-port memory maybe - it might work but it would require me to correctly predict the address order. At the moment the simulatoin and the spec don't quite tie up15:32
maxpalnI think I am not understanding the way this works correctly - Table 4-3 gives the address ordering. For the above example, the first address (0x254C) has the LSBs as "100" so the address sequence should still be in order "4-5-6-7-8-9-A-B"15:34
maxpalnBut if switching the OR1200 to linear bursts isn't an option (which it sounds as though it isn't) I will need to think around this a little more...15:36
rokkahello, is it possible to program ordb2a directly from quartus?15:38
_franck_w_I'm not  a burst expert either :) if you consider bits [15..2] of your address, it matches what's in the table 4-315:38
_franck_w_I mean bits [4..2] since there is 3 bits in the table15:38
_franck_w_rokka: I don't this so. You need to use urjtag (but I don't know more). olofk or LoneTech might know that15:40
maxpalnah, that's an interesting point - since the byte width is 4 maybe bits 1 and 0 are ignored15:42
maxpalnit's a bit of a leap of faith though :-)15:42
_franck_w_maxpaln: in the chapter 4.2.3 it says :"The increment is dependent on the data array....for a 32bit data array the increment is 4"15:42
maxpalnyeah, I was just reading that myself15:43
_franck_w_so "0-1-2-3-4-5-6-7" represents increments so it has to be x4 for a 32 bits bus15:43
_franck_w_ok15:44
maxpalnyep, I see that bit - it's the LSB column which isn't quite clear15:44
_franck_w_true, it's not clear15:45
maxpalnbut given that the increment of 4 makes the lower 2 bits irrelevent it would be sensible to take the LSBs from 4..2 - but I can't see it stated anywhere15:45
maxpalnI think I need to give this more thought - but thanks for your help. This has been a good intro to the IRC here :-)16:01
_franck_w_great, see you soon16:03
stekernmaxpaln: I think the chapter about wrapping bursts are a bit confusing as well, but as you found out for 32 bit accesses the increments are by four16:13
stekernand the wrapping point can be by 4 or 8 (or 16 iirc, but or1200 doesn't use that)16:14
maxpalnHi stekern, thanks - yes I had come to that conclusion.16:15
stekernthe wrapping point (burst length) is communicated over the bus16:15
maxpalnthe outstanding query now is on the LSBs, do these shift as the number of bits increases?16:15
maxpalni.e. for 32-bit bus is the LSB read from bits 4:2 of the address bus?16:16
maxpaln(and presumably bits 3:1 for 16-bit bus width16:16
maxpaln)16:16
stekernif your mem controller doesn't support wrapping bursts, it's probably best to have a 1 burst length cache16:16
stekernyes, increments are by bus datawidth16:17
maxpalngreat, thanks16:17
stekerni.e. it increases one word16:18
stekernthat's no different from non-wrapping bursts though16:18
maxpalnThe DDR3 bus interface is interesting - because the DDR3 itself is on a completely different clock domain (for a variety of reasons) to the wishbone bus the transactions are buffered through dual-clock FIFOs16:18
maxpalnso by the time the data is read from by the wishbone bus the FIFO already contains data from several address locations16:19
stekernyes, that sounds a lot like the xilinx ddr2 memory interface16:20
maxpalnat the moment the locations start at the first address given - i.e. the wishbone interface does not implement the wrap-4 style of bursts16:20
maxpalnimplementing a modified system that understands the wrap-4 structure shouldn't be that hard - it would involve adjusting the first address read from the DDR3 and then reading them into a local 'burst cache' in a single EBR or something equivalent16:22
maxpalnit's just a block of functionality that hasn't been implemented ...16:22
maxpalnbut this conversation has helped me to understand the best way to proceed now16:22
stekernah, so the ddr3 mem controller have a wb interface?16:23
stekernout of the box, I mean16:23
maxpalnno, the DDR3 controller has a generic interface - a wishbone interface has been bolted onto it.16:24
maxpalnwhich is useful - because I can go in and modify it without messing with the DDR3 controller16:24
stekernok, i see16:24
maxpalnin the interim, I have noticed I can disable bursts completely in or1200_defines.v - this should allow to get the basic functionality working at least, I can implement a more appropriate burst handling mechanism down the line16:24
--- Log closed Fri Nov 29 00:00:46 2013

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!