Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
<kristianpaul> nice urjtag is moving https://bugzilla.redhat.com/show_bug.cgi?id=598315
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
wolfspraul [wolfspraul!~wolfsprau@p5B0AB30F.dip.t-dialin.net] has joined #milkymist
lekernel_ [lekernel_!~lekernel@g225034006.adsl.alicedsl.de] has joined #milkymist
proppy [proppy!u1692@gateway/web/irccloud.com/x-nylyjrkynppmsrto] has joined #milkymist
Technicus [Technicus!~Technicus@24-196-36-61.dhcp.stpt.wi.charter.com] has joined #milkymist
sameeg [sameeg!~leduc@APuteaux-153-1-55-24.w82-124.abo.wanadoo.fr] has joined #milkymist
kyak [kyak!~kyak@95-27-54-212.broadband.corbina.ru] has joined #milkymist
kyak [kyak!~kyak@unaffiliated/kyak] has joined #milkymist
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
Scopeuk_ [Scopeuk_!~scopeukfr@li187-253.members.linode.com] has joined #milkymist
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
rejon [rejon!~rejon@221.221.173.124] has joined #milkymist
elldekaa [elldekaa!~hyviquel@vpn3.enssat.univ-rennes1.fr] has joined #milkymist
rejon_ [rejon_!~rejon@li382-141.members.linode.com] has joined #milkymist
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
<wolfspraul> wpwrak: wow, nice led testing!
<wolfspraul> do you think the led under the ir receiver could impact ir performance?
azonenberg [azonenberg!~azonenber@cpe-67-246-33-188.nycap.res.rr.com] has joined #milkymist
<lekernel_> migen logo => http://lekernel.net/migen.svg
<lekernel_> larsc: the same type can be shared under some conditions
<lekernel_> first, it must be "stateless", ie the content of the output token only depends on the input token that caused it
<lekernel_> then, there are scheduling restrictions
<lekernel_> pipeline and comb actors can always be time shared
<lekernel_> for dynamic schedules, there are two cases we can deal with:
<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.
<lekernel_> 2) it generates the output tokens out of order, then we need to implement some standardized mechanism for tagging tokens
<lekernel_> (which the actor needs to be fully aware of)
<lekernel> larsc: 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.
<Fallenou> nice logo
<larsc> lekernel: so same type is same class instanciated with the same parameters
<larsc> ?
<lekernel> yes
<lekernel> and yes, we do not have a mechanism for that atm
<lekernel> either 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 lists
<lekernel> the second option is probably more flexible
<lekernel> the "promotion" rules can probably be part of this protocol, too
<lekernel> eg have a method "is_compatible_with" which tests if the current object can also do the work of the one passed as parameter
<larsc> yes, that's what i was thinking of, too
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
elldekaa [elldekaa!~hyviquel@vpn3.enssat.univ-rennes1.fr] has joined #milkymist
elldekaa [elldekaa!~hyviquel@vpn3.enssat.univ-rennes1.fr] has joined #milkymist
<wpwrak> wolfspraul: (led testing) leds make for pretty pictures :)
<wpwrak> wolfspraul: (IR) i don't think it should. but lemme check ...
<wolfspraul> because it's so close, who knows what effects may be in place so close to the led source
<wpwrak> probably 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 nm
<wpwrak> so there are about 40 nm between them
<wpwrak> the 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)
<wpwrak> plus, they're far from each other's peak emission/sensitivity angles. so that gives you another factor of 10-100.
<lekernel> the IR receiver is supposed to filter "DC" light, so as long as you don't saturate it, it should be fine
<wolfspraul> alright, I just thought I ask
<wpwrak> our light would be modulated. but yes, it would be outside the range of the modulation filter, too
<wpwrak> some 3 dB more ;-)
<wpwrak> we 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.
wolfspraul [wolfspraul!~wolfsprau@p5B0AB3BE.dip.t-dialin.net] has joined #milkymist
<wolfspraul> can I use urjtag commands while the m1 is running/rendering ?
<wolfspraul> so far I always had it in standby mode, but now that the standby mode is gone it boots to rendering right away
<lekernel> yes, you can
<wolfspraul> yes we can - great, thanks!
<wolfspraul> will try in a bit ;-)
azonenberg [azonenberg!~azonenber@cpe-67-246-33-188.nycap.res.rr.com] has joined #milkymist
antgreen [antgreen!~user@70.50.65.59] has joined #milkymist
<wolfspraul> lekernel: here's a small license detail we could improve
<wolfspraul> since 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 sources
<wolfspraul> that'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.
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
<juliusb> what's the license ont eh latticemico stuff?
<lekernel> BSD like, but there's some US export restriction related crap in it
<juliusb> not bad, two typos in that sentence
<juliusb> (mine, not yours)
<juliusb> oh yeah
<juliusb> so i'm about to release a new openrisc implementation
<juliusb> nice little thing, much smaller, faster than or1200
<lekernel> ha
<lekernel> as fast as LM32?
<juliusb> not sure yet
<juliusb> but I'll be sure to check it out
<juliusb> in fact, I think someone already is
<juliusb> but the goal of this new processor project will be to have interchangable pipelines
<juliusb> along the lines of the nios stuff, choice between synthesisable speed and area
<wolfspraul> lekernel: did you read about the idea of adding a LatticeMico exception to the GPL sources?
<wolfspraul> basically 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 granted
<wolfspraul> that would clarify the status quo to newcomers
<lekernel> it'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...
<lekernel> wolfspraul: yes, I read it
<juliusb> yep, well, I don't fuck around
<stekern> that "someone" juliusb is talking about ought to be me ;)
<wolfspraul> stekern: hey, right :-) how's your m1 hacking? :-)
<lekernel> juliusb: by the way, does that new OR CPU have a MMU?
<lekernel> and a decent one, not like that of or1200 *g*
* kristianpaul wonder if a MMU can be decent anyway *g*
<lekernel> kristianpaul: what we discussed for the LM32 would be pretty good
<stekern> wolfspraul: it's going on well, it might be a bit orthogonal to the project objectives at the moment, but I'm tinkering
<kristianpaul> good then :)
<wolfspraul> lekernel: before it gets forgotten - what do you think about the GPL exception idea then?
<lekernel> wolfspraul: I'm not against it, will think about doing it if we have more FPGA developers someday
<juliusb> lekernel: no, because I'm not really interested in running Linux, but if people want it, it shouldn't be too hard to add one
<wolfspraul> he :-)
<kristianpaul> hmm?
<juliusb> and 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?
<juliusb> anyone of you guys going to FOSDEM, btw?
<kristianpaul> MMU, if it works for you no rush i bet, juliusb ;)
<kristianpaul> picky Linux ;)
* kristianpaul hides
<juliusb> well who wants to run Linux on some small slow CPU? It's a nice advertisement but what real work are you going to do?
<lekernel> wolfspraul: and maybe we'll switch to OR anyway (if juliusb writes an implementation at least as good as LM32)
<juliusb> i think RTOSes are the perfect thing for that class of processor
<kristianpaul> switch? oh wow !
<juliusb> well, the "embedded" RTOSes
<kristianpaul> just wait you need decent usb support
<juliusb> if 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 processors
<lekernel> kristianpaul: 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.
<juliusb> yes, 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 else
<lekernel> and anything technically better is eligible, no matter where it comes from
<juliusb> so every day there's another RTOS/microkernel popping up
* kristianpaul will try some cpu beside lm32 someday..
<juliusb> and as a result, none relaly gets to the point where they have dedicated people developing useful things up the stack like USB and networking drivers
<juliusb> anyway, so no one heading to Brussels for FOSDEM and lots of beer this year?
<juliusb> (all my comments about RTOSes pertain to open source ones, btw, there's plenty of very nice commerical ones AFAIK)
<lekernel> not this year... I'm already using my travel "budget" for a 1-month trip to the US
<juliusb> oh nice
<lekernel> by the way RTEMS has USB and networking
<lekernel> both ported from BSD
<lekernel> it's not great, but it's ok
<lekernel> what sort of load does Linux context switching put on a CPU by the way?
<kristianpaul> this USB RTEMS is used on FN, or you talk directly to the softusb core?
<lekernel> why would it be slower than, say, RTEMS context switching?
<juliusb> lekernel: 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 accelleration
<lekernel> yes, but that's basically the sort of things I meant when I said OpenRISC was slow :-)
<juliusb> you have all of your virtual memory management
<lekernel> I got SSH to work quite easily on LM32 for example
<lekernel> (nommu though)
<lekernel> that was on a 100MHz CPU running on the ML401
<kristianpaul> you ran quake too isnt?
<lekernel> I ran doom, yes
<kristianpaul> or some this quake-like games
<kristianpaul> yes
<juliusb> Well, 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 SoC
<juliusb> but that's quite cool, that you got it to work
<juliusb> I 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 kernel
<lekernel> how fast can you clock your OR CPU atm?
<lekernel> and on what fpga?
<juliusb> hey 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?
<lekernel> no, he was working for Lattice, but he no longer does and no longer takes care of much LM32 related code
<juliusb> lekernel: good question, depending on your pipline configuration, I think we got around 100Mhz
<lekernel> on what fpga?
<lekernel> it's not bad, considering all the OR1200's I have seen were 30MHz or less :-)
<juliusb> mmm by itself on Virtex 5 I got over 100 in various configurations
<juliusb> but I think like 80MHz on spartan 6
<juliusb> stekern might be able to tell you more
<kristianpaul> what RTOS does it support?
<juliusb> ah right, he was a Lattice guy huh? Pity he doesn't play more with the open source community
<juliusb> kristianpaul: I haven't really run much other than some verification and bootloader software on it
<kristianpaul> how big in LUTs is it?
<juliusb> again, it depends a LOT on what features you enable
<juliusb> I think I'll do some demo synthesis runs and put a table up when it's released
<juliusb> to answer all questions
<kristianpaul> k
<stekern> the comparisons I've done on m1 shows: area: about the same as lm32 speed: a bit slower, but with clear critical paths
<juliusb> or1k has some architectural disadvantages compared to lm32, delay slots for one, making implementation more annoying
<juliusb> I'm also not a fan of OR1K's special purpose register arrangement
<juliusb> but whatever, at some point I'll be pushing to roll out some updates or a new or architecture
<juliusb> s/updates/updates to the current/
<lekernel> stekern: did you measure that speed from the clock frequency, or using some benchmark software running on the cpu?
<lekernel> juliusb: then remove those delay slots? that's the point of a softcore CPU, no? :)
<lekernel> (but yes, of course, you'll crawl in RMS-related niceties later, unless you use LLVM which is a tad better)
<stekern> lekernel: that's just clock frequency
<kristianpaul> juliusb: how fast in ASIC it can be?
<kristianpaul> oh, has a FPU
<lekernel> what 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"?
<kristianpaul> dunno just reading (firs time :) its wiki page :)
<stekern> I 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 soon
<stekern> no FPU
<wolfspraul> lekernel: 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 codes
<wolfspraul> because if not, every user of the Milkymist SoC would be running unlicensed software
<wolfspraul> the only question is how formally we make that statement, whether casually here in chat, or with a well-written exception in the sources
<wolfspraul> so if we don't want to do that formally right now, I consider it done casually
<wolfspraul> otherwise the entire Milkymist SoC becomes something that cannot be used in its entirety legally by anyone but lekernel :-)
<wolfspraul> I don't personally believe that the GPL licensed parts are incompatible with the Lattice parts, and it will never be proven in court anyway
<wolfspraul> the FSF won't do us the favor of checking for compatibility
<wolfspraul> so it's down to lekernel stating in some way that they are compatible...
togi [togi!~yur@c83-250-142-73.bredband.comhem.se] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
* kristianpaul realices that there is more open-sorce IP stuffcoming from lattice besides lm32
kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #milkymist
<wpwrak> wolfspraul: 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)
<wolfspraul> we are only discussing lekernel sources at this moment
<wolfspraul> the few snippets that have been contributed by others were already under a BSD-like license I believe
<lekernel> aah, those Germans ;-)
<wpwrak> sure. but it's generally a good idea to settle such things as early as possible
<lekernel> yes, of course, my code can be used with LM32
<wolfspraul> and honestly, I consider this exception either granted or irrelevant, otherwise the entire Milkymist SoC would be unlicensed
<wolfspraul> there you go, done :-)
<wolfspraul> that's the GPL exception, right here...
<wolfspraul> lekernel: thanks!
<lekernel> writing it properly requires updating the headers in source, which I'm not really bothered about doing
<wolfspraul> totally fine by me
togi [togi!~yur@c83-250-142-73.bredband.comhem.se] has joined #milkymist
<juliusb> kristianpaul: 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 ;)
<wolfspraul> test in simulation or test in silicon?
<juliusb> simulation, I don't think I could sneak a processor onto a tapeout
<juliusb> anyway wolfspraul I want to ask why you guys put GPL licenses on all of your HDL?
<juliusb> I think it's ludicrous
<juliusb> that GPL stuff is explicitly for software
<wolfspraul> I 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 values
<wolfspraul> that's we as in 'me', others need to speak for themselves if they care to do so
<juliusb> ok cool, that makes sense
<juliusb> I'm on a bit of campaign to try and get open source hardware a) properly licensed and b) used more in industry
<wolfspraul> great
<juliusb> so i put together a weak copyleft license based on the Mozilla MPL2
<wolfspraul> hope you feel Milkymist and Qi are already where you think they should be
<juliusb> (sorry, superfluous Mozilla there)
<wolfspraul> I'm personally becoming more of a public domain guy lately
<wolfspraul> but I code little, and the GPLv3 is still a great way to communicate values, I think
<juliusb> yes, 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 speak
<juliusb> that's my thesis, anyway
<kristianpaul> well, for know we dont fab asics, so as it is sofcore and software-like license should be okay
<wolfspraul> the letter? don't understand
<juliusb> I 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 are
<wolfspraul> you mean the GPL is not effective in hardware?
<juliusb> (the letter as in the letter of the law of the GPLv3 and how it applies to HDL)
<wolfspraul> I totally agree with you, but nobody I know is inclined to start a FSF-like organization for hardware
<juliusb> sure, 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 to
<wpwrak> there's much more to it. FSF probably never sees most of the GPL-covered work
<juliusb> my 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 world
<wpwrak> so it also provides a reference. for licensing terms and their interpretation.
<juliusb> yes, true, they are an influential institution in this regard
<wpwrak> also, you can have organizations like gpl-violations.org that defend the license (using the copyright / exclusive rights of individual authors)
<wpwrak> in practice, that means a copyright assignment / assignment of exclusive rights to gpl-violations.org, though. so it's similar to how the FSF works.
<kristianpaul> gpl violations in asic will be fun, we'll need azonenberg skills :)
<juliusb> well, 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 them
<juliusb> all 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 alternatives
<juliusb> I 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 now
<wpwrak> yeah. and industry acceptance also means better access to funding
<juliusb> that too, once there's more appreciation of it
<juliusb> anyway, 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 :)
<juliusb> but I reckon it's something which needs to be addressed
<wpwrak> yeah. it may be one of those things that everybody agrees should be done, yet nobody feels motivated and/or comfortable doing :)
<larsc> juliusb: i had similar thoughts recently. everybody comes up with their own peripheral cores, because it is cheaper than licencing it
<larsc> and i think for trivial cores open-source implementations will hopefully become the norm, because everything else is not sustainable
<roh> larsc: nice theory. i like it
<wpwrak> hopefully also for not so trivial ones :)
<roh> would 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)
<roh> too bad there seem to be no arm cores fully using those
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
krispaul [krispaul!~krispaul@2001:0:53aa:64c:2893:3a08:4163:121f] has joined #milkymist
<Fallenou> To follow mmu project : https://github.com/fallen/milkymist-mmu (I've forked the official git repo) branch mmu (the default one)
<Fallenou> do not try to synthetise it's just a start of a draft
<lekernel> juliusb: HDL is software, no?
<lekernel> juliusb: 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.
<Fallenou> by strong copyleft you mean they must share their modifications ?
<wpwrak> HDL is ... tricky ;-) sw ? hw ? the industry just calls it "IP", which is about as good as "uh, some sort of stuff"
<lekernel> Fallenou: yes
<lekernel> wpwrak: it's just the same problem as a bootloader you'd put into a mask ROM
<lekernel> both are software
<wpwrak> apart 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 ?
<wpwrak> with "meaningful" = clearly distinguishing it from a physical circuit ("hardware") and stuff written in C/assembler/etc. ("software")
<kristianpaul> IP always scares me
<wpwrak> yeah. IP sort of implies a threat. "my territory ! go away ! trespassers will be sued !"
wpwrak [wpwrak!~werner@94-163-231-201.fibertel.com.ar] has joined #milkymist
<wpwrak> oops. so much for my clever plan to just restart fvwm to let it pick up the changed screen geometry :-(
<wpwrak> (without losing the rest of the X session)
<Fallenou> "a programming language that describes the behaviour of a chip"
<Fallenou> it has programming language in it, it let you think about sw
<Fallenou> at least makes me think about it
<lekernel> wpwrak: gateware?
<wpwrak> so .. what would be a nice short word for "a program that describes the behaviour of a chip" ?
<wpwrak> not bad ...
<Fallenou> ahah nice :)
<wpwrak> easy to be misheard/misread as "gateway", but that's a risk to expect with any new term
<kristianpaul> but is not a program is a model
<kristianpaul> i think
<kristianpaul> or presentation
<wpwrak> well, the difference is blurred
<kristianpaul> s/presentantion/representation
<wpwrak> e.g., think of declarative langues like prolog
<wpwrak> langUAGes
<wpwrak> and with a simulator, the HDL does get executed pretty much like any "normal" program
sameeg [sameeg!~leduc@APuteaux-153-1-55-24.w82-124.abo.wanadoo.fr] has joined #milkymist
azonenberg [azonenberg!~azonenber@cpe-67-246-33-188.nycap.res.rr.com] has joined #milkymist
kristianpaul [kristianpaul!~kristianp@cl-498.udi-01.br.sixxs.net] has joined #milkymist
kristianpaul [kristianpaul!~kristianp@unaffiliated/kristianpaul] has joined #milkymist
proppy [proppy!u1692@gateway/web/irccloud.com/x-emgcfvguewsvypin] has joined #milkymist
sameeg [sameeg!~leduc@APuteaux-153-1-55-24.w82-124.abo.wanadoo.fr] has joined #milkymist
<wolfspraul> kristianpaul: btw, I've solved my urjtag problems on Fedora by running jtag inside a Debian kvm, works beautifully
<wolfspraul> that 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 :-)
<wpwrak> pragmatism rules ;-)
<wpwrak> lekernel: 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"