--- Log opened Fri Nov 13 00:00:07 2015 | ||
-!- Netsplit *.net <-> *.split quits: Pimster, poke53281 | 02:37 | |
-!- Netsplit over, joins: Pimster, poke53281 | 02:42 | |
hesham | olofk: Except for uart datawidth=8, everything is modified according to your comments. Please have a look. | 09:03 |
---|---|---|
olofk | hesham: Thanks. I'll pull the patch | 09:25 |
olofk | But wb_data_resize_must be fixed, because I think this won't work when we try to access registers with lsb != 00 | 09:26 |
hesham | olofk: Indeed. I had problems with GPIO also due to endianness | 09:27 |
hesham | And SPI... | 09:27 |
hesham | But that's for Atlys board not the Icarus one. | 09:27 |
olofk | Hmm.. so how to fix this? Should I swap sel, data or both? | 09:31 |
olofk | hesham: Just to be sure, you're using a little-endian wishbone bus? | 09:32 |
hesham | olofk: I am managing endianness by setting up the appropriate sel bits from vscale | 09:33 |
hesham | So yes, endianness is handled correctly from vscale side if that's what you mean. | 09:34 |
olofk | I'm getting headaches evertyime I think about endianness :) | 09:34 |
hesham | Same here | 09:34 |
hesham | I had to debug both SPI, UART, and sb/lb instructions due to this issue | 09:35 |
olofk | So... maybe it's enough to reverse sel in wb_data_resize to fix this | 09:35 |
hesham | And it's because of endianness | 09:35 |
olofk | I'm going to do a middle-endian CPU some day | 09:36 |
olofk | That will really mess things up | 09:36 |
hesham | Maybe a it's better to add an ENDIANNESS parameter or something | 09:36 |
olofk | Don't have time to look at this now, but I'll try to fix this asap. Help is appreciated from anyone who feels comfortable with endianness | 09:37 |
olofk | Yes, that's what I'm thinking. And a field in wb_intercon.conf to set this | 09:37 |
hesham | yes that would be better. | 09:38 |
hesham | Did you make other comments on the recent changes? | 09:38 |
olofk | Not yet. I'll take a quick look before I pull the patch | 09:39 |
hesham | OK, thanks for the comments. | 09:40 |
olofk | Looks good. Thanks for the patches. I'll pull it now | 09:41 |
hesham | Great! | 09:41 |
olofk | done | 09:43 |
hesham | I had a look at picorv32 core you added to see if it can work like vscale, but the core contains its own AXI-memory. | 09:43 |
hesham | The next steps maybe getting the SREC loader working. | 09:44 |
hesham | I am also thinking of adding the hello world assembly/C program to vscale-generic/sw like with the bootloader. | 09:44 |
olofk | hesham: Yeah, it would be nice to try the SREC loader in a testbench | 09:58 |
hesham | olofk: Would it work within a simulator? If so, I am not sure how it will get its input. I only tried it with minicom/FPGA. | 09:59 |
hesham | The Icarus UART core model doesn't support reading data I guess. | 10:00 |
olofk | hesham: There are probably a few options. I've been considering adding a VPI module that connects to a socket, so that you can send stuff over telnet to the simulator | 10:01 |
olofk | That's more or less how jtag_vpi works already | 10:02 |
olofk | Another option is to just read stimuli from a file | 10:02 |
olofk | But sockets are cooler :) | 10:02 |
hesham | I think that's similar to how or1ksim loads linux | 10:02 |
olofk | ...but more complicated | 10:02 |
hesham | Another option is to just get it running on FPGA :) | 10:03 |
olofk | haha. I've never been good at simple solutions :) | 10:03 |
olofk | But for debugging, it would be nice to simulate it | 10:04 |
hesham | Well, it works on Atlys, if you wanna give it a try let me know. | 10:04 |
hesham | Yeah sure, I've been debugging it using Atlys Leds only :/ | 10:05 |
olofk | Sure. I don't have an atlys board, but I definitely want to try it whenever we get a port to de0_nano or something like that | 10:05 |
olofk | The ordb2a board didn't even have LEDs. That was really annoying when nothing works at all | 10:05 |
hesham | And I thought debugging using LEDS was terrible... | 10:06 |
hesham | I think if we got an Atlys port running, it would just work on de0_nano. | 10:07 |
olofk | Yes. More or less | 10:07 |
hesham | It's a matter of rx, rd constraints only I guess | 10:07 |
hesham | And those have nothing to do with the core itself. | 10:07 |
olofk | hesham: An endianness question... when you use a byte-read instruction, do you expect the data to be in bits [7:0] or [31:24]? | 10:08 |
hesham | [7:0] | 10:08 |
olofk | Thanks | 10:08 |
hesham | That's why I set sel to 0x1 instead of 0x8 | 10:08 |
olofk | hmm... always [7:0], even if you read from address 0x1, 0x2 or 0x3? | 10:09 |
hesham | No | 10:09 |
hesham | It's shifted this time | 10:09 |
olofk | So address 0 => 7:0, 1 => 15:8, 2 => 23:16, 3 => 31:24 ? | 10:10 |
hesham | https://github.com/heshamelmatary/wb_riscvscale/blob/master/wb_vscale.v#L234 | 10:10 |
olofk | Just want to be really really sure :) | 10:10 |
hesham | Yes if you're loading/storing a byte | 10:11 |
hesham | SREC writes a big endian address too, so I had to handle this. | 10:12 |
olofk | hmm.. that link you sent me, it looks like sel can only be 1, 3 or f. Is that correct? | 10:12 |
hesham | For a read operation yes. | 10:14 |
wallento | olofk: are you ready for the next level of markdown? | 10:14 |
hesham | olofk: 1 -> lb, 2 -> lh/lhu and F -> lw | 10:14 |
olofk | Wishbone doesn't work like that. For a byte-read operation of an address, you need to set the two lower bits of the address to 00 and instead set the correct bit in the sel field | 10:15 |
olofk | wallento: That sounds really scary | 10:15 |
wallento | https://raw.githubusercontent.com/opensocdebug/slides/gh-pages/2015-11-12-overview/slides.md -> http://opensocdebug.github.io/slides/2015-11-12-overview | 10:15 |
olofk | hesham: , so for example, to read byte address 0x5e, you set address to 0x5c and sel to b0010 | 10:16 |
hesham | olofk: Yes, but since vscale core is doing the same operation, I had to keep wishbone work this way. | 10:16 |
hesham | vscale is loading the entire word and shifts it according to the load size | 10:17 |
hesham | I can disable this from vscale and make wishbone work as you say | 10:18 |
olofk | lunch now. bbl | 10:18 |
olofk | I think you need to change this, because it will not be compatible with wishbone slaves otherwise | 10:18 |
hesham | It's only done for memory read operation | 10:19 |
hesham | For UART, it's behaving like what you said, I had to disable it from vscale also. | 10:19 |
hesham | I'll see if that can be changed without breaking other operations. | 10:20 |
juliusb_ | stekern: ah, they're the pretty slides the hardcaml guy was using?! | 10:25 |
juliusb_ | Andy Ray | 10:25 |
juliusb_ | nice stuff | 10:26 |
stekern | juliusb_: ??? | 10:35 |
olofk | hesham: Hmm... there might actually be a bug in the memory controller then. It shouldn't allow byte accesses like that | 11:00 |
olofk | Need to look that up too | 11:00 |
olofk | stekern: You're good with wishbone byte-select stuff. Any comments? | 11:06 |
stekern | hmm, can you give a summary? | 11:07 |
stekern | haven't read the backlog today | 11:07 |
juliusb_ | stekern: whoops, that was meant for wallento! | 11:11 |
wallento | ah, yeah, I think he also used reveal.js | 11:12 |
wallento | quite easy to use and publish | 11:12 |
hesham | olofk: The vscale core issues the right address with the least significant two bits set to 00. https://github.com/heshamelmatary/vscale/blob/master/src/main/verilog/vscale_pipeline.v#L45 | 11:12 |
stekern | reveal.js is nice, yeah | 11:12 |
hesham | And then do the shift. This is the same as what a wishbone-interface does I think. | 11:13 |
stekern | yes, on a 32-bit wishbone interface, the two lsb's are don't care | 11:14 |
hesham | And they're used for setting sel bits right? | 11:15 |
stekern | used where? | 11:16 |
stekern | inside a wishbone master, they could be used to generate sel bits | 11:16 |
stekern | if the wishbone master internally generates addresses with 8-bit granularity | 11:17 |
hesham | stekern: Yes, from the vscale that acts as a wishbone master. | 11:51 |
hesham | gtg | 11:52 |
olofk | stekern: hesham's wb master generates byte accesses by setting sel = 0x1 and shifting the data 0, 8, 16 or 24 bis, if I have understood this correctly | 11:56 |
olofk | But my understanding of wb is that you don't shift the data, and instead set sel to 0x1, 0x2, 0x4 or ox8 | 11:56 |
stekern | yes | 11:57 |
stekern | how would the slave otherwise know what address you are trying to access? | 11:57 |
olofk | true | 12:01 |
hesham | olofk: OK, I can modify the vscale master core to comply with this behaviour. It's only the load instruction that behaves this way. | 13:37 |
andrzejr | olofk, does wb spec require 2 lsbs to be 0 or is it just a common practice? | 13:58 |
andrzejr | I am planning adding support for byte/half-word access to wb bfm. I assumed there is several ways to access the same address | 14:00 |
olofk | andrzejr: I remember that we had a discussion about this a while ago, and I'm not sure, but I think the conclusion was that the 2 lsb had to be zero. | 14:02 |
andrzejr | BTW, have you done any work on bfm recently? asking to avoid duplication of effort | 14:07 |
olofk | hesham: So you mean that the sel mask is ok on writes? | 14:08 |
olofk | andrzejr: No work done. Love to see some effort on the byte/half-word stuff | 14:09 |
hesham | olofk: Yes | 14:09 |
hesham | There's no shifting from the vscale this | 14:09 |
hesham | olofk: Could you double check please? https://github.com/heshamelmatary/wb_riscvscale/blob/master/wb_vscale.v#L204 | 14:10 |
hesham | Don't care about the half-word accesses for now, I fixed it on my local repo | 14:10 |
olofk | hesham: How is dmem size defined? Is it the number of bytes to read/write? | 14:12 |
hesham | Yes 0 for byte accesses | 14:12 |
olofk | ok, and 1 for 16-bit, 2 for 32-bit? | 14:12 |
hesham | olofk: https://github.com/heshamelmatary/wb_riscvscale/blob/master/vscale_ctrl_constants.vh#L34 | 14:13 |
hesham | Yes | 14:13 |
olofk | I think that looks fine (for byte accesses) | 14:13 |
olofk | Not sure about the endianness of course :) | 14:13 |
olofk | Maybe it's 8 >> dmem_addr[1:0] | 14:13 |
olofk | hmm.. is the sel mask generation the only thing that differs between a big-endian and little-endian master? | 14:14 |
hesham | Yeah, for half-word it would be "(dmem_size == 1 || dmem_size == 5)? 3 << (dmem_addr[1:0])" | 14:14 |
hesham | olofk: That's what I think so far. | 14:15 |
hesham | And it works fine with sb/sw with the srec loader | 14:15 |
hesham | And hello world, bootloader | 14:16 |
olofk | Cool | 14:16 |
olofk | Have you tried regenerating with datawidth=8? | 14:17 |
olofk | for the uart slave | 14:17 |
hesham | Yeah, and it fails. | 14:18 |
olofk | Still need to fix the endian selector there I guess | 14:39 |
hesham | olofk: Let me try to fix things from the vscale master core first, and see if this issue can be handled there. | 14:47 |
hesham | It would a workaround, so it's better to parametrize endianness from the wb_data_resize instead | 14:48 |
olofk | Agree | 14:57 |
olofk | But it would be good to know if it works with the workaround | 14:57 |
hesham | olofk: I've been trying but that's a headache | 15:14 |
hesham | If I want a byte from the memory for example, I've to shift it all the time because it's placed on the wrong MSB instead of the LSB order. | 15:16 |
hesham | From little endian perspective :/ | 15:17 |
-!- _franck__ is now known as _franck_ | 19:48 | |
--- Log closed Sat Nov 14 00:00:09 2015 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!