| stekern | glowplug: what do you mean by optional vs integral lsu? | 05:59 |
|---|---|---|
| stekern | but to go back to your question about blockram speed vs system memory, that depends of course what kind of system memory you have, but let's assume we are speaking SDRAM | 06:00 |
| stekern | even if you run that SDRAM at 100MHz, you have a 2 clock cycle latency on random accesses (+ you have to break for refreshes) | 06:02 |
| stekern | plus, you are using that memory for both your instructions and data, so they have to wait for accesses from the other bus | 06:03 |
| glowplug | I wasn't sure if the LSU was a module that could be turned on and off for cappuccino but after reading more I realized that it was integral to it and not present in the other pipeline implimentations. | 06:24 |
| glowplug | The memory would be DDR. A board with two DDR chips could be used for caching data and instructions seperately. | 06:25 |
| glowplug | There is an extremely interesting project that I discovered today where a small group is working on DIY semiconductor fabrication. They have 20 micron lithography which can be scaled down to 405nm cheaply. The first mor1kx ASIC could be homemade on a 405nm process in someones garage. Pretty exciting stuff. =) | 06:38 |
| glowplug | They have an IRC channel #homecmos. | 06:41 |
| glowplug | I think communication between the two groups is probably important given that each group is solving a seperate half of the same problem. The democritization of technology. | 06:41 |
| stekern | all pipelines have lsus | 06:44 |
| stekern | but only cappuccino have a seperate pipeline stage for the data memory accesses | 06:45 |
| glowplug | I think the first thing I'm going to do when I understand the HDL is to help write better documentation for mortals. 8) | 06:50 |
| stekern | to understand the basics of a risc pipeline, I find this pretty helpful: http://en.wikipedia.org/wiki/Classic_RISC_pipeline | 06:53 |
| glowplug | I read that one many times. =) | 06:54 |
| glowplug | Unfortunately I'm very new to Verilog so it's hard to apply the high level concepts with the code. Getting there though (slowly). | 06:54 |
| glowplug | If you don't mind me asking where did you learn chip design? | 07:07 |
| stekern | I studied electrical engineering, there I was introduced to vhdl | 07:09 |
| stekern | then I didn't do any hdl design for a couple of years, and felt I needed to dust of the knowledge, so I bought a spartan 3 dev board and designed a subtractive synthesizer | 07:10 |
| glowplug | At a University? | 07:10 |
| stekern | yes | 07:11 |
| glowplug | Why is it that Universities all teach VHDL over Verilog? Haha | 07:11 |
| stekern | because I lived in Sweden ;) | 07:12 |
| glowplug | That is really great though. I've never attended a University but hopefully I can catch up and contribute. 8) | 07:12 |
| stekern | europe = vhdl, states = verilog (roughly) | 07:12 |
| stekern | open source hdl tend to be verilog, since there are better open source tool support for it (simulators and such) | 07:13 |
| glowplug | I live in Metro Detroit in Michigan, USA. =) | 07:13 |
| glowplug | It doesn't sound like you guys will be coming to the States anytime soon. I would attend if you had the 2013 conference here though! | 07:15 |
| stekern | I wouldn't mind having a conference in the states, if someone paid my flight ticket ;) | 07:22 |
| stekern | there are others involved in the project from the states | 07:23 |
| glowplug | Really? I thought everyone was in Europe. Very cool. | 07:23 |
| stekern | peter gavin, that have done massive work on the toolchain, is for instance | 07:39 |
| glowplug | Does he ever come into the IRC channel? | 07:47 |
| stekern | yes, but it was a while since he was active | 07:51 |
| mor1kx | [mor1kx] skristiansson pushed 6 new commits to master: https://github.com/openrisc/mor1kx/compare/ea9ec64ae27e...e11294b50bd8 | 16:03 |
| mor1kx | mor1kx/master 26e8358 Stefan Kristiansson: cappuccino/execute_ctrl: allow mfspr to stall the pipeline | 16:03 |
| mor1kx | mor1kx/master 5f8cb0f Stefan Kristiansson: cappuccino/rf: fix typo in comment | 16:03 |
| mor1kx | mor1kx/master 6a2745c Stefan Kristiansson: cappuccino/execute_ctrl: whitespace cleanup | 16:03 |
| juliusb | stekern: I like your move icache into fetch work | 17:22 |
| juliusb | that makes a lot of sense | 17:22 |
| stekern | yeah, in hindsight it was a mistake to keep the hierarchy flat like that | 17:53 |
| stekern | the mmus are in the fetch and lsu too | 17:54 |
| stekern | ouch... seems I have created a insanely slow path to the debug system now... | 17:59 |
| stekern | and just when I was so happy that I just had fixed the single stepping that I had broke :( | 18:06 |
| stekern | let's see if I can pinpoint what it is | 18:07 |
| stekern | one thing I have done is to flush the tail of the pipeline, since we are taking the exceptions at the end of it. | 18:08 |
| stekern | but I think that a du_stall should not flush the tail, only up until execute | 18:09 |
| stekern | but having the du_stall connected there might be the cause of the slow path | 18:10 |
| stekern | ...nope, it's something else | 18:11 |
| stekern | juliusb: I'm going to make you a sad panda, looks like it's your range or overflow stuff that is causing the insane slow path | 18:30 |
| stekern | can't say I understand how that can make a path from dcache to the debug interface though | 18:32 |
| stekern | I just tried disabling both in mor1kx.v, I'll try to see which one of them is the guilty one | 18:34 |
| stekern | (both as in OVERFLOW and ADDC) | 18:35 |
| stekern | so my comment about range was probably wrong, it's OVERFLOW or ADDC | 18:37 |
| stekern | my guess is addc, since that is the only thing that I can come up with having anything in common with the debug unit and dcache, the address | 18:39 |
| juliusb | Hmm OK | 18:43 |
| juliusb | maybe addressing into the debug SPRs? | 18:43 |
| stekern | it goes through the wb arbiter | 18:44 |
| juliusb | ??! | 18:45 |
| juliusb | pastie the report? | 18:45 |
| stekern | yeah, I will, just got to run the synthesis again :) | 18:45 |
| juliusb | nps | 18:45 |
| juliusb | are you building for the DE0? | 18:45 |
| stekern | jupp | 18:45 |
| stekern | it's no crisis though, they are easy to disable with the parameter | 18:46 |
| juliusb | nice | 18:46 |
| juliusb | we're using that for the chiphack so I'll have to take your build system for it :) | 18:46 |
| juliusb | yeah I agree | 18:46 |
| juliusb | i's no biggie | 18:46 |
| stekern | have it run at 30 MHz with ADDC or 80 MHz without ;) | 18:47 |
| juliusb | it's kinda useless unles you want it (C compiler doesn't emit etc.) | 18:47 |
| stekern | chances are that it's solve it self when I get to reworking the dcache | 18:47 |
| juliusb | !! | 18:47 |
| juliusb | I'd like to do some research on the espressos | 18:47 |
| juliusb | are you building in orpsoc or mor1kx-dev-env? | 18:49 |
| juliusb | or c) | 18:49 |
| juliusb | :) | 18:49 |
| stekern | orpsoc | 18:52 |
| stekern | actually, it looks like the RANGE feature is creating a long path too (sorry about being confusing, it was FEATURE_RANGE and FEATURE_ADDC that I disabled) | 18:55 |
| stekern | juliusb: http://git.openrisc.net/cgit.cgi/stefan/orpsoc/ <- that's my build system | 18:55 |
| stekern | just copy a fresher mor1kx in there | 18:55 |
| stekern | the range feature creates a long path through immu, dmmu and icache though | 18:58 |
| stekern | let's concentrate on the ADDC then, I guess the range path can be because it's hooked up to the exceptions | 18:59 |
| juliusb | yes, but we should perhaps regsiter it or something | 19:02 |
| juliusb | (the range exception) | 19:02 |
| juliusb | that's easy to to - out of the ALU | 19:02 |
| juliusb | or maybe in ctrl | 19:02 |
| stekern | shouldn't it already be registered from the alu? | 19:04 |
| stekern | hmm... enabling ADDC without RANGE doesn't bring out that long path to debug if anymore... | 19:07 |
| stekern | so I guess it's the RANGE feature that is the problem after all | 19:08 |
| juliusb | ok cool | 19:16 |
| juliusb | no not sure we're registering it | 19:16 |
| juliusb | you got a logic overhead number out of interest (for disabling RANGE?) | 19:16 |
| juliusb | well, for enabling it | 19:16 |
| juliusb | what's design size diff>? | 19:16 |
| stekern | hrrm, not sure | 19:17 |
| stekern | I got the signaltap in there too, so probably should rip that out and test before doing anything drastic | 19:17 |
| juliusb | ah no probs | 19:18 |
| juliusb | just out of curiosity | 19:18 |
| juliusb | I will look at it later | 19:18 |
| stekern | http://pastie.org/pastes/6574031/text | 19:19 |
| stekern | that's the debug if path anyways | 19:19 |
| stekern | but I think that is one of the slower/longer paths, so perhaps it's just getting pushed up by the range exception | 19:20 |
| juliusb | wtf | 19:20 |
| juliusb | 25ns of that path is outside of mor1kx | 19:21 |
| juliusb | odd.... | 19:21 |
| juliusb | and this is only being enabled when you have RANGE going? | 19:21 |
| stekern | jupp | 19:21 |
| juliusb | wow, OK | 19:21 |
| juliusb | that makes no sense to me at the moment | 19:22 |
| juliusb | i have to head out for a little bit, should be back in an hour or so | 19:22 |
| stekern | nps, I'll be on and off here (as always =P) | 19:22 |
| juliusb | very good :) | 19:23 |
| stekern | that path doesn't make sense, but I know why it happens | 19:23 |
| stekern | the root problem is the cache, where the wb-bus ack is combinatorially connected to the ack of the dcache (which of course look at the addresses to generate the ack) | 19:24 |
| stekern | in practice, they are never active at the same time, but it's damn hard for the synthesizer to know that | 19:25 |
| juliusb | so false path | 19:25 |
| juliusb | but... what do you mean address? | 19:25 |
| stekern | the lsu address | 19:27 |
| juliusb | ah right | 19:27 |
| stekern | is compared to what comes out of the caches tagram | 19:27 |
| juliusb | yep, but how is the overflow stuff playing with that? | 19:28 |
| juliusb | i thought we just generated a signal based on it | 19:28 |
| stekern | my guess it's not related to that, just that it creates a (different) critical path which the router resolves nicely, but forces this path to be long and slow | 19:29 |
| stekern | I've seen that happen before | 19:30 |
| juliusb | ohh OK | 19:33 |
| juliusb | :( | 19:33 |
| juliusb | but we're not really adding that much logic with the overflow thing | 19:33 |
| juliusb | i'd be very interested to see areas of overflow vs no-overflow | 19:34 |
| juliusb | but I can play with that | 19:34 |
| juliusb | anywya | 19:34 |
| juliusb | really away for a bit | 19:34 |
| stekern | well, you have it connected to execute_valid | 19:43 |
| stekern | that's a "heavy" signal | 19:43 |
| stekern | and the lsu_valid is connected to it | 19:43 |
| stekern | (which in turn is connected to the dcache ack) | 19:43 |
| stekern | so I guess that path makes sense then | 19:43 |
| stekern | so, yeah, the solution is probably to move that logic out of ctrl into execute_ctrl and generate the (registered) exeption signal in there | 19:47 |
| stekern | why is it connected to execute_valid anyway? when the overflow_set/clear signals are in control stage? | 19:48 |
| juliusb | which file? in ctrl? | 20:40 |
| stekern | yes | 20:41 |
| stekern | looks like the execute_valid is the problem, having RANGE enabled and commenting out that execute_valid makes the long path go away | 20:42 |
| juliusb | it's not:?! | 20:42 |
| juliusb | I can't see where/how | 20:43 |
| juliusb | it only goes to the range exception signal | 20:44 |
| stekern | yeah, exactly | 20:44 |
| stekern | that's what I'm speaking about | 20:44 |
| stekern | https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx_ctrl_cappuccino.v#L314 | 20:46 |
| juliusb | ohhh, AND with it?! | 20:46 |
| stekern | mmm | 20:46 |
| stekern | connected to it with an AND =P | 20:47 |
| stekern | heh, maybe my way of saying that was confusing | 20:47 |
| juliusb | ok... but | 20:48 |
| juliusb | I don't get it | 20:48 |
| juliusb | we're reading it there | 20:48 |
| stekern | but the question remains, why is it anded with the ctrl_overflow_set_i? | 20:48 |
| juliusb | i guess if execute valid is controlled by the LSU | 20:48 |
| juliusb | umm | 20:49 |
| juliusb | yes I don't know :) | 20:49 |
| stekern | ctrl_overflow_set_i is in control stage and execute_valid_i is in execute | 20:49 |
| juliusb | maybe it's something I forgot to remove from the espresso and pronto | 20:49 |
| juliusb | yes | 20:49 |
| juliusb | it's probably wrong then! | 20:49 |
| juliusb | well | 20:49 |
| juliusb | ti' | 20:49 |
| juliusb | it's from the execute_ctrl module | 20:49 |
| juliusb | overflow is registered in there | 20:49 |
| stekern | mmm, and the execute_valid is implied by the latching with padv_i | 20:50 |
| juliusb | ahh, execute_valid is combinatorial | 20:53 |
| juliusb | not registered in execute_ctrl_capp | 20:54 |
| juliusb | but then the overflow indication will come a cycle later | 20:54 |
| juliusb | it's not like that in espressos | 20:54 |
| stekern | but that's all cool, all exceptions are handled in ctrl stage | 20:54 |
| juliusb | ok | 20:54 |
| juliusb | but, we can then break the path can't we maybe? | 20:54 |
| stekern | yeah, to me it looks like that execute_valid_i could just be removed and it should work as intended | 20:55 |
| juliusb | I just picked a signal in cappuccino which I think was right | 20:55 |
| juliusb | yes I think so\ | 20:55 |
| juliusb | because we register it based on padv in the execute_ctrl stage | 20:56 |
| juliusb | s/stage/block/ | 20:56 |
| juliusb | let me check this :) | 20:56 |
| stekern | yes, and that's basically how all exceptions are handled | 20:56 |
| stekern | you designed it that way ;) | 20:57 |
| juliusb | I suspect, though, we only want that range guy to pulse for a sec | 20:57 |
| juliusb | so it may get stuck | 20:57 |
| stekern | naah, when the exception hits SR will be "overwritten" | 20:58 |
| juliusb | nope. worked fine | 20:58 |
| juliusb | or1k-ov passes anyway | 20:59 |
| juliusb | running or1k-ovcy | 21:00 |
| juliusb | (it takes a while) | 21:00 |
| juliusb | will see how it goes | 21:00 |
| juliusb | (if the verilator model built for cappuccinno it'd be alot quicker :P) | 21:00 |
| stekern | or1k-cy didn't pass before at least | 21:00 |
| juliusb | oh, or1k-cy shouldn't be effected by this | 21:00 |
| stekern | yeah, I'm gonna fix that, the problem with the dcache and and wb-ack is what makes those loops there too (I think) | 21:01 |
| juliusb | odd that it didn't pass thoguh | 21:01 |
| juliusb | ok I just saw an overflow exception go through in ovcy, so I think this is behaving fine | 21:05 |
| juliusb | do you want to check that in? | 21:05 |
| stekern | yeah, sure, if you're not up to it =P | 21:08 |
| juliusb | ah yeah im just not exactly sat infront of the machine at present | 21:19 |
| juliusb | so before we forget , I reckon it's agood thing | 21:19 |
| stekern | ok, consider it done | 21:23 |
| stekern | I'll queue it up among my millions of other commits | 21:24 |
| stekern | the execute_valid is a bit tricky in cappuccino btw, because it can depend on two instructions, one in execute and one in ctrl stage. | 21:28 |
| stekern | so it should only go high when both of them have completed | 21:29 |
| juliusb | ah cool | 21:45 |
| juliusb | or1k-cy passes here man | 21:45 |
| juliusb | on capp | 21:45 |
| juliusb | im in front of a PC now | 21:45 |
| stekern | ok, got to recheck that then | 22:25 |
| stekern | I'm pretty close to have queued up all the dmmu work now | 22:26 |
| stekern | s/dmmu/mmu | 22:26 |
| stekern | it's basically just dropping in the mmu stuff and the signals related to that left | 22:27 |
| stekern | up until now I've only merged "bugfixes" =P | 22:27 |
| stekern | including basically rewriting the fetch-stage (again) | 22:29 |
| stekern | why is that such a pain... | 22:30 |
| stekern | ? | 22:30 |
| juliusb | haha | 22:32 |
| juliusb | yeah, it's a fairly important bit of the thing | 22:33 |
| stekern | oh no... now I broke the debugexcept test again... | 22:33 |
| juliusb | :-/ | 22:35 |
| juliusb | well I wrote a test that breaks espresso :) | 22:37 |
| juliusb | https://github.com/juliusbaxter/mor1kx-dev-env/blob/master/sw/tests/or1k/sim/or1k-intmulticycle.S | 22:38 |
| stekern | but that's more positive, that's finding already existing bugs | 22:38 |
| stekern | I'm just creating new ones... | 22:38 |
| stekern | :( | 22:38 |
| juliusb | hehe | 22:39 |
| stekern | at least my small increamental changes strategy is paying off, I found the cause for it within minutes :) | 22:39 |
| juliusb | yes, that is good | 22:39 |
| juliusb | i like your strategy actually | 22:40 |
| juliusb | do the work in a big lump | 22:40 |
| juliusb | then progressively verify as you check in | 22:40 |
| juliusb | I like writing these asynchronous-exceptions-while-we're-doing-some-work tests | 22:41 |
| juliusb | feels like a real world aplication to me | 22:41 |
| juliusb | another real-world application - FreeRTOS | 22:41 |
| juliusb | you know it's the second most used RTOS in the industy, second only to in-house written ones | 22:41 |
| juliusb | I saw that on eetimes recently and was surprised | 22:42 |
| juliusb | so figured I should get a nice little demo app for OpenRISC together | 22:42 |
| juliusb | and it's what I intend to demo at the chip hack | 22:42 |
| juliusb | there's a port | 22:42 |
| juliusb | but it's only ever been run on or1ksim | 22:42 |
| juliusb | so needs some massaging | 22:42 |
| stekern | at our company, uCos is by far the most used | 22:42 |
| juliusb | yeah uCos isn't that popular surprisingly | 22:42 |
| juliusb | http://eetimes.com/ContentEETimes/Images/news/20130227pcEmbeddedSurvey841.jpg | 22:43 |
| juliusb | sorry I was wrong | 22:43 |
| juliusb | android is second now | 22:43 |
| juliusb | but that's for serious systems | 22:43 |
| juliusb | for deeply embedded freertos surely gets used second most | 22:43 |
| glowplug | How many run the RTOS on the FPGA though? Normally the RTOS runs on a uC and communicates with an FPGA if necessary correct? | 22:43 |
| juliusb | glowplug: that's probably very true | 22:44 |
| juliusb | but why not put it all on the FPGA? save yourself another IC | 22:44 |
| juliusb | (i'll give you some reasons, though - power, cost :/ ) | 22:44 |
| juliusb | eCos is nothing, I'm surprised by that | 22:45 |
| glowplug | Maybe we are 5 years away from DIY 405nm ASICs that can run mor1kx. Until then using OpenRISC for RTOS would be a $100+ FPGA board. Companies are short sighted and will take the $5 i.mx233 instead. | 22:45 |
| stekern | yeah, if you only count RTOS it's FreeRTOS, VxWorks, ucOS | 22:45 |
| juliusb | micrium lost 4% lsat year! | 22:45 |
| juliusb | ThreadX I thought was massive, too, but it's not so big | 22:45 |
| juliusb | FreeRTOS rules them all :) | 22:45 |
| glowplug | There are not cost savings. iC's with PC power cost ~$5 now. | 22:45 |
| juliusb | we use all home-grown stuff on our chips | 22:46 |
| juliusb | nothing commodity | 22:46 |
| juliusb | no real reason for it, just it was done that way in the beginning and they've continued with it | 22:46 |
| juliusb | but, apparently that's not too uncommon | 22:46 |
| glowplug | Then you add a cheap FPGA to your design for $5 (versus $50). That is what most companies will do (and as far as I know, are doing). | 22:46 |
| stekern | glowplug: not if they need to have an FPGA anyway | 22:46 |
| juliusb | i was surprised to see that, too. I knew nothing about the amount of use RTOSes get in industry until I saw that chart | 22:46 |
| glowplug | The systems that I know of have a uC and FPGA on a single board. | 22:47 |
| glowplug | Maybe that is unique to motion control / communications. | 22:47 |
| stekern | glowplug: I actuall had motion control/fieldbus systems in mind | 22:47 |
| glowplug | The raw performance of OpenRISC on a $100 FPGA is roughly 10% that of a ~$5 32-bit uC. | 22:47 |
| stekern | that's what I see most of at dayjob | 22:47 |
| juliusb | Sure, but if you can have spare capacity on your FPGA, and can deal with a cut in the MIPS you'll get from running an RTOS on a softcore, then you can save yourself money by buying only a FPGA + RAM instead of FPGA + uC + RAM | 22:48 |
| juliusb | anyway | 22:48 |
| juliusb | this is my dream for April | 22:48 |
| juliusb | FreeRTOS on mor1kx on de0 nano | 22:48 |
| juliusb | it shall be | 22:48 |
| glowplug | I agree with all of that except the money savings part. I don't think 11k LE's would ever be spare space for cost sensitive operations. | 22:48 |
| glowplug | For non cost sensitive operations they need the MIPS. So its uC anyways. | 22:48 |
| juliusb | the cost sensitive, it depends on what the cost of the FPGA To fit your soft-core is vs the cost for a uC + stuff it requires | 22:49 |
| juliusb | the incremental cost, I mean, if you need to go one model up or something | 22:50 |
| glowplug | There are many many factors. Too many. | 22:50 |
| glowplug | But in my opinion for a project to benefit from an OpenRISC core on an FPGA a lot of factors need to fall into place perfectly. | 22:50 |
| stekern | look at this for example: http://industrial.softing.com/en/products/functionality/software/protocol-stacks-for-fpgas/offering-for-altera-fpgas/offering-for-altera-fpgas.html | 22:51 |
| stekern | in right quantities, large FPGAs can become _very_ cheap | 22:52 |
| glowplug | NIOS II softcores occupy ~1k LE's | 22:52 |
| glowplug | 11 times less than ORPSoC. | 22:52 |
| stekern | but Nios II is just the cpu | 22:52 |
| stekern | orpsoc is a whole soc | 22:53 |
| glowplug | That is with peripherals. | 22:53 |
| glowplug | Let me see if I can find the PDF I had. | 22:53 |
| glowplug | www.altera.com/literature/ds/ds_nios2_perf.pdf | 22:55 |
| glowplug | It looks like you are right. It says 1,230 LE's for the NIOS II core. RAM controller is 3,100. | 22:56 |
| glowplug | No wait. Cyclone IV GX LE usage 360. | 22:57 |
| glowplug | I'm not really sure what the deal is with the Cyclone V LE usages. But the Cyclone IV with RAM controller is ~$2100 LE's. | 22:58 |
| glowplug | *~2100 | 22:58 |
| stekern | no, it says 1810 for only the cpu with 512 byte cache and no hw multiplier | 22:58 |
| stekern | on a IV GX | 22:59 |
| glowplug | I agree that the NIOS II isn't comparable to OR1200. | 22:59 |
| glowplug | But I think the systems that utilize NIOS II do so because the LE requirement is very low making the overall hardware cost very low. | 22:59 |
| stekern | no, they do so because altera have been succesful with their tools around it + with their pr | 23:01 |
| glowplug | Haha | 23:01 |
| glowplug | That may very well be the case. | 23:01 |
| stekern | 1810 isn't "very low" | 23:01 |
| stekern | it's good, but it shouldn't be completely impossible to achieve | 23:02 |
| glowplug | If that is achievable then I totally agree with the cost benefits. | 23:02 |
| glowplug | Because such a small softcore is usable in ~$15 FPGA boards in volume. | 23:02 |
| glowplug | The problem then becomes what you mentioned. Tools and PR / advertising. | 23:03 |
| stekern | I know that at least cyclone III 25k devices become dirt cheap in volume | 23:03 |
| stekern | there isn't really a connection between LEs and price when you go up in volume, there are certain devices that are cheap, and some are not | 23:04 |
| stekern | you'd easily fit orpsoc on one of those ;) | 23:05 |
| glowplug | I plan on using mor1kx for my own motion control projects. But that is because I see the immense importance of open / distributed design. Large companies arent as forward-looking. =) | 23:05 |
| stekern | I agree | 23:05 |
| glowplug | That is true at volume. The problem though becomes obtaining that volume yourselves. Because nobody else is going to financially jump before you guys do. | 23:06 |
| glowplug | So to offer devices at those prices you probably have to already have them. | 23:06 |
| glowplug | Are you familiar with this company? | 23:08 |
| glowplug | http://www.mesanet.com/fpgacardinfo.html | 23:08 |
| stekern | nope | 23:09 |
| glowplug | They are extremely popular in motion control and industrial networking. | 23:09 |
| glowplug | All of their products are impressive. But most notibly are that they offer softcore motor control that can be loaded onto the FPGA's and can drive eight motors simultanously with encoder feedback. | 23:10 |
| stekern | nice | 23:11 |
| glowplug | Mesa is probably who you would be competing with mostly. | 23:11 |
| glowplug | If you decided to design such a device. | 23:11 |
| stekern | most of the motion control I've seen is on the client side of fieldbuses | 23:12 |
| stekern | like ethercat, powerlink (and the more exotic macro) | 23:13 |
| glowplug | The Mesa devices can be client side. And even communicate with EtherCAT. | 23:14 |
| stekern | what I meant was that I haven't been involved with the actual motor control, only interfacing with the fieldbus as a client | 23:19 |
| glowplug | Ohh I see. | 23:19 |
| glowplug | This is something that I would like to achieve myself. Six axis bldc motor controller with closed loop encoder feedback on a single FPGA. Mesa offers it but what fun is that? | 23:20 |
| glowplug | I think if you could offer such a thing at ~$150 they would sell. | 23:21 |
| stekern | I agree | 23:21 |
| glowplug | Well lets get on it then! Haha | 23:21 |
| glowplug | Mesa offers the IP for SoftDMC but obviously its a proprietary license. | 23:22 |
| glowplug | If I can build the Quandary FPGA board for ~$40 each and we can figure out the motion control IP then I think that such a product is possible. | 23:24 |
| glowplug | I found a site that will prototype the 6-layer boards for Quandary at $40 each with a $275 minimum order. Cheaper than China. | 23:25 |
| glowplug | In volume order the boards can be made for ~$3 each. But the $40 boards can be used for prototyping. | 23:26 |
| glowplug | At any rate when I get some boards made I will send you guys some after I verify that they actually work. =) | 23:37 |
| juliusb | stekern: ah that bug in the new test wasn't a bug in the HW, it was a bug in the test | 23:44 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
