IRC logs for #openrisc Tuesday, 2015-12-01

--- Log opened Tue Dec 01 00:00:42 2015
maxpalnhowdy 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
maxpalnI have OPTION_RESET_PC set as    .OPTION_RESET_PC(32'hf0000100)10:56
maxpalnThis is a hangover from the OR1200 days I think...10:56
maxpalnI 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
maxpalnAny thoughts?10:58
maxpalnIt is also set to 0xF0000100 on the Atlys but set to 0xF0000000 on the de0_nano examples in fusesoc.11:00
maxpalnI wonder if all the 0xF0000100 references are from designs ported from OR1200...11:00
maxpalnhmmm, I think I see the problem...11:18
maxpalnthere 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
maxpalnhmmm, 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
maxpalnand these all have rom code small enough that there is no problem...11:24
maxpalnhmmm, 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
maxpalnThis works if rom0_aw is 6 or less (more by luck than judgement I think).11:36
maxpalnbut 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
maxpalnmy gut feeling is that the way the rom address is shifted in the instantiation is wrong.11:41
maxpalnbut 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
maxpalncombined with the fact that the rom.v file uses the WB adr directly as the address into the bootrom.v file.11:44
maxpalnAll 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
maxpalnit 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
maxpalnlooking 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 authorL11:48
maxpalnah, 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 that12:32
maxpaln_franck__: thanks - I guess you must have helped me out with a problem on the de0_nano before :-)12:34
maxpalnI have now fixed it by changing the reset address to 0xF0000000 instead of the original 0xF000010012:34
maxpalnthe 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
maxpalnI 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 is12:37
maxpalnin 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
viawill or1k fit on one of those 8k lattice ice chips?13:41
maxpalnvia: 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
viawell, i just bought one13:42
viai just learnedabout the icestorm project13:43
viacomplete verilog to bitstream floss stack13:44
maxpalncool - although I am not sure our company would agree :-)13:47
viaagree with what?13:47
maxpalnthat reverse engineering the bitstream to create a parallel tool flow is cool13:51
viawell, i guess we disagree there. the lack of a floss stack has been a major impediment to a truly open platform imho13:52
maxpalnI didn't say it was my opinion - I think its cool. I can see management disagreeing though...13:53
viado you work for an fpga company?13:53
maxpalnYes, Lattice.13:53
viaoh, cool13:53
viaive never used lattice chips before, so this willbe my first13:54
maxpalnPersonally, I think anything that increases interest in the devices is a good thing.13:54
viayou all hiring? :p13:55
maxpalnThe 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
maxpalnAn no, not hiring :-( just finished downsizing... :-(13:55
viathey look pretty minimalistic, but thats not a bad thing13:55
viaplus,those dev boards are insanely cheap13:56
maxpalnyep, 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
maxpalnCrazy really - FPGAs in a wearable!14:06
maxpalnsome 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
viayeah, i'll definitely focus on them more now14:29
LoneTechmaxpaln: only the link register and zero register have implementation details, you can use the rest as you want in your bootloader14:52
maxpalnLoneTech: Thanks :-)15:25
--- Log closed Wed Dec 02 00:00:44 2015

Generated by 2.15.2 by Marius Gedminas - find it at!