| --- Log opened Wed Sep 11 00:00:51 2013 | ||
| stekern | we have contact: http://oompa.chokladfabriken.org/tmp/hello_world_from_mor1kx_on_sockit.png | 03:18 |
|---|---|---|
| olofk | stekern: Congratulations. What was the problem? | 06:06 |
| olofk | _franck_: Hmmm.. I'm not sure that's the original source | 06:07 |
| olofk | But at least it might be an unchanged copy | 06:07 |
| stekern | olofk: you need to configure the pinmuxes from software | 06:14 |
| stekern | and it has to be done in u-boot-spl | 06:14 |
| olofk | aha | 06:19 |
| olofk | Hmm.. I find a lot of verilog models on microns website, but for the particular ram we're using, I can't find anything | 06:19 |
| stekern | finding instructions how to replace spl wasn't trivial neither | 06:26 |
| stekern | I managed to screw up my sdcard | 06:26 |
| stekern | I dd'ed the image to the wrong partition... | 06:27 |
| stekern | I also have discovered that you can "brick" the device with a broken vjtag setup... | 06:28 |
| olofk | brick the sockit? | 06:29 |
| stekern | mmm | 06:30 |
| stekern | actually, maybe it's not the vjtag setup that I have trashed | 06:30 |
| olofk | So far I have found verilog models for 19 of 50 Micron SDRAM memories | 06:30 |
| stekern | "brick" as in: need power toggle to remove the broken fpga configuration | 06:32 |
| stekern | I cleaned up the pll stuff a bit, removing the megawiz generated files and just instantiated the pll directly in clkgen.v | 06:35 |
| stekern | but I accidently connected the active low reset to the active high reset input of that instantiation... | 06:35 |
| stekern | classic mistake, wrong polarity of reset signals | 06:36 |
| stekern | olofk: have you considered adding 'scripting' support to orpsoc? | 06:40 |
| stekern | I imagine it would be fairly simple to allow python scripts in cores/systems be called from orpsoc | 06:41 |
| olofk | stekern: Yep, I'm planning to add that at some point | 06:44 |
| olofk | It's probably needed | 06:44 |
| stekern | needed or not, it'd be cool ;) | 06:45 |
| stekern | and it'll make it a lot more powerful tool | 06:45 |
| olofk | Yes, and again I'm looking at gentoos ebuild format | 07:07 |
| olofk | But they use shell scripts, and I do not want that | 07:07 |
| olofk | So the idea is to have config options that makes it possible to run scripts at different stages | 07:08 |
| olofk | Like pre_compile=do_some_preprocessing_stuff.py | 07:08 |
| olofk | But I think that the internal APIs need to be documented and somewhat stable before that | 07:09 |
| stekern | yeah, sure | 07:11 |
| _franck_ | olofk: about the sdram ram model, when I said original source I meant unmodified | 07:54 |
| olofk | _franck_: Ah ok. I see | 08:12 |
| knz | I got my new hard drive \o/ (that means I can now install the EDA tools properly) | 09:30 |
| stekern | by transforming google-fu into emacs-fu I have came up with this for all verilog-mode indentation haters: http://pastie.org/8316378 | 09:33 |
| olofk | Killing auto-newline is a godsend too | 09:38 |
| olofk | We could of course have a full-scale war about the tab width | 09:39 |
| stekern | no, a tab is 8 | 09:39 |
| stekern | everything else are spaces | 09:39 |
| olofk | I'll take it for a test-drive | 09:40 |
| stekern | go ahead, drive it with caution, it's still a low-miler ;) | 09:41 |
| stekern | might need some carburator adjustments etc | 09:41 |
| stekern | I think I actually prefer to kill verilog-auto-indent-on-newline too | 09:42 |
| olofk | To get rid of trailing spaces on empty lines? | 09:43 |
| olofk | Found a problem with your verilog mode. http://pastie.org/8316396 | 09:44 |
| stekern | yes, to get rid of trailing spaces on empty lines | 09:57 |
| stekern | and I found myself constantly going back erasing them after a newline | 09:58 |
| stekern | olofk: I SAID DRIVE CAREFULLY! | 09:58 |
| stekern | ;) | 09:59 |
| stekern | ah, but you know what, I think it's just that it doesn't know how to fix it when there are already spaces in there | 10:00 |
| stekern | no, that's not it, it's because you have the ( in the wrong place ;) | 10:04 |
| stekern | no, it's still odd... | 10:06 |
| stekern | it doesn't do it on all files even | 10:10 |
| olofk | That's weird | 10:13 |
| olofk | I tried a few different placements of the ( too, but it didn't help | 10:13 |
| stekern | yeah, it's unrelated | 10:13 |
| stekern | try editing orpsoc_top.v in generic for example, that works fine | 10:14 |
| olofk | hmm... | 10:14 |
| olofk | Are there any leftover verilog-mode hints in that file? | 10:14 |
| olofk | Started a fresh file with just a module header. Same problem | 10:15 |
| olofk | So it's not due to existing spaces | 10:15 |
| stekern | I think it might have to do with the parameters | 10:20 |
| olofk | verilog parameters? | 10:21 |
| stekern | yes | 10:24 |
| olofk | Hmm.. I added a parameter, and now the inputs are indented one space from the first one | 10:37 |
| olofk | And if I add two parameters, they get the crazy indent | 10:37 |
| stekern | maybe there's a bug somewhere in verilog-mode doing that | 10:38 |
| olofk | Can I reload my .emacs without shutting down emacs? | 10:38 |
| stekern | dunno | 10:39 |
| stekern | I mean, I think you can, but I don't know how | 10:39 |
| olofk | M-x eval-buffer | 10:40 |
| olofk | Doesn't seem to be all that simple though | 10:41 |
| knz | you can't "re-init" emacs | 10:42 |
| knz | eval-buffer is the best you can have | 10:42 |
| knz | but it's not equivalent to a reload | 10:42 |
| olofk | verilog-indent-lists t helped a lot | 10:43 |
| olofk | ports and parameters aren't lined up with each other, but it looks a lot better | 10:44 |
| olofk | http://pastie.org/8316496 | 10:45 |
| stekern | mogna parameternamn! =) | 10:46 |
| stekern | but no, verilog-indent-lists t doesn't help a bit, will screw up module instantiations | 10:46 |
| olofk | Hmm.. I wonder if our verilog-modes differ to begin with | 10:47 |
| stekern | and the inputs should be one tab inwards | 10:47 |
| olofk | I'm not seeing any problems with module instantiations here | 10:47 |
| olofk | As a side note. My tabs don't seem to be 8 spaces wide | 10:48 |
| stekern | it only inserts one tab and doesn't line it up with the (? | 10:49 |
| olofk | I get two tabs and two spaces on the first line, and three tabs on the rest | 10:49 |
| olofk | Does pastie keep the tabs/spaces? | 10:50 |
| olofk | http://pastie.org/8316514 | 10:51 |
| stekern | it should look like this: https://github.com/fjullien/orpsoc-cores/blob/master/systems/de1/rtl/verilog/orpsoc_top.v#L500 | 10:51 |
| stekern | taste issue of course, but that's my how I'd like it | 10:51 |
| knz | question: can I use the same binutils install for both the cores with and without delay slots? | 10:52 |
| olofk | But won't that be a mess when you have signal names of different length. If I copy/paste that piece of code it looks like crap | 10:53 |
| stekern | knz: yes you can, it'll install them as multilibs (iirc) | 10:54 |
| knz | hmm | 10:54 |
| knz | but the binutils are not libraries | 10:55 |
| stekern | olofk: now I'm not following, what does the signal names | 10:55 |
| knz | I don't see how multilibs are relevant here | 10:55 |
| stekern | knz: no sorry, I "read" or1k-src from binutils | 10:56 |
| knz | hum | 10:56 |
| knz | now I'm confused | 10:56 |
| olofk | stekern: It's more of a general problem with tabs I guess. It just looks awful when you don't have tab width 8 | 10:56 |
| knz | isn't the or1k-src repo exactly about binutils? | 10:56 |
| knz | the README-OR1K in there only mentions building the binutils | 10:57 |
| stekern | olofk: but you do have a tab width of 8, everything else is insane ;) | 10:58 |
| stekern | knz: that README should be removed, it's obsolete | 10:58 |
| stekern | (I think, let me look) | 10:58 |
| stekern | yeah, quickly forget what that says | 10:59 |
| knz | hrm | 10:59 |
| knz | maybe put a link to http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Installation_of_development_versions in there | 11:01 |
| stekern | good idea | 11:07 |
| knz | ARGH | 11:12 |
| knz | silly thing | 11:12 |
| knz | the binutils configure script uses ISL_CHECK_VERSION assuming it does an "at least" check | 11:13 |
| knz | but the m4 macro is atually an exact check | 11:13 |
| knz | so my 0.11 is not recognized :( | 11:13 |
| _franck_ | olofk, stekern : don't you have this king of thing in emacs: http://picpaste.com/pics/Sans_titre-fwYfIpv9.1378898274.png | 11:18 |
| _franck_ | showing you white space and tabs ? | 11:18 |
| olofk | _franck_: Not sure actually | 11:19 |
| olofk | I have to use my usual emacs answer. There probably is a way, but I don't have a clue how to do it :) | 11:20 |
| stekern | _franck_: yes there are | 11:20 |
| stekern | it's called global-white-space mode | 11:20 |
| _franck_ | with this enabled you won't mix tap/space ever :) | 11:21 |
| _franck_ | *tabs | 11:21 |
| stekern | http://oompa.chokladfabriken.org/tmp/emacs_global_whitespace.png | 11:23 |
| stekern | it also shows trailing whitespaces (as I demonstrate in the screenshot) | 11:24 |
| stekern | the grayish stuff is tabs | 11:24 |
| _franck_ | great | 11:24 |
| olofk | Doesn't work on my emacs :( | 11:24 |
| stekern | *greyish stuff are | 11:25 |
| stekern | what emacs do you have? | 11:26 |
| olofk | 22.3.1, the GTK version | 11:27 |
| olofk | Doesn't work in -nw mode either | 11:28 |
| stekern | heh, why not? | 11:28 |
| olofk | No clue | 11:29 |
| stekern | are all the wb_intercon changes just related to testbenches? | 11:30 |
| olofk | stekern: No, it's updates to the module ports that are done in preparation of the wb_intercon generator | 11:30 |
| olofk | I wasn't happy with the wb_mux design, so that's the main reason for the updates | 11:31 |
| stekern | let me rephrase that, do I have to change anything in my sockit WIP | 11:32 |
| stekern | ? | 11:32 |
| olofk | Now it's just so incredibly awesome that it blows my mind by looking at the code | 11:32 |
| olofk | yes, if you use wb_intercon.v or wb_mux.v from the wb_intercon core | 11:32 |
| * stekern looks at _franck_ | 11:33 | |
| olofk | Sorry s/wb_intercon.v/wb_arbiter.v | 11:33 |
| olofk | Take a look at the or1200-generic system | 11:33 |
| olofk | It's been updated | 11:33 |
| stekern | yes, but there was only changes from dat_o to rdt (which I think is not so smart) | 11:34 |
| olofk | Ah yes. That would be the only change for interconnects with a single slave | 11:35 |
| olofk | (which is still up for discussion) | 11:35 |
| olofk | So wb_mux wasn't used before in or1200-generic (which is why you didn't see any changes) | 11:36 |
| olofk | But the last commit last night added a UART and hence a wb_mux in wb_intercon | 11:36 |
| stekern | ah, ok | 11:36 |
| knz | side question: is there any or1k-based soc with anything else than buses as interconnect? | 11:37 |
| stekern | olofk: but that's also just tb changes? | 11:37 |
| olofk | stekern: Depends on how you see it. In or1200-generic I decided to put everything in the bench directory since the whole system is just meant for simulation, so yes, there it's only tb changes | 11:40 |
| olofk | knz: What do you have in mind that is not buses? | 11:40 |
| stekern | ok, well, I'll figure it out | 11:40 |
| knz | olofk: on-chip packet switching | 11:40 |
| stekern | why is it just meant for simulation btw? | 11:40 |
| olofk | knz: Still buses :) | 11:41 |
| knz | olofk: no, not strictly | 11:41 |
| knz | at the wire level you're right but then the system model has a very different behavior to contention on shared units | 11:42 |
| knz | also, I would not call a pair of wires with only 1 slave and 1 master a "bus" | 11:42 |
| olofk | stekern: I don't want to add clock and reset generation that would be needed to build it for real. | 11:42 |
| knz | just a "pair of wires" | 11:42 |
| olofk | But I will probably move it it rtl/verilog, because then you can use it as a subcomponent in another system where you have the techonlogy-dependent stuff | 11:43 |
| olofk | I've been trying out a lot of ideas. Some good... some not so good | 11:43 |
| olofk | knz: I think I might have heard of someone doing something NoC-related with OpenRISC, but you would need to have different bus interfaces on all the cores then | 11:45 |
| olofk | Wishbone isn't well suited for NoC as it is today | 11:45 |
| knz | that is why I was asking | 11:45 |
| stekern | olofk: fair enough | 11:47 |
| olofk | I don't think we would benefit from NoC in most of our applications really. | 11:50 |
| stekern | olofk: so, it's this commit that has the core changes that breaks the interface, right? https://github.com/openrisc/orpsoc-cores/commit/ade07bf7b8883b25d66cb1e66899c4bcb905bfed | 11:50 |
| knz | olofk: thanks for your comments | 11:50 |
| knz | other question, as I am currently reviewing mor1kx_rf_cappuccino.v | 11:51 |
| knz | stekern: maybe that one's for you | 11:51 |
| olofk | stekern: Yep, that should be it | 11:51 |
| knz | is it the case that the register file gets activated and read from at every cycle, regardless of whether the read is bypassed from a later pipeline stage? | 11:51 |
| knz | I ask because I only see a select on the rf_ram_o, not the _en bit | 11:52 |
| stekern | knz: yes | 11:52 |
| knz | ok | 11:53 |
| stekern | but there is no real reason why it couldn't be gated by the bypass signal | 11:53 |
| knz | I can see one: timing | 11:53 |
| knz | that means the read cannot be done in parallel with reading the bypasses | 11:54 |
| stekern | yeah, but I mean theoretical | 11:54 |
| knz | ok | 11:54 |
| stekern | yeah, that is true, was a while since I poked at that, so not really context switched in ;) | 11:54 |
| knz | I'm working on a core design where the RF is much larger, and thus power hungry | 11:55 |
| knz | so I 'm exploring ways to save up there | 11:55 |
| stekern | mmm, but should be doable | 12:03 |
| olofk | All right then. Went through all the 201 SDRAM models on Microns website. There are _no_ simulation models for the mt48lc16m16* parts | 12:05 |
| olofk | In total, 98 out of 201 has a verilog model, so there might be a chance that one of those could be used | 12:06 |
| olofk | Aha! I was wrong | 12:25 |
| olofk | But the newest one I can find is from August 2001. The one in ORPSoC is updated June 2002 | 12:25 |
| stekern | olofk: I can't get my head around how the MATCH_ADDR and MATCH_MASK works | 12:28 |
| stekern | nm, now I do | 12:30 |
| stekern | no... maybe I'm sleep deprived, but how can I get slave 0 selected between addresses 0x90000000-0xffffffff? | 12:43 |
| olofk | stekern: Hmm... that won't work | 12:59 |
| olofk | 0x80000000-0xffffffff would work though | 13:00 |
| olofk | (and make more sense) | 13:00 |
| olofk | If you want to block 0x80000000-0x8fffffff that could be done too | 13:01 |
| olofk | Or am I missing a use case here? | 13:02 |
| olofk | aha! The model on Microns website that is date 08/2001 contains a file that is last updated 06/2002. I found the original! | 13:04 |
| olofk | http://www.micron.com/~/media/Documents/Products/Sim%20Model/DRAM/DRAM/4012mt48lc16m16a2.zip | 13:05 |
| olofk | #openrisc, my private pastie | 13:05 |
| stekern | mine too | 13:09 |
| stekern | yeah, I know that 0x80000000-0xffffffff would work, and it's fine for my use case | 13:09 |
| stekern | kind of wasteful if you have 4 gigs of ram | 13:09 |
| stekern | or am I missing something | 13:10 |
| mschulze | Hi all! | 13:11 |
| stekern | the sel signal seemed more flexible | 13:11 |
| stekern | heh, now I'm all confused by the rdt/sdt/dat_o/dat_i changes... I changed all the signals on wb_data_resize too... | 13:15 |
| olofk | stekern: Yes, the sel signal was more flexible. I figured that the flexibility wasn't needed though. I might have been wrong there | 13:15 |
| olofk | stekern: Me too. I realize that I started a mess | 13:16 |
| olofk | and hi mschulze! | 13:16 |
| stekern | I vote for the m2s and s2m naming and keep the _dat name | 13:16 |
| mschulze | Are you discussing the wishbone signal names? | 13:17 |
| stekern | olofk: it's all cool, you've got to through away one sometimes | 13:17 |
| olofk | mschulze: That or tab width :) | 13:18 |
| stekern | in the #openrisc church | 13:18 |
| mschulze | I have got a comment on that too... :-) | 13:18 |
| olofk | mschulze: Welcome to the party. The tab is open and we have plenty of space for you | 13:19 |
| mschulze | When generating wishbone arbiter files it would be helpful if the signal names within the arbiter and at the top level would contain the name of the core that is connected to the "port" and not only a number :-D | 13:20 |
| olofk | mschulze: You can take a look at https://github.com/openrisc/orpsoc-cores/blob/master/systems/or1200-generic/bench/verilog/wb_intercon.v | 13:20 |
| olofk | That has been generated from my wb_intercon generator | 13:21 |
| mschulze | I really must have a look at your generator soon. At the moment I am a bit out of order because I have to do all that things that I haven't done the last months... | 13:22 |
| mschulze | Your names look exact like generated ones working around the problem I had... | 13:24 |
| olofk | mschulze: Here is a preliminary version | 13:26 |
| olofk | https://www.dropbox.com/s/cjskgr1j4hh1oba/wb_intercon_gen.tar.gz | 13:26 |
| olofk | I can provide you with a 30 day evaluation license for the generator | 13:26 |
| olofk | After you have signed the NDA | 13:27 |
| mschulze | My question is: Am I bound to the wishbone naming only at the interface to the IP cores or am I bound in other files too? | 13:28 |
| olofk | Not sure what you mean | 13:28 |
| mschulze | The signal names in the wishbone specification document | 13:29 |
| mschulze | Are we bound to them in our generated files? | 13:30 |
| mschulze | I have no NDA within your archive file... | 13:33 |
| knz | other question: who's responsible for the newlib/libgloss code? | 14:00 |
| olofk | mschulze: You can use whatever name you want internally in your cores | 14:03 |
| olofk | But we should use the names in the spec for the interfaces. Note that I have _not_ used the name from the spec for the data signal from the slaves | 14:04 |
| olofk | But I probably need to change this | 14:04 |
| stekern | knz: the one that touched it last ;) | 14:14 |
| * stekern prays it wasn't me | 14:14 | |
| stekern | knz: most of the code there have been done by jeremybennett and juliusb | 14:20 |
| mschulze | olofk: I'm still waiting for your NDA or a hint that it has been a joke... | 14:22 |
| olofk | It was a joke :) | 14:24 |
| olofk | Sorry | 14:24 |
| knz | ok | 14:32 |
| knz | thanks | 14:32 |
| stekern | I read DNA first... | 14:45 |
| _franck_ | http://www.vscom.de/6801_larger.htm | 14:45 |
| _franck_ | looks like it is now named OnRISC | 14:45 |
| _franck_ | http://www.smartoshop.com/documents/Alekto.pdf | 14:46 |
| stekern | I just realised I can copy-paste from the weblogs when I'm on the run | 14:50 |
| stekern | there's just a bit of latency | 14:50 |
| mschulze | olofk: Thanks, I'll look through it as soon as my time table allows it. Your approach looks more modular than mine. At the moment I am struggeling with some gitignore problems. As soon as they are done I am ready to release it to github although it doesn't work at the moment. There are missing module_defines.v files for modules that I don't use and I have to figure out, where they are referenced. | 15:07 |
| mschulze | Oh, sometimes I tend to build up a wall of text. Sorry. I have to leave now. Bye ;-) | 15:10 |
| knz | hi again | 17:24 |
| knz | for or1ksim, the target is or32-elf, not or1k-elf, right? | 17:24 |
| knz | never mind | 17:25 |
| stekern | olofk: If you agree on the s2m and m2s naming, I could take on the fun job to rename all the signals across orpsoc-cores if you'd like | 17:52 |
| stekern | and sorry if I come out as a bit overcritical at times, overall I think it's really great what you've done with orpsocv3 and orpsoc-cores! | 17:53 |
| stekern | _franck_: this isn't right, right? https://github.com/fjullien/orpsoc-cores/blob/master/systems/de1/rtl/verilog/orpsoc_top.v#L366 | 18:19 |
| stekern | ah, yes it is, now I see where that comes from | 18:30 |
| stekern | it's a bit tricky when parameters are lower case and not declared in the same file | 18:32 |
| stekern | olofk, _franck_: the approach of having one wb_data_resize for a whole bytebus is not how it's intended to be used, right? | 19:01 |
| _franck_ | well, why not ? | 19:03 |
| stekern | because it's not going to work with the olofk's latest changes | 19:03 |
| _franck_ | ah ok :) | 19:03 |
| _franck_ | I was about to take a look at this | 19:03 |
| stekern | I think my criticism over MATCH_ADDR and MATCH_MASK might have been slightly misdirected too | 19:04 |
| stekern | so, if I understand things correctly, the idea is to have only one wb_mux for the whole data buss, and each peripheral get picked with the MATCH_ADDR and MATCH_MASK (possibly as fine grained as just the registers it covers) | 19:08 |
| stekern | then on each byte-peripheral you hook up a resizer | 19:09 |
| stekern | and it's not going to work with a single bytebus in the scenario where you'd have 0x90000000 = byte, 0x91000000 = word, 0x92000000 = byte | 19:11 |
| _franck_ | yes, you have to have on resizer per mux output | 19:14 |
| _franck_ | let me size how it works in my de1 | 19:15 |
| stekern | I'm pretty familiar with how it works there, since I copied that as a base for sockit ;) | 19:15 |
| _franck_ | ok a resizer then a mux | 19:16 |
| stekern | it's fine there since all peripherals are bytebussed | 19:16 |
| stekern | perhaps wb_mux could always default to the '0' bus and everything else would just be masked out of that | 19:18 |
| stekern | that would solve the "waste a lot of memory space" problem | 19:18 |
| _franck_ | do you think waste of memory space is a problem ? | 19:19 |
| stekern | "problem", but yes. It's ugly if nothing else | 19:20 |
| stekern | but, actually, you can get the wb_mux to do the "default to" as it is now | 19:20 |
| stekern | just set that RAM mask to 0x00000000 and addr to 0x00000000 an put it last | 19:22 |
| stekern | +d | 19:22 |
| _franck_ | I'll see how the wb_intercon_gen is doing this thing because I'd like to remove all this bus part from my top | 19:25 |
| stekern | yeah, I'm starting to get the same urge | 19:26 |
| _franck_ | I need a pen to draw diagrams for that :) | 19:29 |
| _franck_ | http://pastie.org/8317901 | 19:34 |
| _franck_ | as you said, we would have only resizers in the top....until olofk adds support for resizer in wb_intercon_gen ;) | 19:35 |
| stekern | yup, you can of course wrap the generated intercon.v and have the resizers there... but I'm not sure if that's any better than to have them in top | 19:42 |
| * _franck_ is going to loose 15 minutes with this tab/spaces thing :) | 19:43 | |
| stekern | was that your 15 minutes of fame that went now? | 19:43 |
| _franck_ | ? I don't get it | 19:45 |
| stekern | ah, it was a joke ;) it's a famous Andy Warhol quote, "everybody gets 15 minutes of fame" | 19:46 |
| _franck_ | ok, I knew it was a joke but I wasn't smiling so I knew I didn't get it :) | 19:48 |
| stekern | well, it wasn't very funny, so... =) | 19:48 |
| stekern | _franck_: have you tested to run olofk's work-in-progress intercon_gen? | 19:49 |
| _franck_ | no I'm about to do it | 19:51 |
| stekern | ah, now it worked | 19:51 |
| stekern | invoke it by: python wb_intercon_gen.py intercon.conf | 19:51 |
| stekern | this is impressive stuff | 19:52 |
| _franck_ | I think we should (at least me) learn python to give olofk a hand | 19:54 |
| stekern | yeah, me too would need to learn more | 19:54 |
| stekern | I've only dabbled with it | 19:54 |
| _franck_ | it would be great to have the module instantiation skeleton on the generated intercon.v | 20:03 |
| stekern | yes | 20:10 |
| stekern | you can get that with AUTOINST though | 20:11 |
| _franck_ | that's why I should try to use emacs... | 20:12 |
| stekern | now if only the wires could be AUTOWIREable | 20:26 |
| stekern | they are, but what I mean is that also the destinations would be AUTOINSTable | 20:36 |
| _franck_ | the intercon.v use an arbiter for dbg_d, cpu_i and cpu_d | 20:48 |
| _franck_ | so we can't take advantage of your wonderful port cached sdram controller | 20:49 |
| _franck_ | I need to review my intercon config file | 20:50 |
| stekern | ah, you just have to configure it a bit differently | 20:50 |
| stekern | http://pastie.org/8318074 | 20:50 |
| _franck_ | yeah tell mem is imem for exmaple | 20:51 |
| _franck_ | let's see what you've done | 20:51 |
| stekern | yes, a seperate slave for each port | 20:52 |
| _franck_ | wb_intercon_gen doesn't want my led to blink :( I'll that tomorrow | 21:27 |
| stekern | I'm not done hooking it up | 21:32 |
| stekern | I'm trying out the s2m and m2s notion to see if it makes sense | 21:33 |
| --- Log closed Thu Sep 12 00:00:52 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
