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

kristianpaulnice urjtag is moving https://bugzilla.redhat.com/show_bug.cgi?id=59831502:38
wolfspraulwpwrak: wow, nice led testing!09:24
wolfsprauldo you think the led under the ir receiver could impact ir performance?09:30
lekernel_migen logo => http://lekernel.net/migen.svg10:09
lekernel_larsc: the same type can be shared under some conditions10:09
lekernel_first, it must be "stateless", ie the content of the output token only depends on the input token that caused it10:10
lekernel_then, there are scheduling restrictions10:10
lekernel_pipeline and comb actors can always be time shared10:11
lekernel_for dynamic schedules, there are two cases we can deal with:10:11
lekernel_1) it generates the output tokens in the same order as the input tokens, in this case all we need to provide is the maximum number of tokens that can be "inside" the actor so that an appropriately sized tracking circuit can be generated. if that number is exceeded at runtime, it should stall, not fail.10:13
lekernel_2) it generates the output tokens out of order, then we need to implement some standardized mechanism for tagging tokens10:13
lekernel_(which the actor needs to be fully aware of)10:13
lekernellarsc: also, we can imagine some rule system for sharing actors with different types. for example, a divider for 32-bit integers can also handle 31-bit integers.10:17
Fallenounice logo10:17
larsclekernel: so same type is same class instanciated with the same parameters10:24
lekerneland yes, we do not have a mechanism for that atm10:26
lekerneleither switch the DFG nodes to "actor descriptions", e.g. actor class + parameters and let the composite actor do the instantiations, or implement some protocol in Actor for handling relevant parameter lists10:29
lekernelthe second option is probably more flexible10:29
lekernelthe "promotion" rules can probably be part of this protocol, too10:34
lekerneleg have a method "is_compatible_with" which tests if the current object can also do the work of the one passed as parameter10:35
larscyes, that's what i was thinking of, too10:40
wpwrakwolfspraul: (led testing) leds make for pretty pictures :)13:14
wpwrakwolfspraul: (IR) i don't think it should. but lemme check ...13:15
wolfspraulbecause it's so close, who knows what effects may be in place so close to the led source13:19
wpwrakprobably none :) the LED's emission spectrum drops to zero around 710 nm, according to the data sheet. the IR receiver's sensitivity hits zero around 750 nm13:22
wpwrakso there are about 40 nm between them13:23
wpwrakthe LED could also emit thermal photons (long-wave IR), but the IR receiver wouldn't pick up these either (well, except in the form of thermal noise)13:25
wpwrakplus, they're far from each other's peak emission/sensitivity angles. so that gives you another factor of 10-100.13:26
lekernelthe IR receiver is supposed to filter "DC" light, so as long as you don't saturate it, it should be fine13:27
wolfspraulalright, I just thought I ask13:27
wpwrakour light would be modulated. but yes, it would be outside the range of the modulation filter, too13:28
wpwraksome 3 dB more ;-)13:29
wpwrakwe can test it to be sure: place a LED such that it shines directly on the IR receiver. then see what range an IR remote gets with the LED off. then turn on the LED and see if it makes much of a difference.13:31
wolfspraulcan I use urjtag commands while the m1 is running/rendering ?14:31
wolfspraulso far I always had it in standby mode, but now that the standby mode is gone it boots to rendering right away14:31
lekernelyes, you can14:33
wolfspraulyes we can - great, thanks!14:34
wolfspraulwill try in a bit ;-)14:35
wolfspraullekernel: here's a small license detail we could improve15:32
wolfspraulsince you are the author of most/all of the GPL licensed SoC source files, you could add a GPL exception that allows usage together with the LatticeMico sources15:33
wolfspraulthat's only 1 line for you, and it would eliminate problems of GPL incompatibility. even though they are hypothetical, by adding this exception you would make everything very clear in advance.15:34
juliusbwhat's the license ont eh latticemico stuff?17:23
lekernelBSD like, but there's some US export restriction related crap in it17:24
juliusbnot bad, two typos in that sentence17:24
juliusb(mine, not yours)17:24
juliusboh yeah17:24
juliusbso i'm about to release a new openrisc implementation17:24
juliusbnice little thing, much smaller, faster than or120017:24
lekernelas fast as LM32?17:24
juliusbnot sure yet17:24
juliusbbut I'll be sure to check it out17:25
juliusbin fact, I think someone already is17:25
juliusbbut the goal of this new processor project will be to have interchangable pipelines17:25
juliusbalong the lines of the nios stuff, choice between synthesisable speed and area17:25
wolfspraullekernel: did you read about the idea of adding a LatticeMico exception to the GPL sources?17:26
wolfspraulbasically just saying in addition to the freedoms the GPL grants, the freedom to link/use together with any sources licensed under LatticeMico Open Source license is granted17:26
wolfspraulthat would clarify the status quo to newcomers17:27
lekernelit'd already be an achievement if that CPU simply worked with an acceptable performance and area and without major bugs. this stuff is crucially lacking in the open source cores...17:27
lekernelwolfspraul: yes, I read it17:27
juliusbyep, well, I don't fuck around17:28
stekernthat "someone" juliusb is talking about ought to be me ;)17:28
wolfspraulstekern: hey, right :-) how's your m1 hacking? :-)17:29
lekerneljuliusb: by the way, does that new OR CPU have a MMU?17:29
lekerneland a decent one, not like that of or1200 *g*17:29
Action: kristianpaul wonder if a MMU can be decent anyway *g*17:30
lekernelkristianpaul: what we discussed for the LM32 would be pretty good17:30
stekernwolfspraul: it's going on well, it might be a bit orthogonal to the project objectives at the moment, but I'm tinkering17:31
kristianpaulgood then :)17:31
wolfspraullekernel: before it gets forgotten - what do you think about the GPL exception idea then?17:31
lekernelwolfspraul: I'm not against it, will think about doing it if we have more FPGA developers someday17:31
juliusblekernel: no, because I'm not really interested in running Linux, but if people want it, it shouldn't be too hard to add one17:32
wolfspraulhe :-)17:32
juliusband in fact there's nothing wrong with the one in the or1200, it's some RAMs, as you would expect, I don't understand why it's not decent in your books?17:33
juliusbanyone of you guys going to FOSDEM, btw?17:33
kristianpaulMMU, if it works for you no rush i bet, juliusb ;)17:34
kristianpaulpicky Linux ;)17:34
Action: kristianpaul hides17:34
juliusbwell who wants to run Linux on some small slow CPU? It's a nice advertisement but what real work are you going to do?17:35
lekernelwolfspraul: and maybe we'll switch to OR anyway (if juliusb writes an implementation at least as good as LM32)17:35
juliusbi think RTOSes are the perfect thing for that class of processor17:35
kristianpaulswitch? oh wow !17:35
juliusbwell, the "embedded" RTOSes17:35
kristianpauljust wait you need decent usb support17:36
juliusbif you're not sitting there spending most of your cycles context switching and have some MIPs left to do work, Linux might be useful, but largely I'm not interested in running it on such small processors17:36
lekernelkristianpaul: it's do-ocracy here, things are judged mainly by their technical merits. I'm not using OR1200 because it's a slow, buggy and bloated piece of crap, that's all.17:36
juliusbyes, true, my understanding of the embedded RTOS space is that it's pretty fragmented and no one project really has all of the features to attract everyone else17:37
lekerneland anything technically better is eligible, no matter where it comes from17:37
juliusbso every day there's another RTOS/microkernel popping up17:37
Action: kristianpaul will try some cpu beside lm32 someday..17:37
juliusband as a result, none relaly gets to the point where they have dedicated people developing useful things up the stack like USB and networking drivers17:38
juliusbanyway, so no one heading to Brussels for FOSDEM and lots of beer this year?17:38
juliusb(all my comments about RTOSes pertain to open source ones, btw, there's plenty of very nice commerical ones AFAIK)17:39
lekernelnot this year... I'm already using my travel "budget" for a 1-month trip to the US17:40
juliusboh nice17:41
lekernelby the way RTEMS has USB and networking17:42
lekernelboth ported from BSD17:42
lekernelit's not great, but it's ok17:42
lekernelwhat sort of load does Linux context switching put on a CPU by the way?17:43
kristianpaulthis USB RTEMS is used on FN, or you talk directly to the softusb core?17:43
lekernelwhy would it be slower than, say, RTEMS context switching?17:43
juliusblekernel: my experience with working with it on OpenRISC is that the overhead of the OS doesn't really leave a whole lot of grunt left to do anything intensive, for instance, I think we never got SSH working because there wasn't enough capacity to do the crypto without any accelleration17:44
lekernelyes, but that's basically the sort of things I meant when I said OpenRISC was slow :-)17:45
juliusbyou have all of your virtual memory management17:45
lekernelI got SSH to work quite easily on LM32 for example17:45
lekernel(nommu though)17:45
lekernelthat was on a 100MHz CPU running on the ML40117:46
kristianpaulyou ran quake too isnt?17:47
lekernelI ran doom, yes17:47
kristianpaulor some this quake-like games17:47
juliusbWell, it's a good question to ask why it struggles so much, I don't think the CPU has a great deal to do with that, more the ISA and kernel port and memory architecture on the SoC17:47
juliusbbut that's quite cool, that you got it to work17:48
juliusbI think our kernel port has received significant improvement since I last used it seriously for anything, so maybe they eliminated some bottlenecks, but until we can clock the thing faster and have more hardware to offload menial processing tasks, I'm not too motivated to boot the Linux kernel17:49
lekernelhow fast can you clock your OR CPU atm?17:50
lekerneland on what fpga?17:50
juliusbhey btw, I've been playing with CGEN lately and noticed some guy Jon Beniston had written a bunch of stuff for the LM32, I was wondering if he's anything to do with the mm project?17:51
lekernelno, he was working for Lattice, but he no longer does and no longer takes care of much LM32 related code17:52
juliusblekernel: good question, depending on your pipline configuration, I think we got around 100Mhz17:52
lekernelon what fpga?17:52
lekernelit's not bad, considering all the OR1200's I have seen were 30MHz or less :-)17:52
juliusbmmm by itself on Virtex 5 I got over 100 in various configurations17:53
juliusbbut I think like 80MHz on spartan 617:53
juliusbstekern might be able to tell you more17:53
kristianpaul what RTOS does it support?17:53
juliusbah right, he was a Lattice guy huh? Pity he doesn't play more with the open source community17:54
juliusbkristianpaul: I haven't really run much other than some verification and bootloader software on it17:54
kristianpaulhow big in LUTs is it?17:55
juliusbagain, it depends a LOT on what features you enable17:55
juliusbI think I'll do some demo synthesis runs and put a table up when it's released17:55
juliusbto answer all questions17:56
stekernthe comparisons I've done on m1 shows: area: about the same as lm32 speed: a bit slower, but with clear critical paths17:56
juliusbor1k has some architectural disadvantages compared to lm32, delay slots for one, making implementation more annoying17:57
juliusbI'm also not a fan of OR1K's special purpose register arrangement17:58
juliusbbut whatever, at some point I'll be pushing to roll out some updates or a new or architecture17:58
juliusbs/updates/updates to the current/17:58
lekernelstekern: did you measure that speed from the clock frequency, or using some benchmark software running on the cpu?18:00
lekerneljuliusb: then remove those delay slots? that's the point of a softcore CPU, no? :)18:01
lekernel(but yes, of course, you'll crawl in RMS-related niceties later, unless you use LLVM which is a tad better)18:01
stekernlekernel: that's just clock frequency18:04
kristianpauljuliusb: how fast in ASIC it can be?18:06
kristianpauloh, has a FPU18:06
lekernelwhat FPU is it? the one from that person who calls it something along the lines of "such a complex (!!) piece of hardware that it cannot (!!!) be pipelined manually"?18:08
kristianpauldunno just reading (firs time :) its wiki page :)18:08
stekernI have merely ran a "hello world" on the m1 soc with it, I've just finished off porting libhpdmc for or1k, so I hope to be able to run something more serious on it soon18:13
stekernno FPU18:15
wolfspraullekernel: we can't delay license clarifications until whenever we like. that's very unattractive to newcomers. our position right now, I would very much hope, is that of course the Milkymist Soc GPL licensed codes can fully be used with the LatticeMico open-source codes18:16
wolfspraulbecause if not, every user of the Milkymist SoC would be running unlicensed software18:16
wolfspraulthe only question is how formally we make that statement, whether casually here in chat, or with a well-written exception in the sources18:16
wolfspraulso if we don't want to do that formally right now, I consider it done casually18:16
wolfspraulotherwise the entire Milkymist SoC becomes something that cannot be used in its entirety legally by anyone but lekernel :-)18:17
wolfspraulI don't personally believe that the GPL licensed parts are incompatible with the Lattice parts, and it will never be proven in court anyway18:18
wolfspraulthe FSF won't do us the favor of checking for compatibility18:18
wolfspraulso it's down to lekernel stating in some way that they are compatible...18:18
Action: kristianpaul realices that there is more open-sorce IP stuffcoming from lattice besides lm3218:30
wpwrakwolfspraul: there's a much worse problem with delaying license clarifications: you also have to get the permission of all people who contributed under the previous license (or exclude their code)18:47
wolfspraulwe are only discussing lekernel sources at this moment18:47
wolfspraulthe few snippets that have been contributed by others were already under a BSD-like license I believe18:48
lekernelaah, those Germans ;-)18:48
wpwraksure. but it's generally a good idea to settle such things as early as possible18:48
lekernelyes, of course, my code can be used with LM3218:48
wolfsprauland honestly, I consider this exception either granted or irrelevant, otherwise the entire Milkymist SoC would be unlicensed18:48
wolfspraulthere you go, done :-)18:48
wolfspraulthat's the GPL exception, right here...18:48
wolfspraullekernel: thanks!18:48
lekernelwriting it properly requires updating the headers in source, which I'm not really bothered about doing18:49
wolfspraultotally fine by me18:49
juliusbkristianpaul: regarding how fast it might be in ASIC, I'm not sure, but I intend on synthesising it for 40nm at some point in the future to test it out ;)19:01
wolfspraultest in simulation or test in silicon?19:02
juliusbsimulation, I don't think I could sneak a processor onto a tapeout19:03
juliusbanyway wolfspraul I want to ask why you guys put GPL licenses on all of your HDL?19:03
juliusbI think it's ludicrous19:03
juliusbthat GPL stuff is explicitly for software19:04
wolfspraulI think in general we are not very legalistic here, so actually we don't care much, we just try to get our *values* across and the GPLv3 seems an easy way to communicate those values19:04
wolfspraulthat's we as in 'me', others need to speak for themselves if they care to do so19:04
juliusbok cool, that makes sense19:04
juliusbI'm on a bit of campaign to try and get open source hardware a) properly licensed and b) used more in industry19:05
juliusbso i put together a weak copyleft license based on the Mozilla MPL219:05
wolfspraulhope you feel Milkymist and Qi are already where you think they should be19:05
juliusb(sorry, superfluous Mozilla there)19:05
wolfspraulI'm personally becoming more of a public domain guy lately19:05
wolfspraulbut I code little, and the GPLv3 is still a great way to communicate values, I think19:06
juliusbyes, the spirit is right, but unfortunately I really don't think the letter is, and we won't see any serious industry participatio until they know their asses are covered, so to speak19:06
juliusbthat's my thesis, anyway19:07
kristianpaulwell, for know we dont fab asics, so as it is sofcore and software-like license should be okay19:07
wolfspraulthe letter? don't understand19:08
juliusbI don't reckon FPGA bitstreams are covered by the language in those GPL licenses and perhaps some extension ought to be put forward to the GNU license people to make sure that they are19:08
wolfspraulyou mean the GPL is not effective in hardware?19:08
juliusb(the letter as in the letter of the law of the GPLv3 and how it applies to HDL)19:09
wolfspraulI totally agree with you, but nobody I know is inclined to start a FSF-like organization for hardware19:09
juliusbsure, but I get the feeling the FSF is mainly there so there's one big monolithic organisation who can step up for the many little-guy developers who have assigned their copyright to the FSF in the hope they will bring licenses infringment cases when they need to19:10
wpwrakthere's much more to it. FSF probably never sees most of the GPL-covered work19:12
juliusbmy argument is for more permissive open source licenses for hardware so you get the industry players active, in which case I think it's a bit different to the many-small-guy scenario of the software world19:12
wpwrakso it also provides a reference. for licensing terms and their interpretation.19:12
juliusbyes, true, they are an influential institution in this regard19:13
wpwrakalso, you can have organizations like gpl-violations.org that defend the license (using the copyright / exclusive rights of individual authors)19:14
wpwrakin practice, that means a copyright assignment / assignment of exclusive rights to gpl-violations.org, though. so it's similar to how the FSF works.19:15
kristianpaulgpl violations in asic will be fun, we'll need azonenberg skills :)19:15
juliusbwell, I'm not sure how we'd enforce the stuff, or if it's critical. My main motivation is to get the near-zero level of industry participation up, and I think one way is by making the licensing issue clearer for them19:18
juliusball these bloody asic design houses paying through the nose for the same crap from the same vendors all the time, with no one stepping up with open source alternatives19:19
juliusbI reckon open source ASIC is actually pretty hard and probably won't become as important as open source is in the software world, but it can for sure play a much greater role than it does now19:20
wpwrakyeah. and industry acceptance also means better access to funding19:20
juliusbthat too, once there's more appreciation of it19:20
juliusbanyway, it's a bit of a project of mine at the moment, all I've done is hacked the MPL2 and written a FAQ and rant on a page :)19:21
juliusbbut I reckon it's something which needs to be addressed19:21
wpwrakyeah. it may be one of those things that everybody agrees should be done, yet nobody feels motivated and/or comfortable doing :)19:23
larscjuliusb: i had similar thoughts recently. everybody comes up with their own peripheral cores, because it is cheaper than licencing it19:50
larscand i think for trivial cores open-source implementations will hopefully become the norm, because everything else is not sustainable19:53
rohlarsc: nice theory. i like it20:32
wpwrakhopefully also for not so trivial ones :)20:33
rohwould mean we can get nice peripherals at some place and not the crud ti etc deliver... i liked the peripherals of atmel (from a programmers pov)20:33
rohtoo bad there seem to be no arm cores fully using those20:33
FallenouTo follow mmu project : https://github.com/fallen/milkymist-mmu (I've forked the official git repo) branch mmu (the default one)21:29
Fallenoudo not try to synthetise it's just a start of a draft21:30
lekerneljuliusb: HDL is software, no?21:31
lekerneljuliusb: and I want strong copyleft and if the proprietary ASIC industry has a problem with that, then either they don't use it or they ask for/buy an alternative license from me. I'm totally fine with both of these options.21:33
Fallenouby strong copyleft you mean they must share their modifications ?21:34
wpwrakHDL is ... tricky ;-) sw ? hw ? the industry just calls it "IP", which is about as good as "uh, some sort of stuff"21:34
lekernelFallenou: yes21:35
lekernelwpwrak: it's just the same problem as a bootloader you'd put into a mask ROM21:36
lekernelboth are software21:36
wpwrakapart from the licensing issues, where I would agree that considering it software is at least a good basis, if not the solution, how to call the HDL in a concise, intuitively clear, and meaningful way ?21:39
wpwrakwith "meaningful" = clearly distinguishing it from a physical circuit ("hardware") and stuff written in C/assembler/etc. ("software")21:40
kristianpaulIP always scares me21:40
wpwrakyeah. IP sort of implies a threat. "my territory ! go away ! trespassers will be sued !"21:41
wpwrakoops. so much for my clever plan to just restart fvwm to let it pick up the changed screen geometry :-(21:42
wpwrak(without losing the rest of the X session)21:42
Fallenou"a programming language that describes the behaviour of a chip"21:44
Fallenouit has programming language in it, it let you think about sw21:44
Fallenouat least makes me think about it21:44
lekernelwpwrak: gateware?21:45
wpwrakso .. what would be a nice short word for "a program that describes the behaviour of a chip" ?21:45
wpwraknot bad ...21:45
Fallenouahah nice :)21:45
wpwrakeasy to be misheard/misread as "gateway", but that's a risk to expect with any new term21:47
kristianpaulbut is not a program is a model21:50
kristianpauli think21:50
kristianpaulor presentation21:51
wpwrakwell, the difference is blurred21:52
wpwrake.g., think of declarative langues like prolog21:53
wpwrakand with a simulator, the HDL does get executed pretty much like any "normal" program21:53
wolfspraulkristianpaul: btw, I've solved my urjtag problems on Fedora by running jtag inside a Debian kvm, works beautifully23:16
wolfspraulthat way I can just wait and hope that one day the problem on fedora will go away, and my jtag binary is a little bigger until then :-)23:16
wpwrakpragmatism rules ;-)23:19
wpwraklekernel: one thing that's not so nice about "gateware" is that gates are also things set up to deny people passage. as in "gated community" or "linux is like a wigwam, no gates, no windows"23:37
--- Wed Jan 25 201200:00

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