| glowplug | http://bit.ly/Wdb5xP | 00:00 |
|---|---|---|
| andresjk | still you need to modify the orpsoc to talk with the pic32 | 00:01 |
| _franck_ | I would replace the pic32 with a Ethernet phy + connector | 00:02 |
| glowplug | Removing the pic32 adds $30 in cost for an external FPGA programmer. I think the pic is a great idea. | 00:02 |
| glowplug | I think the only modification would be to bring out SPI wires where they are needed then write drivers. | 00:03 |
| glowplug | *external JTAG programmer | 00:04 |
| _franck_ | well not having a JTAG connector is not conveniant (I'm an Altera user and I use signal tap, don't know about xilinx) | 00:05 |
| andresjk | something, Xilinx uses JTAG for chipscope | 00:06 |
| _franck_ | you can use a ft2232 + openOCD to program your fpga if you don't want to use a jtag connector | 00:07 |
| glowplug | The software written for the PIC32 exposes itself as a standard JTAG programmer (usb-blaster). The Xilinx/Altera software pick it up automagically. =) | 00:07 |
| _franck_ | chipscope is not free afaik ;) | 00:07 |
| _franck_ | glowplug: ah ok, this is here: http://dangerousprototypes.com/forum/viewtopic.php?f=56&t=3029 | 00:08 |
| _franck_ | I've always wanted to test this | 00:08 |
| glowplug | Exactly. That software which is available from the japanese website will load onto the pic32. | 00:09 |
| glowplug | Instant built-in JTAG programmer. | 00:09 |
| _franck_ | it's bed time, bye | 00:20 |
| glowplug | Goodnight. =) | 00:22 |
| glowplug | I think that $3 per board from a chinese fab is possible. 5 square inches, 6 layers. | 00:24 |
| andresjk | wow thats cheaper than 1 layer homemade lol | 00:28 |
| glowplug | The only general pricing I could find suggests .3 per square inch in 6-layer. But that is at high volume. | 00:29 |
| glowplug | It looks like the next step would be to find a chinese fab, upload the kicad files and see what price I get and go from there. | 00:29 |
| glowplug | It looks like from non-chinese sources the boards will be ~$12 each. | 00:41 |
| andresjk | are you going to build a prototype first? | 00:42 |
| glowplug | Theoretically 6 layer boards are just three two layer boards. | 00:44 |
| glowplug | I can produce two layer boards. | 00:45 |
| glowplug | Never tried anything like that before though. | 00:45 |
| glowplug | It looks like ~$1800 is the smallest order possible for 6-layer from china. That is at $.68 per square inch or $3.20 per board. | 00:45 |
| glowplug | Yeah thats about 570 boards. I'm not sure we have that much interest at the moment. | 00:46 |
| andresjk | thats why I would first build a prototype that can work out-of-the-box | 00:50 |
| glowplug | A prototype 6-layer board with a BGA225 chip. Sure! | 00:51 |
| glowplug | I have a fairly accurate CNC that could drill the vias. The documentation of this process online is very slim. | 00:52 |
| glowplug | Yeah it doesn't seem like it's realistic to make a 6-layer board myself. I'll see if I can get 2-3 boards made. They will be very expensive but at least I can prove functionality then see if anyone else is interested after that. | 01:06 |
| GentlemanEnginee | Hello. | 03:01 |
| glowplug | Hey. =) | 03:02 |
| GentlemanEnginee | Are you on here always? | 03:02 |
| glowplug | I am I am. | 03:03 |
| GentlemanEnginee | So how fares the battle of creating the low-cost board? | 03:04 |
| glowplug | The current plan is to either attempt making a prototype myself or to order a few boards. Prove functionality and see if anyone is interested after that point. | 03:05 |
| glowplug | I'm researching the process of making 6-layer boards. Not fun. =( | 03:06 |
| GentlemanEnginee | Are you certain six layers would be required? Often it can be accomplished in four... | 03:06 |
| glowplug | I may not be. But the 6-layer design was tested by Numato. | 03:07 |
| glowplug | So if it doesn't work then I know it's my board and not the design. | 03:07 |
| GentlemanEnginee | So, you are intending on having their board created? | 03:07 |
| GentlemanEnginee | Is it possible to order the board directly from them? | 03:07 |
| glowplug | They actually gave away 50 of the boards for free. I missed out. | 03:08 |
| glowplug | I could throw them an email asking for a qoute on the board. | 03:08 |
| GentlemanEnginee | You may find that it would be the most inexpensive route. Especially since one must mount the BGA packages... | 03:09 |
| glowplug | It's hard to say. Chinese fabs will do 570 of those boards for $1800. | 03:10 |
| glowplug | There is no way that Numato would do that. | 03:10 |
| glowplug | It really depends on volume. | 03:10 |
| GentlemanEnginee | Correct. However, at low volumes (for evaluation purposes), it would be rater difficult in obtaining the interest of the larger Chinese fabs. | 03:12 |
| glowplug | Agreed. If I try to have 3-5 boards made they will be probably $40 each (for just the pcb). Which is why I might take a crack at doing them myself. | 03:13 |
| GentlemanEnginee | The boards would likely be in excess of that from them. | 03:14 |
| GentlemanEnginee | Also, as I indicated earlier, *you* would have to mount the BGA packages then. | 03:15 |
| glowplug | I have to moutn the BGA packages either way. If I paid for assembly too that would be $150 per board at least maybe more. | 03:15 |
| glowplug | I am going to send Numato an email right now though and see if they would do a short run of those boards. That was a good idea. =) | 03:16 |
| GentlemanEnginee | I was due for one this year... | 03:17 |
| GentlemanEnginee | brb | 03:19 |
| GentlemanEnginee | I have returned... | 03:24 |
| glowplug | Just sent an email to Numato. Asked for a quote on 10 boards. We'll see how that goes... | 03:24 |
| GentlemanEnginee | Yes, it is not offered in their store's website, as far as I was able to locate. | 03:25 |
| glowplug | Nope. They just gave them away. Was a missed opportunity. =( | 03:27 |
| glowplug | They probably have plans to sell complete boards in the future. But who knows when that will be (or what the price will be). | 03:28 |
| GentlemanEnginee | Your first unborn child, no doubt... | 03:29 |
| glowplug | Based on the price of their Spartan III board I'm assuming the Spartan-6 one they would probably offer for around $100. Totally worth it for a tested working board. But I'm more adventerous. | 03:29 |
| glowplug | Haha | 03:29 |
| glowplug | *adventurous | 03:32 |
| GentlemanEnginee | Naturally... | 03:35 |
| GentlemanEnginee | With two BGA packages (if my memory serves me), I imagine the overall yield would be low with DIY techniques... | 03:36 |
| glowplug | I've heard that 80% to 90% is realistic for DIY. So an otherwise $35 board would cost ~$38. | 03:38 |
| glowplug | There is only one BGA per board, the Spartan-6 itself. Everything else is a normal SMD. | 03:39 |
| GentlemanEnginee | I thought that you had stated that there was another BGA for some storage. | 03:42 |
| GentlemanEnginee | Must go again. | 03:46 |
| glowplug | Nope. There is a PIC32 and a 512MB DDR module. Both are standard SMD. | 03:48 |
| GentlemanEnginee | I am back. | 03:57 |
| GentlemanEnginee | It appears that my memory is failing me. I shall have to run Mem86+ tonight... | 03:58 |
| glowplug | xD | 03:59 |
| GentlemanEnginee | What RAM does that board have? | 04:07 |
| glowplug | MT46V128M4 | 04:09 |
| glowplug | It's a Micron 512mb DDR chip. =) | 04:09 |
| GentlemanEnginee | Not DDR2? | 04:09 |
| glowplug | As far as I know only the Xilinx IP memory controller can do DDR2 (Altera has one too). | 04:11 |
| glowplug | The non-proprietary memory controller thats available is DDR only. | 04:11 |
| GentlemanEnginee | This memory controller is an OpenCores offering? | 04:12 |
| glowplug | Also as far as being an FPGA board we are limited to ~50mhz operation. I can't imagine that system will be memory bound. | 04:12 |
| GentlemanEnginee | I suppose that is correct. Forget I mentioned it. | 04:13 |
| glowplug | It's actually from the Milkymist project. The memory controller is in their git repo. =) | 04:13 |
| GentlemanEnginee | Yes, I was ascertaining that was the one that you were referring to, and not another. | 04:13 |
| glowplug | The great thing about SDRAM vs DDR is the fact that 512mb chips are available for ~$5. 512mb SDRAM chips don't even exist as far as I know. | 04:13 |
| glowplug | Wups. I mean DDR vs SDRAM. | 04:14 |
| glowplug | There are actually 1gb DDR chips also but they are ~$50. | 04:14 |
| glowplug | Then of course theres the possibility of using many chips, or even a DIMM. But that would require redesigning the board. | 04:15 |
| GentlemanEnginee | 512 would most likely be sufficient for SoC verification. | 04:16 |
| glowplug | With the current CPU performance 512 is more than enough. Maybe sometime in the far future when we have mor1kx based ASIC we can put 4GB of DDR3 on there and get rid of our desktops. =) | 04:18 |
| glowplug | From the Spartan-6 FPGA the performance is roughly the same as a home router. 8) | 04:21 |
| GentlemanEnginee | How useful... | 04:23 |
| glowplug | Useful for one thing and one thing only. Getting the CPU design good enough for a 1 million dollor run of ASICs. | 04:24 |
| GentlemanEnginee | I know. | 04:25 |
| glowplug | 8) | 04:25 |
| GentlemanEnginee | Remember, the nibble-based serial processor I discussed? | 04:25 |
| glowplug | No I missed that. =( | 04:26 |
| GentlemanEnginee | Oh. When I was in University, I co-designed a nibble-based serial processor. | 04:30 |
| GentlemanEnginee | Was limited by FPGA Routing Resources. | 04:30 |
| GentlemanEnginee | Used 98% of the available routing. | 04:30 |
| GentlemanEnginee | We even designed an assembler for it. | 04:31 |
| glowplug | Interesting. Are there any architectural advantages compared to a harvard risc chip? | 04:31 |
| GentlemanEnginee | Programs were loaded and run over a serial connection. | 04:31 |
| GentlemanEnginee | None whatsoever. | 04:31 |
| glowplug | That is an amazing feat. I am just learning beginner Verilog. I am very much more hardware-oriented than software. | 04:31 |
| GentlemanEnginee | I designed the ALU. | 04:32 |
| GentlemanEnginee | I can inform you that with a serial based processor a barrel shifter is far easier in one direction than the other. | 04:32 |
| glowplug | You should take a stab at the ALU's in mor1kx! There are four different ones and they are experimenting right now. Maybe you could design a better one. =) | 04:32 |
| glowplug | I wish I could contribute. I'm trying to complete a ~30 hour lecture series from an university in india on digital circuit design. | 04:35 |
| GentlemanEnginee | I do know that my skills are rather rusty. | 04:35 |
| glowplug | At least your school had the forsight to use Verilog. =) | 04:36 |
| GentlemanEnginee | I taught myself Verilog. | 04:36 |
| GentlemanEnginee | Actually, the XC42 (our nomenclature) was done with VHDL. | 04:37 |
| GentlemanEnginee | I taught myself that as well. Have not used i since. | 04:37 |
| GentlemanEnginee | *it. | 04:37 |
| glowplug | Oh ouch. Actually that makes sense because Verilog is much newer if I remember correctly. | 04:39 |
| GentlemanEnginee | Verilog was somewhat proprietary at one point. | 04:39 |
| GentlemanEnginee | If you are interested, one may locate somewhat useful information at: http://www.asic-world.com. | 04:40 |
| glowplug | Some more tutorials! Very cool thank you. =) | 04:42 |
| glowplug | I am collecting some tutorial links. After my indian digital circuit course I'm going to start some tutorials. 8) | 04:42 |
| GentlemanEnginee | Indian digital circuit? | 04:44 |
| glowplug | Haha. Yeah there are digital circuit lectures from an university in India on Youtube. | 04:45 |
| glowplug | Works for me. =) | 04:45 |
| GentlemanEnginee | Ah! | 04:45 |
| GentlemanEnginee | I should refresh myself as well, at some point. | 04:46 |
| stekern | glowplug: mor1kx only has one ALU, all pipeline implementations are using the same ALU module | 08:44 |
| stekern | wtf... the dsx test is suddenly failing on openrisc/mor1kx, and it fails fare back | 10:18 |
| stekern | this has to be some glitch in my test setup now | 10:18 |
| stekern | s/fare/far | 10:18 |
| stekern | hmm, it passes in my mmu branch | 10:33 |
| stekern | juliusb: I assume you ran that test when you added the overflow stuff? | 10:41 |
| stekern | you're overflow stuff is unrelated, I'm just trying to confirm that my setup is insane somehow | 10:42 |
| stekern | because I fail that test on a commit where I *fixed* a bug discoverd in that particula test, one would assume the test would at least have passed on that commit... | 10:43 |
| stekern | I've also ran the complete suite on every of my commits that are in openrisc/mor1kx, so it *has* | 10:43 |
| stekern | to be something fishy here | 10:43 |
| stekern | hmm, it's running the dmmu tests... | 11:05 |
| stekern | that explains why my mmu branch pass the test | 11:05 |
| stekern | but why is SPR_UPR_DMP suddenly read as set? | 11:06 |
| stekern | because I have FEATURE_DMMU set in my top module... | 11:10 |
| stekern | ...man, do I feel silly now... | 11:12 |
| LoneTech | hello | 11:15 |
| stekern | morning LoneTech | 11:16 |
| mor1kx | [mor1kx] skristiansson pushed 2 new commits to master: https://github.com/openrisc/mor1kx/compare/edefb6ee9cd3...f5abffbf0c22 | 11:44 |
| mor1kx | mor1kx/master 0bfe390 Stefan Kristiansson: cappuccino/lsu: fix typo in dbus_sel_o dcache bypass | 11:44 |
| mor1kx | mor1kx/master f5abffb Stefan Kristiansson: cappuccino: move icache into fetch | 11:44 |
| stekern | and the shuffling has begun | 11:45 |
| juliusb | stekern: sorry... that DSX test, was it working? | 13:11 |
| juliusb | in the end I mean | 13:11 |
| stekern | juliusb: yeah, ignore the noise ;) | 13:20 |
| stekern | I had FEATURE_DMMU and FEATURE_IMMU enabled in orpsoc_top, but no dmmu or immu implemented... | 13:21 |
| stekern | and the dsx test run some tests against the dmmu if the dmmu bit is set in UPR reg | 13:22 |
| stekern | and that bit is set if FEATURE_DMMU!="NONE" | 13:22 |
| juliusb | ah right :) | 13:29 |
| juliusb | I'd really like to have something in each of the software tests (based on feature-present bits in either UPR or ISR) to know if it should run or not | 13:29 |
| stekern | don't we on the most obvious cases at least? | 13:32 |
| juliusb | umm, not really | 13:36 |
| stekern | ok :( | 13:40 |
| juliusb | we should do more | 13:47 |
| juliusb | that's the dream :) | 13:48 |
| stekern | do you mean tests or feature-present checking (or both)? | 13:51 |
| stekern | I probably should make a test for the last bug I fixed, but it's so convoluted... | 13:52 |
| stekern | basically it's an instruction after a delay slot that is exactly on a page boundary, but still in the cacheline | 13:52 |
| stekern | juliusb: I just pulled mor1kx-devenv and it complains about a missing or1k-support-defs.h, where is that suppose to be? | 13:53 |
| stekern | the dependency on that was added here: https://github.com/juliusbaxter/mor1kx-dev-env/commit/bba5440914b7f654112f6cd3100dd9c985585631 | 13:56 |
| juliusb | hmmm | 13:59 |
| juliusb | ok maybe I forgot something | 13:59 |
| juliusb | oh | 13:59 |
| juliusb | thats's in newlib? | 13:59 |
| juliusb | yeah it's in newlib | 14:00 |
| juliusb | the new one | 14:00 |
| juliusb | find /opt/openrisc/ -name "or1k-support-defs.h" | 14:02 |
| juliusb | /opt/openrisc/or1k-elf/include/or1k-support-defs.h | 14:02 |
| stekern | hmm, why is my or1k-elf-gcc from 20120303 | 14:02 |
| juliusb | regarding more tests: well more tests are good, but I mean more checking features of the processor are present before running a test | 14:03 |
| juliusb | mine or1k-elf-gcc is from 20120611 | 14:04 |
| juliusb | or1k-elf-gcc (GCC) 4.8.0 20120611 (experimental) | 14:04 |
| stekern | I'm updating my elf toolchain now | 14:07 |
| stekern | at least those lazy openrisc guys have nice build instructions on their wiki :) | 14:09 |
| juliusb | :) | 14:14 |
| LoneTech | I seem to have a mismarked cyclone V | 14:20 |
| stekern | mismarked in what way? | 14:21 |
| LoneTech | larger capacity than the markings on the casing say | 14:21 |
| LoneTech | looks like a 5CEFA2U19C8, talks like a 5CEFA4U19 | 14:24 |
| stekern | that sounds like a win situation | 14:28 |
| LoneTech | I don't mind it, just an oddity | 14:28 |
| LoneTech | assuming it actually works properly | 14:28 |
| stekern | maybe it's like the CPUs that are labeled as a 2-core, but really is a 4-core with 2-cores disabled ;) | 14:31 |
| _franck_ | stekern: you can also build gdb now (I haven't updated your instructions on the wiki) | 14:46 |
| stekern | _franck_: ah, right, I'll give it a go | 14:47 |
| stekern | _franck_: I get this when I try to build with gdb enabled: http://pastie.org/6513108 | 15:20 |
| stekern | I think this patch should fix it: http://pastie.org/6513179 | 15:25 |
| stekern | yup, that did it | 15:38 |
| _franck_ | ok, great | 15:54 |
| _franck_ | are you building it with --enable-sim ? | 15:55 |
| stekern | I only had --enable-gdb | 15:55 |
| _franck_ | ok | 15:56 |
| _franck_ | (my question wasn't related to the error you found) | 15:57 |
| stekern | yeah, I realised that | 16:03 |
| stekern | anyways, I pushed that fix | 16:03 |
| mor1kx | [mor1kx] skristiansson pushed 3 new commits to master: https://github.com/openrisc/mor1kx/compare/f5abffbf0c22...ea9ec64ae27e | 16:11 |
| mor1kx | mor1kx/master 99d037c Stefan Kristiansson: cappuccino: remove unused op_mfspr wire | 16:11 |
| mor1kx | mor1kx/master 5068af1 Stefan Kristiansson: cappuccino/ctrl: default spr acks to 1 instead of 0... | 16:11 |
| mor1kx | mor1kx/master ea9ec64 Stefan Kristiansson: cappuccino/ctrl: avoid taking exceptions when bubble is in ctrl stage... | 16:11 |
| stekern | everyday I'm shufflin' | 16:11 |
| juliusb | tops | 16:15 |
| stekern | still lots to go | 16:16 |
| stekern | but I'm working hard to get them in there in bisectable commits | 16:17 |
| stekern | it was worth it last with the pipeline rework, I found a couple of issues in the process then | 16:19 |
| juliusb | I don't understand that last sentence | 16:26 |
| juliusb | (I'm still rubbish at committing my work in nice bits) | 16:27 |
| juliusb | (my problem is I'll do 2 fixes in a single file at once, and can't be bothered to take 1 fix out, check the other one in, and then do the next one) | 16:27 |
| juliusb | (so it gets lumped together a bit too often) | 16:28 |
| stekern | well, the sentence meant just that, make each commit do just one thing =) | 16:52 |
| stekern | and each commit should ideally pass all tests | 16:52 |
| juliusb | ah don't worry if it doens't | 17:18 |
| ams | juliusb: split it later... | 17:22 |
| juliusb | ams: how? | 17:23 |
| ams | juliusb: rebase the hunks | 17:24 |
| ams | http://plasmasturm.org/log/530/ | 17:26 |
| ams | juliusb: i'm as bad as well at not splitting things ... so :-) | 17:26 |
| stekern | juliusb: don't worry, it's as much for my own sake I want them bisectable | 17:28 |
| stekern | makes finding the guilty commit so much easier later when things starts to turn out broken ;) | 17:30 |
| juliusb | ah, but the trick is to get it right the first time ;) | 17:36 |
| stekern | yeah, but that's why I have my messy commits in the skristiansson/mor1kx tree | 17:38 |
| stekern | that (roughly) shows how I didn't get it right the first time | 17:39 |
| stekern | that doesn't mean that I have to show others my silly mistakes =) | 17:39 |
| stekern | at least not all of them... | 17:40 |
| stekern | juliusb: did or1k-cy pass on cappuccino sometime? | 17:54 |
| juliusb | stekern: not sure | 18:01 |
| juliusb | check ADDC is enabled | 18:03 |
| stekern | yeah, it's enabled by default in mor1kx.v | 18:22 |
| stekern | it fails here too, so I guess I haven't broke it: https://github.com/openrisc/mor1kx/commit/9dc8c8d5c278b81606810df57331e19b780c50a5 | 18:29 |
| stekern | juliusb: I have decreased the tick timer rate on a few of the tests, for example or1k-shortjump get stuck in a loop where the exception happens in the delay slot and the jump fails to complete before the exception is hit again | 18:52 |
| stekern | are you willing to pull that in? | 18:54 |
| stekern | ideally we should have per board intervals | 18:54 |
| glowplug | Good morning all. 8) | 19:37 |
| stekern | good evening glowplug | 19:38 |
| glowplug | I realized sometime after I typed that. I'm slowly trying to understand CPU design and digital circuits. | 19:40 |
| glowplug | I'm curious about the CPU cache. Is it possible to use small fast external memory chips as cache without a massive latency penalty? Currently the CPU cache is part of the synthesis correct? | 19:49 |
| stekern | they are on-chip RAM, yes | 19:50 |
| glowplug | Could you cram a lets say 1MB ram module right next to the FPGA and wire it as CPU cache would it have too great of latency? | 19:52 |
| stekern | if you find a synchronous ram with single-cycle access at ~100MHz, yes | 19:55 |
| glowplug | Older computer systems had such a configuration for the L2 and later L3 caches. But those were x86 systems. | 19:56 |
| stekern | if we assume a cpu-freq at 100MHz | 19:56 |
| glowplug | Can the mor1kx run at 100mhz on a Spartan-6? | 19:56 |
| stekern | not yet, but it should be able to | 19:57 |
| stekern | ~80 MHz atm | 19:57 |
| glowplug | 100mhz is pretty standard for SDRAM chips. | 19:57 |
| stekern | yeah, but they are not single cycle | 19:57 |
| glowplug | Interesting. Let me see if I can find something suitable. | 19:58 |
| glowplug | I'm assuming that would save thousands of LE's. | 19:58 |
| stekern | no, only blockram (at least in the common altera and xilinx devices) | 19:58 |
| glowplug | Ahh I see. That makes sense. So at most we would gain cache capacity at possible a cost of latency. | 20:00 |
| stekern | you'll probably have at least some blockrams to spare for a small l1 cache, what you could do with a small fast external memory is to create a l2 cache | 20:01 |
| stekern | but chances are that you're main memory is fast enough compared to the cpu-freq, that there's little point | 20:02 |
| stekern | s/you're/your | 20:02 |
| glowplug | There currently is no L2 cache in mor1kx at all? | 20:03 |
| stekern | no, there's no point, at least not in an FPGA | 20:03 |
| stekern | that L2 cache would be as fast as the L1 cache | 20:03 |
| stekern | since both would be 1-cycle blockram | 20:03 |
| glowplug | The only point would be capacity assuming you can maintain the same latency. | 20:04 |
| glowplug | Here is a 2MB chip for $7 with 5ns latency single cycle at 100mhz. Thats four times the blockram in the FPGA correct? | 20:05 |
| glowplug | Would the capacity have any noticable impact on performance for certain operations? | 20:05 |
| stekern | depends on your application | 20:09 |
| glowplug | Nevermind I'm going to assume not in most cases. The Freescale i.mx233 has only 32kb of cache and is a 454mhz ARM9. On to the next idea. | 20:11 |
| stekern | where's 'here' btw? =P | 20:12 |
| glowplug | http://www.digikey.com/product-detail/en/IDT71V632S5PFG/800-1484-ND/1915785 | 20:14 |
| stekern | but an L2 cache wouldn't need to be implemented in the cpu-core anyway, you can put it next to the main mem (i.e. let all accesses to the main mem go 'through' your cache) | 20:15 |
| andresjk | stekern, which are the linux drivers files that implement support for the DMA peripheral that you used in your atlys prj | 20:16 |
| glowplug | Exactly that's what I was thinking. But it seems at the performance level of FPGA's we are "cpu bound" heavily and the blockram on the FPGA is more than enough. The Ivy Bridge i5 3570k has 1MB of L2 but it is almost exactly 1,000 times faster than mor1kx on an FPGA. | 20:18 |
| stekern | andresjk: do you mean this? http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/xilinx/atlys/rtl/verilog/dma | 20:18 |
| stekern | if so, none, I never got around to actually use that | 20:18 |
| andresjk | oh ok | 20:19 |
| andresjk | so the software for linux its not ready yet | 20:19 |
| glowplug | It also seems that mor1kx is less cache dependant than CISC processors? | 20:19 |
| stekern | andresjk: DMA are handled by the individual cores | 20:20 |
| stekern | the only core that is around that uses that DMA controller is the ac97 core, my plan was to add DMA support for the ac97 linux driver using that core | 20:21 |
| stekern | ...but as I said, haven't got around to it | 20:21 |
| andresjk | so the device driver handles the DMA? | 20:21 |
| stekern | yes | 20:21 |
| andresjk | ok but you did a vga linux driver, right? | 20:22 |
| stekern | basically they allocate a memory area that has the cache_inhibit bit set | 20:22 |
| stekern | yes, I rewrote the ocfb driver | 20:23 |
| andresjk | yes, Im basically interested in that since Im making a master peripheral | 20:23 |
| stekern | then that memory area is handed to the core in question | 20:23 |
| andresjk | you used interrupts? | 20:24 |
| andresjk | I guess the file name is ocfb.c ... | 20:24 |
| stekern | http://git.openrisc.net/cgit.cgi/jonas/linux/tree/drivers/video/ocfb.c#n271 | 20:26 |
| stekern | it's done in that function | 20:26 |
| andresjk | thanks | 20:27 |
| andresjk | Im going to study it :) | 20:28 |
| andresjk | I guess you allocate the uncache memory in fbdev->fb_virt = dma_alloc_coherent(&pdev->dev, PAGE_ALIGN(fbsize), | 20:31 |
| andresjk | &fbdev->fb_phys, GFP_KERNEL); | 20:31 |
| andresjk | brb | 20:32 |
| stekern | sorry, got to go put the kids to bed, but it looks like you're on the right track, yes | 20:34 |
| glowplug | I'm curious whether the FPGA is so slow that the blockram is not that much faster than the system memory. | 20:35 |
| glowplug | I really need to get hardware so I can test things like this. =( | 20:36 |
| glowplug | Be right back. Mcdonalds run. | 20:38 |
| glowplug | Just realized that you already said that the system memory speed is comparable to the blockram. Dur! | 21:06 |
| glowplug | There is not that much information available for the LSU. Is the LSU optional for the cappuccino or integral? | 21:16 |
| glowplug | Nevermind. It appears optional by using the other pipeline implimentations. | 21:21 |
| glowplug | It seems like the cappuccino is most like other modern RISC architectures such as Cortex-A15. I have a feeling that will be the prevailing implimentation. | 21:27 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!