wolfspraul | anybody here? | 06:32 |
---|---|---|
cladamw | any problems ? :-) | 06:45 |
wolfspraul | no problems, just thinking | 06:50 |
wolfspraul | right now I'm wondering whether we can accelerate some of the planned changes such as the switch to spi flash, ddr3, or upgrade to slx75 :-) | 06:51 |
wolfspraul | let's wait until sebastien is back from the US... | 06:52 |
wolfspraul | until then hopefully the current R4 is fully settled in kicad, the schematics | 06:53 |
cladamw | do you want KiCad m1r4 to be experimental run ? or let one directly go for spi flash, ddr3, or upgrade to slx75 ? | 06:54 |
wolfspraul | well that's the question | 06:56 |
wolfspraul | sales are slow, so we are not under pressure to make a new product run fast | 06:56 |
wolfspraul | whether that's good or bad is another question, but we can accelerate making improvements we have already more or less agreed upon | 06:57 |
wolfspraul | but definitely settle the current r4 schematics in kicad first | 06:57 |
wolfspraul | I'm just wondering about small run, maybe we can make more improvements before the small run, it saves money | 06:57 |
wolfspraul | if we change to spi flash, ddr3 and slx75 that breaks bitstream compatibility, that's a problem | 06:58 |
wolfspraul | and ddr3 (and spi) means a lot of work to actually get it to work again | 06:58 |
wolfspraul | just wondering... | 06:58 |
wolfspraul | we could call it R5 and just skip making any physical R4 :-) | 07:00 |
wolfspraul | anyway just thinking | 07:01 |
cladamw | regards to AD m1r4 keeps running. these improvements about spi, ddr3 or slx75 are definitely from now on to use KiCad m1r4 to modify for further small run(M1R5). But just to know if one has this wish to go. Since as you said, it's lot of works moving. :-) | 07:01 |
cladamw | well... i keep embellishing sch. chat later. | 07:02 |
wolfspraul | embellishing ;-) | 07:03 |
wolfspraul | sounds good | 07:03 |
cladamw | but one thing, long time ago, you said that a main like core/fpga module without video-in decoder & audio codec mounted, that idea is suffer from chip vendor's potential phase out issue. Does this mean to for m1r5 ? | 07:08 |
wolfspraul | no I'm not worried about that now | 07:17 |
wolfspraul | of course in theory it would be great to switch to digital video-in and out, but our highest priority should still be what works today | 07:17 |
wolfspraul | otherwise we are completely in development land, and then everybody can just randomly hack on whatever they want | 07:18 |
wolfspraul | so first step, we are *adding* digital dvi video out, which will initially not work | 07:18 |
wolfspraul | after that is working, we can one day think about removing the analog video-out, if people don't want or need it anymore. but in this order. | 07:18 |
wolfspraul | same for video-in, what we have now works today | 07:18 |
wolfspraul | all is fine with R4 as it is planned now, I think | 07:20 |
wolfspraul | I am just wondering whether we should accelerate future planned improvements | 07:20 |
wpwrak | (breaking bitstream compatibility) do holy cows make a nice barbecue, once they're finally slaughtered ? ;-) | 12:22 |
Fallenou | I guess it means that older M1 won't be supported anymore ? | 12:24 |
Fallenou | no more FN update nor bitstream update | 12:24 |
wpwrak | (slows sales) i was just thinking about that. in fact, it's a good sign. not "good" as in what we'd like to happen in a perfect world, but "good" in making sense. marketing efforts are currently low. so this shows the connection. | 12:24 |
wolfspraul | Fallenou: oh you bet they will be supported! | 12:24 |
Fallenou | well it will be a lot of work | 12:24 |
wolfspraul | the moment we drop support for old hardware any claims of 'commercial use' are done | 12:24 |
Fallenou | it will mean two branches (or two different repositories) | 12:24 |
Fallenou | by support I meant "update" | 12:25 |
wolfspraul | yeah, so maybe it's not a good idea | 12:25 |
Fallenou | not "mine is broken please help" | 12:25 |
wolfspraul | well, considering that we still don't even have a test plan :-) | 12:25 |
Fallenou | well for FN maybe I'm pessimistic, it's still possible to have only one source, even one binary, that could work on two different M1 | 12:26 |
wolfspraul | but I think we should avoid anything that would fragment our already small active community | 12:26 |
wpwrak | (m1r4) i think it's a big enough step that it makes sense to build it, not just on paper. that way, we have a fallback option that's not too far away. | 12:26 |
Fallenou | you just test for the hardware version in software and do two different things | 12:26 |
Fallenou | it just means that the software will grow a little bit more comple | 12:27 |
Fallenou | complex* | 12:27 |
Fallenou | but for the bitstream development, sometimes features added to the newer bitstream will have to be backported to the old bitstream | 12:28 |
Fallenou | if it's possible | 12:28 |
Fallenou | sometimes it will be trivial | 12:28 |
Fallenou | like a git cherry-pick | 12:28 |
wolfspraul | yes I agree with Werner now | 12:28 |
wpwrak | Fallenou: the effect i'd expect would be more along the lines of main development focusing on the latest hardware but things still being able to build for older hardware. and occasionally, e.g., for releases, there would be systematic testing of the builds for older hardware | 12:28 |
Fallenou | sometimes it won't, because the 2 fpga are just different | 12:28 |
wolfspraul | we should make a small run fast, and establish a baseline | 12:28 |
wpwrak | Fallenou: eventually, the older builds would start to rot. but that may take a while. | 12:28 |
wolfspraul | then we can decide whether to make more of that, or quickly do another small run with another incremental R5 | 12:28 |
wolfspraul | ideally we should try to cluster any change that breaks compatibility, at least that | 12:29 |
wolfspraul | changes (plural) | 12:29 |
Fallenou | wpwrak: ok | 12:29 |
wpwrak | a R5 run would also help to validate the kicad version. chances are that it has some nasty bugs. there's a lot of stuff in there, with the risk of overlooking something. but we'll never find them unless we actually try to make the board. | 12:30 |
wolfspraul | maybe we can make R4 with kicad | 12:30 |
wolfspraul | I want to accelerate, as usual :-) | 12:30 |
wolfspraul | although it would probably just be an import of gerbers, and then a well documented process back out of kicad | 12:31 |
wolfspraul | (for the layout) | 12:31 |
wpwrak | Fallenou: i wouldn't even think of branching. more like #ifdefs | 12:31 |
Fallenou | wpwrak: I was more thinking about real if () | 12:32 |
Fallenou | in order to have just one binary | 12:32 |
Fallenou | just one build, one binary | 12:32 |
wpwrak | wolfspraul: i don't see a successful gerber -> pcbnew workflow. to start with, you'd probably have countless things off-grid | 12:33 |
Fallenou | one distribution, one location | 12:33 |
wpwrak | Fallenou: real if() may be tricky. e.g., when we reassign pins | 12:33 |
Fallenou | I agree it would make the binary a bit bigger (but really significantly ? not sure) | 12:33 |
Fallenou | wpwrak: maybe adding a small abstraction layer ? | 12:33 |
wpwrak | Fallenou: and pin reassignment is a likely occurrence: we're almost out of free pins and going from NOR to SPI would free quite a lot of them | 12:34 |
wpwrak | Fallenou: if the abstraction layer creates a different bitstream, yes, that can be done :) | 12:34 |
Fallenou | no no I meant a software abstraction layer | 12:35 |
wpwrak | if you keep alternatives in the bitstream, this probably also means that your propagation delays increase. so timing will also get more difficult. | 12:35 |
larsc | two bitstreams, one software | 12:35 |
Fallenou | instead of testing in the code right where you need to toggle a GPIO, in order to check for hardware version | 12:35 |
wpwrak | larsc: exactly :) | 12:36 |
Fallenou | you do like "set_pin(PIN_XYZ, value);" | 12:36 |
wpwrak | or N bitstreams, one source. whatever it takes. | 12:36 |
Fallenou | and the set_pin checks for hardware version and translates PIN_XYZ for the correct pin | 12:36 |
Fallenou | wpwrak: yes one source, even one binary :) | 12:36 |
wolfspraul | wpwrak: you mean you have to enter the layout manually into pcbnew? | 12:37 |
wpwrak | i don't believe in the "one binary to rule them all" theory :) | 12:37 |
Fallenou | It's very convenient to only have to do one release | 12:37 |
wpwrak | wolfspraul: if you want to be able to make significant changes, most likely yes | 12:37 |
wolfspraul | the problem is in the gerber import path, or in pcbnew's capabilities itself? | 12:37 |
wolfspraul | ok, got it | 12:37 |
Fallenou | users can't mess up, making mistake flashing the wrong binary, and when you release the latest FN, you release it instantly for all M1 owners, not just for latest M1 revision :) | 12:38 |
wpwrak | Fallenou: and i want a flying pink unicorn. with lasers ;-) | 12:39 |
Fallenou | me too :p | 12:39 |
Action: larsc not | 12:39 | |
wolfspraul | all nice theories, but to pull it off in reality is a lot of infrastructure, testing, risk, etc. | 12:39 |
Fallenou | you really think it's that difficult to put in place ? | 12:39 |
wolfspraul | in the long run it's necessary, but if we can avoid now - great | 12:40 |
wpwrak | wolfspraul: i think it's indeed mainly an infrastructure issue. we need more 100% automated tests. that way, the testing burden largely vanishes. | 12:41 |
wolfspraul | yes | 12:41 |
wpwrak | besides, 100% automated tests would be useful to have in general, not just for bitstream versions | 12:41 |
Action: Fallenou agrees about automated tests, or just tests in general | 12:42 | |
wolfspraul | is there a way to create graphical schematics of Milkymist SoC codes? does it make any sense to gain overview? | 13:29 |
wolfspraul | if anybody does this - which tool to use? ISE? free tools? | 13:29 |
wpwrak | hmm, there is some sort of editor that supposedly can do this. i never got it to run, though | 13:31 |
wpwrak | and of course, entirely non-free | 13:31 |
wpwrak | s/free/Free/ # gratis it is | 13:35 |
kristianpaul | #ifdefs, yeah :) | 14:15 |
kristianpaul | graph from the sinthesized code is not always the same.. | 14:19 |
kristianpaul | for overview i use this http://kristianpaul.org/~paul/tmp/mm1_html/hierarchy.html verilog2html make some easy browse trought SoC signals and modules | 14:20 |
Action: sb0 just completed the 43-hour Fermilab->NASA JPL train ride | 15:44 | |
GitHub183 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/thPdnA | 16:49 |
GitHub183 | [milkymist-ng/master] tb/asmicon_wb: better access pattern - Sebastien Bourdeauducq | 16:49 |
GitHub85 | [migen] sbourdeauducq pushed 3 new commits to master: https://github.com/milkymist/migen/compare/6a52e44...f2c20e4 | 16:50 |
GitHub85 | [migen/master] sim: pass extra keyword arguments to Verilog converter - Sebastien Bourdeauducq | 16:50 |
GitHub85 | [migen/master] fhdl/verilog: add option to display which comb blocks are run - Sebastien Bourdeauducq | 16:50 |
GitHub85 | [migen/master] bus/asmibus/hub: hack to prevent comb loops - Sebastien Bourdeauducq | 16:50 |
sb0 | if someone wants to test... the DRAM may work from LM32 now | 16:50 |
kristianpaul | speed? | 17:16 |
--- Wed May 2 2012 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!