| glowplug | Is anyone familiar with this project? kck.st/UNVcNF | 01:39 |
|---|---|---|
| GentlemanEnginee | Hello. | 04:15 |
| glowplug | Welcome back. =) | 04:16 |
| GentlemanEnginee | It appears we have a similar schedule... | 04:16 |
| glowplug | I've actually been in here all day. Haha | 04:16 |
| GentlemanEnginee | I think the office might have some issues if I attempted something similar. | 04:16 |
| glowplug | Sounds like you need to straiten them out. OpenRISC is obviously more important. | 04:18 |
| GentlemanEnginee | I would not disagree... | 04:19 |
| GentlemanEnginee | However, it is unlikely they would be willing to change their viewpoint. | 04:19 |
| glowplug | That's what I mean. You need to "change" their viewpoint. 8) | 04:21 |
| -!- Gentlema` is now known as GentlemanEnginee | 04:22 | |
| GentlemanEnginee | I fear greatly that changing their viewpoint on me working on OpenCores all day runs the risk of changing their viewpoint in providing me with paycheques... | 04:23 |
| glowplug | OR providing you with a BIGGER paycheck. Can't know unless you try. =) | 04:24 |
| GentlemanEnginee | Actually, I am hoping to transfer to the FPGA Department in the future... | 04:24 |
| glowplug | Your company has an FPGA department. So lucky. | 04:25 |
| GentlemanEnginee | Only if I can transfer to it. | 04:25 |
| glowplug | Have you seen this company / board before? | 04:26 |
| glowplug | http://wvshare.com/product/OpenEP4CE10-C-Standard.htm | 04:26 |
| GentlemanEnginee | No. | 04:27 |
| GentlemanEnginee | I have only used some Xilinx products. | 04:28 |
| glowplug | I've been trying to figure out if ORPSoc will run on it. That would be pretty great if it did because it's only $49. | 04:28 |
| GentlemanEnginee | I am not certain of ORPSoc's requirements. | 04:28 |
| glowplug | The other FPGA boards supported by ORPSoc are $90 and $160. O.o | 04:28 |
| GentlemanEnginee | It was my thought to familiarize myself on some of the internal structures &c prior to looking at FPGA Requirements. | 04:29 |
| glowplug | I know that it can synthesize on Cyclone IVs. And that the two boards *oficially* supported have 22k LEs. These have 10K LEs but that doesn't necessarily disqualify it. | 04:29 |
| glowplug | It might mean less peripherals or other changes to cram it in. | 04:30 |
| GentlemanEnginee | 10k for peripherals? | 04:31 |
| glowplug | The FPGA in that board I linked has 10K LEs *total*. | 04:32 |
| GentlemanEnginee | Yes, and you were stating that 22k LEs were required for a full build. | 04:32 |
| glowplug | I haven't been able to figure out the exact LE requirement for ORPSoc on a Cyclone IV. It is < 22k. That's all I know. Haha | 04:32 |
| GentlemanEnginee | Ah! | 04:32 |
| glowplug | $49 is still a lot for the board. But if it works then it would many many more people to contribute to the project. $90 and $160 is too expensive and I think many would agree. | 04:35 |
| GentlemanEnginee | I would wish to avoid that cost if I could. | 04:36 |
| glowplug | That is why Arduino is such a popular development environment. Anyone can spend $20 to tinker. Few can spend $90. But many can spend $49. | 04:36 |
| glowplug | You probably can if you depend completely on simulation. But I guess that depends on what you are working on. | 04:36 |
| glowplug | Another interesting thing about the board that I linked. They offer an SDRAM module that plugs into the top for $8 with 256MB. I imagine that chip can be swapped out for 1GB+. | 04:37 |
| GentlemanEnginee | For something simple in terms of Verilog testing, one could look at the CPLD Dev Board for $15: http://www.seeedstudio.com/depot/xc2c64a-coolrunnerii-cpld-development-board-p-800.html?cPath=174 | 04:39 |
| glowplug | Those are available on Ebay for even less. Unfortunately you cant synthesize an OpenRISC core on one. =( | 04:41 |
| GentlemanEnginee | No, I was referring to learning Verilog &c. | 04:43 |
| GentlemanEnginee | Also, it could be useful in connecting to an OpenRISC Core for testing purposes. | 04:43 |
| glowplug | I see. I'm not convinced it's that great of a tool because of the rate you would outgrow the hardware. | 04:44 |
| GentlemanEnginee | It could be used to validate a wishbone interface, in a unit testing manner. | 04:45 |
| GentlemanEnginee | Also, it allows for level shifting. | 04:45 |
| glowplug | A wishbone interface between the CLPD and an FPGA? | 04:45 |
| glowplug | *CPLD | 04:46 |
| glowplug | Wouldn't that only be useful if you ran out of LE's or pins on the FPGA? | 04:46 |
| GentlemanEnginee | External testing of a core. | 04:46 |
| GentlemanEnginee | Create CPLD with unit testing on it. | 04:47 |
| GentlemanEnginee | Change Core design to heart's content, and then connect to CPLD for testing. | 04:47 |
| GentlemanEnginee | Also, as I stated, it does allow for level shifting. | 04:47 |
| glowplug | Right. Then interface the CPLD to an FPGA and use it for debugging / testing. | 04:47 |
| GentlemanEnginee | Exactly. | 04:48 |
| glowplug | I totally agree. But I don't think we can get anything done without a full size FPGA. | 04:48 |
| GentlemanEnginee | Not for OpenRISC... | 04:49 |
| glowplug | Making the CPLD more of a toy. Couldn't you synthesize your tools in the primary FPGA and interact with that circuit directly and debug your OpenRISC core from inside the FPGA? | 04:49 |
| GentlemanEnginee | The CPLD could be used as a Golden Test Tool. | 04:50 |
| GentlemanEnginee | Consider it similar to a logic analyzer with specialized testing. | 04:50 |
| glowplug | I can see that usage for it. | 04:51 |
| GentlemanEnginee | It was a thought that had drifted into my mind... | 04:51 |
| glowplug | What I'm asking is if we can't synthesize the same tools into the primary FPGA assuming we have free LEs and pins. | 04:51 |
| glowplug | Removing the need for the CPLD. | 04:51 |
| glowplug | http://wvshare.com/product/SDRAM-Board-A.htm | 04:52 |
| glowplug | There is a link to the SDRAM module for the board I linked previously. Very cool. =) | 04:52 |
| GentlemanEnginee | That would be changing the core from its intended use for testing. This could allow for functionality to be tested incorrectly. | 04:53 |
| GentlemanEnginee | Interesting... | 04:53 |
| glowplug | Assuming the testing circuit was synthesized without errors you could interact with it over RS-232 for example and use it to test the OpenRISC core through wishbone in the same way you described. Without external hardware. | 04:54 |
| GentlemanEnginee | If one desired... | 04:55 |
| glowplug | All in the spirit of saving $15 of course. =) | 04:55 |
| GentlemanEnginee | In deference to full disclosure, I already own one. | 04:55 |
| glowplug | Ahah! Haha | 04:55 |
| glowplug | Now you just need an FPGA. 8) | 04:56 |
| GentlemanEnginee | Indeed. | 04:56 |
| GentlemanEnginee | It might be nice to connect it to some GNU Radio Hardware. | 05:02 |
| glowplug | There is a new USB 3.0 SDR that recently came out. Let me get a link. | 05:03 |
| glowplug | http://nuand.com/order.php | 05:05 |
| GentlemanEnginee | I forsee some charges to my credit card... | 05:05 |
| glowplug | Hahaha | 05:05 |
| glowplug | Have you implimented PWM in Verilog? | 05:06 |
| GentlemanEnginee | No. | 05:06 |
| glowplug | Damn. | 05:07 |
| GentlemanEnginee | I have done some counters and register swapping. | 05:07 |
| GentlemanEnginee | I have implemented PWM in C. | 05:07 |
| GentlemanEnginee | I would assume that Google would provide with several examples, though... | 05:08 |
| glowplug | For CNC you need many parallel PWM signals that can all change in real-time. In my case I need six. I wonder if there's enough zoom in that $15 CPLD to do it. | 05:08 |
| GentlemanEnginee | Quite possibly... | 05:09 |
| glowplug | Taking input from a uC with the duty cycles. | 05:09 |
| GentlemanEnginee | Would the uC be sending the PWM Duty Cycles in parallel or in serial? | 05:10 |
| glowplug | Technically serial since thats all a uC can do. But the latency for the duty cycles would be acceptable. What the uC *cant* do is the actual PWM generation with acceptable latency for 6 channels. | 05:11 |
| GentlemanEnginee | It could be parallel if one had enough pins... | 05:12 |
| glowplug | Don't all uC's execute in serial by design? | 05:12 |
| glowplug | Well at any rate the way I would really like to solve my problem is by implimenting everything into an FPGA using an openrisc core. | 05:14 |
| GentlemanEnginee | Write value to memory that is mapped to the pins. | 05:14 |
| glowplug | The CPLD's are very cool for being so cheap though. =) | 05:14 |
| GentlemanEnginee | This allows for value to appear "instantly". | 05:14 |
| glowplug | Ahh I see what you mean. That makes sense. | 05:15 |
| GentlemanEnginee | Assuming one has enough pins to devote to this. | 05:15 |
| glowplug | Which is probably why it makes more sense to cram everything into a single FPGA. | 05:15 |
| glowplug | That brings latency down, board complexity ect. | 05:16 |
| GentlemanEnginee | Yes. | 05:16 |
| GentlemanEnginee | However, the CPLD would be a good interim solution. | 05:16 |
| GentlemanEnginee | It might also be less expensive. | 05:17 |
| glowplug | It's true that a CPLD + a cheap uC would probably be $25 total VS $49. I think the FPGA method would save enough time to justify it. Plus the cool factor of running a free software core. =) | 05:18 |
| GentlemanEnginee | I concur. | 05:19 |
| glowplug | This board has 15k LE's and is $45. http://wvshare.com/product/OpenEP3C16-Standard.htm | 05:39 |
| glowplug | It's probably less power efficient since it's a Cyclone III. | 05:40 |
| GentlemanEnginee | I doubt for a CNC that the current draw of the processor would be the limiting factor... | 05:43 |
| glowplug | Oh no. I'm simply saying that the Cyclone III has an inferior manufacturing processes to the Cyclone IV. | 05:45 |
| glowplug | But the board is $5 cheaper with 5k more LE's | 05:46 |
| GentlemanEnginee | If you can find room on your CNC for the larger die... | 05:48 |
| GentlemanEnginee | What manner of resolution were you considering for the PWMs? | 05:53 |
| glowplug | We still have to find out if this board has enough LE's for ORPSoc. That is the golden question. =) | 05:53 |
| glowplug | http://wvshare.com/product/OpenEP3C16-Standard.htm | 05:53 |
| glowplug | Sine PWM would be nice. 16-bit PWM would be fine. | 05:59 |
| glowplug | http://bit.ly/WGJMxh | 06:02 |
| glowplug | Basically I need six closed loop (encoder feedback) analog (sine) servo drivers. Preferably integrated onto a single board (minus the powerstages obviously). | 06:05 |
| GentlemanEnginee | How would the feedback be provided? | 06:08 |
| glowplug | Output from the encoders would go into some comparator circuit in the FPGA. Unfortunately it has gotten late again I will be on tomorrow. If you can try to find out if that board I found will work with ORPSoc. =) | 06:22 |
| GentlemanEnginee | Perhaps I shall converse with you in the morrow... | 06:23 |
| andresjk | Is wget stable in the busybox 1.19.0? I keep getting not http | 07:13 |
| GentlemanEnginee | A good night to all... | 07:27 |
| stekern | glowplug: if you're looking for a relatively cheap board for openrisc development, this is my favorite: http://www.terasic.com.tw/cgi-bin/page/archive.pl?No=593 | 07:30 |
| stekern | generating pwm in a fpga is dead simple by the way | 07:33 |
| stekern | I think I have soon read all functions there is in the linux kernel... in disassembled form | 12:50 |
| stekern | think I got the slippery little bug I've been chasing the last few days on the hook now at least | 12:51 |
| stekern | looks like a set flag issue | 12:51 |
| stekern | http://pastie.org/6470056 | 12:52 |
| stekern | that branch is taken, but r11 is 0 | 12:53 |
| juliusb | set flag in delay slot?! | 13:28 |
| juliusb | and in delay slot of branch based on flag!!? | 13:28 |
| juliusb | so I'm trying to run the GCC testsuite against mor1kx at the moment | 13:33 |
| juliusb | the only problems I'm having is with the compiler and the testsuite software :) | 13:33 |
| juliusb | I added -O2 to the compile command line | 13:33 |
| juliusb | (I do a simple hack of getting all of the C files in the gcc C torture directory and just compile them plainly) | 13:34 |
| juliusb | and now some tests fail | 13:34 |
| juliusb | eg | 13:34 |
| juliusb | this one | 13:34 |
| juliusb | 920711-1.c | 13:34 |
| juliusb | f(long a){return (--a > 0);} | 13:34 |
| juliusb | main(){if(f(0x80000000L)==0)abort();exit(0);} | 13:34 |
| juliusb | (that's literrally what the file contains) | 13:34 |
| stekern | set flag in delay slot should be just fine | 13:36 |
| stekern | mor1kx handle that perfectly | 13:36 |
| juliusb | so... when compiled without -O2, main looks like this: http://pastie.org/6470335 | 13:36 |
| stekern | =) | 13:36 |
| juliusb | but compiled with -O2 it looks like this: http://pastie.org/6470337 | 13:37 |
| stekern | but the clear flag signal isn't coming out of the alu on the l.sfnei r11,0 | 13:37 |
| juliusb | stekern: still... I'm surprised thecompiler sets flags in delay slots and that it's legal | 13:37 |
| juliusb | i guess it's fine | 13:37 |
| juliusb | anyway | 13:37 |
| stekern | hmm, could you put the C code and the two cases in the pastie? | 13:38 |
| juliusb | with -O2 on that code fragment, it clearly screws something up when being too clever | 13:38 |
| juliusb | http://pastie.org/6470345 | 13:39 |
| stekern | why wouldn't setting flags in the delay slot be legal? | 13:39 |
| juliusb | (flags) I don't know, it doesn't seem right, but when you think about it - it's fine | 13:40 |
| juliusb | it depends on when you're evaluating the flags | 13:40 |
| juliusb | you'd hope it's on the branch instruction itself | 13:41 |
| juliusb | it's kinda like alterting the register of the branch target in a delay slot | 13:42 |
| juliusb | ie l.jr r3; l.movhi r3, 0 | 13:42 |
| juliusb | anyway | 13:42 |
| juliusb | this compiler thing is annoying | 13:42 |
| juliusb | all I want to do is compile and execute every C file in the GCC C torture tests things! | 13:43 |
| stekern | lemme see what clang does | 13:43 |
| juliusb | and want to use -O2 | 13:43 |
| juliusb | but maybe I Can't | 13:43 |
| juliusb | yes, actually | 13:43 |
| stekern | just for the fun of it | 13:43 |
| juliusb | please run that through llvm :) | 13:43 |
| juliusb | maybe it's a known flaw in GCC or something? | 13:45 |
| stekern | http://pastie.org/6470391 | 13:49 |
| stekern | that's what llvm does with -O2 | 13:50 |
| juliusb | it gets it right! | 13:51 |
| juliusb | clang: 1 | 13:52 |
| juliusb | gcc: 0 | 13:52 |
| juliusb | clang does appear to execute some superfluous stack manipulation though | 13:52 |
| juliusb | so, the idea of running the GCC C code isn't to test the compiler in this case, it's just to run a bunch of different code through the processor | 13:53 |
| juliusb | so that I have to sidestep around a few compiler issues is a bit annoying but not a major problem | 13:53 |
| stekern | well, we probably want to fix that bug too ;) | 13:57 |
| stekern | or32 toolchain gets it right too | 13:58 |
| stekern | l.jr r3; l.movhi r3, 0 <- isn't that alright too? | 14:00 |
| stekern | or was that just an example of something that feels wrong, but is right? | 14:06 |
| juliusb | no with -O2 it jumps to abort | 14:06 |
| juliusb | so the test fails! | 14:06 |
| juliusb | ie it calculates that 0x80000000-1 is not greater than zero | 14:07 |
| juliusb | sorry | 14:07 |
| juliusb | yes | 14:07 |
| juliusb | hmmm wait | 14:07 |
| juliusb | so it's essentially testing if ((0x80000000-1)>0)==FALSE) | 14:08 |
| juliusb | so with -O2 it's getting the result that (0x7fffffff>0) is FALSE | 14:09 |
| juliusb | because it's automatically jumping to abort | 14:09 |
| stekern | jupp | 14:10 |
| juliusb | and that is wrong, isn't it? | 14:10 |
| stekern | could there be some weird assumption somewhere that long is 64 bit | 14:10 |
| juliusb | that wouldn't matter would it? | 14:10 |
| juliusb | because 0x000000007fffffff > 0 is true | 14:11 |
| juliusb | but anyway, long in OR1K is 32-bit | 14:11 |
| juliusb | and the compiler should know that | 14:11 |
| stekern | ah, yeah you're right | 14:14 |
| juliusb | although | 14:14 |
| juliusb | I guess we're talking about signed here | 14:14 |
| stekern | got confused for a second there | 14:14 |
| juliusb | mmm | 14:14 |
| juliusb | 0x80000000 is the biggest negative signed number you can have | 14:15 |
| juliusb | so that -1 will cause 32-bit signed overflow | 14:15 |
| stekern | mmm, and it should wrap around on -1 | 14:15 |
| juliusb | which ... maybe that's what GCC is picking up and saying it should still be < 0 | 14:15 |
| stekern | so I guess my idea was that the compiler is getting confused and thinks about the number as a large negative number and then subtracts from it | 14:16 |
| stekern | you're on a 32-bit machine, right? | 14:18 |
| juliusb | stekern: yep | 15:13 |
| juliusb | found another one: http://pastie.org/6471029 | 15:15 |
| juliusb | I suspect these are bugs in our compiler | 15:16 |
| juliusb | I will put them up on the bugzilla at some point | 15:16 |
| juliusb | but keep in mind that these all passed without any optimisation flag | 15:17 |
| stekern | I'll take a look at it | 15:23 |
| stekern | shouldn't be to hard to find where it goes wrong, the testcases are nice and small | 15:24 |
| stekern | +o | 15:24 |
| stekern | I just need to kill this bug first | 15:24 |
| stekern | it's not a flag bug, but a fetch bug (surprise!) | 15:25 |
| stekern | at least I think it is a fetch bug | 15:25 |
| stekern | because there is a nop in the alu when there should be a l.sf instruction | 15:25 |
| juliusb | ah! | 15:27 |
| juliusb | an l.nop where an l.sf should be isn't usually a good thing. | 15:27 |
| juliusb | but yeah, if you want to look at it, sure - but I'm not sure it's a big deal ATM | 15:30 |
| stekern | given that I'm using that compiler to compile the kernel I'm debugging atm, I'd say any bug is a big deal ;) | 15:34 |
| juliusb | ya good point | 15:36 |
| juliusb | i'm surprised this stuff isn't picked up the debug suite | 15:36 |
| stekern | bah, this is a reincarnation of the last bug I fixed | 15:59 |
| stekern | the root problem is that branches isn't resolved in decode stage, so we get two "delay-slots" | 16:00 |
| stekern | i.e. it takes two cycles until the branch has propagated into execute and it is recognized | 16:01 |
| stekern | and it creates all kind of ugly corner cases where it starts to fetch stuff beyond the delay-slot | 16:01 |
| stekern | I've got a signal that is indicating that corner case, but it looks like I haven't connected it to all the right places | 16:03 |
| juliusb | jeremybennett: nice work on the ChipHack announcement - are you planning on advertising it on the OpenRISC list, too? | 16:41 |
| juliusb | stekern: hah, yep sounds like it's time to implement the branch detection/address generation in the fetch/decode stage :) | 16:42 |
| juliusb | btw for anyone who's around London and wants to learn about FPGA development: http://chiphack.org/ | 16:45 |
| juliusb | jeremybennett: nice idea to provide the boards for free to teachers who come along | 16:47 |
| LoneTech | I'm coming over for the Muse concert, but that's not until May | 16:48 |
| LoneTech | looks like a nice idea | 16:48 |
| jeremybennett | juliusb: Yes I should advertise it there as well. | 16:58 |
| jeremybennett | Except it is filling up fast. I only sent the email an hour ago and 25% of the places have already gone! | 16:59 |
| juliusb | that's good! | 17:01 |
| juliusb | how many places are there in total at the moment? | 17:01 |
| jeremybennett | juliusb: 22 places left as of 15:12 GMT | 17:12 |
| jeremybennett | Just posted to the OpenRISC mailing lists and the OpenRISC and OpenCores forums | 17:12 |
| juliusb | nice one, it's good publicity for the project nonetheless | 17:18 |
| glowplug | That is a good board but it is around $90 after shipping. I'm still curious about this board since it is around half the cost. | 17:29 |
| glowplug | http://wvshare.com/product/OpenEP3C16-Standard.htm | 17:29 |
| glowplug | I suppose my question really is... can ORPSoc fit within 15k LE's? | 17:32 |
| jeremybennett | glowplug: Don't know that board. We had some debate over which board to use, but went with the DE0-nano because it is well established and easy to buy. | 17:38 |
| glowplug | Do you think that there would be a massive issue with synthesizing ORPSoc on a 15k LE Cyclone III? | 17:43 |
| jeremybennett | glowplug: You'll need one of the HW guys to answer that - I'm a SW person | 18:04 |
| glowplug | I'll be hanging out in here so thats no problem. Thanks for your help. =) | 18:07 |
| juliusb | glowplug: I can't say at the moment but I will be playing around with synthesisfor an altera device quite soon | 18:15 |
| glowplug | Fantastic! From the NIOS II documentation it looks like the LE's in Cyclone III devices are exactly the same as Cyclone IV. So the LE usage on the Nano should be the same on the OpenEP3C16. Assuming that is under 15k then we have a mass produced $45 development platform with a 256MB sdram module. =) | 18:23 |
| glowplug | I'm assuming that if the sdram chip was swapped for ~1GB that would work just fine with ORPSoc? | 18:24 |
| glowplug | Good afternoon andresjk. =) | 18:40 |
| andresjk | hi | 18:41 |
| glowplug | I am on a quest to determine if ORPSoc will run on some boards that I found recently. They are Cyclone III with 15k LE, and Cyclone IV with 10k LE. | 18:44 |
| andresjk | have you check this one: http://opencores.org/shop,item,11 | 18:45 |
| andresjk | its a cyclon IV | 18:46 |
| glowplug | I have. =) | 18:46 |
| glowplug | The boards I found are $32 and $45. A little more in my budget range (unfortunately). | 18:46 |
| glowplug | I have yet to determine the actual minimum LE requirement for ORPSoc in terms of Altera boards however. Only that the commonly used boards have 22k. | 18:48 |
| andresjk | Have you synthesized ORPSoC in quartus for any of those boards? | 18:49 |
| andresjk | Im using a Virtex5 right now and Its taking 49% lol | 18:49 |
| glowplug | No I have not. That is why I am researching an affordable board. =) | 18:49 |
| glowplug | What is your boards total LE count? (thank you for all of your help by the way!). | 18:50 |
| andresjk | but quartus its free, give it a try | 18:50 |
| glowplug | Oh you mean in simulation? | 18:51 |
| andresjk | its kinda hard to compare Xilinx and Altera's architecture on resources | 18:51 |
| andresjk | yeah | 18:51 |
| glowplug | I agree. I just need anyone who has synthesized ORPSoc on the Nano or ORSoc board to say what the LE requirement was. =) | 18:52 |
| andresjk | I mean, try to synthesize the ORPSoC with one configuration (a specific fpga) and then see the summary | 18:52 |
| glowplug | I figured it would come to that. 8) | 18:52 |
| andresjk | I actually have a project in quartus of the orpsoc | 18:52 |
| andresjk | I could do it but I have to restart since its in my win partition | 18:53 |
| glowplug | I will be back in ~10 minutes grabbing lunch. If its inconvenient at all thats no big deal! I'm just being lazy. Haha | 18:53 |
| andresjk | ok then | 18:54 |
| andresjk | glowplug, are you there? | 19:25 |
| glowplug | I am. =) | 19:28 |
| andresjk | ok, I synthesized the project for an 15K LE fpga and it failed. Then I try a 24K LE and the report said it used 13 365 LE which remind me to a design rule that says always use a fpga with 20-30% more resource because otherwise the PAR will try to do magic and will eventually fail | 19:42 |
| andresjk | btw the project was not actually the orpsoc, It didnt have the ethernet controller | 19:42 |
| andresjk | it was http://opencores.org/websvn,listing?repname=openriscdevboard&path=%2F&rev=2 | 19:43 |
| andresjk | sorry but that was the one I have handy | 19:43 |
| andresjk | lol | 19:43 |
| andresjk | I dont know, maybe you could actually fit the orpsoc into a small fpga, but I wouldnt risk my money buying a devices which has the exactly same amount of resources that the software says it need. Just my opinion lol | 19:47 |
| glowplug | Interesting. So functionally you can only ever assume that ~70% of your LE's are really usable. Thats unfortunate. =( | 19:50 |
| glowplug | Thank you very much for the information! | 19:50 |
| glowplug | I would have gotten the failure and assumed it was a mistake that I made. Haha | 19:50 |
| andresjk | yes, only 70% to be safe xD. A friend lost about 8K USD because the fpga he bought had almost the same map resources but when he tried to do the PAR it never fit. true story | 20:01 |
| glowplug | $8k! I can see why you guys put together a stable development platform. It's really hard to get started on the hardware side. | 20:03 |
| glowplug | Maybe I can be of some help locating cheaper boards and verifying which ones actually work. I think that would really help people people who are economically challenged get started with the project. =) | 20:04 |
| glowplug | I just watched Olof's ORPSoc 3.0 presentation again. Would you agree that there will probably be a sharp reduction in the LE requirement of ORPSoc in v3.0? | 20:08 |
| juliusb | I'm not sure to be honest | 20:08 |
| juliusb | it depends a lot on how the system is configured | 20:08 |
| stekern | andresjk: that board has a lot that's not needed, no? | 20:10 |
| andresjk | thats why dynamic partial reconfiguration its the future. Virtually unlimited resources | 20:10 |
| stekern | http://pastie.org/6474415 | 20:10 |
| andresjk | well kinda | 20:10 |
| stekern | glowplug: that's my latest build for de0-nano | 20:10 |
| stekern | don't mind the high mem-usage, I have signaltap in there using up all availabe on-board ram | 20:11 |
| glowplug | 12k LE's, 10k registers, 74 pins. I think that would work on this board even within the safety margin. | 20:11 |
| glowplug | http://wvshare.com/product/OpenEP3C16-Standard.htm | 20:11 |
| glowplug | The memory usage is high. =) | 20:13 |
| glowplug | It still looks like the EP3C16 has almost as much memory as the Nano. | 20:13 |
| stekern | ah, and signaltap is taking 5k LE's too... | 20:13 |
| glowplug | The signaltap module is totally unecessary? | 20:14 |
| stekern | it's a debugtool, alteras onchip logic analyzer | 20:15 |
| stekern | it record signals into on-chip ram and dumps it on the jtag port | 20:16 |
| glowplug | Signaltap could be flashed to a smaller external FPGA and used to debug ORPSoc externally correct? | 20:16 |
| glowplug | (Sorry for all of the questions I am very new to this stuff!). | 20:16 |
| stekern | not really, but it's not a necessity | 20:17 |
| stekern | well, perhaps you could, but you wouldn't ;) | 20:18 |
| glowplug | The latency is too great? | 20:18 |
| stekern | I'm recording ~250 different signals right now, that would mean I'd need to connect 250 pins between the two fpgas | 20:20 |
| glowplug | Well at any rate. If it's true that your using ~7k LE's for ORPSoc on a Cyclone IV device then this board could probably be used for development. | 20:20 |
| glowplug | http://wvshare.com/product/CoreEP4CE10.htm | 20:20 |
| glowplug | They are $32 for 4+ units (I believe that larger price breaks are available). I think I understand. The signaltap is reading internal signals that would need to be assigned to external pins to be used in the way I described. That would be very inconvenient. | 20:21 |
| stekern | yup, and it's not a part of orpsoc, I just have it in there to debug mor1kx when booting linux | 20:26 |
| glowplug | I think that I am going to order one of these boards and the JTAG programmer and see if I can get ORPSoc to cram in there. If not I suppose I can start hacking off modules until it fits. 8) | 20:27 |
| stekern | what do you need? | 20:30 |
| stekern | sdram controller, uart. ethernet? what more? | 20:30 |
| glowplug | Actually that's the entire list. I don't need vga, usb, anything like that. Just network and sdram (hopefully 256mb). | 20:31 |
| stekern | + your custom drive control logic of course | 20:31 |
| glowplug | That I am still trying to learn which is why I want to get a board ASAP. | 20:32 |
| glowplug | Six PWM outputs and six encoder inputs. I have absolutely no idea how many LE's those will consume. | 20:32 |
| stekern | just a note, I don't have ethernet on this board | 20:32 |
| glowplug | Thats fine I can get ethernet with an ASIC for dirt cheap. LE's are expensive. =) | 20:34 |
| stekern | time to hit the sack here, night | 20:34 |
| glowplug | Thanks for all of your help! Night. =) | 20:35 |
| andresjk | stekern, its there a limit on the number of masters that can be connected to the Xilinx MIG DDR2 controller? | 20:38 |
| glowplug | By the way if you guys need ethernet and you are short on FPGA space these are very cheap. http://bit.ly/14Xww5o | 20:40 |
| andresjk | btw, glowplug if port ORPSoC to a new board I would be nice if you share it. Im going to share my thesis project when Im done | 20:53 |
| glowplug | Absolutely. In my opinion one of the most important goals to getting more contributors is cheap hardware. Gotta solve that first. =) | 20:55 |
| glowplug | Also this device can be built for ~$3 and can flash Altera chips. Could be very helpful. | 21:01 |
| andresjk | yeah, on the other hand thanks to fpgas we can develop hardware without having to have access to a expensive clean room | 21:02 |
| andresjk | It looks cool | 21:02 |
| andresjk | thanks | 21:02 |
| glowplug | After I build one and verify that it works I will try and put something together in english that can easily be posted on the OpenCores site. | 21:03 |
| glowplug | The SDRAM controller communicates over LVTTL? | 21:49 |
| glowplug | Nevermind I think I figured it out. The current SDRAM controller implimentation does not support DIMMs (multiple synchronous sdram chips) correct? | 22:20 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!