| --- Log opened Thu Nov 28 00:00:44 2013 | ||
| maxpaln | Hi - 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 |
|---|---|---|
| rah | maxpaln: there are people around | 14:15 |
| rah | maxpaln: ask your question and wait | 14:15 |
| rah | maxpaln: someone should answer eventually | 14:15 |
| rah | maxpaln: also, that is very good news if Lattice is sponsoring work on porting openrisc | 14:17 |
| rah | maxpaln: please congratulate your employers for taking a step in the right direction :-) | 14:17 |
| maxpaln | :-) | 14:46 |
| maxpaln | thanks - good to hear there are people out there. | 14:46 |
| maxpaln | I have made a lot of progress, it works in general - | 14:46 |
| maxpaln | however, 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 |
| maxpaln | as 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 |
| maxpaln | CTI_I="010" indicating an incrementing burst. BTE_I is "01" indicating a 'wrap 4' style increment | 14:49 |
| maxpaln | but the address order from the OR1200 is as follows: | 14:50 |
| maxpaln | 254C | 14:50 |
| maxpaln | 2540 | 14:50 |
| maxpaln | 2544 | 14:50 |
| maxpaln | 2548 | 14:50 |
| maxpaln | all hex values | 14:50 |
| maxpaln | This 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 |
| maxpaln | ideally I'd like to set the burst type to linear and I'd have no more problems. | 14:52 |
| _franck_w_ | hi maxpaln | 14:54 |
| maxpaln | hi | 14: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 questions | 14:56 |
| maxpaln | ok - 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 |
| maxpaln | provide a distribution of the ORSOC that is supported on one of our lowish cost eval boards for our ECP3 family | 14:59 |
| maxpaln | the driver is a specific customer request that has allowed me to do set time aside for the work | 14:59 |
| _franck_w_ | ok great | 15:00 |
| maxpaln | I 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 curce | 15:00 |
| maxpaln | curve | 15:00 |
| _franck_w_ | orpsocv3 doesn't support lattice workflow for now but that would be great if you can do the job | 15:01 |
| maxpaln | I have a lot of the design working - but the burst reads are not working at all | 15:01 |
| maxpaln | yeah - agreed | 15:01 |
| _franck_w_ | what's the problem with burst read ? did you simulate it ? | 15:04 |
| maxpaln | yep, a LOT of simulation - in fact pretty much exclusively in simulatoin although I have confirmned the problem in HW too | 15:05 |
| maxpaln | the 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 address | 15:05 |
| maxpaln | so a wishbone burst read that goes something like this is fine: 0x2540, 0x2544, 0x2548, 0x254C | 15:06 |
| maxpaln | However, 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 addresses | 15:07 |
| maxpaln | 0x254c, 0x2540, 0x2544, 0x2548 | 15:07 |
| maxpaln | this 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 defined | 15: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 know | 15:27 |
| _franck_w_ | may be that you should implement some cache memory in your DDR controller and support burst wrap on this cached memory | 15:28 |
| maxpaln | well, 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 |
| maxpaln | I 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 up | 15:32 |
| maxpaln | I 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 |
| maxpaln | But 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 |
| rokka | hello, 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-3 | 15:38 |
| _franck_w_ | I mean bits [4..2] since there is 3 bits in the table | 15: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 that | 15:40 |
| maxpaln | ah, that's an interesting point - since the byte width is 4 maybe bits 1 and 0 are ignored | 15:42 |
| maxpaln | it'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 |
| maxpaln | yeah, I was just reading that myself | 15:43 |
| _franck_w_ | so "0-1-2-3-4-5-6-7" represents increments so it has to be x4 for a 32 bits bus | 15:43 |
| _franck_w_ | ok | 15:44 |
| maxpaln | yep, I see that bit - it's the LSB column which isn't quite clear | 15:44 |
| _franck_w_ | true, it's not clear | 15:45 |
| maxpaln | but 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 anywhere | 15:45 |
| maxpaln | I 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 soon | 16:03 |
| stekern | maxpaln: 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 four | 16:13 |
| stekern | and the wrapping point can be by 4 or 8 (or 16 iirc, but or1200 doesn't use that) | 16:14 |
| maxpaln | Hi stekern, thanks - yes I had come to that conclusion. | 16:15 |
| stekern | the wrapping point (burst length) is communicated over the bus | 16:15 |
| maxpaln | the outstanding query now is on the LSBs, do these shift as the number of bits increases? | 16:15 |
| maxpaln | i.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 width | 16:16 |
| maxpaln | ) | 16:16 |
| stekern | if your mem controller doesn't support wrapping bursts, it's probably best to have a 1 burst length cache | 16:16 |
| stekern | yes, increments are by bus datawidth | 16:17 |
| maxpaln | great, thanks | 16:17 |
| stekern | i.e. it increases one word | 16:18 |
| stekern | that's no different from non-wrapping bursts though | 16:18 |
| maxpaln | The 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 FIFOs | 16:18 |
| maxpaln | so by the time the data is read from by the wishbone bus the FIFO already contains data from several address locations | 16:19 |
| stekern | yes, that sounds a lot like the xilinx ddr2 memory interface | 16:20 |
| maxpaln | at the moment the locations start at the first address given - i.e. the wishbone interface does not implement the wrap-4 style of bursts | 16:20 |
| maxpaln | implementing 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 equivalent | 16:22 |
| maxpaln | it's just a block of functionality that hasn't been implemented ... | 16:22 |
| maxpaln | but this conversation has helped me to understand the best way to proceed now | 16:22 |
| stekern | ah, so the ddr3 mem controller have a wb interface? | 16:23 |
| stekern | out of the box, I mean | 16:23 |
| maxpaln | no, the DDR3 controller has a generic interface - a wishbone interface has been bolted onto it. | 16:24 |
| maxpaln | which is useful - because I can go in and modify it without messing with the DDR3 controller | 16:24 |
| stekern | ok, i see | 16:24 |
| maxpaln | in 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 line | 16: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!