IRC logs for #openrisc Wednesday, 2013-03-13

glowplugIs anyone familiar with this project?  kck.st/UNVcNF01:39
GentlemanEngineeHello.04:15
glowplugWelcome back.  =)04:16
GentlemanEngineeIt appears we have a similar schedule...04:16
glowplugI've actually been in here all day.  Haha04:16
GentlemanEngineeI think the office might have some issues if I attempted something similar.04:16
glowplugSounds like you need to straiten them out.  OpenRISC is obviously more important.04:18
GentlemanEngineeI would not disagree...04:19
GentlemanEngineeHowever, it is unlikely they would be willing to change their viewpoint.04:19
glowplugThat's what I mean.  You need to "change" their viewpoint.  8)04:21
-!- Gentlema` is now known as GentlemanEnginee04:22
GentlemanEngineeI 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
glowplugOR providing you with a BIGGER paycheck.  Can't know unless you try.  =)04:24
GentlemanEngineeActually, I am hoping to transfer to the FPGA Department in the future...04:24
glowplugYour company has an FPGA department.  So lucky.04:25
GentlemanEngineeOnly if I can transfer to it.04:25
glowplugHave you seen this company / board before?04:26
glowplughttp://wvshare.com/product/OpenEP4CE10-C-Standard.htm04:26
GentlemanEngineeNo.04:27
GentlemanEngineeI have only used some Xilinx products.04:28
glowplugI'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
GentlemanEngineeI am not certain of ORPSoc's requirements.04:28
glowplugThe other FPGA boards supported by ORPSoc are $90 and $160.  O.o04:28
GentlemanEngineeIt was my thought to familiarize myself on some of the internal structures &c prior to looking at FPGA Requirements.04:29
glowplugI 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
glowplugIt might mean less peripherals or other changes to cram it in.04:30
GentlemanEnginee10k for peripherals?04:31
glowplugThe FPGA in that board I linked has 10K LEs *total*.04:32
GentlemanEngineeYes, and you were stating that 22k LEs were required for a full build.04:32
glowplugI 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.  Haha04:32
GentlemanEngineeAh!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
GentlemanEngineeI would wish to avoid that cost if I could.04:36
glowplugThat 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
glowplugYou probably can if you depend completely on simulation.  But I guess that depends on what you are working on.04:36
glowplugAnother 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
GentlemanEngineeFor 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=17404:39
glowplugThose are available on Ebay for even less.  Unfortunately you cant synthesize an OpenRISC core on one.  =(04:41
GentlemanEngineeNo, I was referring to learning Verilog &c.04:43
GentlemanEngineeAlso, it could be useful in connecting to an OpenRISC Core for testing purposes.04:43
glowplugI see.  I'm not convinced it's that great of a tool because of the rate you would outgrow the hardware.04:44
GentlemanEngineeIt could be used to validate a wishbone interface, in a unit testing manner.04:45
GentlemanEngineeAlso, it allows for level shifting.04:45
glowplugA wishbone interface between the CLPD and an FPGA?04:45
glowplug*CPLD04:46
glowplugWouldn't that only be useful if you ran out of LE's or pins on the FPGA?04:46
GentlemanEngineeExternal testing of a core.04:46
GentlemanEngineeCreate CPLD with unit testing on it.04:47
GentlemanEngineeChange Core design to heart's content, and then connect to CPLD for testing.04:47
GentlemanEngineeAlso, as I stated, it does allow for level shifting.04:47
glowplugRight.  Then interface the CPLD to an FPGA and use it for debugging / testing.04:47
GentlemanEngineeExactly.04:48
glowplugI totally agree.  But I don't think we can get anything done without a full size FPGA.04:48
GentlemanEngineeNot for OpenRISC...04:49
glowplugMaking 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
GentlemanEngineeThe CPLD could be used as a Golden Test Tool.04:50
GentlemanEngineeConsider it similar to a logic analyzer with specialized testing.04:50
glowplugI can see that usage for it.04:51
GentlemanEngineeIt was a thought that had drifted into my mind...04:51
glowplugWhat 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
glowplugRemoving the need for the CPLD.04:51
glowplughttp://wvshare.com/product/SDRAM-Board-A.htm04:52
glowplugThere is a link to the SDRAM module for the board I linked previously.  Very cool.  =)04:52
GentlemanEngineeThat would be changing the core from its intended use for testing. This could allow for functionality to be tested incorrectly.04:53
GentlemanEngineeInteresting...04:53
glowplugAssuming 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
GentlemanEngineeIf one desired...04:55
glowplugAll in the spirit of saving $15 of course.  =)04:55
GentlemanEngineeIn deference to full disclosure, I already own one.04:55
glowplugAhah!  Haha04:55
glowplugNow you just need an FPGA.  8)04:56
GentlemanEngineeIndeed.04:56
GentlemanEngineeIt might be nice to connect it to some GNU Radio Hardware.05:02
glowplugThere is a new USB 3.0 SDR that recently came out.  Let me get a link.05:03
glowplughttp://nuand.com/order.php05:05
GentlemanEngineeI forsee some charges to my credit card...05:05
glowplugHahaha05:05
glowplugHave you implimented PWM in Verilog?05:06
GentlemanEngineeNo.05:06
glowplugDamn.05:07
GentlemanEngineeI have done some counters and register swapping.05:07
GentlemanEngineeI have implemented PWM in C.05:07
GentlemanEngineeI would assume that Google would provide with several examples, though...05:08
glowplugFor 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
GentlemanEngineeQuite possibly...05:09
glowplugTaking input from a uC with the duty cycles.05:09
GentlemanEngineeWould the uC be sending the PWM Duty Cycles in parallel or in serial?05:10
glowplugTechnically 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
GentlemanEngineeIt could be parallel if one had enough pins...05:12
glowplugDon't all uC's execute in serial by design?05:12
glowplugWell 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
GentlemanEngineeWrite value to memory that is mapped to the pins.05:14
glowplugThe CPLD's are very cool for being so cheap though.  =)05:14
GentlemanEngineeThis allows for value to appear "instantly".05:14
glowplugAhh I see what you mean.  That makes sense.05:15
GentlemanEngineeAssuming one has enough pins to devote to this.05:15
glowplugWhich is probably why it makes more sense to cram everything into a single FPGA.05:15
glowplugThat brings latency down, board complexity ect.05:16
GentlemanEngineeYes.05:16
GentlemanEngineeHowever, the CPLD would be a good interim solution.05:16
GentlemanEngineeIt might also be less expensive.05:17
glowplugIt'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
GentlemanEngineeI concur.05:19
glowplugThis board has 15k LE's and is $45.  http://wvshare.com/product/OpenEP3C16-Standard.htm05:39
glowplugIt's probably less power efficient since it's a Cyclone III.05:40
GentlemanEngineeI doubt for a CNC that the current draw of the processor would be the limiting factor...05:43
glowplugOh no.  I'm simply saying that the Cyclone III has an inferior manufacturing processes to the Cyclone IV.05:45
glowplugBut the board is $5 cheaper with 5k more LE's05:46
GentlemanEngineeIf you can find room on your CNC for the larger die...05:48
GentlemanEngineeWhat manner of resolution were you considering for the PWMs?05:53
glowplugWe still have to find out if this board has enough LE's for ORPSoc.  That is the golden question. =)05:53
glowplughttp://wvshare.com/product/OpenEP3C16-Standard.htm05:53
glowplugSine PWM would be nice.  16-bit PWM would be fine.05:59
glowplughttp://bit.ly/WGJMxh06:02
glowplugBasically I need six closed loop (encoder feedback) analog (sine) servo drivers.  Preferably integrated onto a single board (minus the powerstages obviously).06:05
GentlemanEngineeHow would the feedback be provided?06:08
glowplugOutput 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
GentlemanEngineePerhaps I shall converse with you in the morrow...06:23
andresjkIs wget stable in the busybox 1.19.0? I keep getting not http07:13
GentlemanEngineeA good night to all...07:27
stekernglowplug: 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=59307:30
stekerngenerating pwm in a fpga is dead simple by the way07:33
stekernI think I have soon read all functions there is in the linux kernel... in disassembled form12:50
stekernthink I got the slippery little bug I've been chasing the last few days on the hook now at least12:51
stekernlooks like a set flag issue12:51
stekernhttp://pastie.org/647005612:52
stekernthat branch is taken, but r11 is 012:53
juliusbset flag in delay slot?!13:28
juliusband in delay slot of branch based on flag!!?13:28
juliusbso I'm trying to run the GCC testsuite against mor1kx at the moment13:33
juliusbthe only problems I'm having is with the compiler and the testsuite software :)13:33
juliusbI added -O2 to the compile command line13: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
juliusband now some tests fail13:34
juliusbeg13:34
juliusbthis one13:34
juliusb920711-1.c13:34
juliusbf(long a){return (--a > 0);}13:34
juliusbmain(){if(f(0x80000000L)==0)abort();exit(0);}13:34
juliusb(that's literrally what the file contains)13:34
stekernset flag in delay slot should be just fine13:36
stekernmor1kx handle that perfectly13:36
juliusbso... when compiled without -O2, main looks like this: http://pastie.org/647033513:36
stekern=)13:36
juliusbbut compiled with -O2 it looks like this: http://pastie.org/647033713:37
stekernbut the clear flag signal isn't coming out of the alu on the l.sfnei r11,013:37
juliusbstekern: still... I'm surprised thecompiler sets flags in delay slots and that it's legal13:37
juliusbi guess it's fine13:37
juliusbanyway13:37
stekernhmm, could you put the C code and the two cases in the pastie?13:38
juliusbwith -O2 on that code fragment, it clearly screws something up when being too clever13:38
juliusbhttp://pastie.org/647034513:39
stekernwhy 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 fine13:40
juliusbit depends on when you're evaluating the flags13:40
juliusbyou'd hope it's on the branch instruction itself13:41
juliusbit's kinda like alterting the register of the branch target in a delay slot13:42
juliusbie l.jr r3; l.movhi r3, 013:42
juliusbanyway13:42
juliusbthis compiler thing is annoying13:42
juliusball I want to do is compile and execute every C file in the GCC C torture tests things!13:43
stekernlemme see what clang does13:43
juliusband want to use -O213:43
juliusbbut maybe I Can't13:43
juliusbyes, actually13:43
stekernjust for the fun of it13:43
juliusbplease run that through llvm :)13:43
juliusbmaybe it's a known flaw in GCC or something?13:45
stekernhttp://pastie.org/647039113:49
stekernthat's what llvm does with -O213:50
juliusbit gets it right!13:51
juliusbclang: 113:52
juliusbgcc: 013:52
juliusbclang does appear to execute some superfluous stack manipulation though13:52
juliusbso, 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 processor13:53
juliusbso that I have to sidestep around a few compiler issues is a bit annoying but not a major problem13:53
stekernwell, we probably want to fix that bug too ;)13:57
stekernor32 toolchain gets it right too13:58
stekernl.jr r3; l.movhi r3, 0 <- isn't that alright too?14:00
stekernor was that just an example of something that feels wrong, but is right?14:06
juliusbno with -O2 it jumps to abort14:06
juliusbso the test fails!14:06
juliusbie it calculates that 0x80000000-1 is not greater than zero14:07
juliusbsorry14:07
juliusbyes14:07
juliusbhmmm wait14:07
juliusbso it's essentially testing if ((0x80000000-1)>0)==FALSE)14:08
juliusbso with -O2 it's getting the result that (0x7fffffff>0) is FALSE14:09
juliusbbecause it's automatically jumping to abort14:09
stekernjupp14:10
juliusband that is wrong, isn't it?14:10
stekerncould there be some weird assumption somewhere that long is 64 bit14:10
juliusbthat wouldn't matter would it?14:10
juliusbbecause 0x000000007fffffff > 0 is true14:11
juliusbbut anyway, long in OR1K is 32-bit14:11
juliusband the compiler should know that14:11
stekernah, yeah you're right14:14
juliusbalthough14:14
juliusbI guess we're talking about signed here14:14
stekerngot confused for a second there14:14
juliusbmmm14:14
juliusb0x80000000 is the biggest negative signed number you can have14:15
juliusbso that -1 will cause 32-bit signed overflow14:15
stekernmmm, and it should wrap around on -114:15
juliusbwhich ... maybe that's what GCC is picking up and saying it should still be < 014:15
stekernso 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 it14:16
stekernyou're on a 32-bit machine, right?14:18
juliusbstekern: yep15:13
juliusbfound another one: http://pastie.org/647102915:15
juliusbI suspect these are bugs in our compiler15:16
juliusbI will put them up on the bugzilla at some point15:16
juliusbbut keep in mind that these all passed without any optimisation flag15:17
stekernI'll take a look at it15:23
stekernshouldn't be to hard to find where it goes wrong, the testcases are nice and small15:24
stekern+o15:24
stekernI just need to kill this bug first15:24
stekernit's not a flag bug, but a fetch bug (surprise!)15:25
stekernat least I think it is a fetch bug15:25
stekernbecause there is a nop in the alu when there should be a l.sf instruction15:25
juliusbah!15:27
juliusban l.nop where an l.sf should be isn't usually a good thing.15:27
juliusbbut yeah, if you want to look at it, sure - but I'm not sure it's a big deal ATM15:30
stekerngiven 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
juliusbya good point15:36
juliusbi'm surprised this stuff isn't picked up the debug suite15:36
stekernbah, this is a reincarnation of the last bug I fixed15:59
stekernthe root problem is that branches isn't resolved in decode stage, so we get two "delay-slots"16:00
stekerni.e. it takes two cycles until the branch has propagated into execute and it is recognized16:01
stekernand it creates all kind of ugly corner cases where it starts to fetch stuff beyond the delay-slot16:01
stekernI've got a signal that is indicating that corner case, but it looks like I haven't connected it to all the right places16:03
juliusbjeremybennett: nice work on the ChipHack announcement - are you planning on advertising it on the OpenRISC list, too?16:41
juliusbstekern: hah, yep sounds like it's time to implement the branch detection/address generation in the fetch/decode stage :)16:42
juliusbbtw for anyone who's around London and wants to learn about FPGA development: http://chiphack.org/16:45
juliusbjeremybennett: nice idea to provide the boards for free to teachers who come along16:47
LoneTechI'm coming over for the Muse concert, but that's not until May16:48
LoneTechlooks like a nice idea16:48
jeremybennettjuliusb: Yes I should advertise it there as well.16:58
jeremybennettExcept it is filling up fast. I only sent the email an hour ago and 25% of the places have already gone!16:59
juliusbthat's good!17:01
juliusbhow many places are there in total at the moment?17:01
jeremybennettjuliusb: 22 places left as of 15:12 GMT17:12
jeremybennettJust posted to the OpenRISC mailing lists and the OpenRISC and OpenCores forums17:12
juliusbnice one, it's good publicity for the project nonetheless17:18
glowplugThat 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
glowplughttp://wvshare.com/product/OpenEP3C16-Standard.htm17:29
glowplugI suppose my question really is... can ORPSoc fit within 15k LE's?17:32
jeremybennettglowplug: 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
glowplugDo you think that there would be a massive issue with synthesizing ORPSoc on a 15k LE Cyclone III?17:43
jeremybennettglowplug: You'll need one of the HW guys to answer that - I'm a SW person18:04
glowplugI'll be hanging out in here so thats no problem.  Thanks for your help.  =)18:07
juliusbglowplug: I can't say at the moment but I will be playing around with synthesisfor an altera device quite soon18:15
glowplugFantastic!  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
glowplugI'm assuming that if the sdram chip was swapped for ~1GB that would work just fine with ORPSoc?18:24
glowplugGood afternoon andresjk.  =)18:40
andresjkhi18:41
glowplugI 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
andresjkhave you check this one: http://opencores.org/shop,item,1118:45
andresjkits a cyclon IV18:46
glowplugI have.  =)18:46
glowplugThe boards I found are $32 and $45.  A little more in my budget range (unfortunately).18:46
glowplugI 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
andresjkHave you synthesized ORPSoC in quartus for any of those boards?18:49
andresjkIm using a Virtex5 right now and Its taking 49% lol18:49
glowplugNo I have not.  That is why I am researching an affordable board.  =)18:49
glowplugWhat is your boards total LE count?  (thank you for all of your help by the way!).18:50
andresjkbut quartus its free, give it a try18:50
glowplugOh you mean in simulation?18:51
andresjkits kinda hard to compare Xilinx and Altera's architecture on resources18:51
andresjkyeah18:51
glowplugI agree.  I just need anyone who has synthesized ORPSoc on the Nano or ORSoc board to say what the LE requirement was.  =)18:52
andresjkI mean, try to synthesize the ORPSoC with one configuration (a specific fpga) and then see the summary18:52
glowplugI figured it would come to that.  8)18:52
andresjkI actually have a project in quartus of the orpsoc18:52
andresjkI could do it but I have to restart since its in my win partition18:53
glowplugI will be back in ~10 minutes grabbing lunch.  If its inconvenient at all thats no big deal!  I'm just being lazy.  Haha18:53
andresjkok then18:54
andresjkglowplug, are you there?19:25
glowplugI am.  =)19:28
andresjkok, 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 fail19:42
andresjkbtw the project was not actually the orpsoc, It didnt have the ethernet controller19:42
andresjkit was http://opencores.org/websvn,listing?repname=openriscdevboard&path=%2F&rev=219:43
andresjksorry but that was the one I have handy19:43
andresjklol19:43
andresjkI 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 lol19:47
glowplugInteresting.  So functionally you can only ever assume that ~70% of your LE's are really usable.  Thats unfortunate.  =(19:50
glowplugThank you very much for the information!19:50
glowplugI would have gotten the failure and assumed it was a mistake that I made.  Haha19:50
andresjkyes, 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 story20: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
glowplugMaybe 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
glowplugI 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
juliusbI'm not sure to be honest20:08
juliusbit depends a lot on how the system is configured20:08
stekernandresjk: that board has a lot that's not needed, no?20:10
andresjkthats why dynamic partial reconfiguration its the future. Virtually unlimited resources20:10
stekernhttp://pastie.org/647441520:10
andresjkwell kinda20:10
stekernglowplug: that's my latest build for de0-nano20:10
stekerndon't mind the high mem-usage, I have signaltap in there using up all availabe on-board ram20:11
glowplug12k LE's, 10k registers, 74 pins.  I think that would work on this board even within the safety margin.20:11
glowplughttp://wvshare.com/product/OpenEP3C16-Standard.htm20:11
glowplugThe memory usage is high.  =)20:13
glowplugIt still looks like the EP3C16 has almost as much memory as the Nano.20:13
stekernah, and signaltap is taking 5k LE's too...20:13
glowplugThe signaltap module is totally unecessary?20:14
stekernit's a debugtool, alteras onchip logic analyzer20:15
stekernit record signals into on-chip ram and dumps it on the jtag port20:16
glowplugSignaltap 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
stekernnot really, but it's not a necessity20:17
stekernwell, perhaps you could, but you wouldn't ;)20:18
glowplugThe latency is too great?20:18
stekernI'm recording ~250 different signals right now, that would mean I'd need to connect 250 pins between the two fpgas20:20
glowplugWell 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
glowplughttp://wvshare.com/product/CoreEP4CE10.htm20:20
glowplugThey 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
stekernyup, and it's not a part of orpsoc, I just have it in there to debug mor1kx when booting linux20:26
glowplugI 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
stekernwhat do you need?20:30
stekernsdram controller, uart. ethernet? what more?20:30
glowplugActually 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 course20:31
glowplugThat I am still trying to learn which is why I want to get a board ASAP.20:32
glowplugSix PWM outputs and six encoder inputs.  I have absolutely no idea how many LE's those will consume.20:32
stekernjust a note, I don't have ethernet on this board20:32
glowplugThats fine I can get ethernet with an ASIC for dirt cheap.  LE's are expensive.  =)20:34
stekerntime to hit the sack here, night20:34
glowplugThanks for all of your help!  Night.  =)20:35
andresjkstekern, its there a limit on the number of masters that can be connected to the Xilinx MIG DDR2 controller?20:38
glowplugBy the way if you guys need ethernet and you are short on FPGA space these are very cheap.  http://bit.ly/14Xww5o20:40
andresjkbtw, 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 done20:53
glowplugAbsolutely.  In my opinion one of the most important goals to getting more contributors is cheap hardware.  Gotta solve that first.  =)20:55
glowplugAlso this device can be built for ~$3 and can flash Altera chips.  Could be very helpful.21:01
andresjkyeah, on the other hand thanks to fpgas we can develop hardware without having to have access to a expensive clean room21:02
andresjkIt looks cool21:02
andresjkthanks21:02
glowplugAfter 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
glowplugThe SDRAM controller communicates over LVTTL?21:49
glowplugNevermind 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!