#milkymist IRC log for Wednesday, 2012-01-04

wolfsprauljust got my faderfox lv3 and dx209:20
wolfspraulmuch nicer!09:20
wolfspraulyes I agree, on the lv3 the joysticks looks like they are asking to be broken off09:21
wolfspraulI couldn't resist the older (midi, not usb) dx2 that was on-sale09:22
wolfspraul99 EUR09:22
wolfspraulnot bad! 4 pots, 5 rasterized encoders09:24
wpwrakah, lemme see what it's like ...11:56
wpwrakhmm, lots of knobs. i think you'll have a lot more fun with the lv3 :)11:58
wpwraknext: do something with all the midi extravaganza :)11:59
wpwraki don't know what codes the dx2 sends. for the lv3, you need a pc to translate. (FN only listens on one channel for now)11:59
wpwrakthe icreativ should work out of the box12:00
cocoadaemon_ola lekernel se suis tombé sur un article sur MM dans  theobserver13:43
cocoadaemon_tiens je le retrouve plus, par contre hackerspace chinois : http://xinchejian.com/2011/12/28/milkymist-one-video-synthesizer/13:47
lekernelc'est pas plutôt the register?13:57
wolfspraullekernel: you are back! :-)14:44
wolfspraulI was wondering what rough priorities you have now about Milkymist, going forward14:45
wolfspraulnew year thinking14:45
wolfspraulwe saw the big migen stuff, that looks very promising14:45
wolfspraulany timeline in mind? how will this evolve? what to expect? how can anybody help?14:45
wolfspraulon the manufacturing side, I will focus on rc4 next few months14:46
wolfsprauland as we make rc3 better and better, more aggressive and systematic rc3 sales and marketing efforts14:46
wolfspraulwould it help anybody if m1 switched to the slx75 variant? for example let's assume the slx45 and slx75 would cost the same.14:48
cocoadaemon_ah oui pardon register15:20
wpwrakslx75 seems to have a lot more gates. are they really so close in price ? of course, the more gates, the merrier, in general15:35
wolfspraulthat's why I ask15:37
wolfspraulI just try to understand the decision making process better, or rather document it15:37
wolfspraulthe smaller variants are not an option, I'm sure15:37
wolfspraulbecause I think even today, the milkymist bitstreams would hardly fit into an slx25, and there would be no room for development/experiments15:38
wolfspraulthen on the other side there are the slx75, slx100 and slx15015:38
wolfspraulthe problem with the slx100 and slx150 is that the free ISE will not synthesize for them, so you either need to pay big bucks, find an academic license somewhere, or just use pirate software as Xilinx's FAEs are happily handing out to their customers in China... :-)15:39
wolfspraulI actually expect more closedness on the tools side gradually, but let's make decisions one by one as they suit us15:40
wolfspraulso I think for reasons of easy and free synthesizability today, we should stay away from slx100 or slx150 on m115:40
wolfspraulthat means we're down to slx45 or slx7515:40
wolfspraulwould it be hard to support both? I guess the slx75 would need a different bitstream? I don't know15:41
wolfspraulthat's why I'm asking, hypothetically - *if* the slx75 would cost the same as the slx45, is it then something one might want in m1? or even then it's rather NO...15:41
wolfspraulI assume it's a little more expensive, yes. maybe 5 USD? I don't know. I'm not saying we should switch or anything, I just try to understand what the reasons in slx45 vs slx75 could be if they would cost the same...15:42
wpwrakhow much do you pay for the 45 ?15:42
wolfspraulfor example I personally would not want the slx100 because it would force us to email cracks around...15:42
wolfspraulI pay 39 USD15:43
wpwrakyeah, tools are essential15:43
wolfspraulyes but we are at the mercy of the big guys here, they decide15:43
wolfspraulso the slx45 costs 35-50 USD maybe15:45
wolfspraulthe one we have15:45
wolfspraul-2 speed grade, commercial15:45
wolfspraulat digikey maybe 60 USD15:45
wpwrakextrapolating from digi-key pricing, a ~75 would cost you around usd 65 then.15:45
Fallenouwolfspraul: yes different fpga => different bitstream15:45
wpwrak68.76 at digi-key. the other 113.25-119.6315:45
wolfspraulI think the gates & pricing is pretty linear15:45
wolfspraulthe slx45 costs me ca. 40 USD, the slx150 ca. 120 USD15:46
wolfspraulyes yes, sure15:46
wpwrak(the cheaper one is the ~T. not sure if they're interchangeable)15:46
wolfspraulbut I didn't want to ask about prices15:46
wolfspraulthose I know alraedy :-)15:46
wolfspraulI was asking about bitstream compatibility - Fallenou just answered that - thanks!15:46
wolfspraulso if m1 rc4 would have an slx75, that would create some effort to support in software update, if we want to support all our m1 customers well, with updates15:46
wolfspraulthat alone is a reason to not want it, even if it costs the same as slx4515:47
wolfspraullet's see whether sebastien sees any upside for milkymist in more cells15:47
wolfspraulI think the slx45 today is only ca. 50% used15:47
wolfspraulor so15:47
wolfspraulbut then I sometimes here this or that feature would 'take up too many resources'15:47
wolfspraulso I don't know, just asking15:47
wpwraki still think it's merely a question of time until we need different bitstreams.15:48
wpwrakso i wouldn't consider this a blocker15:48
wpwrakor red flag15:48
wolfspraulsure sure, I don't disagree but it's all work15:48
wpwrakeven less free tools would be, though15:49
wolfspraulI am wondering whether Sebastien sees any value in more free fpga resources15:49
wolfspraulanyway, small question15:49
wolfspraulthe more important ones I had was to understand sebastien's bigger planning for the next months, what he's excited about, how we can help15:49
wolfspraulall that15:49
lekernelwolfspraul: FAEs aren't handing out software only in China15:56
lekernellx75 isn't bitstream compatible15:57
lekernelthere's about half the current chip available15:57
lekerneland it's not like everyone's trying to do stuff on our FPGA, most people do not care and buy a digilent atlys because it's cheap15:57
lekernelor even papillio lol15:58
lekernelif you want an easy and meaningful FPGA replacement, use the -3N variant15:59
lekernelsame price as the -2, faster, but without that memory controller we do not need15:59
lekernel(-3N wasn't available when I designed the original M1 schematics, that's why we do not use it...)15:59
lekernelbut it's a drop-in replacement15:59
lekernel(in theory, at least)15:59
wpwrakhow much faster ?16:03
lekernel20-30% more MHz16:03
wpwrakfor core and memory ? or just core ? or just memory ?16:04
lekernelit's just faster silicon...16:04
lekernelso, everything is faster16:04
wpwrakkewl. sounds like a winner :)16:04
lekernelthen the software has to detect -3N and reprogram the clock generator to increase the system freq16:05
lekernelso the bitstream stays compatible with -2 boards16:05
wpwrakso there's nothing else in the circuit that would have to change ? routing, caps, ... ?16:09
GitHub45[liboscparse] sbourdeauducq pushed 1 new commit to master: http://git.io/6rWFIA16:12
GitHub45[liboscparse/master] Strict prototypes - Sebastien Bourdeauducq16:12
lekernelin theory, no16:13
lekernelit's just a chip with smaller internal delays16:13
lekernelnow we can, of course, experience unexpected murphic effects when trying -3N :)16:14
wpwrakexcellent. sounds like a quite desirable change. also for making the point that we don't need that memory controller :)16:14
wpwrakno risk, no fun :)16:14
lekernelwpwrak: btw, the "severly dysfunctional compiler" bug is gone since your last round of changes16:19
wpwrakwhee ! good riddance, whatever it was :)16:20
wpwrakbtw, fragment->bind_mode == FPVM_BIND_NONE  never seems to happen, not now and not in the future, right ?16:21
lekernelnot afaik... but it used to16:21
wpwrak(i'm looking into better tracking of when and how a variable is used. might move register assignment into FN, too. that way, we could have a proper symbol table there.)16:22
wpwrak(register assignment) at the FPVM level16:23
wolfspraullekernel: understood about -3N, I shall investigate :-)16:34
wolfspraulso you wouldn't want the SLX75 even if it were same price?16:34
wolfspraulthe main argument being that we have 'enough' free resources on the slx45 as it is16:34
wolfspraulthat is fine by me, I just try to understand...16:35
lekernelyes, and switching to SLX75 will definitely break bitstream compatibility16:36
lekernel(even if you can find a pin-compatible package)16:36
wolfspraulif you don't like it, it won't happen anyway (slx75)16:38
wolfspraulthe argument is "we haev enough free resources, let's use those first", which is perfect16:38
wolfspraulI will look into -3N though16:38
wolfspraul-N3 rather16:38
wolfspraulhow about my other questions?16:39
wolfspraulcan you give us some update on your thinking now? where is migen going?16:39
wolfspraulhow can others help?16:39
wolfspraulI will focus on rc4 next months and I feel there is a lot of good valuable stuff to do, which will help us in the short and long run16:40
wpwrakwolfspraul: how are things on the DVI front ? how will this be tackled ? is there anything that can be prototyped without a new PCB ? if not, what are the preconditions for that PCB run ?16:41
wolfspraulDVI front. Sebastien's mail is the last stop.16:43
wolfspraulI think the consensus is that dual-link provides little or no value, so probably no need to take the hassle16:43
wolfspraullet's focus on making single-link work fast and well16:43
wolfspraulno rerouting of existing pins16:43
wolfspraulcan things be prototyped, hmm16:43
wpwrak(sebastien's mail) from october ? ("DVI notes")16:44
wolfspraultheoretically always, but is there a need?16:44
wolfspraulit's a lot of work, I mean maybe one could make an expansion board/wiring today and make this work?16:44
wolfspraulI rather just go the direct route, that is layout house, review, make pcbs16:44
lekernelI don't think so, we aren't exposing the right FPGA pins and the tracks do not have the appropriate dimensions16:45
wolfspraulalright then16:45
wpwrakokay, then the path seems clear :)16:45
lekernelregarding migen, it's more long term stuff. headed for a major redesign of the soc ...16:46
lekernelwhich we will need to properly support memories like DDR3 (in the future, but the current DDR will benefit as well) and more complex GPU acceleration16:47
wpwrak(migen) but it's still a prerequisite for more bits per pixel ? or are you thinking of implementing this the "old way" for now ?16:47
lekernelno, I'm not thinking about implementing stuff the old way... and do everything at the same time16:48
lekernelmore memory bandwidth16:48
lekernelhigher bpp16:48
lekernelnew design flow16:48
wolfspraulany way to help? what's a realistic timeline?16:48
wpwrakwait .. did the negation apply to doing everything at the same time too ? :)16:48
lekernelwpwrak: no16:49
wpwrakokay, so it's migen -> { mem_bw, bpp, smoother_flow }16:49
wpwraksounds good to me16:50
wolfspraul1. ways to help 2. realistic timeline ?16:50
wpwrakwouldn't call migen "long term stuff" then, though. that always sounds like "blue sky research" ;-)16:50
lekernel#1 most of the migen work require precise knowledge of HDL and low-level architecture, and unfortunately we do not have many contributors here with these skills. I'm trying to "recruit" though, by asking if some other FPGA people would like to use it for their projects.16:54
wolfspraulI am hoping at some point that the fun-to-use m1 will become a platform people enjoy as a starting point16:55
wolfspraulI could never understand how someone can be motivated on a random devel board - everything will end with the most difficult bugs unfixed etc. well. maybe thesis & grade is done, and then forget it :-)16:55
wolfspraulsooner or later we will get that rolling on m116:56
wpwrakyeah. it's a pity so many spend time porting fragments of our stuff to devel boards16:56
lekernelwell, Migen hopefully will address that as well, by making SoC design easier than messing with bus wires manually in verilog16:56
wolfspraulyeah well16:56
wolfspraulso you are very determined on migen it sounds16:57
lekernelof course, I'm sure the first thing I'll see will be a limited migen soc for some other FPGA board. well...16:57
wolfspraulI'm always a bit worried you feel the m1 progress is too slow, even though a lot of people actually work very hard, and I believe we make substantial and valuable progress16:57
wolfspraulbut it doesn't show yet in results, admittedly16:57
wolfspraulcommunity, sales, reach16:58
wolfspraulwhat is a realistic timeline for migen?16:58
lekernelassuming no one contributes to the core of it, it'll take some time16:59
lekerneland I'll have to redesign an out-of-order and frequency-doubling DRAM controller to work with the new bus system, which can potentially provide a ~4x increase in bandwidth, but may be hard to get to work17:00
lekernelmonths, definitely17:01
lekernelwpwrak: migen isn't blue skies research. there are already practical results, like being able to semi-automatically integrate the SoC with code such as https://github.com/milkymist/milkymist-ng/blob/master/top.py instead of messy manual verilog coding17:03
lekerneland this stuff does work on the real hw17:04
lekernelthere will, indeed, be some blue skies research in some areas of migen flow, but those areas aren't absolutely necessary to get things to work17:05
wpwraklekernel: oh, i understand it isn't blue sky research. just "long term" has that sound to it. well, blue sky or old school communism with central planning for the next decade ;-)17:07
wpwraklekernel: so when you write "long term", i can see wolfgang flinch :)17:07
lekernelhe, for the shorter term stuff, we might have Peter helping with the doc. this has a quite some potential for helping the project imo.17:11
wpwrakoh yes, better doc is great. i didn't comment your mail, but all that sounds very good17:12
lekerneland that doc may actually be read :)17:13
wpwrakyour is being read too, but ... :) (speaking of the FN manual)17:14
wolfspraullekernel: sounds great [migen] how can we make you happy throughout the process?17:25
wolfspraulso you feel some pride and success in Milkymist and it's fun to hack on migen :-)17:25
wpwrak*hmm* massive cleanup in RTEMS ? just did an update and there's a gazillion of changes18:28
wpwrakand of course, it doesn't compile anymore. oh, joy ...18:32
wpwraktime for pinning ...18:32
wpwrakjust .. to what ? :-(18:40
wpwrakthe rtems git isn't in operation yet, is it ?18:40
lekernelin theory, it is18:43
wpwrakoh, cool. let's see if i have more luck there18:47
wpwrakgit has the problems, too:  undefined reference to `rtems_shell_init_env'. and also rtems_shell_main_mv, bootp_strdup_realloc19:11
wpwrakcvs date 2011/12/01 seems to be okay, though19:11
wpwrakah, VCS issues. okay :)19:12
lekernel[florian]: happy birthday!21:04
wolfspraullekernel: would you have a problem with us transferring the m1 schematics and layout into kicad?22:39
wpwrakwolfspraul: perhaps some background would help (besides the general long-term goal of moving to free and open tools)22:41
wpwraki.e., that the idea is to better automate sourcing with boom. boom is aligned with kicad. plus, it would be kinda inconvenient if i couldn't generate "real" boms for testing :)22:43
wpwrakwolfspraul: and i think "transferring" may mean a dual approach, with the layout possibly still in altium. or have you dropped that possibility ?22:44
wolfspraulno, not22:45
wpwrak(layout in altium) so that would mean parallel schematics. similar to what we have for the ben.22:45
wolfspraulyes maybe the schematics first, I haven't thought it through in detail22:46
wpwrakand, if the layout is still to be done with altium, then only the altium schematics would be used for the layout. while the kicad schematics would be used for the bom.22:46
wpwrak(and possibly other things, like schematics diffs)22:46
--- Thu Jan 5 201200:00

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