| --- Log opened Tue Dec 01 00:00:42 2015 | ||
| maxpaln | howdy all! I have a question that, on the face of it is pretty basic, but I haven't had to look at this section of code before... | 10:52 |
|---|---|---|
| maxpaln | I have OPTION_RESET_PC set as .OPTION_RESET_PC(32'hf0000100) | 10:56 |
| maxpaln | This is a hangover from the OR1200 days I think... | 10:56 |
| maxpaln | I have been reworking the bootrom.S file and have expended to need more address space - so now I have the problem that setting the address width to include the 9th bit means the ROM boots to address 0x40 instead of 0x0. I think the solution is to set the PC Reset Address to 0xF0000000 - but I am not sure if there is a reason why it should have been set to 0xF0000100 as above. | 10:58 |
| maxpaln | Any thoughts? | 10:58 |
| maxpaln | It is also set to 0xF0000100 on the Atlys but set to 0xF0000000 on the de0_nano examples in fusesoc. | 11:00 |
| maxpaln | I wonder if all the 0xF0000100 references are from designs ported from OR1200... | 11:00 |
| maxpaln | hmmm, I think I see the problem... | 11:18 |
| maxpaln | there must be an updated ROM file somewhere - I must have failed to update the ROM that I am using from the old or1200 version. The new one has a much more sensible system for controlling the address width... | 11:19 |
| maxpaln | hmmm, this is more curious - the de0_nano board uses a rom called wb_bootrom.v, I can't find this anywhere. The other systems I have checked all use the old or1200 rom.v with its funky address shifting system. | 11:23 |
| maxpaln | and these all have rom code small enough that there is no problem... | 11:24 |
| maxpaln | hmmm, well I have several solutions but I am not sure which is the most inline with the way the wb_intercon arbiter and the MOR1KX will work. The size of my rom is defined as plenty big enough in wb_intercon.conf (256). However, it is instantiated using some bit shifting of the address: | 11:35 |
| maxpaln | .wb_adr_i (wb_m2s_rom0_adr[(rom0_aw+2)-1:2]), | 11:36 |
| maxpaln | This works if rom0_aw is 6 or less (more by luck than judgement I think). | 11:36 |
| maxpaln | but once rom0_aw is set to 7 (or even 8 to match up with the width in wb_intercon.conf) then this address shifting makes a mess of the address. | 11:37 |
| maxpaln | my gut feeling is that the way the rom address is shifted in the instantiation is wrong. | 11:41 |
| maxpaln | but because the ROM is a 32-bit peripheral I see that the bit shifting is needed in order to honour the size of 256! | 11:43 |
| maxpaln | combined with the fact that the rom.v file uses the WB adr directly as the address into the bootrom.v file. | 11:44 |
| maxpaln | All in all there are a collection of wrongs here that somehow come out to a right as long as the ROM is less than 64 instructions!! | 11:45 |
| maxpaln | it seems that whoever wrote the de0_nano (_franck_?) also ran into this problem and solved it by setting the ROM address to 0xF0000000 and writing a new ROM. | 11:46 |
| maxpaln | looking at this file on github - this is how I would have solved it so I am guessing this is the solution used by the de0_nano authorL | 11:48 |
| maxpaln | https://github.com/olofk/or1k_bootloaders/blob/master/wb_bootrom.v | 11:48 |
| maxpaln | ah, it looks as though this is pretty recent... | 11:48 |
| _franck__ | maxpaln: I didn't write de0_nano. The fix in the de0_nano is recent GeneralStupid have had problem with that | 12:32 |
| maxpaln | _franck__: thanks - I guess you must have helped me out with a problem on the de0_nano before :-) | 12:34 |
| maxpaln | I have now fixed it by changing the reset address to 0xF0000000 instead of the original 0xF0000100 | 12:34 |
| maxpaln | the address bit shifting is, IMHO, messy the way I have currently implemented it, but is logically equivalent to the way it is done in the wb_bootrom.v example (which is a more elegant and intuitive solution I think). So, I'll live with it for now. | 12:36 |
| maxpaln | I wonder if anyone knows why the reset address was origianlly set to 0xF0000100 - I guess it was a straight shift of the reset vector at 0x100 to the rom address... | 12:36 |
| _franck__ | I think it is | 12:37 |
| maxpaln | in the bootrom are there any restrictions on the GPRs that I can use? the architecture manual describes reserved functions for several registers - do these apply for something as basic as the bootrom? I need more space than the defined general purpose registers permit... | 13:32 |
| via | will or1k fit on one of those 8k lattice ice chips? | 13:41 |
| maxpaln | via: interestingly olofk has done some work on that. I still owe him an eval board that I should have sent to him months ago (sorry olofk - no excuses) | 13:42 |
| via | well, i just bought one | 13:42 |
| via | lol | 13:42 |
| via | i just learnedabout the icestorm project | 13:43 |
| maxpaln | icestorm? | 13:44 |
| via | http://www.clifford.at/icestorm/ | 13:44 |
| via | complete verilog to bitstream floss stack | 13:44 |
| maxpaln | cool - although I am not sure our company would agree :-) | 13:47 |
| via | agree with what? | 13:47 |
| maxpaln | that reverse engineering the bitstream to create a parallel tool flow is cool | 13:51 |
| via | huh | 13:52 |
| via | well, i guess we disagree there. the lack of a floss stack has been a major impediment to a truly open platform imho | 13:52 |
| maxpaln | I didn't say it was my opinion - I think its cool. I can see management disagreeing though... | 13:53 |
| via | do you work for an fpga company? | 13:53 |
| maxpaln | Yes, Lattice. | 13:53 |
| via | oh, cool | 13:53 |
| via | ive never used lattice chips before, so this willbe my first | 13:54 |
| maxpaln | Personally, I think anything that increases interest in the devices is a good thing. | 13:54 |
| via | you all hiring? :p | 13:55 |
| maxpaln | The iCE chips have an unusual heritage - they also have a tool flow designed in the dark ages! They work fine though - just no bells and whistles! | 13:55 |
| via | yeah | 13:55 |
| maxpaln | An no, not hiring :-( just finished downsizing... :-( | 13:55 |
| via | they look pretty minimalistic, but thats not a bad thing | 13:55 |
| via | plus,those dev boards are insanely cheap | 13:56 |
| maxpaln | yep, the whole thing was designed to be a low cost and very small FPGA. We sell them into all sorts of places - smart phones, tablets, wearables. | 14:05 |
| maxpaln | Crazy really - FPGAs in a wearable! | 14:06 |
| maxpaln | some of the new ones have some cool blocks in them - DSPs, I2C and SPI Blocks - the newest one out soon even has a massive SRAM in there! | 14:20 |
| via | yeah, i'll definitely focus on them more now | 14:29 |
| LoneTech | maxpaln: only the link register and zero register have implementation details, you can use the rest as you want in your bootloader | 14:52 |
| maxpaln | LoneTech: Thanks :-) | 15:25 |
| --- Log closed Wed Dec 02 00:00:44 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!