| --- Log opened Sun Mar 24 00:00:36 2013 | ||
| Gentlema` | Hello. | 00:54 |
|---|---|---|
| glowplug | Good afternoon. =) | 01:20 |
| glowplug | I found an SDR project on github. https://github.com/NBitWonder/SDR | 01:23 |
| Gentlema` | How interesting. | 02:46 |
| Gentlema` | Sorry, I did not see your reply. | 02:46 |
| Gentlema` | I finally made it out today. | 02:46 |
| Gentlema` | Considering of where we are, I do think that the FPGA approach is better than the micro approach to SDR. | 02:49 |
| glowplug | Yeah Its really unfortunate that he decided to use a PIC for that project. | 02:51 |
| Gentlema` | It does appear to limit its capabilities. | 02:51 |
| glowplug | Severely. | 02:52 |
| Gentlema` | The farmers here got fed up and cleared a path themselves about six feet wide. | 02:53 |
| Gentlema` | Snow piled precariously. | 02:53 |
| glowplug | I'm surpirsed there are farmers there! I wonder how long their grow season is... | 02:54 |
| Gentlema` | We are in the northern end of the breadbasket. | 02:57 |
| Gentlema` | The soil here is fairly fertile as well. | 02:57 |
| Gentlema` | In fact, the mojority of potash is mined from this area. | 02:58 |
| Gentlema` | *majority. | 03:00 |
| Gentlema` | Also, uranium. | 03:00 |
| glowplug | Are you joking or being serious? Haha | 03:03 |
| Gentlema` | Serious. | 03:04 |
| glowplug | That is epic... | 03:04 |
| glowplug | Onesecond have to reboot. | 03:04 |
| glowplug | Back. | 03:09 |
| Gentlema` | *That* was far longer than one second... | 03:09 |
| Gentlema` | Saskatchewan has ~40% of the World's Uranium. | 03:10 |
| glowplug | Learn something new every day. 8) | 03:15 |
| Gentlema` | Indeed... | 03:17 |
| glowplug | Have you learned anything about the memory controller? | 03:36 |
| Gentlema` | I have learned some about the memory controller. | 03:41 |
| Gentlema` | I am currently attempting to get stekern's tools to build. | 03:41 |
| glowplug | I see. What kind of issues are you running into? | 03:43 |
| Gentlema` | At the moment undefined functions from either within the project or dependiencies from one of stekern's other projects... | 03:45 |
| stekern | Gentlema`: can you paste the errors? | 03:47 |
| Gentlema` | or1ktrace.c: In function 'or1ktrace_init': | 03:48 |
| Gentlema` | or1ktrace.c:316:28: error: 'bfd_arch_or1k' undeclared (first use in this function) | 03:48 |
| Gentlema` | or1ktrace.c:316:28: note: each undeclared identifier is reported only once for each function it appears in | 03:48 |
| Gentlema` | or1ktrace.c:321:48: error: 'print_insn_or1k' undeclared (first use in this function) | 03:48 |
| Gentlema` | make[1]: *** [libor1ktrace_la-or1ktrace.lo] Error 1 | 03:48 |
| Gentlema` | 03:48 | |
| glowplug | The best way to paste errors is to use http://tny.cz/ | 03:54 |
| glowplug | That way you don't lose formatting and it takes up less space on IRC. =) | 03:54 |
| glowplug | Why would there be an undeclared variable? O.o | 03:56 |
| stekern | oh, that's juliusb tools ;) | 03:56 |
| Gentlema` | Sorry. | 03:58 |
| Gentlema` | I transposed names. | 03:58 |
| stekern | Gentlema`: did you build the toolchain like this? http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Newlib_toolchain_.28or1k-elf.29 | 03:58 |
| mor1kx | [mor1kx] skristiansson pushed 2 new commits to master: https://github.com/openrisc/mor1kx/compare/1f666b95d88f...dbc447518fca | 04:27 |
| mor1kx | mor1kx/master 884da83 Stefan Kristiansson: icache: remove bypass leftovers | 04:27 |
| mor1kx | mor1kx/master dbc4475 Stefan Kristiansson: dcache: change local parameters to localparam | 04:27 |
| stekern | what a relief, none of the mmu changes have decreased fmax (actually increased it slightly) | 04:37 |
| stekern | timequest reports 82.37 as fmax on the de0-nano | 04:37 |
| stekern | with mmus disabled | 04:38 |
| stekern | around 72 Mhz with them enabled | 04:38 |
| stekern | and then the critical path goes from dmmu->wb-bus->rf | 04:39 |
| stekern | through dcache | 04:39 |
| stekern | which is the next thing on my list to go through | 04:40 |
| stekern | is it me or verilator that is stupid? this patch fixes what verilator considers a comb-loop: http://pastie.org/7097134 | 07:58 |
| stekern | is it because of the blocking statements in the pre-patch case? | 08:25 |
| juliusb | hmmm, yeah, strange! | 10:35 |
| stekern | juliusb: still around? why do I get "%Warning-WIDTH"s even though I use "-Wno-WIDTH"? | 11:46 |
| stekern | this is in execute_alu, so I assume you get around that | 11:48 |
| juliusb | pastie? | 11:57 |
| stekern | http://pastie.org/7098580 | 12:01 |
| stekern | and I run it with: make vlt-tests USER_VLT_FLAGS="-Wno-WIDTH" | 12:02 |
| juliusb | hmm odd - what default for the divider are you using? | 12:14 |
| juliusb | err I mean what parameter are you passing? | 12:14 |
| juliusb | just try putting the /* verilator lint_off WIDTH */ around it | 12:15 |
| juliusb | btw I'm verilator version: Verilator 3.841 2012-09-03 rev verilator_3_841 | 12:15 |
| stekern | 3.820 here | 12:18 |
| stekern | I think I'm using the serial and cmov enabled | 12:18 |
| juliusb | The way we call verilator in orpsoc/mor1kx-dev-env is like so: | 12:18 |
| juliusb | verilator -language 1364-2001 --top-module orpsoc_top -Mdir . --sc \ | 12:18 |
| juliusb | --trace --exe --inline-mult 1 -O3 -x-assign unique -I/work/mor1kx-dev-env/boards/generic/mor1kx-prontoespresso/sim/run/../../../../../bench/sysc/include -I/work/mor1kx-dev-env/boards/generic/mor1kx-prontoespresso/sim/run/../../../../../bench/sysc/src \ | 12:18 |
| juliusb | -f /work/mor1kx-dev-env/boards/generic/mor1kx-prontoespresso/sim/run/../../sim/vlt/verilator.scr | 12:18 |
| juliusb | no -Wno-* | 12:19 |
| juliusb | (nothing passed in the verilator.scr either) | 12:19 |
| stekern | yeah, but the USER... get passed somewhere, because if I do -Wno-BLAH it errors with unknown option | 12:20 |
| juliusb | oh.. the USER stuff gets exported? Let me look... | 12:20 |
| juliusb | nope, no -Wno-* stuff anywhere in the verilator makefile | 12:22 |
| juliusb | maybe hard to understand exactly why this is happening, but just do the annoying thing and put the lint_off comments around it | 12:22 |
| juliusb | I'm happy to have that committed | 12:22 |
| juliusb | it's a known shortcoming in Verilator's linting | 12:23 |
| juliusb | (if the parameter passed is a different string length to the one defined as the default in the module, this will fail linting) | 12:23 |
| stekern | yeah, and we'll be able to catch real width errors | 12:24 |
| juliusb | yep | 12:24 |
| juliusb | man I need to buy Wilson Snyder a beer if I ever meet him - this is a very good tool isn't it? | 12:24 |
| juliusb | just the fact it's a good lint tool is enough | 12:25 |
| juliusb | so i'll buy him a beer for that feature, and a beer for the cycle-accurate C model bit | 12:26 |
| juliusb | :) | 12:26 |
| stekern | "it's an annoying bitch, but a good annoying bitch" to quote you (I think) ;) | 12:30 |
| juliusb | Certainly | 12:30 |
| juliusb | the quality of the code and design is better for it | 12:31 |
| stekern | next problem: undefined references to set_mem32 and getGpr | 14:07 |
| stekern | I know I've encountered that before, but no what the solution was... | 14:08 |
| juliusb | mmmm | 14:11 |
| juliusb | in the cappuccino pipeline? | 14:11 |
| juliusb | or in the systemc stuff? | 14:11 |
| stekern | in the systemc stuff | 14:13 |
| stekern | I get that in espresso too | 14:13 |
| stekern | they are suppose to be in a OrpsocMemoryAcces | 14:16 |
| stekern | ah, it's this stupid problem that files change name if the content change | 14:47 |
| stekern | the gnerated files | 14:48 |
| stekern | this need to be fixed once for all | 14:55 |
| glowplug | Have you guys talked about adding SIMD to mor1kx? | 20:58 |
| juliusb | the vector data instruction set in the OR1K architecture? | 21:52 |
| glowplug | Exactly. For parallel computation and basic 3d operations ect. | 21:53 |
| juliusb | it's not critical, or on the plan | 21:53 |
| juliusb | so, not much thought for it- but please, have a go :) | 21:53 |
| juliusb | it wouldn't be that hard | 21:53 |
| glowplug | There is some SIMD work in the ORSoc graphics core which is in Verilog. | 21:53 |
| glowplug | I'm still trying to learn the basics though. I think I would be really interested in attempting that. =) | 21:54 |
| stekern | juliusb: I've hacked OrpsocMor1kxAccess and OrpsocMemoryAccess to not depend on those numbers. | 21:56 |
| stekern | it's not so pretty, and can potentially slow down since it now references through orpsoc_top and down to the modules | 21:57 |
| stekern | but however ugly it is now, it's still prettier than constantly have to change those includes and classes etc... | 21:57 |
| stekern | I'll clean it up tommorrow and send it to you | 21:59 |
| juliusb | ok, sounds good | 21:59 |
| juliusb | it never bothered me too much as it rarely changed | 22:00 |
| stekern | how have you put up with changing those numbers around for so long?? ;) | 22:00 |
| juliusb | I did it only like 3 times all up! | 22:03 |
| stekern | heh, ok | 22:03 |
| stekern | maybe it's me tinkering with stuff to much so they change a lot... | 22:03 |
| stekern | s/to/too | 22:04 |
| stekern | anyway, I'm sleep deprived, have to go to bed. I almost went already at 21:00, but remembered that I hadn't put together my invoices for the bookkeeper and she needs it tomorrow. | 22:05 |
| stekern | but when that was done, sitting by the computer and having a nagging problem was too much to resist... | 22:06 |
| glowplug | Haha | 22:07 |
| glowplug | Have a good sleep and dont let the "bugs" keep you up. =) | 22:07 |
| juliusb | :) | 22:07 |
| juliusb | I know the feeling | 22:07 |
| juliusb | mor1kx didn't really need a single-cycle ROM fetch unit | 22:08 |
| juliusb | but, i would like it | 22:08 |
| juliusb | so | 22:08 |
| juliusb | have almost finished it :) | 22:08 |
| juliusb | pronto-espresso, specifically | 22:09 |
| asm | ok, today's goal | 22:13 |
| asm | get linux running on my de0 nano | 22:13 |
| * asm gets excited | 22:13 | |
| juliusb | :) | 22:13 |
| asm | I'm going to start here: http://ec2-122-248-210-243.ap-southeast-1.compute.amazonaws.com/mediawiki/index.php/UClinux | 22:14 |
| asm | unless you guys have some other recomendations | 22:14 |
| juliusb | erm | 22:15 |
| juliusb | you realise you're in #openrisc? | 22:15 |
| asm | ya | 22:15 |
| asm | haha, excellent point | 22:15 |
| asm | is the a good tutorial on getting linux on the openrisc core? | 22:15 |
| juliusb | and the page you just posted talks about using some horrible proprietary shite from Altera? | 22:15 |
| asm | yeah :( | 22:15 |
| glowplug | =( | 22:15 |
| asm | nios2 | 22:15 |
| * asm googles again | 22:16 | |
| glowplug | NIOS 2 is our enemy. Haha | 22:16 |
| juliusb | but... haha, yes I'm not sure there's a nice easy guide for the de0 nano | 22:16 |
| juliusb | my goal for the weekend was to do a guide for running FreeRTOS on the DE0 nano | 22:16 |
| juliusb | but I wrote a single-cycle ROM fetch unit for the mor1kx instead :( | 22:16 |
| asm | well, ok, I'll start over | 22:16 |
| juliusb | but I will prepare something like that for the chiphack.org | 22:16 |
| juliusb | event | 22:16 |
| asm | my real goal is to get mruby on the de0-nano | 22:16 |
| juliusb | so if you check back ni a few weeks the FreeRTOS tutorial should be avialable | 22:17 |
| asm | I was thinking of using uclinux + nios2 | 22:17 |
| asm | but I'd love to use openrisc | 22:17 |
| glowplug | You should look into Topaz > Mruby although it is very infant. | 22:17 |
| glowplug | For embedded development. | 22:17 |
| asm | dur, it's written in python? | 22:18 |
| asm | you're talking about this? http://docs.topazruby.com/en/latest/blog/announcing-topaz/ | 22:18 |
| glowplug | asm do you plan on learning Verilog and actually modifying the fpga ip? | 22:18 |
| asm | glowplug: eventually | 22:18 |
| asm | I'd like to write custom vhdl <-> ruby bindings | 22:19 |
| glowplug | Its not really written in Python. Its RPython and it compiles Ruby into C at runtime through something called the JIT. | 22:19 |
| asm | that seems far overblown at the moment | 22:19 |
| asm | mruby is just simple c | 22:19 |
| asm | bbiab | 22:19 |
| glowplug | Its actually extremely underblown. | 22:19 |
| glowplug | You write Ruby. Run translator and it generates C magically. | 22:19 |
| glowplug | =) | 22:19 |
| glowplug | There are some things to consider though. Firstly at the processing power of openrisc/nios2 is not enough for mruby/topaz ect. | 22:21 |
| glowplug | I would suggest that if you want to do embedded Ruby development for now you need a very fast embedded CPU. Like an imx233. | 22:23 |
| glowplug | And if you want to do RTL type stuff seperately on the Nano. Then merge them at a much later date when its realistic. | 22:24 |
| glowplug | This is the best board for doing Ruby in tiny systems at the moment. https://www.olimex.com/Products/OLinuXino/iMX233/iMX233-OLinuXino-MICRO/ | 22:25 |
| glowplug | Here is a really great article that explains why RPython (and Topaz) are fundamentally different than regular interpreters (like mruby). | 22:43 |
| glowplug | http://tratt.net/laurie/tech_articles/articles/fast_enough_vms_in_fast_enough_time | 22:43 |
| asm | back | 22:56 |
| asm | reading your links | 22:56 |
| asm | that's not a bad little board | 22:56 |
| asm | but the raspberry pi is far better | 22:57 |
| asm | and cheaper | 22:57 |
| glowplug | The board I linked can be homebuilt for $15. Also the RPi is our enemy. | 22:57 |
| asm | oh dear | 22:57 |
| asm | you guys have too many enemies :P | 22:57 |
| glowplug | They have a bad history about being dishonest about their product. | 22:58 |
| glowplug | Contrary to popular belief the RPi is a very closed system. | 22:58 |
| asm | indeed | 22:58 |
| asm | but it's an important first step | 22:59 |
| asm | regardless, I'm not here to talk about embedded systems | 22:59 |
| asm | I want to see fpgas running more applications | 22:59 |
| asm | and more accessable | 22:59 |
| glowplug | FPGA's are bad at running serial applications. | 22:59 |
| asm | very true | 23:00 |
| asm | and this is why I think they're the future | 23:00 |
| glowplug | The reason we develop on FPGA's is because we cannot fabricate our own semiconductor chips (yet). | 23:00 |
| asm | yup, now it's time to think out of the box | 23:00 |
| glowplug | It would be exceptional if FPGA's could run at 1.6ghz. | 23:00 |
| glowplug | But it's simply not possible. | 23:01 |
| asm | and they will soon | 23:01 |
| asm | not to mention they'll have more and more LEs | 23:01 |
| glowplug | FPGA architectures are proprietary. | 23:01 |
| asm | but think about the paradigm shift in the macroprogramming world | 23:01 |
| asm | programmers are no longer coding serial systems | 23:01 |
| asm | we have parallel and async systems to work with now | 23:02 |
| asm | wouldn't it be nice if these systems ran on fpgas? | 23:02 |
| glowplug | SIMD devices. Absolutely. | 23:02 |
| glowplug | No it would be horrible. Haha | 23:02 |
| asm | today it's horrible | 23:02 |
| asm | sure | 23:02 |
| glowplug | FPGA's are only good for 1. designing systems 2. low volume systems that need to change constantly | 23:02 |
| asm | and 2 is the key | 23:02 |
| asm | think about what the average computer is doing | 23:03 |
| glowplug | The average computer is roughly five million times more efficient than an FPGA + NIOS2. | 23:03 |
| asm | today it is | 23:03 |
| glowplug | =) | 23:03 |
| glowplug | There are a lot of problems with assuming that FPGA's will surpass ASIC's. | 23:04 |
| glowplug | For example. Xeon Phi boards yield 1TFLOPS double float at 200 watts. | 23:04 |
| glowplug | That number is only going to go up... fast.. | 23:04 |
| asm | but it's not going up because of advances in chipmaking | 23:04 |
| glowplug | Currently embedded processors on FPGA's are many billions of times less efficient. | 23:05 |
| asm | currently | 23:05 |
| glowplug | That gap will widen. | 23:05 |
| glowplug | With the ASICs getting more and more ahead of FPGA's. | 23:05 |
| asm | the asics are only changing their architecture | 23:05 |
| asm | the chip tech isn't changing | 23:06 |
| asm | whereas fpgas have a long way to go | 23:06 |
| glowplug | Phi is 50 Ivy Bridge cores at 1.2ghz. | 23:06 |
| glowplug | On a single chip. | 23:06 |
| asm | imagine if intel put that kind of effort into fpgas | 23:06 |
| glowplug | If FPGA's ever come within a million times as efficient. It would take 200 years. | 23:06 |
| asm | think about where we were 200 years ago | 23:07 |
| asm | I'd say you're off a few :) | 23:07 |
| glowplug | I know that technology improves over time. | 23:07 |
| glowplug | But ASIC performance will always scale faster than FPGA. | 23:07 |
| asm | yes, for a single purpose | 23:07 |
| glowplug | An FPGA with a serial processing core is a single purpose processor. | 23:08 |
| asm | indeed | 23:08 |
| asm | but what if it could reconfigure itself based on its workload | 23:08 |
| asm | suddenly, it's far more efficient | 23:09 |
| glowplug | There are firms working on that. But the benefits are maybe 1-2 times. Not the billion times that it would need. | 23:09 |
| asm | I have a perfect example on my desk | 23:09 |
| asm | I have a top of the line intel cpu | 23:09 |
| glowplug | Alright. | 23:23 |
| asm | it's hash rate of sha256 is about 1 mega hash/s | 23:23 |
| asm | firing on all cores | 23:23 |
| glowplug | Do you know what the most efficient and fastest sha256 core is on the planet? | 23:23 |
| glowplug | It's an ASIC. =) | 23:23 |
| glowplug | By about a factor of 1,000 compared to FPGA's. | 23:23 |
| asm | in the machine next to it, I have 8 gpus | 23:23 |
| asm | they each have about 1024 vector cores | 23:23 |
| asm | this machine can do about 500-700gh/s | 23:23 |
| asm | err mega | 23:23 |
| asm | hold on I'm getting there | 23:23 |
| asm | on my desk is an fpga doing about 300mh/s using a trivial amount of power | 23:23 |
| glowplug | Right. | 23:23 |
| asm | and the avalon asic system is doing something in the gh/s range | 23:23 |
| glowplug | And there is an ASIC chip that gets 65gh/s using less power than your FPGA. | 23:23 |
| asm | my point here is this: the fpga is certainly not the fastest system at hashing | 23:23 |
| glowplug | It will never be physically possible for an FPGA to be even within an order of magnitude of an ASIC for any task. | 23:23 |
| glowplug | The ultimate goal for designing open source processors, graphics cards, network controllers, is to have those cores made into ASICs. | 23:23 |
| glowplug | Flashing them to FPGA's is an intermediary development stage. | 23:23 |
| glowplug | FPGA's themselves are an intermediary technology. | 23:23 |
| -!- Netsplit *.net <-> *.split quits: ams, heroux | 23:23 | |
| -!- Netsplit *.net <-> *.split quits: jonmasters | 23:24 | |
| asm | doh, irc hiccup | 23:24 |
| glowplug | Interesting.... | 23:26 |
| asm | http://opencores.org/or1k/FPGA_Development_Boards#Pre-built_image_with_orpsoc.2C_U-Boot_and_Linux | 23:27 |
| asm | nice | 23:27 |
| glowplug | At any rate. You should look into the homecmos project. The goal is to open up the technology for fabricating ASIC's to the masses. Totally eliminating proprietary FPGA's from the picture. Open design => Open hardware with no middleman. | 23:27 |
| asm | that would be nice | 23:28 |
| glowplug | It would truly cause a paradigm shift. Infact it would be possible to fabricate FPGA's with an open architecture to fulfill niche markets (like motion control and software defined radios ect.). | 23:35 |
| glowplug | But FPGA's themselves are a solution to only a very small amount of problems. And they scale very poorly. | 23:35 |
| glowplug | If you are interested in getting heavily involved in processor design (asic OR fpga) you should research all of the tools on this site. http://opencircuitdesign.com/verilog/index.html | 23:35 |
| asm | perhaps, but let's just disagree for now :) | 23:35 |
| -!- Netsplit over, joins: heroux | 23:35 | |
| asm | thanks! | 23:35 |
| glowplug | Let me put it this way. Altera and Xilinx are not capable of what you describe. But if you want to design such an FPGA do so in Verilog and have it made into an ASIC (which an FPGA is, oddly). You can use VTR as a design basis and sythesis toolchain. https://code.google.com/p/vtr-verilog-to-routing/ | 23:46 |
| asm | I'm not interested in building asics for now | 23:46 |
| glowplug | If thats true then you will never see FPGA's as fast as you want. Unfortunately. | 23:46 |
| glowplug | I would very much like for that to be possible. | 23:46 |
| glowplug` | Did I just get booted? | 23:50 |
| juliusb | the server's going crazy | 23:50 |
| -!- Netsplit *.net <-> *.split quits: simoncoo1, nollan, _franck_, serp__, larks, larks_, jonmasters_, stekern, orsoc1_, Amadiro, (+14 more, use /NETSPLIT to show all of them) | 23:58 | |
| --- Log closed Mon Mar 25 00:00:41 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!