| --- Log opened Sat Mar 23 00:00:35 2013 | ||
| GentlemanEnginee | The RM just posted that their graders are hitting 8 - 15 foot drifts. | 00:07 |
|---|---|---|
| glowplug | Holy crap that is insane. O_O | 00:07 |
| GentlemanEnginee | I am beginning to doubt that I will be able to get anywhere in the morrow... | 00:07 |
| glowplug | Are you working from home these last few days? | 00:08 |
| GentlemanEnginee | Some. | 00:08 |
| GentlemanEnginee | Took today off. | 00:08 |
| GentlemanEnginee | This in despite of the work that needs to be done. | 00:08 |
| glowplug | Badass. It's like a school snowday. Haha | 00:08 |
| glowplug | Clearly you picked the more important project to work on. 8) | 00:08 |
| GentlemanEnginee | In fact, I was asked to come in tomorrow to attempt to finalize my fix that will hopefully alleviate a production issue. | 00:09 |
| glowplug | If you don't mind me asking what does your company do? | 00:09 |
| GentlemanEnginee | Designs and manufactures equipment (mainly for transmission of HD Video). | 00:10 |
| GentlemanEnginee | Also, some equipment for WiMax. | 00:10 |
| glowplug | Very cool. Wireless transmission or wired? | 00:11 |
| GentlemanEnginee | Both. | 00:11 |
| glowplug | Very cool. Have you worked with software defined radios? | 00:11 |
| GentlemanEnginee | However, the majority is for wired transmission. | 00:11 |
| GentlemanEnginee | I have not yet had the opportunity. | 00:11 |
| GentlemanEnginee | However, I am wishing to rectify this grave oversight. | 00:11 |
| glowplug | It is grave. SDN is absolutely amazing. | 00:12 |
| glowplug | SDN is like homecmos and opencores in that it will open up the airwaves, networks and cellphones to the people. | 00:13 |
| GentlemanEnginee | I am eagerly anticipating the adoption of Whitespace Rules here similar to what you FCC has adopt. | 00:13 |
| GentlemanEnginee | Up to four Watts of transmission power. | 00:14 |
| glowplug | Four watts. I hate governments so much. Haha | 00:15 |
| GentlemanEnginee | Four Watts is a fair amount. Transmission of tens of kilometers... | 00:16 |
| glowplug | We would all have free cell and internet access if it wasn't for band regulation. So frustrating. | 00:16 |
| GentlemanEnginee | With this, Internet access could be applied. | 00:17 |
| GentlemanEnginee | In fact, Rural Internet Access was one of the driving points behind this move. | 00:17 |
| glowplug | We have a project here in Detroit, its actually the first in the world that I'm aware of to create a wireless mesh network in the city that does not depend on any ISP's ect. | 00:17 |
| glowplug | But it is severely limited by regulation. And their approach is way worse than what is possible. | 00:18 |
| GentlemanEnginee | I would definitely appreciate having more than a (theoretical) 2Mbps download. | 00:18 |
| GentlemanEnginee | The Detroit Project should look at the Whitespace Regulations. | 00:19 |
| GentlemanEnginee | It would completely change their setup. | 00:19 |
| glowplug | I'm sure they know about it. They have been trying to do a mesh network for years. | 00:19 |
| glowplug | Actually this is very interesting. Apparently they could have a 30 mile range. This post is from 2008 though. | 00:22 |
| GentlemanEnginee | My nearest neighbour is ~1/2 mile away. | 00:22 |
| GentlemanEnginee | I also have two neighbours ~1 and 1-1/2 miles away. | 00:23 |
| glowplug | You can get 1/2 mile range with standard wifi already though. | 00:24 |
| glowplug | The challenge is spanning 300 mile gaps of desert and/or mountains. | 00:25 |
| GentlemanEnginee | Yes I am aware. However, it would be of little utility except for exchanging files. | 00:25 |
| glowplug | You could share a single internet charge. =) | 00:26 |
| GentlemanEnginee | B/W. | 00:26 |
| GentlemanEnginee | We are both already hitting B/W issues. | 00:26 |
| glowplug | Ahh I see. | 00:27 |
| GentlemanEnginee | I am using a microwave link (provided by a subsidiary of my firm) to a tower that is ~40km away. | 00:27 |
| glowplug | Thats how you get internet? That is amazing. Haha | 00:28 |
| glowplug | It is highly directional then? | 00:28 |
| glowplug | Also this whitespace thing is extremely interesting I can't believe this isn't all over the news. | 00:29 |
| GentlemanEnginee | It is indeed. | 00:29 |
| glowplug | Apparently there are already retail software defined radios that can determine which whitespace they are allowed to use and then use those bands. | 00:29 |
| GentlemanEnginee | I have a directional antenna on my roof. | 00:30 |
| glowplug | Very cool. | 00:32 |
| glowplug | It looks like the BladeRF unit I linked to you before should be able to take advantage of whitespace bands. | 00:32 |
| GentlemanEnginee | Yes. However, I was wishing to build my own. | 00:32 |
| GentlemanEnginee | This could be done with an FPGA. | 00:32 |
| GentlemanEnginee | In fact, it is another application that the Development Board could be used for... | 00:33 |
| glowplug | Those kinds of devices are a serious pain in the ass. The analog domain is a very scary place. O_O | 00:34 |
| GentlemanEnginee | All digital devices are created with analog components. | 00:34 |
| glowplug | I wouldn't touch SDN with a 20 foot pole unless I had a massive budget. | 00:34 |
| GentlemanEnginee | SDN? | 00:35 |
| glowplug | Software Defined Radio | 00:35 |
| GentlemanEnginee | So, SDR. | 00:35 |
| glowplug | Ahh yes SDR. =) | 00:35 |
| GentlemanEnginee | Some fellows are doing so with a rather small budget. | 00:35 |
| glowplug | If you are really comfortable designing low noise PCB's then go for it. But there is no way I'm going to attempt it. Hah | 00:36 |
| glowplug | The BladeRF guys? | 00:36 |
| glowplug | They have 1/4 million to work with. | 00:37 |
| GentlemanEnginee | No, I was referring to hobbiests. | 00:37 |
| glowplug | There are DIY FPGA SDR boards? | 00:38 |
| GentlemanEnginee | I had come across something. However, I did not have the time to investigate further. | 00:39 |
| glowplug | Time to investigate. =) | 00:40 |
| glowplug | This might be it. | 00:50 |
| glowplug | http://openhpsdr.org/index.php | 00:50 |
| glowplug | Very interesting stuff in there... | 00:50 |
| GentlemanEnginee | Quite likely... | 00:52 |
| glowplug | I might have another IRC channel to join... | 00:58 |
| GentlemanEnginee | What? | 01:01 |
| glowplug | I actually can't find the IRC channel for the HPSDR project.. | 01:08 |
| glowplug | So they dont use IRC and they use SVN. Things are not looking good for the HPSDR people. O.o | 01:11 |
| GentlemanEnginee | I see you are in the Linus Group... | 01:25 |
| glowplug | Linus group? | 01:34 |
| glowplug | Apparently SDR's can be DIY'd look at this. http://wwwhome.cs.utwente.nl/~ptdeboer/ham/sdr/ | 01:34 |
| glowplug | He is a PHD but it is a working 2 layer DIY SDR. | 01:34 |
| GentlemanEnginee | In regards to Revision Control. | 01:34 |
| GentlemanEnginee | That is interesting, and doable. | 01:34 |
| GentlemanEnginee | What silicon is he using? | 01:35 |
| glowplug | Looks like a gigabit ethernet ic, an analog to digital converter, and a spartan xcs3s500e fpga. | 01:38 |
| glowplug | It really is not that complicated of a board. The BladeRF people make it look a lot harder than it is. | 01:38 |
| glowplug | Of course again he is a PHD so... | 01:38 |
| glowplug | I wish he would post schematics. =( | 01:40 |
| glowplug | Apparently his boards are single layer. Haha | 01:42 |
| glowplug | Should be able to copy them by the pictures in that case. | 01:42 |
| glowplug | You know what. This is actually awesome. | 01:42 |
| glowplug | If I design the FPGA board as a SO-DIMM module then all that needs to be designed is a single layer "motherboard" with the A/D converter and BNC connector. | 01:43 |
| GentlemanEnginee | That would work. | 01:44 |
| GentlemanEnginee | The FPGA Board could be used with a number of "motherboards" allowing for differing functionality. | 01:45 |
| glowplug | That was my original plan. But I never intended to actually design one. Haha | 01:46 |
| glowplug | It seems like the SDR mainboard would be extremely simple though. | 01:46 |
| GentlemanEnginee | Leave some space for some op-amps. | 01:47 |
| glowplug | Actually it needs an A/D ic and D/A ic to be a transceiver. | 01:47 |
| GentlemanEnginee | I meant to allow for amplifying the signal prior to the A/D, if necessary. | 01:48 |
| GentlemanEnginee | Although, the other direction may be nice as a buffer. | 01:49 |
| glowplug | http://websdr.ewi.utwente.nl:8901/ | 01:49 |
| glowplug | It's hard to tell what each IC is in his design. | 01:49 |
| GentlemanEnginee | I imagine if you were to email him, he would be willing to part with schematics. | 01:54 |
| glowplug | Thats a good idea. Maybe I will have more luck with him than with Numato. Haha | 01:54 |
| GentlemanEnginee | Still no word? | 01:57 |
| glowplug | Nothing from them no. Thats ok I don't want their board anyways. =) | 01:59 |
| glowplug | We have a little bit of a problem though. Apparently his ADC is $90. Haha | 02:00 |
| GentlemanEnginee | Perhaps you should lith up some less expensive alternatives... | 02:01 |
| glowplug | Working on it. Haha | 02:01 |
| GentlemanEnginee | As long as it is done by Monday... | 02:01 |
| glowplug | O_O | 02:01 |
| glowplug | AD9460BSVZ-80 | 02:39 |
| glowplug | Is the best I can do. | 02:39 |
| glowplug | It's $70 has higher power output and the same sampling rate. | 02:39 |
| glowplug | This will not be a cheap board.... | 02:39 |
| GentlemanEnginee | Raffle it off. | 02:53 |
| glowplug | AD9786BSVZ | 02:54 |
| glowplug | For the DAC | 02:54 |
| glowplug | So thats pretty much it. The entire thing is basically a BNC connector a DAC and a ADC. It will still be about $120. | 02:55 |
| GentlemanEnginee | I was jesting about raffling off boards to pay for your own. | 02:55 |
| glowplug | I know. =) | 02:59 |
| glowplug | What do you think about seperate boards for receiving and transmitting? | 03:00 |
| glowplug | If both were connected to the same host you could do transciever type stuff (wifi/gsm ect.). Or use individual boards to do transmit only (fm radio) or receive only (ham type stuff). | 03:01 |
| GentlemanEnginee | That is not a poor idea. | 03:08 |
| GentlemanEnginee | Perhaps if these two boards were designed s/t they may connect to each other. | 03:09 |
| glowplug | That would make scaling pretty easy too. If you need more transmit bandwidth just add more boards. | 03:09 |
| GentlemanEnginee | Although, we should concentrate on the FPGA board. | 03:09 |
| glowplug | Have you done board design before? | 03:10 |
| glowplug | If you want to take a crack at the TX/RX mainboards I can send you KiCad file. | 03:13 |
| GentlemanEnginee | I could. | 03:14 |
| GentlemanEnginee | I am focussing on the FPGA Memory Controller, though. | 03:14 |
| glowplug | Ahh I see. Well I will leave the TX/RX boards for later then. =) | 03:16 |
| GentlemanEnginee | I believe that would be best. | 03:17 |
| GentlemanEnginee | They will be of little use until there is an FPGA Board to use them. | 03:18 |
| glowplug | Well the TX/RX boards don't actually need RAM. But since the modules are only $5 theres no point in changing the FPGA module just for the SDR. | 03:20 |
| GentlemanEnginee | Especially if one wishes to do some processing on them. | 03:21 |
| glowplug | Is anyone familiar with LVDS for data transmission? | 03:22 |
| GentlemanEnginee | I have done a little. | 03:22 |
| GentlemanEnginee | Keep the traces parallel, with equal impedance. | 03:23 |
| stekern | morning | 03:25 |
| glowplug | I've seen a project where LVDS was routed using SATA cables. I think its a fantastic idea for linking the SDR modules together at extremely low latency. | 03:26 |
| glowplug | Good morning. =) | 03:26 |
| GentlemanEnginee | Is it already? | 03:26 |
| glowplug | But I have absolutely no idea how to use LVDS as GPIO in Linux. | 03:26 |
| stekern | 5:25 here | 03:26 |
| glowplug | Are you familiar with LVDS Stefan? | 03:27 |
| GentlemanEnginee | It depends on how one wishes to encode the information. | 03:28 |
| stekern | not much | 03:28 |
| GentlemanEnginee | One usually uses some manner of tranceiver, though. | 03:28 |
| glowplug | The FPGA would be the tranceiver. | 03:29 |
| glowplug | And I want to communicate with the host PC over LVDS instead of ethernet. | 03:29 |
| GentlemanEnginee | I have not had experience with that. | 03:31 |
| GentlemanEnginee | Hardware only. | 03:31 |
| glowplug | It can get up to 3 Gbit/s apparently. | 03:33 |
| glowplug | The latency of LVDS is also way way lower than ethernet. | 03:36 |
| GentlemanEnginee | Ethernet would be much simpler, though. | 03:36 |
| GentlemanEnginee | I would say that LVDS would be a Rev. 2 Improvement. | 03:36 |
| glowplug | I'm not giving up that easy. 8) | 03:38 |
| glowplug | For another day though. Heading to bed. :D | 03:38 |
| GentlemanEnginee | Night. | 03:39 |
| GentlemanEnginee | How is stekern? | 03:40 |
| stekern | Fine, thank you very much | 03:40 |
| GentlemanEnginee | I am still snowed in. | 03:41 |
| stekern | :( | 03:42 |
| GentlemanEnginee | Neighbours are attempting to dig a path themselves with their tractors. | 03:42 |
| stekern | sounds extreme, we're never get that kind of extreme weather over here | 03:43 |
| stekern | at least not in the southern regions | 03:44 |
| GentlemanEnginee | I understand that the Northern Regions even have their own aboriginal population. | 03:47 |
| stekern | yeah, the sami people | 03:49 |
| GentlemanEnginee | I must admit that from my viewing of pictures, they appear rather much the same as other Scandanavians. | 03:51 |
| stekern | you mean the physical appearance? | 03:54 |
| GentlemanEnginee | Yes. | 03:54 |
| GentlemanEnginee | I understand the culture is somewhat different, though. | 03:57 |
| stekern | yes, they are very "nature"-oriented | 03:59 |
| GentlemanEnginee | Interesting. | 04:01 |
| stekern | but on the other hand, people up north are in general more nature-oriented than down south too | 04:01 |
| GentlemanEnginee | I wonder how similar the culture would be to aboriginals here. | 04:01 |
| GentlemanEnginee | I can tell you that those living in remote locations have a tendency to be more nature-oriented. | 04:02 |
| stekern | ok, bug identified, it's not in mor1kx at all, but in my xilinx ddr2 mem controller wrapper... | 16:26 |
| juliusb | :) | 16:26 |
| juliusb | I've found that my bug fix causes a combinatorial loop :-/ | 16:26 |
| stekern | have you got any pastebins of it? | 16:27 |
| juliusb | basically the bug is to do with immediately returning from exception to another asynchronous IRQ | 16:27 |
| juliusb | so from tick to IRQ, or vice versa | 16:27 |
| juliusb | of.... the test code? | 16:28 |
| stekern | yes, or your bugfix | 16:28 |
| juliusb | sorry, of the test software or the RTL? | 16:28 |
| juliusb | RTL: http://pastie.org/7091595 | 16:29 |
| juliusb | basically one bug was of the EPCR was being set to the vector we were just l.rfe'ing from if we immediately did another exception | 16:29 |
| juliusb | instead of staying the same and servicing the next exception | 16:30 |
| juliusb | also, we didn't do the tick-timer IRQ properly, if l.rfe'ing from an IRQ | 16:31 |
| juliusb | sorry, didn't go to the tick exception if doing l.rfe from an IRQ exception | 16:31 |
| juliusb | a bug in the address generation | 16:31 |
| juliusb | https://github.com/juliusbaxter/mor1kx-dev-env/blob/master/sw/tests/or1k/sim/or1k-inttickloop.S | 16:36 |
| juliusb | that's the software test | 16:36 |
| stekern | ah, ok, yeah I can imagine that happening | 16:38 |
| stekern | have you ran that against cappuccino? | 16:38 |
| juliusb | not yet | 16:39 |
| stekern | otoh, you can't push cappuccino that hard with the int and ticks anymore | 16:39 |
| juliusb | just wanted to run vlt-tests and check everything | 16:39 |
| juliusb | and noticed comb loop :( | 16:40 |
| stekern | a couple of those tests in your repo are currently not working with cappuccino | 16:40 |
| stekern | it gets into a loop, where it just rfeing to a branch and then get the timer exception in the delay slot | 16:41 |
| stekern | I have patches for all of those | 16:41 |
| stekern | but not sure if you want to take them | 16:42 |
| stekern | they are here anyways: https://github.com/skristiansson/mor1kx-dev-env/commits/master | 16:44 |
| juliusb | oh patches to the SW? | 16:44 |
| stekern | yes, the tests | 16:46 |
| stekern | we should really have those tick values being pipeline specific | 16:47 |
| juliusb | ah yep | 16:47 |
| juliusb | fair call | 16:47 |
| stekern | but I've been lazy and just tweaked them | 16:47 |
| stekern | the or1k-tickloop is ok though, it just fixes the issue without changing the test | 16:49 |
| juliusb | that's the only thing you changed? just tick loop times? | 16:49 |
| stekern | don't know why I haven't sent you a pull request for that + the or1k-systemcall change :/ | 16:49 |
| juliusb | nps | 16:50 |
| stekern | yes, in or1k-shortjump, or1k-timer and or1k-ticksyscall I've just changed the tick loop times | 16:50 |
| stekern | the intloop fails on cappuccino too, and it's not getting stuck in a loop, just exists with an exit(0) | 16:52 |
| stekern | no 0x8000000d or 0xbaaaaaad | 16:52 |
| stekern | *inttickloop | 16:52 |
| juliusb | hmm OK interesting | 16:59 |
| juliusb | found a fix for my comb loop! But another test is failling...insnfetcherror! | 17:00 |
| stekern | I still need to completely figure out what's failing in the xilinx ddr2 wrapper, it's something to do with acking during bursting | 17:13 |
| stekern | then I'll take a look at your new fancy test ;) | 17:14 |
| juliusb | oh it's cool I'll check that out for the other pipelines | 17:17 |
| juliusb | ah I had accidentally tied something low in cpu_prontoespresso when updating with some new ports you'd added | 17:22 |
| juliusb | insnfetcherror passing again... | 17:23 |
| stekern | ah, yeah, I probably should have done that update... didn't think about that I changed some of the generic modules | 17:32 |
| juliusb | np, is trivial (although I still managed to screw it up :P) | 17:38 |
| juliusb | wasn't paying attention | 17:38 |
| juliusb | i was redefining a module instantiation port automatic thing from a signal to 0 | 17:38 |
| juliusb | like, 2 lines below where it was written\ | 17:39 |
| stekern | I want to look at the fail btw, it's good to see and understand what's wrong | 17:41 |
| juliusb | which? the int/tick overlapping test? | 17:41 |
| stekern | yup | 17:42 |
| juliusb | cool | 17:55 |
| juliusb | well my updates don't appear to have broken anything in pronto | 17:55 |
| juliusb | btw loving this IRC logging thing | 17:57 |
| juliusb | means I can keep up to date with IRC from anything with a web browser | 17:57 |
| juliusb | a cron job is set for every 10 minutes to update the logs, although it appears to fire randomly | 17:58 |
| juliusb | 20 minutes sometimes | 17:58 |
| juliusb | oh well | 17:58 |
| juliusb | OK, espresso works witht he exact same patch as pronto | 18:04 |
| juliusb | 2 down - a frothy milk-based core to go :) | 18:04 |
| glowplug | The logs really are great. I actually like yours better than the one I suggested. Very neat and easy to read. =) | 18:10 |
| stekern | 20 minute intervals is more than good enough | 18:42 |
| LoneTech | slowly making progress on a karnaugh diagram drawing program I doubt anyone really needs | 19:32 |
| stekern | LoneTech: not even yourself | 19:38 |
| stekern | ? | 19:38 |
| LoneTech | well, I've missed it a little bit, about twice | 19:38 |
| LoneTech | for things like http://electronics.stackexchange.com/questions/61697/decoding-multiple-quadrature-rotary-encoders/61722#61722 | 19:38 |
| stekern | I can't recall drawing a karnaugh diagram once after graduating from university | 19:39 |
| stekern | we did use the word extensively during the study time, as a pun on the word 'kanon'... (sigh, student humor...) | 19:41 |
| juliusb | ??? | 19:42 |
| stekern | 'kanon' means 'canon', but is commonly used as an expression for 'super' or 'great' | 19:43 |
| LoneTech | that slang expression is from the cannon meaning, I believe | 19:45 |
| LoneTech | I believe kanon has at least three meanings | 19:45 |
| juliusb | stekern: well, wouldn't you know it -cappuccino passes this test without modifications! | 19:46 |
| stekern | LoneTech: yeah, that one 'n' slipped away under my fingers... | 19:46 |
| stekern | juliusb: intereseting, it fails here :/ | 19:47 |
| juliusb | oh?! | 19:47 |
| juliusb | just going to sanity check this end, make sure it's doing what I think it is | 19:48 |
| stekern | taking a look now, making sure I've got nothing in my working tree messing things up | 19:48 |
| juliusb | nope this definitely works... I think | 19:50 |
| stekern | oh, it works here too (I think), it just prints a couple of reports after the 0x80..0d, so I didn't see that | 19:51 |
| juliusb | yeah | 19:51 |
| juliusb | i will just check the code | 19:51 |
| juliusb | you may get a timer interrupt there | 19:51 |
| stekern | looks like it's based on the tickloop, right? | 19:52 |
| juliusb | yep | 19:52 |
| juliusb | the intloop/tickloop tests | 19:52 |
| stekern | so this should fix that too then: https://github.com/skristiansson/mor1kx-dev-env/commit/75b7d0b9afdc087a0a031534b070717aa07c344b | 19:53 |
| juliusb | ah i'm just going to disable tick/IRQ in SR when we finish | 19:56 |
| juliusb | we don't test for the whole thing being finished in the exception handler | 19:56 |
| stekern | ah, right | 19:58 |
| mor1kx | [mor1kx] juliusbaxter pushed 3 new commits to master: https://github.com/openrisc/mor1kx/compare/0014bfa73c6e...1f666b95d88f | 20:12 |
| mor1kx | mor1kx/master 8086c34 Julius Baxter: pronto cpu: tie off decode inputs for MMU exceptions as we don't have one | 20:12 |
| mor1kx | mor1kx/master 339d7d6 Julius Baxter: espresso cpu: tie off decode inputs for MMU exceptions as we don't have one | 20:12 |
| mor1kx | mor1kx/master 1f666b9 Julius Baxter: espresso and pronto ctrl: fix bugs with simultaneous tick and IRQ exceptions... | 20:12 |
| * juliusb rediscovers the "Pull Requests" button on github | 20:15 | |
| juliusb | I don't get it | 20:19 |
| juliusb | I just did the pull request | 20:20 |
| juliusb | then did remote update on my local clone, and it said it downloaded some stuff, but I don't see it | 20:20 |
| juliusb | like, it's not updated my local copy | 20:20 |
| juliusb | i did a git pull | 20:20 |
| juliusb | but i'm not on a branch, so it didn't work | 20:21 |
| juliusb | ah I needed to do : git pull origin master | 20:24 |
| stekern | umm, are you making pull requests to yourself? ;) | 20:27 |
| stekern | ah, now I see what you're doing | 20:29 |
| glowplug | Git can be a pain in the ass. ;) | 20:38 |
| stekern | no no, | 20:44 |
| juliusb | can anyone remind me how we run objcopy to generate a binary of stuff starting at 0xf0000000 and have it start from 0? | 22:00 |
| juliusb | i'm trying to emulate running from flash - so have compiled with a linker script saying the code is in 0xf0000000 space | 22:01 |
| stekern | you can define different load and run addresses with the linker script | 22:19 |
| juliusb | ah it's ok - I think my approach was bad | 22:20 |
| juliusb | so I'm interested in running mor1kx out of a "ROM" so all instruction and data accesses are single cycle | 22:20 |
| juliusb | well, accesse to code literals | 22:20 |
| juliusb | but RAM obviously may not be single cycle | 22:20 |
| juliusb | just to test the behaviour of this stuff | 22:21 |
| juliusb | so I'm thinking maybe we should rename the top-level like mor1kx_wb_wrapper or something | 22:22 |
| juliusb | I like how you've integrated the caches and MMUs more into the pipeline | 22:22 |
| juliusb | we can basically make mor1kx_cpu the bus-agnostic top-level | 22:22 |
| juliusb | and then have bus-interface wrappers | 22:22 |
| juliusb | with different ports etc. | 22:22 |
| juliusb | but for now in this system I'm just implementing a mor1kx_cpu in orpsoc and hooking ibus up to a dedicated memroy | 22:23 |
| stekern | yeah, that sounds cool for now. | 22:24 |
| stekern | I was thinking about putting the ROM interface straight in the fetcher | 22:25 |
| stekern | and parameterise away all redundant logic in that mode | 22:25 |
| juliusb | a ROM interface for a TCM or something? | 22:26 |
| stekern | because, the way I have it now, all wb-accesses are "protected" by being registered (you could of course just parameterise that protection, but you still get some overhead by the wb-bus) | 22:27 |
| juliusb | "protected" timing path wise? | 22:28 |
| stekern | exactly | 22:28 |
| stekern | my thinking behind that is, cappuccino being the "big muscle" pipeline, you're probably going to have caches enabled if you connect it to some main memory, so the extra cycle there won't be that hurtful | 22:29 |
| stekern | cache refill is seperated from that protection, so that's not having the penalty | 22:31 |
| juliusb | huh, how is cache refill protecteD? | 22:31 |
| juliusb | that would certainly go to the wb-bus no? | 22:32 |
| stekern | so, I have basically completely seperated the cache-accesses and bus-accesses (this is icache only so far) | 22:32 |
| stekern | yes, the cache refill goes straight to the wb-bus. But the path for that ends in writing into the cache (basically) | 22:33 |
| stekern | so that's not so critical | 22:33 |
| juliusb | just as I suspected - prontoespresso doesn't run even the simplest tests :) | 22:49 |
| juliusb | not sure why not yet, thuogh | 22:50 |
| juliusb | oh, dbus craps out, probably didn't hook it up right. d'oh! | 22:51 |
| stekern | that's what usually happen when I change something too, I've forgot to connect signals all over the place | 22:56 |
| stekern | and nothing even compiles because of all the typos | 22:56 |
| stekern | mail ohoy ;) | 22:57 |
| juliusb | !!! | 22:57 |
| juliusb | awesome man :) | 22:57 |
| juliusb | thoroughly epic | 22:58 |
| stekern | and on that bombshell, bedtime :) | 22:58 |
| juliusb | haha | 22:58 |
| juliusb | i want to see a cat /proc/cpuinfo before I believe it :) | 22:59 |
| stekern | I didn't connect the keyboard to it, you just have to take my word for it =P | 23:00 |
| juliusb | sure, sure :) | 23:07 |
| --- Log closed Sun Mar 24 00:00:36 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!