| azonenberg | wpwrak: yes, that is annoying | 01:31 |
|---|---|---|
| azonenberg | i understand the need for load balancing | 01:31 |
| azonenberg | but that can be done server side | 01:31 |
| azonenberg | wolfspraul: also, initial UI mockup for the control panel http://i.imgur.com/xGozm.png | 01:31 |
| azonenberg | kristianpaul: * | 01:31 |
| azonenberg | you'd use this to dial in what signals you're watching (a future, more advanced version may be able to parse HDL but thats a much longer term project) | 01:32 |
| azonenberg | then specify trigger conditions | 01:32 |
| azonenberg | then hit the "start" button | 01:32 |
| wpwrak | i think they don't do it for load balancing but for page impressions | 01:32 |
| azonenberg | once the trigger condition occurs, it'll launch gtkwave with the data of interest | 01:32 |
| wpwrak | next step: protocol decoding :) | 01:33 |
| azonenberg | wpwrak: thats up to gtkwave | 01:33 |
| azonenberg | make a plugin for it | 01:33 |
| azonenberg | my job is just to get data from the board into a .vcd file | 01:33 |
| azonenberg | and launch $VCD_VIEWER (currently gtkwave) to render it | 01:33 |
| wpwrak | ah, gtkwave can do such things ? didn't know that | 01:33 |
| azonenberg | I dont know if it can | 01:34 |
| azonenberg | what i do know is, that's beyond the scope of the LA | 01:34 |
| azonenberg | i'm doing capture and transport | 01:34 |
| wpwrak | ;-) | 01:34 |
| azonenberg | not the presentation layer | 01:34 |
| wpwrak | at some point, you may want to add protocol triggers ... | 01:34 |
| azonenberg | Good point | 01:34 |
| azonenberg | Thats a much longer term project though | 01:34 |
| azonenberg | The trigger systm i have now is adequate for catching the single bug i'm developing the tool for | 01:35 |
| wpwrak | do you stream to DRAM ? or just keep it in the tiny FPGA memory ? | 01:35 |
| azonenberg | once i have it finished to the point that i can use it, i'll then use it to catch my bug | 01:35 |
| azonenberg | Right now, i use four block RAMs | 01:35 |
| azonenberg | each 32 bits wide x 512 bits deep | 01:35 |
| azonenberg | to get 128 channels x 512 samples | 01:35 |
| wpwrak | that's not a lot :-( | 01:35 |
| azonenberg | You could make it deeprr | 01:35 |
| azonenberg | remember this is better than a normal LA for fpga stuff since you are capturing on a clock | 01:36 |
| azonenberg | so you dont need to oversample unless you're looking for glitches | 01:36 |
| azonenberg | so 512 samples = 512 clocks | 01:36 |
| wpwrak | the very shallow sample memory is a problem of all those cheap fpga-based LAs | 01:36 |
| azonenberg | This isnt meant to replace a conventional LA | 01:36 |
| azonenberg | this is meant to replace chipscope | 01:36 |
| azonenberg | and i cant stream to dram | 01:36 |
| azonenberg | for one very simple reason | 01:37 |
| wpwrak | yes, but if you want to analyze protocols, you need a lot of samples (and/or good idle detection) | 01:37 |
| azonenberg | i'm trying to fix a bug in my dram controller | 01:37 |
| azonenberg | using this tool :p | 01:37 |
| wpwrak | heh ;-) | 01:37 |
| wpwrak | i see the catch 22 :) | 01:37 |
| azonenberg | So block ram is a necessity lol | 01:37 |
| azonenberg | a dram based back end is a possibility for a future version | 01:37 |
| azonenberg | as a plugin | 01:37 |
| wpwrak | maybe you can extend it once the dram bug is fixed :) | 01:37 |
| azonenberg | i want to make it highly modular | 01:37 |
| azonenberg | i'm already setting it up so the PC interface is modular | 01:37 |
| azonenberg | the interface implemented right now is a uart at 500kbps but that can be swapped out with usb, ethernet, jtag, etc potentially | 01:38 |
| azonenberg | though uart is the only one i'm implementing in the short term | 01:38 |
| azonenberg | 64 kbits * 500kbps = fraction of a second | 01:38 |
| azonenberg | so its not a bottleneck | 01:38 |
| azonenberg | you could always use more block ram too | 01:38 |
| azonenberg | but this is meant to be a minimally invasive debugging solutoin | 01:39 |
| azonenberg | that you can throw in almost anywhere | 01:39 |
| azonenberg | the current system including a 32-bit counter (my DUT) and the UART | 01:39 |
| azonenberg | uses less than 100 spartan6 slices and four block rams | 01:39 |
| wpwrak | yeah. i'm more after a general LA. deep memory, and a speedy link to the host. with M1, we have everything one would need to make such a critter. | 01:42 |
| azonenberg | wpwrak: yeah | 01:43 |
| azonenberg | And i want to do something like that TOO | 01:43 |
| azonenberg | But my goal right now is to make something useful for fpga debugging | 01:43 |
| azonenberg | where you can't simulate for some reason | 01:44 |
| wpwrak | sure. one piece at a time :) | 01:44 |
| azonenberg | and you dont want to break out to GPIOs and hook up to a regular LA | 01:44 |
| azonenberg | either for lack of GPIOs or lack of a LA or whatever | 01:44 |
| azonenberg | or in my case lack of a sufficiently fast LA | 01:44 |
| wpwrak | yup. an integrated LA is certainly good to have | 01:44 |
| azonenberg | So i dont wnat to have for example super sophisticated triggering systems | 01:45 |
| azonenberg | as that would either make it slower or bigger | 01:45 |
| azonenberg | both are counterproductive in this case | 01:45 |
| azonenberg | i also dont want it so complex i have to spend a long time debugging it | 01:46 |
| wpwrak | so you're not taking the zen approach :) | 01:50 |
| azonenberg | which is that? | 01:50 |
| wpwrak | "the way is the goal" | 01:51 |
| azonenberg | This is a tool, not one of my main projects | 01:51 |
| azonenberg | a necessary step on the road toward world domination is to be able to debug your robot army :p | 01:52 |
| wpwrak | that's a good point | 01:52 |
| kristianpaul | azonenberg: nice | 02:02 |
| kristianpaul | tought i personally will follow a simpler aprouch | 02:02 |
| azonenberg | kristianpaul: how so | 02:02 |
| kristianpaul | like just logging the uart to a log | 02:02 |
| azonenberg | Oh | 02:02 |
| azonenberg | This is meant for raw data dumps though | 02:02 |
| azonenberg | and it captures in real time at high speed and then dumps slowly | 02:03 |
| kristianpaul | but yeah i recalled that | 02:03 |
| kristianpaul | remenber* | 02:03 |
| azonenberg | and integrates nicely with gtkwave for plotting signals :) | 02:03 |
| azonenberg | sure, there are other ways to solve the same problem | 02:03 |
| kristianpaul | yes sure | 02:03 |
| azonenberg | but i think this one will work well for a lot of applications | 02:03 |
| kristianpaul | and is okay, i like gtkwave at the end | 02:03 |
| kristianpaul | sure it is | 02:04 |
| kristianpaul | well i'll just need 3 channel | 02:06 |
| azonenberg | Lol well i'm trying to debug a memory bus | 02:07 |
| kristianpaul | i know :) | 02:07 |
| azonenberg | so i have ~25 bits of address, 32 of data, and a few other things | 02:07 |
| kristianpaul | yeah i can imagine | 02:07 |
| azonenberg | http://www.eejournal.com/archives/articles/20080212_lattice/ | 02:08 |
| azonenberg | might find that interesting | 02:08 |
| wolfspraul | azonenberg: nice project indeed, good luck with polishing/blog etc! You may want to tell the sigrok folks about it (sigrok.org). do you know sigrok? they have different hw&sw right now, mostly, but they might be interested in your LA. | 02:47 |
| azonenberg | wolfspraul: no, i dont know them | 03:30 |
| wolfspraul | it's led by our good friend Uwe Hermann in Germany, and I hope they stick to it for a while and make the software really solid | 03:38 |
| wolfspraul | these are just little toys right now, maybe good for serial, low-speed usb, etc. your LA comes from a different level :-) | 03:38 |
| lekernel | ah, I just proposed sigrok as well :) | 09:15 |
| lekernel | wpwrak: do you think kicad would be good enough for the whole m^3 board (schematics+routing)? | 12:14 |
| wpwrak | schematics certainly, yes. routing, no sure. i haven't done any multilayer (> 2) work with it yet. some people have and their results don't look all bad, though. | 12:18 |
| wpwrak | so i think it would be at least worth trying. you also have "Freeroute" as a fallback option | 12:19 |
| lekernel | worth giving it a try then? | 12:19 |
| lekernel | http://www.freerouting.net/ ? | 12:19 |
| wpwrak | yeah, that one | 12:20 |
| lekernel | huh, weird one | 12:20 |
| wpwrak | ugly SaaS | 12:21 |
| wpwrak | but it seems to work okay. tried it a bit a long time ago | 12:21 |
| wpwrak | someone should write a proper open source router for kicad. kicad helps with manual routing (DRC while you draw; "magnetic" off-grid points), but it's still relatively painful work | 12:25 |
| wpwrak | thanks to adam, we now also have a fairly sizable symbol and footprint library. still needs a bit of ordering, though. | 12:28 |
| lekernel | good | 12:28 |
| lekernel | I think we have some chance of completely getting rid of the ugly altium finally :) | 12:34 |
| wpwrak | yeah. that will be a day worth celebrating :) | 12:48 |
| wpwrak | have you looked at the kicad schematics adam made for m1r4 ? they're very clean. much nicer than the altium version. | 12:49 |
| lekernel | yes, I had a look at them. and I share your opinion | 13:16 |
| lekernel | that's why I'm looking forward to a 100% kicad m^3 | 13:16 |
| wpwrak | excellent :) | 13:18 |
| qi-bot | The MMU firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120616-1504/ | 14:05 |
| Fallenou | hehe nice auto build :) | 14:29 |
| Fallenou | the url is wrong but the files are there : http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-mmu-20120616-1504/ | 14:29 |
| GitHub173 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/bde8361e193038f07dff94398ac9fb8e06186c30 | 15:33 |
| GitHub173 | [migen/master] flow: insert combinators and infer plumbing layout - Sebastien Bourdeauducq | 15:33 |
| GitHub161 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/5c139511e888218731c59a4a51248a13683197db | 17:26 |
| GitHub161 | [migen/master] examples/flow/arithmetic: simulate - Sebastien Bourdeauducq | 17:26 |
| GitHub187 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/c1450daa93ac2013115635841b3a7d49a9452c94 | 19:25 |
| GitHub187 | [migen/master] flow: insert splitters - Sebastien Bourdeauducq | 19:25 |
| GitHub126 | [migen] sbourdeauducq pushed 7 new commits to master: https://github.com/milkymist/migen/compare/c1450daa93ac...21eb17fc3621 | 20:43 |
| GitHub126 | [migen/master] examples/flow/arithmetic: cleanup - Sebastien Bourdeauducq | 20:43 |
| GitHub126 | [migen/master] flow/actor: add single_sink/single_source retrieval methods - Sebastien Bourdeauducq | 20:43 |
| GitHub126 | [migen/master] flow/actor: fix busy signal generation for pipelined actors - Sebastien Bourdeauducq | 20:43 |
| --- Sun Jun 17 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!
