#milkymist IRC log for Thursday, 2012-06-07

wolfspraulxilinx ise eula04:34
wolfspraul"user agrees not to decompile, translate, reverse-engineer, disassemble or otherwise reduce to human readable form the data files generated by the software"04:35
wolfspraul"publish or disclose the results of any benchmarking of the software"04:35
wolfspraulha ha04:35
wolfspraulyeah, I can imagine they need that. good thing that I saw already a number of papers at least who were not afraid to include "benchmarking" in their paper04:36
wolfspraulso for my fpgatools, I will stay away from ISE, pretty much any process that involves any ISE tool and bitstream manipulation violates their eula04:37
Fallenouwolfspraul: is this legal to forbid any benchmarking of their tool ?06:30
Fallenouthey can virtually say whatever they want "our product is the best blablabla" and everybody is expected to just trust them ?06:31
Fallenouit should be a right to be able to compare products :)06:31
Fallenouand to write about it06:32
wolfsprauloh you should be relaxed about it06:34
wolfspraulthat could be a long discussion06:34
wolfspraula lot of things are written in a lot of eulas06:34
wolfspraulit's a fact that it's written there like this, and it speaks for Xilinx06:35
wolfspraulimagine BMW forbidding their buyers to publish "benchmarks" of the car they bought?06:35
wolfsprauldo they already?06:35
wolfspraulI don't know06:35
wolfspraulso BMW can claim the car is doing 250 km/h, but actually it barely can make 160 km/h downhill?06:36
wolfspraulwhatever... :-)06:36
wolfspraulfor my fpgatools, I am already staying away from all trademarks, and of course all copyrightable sources06:36
wolfspraulthe eula just reminded me that the path is correct to also stay away from hooking into or latching onto xdl, par, bitgen or other tools06:37
wolfsprauland we don't need to, I don't06:37
Fallenoufine :)06:37
Fallenoufinishing my breakfast then gotta run to work06:38
Fallenousee you !06:38
wolfspraulhave a nice day06:38
Fallenouthanks you too06:38
GitHub171[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/680a34465d6b664b9c459595ffa9f27282aa0f1612:46
GitHub171[migen/master] flow: refactor scheduling models - Sebastien Bourdeauducq12:46
wolfspraullekernel: I keep running into "edif". Is that a standard file format for low-level gates and wires?13:06
wolfspraulis it any good?13:07
wolfspraulor is edif like a subset of verilog?13:08
lekernelit's a semi standard netlist format13:21
wolfspraulhmm, ok. thanks!13:22
lekernelbtw, how's r4 coming along?13:23
wolfspraulsorry, dinner. moving forward, footprints, boom (sourcing)14:02
lekernelok :)14:11
lekernelhow many are you making?14:11
wolfsprauloh god, if I knew14:15
wolfspraulthere is no demand, we have plenty of M1 in stock14:15
wolfspraulI need to think about it14:15
wolfspraulI definitely want to keep m1 in stock, on sale, and continue to fix bugs and deliver on the promise and be on the lookout for the next thing14:16
wolfspraulbut for sure I will not make a whole bunch of new units now, why? to increase inventory? :-) no point14:16
wolfspraulso let's see14:16
wolfspraulI'm in no rush there, I don't make more m1 so I have a larger pile to look at14:17
lekernelok. and when do we switch to 7/ddr3/simplified board/digital video io?14:19
wpwrakno prototypes ?14:19
wolfspraulone by one, there is no news14:19
wolfspraulof course we should make them, given the work we put in14:19
wolfspraulswitch - asap14:19
wpwrakso what is it then ? "i don't make more" or "we should make them" ? :)14:20
wolfspraulI don't mind just keep moving forward with the tech, but it's a difficult decision to not rip our community apart14:20
wolfspraulI understood sebastien's question as in "a new run of xxx m1"14:20
wolfspraulwhich I see no need for, because we have plenty of m1 in stock14:20
wolfspraulyou are asking about the m1r4 verification/prototype, and my 'upgrade' idea14:21
wpwrakyeah. three digits seems large :)14:21
wolfspraulthere are several things here14:21
wpwrak"board swap" :)14:21
wolfspraul1) fully sellable "retail" boxes in stock14:21
wolfspraul2) boards we make (pcba)14:21
wolfspraul3) sebastien asking about the best way to phase-in -7, ddr3, spi14:21
wolfspraulfor #1, we have 15 or so units in stock, sales are 014:22
wolfspraulso I don't want to add more "for-sale" units, why? for who?14:22
wolfspraulnobody wants them anyway :-)14:22
wolfspraulfor #2, of course we want to verify the work we did14:22
wpwrak#2: good :)14:22
wolfspraulthen it overlaps a little with #3, because there is a tendency to say "since there is no time pressure, let's also add XYZ in now"14:23
wolfspraulbut the decisions are all difficult14:23
wolfspraulno demand, no money, small community that can easily break apart and move into different directions14:23
wolfsprauloh well :-)14:23
wolfspraulif someone had access to some artix7-200, maybe we should just upgrade now :-)14:24
wpwraki don't like the idea of a radically different board too much14:24
wolfspraulbut then there is ddr3, and and14:24
lekernel(artix7) I can ask14:24
wolfspraulyes I understand14:24
wpwraki'd much rather see a proof of concept of the new user interface first14:25
lekernelthe -100 is probably cheaper though, and still twice the size of what we have now14:25
wolfspraullekernel: there will be 3 types initially, -100, -200 and -30014:25
wpwrakand i think we can obtain something of practical use without much hardware development from our side14:25
wolfspraulgiven what I learnt from xilinx pricing, I randomly guess them to be priced at 100 USD / 200 USD / 300 USD14:25
wolfspraulthe -300 is not supported in the webpack version of ISE14:26
wolfspraulthat brings us down to -100 and -20014:26
lekernelI don't care too much about webpack... people who have the nerves to touch the fpga will find a way around the license ...14:26
wpwrak(practical use) i'm particularly worried about having physical pieces on that tablet. while this will certainly look great in art demos, i seriously doubt it'll be liked in the field14:26
wolfspraulfirst I mention it here because it is a fact14:26
wpwrak(physical pieces) so that could pass as a concept study. like car makes make fancy-looking things that will never be produced. but i don't see this as leading towards a product.14:27
wpwraklekernel: i don't think we want to promote piracy :)14:28
lekernelI'm just stating a fact14:29
wpwraklekernel: of course, if wolfgang is successful at reviving llhdl, maybe that would be our salvation ...14:29
wolfspraulno no14:30
wolfspraulI am not reviving llhdl14:30
wpwrakwolfspraul: you're our only hope :)14:30
wolfspraullet's see how much I can focus on this little research project after all14:30
wpwrakwolfspraul: you have motivation and perseverance. you only need to acquire the skills ;-)14:30
lekernelwhat about making a successful product first? then we can focus on geeky little side projects like llhdl ...14:31
rohlekernel: ;)14:42
rohlekernel: i was thinking about exactly that and how to 'use' the components already there and came to the conclusion that we mostly need to think about reducing the featureset per 'application' and make more specialized tools.14:43
rohlike 'a box which does compositing of live video sources' and 'a box for mapping' .. but use the same hardware, just have different 'apps' or 'images' per usecase. the goal would be to make use easier for novices and maybe broaden the userbase that way14:44
kristianpauland the gui !!! remenber it can be a 16 bit cpu but if user interface works...14:44
rohget out of that 'beta, only for hackers' corner14:45
kristianpaulroh: yeah, i like the box idea14:45
rohkristianpaul: i dont think using a 16 compared to a 32bit cpu doesnt matter in the end. i'd stay at what we have and works.14:45
lekernelactually, yes, the "simplified" mainboard could make a nice hdmi mixer ...14:46
lekerneland we also simply DNP HDMI connectors, DDR3 chips, USB, etc.14:47
rohbut first i think we should start at the beginning, and talk to people in the field of 'customers' .. means real vjs, who make a living and ask them aboutn their tools and why they chose them and what they would wish for _exactly_14:47
rohlike 'doing a survey' or 'sampling real-world wishlists'14:47
kristianpaulroh: no no i wast comparing hw, i wanted to re call FIX software issues and improve usabillity14:47
lekernelwell everyone's talking about a hi res video mixer... that one seems pretty clear14:47
kristianpauleveryone's is talking about cloud computing too... ;-)14:48
rohkristianpaul: we would start with usecases which we can realize with the existing m1r3 i guess. and work from there. (atleast i would do)14:48
wpwrakroh: regarding real vjs: would you expect them to be residents who have a fixed installation at their club (for things like milkymist), or rather nomads who carry their own creative equipment14:48
lekernelroh: what would you think of a hdmi mixer?14:48
lekernelsay 3 channels + 1 output14:48
rohlekernel: we need hd video mixing for sure. for mapping as well as for compositing or other stuff ive seen happening14:48
wpwrakroh: also, how large is your sample size ?14:48
lekerneljust simple compositing14:49
lekernel3 faders, one for each source, done14:49
rohwpwrak: berlin creative crowd.. not that big. but mostly they are working with macs and stuff like vvv etc.14:49
kristianpaulroh: me too14:49
rohwpwrak: mapping is very 'in' and does great stuff combined with live video mixing and logo insertions14:49
wpwrakroh: so you say no customers, even for a better/friendlier milkymist ?14:50
lekernelwpwrak: the video mixer can work with their macs14:50
lekerneland I think they really want it14:50
lekerneland it's a first step to get out of the closet14:50
kristianpaulhdmi mixer, duck, ast not for me, but if even that dint work in our current composite inputs... why not have it already working there14:50
rohwpwrak: i think we should first do tools people want already before doing madmen science planning the revolution14:50
rohwpwrak: i think there are customers who could do with the m1r3 hw if we only had software which solves their problem. i just dont know the problems well enough since i'm not a vj.14:53
rohbut i know one and when he comes back from london i will pick his brainz14:54
wpwrakroh: (vjs) so the ones you know, do they have a place where they usually work or do they move around ?14:55
rohwpwrak: both. this specific one is doing it only in one place i guess14:56
rohto be fair: i know more people who do parties and lighting than video projections.14:56
rohdia-beamers and laser-etched metal sheets for masks and such stuff. moving crystals in the path of light.. such stuff14:57
wpwrakroh: okay, so mobility would likely be a requirement14:57
rohwpwrak: for some. but i think there is also a real market for a rack-mountable version.14:57
wpwrakroh: which seems plausible to me, also considering that m1 isn't a very widely known device. so it would be a vj's "special" tool14:57
lekernelroh: I kinda like the "same hardware" idea...14:57
roh19", 1U , all connectors on the back + one usb in front14:58
lekernelbasic board, all connectors on one side14:58
rohlekernel: maybe even split the board in pieces, so we can add/remove/mount differently depending on case and use14:58
lekernelso we can rack mount it... for USB use an "extension cord"14:59
rohso have the fpga board with some hd-flatcable conn. and then io boards for different stuff. so we could e.g. remove a hdmi port and add more midi or usb14:59
lekerneland use the same board in the small video mixer, in the mirteo (with rf sensor board), etc.15:00
rohlekernel: i think for clubs, it would be even reasonable having a box fixed in their gear.15:00
lekernelwhy not mount the hdmi conns directly on the main board? smaller, easier, cheaper.15:00
rohthen it could work as hdmi-passthrough or mixer, add logos of the club.. whatever or even run standalone through some auto-vj program when nobody connected his gear.15:00
rohlekernel: i think for some high-speed io that makes sense.15:01
rohlekernel: but think for example of uses in the audio-world. adding a 'spdif and AES/EBU' board could make it a sound router/mixer15:01
lekernelwell, it should be a different platform then. you don't need a big fpga and 60 gbps of memory bandwidth for audio ...15:02
rohso having one or multiple connectors inside to add more io boards makes lots of sense to me. especially since thatb would make it less expensive to experiment with additional usecases. no new spin of the fpga board needed15:02
lekernelyeh we could do that15:03
lekernelbut I expect those io boards to be rather small...15:03
rohlekernel: hdmi has internal audio. and if you do lots of channels and effects on that. one could synthesize even musical stuff in there15:03
lekernelok, one by one :) writing audio synthesis software isn't easy.15:03
rohsure. maybe only having some adc or level converters, optocouplers, whatever needed for the phy15:03
rohthat means i would also move analog video ins there (when needed) .. only keep a bare minimum of digital ones on the fpga board. means: powersupply, hdmi i/o (2-3) usb, ethernet.15:05
lekernelfor now what I can see is (1) video mixer (2) later, maybe with some features like the m1 has today (3) rackmount versions of those two (4) mirteo15:05
lekernelall sharing a lot of the same infrastructure15:05
lekernelaudio is a different thing15:05
rohlekernel: true. you know 'chameleon'?15:05
rohlots of really expensive hw, and its not sold new anymore. still quite popular on some crowd15:06
lekernelProcessorMotorola DSP56303, 24 bit @ 100 MHz15:06
lekernelInternal MemorySRAM 8 KWords (24 bits per word)15:06
lekernelExternal MemoryDRAM 4 MWords15:06
lekernelyeah, and that's enough :)15:06
rohlekernel: not true. thats really old hw15:07
rohthe important point: there are people doing open source apps for that. but they need some platform to do so on. i would hope to piggyback on that.15:08
lekernelyeah but still ... video stuff is orders of magnitude faster15:08
rohbut you know that that resolutions we do nowadays are only possible because hw got more powerful. same was and is true for audio. more processing power allowed for more and better effects and methods. so i would never say any application will never use 'that much power' ;)15:09
lekernelwell... then yeah, feel free to invite the chameleon people to hack on the next board ;)15:10
roha good synth alone needs loads of samples in ram. ive seen a sampleset of a steinberg piano being in the gigabyte range15:10
lekernelbut that's what? 1Mbit/s?15:11
lekernelthe next board will have 60-70Gbps15:11
lekernel(with all DDR3 chips places)15:11
rohno. it gets downsampled some dimensions after mixing. and you need to be able to play hundreds of channels and mix them. basically i think one would synth a dsp or more into the fpga.15:12
rohalso: think of using one mm not like on chameleon. more like a rack of chameleons in one mm1, including routing inside the box in sw.15:12
rohthat means you need the video out just do display the 'frontpanels' of that one rack15:12
rohfor like a hdmi display ;)15:13
lekernelwouldn't be too hard for someone to add an audio module... if they feel like writing all that software :)15:13
rohi think they would need help getting a dsp inside there, but the 'plugins' doing the effects i think they can do15:14
lekernelso, what would you think of a mainboard that has artix7, a few DDR3 (DNP'able for applications that need less memory bandwidth), 4-5 HDMI connectors (DNPable), USB (DNPable), Ethernet (DNPable), and I/O expansion?15:20
rohhm.. when there would be one of multiple a sata ports on the board one could make it a harddisk-multitrack-recorder15:20
lekernelvia io expansion15:21
lekernelor just footprint/dnpable...15:21
rohlekernel: yeah. sure. (when the io-exp- header can be made so high speed (which i hope))15:21
rohi'm not sure if the fpga could directly drive sata lines of if some driver chip is required15:22
lekerneldirect driving is ok on a715:22
lekernel(all -T FPGAs)15:22
lekernelbut then someone needs to write that gateware, of course.15:22
rohwhat do you think of the hdmi ports. also no drivers needed? ive heard bad stuff when doing this on s6 with long cables15:22
lekernelno drivers needed either15:23
lekernelwe only need an ethernet phy and usb transceivers15:23
rohsure. maybe we can put the switching power onboard also to sink cost?15:24
lekernelwell, yeah, of course15:24
lekerneland nor/spi flash15:24
lekernelspi might free some io and be cheaper...15:24
rohno sdcard slot?15:25
rohspi flash is fscking slow. beware.15:25
lekernelno sdcard... sd is a pain15:26
rohalso sdcard is only fun with some block-cache in ram active15:26
lekernelyeah, need to stop the feature creep at some point :)15:26
rohsd is cheap and could make lots of sense for apps (not the fpga bitstream)15:26
lekernelthere's 4-bit "SPI" which seems reasonably fast15:27
lekernelyes, but we need a flash for the bitstream already. sd adds pure complexity.15:27
rohwell.. that IS what sdcards do15:27
lekernelno, it's not the same protocol15:27
lekernel4-bit "SPI" is much saner15:27
lekerneland you also control what chip is in there, no need to be compatible with all cards15:27
lekernelanyway, SD isn't fast and can sit on the io connector, if someone wants to write software and gateware for it at some point15:28
rohsure. sd is kinda annoying. but its a)dead cheap and b) user replaceable.15:32
rohbut you are right. it can go to the io board. for stuff where it makes sense15:33
rohbut hey.. nice... sounds like a battleplan for the a715:37
lekernelmilkymist modular mainboard? m3? :)15:41
rohm^3 please ;)15:41
roheven if i shouldnt care. real values should make labels unimportant15:43
kristianpaullekernel: what about CF ? also a pain15:58
lekernelnot only a pain, but going to compete with M1 in terms of unpopularity in a few years15:58
lekernelbut if you like CF... you have the I/O connector and a text editor at your disposal15:59
kristianpauli heard that a few years ago :)15:59
kristianpaullekernel: you always so friendly and comunicative ;-)15:59
rohkristianpaul: well, in that case he is surely right. cf is dead16:00
rohalso expensive and less avail.16:00
lekernelI think he was answering my "text editor at your disposal" comment *g*16:01
lekernelI don't know what to do with r4... difficult...16:21
GitHub28[migen] sbourdeauducq pushed 2 new commits to master: https://github.com/milkymist/migen/compare/680a344...1c0f63616:26
GitHub28[migen/master] flow: fix actor repr - Sebastien Bourdeauducq16:26
GitHub28[migen/master] flow: generic parameter passing to Actor from sequential/pipelined - Sebastien Bourdeauducq16:26
wolfspraul[regarding r4] if we want to avoid that milkymist becomes like opencores, we need to make sure that whatever new thing we do reaches all the old folks17:06
wolfspraulotherwise it will becomes like opencores, 100% sure :-)17:06
rohwolfspraul: what do you think about making it modules also in hw?17:48
wolfsprauldon't know, too hypothetical. modules are expensive.17:50
wolfspraulthe trend is towards more integrated and cheaper hw17:50
wolfspraulin fact so cheap that I think the main way to sell hw in the future is via great design and lifestyle/taste, not tech specs17:50
wolfspraulthe 'great design' includes hw+sw, naturally. but only the overall experience to the end user matters, imho17:51
rohwolfspraul: i think you need to differentiate the markets there. its not consumer market. its 'working creatives tools' market.17:52
kristianpaulbut we wan change that  dont you think roh ?17:53
kristianpaulif you could trust time from a copyleft hardware device is a good exaple17:54
rohthe idea of modules is to make everything not essential optional, to make it cheaper to make 'another product' by only needing to make a single, simple board and not respin sth with the expensive parts like the fpga on17:54
kristianpaulroh: do you would trust time from a clock watch you made your self or another floss related project17:55
rohkristianpaul: if i know how good it is supposed to work, yes.17:55
rohusually i trust my norebooks ntp synced clock most. which uses opnesource sw parts to work (ntpd, linux kernel, gnome panel clock)17:56
kristianpaulyou could know but if it dint work no matter what tech specs come with..17:56
rohthats a default for me. things need to work. everything else is secondary.17:56
rohi dont care about techspecs if they dont matter (but they mostly do)17:57
kristianpaullets hope that then17:57
rohmm1 currently can do everything, but its difficult and not easy to sell, make it more specific for multiple usecases and do those better than now, and easy to use.17:58
rohthen it will be also easier to sell. modules was just the idea to seperate the things we share between all 'products' and those specific to make development faster and easier17:59
Fallenoumodularity is - I think - one of the key thing of Arduino's success. The other thing is the IDE which is dead simple to use and the libraries that abstract hardware (AVR) things and makes software dev easy18:24
Fallenoubut modularity surely is one of the key18:24
Fallenouit has allowed the emergence of several hundreds of "shields"18:25
FallenouSo I would say a modular M1, with an easier to use GUI would be a good idea18:25
Fallenoufor instance a patch editor with almost no line of code, all in GUI, with previsualisation etc, dead simple, instant feedback to see what you're doing18:26
Fallenouno line of code <= for the user to write18:26
rohi still hope for no ui, everythin possible via web18:27
Fallenouwe could keep the FNP language, the GUI could be generating the FPN files for instance18:27
Fallenouwell web UI for instance, why not18:27
rohincluding preview18:27
Fallenoujust something dead easy, sexy, and with live visualisation18:27
rohi know somebody who would love to have a 19" box mounted and be able to control the vj hw from time to time remotely18:28
Fallenouor if not "live/instant", at least more easy than compile then run then go back in text editor etc18:28
Fallenouit would be cool to see the patch change while modifying the constants/formulas of the patch - which btw is already what MIDI stuff is doing. And it allows for very awesome demos :)18:28
rohexactly.. have it keep rendering, while preparing another patch in preview on the 'control head'18:30
Fallenouyes for instance18:30
FallenouI was more thinking at the "preview" for the moment when you do the preparation alone at home but it could be during live (but it increases memory bandwidth needs I guess)18:31
Fallenouit's even better like you said :)18:32
rohFallenou: i could even imagine using it for light mixing or sound combined with some input surface (and then use hdmi for control head)18:35
Fallenoulight mixing <= yes sure, using dmx or midi stuff, afaik it's already possible to control dmx spot18:36
Fallenouit could be part of the GUI to generate "patches" without typing a single line of code18:37
lekernelwolfspraul: we can keep some software/gateware in common, but I don't want to be held back by legacy19:17
lekernelespecially when that legacy is such a failure19:18
wpwrakFallenou: (fnp language vs. "visual programming") you normally have to design the language accordingly. the fnp language is fairly specialized and many of its concepts don't translate easily into visual elements19:51
wpwrakFallenou: what you could do is make parametrized patches, written in FNP, controlled by midi (or something providing similar functionality)19:52
wpwrakroh: you may even be able to do without preview. preview is more something we from the "undo generation" get used to19:53
wpwrakmidi is limiting, because we need to translate between the (logical) controls the patch wants and the (physical) controls the midi device provides19:55
wpwrakso a sw surface with virtual controls the patch could request would be an improvement. sort of like the lemur.19:56
rohwpwrak: i am just explaining what i was described as by people who use gear what they really wanted19:57
wpwrakwhen we discussed this concept initially, i though we could integrate some tablet or "raw" touch panel in a future device. integrating a tablet is hairy because they're not designed for this kind of integration19:58
wpwrakthen lekernel brought up the idea of something like the reactable, which is basically a large touch screen, but with complicated additions19:59
rohwpwrak: i still do not believe in doing direct control surfaces. too expensive mechanics, soo specific.20:00
wpwrakthen i came across a short product note in c't about a monitor with touch screen. a web search yielded more. conclusion: there are commercially available touch screens that are nothing but monitor plus touch device. such a thing would be much easier to integrate, mechanically and sw-wise, than a tablet computer20:00
wpwrakroh: hence a table or monitor. that wouldn't be specific. you could do the sw development on a pc.20:02
wpwrakto mechanically integrate it physically with an M1, you would need a frame. you could make that of wood.20:03
wpwrakinterfaces (vga, hdmi, usb) would all be standard20:04
wpwrakdrawbacks: afaik, only large form factors available. high cost due to size and specialization. M1 needs to do a bit more work (i.e., control GUI elements)20:05
wpwrakyou could overcome these drawbacks (trading them for more difficult mechanical and sw integration) with a tablet computer20:05
wpwrakthis is where is see a realistic evolutionary possibility for M1 as a VJ station. the reactable clone is just escapism.20:07
rohwpwrak: well.. when i look at tft and similar hw prices i think its safe to say that staying out of that price downward spiral is a good idea. rather add proper keyboard and usb-midi support and a hdmi display (cheap)20:22
lekernelwpwrak: then the ipad is better20:28
mumptaifor mm2?20:29
lekernelwpwrak: it's neither a reactable clone nor "escapism". it's doing the ui right.20:31
wpwraklekernel: why not use existing hw for the ui ? the tablet idea is good. all the rest may be fun to play with but i see it more as getting in the way than contributing value20:32
lekernelwhich as Fallenou said will include watch the patch change as you touch controls... only you won't need any setup20:33
wpwraklekernel: existing hw would mean m1+touch-capable monitor (like those from llyama) or m1+a tablet computer20:33
lekernelwhy is that idea better than an ipad?20:33
wpwrak(see the patch change) that's independent from what you use as control interface20:34
wpwrakyou mean ipad for effect generation too ?20:34
wpwraklooks nice. but seems to be more mixer than "video synthesizer"20:36
wpwraki like the "broadcast" sequence. that's what i call bold marketing :)20:36
lekernelroh: what expensive mechanics are you talking about?20:44
lekernelthe most complicated mechanics I'm planning to have is something like http://wishidknownthat.blogspot.de/2009/04/fixing-wacom-bamboo-pen.html20:45
lekernellook at what teenage engineering is doing... http://www.youtube.com/watch?v=NwZHfbzcjkw ... all CNC milled aluminum, tons of moving parts, and they're just a few guys20:52
lekernelbeen to their studio a few times when I was in Stockholm ...20:53
mumptaimhmm, anyone like motorfaders?20:57
lekerneldie matlab, die21:21
GitHub77[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/b00e8fa826f14c067b70b630acd72d1d439bd0b821:22
GitHub77[migen/master] examples/fir: plot input and output signals - Sebastien Bourdeauducq21:22
FallenouI hate bugs I cannot reproduce in simulation21:35
Fallenouit's a PITA to fix21:35
Fallenouright now if I do a mapping, mmu_write(addr, value), mmu_read(addr) it won't read back what has just been written21:36
Fallenouon the FPGA at least21:36
Fallenouon ISim it reads back the value21:36
Fallenoulets compare the two assembly code ...21:37
Fallenouoh god, it's a software bug21:41
Action: Fallenou facepalm21:41
wpwrakthe joy of fpgas. so many more possibilities to make mistakes ;-)21:42
FallenouI was just sending incorrect commands through wcsr TLBCTRL21:43
Fallenouwrong bit shift21:43
Fallenouso instead of activating mmu I was disactivating it :)21:43
Fallenoufixed !! \o/21:44
FallenouI was afraid of having to debug for hours this one21:45
Fallenouit turned out to be stupid software bug -_-21:45
Fallenouhttp://pastebin.com/RxE6a8rx \o/21:48
wpwrakvery good ! :)21:50
FallenouI hope the log is understandable21:51
GitHub3[milkymist-mmu] fallen pushed 1 new commit to mmu: http://git.io/ItD6Jw21:54
GitHub3[milkymist-mmu/mmu] Fix a software bug : mmu_read was sending wrong CSR_TLB_CTRL ids thus not enabling the MMU - Yann Sionneau21:54
Fallenoulook how stupid it was :)21:54
Fallenougn8 !21:54
rohlekernel: nice device (the op-1) .. didnt know that one.22:36
rohbut they need to have quite some good mechanical engineer as well as money for the molds22:36
kristianpaulwpwrak: your midi hw is a nice gui :-)23:31
kristianpaulcombined with a real time editor and rendering23:32
--- Fri Jun 8 201200:00

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