| --- Log opened Mon Apr 14 00:00:04 2014 | ||
| Limb | :( Figured adapting this cell ram code wouldve been easier | 01:07 |
|---|---|---|
| Limb | Can 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 |
| stekern | Limb: do you have the code somewhere | 02:56 |
| stekern | nm, wb_err_o is an output | 02:58 |
| stekern | you can't assign a logic expression on that | 02:58 |
| Limb | stekern: http://pastebin.com/NhrC9veh | 03:00 |
| Limb | stekern: why not? | 03:00 |
| stekern | because the rules of verilog forbids you too =) | 03:01 |
| stekern | but what do you want that code to achieve? | 03:02 |
| stekern | that both wb_s2m_mem_rt and celleram_arb_reset get asserted? | 03:02 |
| Limb | I'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 code | 03:03 |
| stekern | it's anyway a bad idea to have logic expressions in the port declarations, some tools doesn't support that iirc (modelsim) | 03:04 |
| stekern | or perhaps that was vhdl... | 03:04 |
| Limb | stekern: 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 used | 03:04 |
| Limb | although it doesnt say I can't do the operation when I do it that way | 03:04 |
| stekern | yes, but is wb_s2m_mem_err connected to anything inside cellram_ctrl? | 03:05 |
| stekern | I bet it might be tied to 0 there | 03:05 |
| stekern | *and* you are already assigning cellram_arb_reset in the code you pasted: assign cellram_arb_reset = (&cellram_arb_timeout); | 03:06 |
| stekern | but the whole cellram_arb thing is not going to be used anyway, so why are you bothering assigning those signals to anything? | 03:07 |
| Limb | stekern: I didn't even think of this as an assignment. I'm thinking of it as a evaluation hah | 03:08 |
| Limb | stekern: Because I haven't a clue what I'm doing | 03:08 |
| Limb | https://github.com/juliusbaxter/mor1kx-dev-env/blob/master/boards/xilinx/nexys3/rtl/verilog/orpsoc_top/orpsoc_top.v#L1156 this is the original code | 03:09 |
| Limb | stekern: but because the wb_intercon generator adds another abstraction on top of what used to be done I'm confused | 03:09 |
| stekern | oh, I think you have some clue of what you're doing, otherwise you wouldn't have came this far ;) | 03:10 |
| Limb | that code directly access the individual wires, but now those wires are hidden behind the module | 03:10 |
| stekern | yes, but the wb_intercon already does that for you | 03:10 |
| stekern | if 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 |
| stekern | it'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 |
| Limb | stekern: http://pastebin.com/ewU0kjgc is what I have | 03:13 |
| stekern | example: https://github.com/openrisc/orpsoc-cores/blob/master/systems/de0_nano/data/wb_intercon.conf#L31 | 03:13 |
| Limb | stekern: I was looking at that before actually :) suppose I might have to do it | 03:13 |
| stekern | so that's what you should *not* do if your mem controller only have 1 port | 03:13 |
| Limb | stekern: how does that change how the cpu access the ram though? | 03:13 |
| stekern | yes, what you have in your pastebin is correct for your cell_ram | 03:15 |
| stekern | you shouldn't add any arbitration ontop of that (i.e. remove the whole cellram_arb thing) | 03:16 |
| Limb | stekern: OK. I just did that and I'm waiting for the synth to complete | 03:16 |
| stekern | it's no difference in how the cpu accesses the ram, the only difference is how the arbitration takes place | 03:16 |
| stekern | i.e. inside the memory controller or inside wb_intercon | 03:18 |
| stekern | the memory controller that is used on de0_nano have several slave ports: https://github.com/openrisc/orpsoc-cores/blob/master/systems/de0_nano/rtl/verilog/orpsoc_top.v#L492 | 03:18 |
| Limb | stekern: Is there any real difference between that and just declaring it as one? | 03:20 |
| Limb | other then the ability to individually address the data and instruction bus? (if that is even a difference?) | 03:20 |
| stekern | the difference is that the memory controller have a better idea how the arbitration should be done to efficiently access the SDRAM | 03:22 |
| stekern | for 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 4 | 03:25 |
| stekern | with only one slave port it would be fill,fill,fill and with two only fill,fill | 03:29 |
| Limb | stekern: well... it appears the memory is working | 03:34 |
| Limb | but program isn't running | 03:34 |
| Limb | but the memory is being filled correctly | 03:35 |
| Limb | it's like the cpu isnt resuming | 03:35 |
| stekern | you should connect the dbg reset output to the cpu reset | 03:37 |
| Limb | stekern: in the ram? | 03:37 |
| stekern | https://github.com/skristiansson/orpsoc-cores/blob/master/systems/atlys/rtl/verilog/orpsoc_top.v#L232 | 03:38 |
| Limb | stekern: that seems to have broken what was working -_- | 03:51 |
| Limb | getting crc errors now | 03:51 |
| stekern | hmmm.. yave you constrained the debug interface and have you checked that you get no timing errors? | 04:14 |
| Limb | stekern: the code I have works fine with ram_wb so the code should be good | 04:25 |
| Limb | like I said, its as of the CPU doesn't resume is the only problem | 04:26 |
| stekern | yes, but that sounds like the cpu get stuck in some state, which my proposed change intended to remedy | 04:56 |
| stekern | but now you get a non-working design from seemingly unrelated changes, which make me suspect timing errors | 04:57 |
| blueCmd | stekern: 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 |
| stekern | blueCmd: ah, interesting | 08:29 |
| maxpaln | howdy 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 |
| maxpaln | I 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 0 | 09:52 |
| maxpaln | the spec doesn't seem to cover this. | 09:52 |
| maxpaln | I am talking about memory reads here - | 09:53 |
| olofk_ | maxpaln: It's ok to present the full data there | 10:14 |
| olofk_ | The master should treat them as don't care | 10:14 |
| olofk_ | But you're right. It's not explicty stated, so a master could potentially assume that other bytes are cleared | 10: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 too | 10:54 | |
| stekern | it's probably ok, but a common thing that is done, is to duplicate the data on the rest | 10:57 |
| maxpaln | thanks - I'll see which way maps into the simplest logic and run it through some tests | 11:32 |
| Limb | stekern: As far as I can see there are no timing errors | 15:03 |
| Limb | stekern: 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 resume | 15:51 |
| stekern | but isn't the crc errors purely specific to the jtag interface? | 17:02 |
| stekern | or more correctly perhaps, the adv_debug core | 17:03 |
| Limb | stekern: 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 on | 17:25 |
| Limb | I'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 do | 17:26 |
| stekern | what is the jtag clock constrained to? | 17:29 |
| stekern | can't let go of the feeling that it might be timing related | 17:31 |
| Limb | stekern: it should be to the internal JTAG tap clock | 17:36 |
| stekern | hmm, ok... does it figure that out by itself? | 17:37 |
| stekern | I mean, is that clock frequency fixed to something? | 17:39 |
| Limb | stekern: as far as I can tell it would be whatever drives the JTAG port | 17:46 |
| Limb | stekern: whats confusing is that the code I had working is now throwing the same errors as with the new ram | 17:48 |
| olofk | Limb: I agree with stekern that it sounds like unconstrained paths. Could you send over you .twr file? | 18:10 |
| Limb | olofk: I'm out and about right now so I'll do so in a few hours | 18:30 |
| -!- julzmb_ is now known as julzmb | 19:08 | |
| mor1kx | [mor1kx] skristiansson pushed 3 new commits to master: https://github.com/openrisc/mor1kx/compare/1a99eb1c9a89...9e5a414e35ce | 19:08 |
| mor1kx | mor1kx/master 8638166 Stefan Wallentowitz: Caches: Rename index->tag... | 19:08 |
| mor1kx | mor1kx/master d510ac3 Stefan Wallentowitz: Caches: Optimized LRU unit... | 19:08 |
| mor1kx | mor1kx/master 9e5a414 Stefan Wallentowitz: Caches: Support multiple ways... | 19:08 |
| -!- FreezingAlt is now known as FreezingCold | 19:43 | |
| Limb | olofk: heres the twr report for the crc failing on resume with cell ram: http://pastebin.com/1juGVr0J | 22:22 |
| Limb | olofk: I also have the twr for the working ram_wb_b3 file if you want | 22:22 |
| Limb | reg npc gives an output of npc (/32): 0x00000E04 if that means anything | 22:24 |
| --- Log closed Tue Apr 15 00:00:06 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!