| --- Log opened Mon Sep 01 00:00:32 2014 | ||
| maxpaln | quick question on the new adv_debug_sys top level - there is an output port called wb_cab_o, it isn't connected in either the atlys or de0_nano implementations. I can't see a reference to CAB in the wishbone spec so I'm not sure what to do with this signal. ANy cllues? | 08:54 |
|---|---|---|
| maxpaln | that should, of course, be a request for clues not cllues! | 08:54 |
| stekern | maxpaln: I'm not sure where that comes from, but there are references to wb_cab_o in or1200 | 08:59 |
| stekern | with a comment that says 'consecutive address burst' | 08:59 |
| stekern | https://github.com/openrisc/or1200/blob/master/rtl/verilog/or1200_wb_biu.v#L109 | 08:59 |
| stekern | maybe it was some custom extension they used before the bursting in wb b3 was defined(?) | 09:00 |
| maxpaln | maybe, perhaps I'll just leave it hanging for now. I am not in a position to test this at the moment but maybe I'll revisit it if the debugger doesn't work. | 09:03 |
| stekern | I have never came across anything that actively use it | 09:07 |
| maxpaln | ok, hopefully it won't become an issue!! | 09:12 |
| stekern | I highly doubt it will | 09:15 |
| olofk | I always assumed that the cab signal was just a tag that could be used to identify transactions | 11:28 |
| olofk | But as stekern said, no one seems to have ever used it for anything. At least not in the last five years | 11:29 |
| olofk | Or perhaps NSA uses that for wiretapping | 11:29 |
| olofk | This changes everything! | 11:30 |
| stekern | olofk: yes, I was also under the expression that it had something to do with tagging, but those signals are TGA, TGD and TGC | 11:32 |
| olofk | Ah yes. That's right | 11:32 |
| stekern | and as maxpaln said, there's nothing in the spec about CAB | 11:32 |
| olofk | Note to self. Never implement a bus standard with a lot of optional extensions | 11:32 |
| olofk | What's the magic option for offsetting an output file with objcopy? | 11:34 |
| stekern | {--change-addresses|--adjust-vma} | 11:38 |
| stekern | maybe? | 11:38 |
| olofk | Yes. That's it. Just got to that in the man page now | 11:38 |
| stekern | ok, so, you ask *first* and then start reading the documentation? =P | 11:39 |
| olofk | Nah, I had been reading it for a while without finding anything | 11:40 |
| olofk | hmm.. not quite there yet. IF I use a negative offset, the output file starts with the initial zeros moved to 0xffffff80 | 11:42 |
| olofk | So it's more like a rotate option | 11:42 |
| stekern | if the offset is negative and you have stuff at address 0, isn't it natural that that address become negative then? | 11:45 |
| olofk | Well, it's really only zeros from 0x0 to 0xff (standard or1k elf file) | 11:46 |
| olofk | What I could do is of course to remove .org 0x100 from the input asm, but what's the fun in that? | 11:46 |
| olofk | It's for generating boot ROM btw | 11:46 |
| stekern | I see | 11:47 |
| stekern | but why did an offset of -256 generate an inital start at -128? | 11:48 |
| stekern | initial | 11:48 |
| olofk | I just tested both | 11:48 |
| olofk | 0xffffff80 was probably for the -128 case | 11:48 |
| stekern | sneaky | 11:48 |
| olofk | Trying to get the theory of this... does .text start at 0x0 or 0x100? | 11:49 |
| stekern | .vectors start at 0x0 | 11:51 |
| stekern | but... I would cut those 256 bytes off from the binary instead | 11:54 |
| olofk | Yeah, I've been doing that | 11:54 |
| stekern | because, even if you *might* not want them in your rom, you probably want them in your preloaded SRAM | 11:55 |
| olofk | And since objdump can't output 32-bit verilog mem files anyway, I'll just finish my python script that takes a binary as input | 11:55 |
| olofk | true | 11:55 |
| olofk | But if I do objdump -x on my file, I don't see vectors anywhere | 11:56 |
| olofk | and .text, .data and .bss all start at 0x0 | 11:56 |
| stekern | what file do you have? | 12:01 |
| olofk | How do you mean? It's a elf compiled from asm with or1k-elf-as | 12:02 |
| stekern | ah, ok I assumed some or1k-elf-gcc compiled file when I mentioned .vectors | 12:03 |
| -!- Netsplit *.net <-> *.split quits: imphil, arokux, jeremypbennett | 13:48 | |
| -!- Netsplit over, joins: arokux, jeremypbennett | 13:48 | |
| maxpaln | Thigs are looking good - I have a pretty up to date version of all peripherals, wb_intercon and MOR1KX in the design now - my last checkout was a month ago so there may be a few differences but essentially making good progress. | 15:14 |
| maxpaln | I was looking at the various memory controllers - the de0_nano board uses an interesting looking port_arbiter to allow multipler wishbone connections to the same memory - I have a similar setup in my design but I am just using the RAM example that shipped with the OR1200 design. | 15:15 |
| maxpaln | I wou;dn't normally bother to look at this any further (since the version I have works in HW) but the code looks messy and the de0_nano version looks pretty efficient. I am also getting glitches in simulation from the version I am using - which is ugly. | 15:16 |
| olofk | maxpaln: Do you have an SDRAM on your board? | 15:16 |
| maxpaln | Nope, a DDR3 memory - | 15:17 |
| maxpaln | I can see that the port_arbiter is only for the sdram | 15:17 |
| maxpaln | but I more interested in the bit that allows multiple WB ports to access the same memory | 15:17 |
| olofk | Yes. We want to separate that eventually, but right now the frontend and backend is glued together | 15:17 |
| maxpaln | ah, ok | 15:18 |
| maxpaln | the wb_port_arbiter code looks pretty neat - and nicely scalable (which the code I am using at the moment definitely isn't). | 15:18 |
| maxpaln | But as I look into it I can see that it is pretty intitmately connected to the sdram controller. | 15:19 |
| olofk | Yes. The source code is poetry coming from stekern's hands | 15:19 |
| maxpaln | Wow - don't often get poetry references from a verilog file :-) | 15:19 |
| olofk | Definitely bonus points if you can make a nice split | 15:19 |
| maxpaln | Maybe I'll take a look once the immediate pressures of getting this code working are removed. | 15:20 |
| olofk | But if you're only looking for a way to share the memory between several masters, then wb_intercon will do that for you | 15:21 |
| olofk | The stuff in wb_sdram_ctrl does some extra things like caching to make the external accesses more efficient | 15:22 |
| maxpaln | ah, that's interesting - so in my case I have carried over the wrapper that is used with the ORPSOCV2 ram_wb component. | 15:25 |
| olofk | That one is pretty crappy | 15:25 |
| maxpaln | agreed! | 15:25 |
| maxpaln | so how would I setup the wb_intercon to mimic the same behaviour? | 15:25 |
| olofk | If you want a memory that maps to internal memory resources, I suggest using wb_ram instead | 15:25 |
| olofk | Sorry. Missed your last sentence | 15:26 |
| maxpaln | ah, ok - I don't actually want the internal RAM. But the wrapper that MUXed the intstruction and data busses onto the same memory peripheral was useful - and indeed still is. | 15:26 |
| olofk | I see | 15:26 |
| maxpaln | but if there is a way to get wb_intercon to do this bit then I would use it - the MUX wrapper is ugly code | 15:26 |
| olofk | Yes. wb_intercon can do that | 15:26 |
| maxpaln | great | 15:27 |
| olofk | Tiny example -> http://ff22c73f65a19cbe.paste.se/ | 15:27 |
| olofk | Basically, you create a slave port for the memory and let all the masters use it | 15:28 |
| maxpaln | so on your little example, on the 'mem' slave - how many wishbone ports would there be? | 15:30 |
| maxpaln | just one, presumably. | 15:30 |
| olofk | Yes | 15:30 |
| maxpaln | interestingly I have something very similar in my wb_intercon - but have explicitly connected both instruction and data bus ports to my individual inputs ports on the memory MUX wrapper. | 15:31 |
| olofk | You used the one from de0_nano for inspiration, right? | 15:32 |
| maxpaln | it sounds as though I can simplify all of this and just have a single wishbone port input to my DDR3 peripheral. | 15:32 |
| olofk | Yep | 15:32 |
| maxpaln | yep - the de0_nano looked like a good starting point - it's caused me a few headaches in the end :-) | 15:32 |
| olofk | The reason why there are two in the de0_nano is that the wb_sdram_ctrl in this case contains it's own arbiter that is probably mor efficient | 15:33 |
| olofk | So that one's a bit special | 15:33 |
| maxpaln | ah, ok | 15:33 |
| olofk | Other than that, the de0_nano is probably your best starting point :) | 15:33 |
| olofk | But beware if you do a fresh checkout. I changed things around a bit there last week | 15:33 |
| maxpaln | apart from the 8-bit to 32-bit resizing :-) | 15:33 |
| olofk | Haha. Right :) | 15:33 |
| maxpaln | but the de0_nano was indeed a very good reference - I am basically hooked up and running now. | 15:34 |
| maxpaln | I doubt i'll need to revisit the de0_nano now - my project is working although in an independant way to fusesoc | 15:34 |
| maxpaln | but this is a good staging point. Getting the code building in the fusesoc directory structure is probably the next one - then I can start to add support for our tools to the fusesoc system... | 15:35 |
| olofk | One of the main ideas with the FuseSoC flow is that you should be able to just use the parts that you want | 15:35 |
| maxpaln | yeah, I am sure I'll be asking some questions when it comes to adding support for our tools. | 15:38 |
| maxpaln | just looking at the way the wb_intercon has been hooked up based on my .conf file - | 15:38 |
| maxpaln | ah, I see where I have gone wrong | 15:38 |
| maxpaln | I have created two slaves - one for the ddr3_ibus and one for the ddr3_dbus | 15:39 |
| maxpaln | I just need to create one slave | 15:39 |
| olofk | That is not allowed in the free version of wb_intercon_gen. I demand that you send me money for the wb_intercon_gen EE edition | 15:39 |
| maxpaln | oh, yeah - of course, i'll upload my bank details now... | 15:40 |
| maxpaln | can you send me a suitably public website so I can maximise the potential for begin scammed... | 15:43 |
| olofk | I only deal in Fax and BBS | 15:44 |
| maxpaln | Fax will work, I'll scan my credit card now... | 15:45 |
| stekern | fidonet ftw | 16:04 |
| olofk | Great. It's just a regular +234 number | 16:22 |
| olofk | It's for our nigerian office | 16:22 |
| olofk | btw, maxpaln, you were planning to show up at orconf in Munich, right? | 16:23 |
| maxpaln | funnily enough, I was just looking at the plans. | 17:30 |
| maxpaln | Yes, I am planning on being there - it also sneaks into Q4 so getting budget approval will be much easier! :-) | 17:30 |
| olofk | quitter! | 17:45 |
| olofk | Has anyone had success with wb_ram in hardware? I remember blueCmd_ said something about the burst stuff not working | 17:45 |
| olofk | And my led blinker doesn't work when I put it in the wb_ram, but it works fine in simulations | 17:46 |
| stekern | olofk: I bet it's in the logs | 17:50 |
| stekern | do you have a de0 nano now btw? or what board are you playing with? | 17:50 |
| stekern | http://juliusbaxter.net/openrisc-irc/%23openrisc.2014-07-06.log.html#t08:20 | 17:51 |
| olofk | stekern: Yes. I have a de0_nano now. I'm actually doing paid OpenRISC work on it. Hope to tell more soon | 17:52 |
| stekern | cool! | 17:52 |
| olofk | I'm thinking of hooking up diila to see if I can find out what's going on with the burst stuff | 17:52 |
| stekern | the 'new_cycle' logic is definetely buggy, but apart from that, I couldn't find anything by just reading the code | 17:57 |
| olofk | Me neither. And it works in simulations | 17:59 |
| olofk | But when I debugged it for a spartan6, I noticed that there were some problems with some of the enable pins for the RAMs | 18:00 |
| stekern | adr = (wb_cti_i == 3'b010) & wb_ack ? next_adr : wb_adr_i; | 18:05 |
| stekern | is non-buggy, I think | 18:06 |
| stekern | wb_ack_o ;) | 18:06 |
| olofk | Looks like the memories are empty. Is there a handy memory inspector somewhere in quartus? | 18:15 |
| olofk | I'll try your solution and run through the sims btw | 18:21 |
| stekern | agenda for the tonights shift, add line-doubling to the vga_lcd core | 18:24 |
| olofk | cat * |wc -l tells me that it's 5010, so you expect to reach 10020 tonight? :) | 18:25 |
| stekern | not quite =P | 18:26 |
| olofk | Display each vertical line twice? | 18:27 |
| stekern | yes | 18:27 |
| stekern | and the horizontal | 18:28 |
| stekern | the vertical are trivial | 18:29 |
| olofk | Horizontal does sound very much harder. Is it? | 18:29 |
| olofk | s/does/doesn't | 18:29 |
| stekern | well, you have to buffer a complete line (or re-read it from mem) | 18:30 |
| olofk | ah ok | 18:30 |
| stekern | bah, this was kinda pointless... sw doesn't like resolutions < 640x400 anyway | 20:14 |
| --- Log closed Tue Sep 02 00:00:34 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!