| --- Log opened Mon Mar 31 00:00:44 2014 | ||
| -!- clopez_ is now known as clopez | 00:45 | |
| -!- Netsplit *.net <-> *.split quits: wkoszek_, ssvb | 01:13 | |
| -!- FreezingAlt is now known as FreezingCold | 02:03 | |
| stekern | olofk: with or without my pqtch? | 02:35 |
|---|---|---|
| stekern | patch | 02:35 |
| -!- Netsplit *.net <-> *.split quits: ssvb_ | 04:39 | |
| -!- Netsplit over, joins: ssvb_ | 04:46 | |
| olofk_ | stekern: Without your patch. It's a new core I have added locally. It's complaining about "localparam new_param = $clog2(param);" | 07:59 |
| olofk_ | It says that $clog2 can't be used in that context. I can't see why not | 07:59 |
| olofk_ | I could try to change all uses of new_param to use $clog2(param) directly instead and see if that helps | 08:00 |
| ysionneau | olofk_: which tool are you using? xilinx tools ? | 08:04 |
| olofk_ | ysionneau: Yes. Xilinx ISE. I've simulated the same thing with icarus and modelsim without any problems | 08:10 |
| ysionneau | so not Vivado | 08:10 |
| ysionneau | http://forums.xilinx.com/t5/Synthesis/clog2-fails-on-a-localparam/td-p/396105 && http://www.xilinx.com/support/answers/57984.html might be interesting for you | 08:10 |
| ysionneau | I guess it's the same issue with ISE | 08:11 |
| olofk_ | hahaha. Just found the exact same thing :) | 08:11 |
| olofk_ | Hmm.. so it seems that it will work if I tell Vivado that it's a systemverilog file. Have to try and see how ISE handles that | 08:13 |
| ysionneau | yes but it will not simulate :p | 08:13 |
| olofk_ | ysionneau: I saw that. Thankfully it's not a problem for FuseSoc :) | 08:14 |
| olofk_ | oh great. So System Verilog isn't supported at all by ISE? | 08:17 |
| olofk_ | Looks like stekern's patch will come in handy | 08:18 |
| ysionneau | Not sure :/ | 08:18 |
| olofk_ | stekern: Your patch helped solve my problem as well | 08:26 |
| olofk_ | But I think we should do something else than check for __ICARUS__. We really want to detect cases where we don't have system verilog support | 08:26 |
| olofk_ | Or perhaps just detect ISE, since that's the only tool that seems to fuck up | 08:27 |
| LoneTech | imho Xilinx breaking $clog2 is just wrong. the function is in Verilog-2005 | 08:53 |
| LoneTech | and explicitly defined to be usable for constant expressions such as parameters | 08:54 |
| LoneTech | well this is just ridiculous.. "For now I guess I will work around it by only using $clog2 in parameters, and not in localparams. I don't know why that works, but it does." | 08:55 |
| olofk_ | LoneTech: I agree. As you say it's not even a system verilog feature. Problem is that they probably treat ISE as a legacy tool now, so it's not going to be fixed | 08:59 |
| LoneTech | olofk_: this problem is older than the announcement of vivado, and still makes no sense | 09:12 |
| stekern | olofk_: $clog2 is not in sv, it's a verilog 2005 feature | 09:17 |
| stekern | ...as LoneTech just said, if I'd read to the end of the backlog before responding | 09:18 |
| stekern | but ISE (13.4 at least, where I had the problem) doesn't support verilog 2005, only 2001 | 09:19 |
| stekern | that they then evaluate it wrongly, that's outragous, but a different story... | 09:19 |
| LoneTech | and they still could support $clog2. specially breaking it is just daft, like Atmel's component library breaking 2-input LPM gates just because there are unparameterized versions | 09:20 |
| stekern | if they still can't handle it properly in releases where they claim to have verilog 2005 support, that's just another proof in the direction that their tools are inferior to other vendors... | 09:21 |
| stekern | LoneTech: yeah, agreed | 09:21 |
| stekern | olofk_: I'd be happy to have that patch only apply to ISE as well | 09:22 |
| stekern | do they emit some `define we can use? | 09:22 |
| LoneTech | http://forums.xilinx.com/t5/Synthesis/What-macros-does-XST-predefine-for-Verilog-code/td-p/154244 | 09:24 |
| LoneTech | unanswered | 09:24 |
| LoneTech | looks like it's down to defining things in your makefiles/project files/scripts | 09:25 |
| stekern | fusesoc ise/vivade builders can emit "XILINX_CRAP" defines I suppose | 09:32 |
| stekern | but that makes the code fusesoc specific :( | 09:32 |
| stekern | perhaps that's a common macro to define though | 09:33 |
| stekern | sadly the altera tools are crazy as well, they fail in mysterious ways if you use absolute paths in the project files... | 09:34 |
| stekern | and: https://github.com/skristiansson/eco32f/blob/master/rtl/verilog/eco32f_mmu.v#L128 | 09:35 |
| LoneTech | lovely | 09:36 |
| blueCmd | stekern: aren't there stanzas that you can use to tell the synthesis to not infer ram? | 09:50 |
| stekern | yes, but that doesn't help | 09:50 |
| blueCmd | oh | 09:50 |
| stekern | it's more down to some internal quartus optimisation thing, where it detect it as a "RAM type" of construct | 09:51 |
| stekern | and then it segfaults when it realises I try to read from it in a non RAMy way | 09:51 |
| stekern | or something like that ;) | 09:51 |
| blueCmd | ah, i'll accept that scientific thesis | 09:53 |
| stekern | so, my guess is that the 'stanzas' are applied some time after that | 09:53 |
| stekern | but, who knows, synthesis tool internals seems to mostly be a mixture of voodoo and black magic ;) | 09:54 |
| jungma | yes :D full of simulated annealing and ant algorithms :D | 10:02 |
| olofk_ | jungma: Baah.. It's probably just simulated activity and anti algorithms | 10:15 |
| jungma | olofk_: :D | 10:18 |
| olofk_ | Would __NAME_OF_TOOL__ be a good `define to use? Icarus appareantly already defines __ICARUS__, but I don't know if other tools do something similar | 10:20 |
| stekern | with "NAME_OF_TOOL" substituted with the actual name? | 10:32 |
| stekern | __XILINX_ISE__, __ALTERA_QUARTUS__ etc? | 10:33 |
| olofk_ | Yes | 10:35 |
| olofk_ | Oh. right. The other alternative would have been to have one define with different values | 10:36 |
| olofk_ | Hi mboehnert | 10:37 |
| olofk_ | Hi maxpaln | 10:37 |
| olofk_ | ...I mean | 10:37 |
| maxpaln | hi | 10:37 |
| blueCmd | olofk_: I would say to have __TOOL__ = 'QUARTUS' | 10:38 |
| blueCmd | or __TOOL__ = (QUARTUS, '13.1') | 10:38 |
| olofk_ | maxpaln: Does the Lattice tools set any verilog defines that can be used for tool-specific workarounds? | 10:38 |
| maxpaln | you mean implicitly? | 10:39 |
| olofk_ | blueCmd: Can you even do that last thing? | 10:39 |
| stekern | I don't think you can | 10:39 |
| blueCmd | or _TOOL_ = namedtuple(tool='Quartus',major_version=13, minor_version=1) (pseudo-code) | 10:39 |
| maxpaln | I am not sure - I would need to check, I haven't come across one but maybe | 10:39 |
| blueCmd | olofk_: well, is it python? :P | 10:39 |
| stekern | blueCmd: verilog | 10:39 |
| blueCmd | aha! | 10:39 |
| blueCmd | they my last thing certainly wouldn't work | 10:40 |
| olofk_ | maxpaln: Would be interesting to know. We are currently looking for some Xilinx-specific defines to workaround a synthesis issue | 10:40 |
| maxpaln | questoin from my side though - I was running some regressions on on the processor (orpsocv2) test suite with my ddr3 memory controller included | 10:41 |
| maxpaln | I found that the or1200-dsx test never completes - it just sits in a loop | 10:41 |
| maxpaln | looking at the assembler test file it looks as though this is expected behaviour when something isn't working | 10:41 |
| maxpaln | but iti isn't clear where I should start looking | 10:41 |
| maxpaln | anyone got any clues? | 10:41 |
| maxpaln | hmm, interesting - or1200-defines.v lists the following: | 10:43 |
| maxpaln | `define OR1200_SR_DSX 13// Unused | 10:43 |
| maxpaln | I am sure this test used to work though! | 10:43 |
| maxpaln | [puzzled of southampton!] | 10:43 |
| olofk_ | maxpaln: I have had issues with some of the tests as well | 10:47 |
| stekern | maxpaln: do you have this: http://opencores.org/websvn,diff?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2Forpsocv2%2Fsw%2Ftests%2For1200%2Fsim%2For1200-dsxinsn.S&rev=858 | 10:47 |
| olofk_ | One test required me to define a huge RAM, because it accessed some memory at quite high addresses | 10:48 |
| olofk_ | I might have written down some observations. Can look for them later tonight | 10:48 |
| maxpaln | olofk: thanks - that would be helpful | 10:51 |
| maxpaln | stekern: different test - I am running or1200-dsx.S | 10:52 |
| maxpaln | BUT ... that is missing from the or1200-dsxinsn.S file so I will add it :-) | 10:52 |
| olofk_ | Some of the issues I found took a while to track down, so I hope I still have those notes for my own sake :) | 10:54 |
| maxpaln | :-) | 10:54 |
| maxpaln | from your memory were they changes to the test or the design? trying to work out whether I have a design problem or not | 10:55 |
| olofk_ | Problem in most cases was that the test made assumptions about the design (caches, RAM size, available instructions, etc..) | 11:34 |
| olofk_ | So to answer your question if it was test or design.... I would have to say yes ;) | 11:34 |
| maxpaln | :-) | 11:37 |
| maxpaln | ok, pretty confused now - I can trace through the assembler and cross reference the instructions executed | 12:34 |
| maxpaln | but then I get a jump to a random address (0x600) to execture an instruction that doesn't appear in the assembler (l.mfspr r2, r16, 0020) | 12:35 |
| maxpaln | is there some implicit functionality in the processor that could cause this? | 12:35 |
| maxpaln | it definitely isn't coming from the test assembler | 12:36 |
| maxpaln | the weird thing is that this happens after a seemingly innocuous set of instructions: | 12:36 |
| maxpaln | l.movhir10,0 | 12:40 |
| maxpaln | l.lwzr1,1(r0) | 12:40 |
| maxpaln | l.orir10,r0,SPR_SR_DSX | 12:40 |
| maxpaln | or linked to the source file | 12:40 |
| maxpaln | ok, struggling to jump to lin number but it is this file: http://opencores.org/websvn,filedetails?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2Forpsocv2%2Fsw%2Ftests%2For1200%2Fsim%2For1200-dsx.S | 12:42 |
| maxpaln | the final instruction before the jump to the l.mfspr is the l.ori instruciton after the comment that reads: /* This test should_ set DSX, so put SPR_SR_DSX in r10 */ - its line 146 in my file | 12:42 |
| maxpaln | probably gonna come back to this unless there are any suggestoins - it is making my head hurt! | 12:43 |
| olofk_ | 0x600 is one of the exception vectors, right? | 12:47 |
| olofk_ | So you're getting an exception. Have to look up which exception, though | 12:48 |
| maxpaln | how can I determine which exception it was? | 12:49 |
| olofk_ | It's an alignment exception | 12:50 |
| olofk_ | http://opencores.org/websvn,filedetails?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2Fdocs%2Fopenrisc-arch-1.0-rev0.pdf | 12:50 |
| olofk_ | I searched for 0x600 | 12:50 |
| maxpaln | ah, I see | 12:50 |
| olofk_ | chapter 6.2 | 12:50 |
| maxpaln | I have that doc open anyway for the instrucitons -) | 12:51 |
| maxpaln | ok, got it | 12:51 |
| maxpaln | ah, ok - so if I understand correctly: I should be able to find the address of the instruction that caused the exception by looking at the EPCR | 12:54 |
| maxpaln | so the obvious next question - where does an orsoc newbie find the EPCR register? | 12:55 |
| maxpaln | ah, took a flyer, might have found it | 12:56 |
| maxpaln | or1200_top/or1200_cu/or1200_sprs/epcr | 12:57 |
| maxpaln | ok, back on track now - | 13:00 |
| maxpaln | thanks! | 13:00 |
| maxpaln | ah, even better - just look at the -executed.log file! | 13:03 |
| maxpaln | learning every day | 13:03 |
| maxpaln | :-) | 13:03 |
| stekern | it's old orpsocv2 knowledge though ;) | 13:08 |
| stekern | maxpaln: l.lwz r1,1(r0) | 13:12 |
| stekern | is unaligned | 13:12 |
| stekern | the test is forcing an unaligned exception, and then check if the DSX bit is correctly set | 13:12 |
| stekern | (or correctly not set) | 13:13 |
| maxpaln | aha - I think I have reached the same place as you olofk | 13:19 |
| maxpaln | I tracked through the exceptions - they are deliberately triggered by the dsx test | 13:20 |
| maxpaln | [suddenly the clouds parted] | 13:20 |
| maxpaln | everything goes swimingly until line 255 when this happens | 13:20 |
| maxpaln | l.lwzr1,-4(r0) | 13:20 |
| maxpaln | this causes a request to read from memory address 0xffffffc | 13:21 |
| maxpaln | which obviously doesn't exist - but the processor tries anyway | 13:21 |
| maxpaln | so I am guessing that this address range should be caught somewhere | 13:21 |
| stekern | ...and then the test expects a bus error to happen | 13:21 |
| maxpaln | the result is that X's are read from the memory and the infinite loop begins | 13:22 |
| maxpaln | stekern: yep - that is correct | 13:22 |
| stekern | in orpsocv2, they are usually triggered by a watchdog | 13:22 |
| maxpaln | ok... | 13:23 |
| stekern | maybe that's long, the simulation is slow and you're not waiting long enough? ;) | 13:23 |
| stekern | or then the x's confuses something somewhere | 13:23 |
| maxpaln | I left it 24 hours | 13:23 |
| maxpaln | :-) | 13:23 |
| maxpaln | but you could be right | 13:23 |
| maxpaln | so I guess my biggest concern is that have somehow disabled or broken something that should be catching this exception | 13:24 |
| stekern | there's a define for that watchdog somewhere | 13:24 |
| stekern | in orpsoc-defines.v | 13:24 |
| stekern | grep that and see what it does on other boards, and that it does the same thing on yours | 13:25 |
| maxpaln | well, it pretty much does the same thing - | 13:30 |
| maxpaln | my orpsoc-defines.v defines the same stuff (ARBITER_IBUS_WATCHDOG, ARBITER_DBUS_WATCHDOG ... | 13:30 |
| maxpaln | the biggest difference is that the Atyls and other Xilinx versions all increase the TIMER_WIDTH for the WATCHDOG when DDR is used | 13:31 |
| maxpaln | its a good tip for my board but I don't think that is causing the problems here | 13:31 |
| maxpaln | so either the watchdog isn't working as it should or I have broken something else :-) | 13:32 |
| maxpaln | hmm, the arbiter watchdog just looks like a timeout watchdog - there's no logic there for catching out-of-range addresses | 13:34 |
| olofk_ | maxpaln: Could it be that the other memory controllers return defined data on out-of-range accesses, and your returns xxxxxxxx? | 13:34 |
| maxpaln | yea, very possible - that is what I was thinking | 13:35 |
| olofk_ | And how does it handle wb_err? | 13:35 |
| maxpaln | when I have run this successfully it has been using a simple RAM (in fact the one that is part of the standard ORSOC distribution) that would generally be mapped into EBRs on the FPGA | 13:35 |
| maxpaln | ah, I see - | 13:36 |
| maxpaln | the finger is turning back towards me... | 13:36 |
| olofk_ | Stupid finger ;) | 13:36 |
| maxpaln | I hate it when it does that... | 13:36 |
| maxpaln | aha - and there it is | 13:37 |
| maxpaln | a little bit of logic to flag wb_err_o when an out of range memory is accessed | 13:37 |
| maxpaln | don't think I can escape this one - it's definitely squaring up on me now. | 13:38 |
| maxpaln | ok, one further question - this comment exists next to the address out of bounds logic in the RAM code | 13:46 |
| maxpaln | Error when out of bounds of memory - skip top nibble of address in case this is mapped somewhere other than 0x0. | 13:47 |
| maxpaln | I don't think I quite follow why this exists - and I'm wondering if I need to follow the same | 13:47 |
| maxpaln | the code looks like: | 13:47 |
| maxpaln | assign addr_err = wb_cyc_i & wb_stb_i & (|wb_adr_i[aw-1-4:mem_adr_width]); | 13:47 |
| maxpaln | which makes sense - | 13:48 |
| maxpaln | so it sounds as though provision has been made for allowing a subsectoin of the memory to be mapped to somewhere other than 0x0 | 13:48 |
| maxpaln | I haven't implemented this in my code - it doesn't seem like an obvious thing to do to me - but then I have stopped using that as a sensible argument a long time ago | 13:49 |
| stekern | I can't parse that comment at all... | 13:53 |
| stekern | where is it "skipping" the top nibble? | 13:54 |
| maxpaln | I think it is the "aw-1-4" | 13:55 |
| maxpaln | the -4 reduces the addr width by half a byte when comparing with the incoming addr | 13:55 |
| stekern | and where is this code? | 13:55 |
| stekern | in the arbiter or the RAM? | 13:55 |
| maxpaln | the code is ram_wb_b3.v line 215ish | 13:55 |
| maxpaln | I'll try and dig out a link | 13:55 |
| stekern | aha... | 13:55 |
| stekern | so, yeah, if you want to use SRAM at some high address (which you might) it shouldn't fail because of that | 13:56 |
| stekern | but otoh... why would you connect the upper bits to the module at all then...? | 13:57 |
| maxpaln | ok, I think I get what you are saying - it is in case the memory has been mapped to somewhere other than 0x0 in the orsoc-params.v | 13:58 |
| maxpaln | that makes sense, I guess | 13:58 |
| stekern | and why is the access to that address even ending up in your memory controller? | 13:58 |
| maxpaln | that was my biggest conundrum | 13:58 |
| maxpaln | if the access has ended up in the memory controller than the top part of the address must be correct | 13:59 |
| maxpaln | or matched | 13:59 |
| maxpaln | i think i will make an exective decision and not implement this code | 13:59 |
| maxpaln | I don't fully understand the reasoning and it would appear to be counter-intuitive | 14:00 |
| stekern | yeah, I don't have code like this in any of the mem controllers/mem controller wrappers | 14:00 |
| stekern | I've done | 14:00 |
| maxpaln | good point - I should have remembered that, after all they formed the basis of mine! | 14:00 |
| stekern | if out of bounds checking should be done, it should be in the arbiters | 14:01 |
| stekern | they should know about the boundaries, not the individual slaves | 14:01 |
| stekern | and how it's been done traditionally in orpsocv2, the access goes out in void and the access times out with the watchdog | 14:02 |
| stekern | ...but it might be that going out in void resolves into X's on wb_ack under some circumstances | 14:03 |
| maxpaln | well, I can see what you are saying - but I think that would require the orpsoc-params.v to include the details of the addressable memory range in the RAM itself, wouldn't it? | 14:04 |
| stekern | yeah, I can't remember how the arbitration worked in orpsocv2 | 14:05 |
| stekern | does it default to something? | 14:05 |
| maxpaln | well it appears to use the upper nibble/byte to map an address to the peripheral or memory | 14:05 |
| stekern | yes, and that 0xfff... shoudn't map to either | 14:05 |
| maxpaln | that's a good point - maybe I had misread how the memory address was being generated | 14:06 |
| maxpaln | I am definitely seeing a memory access to address 0xfffffffc appearing in the memory peripheral connected to the arbiter | 14:07 |
| maxpaln | just checking the simulator to see what address is actually being generated | 14:08 |
| olofk_ | That top nibble thing is an ugly orpsocv2 hack | 14:12 |
| stekern | yes | 14:12 |
| olofk_ | Please don't implement that :) | 14:12 |
| maxpaln | :-) | 14:12 |
| maxpaln | but you have raised an intersting questoin | 14:13 |
| maxpaln | why does address 0xfffffffc resolve to my memorty controller | 14:13 |
| maxpaln | ? | 14:13 |
| maxpaln | I think I have found the culprit - or at least part of it | 14:13 |
| stekern | I just checked how it's connected in the atlys board: http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/xilinx/atlys/rtl/verilog/arbiter/arbiter_dbus.v#n883 | 14:13 |
| maxpaln | aha - two answers in one :-) | 14:14 |
| stekern | there it defaults to slave 2, which is the byte bus | 14:14 |
| maxpaln | but - look at line 875! | 14:14 |
| maxpaln | http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/xilinx/atlys/rtl/verilog/arbiter/arbiter_dbus.v#n875 | 14:15 |
| stekern | and in the bytebus, if nothing matches, no wb_cyc_o/wb_cyc_stb is asserted | 14:15 |
| stekern | http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/xilinx/atlys/rtl/verilog/arbiter/arbiter_bytebus.v#n791 | 14:15 |
| maxpaln | ok, that makes sense but I think line 875 will triger wb_slave_sel[0] to be asserted | 14:15 |
| stekern | oh, right | 14:15 |
| maxpaln | let me check | 14:15 |
| stekern | that's the ROM | 14:16 |
| maxpaln | perhaps *supposed* to be the ROM | 14:16 |
| maxpaln | but then maybe the ROM would generate an error | 14:17 |
| olofk_ | I always found those orpsocv2 interconnects a bit....special case'y | 14:17 |
| stekern | yes, they are a complete mess | 14:18 |
| maxpaln | hmm, well - I have gone almost around in a full cirlc | 14:18 |
| maxpaln | conclusions: | 14:18 |
| maxpaln | 1. I need to implement some out of bounds checking in the memory controller | 14:18 |
| maxpaln | if it becomes redundant because of a more intelligent arbiter in the future than great, but it will be a good thing to implement anyway | 14:19 |
| stekern | no, just remove that special case from there... I bet the data bus never been connected to that anyway | 14:19 |
| stekern | but how has it worked for other boards..? | 14:19 |
| maxpaln | which brings me onto 2. | 14:19 |
| maxpaln | the arbiter would appear to expect to find the ROM at slave 0 - but none of the other boards are implemented this way, which | 14:20 |
| maxpaln | would suggest that accesses to address 0xff always map to slave 0, which appears to always be the memory controller | 14:20 |
| maxpaln | so the other memory controllers must implement some checking for accesses to a memory location which are not in range | 14:20 |
| stekern | no, just remove the special case, it's just plain wrong | 14:21 |
| maxpaln | I agree - and I will do. | 14:21 |
| olofk_ | maxpaln: Unless they are cutting of MSB of the address and wraps | 14:21 |
| maxpaln | [furrther explanation needed] | 14:22 |
| maxpaln | If I understand correctly: Unless the memory controller happens to fill the full address range there is always going to be a chance that an address location is read that does not map to a physical location | 14:23 |
| maxpaln | as the memory gets bigger the invalid range reduces in size but is always there | 14:23 |
| maxpaln | so some checking int he controller to ensure the address is within a physical range would seem like a good thing, right? | 14:24 |
| maxpaln | Is the full addressable memory range defined anywhere else? | 14:24 |
| stekern | sure, if you want that in your memory controller, it's not going to hurt. The others wrap | 14:25 |
| maxpaln | ah, I see - ok, so this is the piece of knowledge I was missing | 14:26 |
| maxpaln | mine definitely does not wrap | 14:26 |
| stekern | but... for your particular problem, the wrapping wouldn't gain the right results, because of the special case with the rom | 14:27 |
| maxpaln | yes, agreed | 14:27 |
| stekern | but let's put that aside | 14:27 |
| maxpaln | :-) | 14:27 |
| maxpaln | I definitely agree with you - I think the reason this test passed before is that the standard RAM controller implements out of range checking | 14:27 |
| stekern | IMO, the memory controller shouldn't now anything about ranges, the only restriction it can have in that regard is having lesser address bits | 14:28 |
| maxpaln | so instead of generating a bus error that particular line of assembler probably generated a RAM error (however that is defined) | 14:28 |
| stekern | and arbiters should know about ranges and generate out-of-bounds errors | 14:28 |
| maxpaln | do the newer arbiters do this? | 14:29 |
| stekern | s/now/know | 14:29 |
| stekern | yes | 14:29 |
| stekern | they do | 14:29 |
| maxpaln | aha - cool! | 14:29 |
| maxpaln | so presumably there would be a parameter to set for the addressable range? | 14:29 |
| stekern | https://github.com/openrisc/orpsoc-cores/blob/master/cores/wb_intercon/wb_mux.v#L116 | 14:30 |
| stekern | no, it's a lot fancier than that ;) | 14:30 |
| maxpaln | I expected nothing less | 14:30 |
| stekern | they are autogenerated from cfg files like this: https://github.com/openrisc/orpsoc-cores/blob/master/systems/or1200-generic/data/wb_intercon.conf | 14:31 |
| stekern | but, it boils down to parameters in the end | 14:31 |
| maxpaln | oooh, nice | 14:31 |
| maxpaln | I guess life will be easier when I can start moving this stuff over to the new code (or maybe not ;-) | 14:32 |
| maxpaln | but for at least the next month or so I need to keep going with the current code for this customer of mine | 14:32 |
| olofk_ | maxpaln: Yeah, you caught us at a bad time where the next generation of our build tools weren't mature enough. But porting the stuff later on shouldn't be too hard either | 14:34 |
| maxpaln | ah, no worries at all. | 14:34 |
| maxpaln | thanks for the debug help though - that would have taken me a LONG time to get to the bottom of | 14:38 |
| stekern | the atlys board port conversion I'm working ok didn't take many hours, if the $clog2 bug is excluded... | 14:40 |
| stekern | s/ok/on | 14:41 |
| analognoise | So is the ultimate Openrisc goal something like the Xilinx EDK? | 17:54 |
| olofk | analognoise: God no! | 17:59 |
| olofk | Have you used that piece of shit? | 18:00 |
| olofk | Sorry. My rage against that tool took overhand | 18:03 |
| olofk | To be honest, we are working on something that shares a lot of functionality with EDK, like making it easier to set up a system | 18:05 |
| stekern | but in a sane package ;) | 18:10 |
| analognoise | I was hoping you'd say that | 18:16 |
| analognoise | Currently I'm at the "it's really rather difficult" stage with the Openrisc, but I'd really rather have an open source processor/compiler toolchain (partially because it's retargetable) | 18:18 |
| analognoise | However there are some "core" items that really require items that aren't portable - picking the right type of structures to build a ddr3 memory controller, for example. You pay the price for admission with the EDK, but those are some nice items to have. | 18:20 |
| analognoise | Is there a preferred working topology for work like that that's underway? | 18:21 |
| analognoise | Like, Lattice, Xilinx, chips work with the non portable bits we have so far, type of thing. | 18:21 |
| olofk | analognoise: You still don't need EDK for that. For the Xilinx ports we have today, we have generated a memory controller with coregen and wrapped it in a wishbone interface | 18:21 |
| analognoise | olofk: That's great news! | 18:22 |
| analognoise | So the procedure would be similar to switch topologies | 18:22 |
| olofk | Not sure I follow you here | 18:22 |
| analognoise | Well I was looking at the Lattice parts, but everything we have is Xilinx based | 18:23 |
| analognoise | So if I wanted to get the same type of setup, I'd do the same: create a wishbone wrapper. | 18:23 |
| olofk | maxpaln is working on a wishbone wrapper for a Lattice memory controller | 18:24 |
| analognoise | Isn't the lattice memory controller IP a pay to play affair? Unless you make the whole thing yourself, which would be rather epic. | 18:24 |
| analognoise | olofk: That's also great news! | 18:25 |
| olofk | I have very little experience with lattice unfortunately | 18:25 |
| olofk | But I would like to see an open source DDR2/3 controller with only a thin technology-specific I/O layer | 18:26 |
| olofk | Most things like command queues and reordering could be done in generic HDL | 18:26 |
| stekern | olofk: I think someone used the memory controller in misoc and added a DDR2/3 layer ontop of it | 18:31 |
| olofk | stekern: Aha. Didn't know that | 18:34 |
| stekern | I don't know if it ever got finished though | 18:40 |
| stekern | but for DDR it has of course been used | 18:41 |
| stekern | I would like to do some experiments like that with with wb_sdram_ctrl | 18:41 |
| stekern | olofk: so a heads up, the pull-request I just posted (https://github.com/openrisc/orpsoc-cores/pull/45) depends on https://github.com/olofk/fusesoc/pull/28 | 18:53 |
| stekern | that's why I'm nagging about the latter ;) | 18:53 |
| olofk | oh sorry | 18:56 |
| olofk | I want to change one thing. Replace the export function with self.export_files = self.src_files + self.include_files. Ok with that? | 18:57 |
| olofk | hmm.. why list(src_files) btw? Isn't it a list already? | 18:58 |
| stekern | sure, I don't care so much, as long as it works ;) | 18:58 |
| olofk | How do I test it? | 18:58 |
| stekern | but why do you want the self.export_files? | 18:58 |
| olofk | No biggie. Just that it makes the sections a tiny bit thinner if they all do it like that, and I can easier change the export function if I want to | 18:59 |
| stekern | (list(src_files)) hmm, that might have been cargo-programming from my side... | 19:00 |
| olofk | stekern: Any ideas for testing? | 19:03 |
| stekern | (test it) pull in 45, see it fail without it, see it succeed with it | 19:03 |
| olofk | IIRC it had something to do with verilator not exporting if there wasn't a vpi section or something like that | 19:03 |
| olofk | c00l | 19:03 |
| olofk | side note.. why doesn't this get both commits from #45 after I fetched it? git cherry-pick 5e5111c..ca291ea | 19:09 |
| stekern | because (IMO) git cherry-pick syntax is broken | 19:11 |
| stekern | you need to do: git cherry-pick 5e5111c^..ca291ea | 19:11 |
| olofk | of course | 19:11 |
| olofk | not | 19:11 |
| olofk | #45 works fine with the fusesoc #22 request and my changes. I'm amending your patch and pushing it. Should I add a signoff? | 19:13 |
| stekern | #22? | 19:21 |
| stekern | I can't find that | 19:21 |
| olofk | sorry. #28 | 19:21 |
| olofk | ahh :) | 19:22 |
| olofk | #30 :) | 19:22 |
| stekern | ;) | 19:23 |
| olofk | I'm pushing what I have now | 19:24 |
| olofk | Oh no! I panicked and pushed an empty line. | 19:25 |
| stekern | as I said, I'm happy as long as it makes #45 works | 19:25 |
| stekern | heh, wut? | 19:26 |
| stekern | ah, ok, I see | 19:27 |
| olofk | Ah. but it's ok. It looks like it was you ;) | 19:27 |
| stekern | you're trying to increase the KLOCS by cheating | 19:27 |
| olofk | hahaha | 19:27 |
| stekern | haha, yes, so more KLOCS for me ;) | 19:27 |
| olofk | Got to go now | 19:28 |
| olofk | Don't send any more fucking pull requests. I'm drowning in those ;) | 19:29 |
| stekern | I don't think I have any fusesoc stuff right now | 19:29 |
| stekern | an atlys board and a sockit board port is pending for orpsoc-cores though | 19:29 |
| olofk | stekern _franck__ Do you have commit access to orpsoc-cores? I wouldn't mind if you pushed stuff there. Especially for the systems where I don't own any hw, and new cores | 19:30 |
| _franck__ | I think we have commit access | 19:31 |
| stekern | yes, at least I do, I can add _franck__ to orpsoc-cores if he hasn't | 19:31 |
| _franck__ | I need to add vhdl section and then I could push the NEEK board | 19:31 |
| _franck__ | (I'm afraid it will be without fb :( ) | 19:32 |
| stekern | maybe we still can do the pull-requests, just to give a hint about what we're about to push | 19:34 |
| _franck__ | yes I think we should do that as a review process | 19:34 |
| stekern | exactly | 19:35 |
| stekern | ok, I've added myself and fjullien to the "orpsoc" team now | 19:37 |
| olofk | good | 19:44 |
| olofk | It also seems like a priority queue would be good so we can get some stuff done. Apart from some general cleanup I have the ISE support that I'm working on. It's pretty stand-alone and ready to be pushed anytime soon, so it shouldn't interfere too much | 19:46 |
| olofk | _franck__: You have the VHDL additions. Anything else? | 19:46 |
| _franck__ | no | 19:47 |
| stekern | yes, and my atlys port of course depends on the ISE support, so I'm holding onto that until then | 19:47 |
| stekern | it's basically done, I need to test it some more just | 19:47 |
| olofk | _franck__: I think we are done with moving around the section stuff, so maybe it's a good time to add VHDL support now | 19:49 |
| _franck__ | ok, I'll do that asap | 19:50 |
| _franck__ | FYI, it is now possible to set TAP_TYPE from openocd command line with -c "set TAP_TYPE xxx" so no need to edit or1k-generic.cfg with you want to work with the VJTAG and MOHOR tap | 19:56 |
| _franck__ | and 0.8 relase is coming out with or1k support in your favorite Linux distribution | 19:57 |
| _franck__ | olofk: stekern : are we still keeping vpi and verilog sections out of the new "section" module ? | 20:02 |
| stekern | (openocd) great! | 20:09 |
| stekern | I'm always forgetting what file I should edit and wonder why things not working | 20:10 |
| olofk | _franck__: Great to hear about openocd | 20:51 |
| olofk | And I want vpi and verilog in section/__init__.py now. | 20:51 |
| olofk | Thinking about moving out ModelsimSection, IcarusSection and VerilatorSection to a separate simulator_sections.py if it grows too much | 20:52 |
| olofk | With the factory method in Section, we don't have to worry so much about the internal details of the section module | 20:53 |
| olofk | But I just came up with a new feature I want to push in section.py. But that can wait | 20:53 |
| _franck__ | stekern: as recompiling my system to add signal takes ages, I need your expertise on mor1kx behavior | 21:25 |
| _franck__ | https://www.dropbox.com/s/od04k68yguprxdr/problem.vcd | 21:26 |
| _franck__ | and the piece of the coresponding Linux disassembly code: http://pastie.org/private/slq4ovu3p582d0xuepz7g | 21:27 |
| _franck__ | at some point, it is stuck at c0003d94 (l.sfgeu r4,r5) and nothing happens | 21:27 |
| _franck__ | I'm just watching decode_insn_i | 21:28 |
| --- Log closed Tue Apr 01 00:00:45 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!