IRC logs for #openrisc Monday, 2014-04-14

--- Log opened Mon Apr 14 00:00:04 2014
Limb:( Figured adapting this cell ram code wouldve been easier01:07
LimbCan anyone tell me why I get this error "Illegal expression in target" for .wb_err_o(wb_s2m_mem_err & cellram_arb_reset)02:37
stekernLimb: do you have the code somewhere02:56
stekernnm, wb_err_o is an output02:58
stekernyou can't assign a logic expression on that02:58
Limbstekern: why not?03:00
stekernbecause the rules of verilog forbids you too =)03:01
stekernbut what do you want that code to achieve?03:02
stekernthat both wb_s2m_mem_rt and celleram_arb_reset get asserted?03:02
LimbI'm trying to adapt the cellular ram code juliusb wrote for the nexys3 to the nexys4. It uses the same chip but I'm having a hard time adapting the wishbone code03:03
stekernit's anyway a bad idea to have logic expressions in the port declarations, some tools doesn't support that iirc (modelsim)03:04
stekernor perhaps that was vhdl...03:04
Limbstekern: I tried putting it into an assign but i believe its still throwing an error because the log claims the wire I assign it to is never used03:04
Limbalthough it doesnt say I can't do the operation when I do it that way03:04
stekernyes, but is wb_s2m_mem_err connected to anything inside cellram_ctrl?03:05
stekernI bet it might be tied to 0 there03:05
stekern*and* you are already assigning cellram_arb_reset in the code you pasted: assign cellram_arb_reset = (&cellram_arb_timeout);03:06
stekernbut the whole cellram_arb thing is not going to be used anyway, so why are you bothering assigning those signals to anything?03:07
Limbstekern: I didn't even think of this as an assignment. I'm thinking of it as a evaluation hah03:08
Limbstekern: Because I haven't a clue what I'm doing03:08
Limb this is the original code03:09
Limbstekern: but because the wb_intercon generator adds another abstraction on top of what used to be done I'm confused03:09
stekernoh, I think you have some clue of what you're doing, otherwise you wouldn't have came this far ;)03:10
Limbthat code directly access the individual wires, but now those wires are hidden behind the module03:10
stekernyes, but the wb_intercon already does that for you03:10
stekernif you want seperate data and instruction wires, you have to 'trick' wb_intercon to do that... and you are not using that 'trick'03:11
stekernit's not really a trick, but you have to define the memory as several slaves (which it actually is, if it has several slave ports)03:12
Limbstekern: is what I have03:13
Limbstekern: I was looking at that before actually :) suppose I might have to do it03:13
stekernso that's what you should *not* do if your mem controller only have 1 port03:13
Limbstekern: how does that change how the cpu access the ram though?03:13
stekernyes, what you have in your pastebin is correct for your cell_ram03:15
stekernyou shouldn't add any arbitration ontop of that (i.e. remove the whole cellram_arb thing)03:16
Limbstekern: OK. I just did that and I'm waiting for the synth to complete03:16
stekernit's no difference in how the cpu accesses the ram, the only difference is how the arbitration takes place03:16
stekerni.e. inside the memory controller or inside wb_intercon03:18
stekernthe memory controller that is used on de0_nano have several slave ports:
Limbstekern: Is there any real difference between that and just declaring it as one?03:20
Limbother then the ability to individually address the data and instruction bus? (if that is even a difference?)03:20
stekernthe difference is that the memory controller have a better idea how the arbitration should be done to efficiently access the SDRAM03:22
stekernfor example, the wb_sdram_ctrl have a 32-byte cache for each wb port, so say that the cpu reads data address 0 and then do 10 instructions (that needs to be read from the SDRAM) and then reads data address 403:25
stekernwith only one slave port it would be fill,fill,fill and with two only fill,fill03:29
Limbstekern: well... it appears the memory is working03:34
Limbbut program isn't running03:34
Limbbut the memory is being filled correctly03:35
Limbit's like the cpu isnt resuming03:35
stekernyou should connect the dbg reset output to the cpu reset03:37
Limbstekern: in the ram?03:37
Limbstekern: that seems to have broken what was working -_-03:51
Limbgetting crc errors now03:51
stekernhmmm.. yave you constrained the debug interface and have you checked that you get no timing errors?04:14
Limbstekern: the code I have works fine with ram_wb so the code should be good04:25
Limblike I said, its as of the CPU doesn't resume is the only problem04:26
stekernyes, but that sounds like the cpu get stuck in some state, which my proposed change intended to remedy04:56
stekernbut now you get a non-working design from seemingly unrelated changes, which make me suspect timing errors04:57
blueCmdstekern: re: the gcc issue. it seems that only my Debian packaged gcc crashes, so my current plan of attack is to compare configure flags.08:12
stekernblueCmd: ah, interesting08:29
maxpalnhowdy all - monday morning wishbone spec question: are there any rules about what data should be presented on the non selected (SEL_I[n]==0) bytes of a 32-bit bus?09:52
maxpalnI am trying to determine if it is ok to always present the full 32-bit data on dat_o or whether the unselected bytes must be set to 009:52
maxpalnthe spec doesn't seem to cover this.09:52
maxpalnI am talking about memory reads here -09:53
olofk_maxpaln: It's ok to present the full data there10:14
olofk_The master should treat them as don't care10:14
olofk_But you're right. It's not explicty stated, so a master could potentially assume that other bytes are cleared10:16
olofk_These types of questions should be posted to the wishone mailing list, but I'm not sure if anyone else but me is signed up to that list :)10:17
* stekern is too10:54
stekernit's probably ok, but a common thing that is done, is to duplicate the data on the rest10:57
maxpalnthanks - I'll see which way maps into the simplest logic and run it through some tests11:32
Limbstekern: As far as I can see there are no timing errors15:03
Limbstekern: I increased the read and write cycles to 8 (so it should be 80 ns) and i can seem to connect, halt, upload a elf and verify the elf... but im getting crc errors on resume15:51
stekernbut isn't the crc errors purely specific to the jtag interface?17:02
stekernor more correctly perhaps, the adv_debug core17:03
Limbstekern: considering I reverted back to the code that did work (although i reduced ram to 1 KB) and I'm getting the same problem I dont know whats going on17:25
LimbI'm synthing the original code that worked with 4 KB ram and I'll see what happens.. but this is gonna take 2 hours to do17:26
stekernwhat is the jtag clock constrained to?17:29
stekerncan't let go of the feeling that it might be timing related17:31
Limbstekern: it should be to the internal JTAG tap clock17:36
stekernhmm, ok... does it figure that out by itself?17:37
stekernI mean, is that clock frequency fixed to something?17:39
Limbstekern: as far as I can tell it would be whatever drives the JTAG port17:46
Limbstekern: whats confusing is that the code I had working is now throwing the same errors as with the new ram17:48
olofkLimb: I agree with stekern that it sounds like unconstrained paths. Could you send over you .twr file?18:10
Limbolofk: I'm out and about right now so I'll do so in a few hours18:30
-!- julzmb_ is now known as julzmb19:08
mor1kx[mor1kx] skristiansson pushed 3 new commits to master:
mor1kxmor1kx/master 8638166 Stefan Wallentowitz: Caches: Rename index->tag...19:08
mor1kxmor1kx/master d510ac3 Stefan Wallentowitz: Caches: Optimized LRU unit...19:08
mor1kxmor1kx/master 9e5a414 Stefan Wallentowitz: Caches: Support multiple ways...19:08
-!- FreezingAlt is now known as FreezingCold19:43
Limbolofk: heres the twr report for the crc failing on resume with cell ram:
Limbolofk: I also have the twr for the working ram_wb_b3 file if you want22:22
Limbreg npc gives an output of npc (/32): 0x00000E04 if that means anything22:24
--- Log closed Tue Apr 15 00:00:06 2014

Generated by 2.15.2 by Marius Gedminas - find it at!