| --- Log opened Mon Mar 25 00:00:41 2013 | ||
| -!- Netsplit over, joins: asm, Amadiro, larks, simoncoo1, heroux, jonmasters_, _franck_, jeremybennett, poke53281, Gentlema` (+10 more) | 00:02 | |
| -!- Netsplit over, joins: zhai365 | 00:04 | |
| mor1kx | [mor1kx] juliusbaxter pushed 2 new commits to master: https://github.com/openrisc/mor1kx/compare/dbc447518fca...46ed8202e90a | 00:09 |
|---|---|---|
| mor1kx | mor1kx/master 2208039 Julius Baxter: pronto: add new "TCM" fetch unit... | 00:09 |
| mor1kx | mor1kx/master 46ed820 Julius Baxter: Merge branch 'master' of https://github.com/openrisc/mor1kx into debug-dev | 00:09 |
| --- Log closed Mon Mar 25 01:27:12 2013 | ||
| --- Log opened Mon Mar 25 01:27:59 2013 | ||
| -!- Irssi: #openrisc: Total of 23 nicks [0 ops, 0 halfops, 0 voices, 23 normal] | 01:27 | |
| -!- Irssi: Join to #openrisc was synced in 17 secs | 01:28 | |
| -!- Netsplit *.net <-> *.split quits: glowplug` | 01:33 | |
| -!- Netsplit over, joins: glowplug` | 01:41 | |
| -!- Netsplit *.net <-> *.split quits: glowplug` | 02:02 | |
| -!- Netsplit over, joins: glowplug` | 02:09 | |
| --- Log closed Mon Mar 25 02:28:16 2013 | ||
| --- Log opened Mon Mar 25 02:41:53 2013 | ||
| -!- Irssi: #openrisc: Total of 23 nicks [0 ops, 0 halfops, 0 voices, 23 normal] | 02:42 | |
| -!- Irssi: Join to #openrisc was synced in 58 secs | 02:42 | |
| stekern | asm: you don't, you have to hookup a ttl-uart (e.g. http://www.miniinthebox.com/cp2102-usb-2-0-to-ttl-uart-6pin-module-serial-converter_p391022.html) to the pinheader | 03:13 |
| stekern | and asm, I'm with you, I'm neither very interested in building ASICs for now ;) | 03:25 |
| glowplug` | It's not for everyone. But at least we should aknowledge the limitations of FPGA's. And their strengths (a development platform for IP). 8) | 03:34 |
| stekern | yes, no doubt about that | 03:36 |
| glowplug` | One thing I want to apologize for asm. I watched a few talks on mruby (mostly rubycon 2012). Apparently it probably WILL run on an OR1200 core. But very very slowly. To get your interactive ruby shell you need to first get an RTOS running on the FPGA. The guys here can help you with that. =) | 03:37 |
| stekern | there's a 3) that you forgot in your list of "FPGAs are only good for". | 03:39 |
| glowplug` | Low volume highly parallel embedded tasks? | 03:39 |
| stekern | 3) systems that need to have the same hardware, but should be sold for different purposes | 03:39 |
| glowplug` | Ahh. Yes that I agree with also. =) | 03:40 |
| glowplug` | FPGA's kick extreme ass at software defined radio and motion control. ASIC's could replace them (and be cheaper and faster) but for some reason they haven't yet. It could be an issue of sales volume. | 03:41 |
| stekern | probably | 03:45 |
| stekern | tbh, i've seen a tendency to move away from ASICs towards fpgas in some application fields | 03:46 |
| glowplug` | Thats the world we live in. Where ASICs are for rich people / large business's only. | 03:47 |
| stekern | oh, this is multibillion large businesses | 03:47 |
| glowplug` | The only physical way to get certain functionality is with FPGAs. Certainly the only realistic way to test rapidly changing hardware designs. | 03:47 |
| stekern | but application falls into your 2) | 03:48 |
| glowplug` | My only point is that they are an intermediary step. We started with zero ability for a hobbyist to design hardware. Now FPGA's give us a slow, expensive, but functional way to do so. And they will eventually be enveloped by rapidly prototyped ASIC's. | 03:49 |
| stekern | and my point is that both have a place and purpose, our problem now is that we only can serve the needs that FPGA's serves, since we have no ability to (easily) produce ASICs | 03:53 |
| glowplug` | I agree completely. =) | 03:54 |
| glowplug` | I think asm was looking to FPGA's for a fast efficient replacement for ASICs. A role they can never fullfill. Unfortunately. | 03:55 |
| glowplug` | Here is something you might be interested in. http://www.myhdl.org/doku.php | 03:58 |
| glowplug` | It allows you to write hardware in Python and compile to Verilog. O_O | 03:58 |
| stekern | I know about it very well | 04:00 |
| glowplug` | Awesome! So you have tried it? | 04:01 |
| stekern | here is another: https://github.com/milkymist/migen | 04:01 |
| stekern | no, haven't tried it | 04:02 |
| glowplug` | This migen project looks very interesting. They use it for SDR. Thanks for the link! | 04:03 |
| glowplug` | I read some reports that MyHDL can sometimes general such good RTL that people at their work cannot even tell it was generated. | 04:04 |
| glowplug` | *sometimes generate | 04:04 |
| glowplug` | I'm reading through the migen documentation right now. It seems like it is quite a bit better than MyHDL. Very cool. | 04:48 |
| stekern | they have a bit of different goals and strategies | 04:53 |
| glowplug` | I really like the Migen approach. The Python side of it is much cleaner and it seems like there is a lot less room for error on the part of the coder. Which is always good. =) | 04:56 |
| glowplug` | I'm going to try and do the "blinking LED" and get the output on GTKWave. | 04:56 |
| glowplug` | Then start working on adding SIMD to mor1kx! | 04:57 |
| glowplug` | What is your opinion of the LatticeMico32 CPU? Is it worth studying? | 05:10 |
| stekern | glowplug`: the architecture is very similiar to or1k | 06:03 |
| stekern | it's IMO less interesting since it's the child of a large semiconductor company in contrast to the completely community driven openrisc | 06:05 |
| stekern | the implementation is very good from what I've seen, one of mor1kx goals is to become as good and then beat it | 06:06 |
| stekern | (or at least one of my goals with mor1kx-cappuccino) | 06:07 |
| stekern | juliusb: what does 'TCM' stand for? | 06:24 |
| stekern | 'git pull -r openrisc_github master' and 'git push openrisc_github debug-dev:master' are the magical commands you should remember ;) | 06:27 |
| stekern | or your debug-dev tree into master and then push to openrisc_github master, that way the merge message makes a lot more sense | 06:33 |
| stekern | *or merge your | 06:33 |
| asm | sweet, I finally got uclinux running | 06:38 |
| asm | CPU: NIOS2 | 06:38 |
| asm | MMU: none | 06:38 |
| asm | FPU: none | 06:38 |
| asm | Clocking: 100.0MHz | 06:38 |
| asm | BogoMips: 48.94 | 06:38 |
| asm | Calibration: 24473600 loops | 06:38 |
| asm | sorry I went with nios2 | 06:38 |
| stekern | oh no! | 06:38 |
| asm | I couldn't get the orpsoc stuff working | 06:38 |
| asm | soon :) | 06:39 |
| stekern | :) | 06:39 |
| stekern | orpsoc for de0-nano is easy, just 'make all' and 'make pgm' and you're done with it | 06:40 |
| asm | yeah, well, there is one issue | 06:40 |
| asm | I'm running linux in a vmware vm | 06:40 |
| asm | and the usb passthrough doesn't seem to be working well atm | 06:40 |
| asm | but I've had all kinds of usb issues today | 06:40 |
| asm | (had to buy a new hub) | 06:40 |
| asm | I'll get it ironed out eventually | 06:40 |
| stekern | in the boards/altera/de0_nano/syn/quartus/run/ directory | 06:41 |
| asm | yeah, I found the readme for the de2-115 | 06:41 |
| stekern | ah, ok, so it wasn't an orpsoc issue at all ;) | 06:41 |
| asm | nah | 06:41 |
| asm | but I just wanted to get something working before I crash for the night | 06:41 |
| stekern | yeah, I understand | 06:41 |
| stekern | actually, I think you could build orpsoc for de0-nano under windows | 06:42 |
| stekern | never tried hthough | 06:42 |
| asm | yup, you can | 06:42 |
| asm | just kinda weird | 06:42 |
| stekern | as long as you have make and the altera tools in your path, you should be all set | 06:42 |
| asm | and I think the jtag bridge works in cygwin | 06:43 |
| asm | ok, crash time | 06:43 |
| asm | thanks for all your help :) | 06:43 |
| asm | (and debate) | 06:43 |
| stekern | good night | 06:43 |
| asm | tomorrow I'll get mruby loaded up on here | 06:43 |
| asm | now I just have to dream of something to do with mruby that involves circuit design :) | 06:44 |
| stekern | I think you could get openocd compiled to run under windows too | 06:44 |
| * stekern thinking out loud | 06:45 | |
| stekern | juliusb: pull request ohoy! | 07:01 |
| stekern | jeremybennett: seems like all verilator questions I google I end up on the veripool boards where you are asking exact the same questions ;) | 08:16 |
| jeremybennett | stekern: Which particular question? | 08:19 |
| jeremybennett | One of the reasons I have a high profile is because Embecosm is paid to support Verilator. | 08:19 |
| stekern | oh, several, this was the latest: http://www.veripool.org/boards/3/topics/show/852?r=883 | 08:19 |
| olofk | stekern, jeremybennett: Have you discussed about merging the frame buffer support into or1ksim? I rediscovered it a while back, and it looks like it would apply as a clean patch | 08:23 |
| olofk | and I like frame buffers. I think they are pretty | 08:23 |
| stekern | me too | 08:23 |
| olofk | My unicorns and rainbows look like shit in ASCII | 08:23 |
| jeremybennett | stekern: Ah yes - I've done a lot of work on that, and it is not easy. Essentially Verilator follows true synthesis semantics - what you get is what you get with DC. However most simulators follow the simulation semantics. Turns out it's not so easy to add to Verilator after all. For now I've given up on it. | 08:24 |
| stekern | I think I pointed jeremybennett to it right after I'd done it, but I don't think he ever got around to take a look at it | 08:24 |
| jeremybennett | olofk: Which patch is this - I'm a bit behind. | 08:24 |
| stekern | we didn't have as good patch submission routines back then | 08:24 |
| jeremybennett | If Or1ksim still passes regression, and the change is documented a) in the ChangeLog and b) in the User Guide, please apply it. | 08:25 |
| stekern | and then I've kind of have forgot about it | 08:25 |
| jeremybennett | Or else send me the patch again to review. | 08:25 |
| stekern | olofk: if you feel like polishing it off and apply it ontop current or1ksim, that'd be cool | 08:26 |
| olofk | jeremybennett: Just to clarify, it was never sent as a patch, but I remembered a while back that stekern implemented it in his tree | 08:26 |
| olofk | stekern: Sure thing. I've been meaning to ask you if I should do that. | 08:27 |
| stekern | "while back" == around februari 2010 ;) | 08:27 |
| olofk | :) | 08:27 |
| olofk | When everyone else is busy running around and implementing new stuff, I find myself digging up old patches and replying to three-year old bugs :) | 08:28 |
| olofk | That's probably because I'm not in a position where I can do real coding at work | 08:28 |
| stekern | that's what everybody really *should* do | 08:28 |
| olofk | Yeah, every project needs that, and I don't mind | 08:28 |
| jeremybennett | olofk: stekern: We ought to follow the procedure. If you post the patch, then as maintainer I can approve it, and you can apply it. | 08:36 |
| stekern | yeah, sure, that sounds perfect | 08:36 |
| -!- Netsplit *.net <-> *.split quits: ams | 08:40 | |
| -!- Netsplit over, joins: ams | 08:44 | |
| stekern | juliusb: I just pushed a set of patches that makes cappuccino sweep through the judgemental eyes of verilator (github announcements seems broken atm). | 08:52 |
| stekern | but your TCM pipeline added a new warning: http://pastie.org/7108275 | 08:53 |
| stekern | s/pipeline/fetcher | 08:54 |
| stekern | pipelining_adr is not declared and not used anywhere else than where it is defined, so I didn't want to touch it myself, since you might want to use it later or just remove it | 08:56 |
| stekern | just so you know :) | 08:56 |
| -!- Netsplit *.net <-> *.split quits: ams | 08:57 | |
| -!- Netsplit over, joins: ams | 08:58 | |
| stekern | the running against gcc regression suite is way cool | 11:07 |
| stekern | looks like it's exposes some bug in cappuccino too | 11:08 |
| stekern | I found a bug in the Makefile though, it restarts from the next test after GCC_C_TESTS_START instead of that test | 11:27 |
| stekern | I snuck in a patch for that in the pending pull request | 11:28 |
| stekern | ah, maybe they are not failing, but just takes very long time to finish | 12:02 |
| stekern | yep, it was just that, cappuccino passed all tests with flying colors | 12:56 |
| juliusb | stekern: TCM - tighly coupled memory, maybe a ROM or something | 13:00 |
| juliusb | I also haev fixes to those lint errors in verilator | 13:00 |
| juliusb | I have another patch to push which makes it pass all tests | 13:00 |
| juliusb | and yes I should have done the nicer git pull command to remove the additional weird pull committ hing | 13:00 |
| juliusb | (btw keeping up with IRC as a web page is so much nicer than scrolling back in irssi) | 13:01 |
| juliusb | (so beenk eeping up with what's being said | 13:01 |
| juliusb | your pull request for the verilator fixes sounds good, too | 13:02 |
| juliusb | some of the GCC tests take aaages to finish | 13:02 |
| juliusb | all up I get about 2hours of runtime when running the tests against the espressos | 13:03 |
| juliusb | that's on my core i5 machine | 13:03 |
| juliusb | (against the verilator model, of course) | 13:03 |
| juliusb | a nicer thing for the gcc regression stuff would be something which logged the results | 13:04 |
| juliusb | proceeded on failure | 13:04 |
| juliusb | and continued | 13:04 |
| juliusb | another thing I'd like is to have the start sequence program the tick timer to fire at regular intervals during all of those tests | 13:04 |
| juliusb | that'd be easy to do I guess | 13:04 |
| juliusb | it's probably something we could have in the crt for all c-based tests | 13:05 |
| stekern | yeah, I figured out the TCM TLA, but this was the first hit on google: http://en.wikipedia.org/wiki/Traditional_Chinese_medicine | 13:10 |
| stekern | keeping track of irc on the web has one advantage though, when you see some guy saying something you sooo badly want to respond to =P | 13:14 |
| juliusb | :) | 13:14 |
| stekern | *disadvantage | 13:14 |
| juliusb | yeah like someone posting stuff about the NIOS | 13:14 |
| stekern | hehe | 13:15 |
| stekern | doesn't the normal VCD=1 work for vcd dumping with vlt-tests? | 13:17 |
| stekern | I know I've done that sometime in the past | 13:17 |
| stekern | man, do I hate this proprietary IDE... | 13:27 |
| stekern | visualdsp++ | 13:28 |
| juliusb | oh, not sure VCD=1 works for the vlt tests | 13:43 |
| juliusb | it's easier to just re-run the test by going ../vlt/Vorpsoc_top | 13:43 |
| juliusb | and because there's an sram.vmem file there it'll automatically run that | 13:43 |
| juliusb | and then you just pass -v I think | 13:43 |
| juliusb | and it'll dump to a VCD | 13:43 |
| juliusb | visualdsp++? | 13:43 |
| stekern | http://www.analog.com/en/content/search_vdsp_landing/fca.html?sourceid=goo_Analog+DSP+Search+Campaign_dsp+development+software_cat_ptab&gclid=CJS2v76AmLYCFZB4cAodqCgAfg#visualDSP | 13:46 |
| stekern | development tool for blackfin | 13:48 |
| juliusb | ah ok | 13:52 |
| juliusb | is it buggy or just annoying? | 13:52 |
| stekern | both :) | 13:54 |
| stekern | it frequently bluescreens this poor windows machine | 13:54 |
| stekern | the editor is complete shit (not that I would use it anyways) | 13:55 |
| stekern | and right now it's mostly annoying because it is a clicky gui-ide | 13:56 |
| juliusb | :) | 13:56 |
| juliusb | all of the complaints we receive about our bundled IDE for our DSPs, too:) | 13:56 |
| juliusb | i have been a little bit involved with the tools team here who maintian the IDE and compiler and stuff for the DSP | 13:57 |
| juliusb | so it's interesting to hear the thoughts of someone who actually has to use one of these things | 13:57 |
| stekern | I have this bug that shows at bootup 1/100 times, and I have breakpoints scattered in strategic places to catch it | 13:57 |
| stekern | in order to break, reload the program, and start the program I have to manually perform 3 different 'clicks' (or keystrokes, at least it has hotkeys) | 13:58 |
| juliusb | I don't think ours bluescreens too often, but the editor is considered a joke, and it's really annoying to use in general | 13:59 |
| juliusb | ewww | 13:59 |
| stekern | instead of being able to nicely automate it if it'd have some command line tools | 13:59 |
| mor1kx | [mor1kx] juliusbaxter pushed 3 new commits to master: https://github.com/openrisc/mor1kx/compare/93d42574f463...8b077a09df4f | 14:17 |
| mor1kx | mor1kx/master 9eaa12c Julius Baxter: pronto: remove unnecessary PC signal going from fetch to ctrl unit | 14:17 |
| mor1kx | mor1kx/master 8a1019c Julius Baxter: pronto tcm fetch: cleanup and bugfixes... | 14:17 |
| mor1kx | mor1kx/master 8b077a0 Julius Baxter: documentation: little bit of an update | 14:17 |
| juliusb | hah I'd kicked off a GCC tests run in mor1kx-dev-env, and in the meantime just don a rebase to push my work from last night. It was obviously doing one of the long loop tests, and when it finished the source had changed, and so it re-built the verilator model and continued :) | 14:22 |
| olofk | I want to remove a section from an elf file. Can I use objcopy for that? Does that output elf files? | 14:22 |
| olofk | solved it | 14:25 |
| olofk | (I think) | 14:25 |
| juliusb | objcopy with -R <sectionname> IIRC from my playing around the other day | 14:31 |
| glowplug` | Have you guys heard of BORPH? http://www.eee.hku.hk/~hso/borph.html | 16:40 |
| juliusb | that page doesn't say anything about the actual hardware (ie. RTL blocks) involved | 16:56 |
| juliusb | it's missing a lot of very important informatino about what is between the software and the FPGA | 16:57 |
| stekern | yeah, I agree, I don't get at all what it actually does from that | 17:11 |
| glowplug` | Back. The BORPH creates a file in linux that is the FPGA (the same way our mouse is a file ect.). | 17:17 |
| glowplug` | You can start, stop userland processes in the linux system that reconfigures the FPGA automatically. | 17:17 |
| juliusb | Fine. What can it do to that then? Does it have stuff on it already? | 17:18 |
| stekern | yes, that's what the page says. doesn't answer juliusbs questions | 17:18 |
| stekern | http://bee2.eecs.berkeley.edu/wiki/Bee2OperatingSystem.html | 17:18 |
| stekern | there's a little more info there | 17:18 |
| juliusb | OK, so let's say you program the FPGA - what's the API (presumably some registers or something on the FPGA) to allow interaction between the Linux system/FPGA hardware | 17:19 |
| glowplug` | The best example of BORPH being used is the Rhino project and ROACH. It simply makes it easier to load and unload IP and also allows you to write applications that communicate between hardware devices using linux (piping ect.). | 17:19 |
| glowplug` | The API is the linux file interaction itself. =) | 17:19 |
| glowplug` | So outputs from lets say an ethernet ic on the FPGA would be grep'able, pipeable ect. | 17:20 |
| juliusb | At the software level, maybe, but how does it actually communicate with the FPGA? Shared memory? SPI? | 17:20 |
| glowplug` | How it works under the hood I have no idea yet. I'm researching it right now. | 17:20 |
| glowplug` | But the possibilities of interfacing with individual hardware blocks as unix files are endless. | 17:20 |
| juliusb | There's tonnes of this airy-fairy academic FPGA stuff, but very little actually seems very powerful | 17:21 |
| glowplug` | It seems like they have a functional telescope radio that processes many billions of samples per second using it. And also a functional long range RADAR system. | 17:22 |
| juliusb | This seems like a sophisticated FPGA programming and communication system put under the Linux kernel's hood. Maybe that's a good place to put it? I don't know, but it seems like a bit of overkill | 17:23 |
| glowplug` | I do agree that academics can produce quite a lot of impractical stuff and make it sound great. But this is running some serious firepower. | 17:23 |
| juliusb | Well, I only think the mainstream CPU + FPGA thing works if you're selling some commodity accelerator | 17:24 |
| glowplug` | I agree. It is an overkill in functionality. But I can see some other great uses for that power to actually simplify things. | 17:25 |
| juliusb | sorry, some commodity accelerator platform - so you have a CPU and say a 16 large-ish FPGAs nearby. You'll certainly need some flexible, easy-to-use mechanism for configuring and communicating with the FPGAs | 17:25 |
| glowplug` | If it could be prepacked in a way that would allow developers to debug openrisc as linux files, load and unload hardware in a way they are already familiar with. ect. | 17:25 |
| juliusb | just like we have a system of standardising executables on operating systems, and it looks like they've done it here | 17:25 |
| glowplug` | I wish I understood more about how it worked. O.o | 17:26 |
| juliusb | for the applications you mentioned, thugh, it seems they could have just done it manually and you would have the same resault | 17:26 |
| juliusb | no doubt this just adds a layer of complexity which I'm not convinced is helpful or even necessary | 17:26 |
| glowplug` | I do agree that it is another layer, but I'm not convinced its a layer of complexity. | 17:27 |
| juliusb | but if I have an FPGA next to my CPU and I want to, say, quickly encode some video to h.264 or whatever, and I have an app which knows how to interface to that FPGA and configure it and feed it frames to make the job quicker, then sounds good to me. | 17:27 |
| glowplug` | CPython is a layer ontop of C. But an abstraction layer that reduces complexity. Hides it from the user. | 17:27 |
| juliusb | however we haven't seen this because modern CPUs are full of such accellerators and run at many GHz - orders of magnitude faster than complex maths or data processing can be run on an FPGA, even the fast ones | 17:28 |
| glowplug` | The current FPGA toolchain is extremely complex to most users who are new to the field. Like C to a Ruby programmer. | 17:28 |
| juliusb | it seems to me that someone must still run the FPGA tool chain at some point to generate the FPGA image | 17:29 |
| juliusb | all you're doing is putting the bit that flashes the image onto the FPGA under the hood of Linux | 17:29 |
| glowplug` | I will agree that modern CPU's are faster at serial tasks than FPGA's but they cannot interface with the outside world. It's a pain in the ass getting 13 IO from a parallel port on a modern PC. | 17:29 |
| juliusb | that is is the dead-easy part of FPGA design (so long as you have the right physical connections :P) | 17:29 |
| glowplug` | And gate latency in an FPGA is 10ns versus my Ivy Bridge PC that runs my CNC has only sub 10us. And thats if its not doing something else. | 17:30 |
| glowplug` | Maybe my example was poor too. Regarding the toolchain. | 17:30 |
| juliusb | I'm not sure the solution to crap I/O on commodity PCs is to put an FPGA next to them | 17:30 |
| glowplug` | I think that doing creative communication and debugging between IP on your FPGA using existing linux tools is the main advantage. | 17:31 |
| juliusb | fine, probably fine-grained real-time I/O control you want an FPGA for | 17:32 |
| glowplug` | You might be right. But the radio and robotics guys seem to think its the solution. Haha | 17:32 |
| juliusb | Mmm I'm of the opinion that the FPGA debug flow is obfuscated enough without adding the Linux kernel to the mix!!! | 17:32 |
| glowplug` | Its a layer of abstracting away complexity though. Not adding complexity to it. | 17:33 |
| glowplug` | How simple is "this file is my nic, I can cat to it, grep it, output its io to file ect." | 17:33 |
| juliusb | I reckon you could achieve the same with userspace code to an FPGA over a USB-interface | 17:34 |
| glowplug` | That is why linux is so great. It solves everything by giving you a small subset of primitives and universal control. | 17:34 |
| glowplug` | You could write an application to do it. I think some exist actually. But linux tools to interact with files are extremely mature, stable and powerfull. | 17:36 |
| glowplug` | Not to mention almost universally understood. | 17:36 |
| juliusb | I'm saying you could write a user-space application (and driver, admittedly) to instantiate the FPGAs and create character devices for them | 17:37 |
| juliusb | probably the value in this project is the standardisation of an API, perhaps | 17:38 |
| juliusb | although I'm not sure they've even done that... must read more | 17:38 |
| glowplug` | That's what I was reffering to. A userspace application + kernel module could achieve the same level of functionality no doubt. But Linux applications can already do anything imaginable to and from a file. | 17:40 |
| glowplug` | I need to read more too. I don't know the answer to the API thing. | 17:40 |
| juliusb | well this whole thing relies on the fact you have the hardware. It sounds additional effort (on top of all of the ballache involved in doing FPGA development) to a) run the kernel they're going on about and b) hook up the I/O between whatever is runningg their fancy kernel and the FPGA | 17:41 |
| juliusb | I still don't see why you don't just write a driver and do this over USB | 17:42 |
| juliusb | and run it on any old kernel | 17:42 |
| glowplug` | Bandwidth/Latecy? | 17:43 |
| glowplug` | *Latency | 17:43 |
| juliusb | well how are they communicating with this FPGA on the board? | 17:44 |
| juliusb | unless it's PCIE I can't see how USB could be any worse than anything else (SPI/I2C etc.) | 17:44 |
| glowplug` | My guess is LVDS? I don't know how else they get that bandwidth. | 17:44 |
| glowplug` | Could be PCI-E also. | 17:45 |
| juliusb | LVDS is just a physical interface | 17:45 |
| juliusb | PCIE uses LVDS (I think) | 17:45 |
| juliusb | you need a protocol to go over the physical interface | 17:46 |
| glowplug` | Actually your right I remember reading that a few days ago on the wikipedia. | 17:46 |
| glowplug` | It probably is PCI-E then. | 17:46 |
| juliusb | But... it looks like they have 1 FPGA programming another, and the fancy Linux is running on .... that FPGA? | 17:46 |
| glowplug` | It is a PPC SoC running the BORPH kernel that reprograms the Virtex-6 | 17:47 |
| juliusb | yeah that is silly | 17:48 |
| glowplug` | It does apparently have an API. | 17:55 |
| glowplug` | It creates a kernel thread that handles HWR routines (the api). When you execute a BOF file it starts a unix process which the kernel thread grabs and configures it then flashes it to the FPGA. | 17:56 |
| glowplug` | Communication is by packets handled by the MKD kernel thread which handles messages from software on the system to gateware on the FPGA. | 17:58 |
| glowplug` | The physical hardware connection is by PLB (peripheral logic bus). Never heard of it. | 17:59 |
| glowplug` | Also the PPC core IS inside of an FPGA. Reffered to as the "control fpga". The PLB is something else. The bus used to reprogram the "user fpga" is the SelectMAP bus which is a bidirectional 8-bit bus running at 50mhz. | 18:01 |
| glowplug` | The more and more I read I'm starting to agree with you. That this is a great idea but their implimentation might be a little hairbrained. | 18:04 |
| stekern | if you need 16 virtex-6, you probably actually need more, then I can see the point of a project that makes it supereasy to swap around images to them | 18:08 |
| stekern | PLB is to PPC what wishbone is to openrisc | 18:10 |
| stekern | basically | 18:10 |
| glowplug` | I see. | 18:13 |
| glowplug` | What I'm trying to figure out now is how the RHINO project uses it. Because they have a Spartan-6. And their SoC is an ARM Cortex-A8. | 18:14 |
| glowplug` | That is a much more realistic configuration. | 18:14 |
| stekern | what's the RHINO project? | 18:15 |
| glowplug` | It is an SDR project that implimented a working RADAR system. | 18:16 |
| glowplug` | Very interesting because the HDL was written in Python using Migen. And they use BORPH. Lots of bleeding edge (and possibly not useful) technology. | 18:17 |
| stekern | it's possible it's useful, but me and julius just see the abstraction layer as an obstacle and not an aid | 18:25 |
| glowplug` | For development (and not deployment) that may very well be the case. | 18:26 |
| glowplug` | Be right back. =) | 18:26 |
| --- Log closed Tue Mar 26 00:00:25 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!