#milkymist IRC log for Wednesday, 2012-07-11

cladamwwpwrak, hehe ... tks for fixing the drills image. :-)01:37
wolfspraulgood morning everybody :-)01:38
kristianpaulhi01:39
kristianpaullekernel: also imagine your new memory controller is generated by a script/such, will allow more people to use it without get caught by all migen ;-))02:10
kristianpauldont know havent check, perhaps this still doable right now02:11
kristianpaulfor example nasa, to they use whole soc? or just memory controller?..02:11
kristianpauli hope i make my point and open opinion to you about migen :)02:11
stekerncan't you just use migen to generate the verilog for one core?02:19
kristianpauli guess yes02:20
kristianpaulnot sure for the memory controller part02:20
wolfspraulit seems migen is the thing that will fragment milkymist into a bunch of buggy 1-person projects :-)02:21
wolfspraulsoon we are ready for inclusion in opencores, all parts :-)02:21
Action: kristianpaul dont want that...02:22
wolfspraulmaybe that's not a bad thing, and we can also find more things to use/reuse from opencores...02:22
kristianpaul+1 for reuse02:22
wolfspraulmore or less everybody will patch up his own system in different ways anyway then02:22
wpwrakyeah, irrespective of technical merit, i see that risk with migen, too02:23
kristianpaulpatch up is good, if a solid base is agreed02:41
kristianpauland maintained02:44
wpwrakcladamw: regarding the review, i haven't forgotten :)02:47
cladamwwpwrak, aha ... thanks you. take your time though. :-)02:48
wpwrakcladamw: making the proper catalogs for all the items is taking a bit more time than i thought. and i've been "away" for a while for that led torch project. sorry about that.02:49
wpwrakcladamw: i hope i'll catch up with the cataloging tools in the next days. then the reviews should be relatively straightforward.02:50
wpwrakunless there are surprises, of course :)02:50
cladamwwpwrak, no problem. no sorry. :-)02:50
stekernI think I just discovered a bug in the lm32 llvm backend, byval function arguments aren't handled correctly02:50
stekernthey are just passed by reference, but not copied to the stack of the caller function02:52
cladamw(led torch) wpwrak sounds you kept working improvements from previous one?02:52
wolfspraulwhat's the *real* status of llvm btw?02:52
wolfspraulfor lm32/milkymist02:52
wolfspraulmy understanding is there are 2 compilers, gcc and llvm02:52
wolfspraulgcc is buggy but maybe or maybe not some people are fixing those bugs?02:52
wolfsprauland we seem to be using that compiler? or is 'we' only a very small number of people anyway?02:53
wolfspraulI never used it :-)02:53
wolfspraulthen there is llvm, which has 'some' degree of lm32 support?02:53
wolfspraulhow many people are using that?02:53
wpwrakstekern: "byval" that would be pretty much all function arguments ?02:53
wolfspraulif one of the two is better, shouldn't we focus on that and then make it work well?02:54
wolfspraulit seems we have two buggy and not really loved compilers02:54
wpwraki don't dislike gcc. on the other hand, i'm suspicious about llvm :)02:55
stekernwpwrak: yes, but in LLVM IR "byval" is used to mark that (for example) a pointer parameter really should be passed by value02:55
stekerns/(for example)/02:55
wolfspraulwe probably have 2-3 people that are actively using gcc for lm3202:55
wolfsprauland how many for llvm? 1? 2?02:55
wpwrakfor all the lm32-independent stuff, one has to work with gcc pretty much all of the time anyway02:56
wpwrakstekern: ah, i see. so it's just an llvmism ?02:56
wpwrakstekern: i.e., if i pass a struct, nothing evil will happen ?02:57
stekernif you pass it as a non-pointer, evil might happen02:58
wpwrakcladamw: previous one ? i mean this critter: http://downloads.qi-hardware.com/people/werner/tmp/antorcha-proto1.jpg02:58
wpwrakstekern: sounds nasty then02:59
kristianpaulwhat on !, wpwrak have you a video of this thing working? (antorcha)03:00
cladamwwpwrak, (RF-antorcha) nice !03:01
kristianpaulyeah03:01
wpwrakkristianpaul: unfortunately not. just still images. http://www.almesberger.net/misc/ant/proto2.jpg http://www.almesberger.net/misc/ant/edd1.jpg03:02
wpwrakcladamw: recycled atben ;-)03:02
stekernlet me show an example: http://pastebin.com/uimYKNFy03:02
kristianpaulwpwrak: getting ready para la marcha ;)03:02
wpwrakkristianpaul: yup :)03:03
wolfspraulhe, www.milkymist.org/fpgatools still points to 404 errors :-)03:04
wpwrakstekern: and you'd get the same if f0 writes to s ...03:04
stekernI've got the same bug in the openrisc backend, I'll merge the change into lm32 when I've fixed it03:05
stekernwpwrak: well, it's with -O003:05
wolfspraulstekern: have you been using llvm for lm32?03:05
stekernwpwrak: for a reference, this is the output from gcc: http://pastebin.com/esBuLwEn03:06
wpwrakstekern: all i need to see is the memcpy, which looks very appropriate there ;-)03:08
stekernwolfspraul: I wouldn't call it "using", but since I'm working on the openrisc backend and their ISAs are pretty similar, I've took a peek or two at it03:08
stekernwpwrak: yes, that's what missing in the llvm/clang output ;)03:09
wolfspraulmaybe we should delete the milkymist soc v1 sources to accelerate migen/-ng adoption?03:12
wpwrakthe dark force is strong in this one03:13
wolfspra1lbtw, I think I hit a little roadblock with fpgatools03:48
wolfspra1lthe routing is a real maze03:48
wolfspra1lso I will go one step back, and work on a model of the chip (rather the routes) in C first03:49
wpwrakthat's what routing is about :003:49
wolfspra1lthat model will create a memory-representation of the routing which I will verify by dumping it into an svg03:49
wolfspra1lnot sure where this is going but I need something visual and something with more logic as can be expressed in C03:49
wolfspra1lsince I am flooded with papers here and wild drawings :-)03:50
wolfspra1lprinted papers :-)03:50
wolfspra1lthat's reached an end03:50
wpwraksome amount of backtracking is to be expected in that line of work ;)03:56
Fallenou05:19 < wolfspraul> maybe we should delete the milkymist soc v1 sources to accelerate migen/-ng adoption? < wow I don't think that's necessary :)06:42
Fallenouwolfspra1l: we all used a lot lm32 gcc, to compile lm32-linux, rtems, flickernoise06:42
Fallenouwolfspra1l: I think at some point Milkymist bios was compiled with clang (llvm)06:43
Fallenouand then with gcc and maybe back with clang I don't know06:43
wolfspra1lwhich of the two compilers do you like better?06:43
Fallenouand from now on I think lekernel is using clang only for -ng bios06:43
Fallenouwolfspra1l: I have no experience with clang :/06:43
Fallenousorry06:43
wolfspra1lfeels like another fragmentation to me06:44
FallenouI would say from a religious point of view I would prefer a working clang/llvm than a working gcc06:44
wolfspra1lbut I have used neither myself, so I may just not know06:44
wolfspra1lcan we build the entire m1 image with clang/llvm or are lots of things missing?06:44
Fallenoubut gcc is a "strong" project. it existed for years06:44
Fallenouso I kind of trust this one06:45
Fallenoubut it would be great if we could replace it with clang :)06:45
Fallenoulinux people are trying to replace gcc with clang too06:45
FallenouBSD people too06:45
Fallenoupkg-src too06:45
Fallenougotta run to the office, bbl06:46
wolfspra1lsure if clang/llvm really works and can fully replace gcc, that sounds great06:47
wolfspra1lbut until proven otherwise, I will assume it doesn't :-)06:47
larscguilty until proven innocent?06:56
wolfspra1lyep07:00
wolfspra1ldefendant has to prove innocence himself07:00
lekernelwolfspra1l: the -ng bios and the firmware (including lua, freetype, yaffs, etc.) compiles with clang07:22
stekernI'd say clang really works and can fully replace gcc if you don't rely to heavily on some gcc attributes (most of those are "hackaroundable" though), I don't know how the situation is for the lm32 parts though07:23
lekernelkristianpaul: yes, you can generate only one core with migen07:25
lekernelthere are few disadvantages to using it... except that people don't look at it and still comment negatively07:25
lekernela bit the same with clang, heh07:26
lekernelwolfspra1l: and sorry, but soc is almost a 1-person project already. also, the main contribs were the on-chip debugger (which stays in verilog in -ng), some USB stuff (likely, will also stay in verilog), and some C firmware (which are not affected by migen or even clang).07:35
Jiamay I ask if I keep working on lm32-gcc is OK?07:37
wolfspra1lyou said you would send a fix :-) did you do that?07:38
Jiawolfspra1l: I've summit a patch to gcc-patches :-)07:38
wolfspra1lgreat07:38
Jiaand cc to lekernel07:38
wolfspra1lwhat's the effect of it?07:38
lekernelJia: I prefer clang/llvm, but anything that makes software run better on lm32 is good.07:38
wolfspra1ldoes 4.6/7/later work now?07:39
wolfspra1lc++ also?07:39
Jiawolfspra1l: the libgcc bug, 4.8 trunk work now.07:39
wolfspra1lmaybe xiangfu should try to build the entire m1 image with that?07:39
lekernelJia: have you compiled and tested software with that?07:39
Jiawolfspra1l: C++ not yet.07:39
wolfspra1lI don't want to break down "compiler works" into this or that little library or bios or what not - can't handle that07:39
JiaOK, I'll try.07:40
wolfspra1lso either it works completely (better than before), or not at all07:40
wolfspra1lxiangfu: you there?07:40
xiangfuyes07:40
wolfspra1lmaybe you can try the latest gcc 4.8 with jia's fixes and see how much works?07:40
wolfspra1land let's include C++ in the test right away07:40
xiangfuok07:41
wolfspra1lJia: what's wrong with C++? can we continue with that?07:41
Jiawolfspra1l: I didn't know C++ has problem, if you need, I'll keep working on it.07:42
wolfspra1ldefinitely we 'need' that :-)07:42
lekernelxiangfu: sent you the patch07:42
Jiaand, how can I work on lm32-clang?07:42
wolfspra1lis more like dying in the desert without water type of need07:42
lekernelJia: you can try compiling the linux kernel... it's a good way to tickle clang/llvm bugs and problems07:43
xiangfulekernel, thanks. got that email.07:43
wolfspra1lnobody will take a platform seriously where all the core devs together (whatever they may be focused on) cannot fix a C++ compiler bug for years07:43
JiaI'll try to catch your step.07:43
wolfspra1leven Itanium probably has more life in it :-)07:43
wolfspra1land no, I stay away from C++ as much as possible07:44
lekernelwolfspra1l: I guess there are lots of C++ haters here ;)07:44
wolfspra1lbut our inability to fix that kind of bug looks bad for the platform07:44
lekernelbtw C++ support in clang is pretty encouraging07:44
wolfspra1lthat's besides the point, I think c++ is a horrible disaster, nightmare07:44
lekernelalso objective-c07:44
wolfspra1lbut the fact that 'we' cannot fix that type of bug in the entire platform for years is quite telling to an outsider07:44
Jiagobjc is very old, and to die :-)07:45
wolfspra1lso if Jia slowly gets up to speed, maybe he can fix that as well :-)07:45
Fallenou09:46 < lekernel> Jia: I prefer clang/llvm, but anything that makes software run better on lm32 is good. < +4207:45
wolfspra1lthat would be awesome07:45
wolfspra1lof course ideally we want both gcc *and* llvm to work fully and completely and out of the box for everything07:45
wolfspra1lI also still write letters to santa claus07:45
lekerneloh cmon07:45
wolfspra1l:-)07:46
wolfspra1lI'll add perfect gcc and llvm support on the next one :-)07:46
wolfspra1lJia: thanks for your support!07:46
Jiawolfspra1l: my pleasure07:47
wolfspra1llet's see how far xiangfu gets with that latest compiler07:47
wolfspra1lI want to see that it really works, and reflash my m1 with the result07:47
Action: Fallenou is back07:49
Action: xiangfu update local gcc now. then try to patch, compile , compile..07:50
Jialekernel: if I wanna working on llvm/clang, should I clone the git repo and...?07:50
xiangfuJia, your patch is base on latest 'master' branch of gcc. right? just for double make sure.07:51
lekernelJia: https://github.com/milkymist/milkymist-ng/blob/master/README#L2407:51
Jiaxiangfu: yes, master07:51
lekernelJia: thanks for your gcc/llvm work!07:51
Jiawolfspra1l: lekernel xiangfu thank you all offer me a chance :)07:52
Jiaxiangfu: is it ok?08:14
lekernelxiangfu: let me know how the testing goes. if it works, i'll commit Jia's patch into gcc.08:15
lekernelJia: guess it's still building ;)08:15
xiangfuJia, not that fast.08:15
Action: Jia hope it is OK.08:15
xiangfulekernel, yes.08:15
Jiawhere can I find lm32 cpu verilog code, verdi, golden and so on?08:16
lekernelverdi/golden??08:17
lekernelJia: https://github.com/milkymist/milkymist-ng/tree/master/verilog/lm3208:17
Jialekernel: thank you! is there a verification env?08:18
lekernelfor lm32? no08:20
lekernelI suppose Lattice has one, but they did not publish it08:21
JiaOK, if I can make lm32 one of our core, I'll push them working on it.08:21
lekernelyou can also try emailing Lattice :) response far from guaranteed though08:22
Jiais Lattice down? I googled lm32, and it is a TI product now.08:23
lekernelJia: http://www.latticesemi.com/products/designsoftware/micodevelopmenttools/index.cfm?source=topnav08:26
wolfspra1lwe need a plan how everybody can and will switch to -ng08:30
FallenouI am willing to contribute to help porting things from M1 SoC in plain verilog to migen style -ng08:34
Fallenoubut my main focus remains MMU08:35
wolfspra1lwow great! (willing to contribute)08:36
wolfspra1lI should probably kick myself more in shape too, but so busy on the fpgatools right now08:36
wolfspra1lthe important thing is to have 1 unified message to the outside world, i.e. newcomers08:36
wolfspra1land not 5 people all saying different things, that's horrible08:37
FallenouI really want the -ng soc on M1 product08:37
wolfspra1lso the starting point should be -ng, and then we somehow need a path from -ng to the legacy stuff or rather devices like m108:37
Fallenou(and not just on M1 board)08:37
wolfspra1lexactly08:37
wolfspra1lwe need a conclusive answer for that, we cannot just have multiple people go in different directions etc.08:37
wolfspra1lif we do that, nobody from outside will join this chaos08:37
wolfspra1lunderstandably08:38
wolfspra1lso the starting point should be -ng, and then it needs to support the old/current stuff08:39
wolfspra1lsince sebastien said there are ways to keep regular verilog through migen, maybe it's all quite simple, I don't know08:39
wolfspra1lon the other hand he said some cores may not be easily translatable, oh well. we shall find out...08:39
Fallenouas far as I understand video input core will have to be re-written in python-migen08:39
FallenouI will try to do/help on this part08:39
Fallenou(Milkymist One part of Sebastien email of the 11 june 2012)08:40
Fallenouwolfspra1l: he said plain verilog can be kept, except for cores that are doing DMA on FML bus (like video input core)08:41
wolfspra1lI always just read the 'except' or 'but' or 'only' parts of such statements :-)08:45
Fallenouhehe08:45
GitHub171[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/eed8fa374d876d89e23a2db760ae92ad002e8bfa10:09
GitHub171[migen/master] fhdl/arrays: use correct BV for intermediate signals - Sebastien Bourdeauducq10:09
xiangfuJia10:10
Action: xiangfu network is slow. will send email after test the gcc patch.10:11
Action: xiangfu switch gcc from svn to git. so re-download it . now 48%10:11
Jiaxiangfu: ?11:54
xiangfuJia, I am compile the gcc with yoru patch now.11:55
Jiagot11:56
xiangfuThe latest master branch cannot compile.12:12
xiangfuI am switch to 'ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120708/'12:12
xiangfua Snapshot  from gcc mailing list12:12
xiangfufailed with compile lib-gcc12:16
xiangfufailed with itself.12:16
JiaI did test it.12:17
xiangfuJia, I am using a 64bit system.12:19
xiangfuconfigure gcc with:12:20
xiangfu~~~~12:20
xiangfu          ../gcc-$(GCC_CORE_VERSION)/configure --target=lm32-rtems4.11 \12:20
xiangfu          --with-gnu-as --with-gnu-ld --with-newlib --verbose \12:20
xiangfu          --enable-threads --enable-languages="c" --disable-shared \12:20
xiangfu          --prefix=$(RTEMS_PREFIX)12:20
xiangfu~~~~12:20
xiangfuit have error when compile latest gcc12:20
xiangfuI compile base on 'trunk@189422' 'b1cd4fdd3fd08fb5096c1310ee8add05331ed7b6'12:21
xiangfuI am switching to 'gcc-4.8-20120708' now.12:21
JiaI'm working on 64bits system too12:22
Jiaand I've send you the script12:22
Jialm32-elf-gcc12:22
Jiaexport PATH=$PATH:$PREFIX/bin12:25
Jiagcc and binutils have the same PREFIX12:25
Jia  --prefix=${PREFIX} --target=${CROSS_TARGET} \12:25
Jia  --enable-interwork --disable-multilib --enable-languages=c --with-newlib \12:25
Jia  --disable-nls --disable-shared --disable-threads --with-gnu-as --with-gnu-ld \12:26
Jia  --without-headers --disable-libquadmath --disable-libssp12:26
wolfspraulif possible try pasting longer scripts or error logs via pastebin etc.12:26
Jiahttp://paste.ubuntu.com/1086095/12:27
wolfspraulperfect12:27
wolfspraulthanks!12:27
Jiano thanks:) and I hope it is ok12:27
xiangfuJia, I would advise we working on this one 'https://github.com/milkymist/scripts/blob/master/compile-lm32-rtems/Makefile'12:43
xiangfuJia, merge your script file to this Makefile. add another target, like: make gcc-trunk12:43
JiaI'll try12:47
kristianpauldid my email about 5bit csr support arrive?14:06
wpwrakkristianpaul: the one with the patch ?14:09
wpwrakkristianpaul: or a reply to sebastien's one line rejection of the 1000+ lines patch ? :)14:09
kristianpaullol yeah, just got email this morning14:12
kristianpaulwpwrak: 1000+ lines is bad?14:16
Jiawolfspraul: sorry, newlib make failed.14:17
wpwrakfor harcoded constants, yes. you could have made it a parameter.14:17
Fallenoukristianpaul: does your patch have a downside ?14:19
FallenouI mean increasing the csr id width14:19
kristianpaula bit more routing i guess14:19
Fallenoudoes it decrease something else ?14:19
kristianpauldont think so, or not realized yet14:19
kristianpaulanyway i just wanted to be there, my early atempt was even more mesier :)14:20
lekernelthe increased resource usage should be minimal14:20
lekernelbut (a) this needs testing against regressions (small mistakes can easily slip through in such code) (b) the preferred way for customized SoCs is to use -ng14:21
kristianpaultesting yes14:21
kristianpaulbut is your prefered way lekernel14:21
lekernelseriously, adding a core to the system including DMA and such is 2-3 lines instead of a big mess14:21
kristianpaulyes..14:21
lekernelI can't see how you'd defend the old method14:22
kristianpaulI dont14:22
kristianpaula parser we need :)14:22
kristianpaulor small tools as wpwrak quoted yday14:22
lekernelmigen is a small tool14:22
lekernelif you only use the bus interconnect generator it's what? 1.5k lines?14:24
wpwrakwhat's not nice about migen is that it acts as a portal instead of a tool. to use migen, you have to do things "inside" migen. you can't just have your regular verilog and call migen when there's something tricky to do14:24
lekernelwell you can - it's just that it's not done this way14:25
lekernelso this criticism should be for milkymist-ng, not migen :)14:26
kristianpaulexactly !, tought i will get confused and think are the same14:26
lekernelhow would you like it to be?14:26
lekerneland what advantage would it have?14:27
wpwrakthe (for the user) nicest but hardest to implement way would be an enhancement of the verilog language. so you'd preprocess regular verilog and only respond to specific migen constructs/directives.14:30
wpwraknow, perhaps that can be done without having to actually parse verilog14:30
wpwrake.g., if the task can be reduced to inserting blocks of things at specific places, you could simple have directives that do this.14:31
wpwrakor maybe have a mixture - parse the parts of verilog you have to, leave the rest alone14:31
lekernelgenerally, it can't be reduced to inserting blocks at specific places14:32
wpwrakthe things migen does that need a language like python could then live either in separate files or be inlined. e.g., the whole memory bus system could probably be abstracted to a point where you'd have a "memory bus generator" that then makes the bits and pieces14:32
wpwrakfor naming ? or does it also have to transform operations ?14:33
lekernelthe dataflow system does some transforms, yes14:33
lekernelalso there are things like generic components that export abstract CSRs14:34
lekerneland the CSRs from those components can be combined into the CSR area of a peripherals14:35
lekernelone example is the generic interrupt controller that cores can include and map in their CSR area14:35
wpwrakand you can't just break the abstract CSRs down to pieces you insert at the right places ?14:36
lekernel??14:36
lekernellike #include ?14:36
lekernelthis makes it uglier, not nicer14:37
wpwrakwell, think of it as #include for now14:37
wpwrakor maybe #include(param, ...) :)14:37
wpwrakwe can worry about making it pretty later :)14:38
lekernelthe current way to do it is call get_registers() on the interrupt controller object, which returns the list of abstract registers, and concatenate it with own registers and pass the result to the CSR interface generator14:38
lekernelthis is much clearer I think than macros14:39
wpwrakmaybe you could express this as a set of migen "modules" you request somewhere early in the verilog ? then you add the respective include directives (or maybe have your parser find the corresponding places automatically)14:40
lekernelbut why should it be based on verilog? I don't think it's such a better language than python...14:40
lekernelhere you can even call into python libraries e.g. to pre compute DSP coefficients14:41
wpwrakit's one of the languages people who do this sort of things are most likely to know14:41
lekernelor even read C include files and retrieve the address at which peripherals should be mapped14:41
wpwrakand if they run into trouble, they have to fall back to verilog anyway14:41
lekernelnot much more than they have to fall back to netlist when using verilog ...14:42
kristianpaullanguge not at all, perhaps a easy to read config file is a good start too14:47
wpwrakfor DSP coefficient, in C you would do this simply by running a script/program that writes a file you can #include. people don't even bother to write C-with-Python-or-whatever-overlay preprocessors for tasks like this.14:49
kristianpaulwpwrak: could bison for example parse config files ans generate verilog from that?14:49
lekernelok, but it's easier to do when you already have that system14:50
kristianpauli havent  never used bison, just thinking...14:50
wpwrakkristianpaul: bison generates C. but you can generate pretty much any parser that makes sense (*) with bison. and then your parser does whatever you want your parser to do :)14:51
lekernelkristianpaul: I recommend you try writing a simple wishbone slave core using verilog (since you like it that much), and add it in -ng. then we talk.14:51
kristianpaulwhy you insist on -ng ..14:51
wpwrak(*) it reaches its limits with ambiguous grammars. e.g., where you only find out late that a previous parsing decision was wrong.14:52
kristianpauland yes i have some slace core in my gps branch14:52
lekernelkristianpaul: because, among many other things, your 1000-line patch would be reduced to about 2 lines :)14:52
kristianpaulof course your atitude is not open to suguestions anyway ng will be another one person project..14:52
lekernelI'm open to suggestions, but only after people have tried the stuff they are commenting on14:53
kristianpaulso why you insist on -ng so much? lets wait other year then anothe repo will be deleted from history?14:54
kristianpaulwell14:54
lekernelnot just a vague "it's over engineering", especially right after sending a messy patch that exemplifies how one problem is better solved with migen14:54
FallenouI think you are too hard on migen14:55
wpwrakyou have a point there ;-)14:55
kristianpaulyeah14:55
wpwrakbut my first reaction wouldn't have been "migen" but "parameters" ;-)14:55
FallenouI find it really cool so far, but my opinion does not weight much since I have almost never used it14:55
FallenouI used it to generate the the soc.v I am using for my MMU simulations14:56
Fallenouand it worked fine14:56
Fallenoubut indeed the kristianpaul patch is a really good example of what happens without migen : thousand lines for a simple change14:57
lekernelwpwrak: well, to be honest, VHDL would have solved it (with packages) as well14:57
Fallenoubut yes, migen is most about data flow than having parametrazable CSR14:57
Fallenouthis is the real value of migen, the token thing14:58
Fallenouand python object language14:58
wpwrakFallenou: cristianpaul's patch illustrates mainly what happens if you hard-code constants all over the place. so he took something that had problems and didn't try to solve these problems, even though the problems should have become rather noticeable after the first few hundred changes :)14:59
wpwrakmaybe he just tried to be polite :)15:00
Fallenouwell ok CSR thing is just not the good example for migen advertisment :)15:06
kristianpaulstill wishbone arbiter :)15:07
Fallenoubut I still think migen is awesome :D15:08
lekernelwell, migen does provide a very decent parameter system :)15:08
lekernelof course, if you reduce it to only that, it's over engineering15:08
kristianpaulfore sure it does.. but as in gnu and autotools i dont want to be trap in migen and ng ;-)15:08
Action: kristianpaul troll15:09
wolfspraulwe need a credible path for everybody to move forward and adopt migen15:09
wolfsprauland I don't think we try to build such a path right now15:10
wolfspraulso there's just this great migen, if you don't understand how great it is you are an idiot and will be left behind15:10
wolfspraulof course that won't work :-)15:10
wolfspraulI work my way bottom up, verilog first - even that is quite high-level for me :-)15:11
kristianpauland obscure (verilog) if we remenber the synthesis tools are/still closed source...15:12
lekernelif you consider that migen only emits a subset of verilog without too many of the annoying corner cases, it has a little point there ;)15:14
lekernelJia: is there any other patch?15:47
lekernelfor 4.6.315:47
JiaI can make one for you, one minute15:47
lekernelplease send it to devel@lists.milkymist.org15:48
JiaOK, but more time, I;m not using the git tree, just tarball15:50
Jiamaybe 10 minutes is OK15:50
lekernelsure15:51
lekernelthanks!15:52
Jianetworking is slow...15:57
lekernelgreat firewall people manually reviewing your data?15:58
JiaI hate GFW!15:59
Jiamaybe they review my code and give me some comments:)16:00
JiaI hope they can help me fix the bug16:00
larschehe :)16:01
larscalways think positive16:01
Jiajust kidding:)16:03
Fallenoucould we expect small performance improvement in generated assembly using new gcc 4.6.3 ?16:05
Action: Jia is not sure...16:06
lekernelI don't think so, this is more about having a strong and up to date toolchain...16:07
Jialekernel: sent16:23
qi-botThe firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120711-1748/17:44
Fallenoulekernel_: do you know "Pierre Barre" ?17:49
lekernelno22:34
Jialekernel: I think maybe I will fix it today, in trunk and 4.7 :)23:53
--- Thu Jul 12 201200:00

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