IRC logs for #openrisc Monday, 2014-03-31

--- Log opened Mon Mar 31 00:00:44 2014
-!- clopez_ is now known as clopez00:45
-!- Netsplit *.net <-> *.split quits: wkoszek_, ssvb01:13
-!- FreezingAlt is now known as FreezingCold02:03
stekernolofk: with or without my pqtch?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 not07:59
olofk_I could try to change all uses of new_param to use $clog2(param) directly instead and see if that helps08:00
ysionneauolofk_: 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 problems08:10
ysionneauso not Vivado08:10
ysionneau && might be interesting for you08:10
ysionneauI guess it's the same issue with ISE08: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 that08:13
ysionneauyes but it will not simulate :p08: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 handy08:18
ysionneauNot sure :/08:18
olofk_stekern: Your patch helped solve my problem as well08: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 support08:26
olofk_Or perhaps just detect ISE, since that's the only tool that seems to fuck up08:27
LoneTechimho Xilinx breaking $clog2 is just wrong. the function is in Verilog-200508:53
LoneTechand explicitly defined to be usable for constant expressions such as parameters08:54
LoneTechwell 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 fixed08:59
LoneTecholofk_: this problem is older than the announcement of vivado, and still makes no sense09:12
stekernolofk_: $clog2 is not in sv, it's a verilog 2005 feature09:17 LoneTech just said, if I'd read to the end of the backlog before responding09:18
stekernbut ISE (13.4 at least, where I had the problem) doesn't support verilog 2005, only 200109:19
stekernthat they then evaluate it wrongly, that's outragous, but a different story...09:19
LoneTechand 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 versions09:20
stekernif 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
stekernLoneTech: yeah, agreed09:21
stekernolofk_: I'd be happy to have that patch only apply to ISE as well09:22
stekerndo they emit some `define we can use?09:22
LoneTechlooks like it's down to defining things in your makefiles/project files/scripts09:25
stekernfusesoc ise/vivade builders can emit "XILINX_CRAP" defines I suppose09:32
stekernbut that makes the code fusesoc specific :(09:32
stekernperhaps that's a common macro to define though09:33
stekernsadly the altera tools are crazy as well, they fail in mysterious ways if you use absolute paths in the project files...09:34
blueCmdstekern: aren't there stanzas that you can use to tell the synthesis to not infer ram?09:50
stekernyes, but that doesn't help09:50
stekernit's more down to some internal quartus optimisation thing, where it detect it as a "RAM type" of construct09:51
stekernand then it segfaults when it realises I try to read from it in a non RAMy way09:51
stekernor something like that ;)09:51
blueCmdah, i'll accept that scientific thesis09:53
stekernso, my guess is that the 'stanzas' are applied some time after that09:53
stekernbut, who knows, synthesis tool internals seems to mostly be a mixture of voodoo and black magic ;)09:54
jungmayes :D full of simulated annealing and ant algorithms :D10:02
olofk_jungma: Baah.. It's probably just simulated activity and anti algorithms10:15
jungmaolofk_: :D10: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 similar10:20
stekernwith "NAME_OF_TOOL" substituted with the actual name?10:32
stekern__XILINX_ISE__, __ALTERA_QUARTUS__ etc?10:33
olofk_Oh. right. The other alternative would have been to have one define with different values10:36
olofk_Hi mboehnert10:37
olofk_Hi maxpaln10:37
olofk_...I mean10:37
blueCmdolofk_: I would say to have __TOOL__ = 'QUARTUS'10:38
blueCmdor __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
maxpalnyou mean implicitly?10:39
olofk_blueCmd: Can you even do that last thing?10:39
stekernI don't think you can10:39
blueCmdor _TOOL_ = namedtuple(tool='Quartus',major_version=13, minor_version=1) (pseudo-code)10:39
maxpalnI am not sure - I would need to check, I haven't come across one but maybe10:39
blueCmdolofk_: well, is it python? :P10:39
stekernblueCmd: verilog10:39
blueCmdthey my last thing certainly wouldn't work10:40
olofk_maxpaln: Would be interesting to know. We are currently looking for some Xilinx-specific defines to workaround a synthesis issue10:40
maxpalnquestoin from my side though - I was running some regressions on on the processor (orpsocv2) test suite with my ddr3 memory controller included10:41
maxpalnI found that the or1200-dsx test never completes - it just sits in a loop10:41
maxpalnlooking at the assembler test file it looks as though this is expected behaviour when something isn't working10:41
maxpalnbut iti isn't clear where I should start looking10:41
maxpalnanyone got any clues?10:41
maxpalnhmm, interesting - or1200-defines.v lists the following:10:43
maxpaln`define OR1200_SR_DSX  13// Unused10:43
maxpalnI 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 well10:47
stekernmaxpaln: do you have this:,diff?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2Forpsocv2%2Fsw%2Ftests%2For1200%2Fsim%2For1200-dsxinsn.S&rev=85810:47
olofk_One test required me to define a huge RAM, because it accessed some memory at quite high addresses10:48
olofk_I might have written down some observations. Can look for them later tonight10:48
maxpalnolofk: thanks - that would be helpful10:51
maxpalnstekern: different test - I am running or1200-dsx.S10:52
maxpalnBUT ... 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
maxpalnfrom your memory were they changes to the test or the design? trying to work out whether I have a design problem or not10: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
maxpalnok, pretty confused now - I can trace through the assembler and cross reference the instructions executed12:34
maxpalnbut 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
maxpalnis there some implicit functionality in the processor that could cause this?12:35
maxpalnit definitely isn't coming from the test assembler12:36
maxpalnthe weird thing is that this happens after a seemingly innocuous set of instructions:12:36
maxpalnor linked to the source file12:40
maxpalnok, struggling to jump to lin number but it is this file:,filedetails?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2Forpsocv2%2Fsw%2Ftests%2For1200%2Fsim%2For1200-dsx.S12:42
maxpalnthe 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 file12:42
maxpalnprobably 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, though12:48
maxpalnhow can I determine which exception it was?12:49
olofk_It's an alignment exception12:50
olofk_I searched for 0x60012:50
maxpalnah, I see12:50
olofk_chapter 6.212:50
maxpalnI have that doc open anyway for the instrucitons -)12:51
maxpalnok, got it12:51
maxpalnah, 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 EPCR12:54
maxpalnso the obvious next question - where does an orsoc newbie find the EPCR register?12:55
maxpalnah, took a flyer, might have found it12:56
maxpalnok, back on track now -13:00
maxpalnah, even better - just look at the -executed.log file!13:03
maxpalnlearning every day13:03
stekernit's old orpsocv2 knowledge though ;)13:08
stekernmaxpaln: l.lwz r1,1(r0)13:12
stekernis unaligned13:12
stekernthe test is forcing an unaligned exception, and then check if the DSX bit is correctly set13:12
stekern(or correctly not set)13:13
maxpalnaha - I think I have reached the same place as you olofk13:19
maxpalnI tracked through the exceptions - they are deliberately triggered by the dsx test13:20
maxpaln[suddenly the clouds parted]13:20
maxpalneverything goes swimingly until line 255 when this happens13:20
maxpalnthis causes a request to read from memory address 0xffffffc13:21
maxpalnwhich obviously doesn't exist - but the processor tries anyway13:21
maxpalnso I am guessing that this address range should be caught somewhere13:21
stekern...and then the test expects a bus error to happen13:21
maxpalnthe result is that X's are read from the memory and the infinite loop begins13:22
maxpalnstekern: yep - that is correct13:22
stekernin orpsocv2, they are usually triggered by a watchdog13:22
stekernmaybe that's long, the simulation is slow and you're not waiting long enough? ;)13:23
stekernor then the x's confuses something somewhere13:23
maxpalnI left it 24 hours13:23
maxpalnbut you could be right13:23
maxpalnso I guess my biggest concern is that have somehow disabled or broken something that should be catching this exception13:24
stekernthere's a define for that watchdog somewhere13:24
stekernin orpsoc-defines.v13:24
stekerngrep that and see what it does on other boards, and that it does the same thing on yours13:25
maxpalnwell, it pretty much does the same thing -13:30
maxpalnmy orpsoc-defines.v defines the same stuff (ARBITER_IBUS_WATCHDOG, ARBITER_DBUS_WATCHDOG ...13:30
maxpalnthe biggest difference is that the Atyls and other Xilinx versions all increase the TIMER_WIDTH for the WATCHDOG when DDR is used13:31
maxpalnits a good tip for my board but I don't think that is causing the problems here13:31
maxpalnso either the watchdog isn't working as it should or I have broken something else :-)13:32
maxpalnhmm, the arbiter watchdog just looks like a timeout watchdog - there's no logic there for catching out-of-range addresses13: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
maxpalnyea, very possible - that is what I was thinking13:35
olofk_And how does it handle wb_err?13:35
maxpalnwhen 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 FPGA13:35
maxpalnah, I see -13:36
maxpalnthe finger is turning back towards me...13:36
olofk_Stupid finger ;)13:36
maxpalnI hate it when it does that...13:36
maxpalnaha - and there it is13:37
maxpalna little bit of logic to flag wb_err_o when an out of range memory is accessed13:37
maxpalndon't think I can escape this one - it's definitely squaring up on me now.13:38
maxpalnok, one further question - this comment exists next to the address out of bounds logic in the RAM code13:46
maxpalnError when out of bounds of memory - skip top nibble of address in case this is mapped somewhere other than 0x0.13:47
maxpalnI don't think I quite follow why this exists - and I'm wondering if I need to follow the same13:47
maxpalnthe code looks like:13:47
maxpalnassign addr_err  = wb_cyc_i & wb_stb_i & (|wb_adr_i[aw-1-4:mem_adr_width]);13:47
maxpalnwhich makes sense -13:48
maxpalnso it sounds as though provision has been made for allowing a subsectoin of the memory to be mapped to somewhere other than 0x013:48
maxpalnI 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 ago13:49
stekernI can't parse that comment at all...13:53
stekernwhere is it "skipping" the top nibble?13:54
maxpalnI think it is the "aw-1-4"13:55
maxpalnthe -4 reduces the addr width by half a byte when comparing with the incoming addr13:55
stekernand where is this code?13:55
stekernin the arbiter or the RAM?13:55
maxpalnthe code is ram_wb_b3.v line 215ish13:55
maxpalnI'll try and dig out a link13:55
stekernso, yeah, if you want to use SRAM at some high address (which you might) it shouldn't fail because of that13:56
stekernbut otoh... why would you connect the upper bits to the module at all then...?13:57
maxpalnok, 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.v13:58
maxpalnthat makes sense, I guess13:58
stekernand why is the access to that address even ending up in your memory controller?13:58
maxpalnthat was my biggest conundrum13:58
maxpalnif the access has ended up in the memory controller than the top part of the address must be correct13:59
maxpalnor matched13:59
maxpalni think i will make an exective decision and not implement this code13:59
maxpalnI don't fully understand the reasoning and it would appear to be counter-intuitive14:00
stekernyeah, I don't have code like this in any of the mem controllers/mem controller wrappers14:00
stekernI've done14:00
maxpalngood point - I should have remembered that, after all they formed the basis of mine!14:00
stekernif out of bounds checking should be done, it should be in the arbiters14:01
stekernthey should know about the boundaries, not the individual slaves14:01
stekernand how it's been done traditionally in orpsocv2, the access goes out in void and the access times out with the watchdog14:02
stekern...but it might be that going out in void resolves into X's on wb_ack under some circumstances14:03
maxpalnwell, 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
stekernyeah, I can't remember how the arbitration worked in orpsocv214:05
stekerndoes it default to something?14:05
maxpalnwell it appears to use the upper nibble/byte to map an address to the peripheral or memory14:05
stekernyes, and that 0xfff... shoudn't map to either14:05
maxpalnthat's a good point - maybe I had misread how the memory address was being generated14:06
maxpalnI am definitely seeing a memory access to address 0xfffffffc appearing in the memory peripheral connected to the arbiter14:07
maxpalnjust checking the simulator to see what address is actually being generated14:08
olofk_That top nibble thing is an ugly orpsocv2 hack14:12
olofk_Please don't implement that :)14:12
maxpalnbut you have raised an intersting questoin14:13
maxpalnwhy does address 0xfffffffc resolve to my memorty controller14:13
maxpalnI think I have found the culprit - or at least part of it14:13
stekernI just checked how it's connected in the atlys board:
maxpalnaha - two answers in one :-)14:14
stekernthere it defaults to slave 2, which is the byte bus14:14
maxpalnbut - look at line 875!14:14
stekernand in the bytebus, if nothing matches, no wb_cyc_o/wb_cyc_stb is asserted14:15
maxpalnok, that makes sense but I think line 875 will triger wb_slave_sel[0] to be asserted14:15
stekernoh, right14:15
maxpalnlet me check14:15
stekernthat's the ROM14:16
maxpalnperhaps *supposed* to be the ROM14:16
maxpalnbut then maybe the ROM would generate an error14:17
olofk_I always found those orpsocv2 interconnects a bit....special case'y14:17
stekernyes, they are a complete mess14:18
maxpalnhmm, well - I have gone almost around in a full cirlc14:18
maxpaln1. I need to implement some out of bounds checking in the memory controller14:18
maxpalnif it becomes redundant because of a more intelligent arbiter in the future than great, but it will be a good thing to implement anyway14:19
stekernno, just remove that special case from there... I bet the data bus never been connected to that anyway14:19
stekernbut how has it worked for other boards..?14:19
maxpalnwhich brings me onto 2.14:19
maxpalnthe arbiter would appear to expect to find the ROM at slave 0 - but none of the other boards are implemented this way, which14:20
maxpalnwould suggest that accesses to address 0xff always map to slave 0, which appears to always be the memory controller14:20
maxpalnso the other memory controllers must implement some checking for accesses to a memory location which are not in range14:20
stekernno, just remove the special case, it's just plain wrong14:21
maxpalnI agree - and I will do.14:21
olofk_maxpaln: Unless they are cutting of MSB of the address and wraps14:21
maxpaln[furrther explanation needed]14:22
maxpalnIf 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 location14:23
maxpalnas the memory gets bigger the invalid range reduces in size but is always there14:23
maxpalnso some checking int he controller to ensure the address is within a physical range would seem like a good thing, right?14:24
maxpalnIs the full addressable memory range defined anywhere else?14:24
stekernsure, if you want that in your memory controller, it's not going to hurt. The others wrap14:25
maxpalnah, I see - ok, so this is the piece of knowledge I was missing14:26
maxpalnmine definitely does not wrap14:26
stekernbut... for your particular problem, the wrapping wouldn't gain the right results, because of the special case with the rom14:27
maxpalnyes, agreed14:27
stekernbut let's put that aside14:27
maxpalnI definitely agree with you - I think the reason this test passed before is that the standard RAM controller implements out of range checking14:27
stekernIMO, the memory controller shouldn't now anything about ranges, the only restriction it can have in that regard is having lesser address bits14:28
maxpalnso instead of generating a bus error that particular line of assembler probably generated a RAM error (however that is defined)14:28
stekernand arbiters should know about ranges and generate out-of-bounds errors14:28
maxpalndo the newer arbiters do this?14:29
stekernthey do14:29
maxpalnaha - cool!14:29
maxpalnso presumably there would be a parameter to set for the addressable range?14:29
stekernno, it's a lot fancier than that ;)14:30
maxpalnI expected nothing less14:30
stekernthey are autogenerated from cfg files like this:
stekernbut, it boils down to parameters in the end14:31
maxpalnoooh, nice14:31
maxpalnI guess life will be easier when I can start moving this stuff over to the new code (or maybe not ;-)14:32
maxpalnbut for at least the next month or so I need to keep going with the current code for this customer of mine14: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 either14:34
maxpalnah, no worries at all.14:34
maxpalnthanks for the debug help though - that would have taken me a LONG time to get to the bottom of14:38
stekernthe atlys board port conversion I'm working ok didn't take many hours, if the $clog2 bug is excluded...14:40
analognoiseSo is the ultimate Openrisc goal something like the Xilinx EDK?17:54
olofkanalognoise: God no!17:59
olofkHave you used that piece of shit?18:00
olofkSorry. My rage against that tool took overhand18:03
olofkTo be honest, we are working on something that shares a lot of functionality with EDK, like making it easier to set up a system18:05
stekernbut in a sane package ;)18:10
analognoiseI was hoping you'd say that18:16
analognoiseCurrently 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
analognoiseHowever 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
analognoiseIs there a preferred working topology for work like that that's underway?18:21
analognoiseLike, Lattice, Xilinx, chips work with the non portable bits we have so far, type of thing.18:21
olofkanalognoise: 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 interface18:21
analognoiseolofk: That's great news!18:22
analognoiseSo the procedure would be similar to switch topologies18:22
olofkNot sure I follow you here18:22
analognoiseWell I was looking at the Lattice parts, but everything we have is Xilinx based18:23
analognoiseSo if I wanted to get the same type of setup, I'd do the same: create a wishbone wrapper.18:23
olofkmaxpaln is working on a wishbone wrapper for a Lattice memory controller18:24
analognoiseIsn'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
analognoiseolofk: That's also great news!18:25
olofkI have very little experience with lattice unfortunately18:25
olofkBut I would like to see an open source DDR2/3 controller with only a thin technology-specific I/O layer18:26
olofkMost things like command queues and reordering could be done in generic HDL18:26
stekernolofk: I think someone used the memory controller in misoc and added a DDR2/3 layer ontop of it18:31
olofkstekern: Aha. Didn't know that18:34
stekernI don't know if it ever got finished though18:40
stekernbut for DDR it has of course been used18:41
stekernI would like to do some experiments like that with with wb_sdram_ctrl18:41
stekernolofk: so a heads up, the pull-request I just posted ( depends on
stekernthat's why I'm nagging about the latter ;)18:53
olofkoh sorry18:56
olofkI want to change one thing. Replace the export function with self.export_files = self.src_files + self.include_files. Ok with that?18:57
olofkhmm.. why list(src_files) btw? Isn't it a list already?18:58
stekernsure, I don't care so much, as long as it works ;)18:58
olofkHow do I test it?18:58
stekernbut why do you want the self.export_files?18:58
olofkNo 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 to18:59
stekern(list(src_files)) hmm, that might have been cargo-programming from my side...19:00
olofkstekern: Any ideas for testing?19:03
stekern(test it) pull in 45, see it fail without it, see it succeed with it19:03
olofkIIRC it had something to do with verilator not exporting if there wasn't a vpi section or something like that19:03
olofkside note.. why doesn't this get both commits from #45 after I fetched it? git cherry-pick 5e5111c..ca291ea19:09
stekernbecause (IMO) git cherry-pick syntax is broken19:11
stekernyou need to do: git cherry-pick 5e5111c^..ca291ea19:11
olofkof course19: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
stekernI can't find that19:21
olofksorry. #2819:21
olofkahh :)19:22
olofk#30 :)19:22
olofkI'm pushing what I have now19:24
olofkOh no! I panicked and pushed an empty line.19:25
stekernas I said, I'm happy as long as it makes #45 works19:25
stekernheh, wut?19:26
stekernah, ok, I see19:27
olofkAh. but it's ok. It looks like it was you ;)19:27
stekernyou're trying to increase the KLOCS by cheating19:27
stekernhaha, yes, so more KLOCS for me ;)19:27
olofkGot to go now19:28
olofkDon't send any more fucking pull requests. I'm drowning in those ;)19:29
stekernI don't think I have any fusesoc stuff right now19:29
stekernan atlys board and a sockit board port is pending for orpsoc-cores though19:29
olofkstekern _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 cores19:30
_franck__I think we have commit access19:31
stekernyes, at least I do, I can add _franck__ to orpsoc-cores if he hasn't19:31
_franck__I need to add vhdl section and then I could push the NEEK board19:31
_franck__(I'm afraid it will be without fb :(  )19:32
stekernmaybe we still can do the pull-requests, just to give a hint about what we're about to push19:34
_franck__yes I think we should do that as a review process19:34
stekernok, I've added myself and fjullien to the "orpsoc" team now19:37
olofkIt 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 much19:46
olofk_franck__: You have the VHDL additions. Anything else?19:46
stekernyes, and my atlys port of course depends on the ISE support, so I'm holding onto that until then19:47
stekernit's basically done, I need to test it some more just19: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 now19:49
_franck__ok, I'll do that asap19: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 tap19:56
_franck__and 0.8 relase is coming out with or1k support in your favorite Linux distribution19: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
stekernI'm always forgetting what file I should edit and wonder why things not working20:10
olofk_franck__: Great to hear about openocd20:51
olofkAnd I want vpi and verilog in section/ now.20:51
olofkThinking about moving out ModelsimSection, IcarusSection and VerilatorSection to a separate if it grows too much20:52
olofkWith the factory method in Section, we don't have to worry so much about the internal details of the section module20:53
olofkBut I just came up with a new feature I want to push in But that can wait20:53
_franck__stekern: as recompiling my system to add signal takes ages, I need your expertise on mor1kx behavior21:25
_franck__and the piece of the coresponding Linux disassembly code:
_franck__at some point, it is stuck at c0003d94 (l.sfgeu r4,r5) and nothing happens21:27
_franck__I'm just watching decode_insn_i21:28
--- Log closed Tue Apr 01 00:00:45 2014

Generated by 2.15.2 by Marius Gedminas - find it at!