Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
<wolfspraul> ok, playing the unsuspecting m1 user...
<wolfspraul> I got a free mouse with a notebook bag I bought over the holidays, tried it on m1, but the mouse moves so fast vertically and very slow horizontally
<wolfspraul> (still on 07-13)
<wolfspraul> I just bought a new rubber keyboard in Media Markt, works in my notebook, doesn't work on m1
<wolfspraul> now... onto the update! :-)
<wpwrak> if you upgrade from july, mice will regress a little and keyboards will get a little better
<wolfspraul> let's see :-)
<wolfspraul> I got 2 new devices (normally I keep a strict set of 'works with m1')
<wolfspraul> plugging both in - both don't work
<wolfspraul> it can't get worse :-)
<wpwrak> excellent :)
<wolfspraul> wow, I just notice the reflash_m1.sh script stands at 389 lines!
lekernel_ [lekernel_!~lekernel@g225032136.adsl.alicedsl.de] has joined #milkymist
<wolfspraul> built urjtag from source (on fedora 16), worked with a few hickups
<wolfspraul> running reflash_m1.sh --release now, suspense...
<wolfspraul> I see some 404 not found errors scrolling by...
<wolfspraul> reflash_m1.sh says 'your m1 was successfully reflashed' even when there are tons of errors before
<wolfspraul> the xc6slx45 was detected, but then "illegal state: Bus missing"
<wolfspraul> and bus driver missing
<wolfspraul> maybe something simple in my urjtag config? checking...
<wpwrak> of course, i'm dodging the difficult part, the selection and downloading of the correct images :)
<wpwrak> but once you've solved that, it's all nice and modular
<wolfspraul> will try, but one sec
<wolfspraul> still at urjtag
<wolfspraul> by default all buses are enabled in the config
<wpwrak> whatever that means :)
<wolfspraul> yeah
<wolfspraul> onto m1nor
<wpwrak> the "bus missing" probably means that you don't have fjmem.bit
<wolfspraul> I don't think so, but ok
<wolfspraul> looking at m1nor it's running the same jtag commands, so I doubt this will work
<wolfspraul> anyway, trying
<wpwrak> m1nor will complain if it can't find fjmem,.bit locally
<wpwrak> if you have fjmem.bit but it's not valid, then strange things will happen :)
<wpwrak> usage: m1nor file ...
<wpwrak> you have to provide all the files you wish to flash
<wolfspraul> gee, yeah :-)
<wpwrak> you can do it one file at a time or several files at a time
<wolfspraul> so the first line would be: m1nor standby.fpg 0x0000 ?
<wpwrak> nope. just standby.fpg
<wpwrak> it knows where to put things
<wpwrak> that is, as long as you use "normal" file names
<wolfspraul> same errors (as expected)
<wolfspraul> illega state, bus missing, bus driver missing
<wpwrak> ah, that's bad then
<wolfspraul> something in urjtag
<wpwrak> anything before that ?
<wolfspraul> slx45 is detected
<wolfspraul> I think it must be some simple problem in urjtag or my system environment
<wolfspraul> which "bus driver" do we need for our jtag-serial pod?
<wpwrak> funny. yes, looks as if urjtag is missing something
Gurty [Gurty!~princess@mtg95-7-78-233-26-36.fbx.proxad.net] has joined #milkymist
<wpwrak> hmm, if i knew ... don't have notes on how i got urtag :(
<wpwrak> oh wait, i do
<wpwrak> this was my build & install process: http://pastebin.com/CaBgsLQb
<wolfspraul> yeah. but it didn't work for me :-)
<wolfspraul> investigating...
<wolfspraul> ah yes, busname is in the command, "fjmem" is the bus
<wpwrak> does help initbus mention fjmem ?
<wpwrak> as in "fjmem FPGA JTAG memory bus driver via USER register, [...]"
<wpwrak> ordering is only almost alphabetical. it would be too easy otherwise :)
<wolfspraul> oh well
<wolfspraul> when you are in the jtag console (just run 'jtag'), then 'cable milkymist', then 'detect' - what output do you see from the 'detect' command?
<wolfspraul> somehow when I do it interactively it just returns without anything
<wolfspraul> and subsequent commands say 'run detect first'
<wolfspraul> it works in the scripts, argh
<wolfspraul> good thing that I don't have to fix C compiler bugs before compiling urjtag before finding fjmem before reflashing before booting
<wpwrak> this is what i get: http://pastebin.com/ZJh1WeaT
<wolfspraul> yeah
<wpwrak> gee. it's a pity that c compiler bugs are so rare these days
<wolfspraul> no idea why I don't get that in interactive mode
<wpwrak> in general, i'd consider urjtag being a bit les chatty a good thing. but in your case ...
<wolfspraul> when I run m1nor or reflash_m1.sh, I see the same output. but when I run it interactively, detect returns without anything :-)
<wolfspraul> go figure
<wpwrak> fwiw, the version i have is commit d00fc335f37dcd4a3254850a41a48aa5740e9cf1
<wpwrak> (Tue Aug 30 02:59:06 2011 +0000)
<wpwrak> (version of urjtag)
<wpwrak> so if you want to see if the past really was better than the present, ... ;)
<wolfspraul> in the debug log I see "FJMEM data register length: 0", wondering whether that's normal
<wpwrak> where'st hat debug log ?
<wolfspraul> found a "debug all" in reflash_m1.sh
<wolfspraul> it's probably a urjtag command
<wolfspraul> ah yes, reglen 0 does not look normal
<wolfspraul> of course that case has no error message in the sources
<wolfspraul> if (fjmem_reg_len <= 0) return NULL;
<wolfspraul> without urj_error_set() as all the other return NULL cases
<wpwrak> zero-length registers ... hmm yes, can exist just for the side effect. but in this case ...
<wpwrak> did you try using the d00fc335f37dcd4a3254850a41a48aa5740e9cf1 version ?
<wolfspraul> not yet. 2am, I'm super sleepy and have ca. 5 hours left to sleep. that has priority now :-)
<wolfspraul> I will try with that commit tomorrow
<wolfspraul> I have my old Debian machine around, one sec
<wolfspraul> that had a working jtag before :-)
<wpwrak> a history of success may help ;-)
<wpwrak> (5 h left to sleep) on a friday night ? weekends are for catching up on all the sleep you missed during the week, no ? :)
<wolfspraul> so reflash_m1.sh definitely gives me 404 for bios-rescue.raw, splash-rescue.raw and splash.raw
<wolfspraul> and the subsequent flashing fails of cours
<wolfspraul> other than that flashing works on my Debian system, phew
<wolfspraul> at least that
<wpwrak> small dents :)
<wolfspraul> guess those 3 files are missing in http://www.milkymist.org/updates/2011-11-29/
<wolfspraul> "lockflash: unknown command"
<wolfspraul> hmm
<wpwrak> oopsie
<wolfspraul> "verify skipped"
<wolfspraul> well
<wpwrak> well, you don;t need it urgently
<wolfspraul> let's reboot!
<wpwrak> verify skipped is normal
<wolfspraul> yes, just for completeness
<wolfspraul> it may be normal but it may distract the unsuspecting newbie
<wolfspraul> unless we tell everybody 'don't worry about a lot of worrisome messages scrolling by' :-)
<wolfspraul> that's all normal
<kristianpaul> for the F16 user please confirm this bug https://bugzilla.redhat.com/show_bug.cgi?id=732291
<kristianpaul> also will be helpfull to build this urjtag https://bugzilla.redhat.com/show_bug.cgi?id=598315
<kristianpaul> to support FEL ;)
<wpwrak> one problem is that urjtag doesn't return all errors. so neither reflash.sh nor m1nor can actually catch problems happening inside urjtag (jtag comand)
<kristianpaul> afai my laptop bios got crazy with F16 and installed the damn xubuntu alpha :/
<wolfspraul> now my m1 suffers from d2/d3 dimly lit :-)
<kristianpaul> *g*
<wolfspraul> need to replug dc a few times...
<wolfspraul> all normal
<kristianpaul> thats souns like my rc2 ;)
* kristianpaul loves fedora bugzilla
<wpwrak> wolfspraul: what revision is it ? rc3 ?
<wolfspraul> I found when I wiggle the power cable a little when inserting, I can make the dimly lit go away
<wpwrak> eek
<wolfspraul> rc2
<kristianpaul> i knew it !
<wpwrak> ah. before my time :)
<wpwrak> rc3 never does "dimly lit" unless the NOR got corrupted
<wolfspraul> yes! it renders!
<wolfspraul> now...
<wolfspraul> first the old mouse
<wpwrak> drum roll ...
<wolfspraul> works
<wpwrak> whee ! no regression :)
<wolfspraul> new mouse: same as before, unusable
<wpwrak> :-(
<wolfspraul> vertical is crazy fast, horizontal very slow
<wolfspraul> plugged into my notebook - all fine
<wpwrak> some mice are odd. not sure yet why. i have one that's slow on x and y. need to find out how linux gets it right.
<wolfspraul> ok, will keep the old one and carry the new one around. probably dump with xiangfu who is collecting all the gear that doesn't work ;-)
<wolfspraul> next, the new keyboard
<wpwrak> how about the keyboard ?
<wpwrak> yeah :)
<wpwrak> from the silence, it probably detonated and left wolfspraul searching for his laptop in a smoke-filled room
<wolfspraul> no no
<wolfspraul> it worked
<wolfspraul> but of course I ran into another problem
<wolfspraul> after switching the gui from 1024x768 to 640x480, my projector couldn't pickup the signal right anymore
<wpwrak> heh :)
<wolfspraul> so the display was shifted (rolling around on top)
<wpwrak> sounds interesting :)
<wolfspraul> turning off the projector didn't help, strange
<wolfspraul> I am rebooting everything now
<wpwrak> did that keyboard work before ?
<wolfspraul> he
<wolfspraul> no it did not!
<wpwrak> if you have a projector that fails to work, that may be VERY useful. that would be the first truly reproducible failyre.
<wolfspraul> after rebooting everything from total power down, the m1 was in rendering mode
<wpwrak> excellent. progress has been achieved ! :)
<wolfspraul> and my projector first picked up the wrong vertical shift again!
<wolfspraul> but after a few seconds, it's back to normal
<wolfspraul> now GUI...
<wolfspraul> yeah, normal in 640x480
<wolfspraul> go figure
<wolfspraul> I can probably reproduce this first going into the GUI at 1024x768 and then switching down to 640x480
<wpwrak> nobody said it would be easy :)
<wolfspraul> but given the number of small issues here and there, that's minor
<wpwrak> well, it may be a lead to fixing the video issues
<wpwrak> alright, now you should be able to use the icreativ. you probably won't need the keyboard. so connect it just there.
<wpwrak> then go to the midi monitor and see if the icreativ is understood
<wolfspraul> my keyboard comes out with a german layout, after full jtag reflashing?
<wolfspraul> is that stored in some place that was not overwritten, or is that our default?
<wpwrak> not sure how much got deleted in the "full reflash"
<wolfspraul> anyway, I'm happy
<wolfspraul> the keyboard works
<wolfspraul> great
<wpwrak> usb keyboards can actually tell you what layout they are :)
<wolfspraul> since my old silicone keyboard broke
<wpwrak> phew :)
<wpwrak> so .. did you try the icreativ ?
<wolfspraul> not yet, really too late
<wolfspraul> I need to fix the problem on fedora, will check kpaul's links tomorrow
<wolfspraul> the new mouse goes to xiangfu's pile
<wolfspraul> new keyboard works - awesome
<wolfspraul> tomorrow I continue with icreativ and the other controllers
<wolfspraul> have to get a midi cable still
<wpwrak> (kbd) let's see how long until i break it again :)
<wolfspraul> oh wait, the usb-midi controllers don't work on m1 yet, do they?
<wpwrak> they should
<wolfspraul> ok
<wolfspraul> I will just plug it together and watch in amazement what happens
<wpwrak> didn't try exhaustively. but it recognized the one i plugged in
<wolfspraul> ok
<wolfspraul> so usb-midi works
<wpwrak> surprisingly well so far, yes
<wpwrak> i'm a little suspicious. if can't be *that* easy. it never is
<wpwrak> s/if/it/
<wolfspraul> I go to sleep happily now. this all worked better than expected.
<wpwrak> despite all the troubles. pessimists have happy lives ;-)
<wolfspraul> optimist, that's why I plug stuff in!
<wolfspraul> let me do a quick check whether I can reproduce the vertical shift problem ;-)
<wolfspraul> no
<wolfspraul> well then
<wolfspraul> rendering in simple mode feels faster than before
<wpwrak> (shift problem) that'll haunt us for a while longer
<wpwrak> (rendering) dunno
<wolfspraul> oops, my m1 just froze
<wpwrak> that's unusual
<wolfspraul> I wouldn't say that, but we haven't done extensive testing on rc2
<wolfspraul> I know of one guy in Stuttgart for sure who says his m1 (rc2) is freezing so often and so fast that it is basically unusable
<wpwrak> naw, in my experience, it rarely freezes nowadays
<wpwrak> aah .. maybe an rc2 issue
<wolfspraul> I have been able to reproduce freezing every few hours with my rc2, and I believe xiangfu had it too
<wolfspraul> just saying
<wpwrak> how do you reproduce it ?
<wolfspraul> it's not a crazy bad problem, and we are fixing bug after bug
<wolfspraul> just let m1 run overnight
<wolfspraul> mine is back rendering now
<wpwrak> nope. that doesn't do anything to my rc3.
<wolfspraul> yes sure
<wolfspraul> I just respond to you saying 'unusual'
<wolfspraul> freezing is not unusual
<wolfspraul> but it's becoming far less common with recent hw & s
<wolfspraul> sw
<wpwrak> >= rc3, there's hope that it is :)
<wolfspraul> kristianpaul: have you seen your m1 freeze?
<wolfspraul> some of those freezes may also have been related to the L3 and L19 discoveries, I am not sure
<wolfspraul> it doesn't matter. we just fix one bug after another, until it's perfect.
<wolfspraul> wow 3am. that is no problem, but alarm at 7.45 am is. calling it a day, n8
<wpwrak> oh, you still have unfixed L3/L19 ?
<wpwrak> ;-))
<wolfspraul> mine should be fixed, I am not sure
<wpwrak> sweet (and quick) dreams :)
<wolfspraul> we have tried to apply these fixes whereever possible, at every opportunity
<wpwrak> heh :)
<wpwrak> at some point in time, you may just retire all the rc<old> you can get a hold of
<wolfspraul> or offer upgrade, sure
<wolfspraul> that's already happening actually
<wolfspraul> I have bought back (!) several rc2, and upgraded to rc3
<wpwrak> kewl :)
<wolfspraul> I think Adam has published a hardware upgrade guide in the wiki
<wolfspraul> one rc2 was donated back to me
<wolfspraul> I will try to upgrade it to rc3 and make best use of it, maybe as review unit or so
<wpwrak> i kinda doubt anyone will use that upgrade path. but it's nice to be there, just as a symbol :)
<wolfspraul> so that is definitely happening, sure
<wpwrak> well, anyone but adam himself
<kristianpaul> wolfspraul: yes
<wolfspraul> wpwrak: here's for 'unusual'
<wpwrak> rc2 :)
<wolfspraul> I thought there was more somewhere
<wolfspraul> look at that :-)
<wpwrak> L3/L19 should only matter when you connect things
<wolfspraul> an easy 23 steps
<wolfspraul> with pictures!
<wolfspraul> anybody can do it
<wpwrak> nothing there explains random freezes. kinda odd.
<wpwrak> yeah, right :)
<wpwrak> maybe it's the reset circuit. or whatever was there in rc2.
<wolfspraul> I wouldn't say 'random' freezes
<wolfspraul> just too little time and energy was spent in tracking them down, finding patterns etc.
<wolfspraul> they just mostly (all?) went away with the various fixes in hw and sw
<wpwrak> heh :)
<wolfspraul> i'm really out now, my m1 rc2 renders overnight, we see... n8
<wpwrak> in rc3, i only know of the NOR corruption, generally "dead" systems (catastrophic breakdown, like the flux thing), and then the rtems queue corruption
Technicus [Technicus!~Technicus@24-196-36-61.dhcp.stpt.wi.charter.com] has joined #milkymist
cocoadaemon [cocoadaemon!~cocoadaem@2a01:e35:8a99:e90:20d:93ff:fe3b:868c] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #milkymist
<lekernel_> wpwrak: even with that overengineered and stupid protocol, most USB keyboards won't tell you their layout.
<lekernel_> I've heard the reason is that adding a programmable part to store the layout would increase the cost compared to a mass-produced keyboard PCB that "works" with all layouts
<GitHub100> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/7b395b565e57f5ee2116e11ef99a9c2574ac5d6b
<GitHub100> [migen/master] verilog: split comb block, use assign statements - Sebastien Bourdeauducq
<GitHub193> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/b6763c28ea20faacb77d7c3649f564b58b7738ad
<GitHub193> [migen/master] constant: equality - Sebastien Bourdeauducq
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
wolfspraul [wolfspraul!~wolfsprau@p5B0AEA22.dip.t-dialin.net] has joined #milkymist
<wpwrak> lekernel: (layout) oh, that's disappointing ;-(
<wpwrak> wolfspraul: did you try usb-midi yet ?
wolfspraul [wolfspraul!~wolfsprau@p5B0AEA22.dip.t-dialin.net] has joined #milkymist
aeris- [aeris-!~aerith@home.aerith.fr] has joined #milkymist
<GitHub103> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/cdd9977a40be0160ada60b70d1f0e8d1ac51052a
<GitHub103> [migen/master] fhdl: better signal naming heuristic - Sebastien Bourdeauducq
<wolfspraul> wpwrak: not yet
<wolfspraul> m1 was rendering fine overnight btw
whitequark [whitequark!~whitequar@2a00:ab00:1::4464:5550] has joined #milkymist
<whitequark> can anyone answer a few questions about milkymist build process?
<wpwrak> possibly :)
<wolfspraul> whitequark: welcome to #milkymist
<whitequark> there are some references to Lattice IP cores
<whitequark> they are not present in Xilinx environment, are they?
<kristianpaul> it depends if you mean build process for sinthesys, so yes
<kristianpaul> there is one order, let see
<kristianpaul> ngdbuild
<kristianpaul> map
<kristianpaul> par
<kristianpaul> and bitstream generation, bitgen
<wpwrak> whitequark: you probably need lekernel for a definite answer. i don't see us enabling IROM anywhere. (would probably be in boards/milkymist-one/rtl/lm32_include.v)
<kristianpaul> indeed
<kristianpaul> and yes,lattice ofer a full set of propietary IP cores for making a soc as well
<kristianpaul> of course we just use the lm32 core :)
<kristianpaul> also fyi and think you alreadt noticed the jtag part for lm32 was adapted to sparnta-6, plus thre is a debug rom written by mwalle and lekernel
<whitequark> aha, thanks
<whitequark> I'll look into it more closely
<whitequark> that question was from a friend of mine
<whitequark> he has ported lattice IP cores to use Xilinx library
<whitequark> *changed reference
<whitequark> you got the idea.
<kristianpaul> yes
<kristianpaul> you friend got a M1 too? :)
<whitequark> nope
<whitequark> just several Xilinx boards
<whitequark> he didn't even knew about m1 until a few days from now
<kristianpaul> cool!
<kristianpaul> did you showed yours in action?
<whitequark> I don't have an M1 (yet) :)
<kristianpaul> still traveling??
<kristianpaul> i mean shipping?
<whitequark> no, I didn't bought it yet
<kristianpaul> ah xD
<whitequark> I think I should make everything work in simulator
<kristianpaul> i imagined !
<whitequark> because it's the way fpgas are debugged anyway
<kristianpaul> well, you still need the silicon
<kristianpaul> but yeah, a testbench can be veryhandy..
<whitequark> (plus I've recently relocated and, for example, I still need a proper work table...)
<kristianpaul> just is icarus could run a lm32 core... as it is
<whitequark> wolfspraul convinced me to try making an MMU for lm32
<whitequark> I don't need silicon for that
<kristianpaul> indeed
<kristianpaul> about mmu, where it goes in milkymist?
<kristianpaul> because still the FML, so the mmu will be a master core for the conbus?
<kristianpaul> the TLB is mandatory?
<kristianpaul> ah yes
<kristianpaul> what does mean that the cache is tagged?
<kristianpaul> also this means there is a limit about the number of process can use mmu?
<whitequark> kristianpaul: I don't know a lot about MMUs and caches, but I know a bit :)
<whitequark> I can recommend you a book, "See MIPS Run Linux"
<whitequark> I didn't know anything about caches back when I read it, and it was quite easy to understand, unlike some other material on the topic
<kristianpaul> ahh that book !
<whitequark> even the most stupid MMUs, like those in MIPS, do not limit the number of processes
<whitequark> actually, they are not like mmus found in Intel chips
<kristianpaul> what about arm?
<whitequark> hm
<kristianpaul> or sparc?
<whitequark> I don't know a lot about ARM ones, but I've read about them. ARM ones (at least for Cortex-m3) are slightly more advanced than MIPS ones, but they're still very simple
<whitequark> and I don't know anything about sparc
<wpwrak> so what sort of MMU architecture are you aiming for ? MIPS R4000-like ?
<wpwrak> i.e., virtual cache with physical tags. MMU running in parallel to the cache
<wpwrak> or a physical cache, MMU between cache and RAM, like MIPS R2000/3000 ?
<whitequark> and the answer is: I do not know yet. I'm not proficient enough in LM32 arch.
<wpwrak> okay. not sure it depends a lot on LM32, though
<whitequark> maybe
<whitequark> I try to not make preliminary decisiona
<whitequark> *decisions
kristianpaul [kristianpaul!~kristianp@unaffiliated/kristianpaul] has quit [#milkymist]
<larsc> there is a discussion about the MMU topic in the MM ML archive
<whitequark> I'll read it
<wolfspraul> I updated keyboard and mice information a little, and will ask xiangfu to retest and document the stuff he has as well... http://en.qi-hardware.com/wiki/Milkymist_One_accessories#keyboard
<wolfspraul> in keyboards, there may be a few more that already work today
<wolfspraul> I'm in the patch editor, and can't get out. there is some text, and when I move the mouse, it's always in selection mode
<wolfspraul> cannot press the close button in the top left corner, nor any other button. it's always moving the selection
<wolfspraul> already tried all sorts of pressing and unplugging/replugging action, no way out yet...
<wolfspraul> somehow it release the selection mode :-)
<wolfspraul> released. was able to close the window
<lekernel> whitequark: we're indeed not using the IROM, but in every case, this proprietary memory description can be easily replaced (as I did for the caches)
<whitequark> lekernel: okay, got it
<wpwrak> wolfspraul: hmm, may be slight report-misinterpretation. or a low battery :)
<whitequark> why they need an explicit memory description at all? Xilinx does a good job guessing it from my Verilog
<larsc> whitequark: today
<wolfspraul> wpwrak: sorry don't understand? which report? which battery?
<wpwrak> wolfspraul: (report) that protocol used for HID devices. we have a few hardcoded formats but there could be a lot more variations.
<wpwrak> (battery) if the mouse is battery-powered. sometimes, they start acting funny when low on power
<wolfspraul> not battery powered afaik. totally regular cheap high-volume mouse
<wolfspraul> free give-away with a notebook bag
<wolfspraul> the vertical resolution seems 10* faster than the horizontal one. other than that the behavior is quite stable.
<wolfspraul> it's mostly unusable though because the super sensitive vertical means that you first have to scroll scroll scroll to get the horizontal right, and then the vertical very carefully. unusable.
<wolfspraul> not very important for me right now, I have another one that works
<whitequark> larsc: today ?
<larsc> whitequark: today the tools do a good job at guessing the memory type
Gurty [Gurty!~princess@mtg95-7-78-233-26-36.fbx.proxad.net] has joined #milkymist
<lekernel> warning: 600-euro registration fee, including (and especially) if you speak. the joys of academia ...
<lekernel> I wonder how strongly they enforce this, though - I've crashed a few times into expensive academic conferences without paying them a cent, and no one said anything
<wpwrak> oslo in summer is nice
<wpwrak> booze is expensive, though. maybe that's where the price tag comes from :)
<lekernel> phew, most academic conferences have > 300E registration fees
<lekernel> it's within the "normal" range
<lekernel> they had FPL2011 in Greece, with 420E "early registration" fee
<wpwrak> EUR 600 seems a bit high. don't remember how much they were in my days of conference hopping, but i think i would remember anything > EUR 400. so adding inflation, EUR 600 is still high.
<wpwrak> maybe it depends on the sector and FPGA folks are known to be wealthy ;-)
<lekernel> it's quite funny how this kind of stuff varies widely depending on the conference
<lekernel> academic conference: you pay expensive registration, travel, accommodation, food
<lekernel> security conference: you don't pay any entrace fee, and they often cover travel, accommodation and/or food, and sometimes you even get a speaker fee on top of that
<wpwrak> yes, but the non-speakers pay for you :)
<lekernel> yes, of course
<wpwrak> see, at the academic conferences, you're one of the customers
<wpwrak> you go there because you need a conference and publication for your curriculum
<lekernel> oh, and I forgot that in the case of the academic conference, they make you sign off your copyright (for free) and sell your paper later on
<lekernel> this stuff is crazy
<wpwrak> why do fat cats like fat cat business ? :-)
<wpwrak> but don't worry, open access will kill them
<lekernel> that's why I have absolutely no moral issue with crashing in and not giving them a cent
* whitequark has memorized that.
<larsc> lekernel: do you tell them you left your ticket at home or do the just don't check the ticket?
<lekernel> they don't check
<lekernel> in many conferences, they just have a registration desk somewhere, which you simply ignore and walk past :)
<lekernel> in extreme cases, attendes even pick up their badge themselves on a table ...
<larsc> hehe
<lekernel> btw, there's also http://www.fpgaworld.com/ which is free (sponsored by exhibitors)
<lekernel> there's even free food from Synopsys
<lekernel> it's more MVC friendly ;)
<larsc> and it is in munich :)
<larsc> or at least was last year
<lekernel> yeah, and I have some friends in Stockholm too :)
cocoadaemon [cocoadaemon!~cocoadaem@2a01:e35:8a99:e90:20d:93ff:fe3b:868c] has joined #milkymist
<GitHub58> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/34c69db14aced5ce010666b3b1e538d967a9fe3e
<GitHub58> [migen/master] endpoint: add _i/_o suffix on signal names - Sebastien Bourdeauducq
<larsc> btw. anybody going to fosdem this year?
<bkero> I am