#milkymist IRC log for Tuesday, 2012-05-01

wolfspraulanybody here?06:32
cladamwany problems ? :-)06:45
wolfspraulno problems, just thinking06:50
wolfspraulright 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
wolfspraullet's wait until sebastien is back from the US...06:52
wolfsprauluntil then hopefully the current R4 is fully settled in kicad, the schematics06:53
cladamwdo you want KiCad m1r4 to be experimental run ? or let one directly go for spi flash, ddr3, or upgrade to slx75 ?06:54
wolfspraulwell that's the question06:56
wolfspraulsales are slow, so we are not under pressure to make a new product run fast06:56
wolfspraulwhether that's good or bad is another question, but we can accelerate making improvements we have already more or less agreed upon06:57
wolfspraulbut definitely settle the current r4 schematics in kicad first06:57
wolfspraulI'm just wondering about small run, maybe we can make more improvements before the small run, it saves money06:57
wolfspraulif we change to spi flash, ddr3 and slx75 that breaks bitstream compatibility, that's a problem06:58
wolfsprauland ddr3 (and spi) means a lot of work to actually get it to work again06:58
wolfsprauljust wondering...06:58
wolfspraulwe could call it R5 and just skip making any physical R4 :-)07:00
wolfspraulanyway just thinking07:01
cladamwregards 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
cladamwwell... i keep embellishing sch. chat later.07:02
wolfspraulembellishing ;-)07:03
wolfspraulsounds good07:03
cladamwbut 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
wolfspraulno I'm not worried about that now07:17
wolfspraulof course in theory it would be great to switch to digital video-in and out, but our highest priority should still be what works today07:17
wolfspraulotherwise we are completely in development land, and then everybody can just randomly hack on whatever they want07:18
wolfspraulso first step, we are *adding* digital dvi video out, which will initially not work07:18
wolfspraulafter 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
wolfspraulsame for video-in, what we have now works today07:18
wolfspraulall is fine with R4 as it is planned now, I think07:20
wolfspraulI am just wondering whether we should accelerate future planned improvements07:20
wpwrak(breaking bitstream compatibility) do holy cows make a nice barbecue, once they're finally slaughtered ? ;-)12:22
FallenouI guess it means that older M1 won't be supported anymore ?12:24
Fallenouno more FN update nor bitstream update12: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
wolfspraulFallenou: oh you bet they will be supported!12:24
Fallenouwell it will be a lot of work12:24
wolfspraulthe moment we drop support for old hardware any claims of 'commercial use' are done12:24
Fallenouit will mean two branches (or two different repositories)12:24
Fallenouby support I meant "update"12:25
wolfspraulyeah, so maybe it's not a good idea12:25
Fallenounot "mine is broken please help"12:25
wolfspraulwell, considering that we still don't even have a test plan :-)12:25
Fallenouwell for FN maybe I'm pessimistic, it's still possible to have only one source, even one binary, that could work on two different M112:26
wolfspraulbut I think we should avoid anything that would fragment our already small active community12: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
Fallenouyou just test for the hardware version in software and do two different things12:26
Fallenouit just means that the software will grow a little bit more comple12:27
Fallenoucomplex*12:27
Fallenoubut for the bitstream development, sometimes features added to the newer bitstream will have to be backported to the old bitstream12:28
Fallenouif it's possible12:28
Fallenousometimes it will be trivial12:28
Fallenoulike a git cherry-pick12:28
wolfspraulyes I agree with Werner now12:28
wpwrakFallenou: 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 hardware12:28
Fallenousometimes it won't, because the 2 fpga are just different12:28
wolfspraulwe should make a small run fast, and establish a baseline12:28
wpwrakFallenou: eventually, the older builds would start to rot. but that may take a while.12:28
wolfspraulthen we can decide whether to make more of that, or quickly do another small run with another incremental R512:28
wolfspraulideally we should try to cluster any change that breaks compatibility, at least that12:29
wolfspraulchanges (plural)12:29
Fallenouwpwrak: ok12:29
wpwraka 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
wolfspraulmaybe we can make R4 with kicad12:30
wolfspraulI want to accelerate, as usual :-)12:30
wolfspraulalthough it would probably just be an import of gerbers, and then a well documented process back out of kicad12:31
wolfspraul(for the layout)12:31
wpwrakFallenou: i wouldn't even think of branching. more like #ifdefs12:31
Fallenouwpwrak: I was more thinking about real if ()12:32
Fallenouin order to have just one binary12:32
Fallenoujust one build, one binary12:32
wpwrakwolfspraul: i don't see a successful gerber -> pcbnew workflow. to start with, you'd probably have countless things off-grid12:33
Fallenouone distribution, one location12:33
wpwrakFallenou: real if() may be tricky. e.g., when we reassign pins12:33
FallenouI agree it would make the binary a bit bigger (but really significantly ? not sure)12:33
Fallenouwpwrak: maybe adding a small abstraction layer ?12:33
wpwrakFallenou: 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 them12:34
wpwrakFallenou: if the abstraction layer creates a different bitstream, yes, that can be done :)12:34
Fallenouno no I meant a software abstraction layer12:35
wpwrakif you keep alternatives in the bitstream, this probably also means that your propagation delays increase. so timing will also get more difficult.12:35
larsctwo bitstreams, one software12:35
Fallenouinstead of testing in the code right where you need to toggle a GPIO, in order to check for hardware version12:35
wpwraklarsc: exactly :)12:36
Fallenouyou do like "set_pin(PIN_XYZ, value);"12:36
wpwrakor N bitstreams, one source. whatever it takes.12:36
Fallenouand the set_pin checks for hardware version and translates PIN_XYZ for the correct pin12:36
Fallenouwpwrak: yes one source, even one binary :)12:36
wolfspraulwpwrak: you mean you have to enter the layout manually into pcbnew?12:37
wpwraki don't believe in the "one binary to rule them all" theory :)12:37
FallenouIt's very convenient to only have to do one release12:37
wpwrakwolfspraul: if you want to be able to make significant changes, most likely yes12:37
wolfspraulthe problem is in the gerber import path, or in pcbnew's capabilities itself?12:37
wolfspraulok, got it12:37
Fallenouusers 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
wpwrakFallenou: and i want a flying pink unicorn. with lasers ;-)12:39
Fallenoume too :p12:39
Action: larsc not12:39
wolfspraulall nice theories, but to pull it off in reality is a lot of infrastructure, testing, risk, etc.12:39
Fallenouyou really think it's that difficult to put in place ?12:39
wolfspraulin the long run it's necessary, but if we can avoid now - great12:40
wpwrakwolfspraul: i think it's indeed mainly an infrastructure issue. we need more 100% automated tests. that way, the testing burden largely vanishes.12:41
wolfspraulyes12:41
wpwrakbesides, 100% automated tests would be useful to have in general, not just for bitstream versions12:41
Action: Fallenou agrees about automated tests, or just tests in general12:42
wolfspraulis there a way to create graphical schematics of Milkymist SoC codes? does it make any sense to gain overview?13:29
wolfspraulif anybody does this - which tool to use? ISE? free tools?13:29
wpwrakhmm, there is some sort of editor that supposedly can do this. i never got it to run, though13:31
wpwrakand of course, entirely non-free13:31
wpwraks/free/Free/ # gratis it is13:35
kristianpaul#ifdefs, yeah :)14:15
kristianpaulgraph from the sinthesized code is not always the same..14:19
kristianpaulfor overview i use this http://kristianpaul.org/~paul/tmp/mm1_html/hierarchy.html verilog2html make some easy browse trought SoC signals and modules14:20
Action: sb0 just completed the 43-hour Fermilab->NASA JPL train ride15:44
GitHub183[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/thPdnA16:49
GitHub183[milkymist-ng/master] tb/asmicon_wb: better access pattern - Sebastien Bourdeauducq16:49
GitHub85[migen] sbourdeauducq pushed 3 new commits to master: https://github.com/milkymist/migen/compare/6a52e44...f2c20e416:50
GitHub85[migen/master] sim: pass extra keyword arguments to Verilog converter - Sebastien Bourdeauducq16:50
GitHub85[migen/master] fhdl/verilog: add option to display which comb blocks are run - Sebastien Bourdeauducq16:50
GitHub85[migen/master] bus/asmibus/hub: hack to prevent comb loops - Sebastien Bourdeauducq16:50
sb0if someone wants to test... the DRAM may work from LM32 now16:50
kristianpaulspeed?17:16
--- Wed May 2 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!