lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs :: EHSM Berlin Dec 28-30 http://ehsm.eu :: latest video http://www.youtube.com/playlist?list=PL181AAD8063FCC9DC
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #milkymist
rejon has joined #milkymist
Jia has joined #milkymist
xiangfu has joined #milkymist
xiangfu has quit [Ping timeout: 248 seconds]
jimmythehorn has joined #milkymist
cladamw has joined #milkymist
xiangfu has joined #milkymist
<cladamw> wpwrak, hehe ... tks for fixing the drills image. :-)
<wolfspraul> good morning everybody :-)
<kristianpaul> hi
cladamw has quit [Quit: Ex-Chat]
rejon has quit [Ping timeout: 252 seconds]
<kristianpaul> lekernel: 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 ;-))
<kristianpaul> dont know havent check, perhaps this still doable right now
<kristianpaul> for example nasa, to they use whole soc? or just memory controller?..
<kristianpaul> i hope i make my point and open opinion to you about migen :)
<stekern> can't you just use migen to generate the verilog for one core?
<kristianpaul> i guess yes
<kristianpaul> not sure for the memory controller part
<wolfspraul> it seems migen is the thing that will fragment milkymist into a bunch of buggy 1-person projects :-)
<wolfspraul> soon we are ready for inclusion in opencores, all parts :-)
* kristianpaul dont want that...
<wolfspraul> maybe that's not a bad thing, and we can also find more things to use/reuse from opencores...
<kristianpaul> +1 for reuse
<wolfspraul> more or less everybody will patch up his own system in different ways anyway then
<wpwrak> yeah, irrespective of technical merit, i see that risk with migen, too
cladamw has joined #milkymist
<kristianpaul> patch up is good, if a solid base is agreed
<kristianpaul> and maintained
<wpwrak> cladamw: regarding the review, i haven't forgotten :)
<cladamw> wpwrak, aha ... thanks you. take your time though. :-)
<wpwrak> cladamw: 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.
<wpwrak> cladamw: i hope i'll catch up with the cataloging tools in the next days. then the reviews should be relatively straightforward.
<wpwrak> unless there are surprises, of course :)
<cladamw> wpwrak, no problem. no sorry. :-)
<stekern> I think I just discovered a bug in the lm32 llvm backend, byval function arguments aren't handled correctly
<stekern> they are just passed by reference, but not copied to the stack of the caller function
<cladamw> (led torch) wpwrak sounds you kept working improvements from previous one?
<wolfspraul> what's the *real* status of llvm btw?
<wolfspraul> for lm32/milkymist
<wolfspraul> my understanding is there are 2 compilers, gcc and llvm
<wolfspraul> gcc is buggy but maybe or maybe not some people are fixing those bugs?
<wolfspraul> and we seem to be using that compiler? or is 'we' only a very small number of people anyway?
<wolfspraul> I never used it :-)
<wolfspraul> then there is llvm, which has 'some' degree of lm32 support?
<wolfspraul> how many people are using that?
<wpwrak> stekern: "byval" that would be pretty much all function arguments ?
<wolfspraul> if one of the two is better, shouldn't we focus on that and then make it work well?
<wolfspraul> it seems we have two buggy and not really loved compilers
<wpwrak> i don't dislike gcc. on the other hand, i'm suspicious about llvm :)
<stekern> wpwrak: yes, but in LLVM IR "byval" is used to mark that (for example) a pointer parameter really should be passed by value
<stekern> s/(for example)/
<wolfspraul> we probably have 2-3 people that are actively using gcc for lm32
<wolfspraul> and how many for llvm? 1? 2?
<wpwrak> for all the lm32-independent stuff, one has to work with gcc pretty much all of the time anyway
rejon has joined #milkymist
<wpwrak> stekern: ah, i see. so it's just an llvmism ?
<wpwrak> stekern: i.e., if i pass a struct, nothing evil will happen ?
<stekern> if you pass it as a non-pointer, evil might happen
<wpwrak> cladamw: previous one ? i mean this critter: http://downloads.qi-hardware.com/people/werner/tmp/antorcha-proto1.jpg
<wpwrak> stekern: sounds nasty then
<kristianpaul> what on !, wpwrak have you a video of this thing working? (antorcha)
<cladamw> wpwrak, (RF-antorcha) nice !
<kristianpaul> yeah
<wpwrak> kristianpaul: unfortunately not. just still images. http://www.almesberger.net/misc/ant/proto2.jpg http://www.almesberger.net/misc/ant/edd1.jpg
<wpwrak> cladamw: recycled atben ;-)
<stekern> let me show an example: http://pastebin.com/uimYKNFy
<kristianpaul> wpwrak: getting ready para la marcha ;)
<wpwrak> kristianpaul: yup :)
<wolfspraul> he, www.milkymist.org/fpgatools still points to 404 errors :-)
<wpwrak> stekern: and you'd get the same if f0 writes to s ...
<stekern> I've got the same bug in the openrisc backend, I'll merge the change into lm32 when I've fixed it
<stekern> wpwrak: well, it's with -O0
<wolfspraul> stekern: have you been using llvm for lm32?
<stekern> wpwrak: for a reference, this is the output from gcc: http://pastebin.com/esBuLwEn
<wpwrak> stekern: all i need to see is the memcpy, which looks very appropriate there ;-)
<stekern> wolfspraul: 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 it
<stekern> wpwrak: yes, that's what missing in the llvm/clang output ;)
<wolfspraul> maybe we should delete the milkymist soc v1 sources to accelerate migen/-ng adoption?
<wpwrak> the dark force is strong in this one
jimmythehorn has quit [Quit: jimmythehorn]
rejon has quit [Ping timeout: 245 seconds]
wolfspraul has quit [Ping timeout: 245 seconds]
wolfspraul has joined #milkymist
wolfspraul has quit [Client Quit]
wolfspraul has joined #milkymist
wolfspraul is now known as Guest34622
Guest34622 has quit [Client Quit]
wolfspra1l has joined #milkymist
rejon has joined #milkymist
<wolfspra1l> btw, I think I hit a little roadblock with fpgatools
<wolfspra1l> the routing is a real maze
<wolfspra1l> so I will go one step back, and work on a model of the chip (rather the routes) in C first
<wpwrak> that's what routing is about :0
<wolfspra1l> that model will create a memory-representation of the routing which I will verify by dumping it into an svg
<wolfspra1l> not sure where this is going but I need something visual and something with more logic as can be expressed in C
<wolfspra1l> since I am flooded with papers here and wild drawings :-)
<wolfspra1l> printed papers :-)
<wolfspra1l> that's reached an end
<wpwrak> some amount of backtracking is to be expected in that line of work ;)
jimmythehorn has joined #milkymist
xiangfu has quit [Ping timeout: 255 seconds]
xiangfu has joined #milkymist
cladamw has quit [Quit: Leaving]
xiangfu has quit [Ping timeout: 264 seconds]
xiangfu has joined #milkymist
cladamw has joined #milkymist
cladamw has quit [Quit: Ex-Chat]
<Fallenou> 05:19 < wolfspraul> maybe we should delete the milkymist soc v1 sources to accelerate migen/-ng adoption? < wow I don't think that's necessary :)
<Fallenou> wolfspra1l: we all used a lot lm32 gcc, to compile lm32-linux, rtems, flickernoise
<Fallenou> wolfspra1l: I think at some point Milkymist bios was compiled with clang (llvm)
<Fallenou> and then with gcc and maybe back with clang I don't know
<wolfspra1l> which of the two compilers do you like better?
<Fallenou> and from now on I think lekernel is using clang only for -ng bios
<Fallenou> wolfspra1l: I have no experience with clang :/
<Fallenou> sorry
<wolfspra1l> feels like another fragmentation to me
<Fallenou> I would say from a religious point of view I would prefer a working clang/llvm than a working gcc
<wolfspra1l> but I have used neither myself, so I may just not know
<wolfspra1l> can we build the entire m1 image with clang/llvm or are lots of things missing?
<Fallenou> but gcc is a "strong" project. it existed for years
<Fallenou> so I kind of trust this one
<Fallenou> but it would be great if we could replace it with clang :)
<Fallenou> linux people are trying to replace gcc with clang too
<Fallenou> BSD people too
<Fallenou> pkg-src too
<Fallenou> gotta run to the office, bbl
<wolfspra1l> sure if clang/llvm really works and can fully replace gcc, that sounds great
<wolfspra1l> but until proven otherwise, I will assume it doesn't :-)
<larsc> guilty until proven innocent?
<wolfspra1l> yep
<wolfspra1l> defendant has to prove innocence himself
<lekernel> wolfspra1l: the -ng bios and the firmware (including lua, freetype, yaffs, etc.) compiles with clang
<stekern> I'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 though
<lekernel> kristianpaul: yes, you can generate only one core with migen
<lekernel> there are few disadvantages to using it... except that people don't look at it and still comment negatively
<lekernel> a bit the same with clang, heh
<lekernel> wolfspra1l: 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).
<Jia> may I ask if I keep working on lm32-gcc is OK?
<wolfspra1l> you said you would send a fix :-) did you do that?
<Jia> wolfspra1l: I've summit a patch to gcc-patches :-)
<wolfspra1l> great
<Jia> and cc to lekernel
<wolfspra1l> what's the effect of it?
<lekernel> Jia: I prefer clang/llvm, but anything that makes software run better on lm32 is good.
<wolfspra1l> does 4.6/7/later work now?
<wolfspra1l> c++ also?
<Jia> wolfspra1l: the libgcc bug, 4.8 trunk work now.
<wolfspra1l> maybe xiangfu should try to build the entire m1 image with that?
<lekernel> Jia: have you compiled and tested software with that?
<Jia> wolfspra1l: C++ not yet.
<wolfspra1l> I don't want to break down "compiler works" into this or that little library or bios or what not - can't handle that
<Jia> OK, I'll try.
<wolfspra1l> so either it works completely (better than before), or not at all
<wolfspra1l> xiangfu: you there?
<xiangfu> yes
<wolfspra1l> maybe you can try the latest gcc 4.8 with jia's fixes and see how much works?
<wolfspra1l> and let's include C++ in the test right away
<xiangfu> ok
<wolfspra1l> Jia: what's wrong with C++? can we continue with that?
<Jia> wolfspra1l: I didn't know C++ has problem, if you need, I'll keep working on it.
<wolfspra1l> definitely we 'need' that :-)
<lekernel> xiangfu: sent you the patch
<Jia> and, how can I work on lm32-clang?
<wolfspra1l> is more like dying in the desert without water type of need
<lekernel> Jia: you can try compiling the linux kernel... it's a good way to tickle clang/llvm bugs and problems
<xiangfu> lekernel, thanks. got that email.
<wolfspra1l> nobody will take a platform seriously where all the core devs together (whatever they may be focused on) cannot fix a C++ compiler bug for years
<Jia> I'll try to catch your step.
<wolfspra1l> even Itanium probably has more life in it :-)
<wolfspra1l> and no, I stay away from C++ as much as possible
<lekernel> wolfspra1l: I guess there are lots of C++ haters here ;)
<wolfspra1l> but our inability to fix that kind of bug looks bad for the platform
<lekernel> btw C++ support in clang is pretty encouraging
<wolfspra1l> that's besides the point, I think c++ is a horrible disaster, nightmare
<lekernel> also objective-c
<wolfspra1l> but the fact that 'we' cannot fix that type of bug in the entire platform for years is quite telling to an outsider
<Jia> gobjc is very old, and to die :-)
<wolfspra1l> so if Jia slowly gets up to speed, maybe he can fix that as well :-)
<Fallenou> 09:46 < lekernel> Jia: I prefer clang/llvm, but anything that makes software run better on lm32 is good. < +42
<wolfspra1l> that would be awesome
<wolfspra1l> of course ideally we want both gcc *and* llvm to work fully and completely and out of the box for everything
<wolfspra1l> I also still write letters to santa claus
<lekernel> oh cmon
<wolfspra1l> :-)
<wolfspra1l> I'll add perfect gcc and llvm support on the next one :-)
<wolfspra1l> Jia: thanks for your support!
<Jia> wolfspra1l: my pleasure
<wolfspra1l> let's see how far xiangfu gets with that latest compiler
<wolfspra1l> I want to see that it really works, and reflash my m1 with the result
* Fallenou is back
* xiangfu update local gcc now. then try to patch, compile , compile..
<Jia> lekernel: if I wanna working on llvm/clang, should I clone the git repo and...?
<xiangfu> Jia, your patch is base on latest 'master' branch of gcc. right? just for double make sure.
<Jia> xiangfu: yes, master
<lekernel> Jia: thanks for your gcc/llvm work!
<Jia> wolfspra1l: lekernel xiangfu thank you all offer me a chance :)
<Jia> xiangfu: is it ok?
<lekernel> xiangfu: let me know how the testing goes. if it works, i'll commit Jia's patch into gcc.
<lekernel> Jia: guess it's still building ;)
<xiangfu> Jia, not that fast.
* Jia hope it is OK.
<xiangfu> lekernel, yes.
<Jia> where can I find lm32 cpu verilog code, verdi, golden and so on?
<lekernel> verdi/golden??
<Jia> lekernel: thank you! is there a verification env?
<lekernel> for lm32? no
<lekernel> I suppose Lattice has one, but they did not publish it
<Jia> OK, if I can make lm32 one of our core, I'll push them working on it.
<lekernel> you can also try emailing Lattice :) response far from guaranteed though
<Jia> is Lattice down? I googled lm32, and it is a TI product now.
kristianpaul has quit [Read error: Connection reset by peer]
<wolfspra1l> we need a plan how everybody can and will switch to -ng
<Fallenou> I am willing to contribute to help porting things from M1 SoC in plain verilog to migen style -ng
<Fallenou> but my main focus remains MMU
<wolfspra1l> wow great! (willing to contribute)
<wolfspra1l> I should probably kick myself more in shape too, but so busy on the fpgatools right now
<wolfspra1l> the important thing is to have 1 unified message to the outside world, i.e. newcomers
<wolfspra1l> and not 5 people all saying different things, that's horrible
<Fallenou> I really want the -ng soc on M1 product
<wolfspra1l> so the starting point should be -ng, and then we somehow need a path from -ng to the legacy stuff or rather devices like m1
<Fallenou> (and not just on M1 board)
<wolfspra1l> exactly
<wolfspra1l> we need a conclusive answer for that, we cannot just have multiple people go in different directions etc.
<wolfspra1l> if we do that, nobody from outside will join this chaos
<wolfspra1l> understandably
<wolfspra1l> so the starting point should be -ng, and then it needs to support the old/current stuff
<wolfspra1l> since sebastien said there are ways to keep regular verilog through migen, maybe it's all quite simple, I don't know
<wolfspra1l> on the other hand he said some cores may not be easily translatable, oh well. we shall find out...
kristianpaul has joined #milkymist
<Fallenou> as far as I understand video input core will have to be re-written in python-migen
<Fallenou> I will try to do/help on this part
<Fallenou> (Milkymist One part of Sebastien email of the 11 june 2012)
<Fallenou> wolfspra1l: he said plain verilog can be kept, except for cores that are doing DMA on FML bus (like video input core)
rejon_ has joined #milkymist
rejon has quit [Ping timeout: 265 seconds]
<wolfspra1l> I always just read the 'except' or 'but' or 'only' parts of such statements :-)
<Fallenou> hehe
kristianpaul has quit [Remote host closed the connection]
kristianpaul has joined #milkymist
Jia has quit [Quit: Konversation terminated!]
kristianpaul has quit [Ping timeout: 248 seconds]
kristianpaul has joined #milkymist
kristianpaul has quit [Remote host closed the connection]
kristianpaul has joined #milkymist
<GitHub171> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/eed8fa374d876d89e23a2db760ae92ad002e8bfa
<GitHub171> [migen/master] fhdl/arrays: use correct BV for intermediate signals - Sebastien Bourdeauducq
<xiangfu> Jia
* xiangfu network is slow. will send email after test the gcc patch.
kristianpaul has quit [Ping timeout: 272 seconds]
* xiangfu switch gcc from svn to git. so re-download it . now 48%
kristianpaul has joined #milkymist
rejon_ has quit [Ping timeout: 245 seconds]
kristianpaul has quit [Remote host closed the connection]
Gurty` has quit [Ping timeout: 265 seconds]
kristianpaul has joined #milkymist
jimmythehorn has quit [Quit: jimmythehorn]
wolfspraul has joined #milkymist
wolfspra1l has quit [Ping timeout: 248 seconds]
azonenberg has quit [Ping timeout: 245 seconds]
km2 has quit [Ping timeout: 276 seconds]
Jia has joined #milkymist
<Jia> xiangfu: ?
km2 has joined #milkymist
<xiangfu> Jia, I am compile the gcc with yoru patch now.
kristianpaul has quit [Ping timeout: 248 seconds]
<Jia> got
kristianpaul has joined #milkymist
kristianpaul has quit [Remote host closed the connection]
kristianpaul has joined #milkymist
<xiangfu> The latest master branch cannot compile.
<xiangfu> I am switch to 'ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120708/'
<xiangfu> a Snapshot from gcc mailing list
<xiangfu> failed with compile lib-gcc
<xiangfu> failed with itself.
<Jia> I did test it.
kristianpaul has quit [Remote host closed the connection]
<xiangfu> Jia, I am using a 64bit system.
<xiangfu> configure gcc with:
<xiangfu> ~~~~
<xiangfu> ../gcc-$(GCC_CORE_VERSION)/configure --target=lm32-rtems4.11 \
<xiangfu> --with-gnu-as --with-gnu-ld --with-newlib --verbose \
<xiangfu> --enable-threads --enable-languages="c" --disable-shared \
<xiangfu> --prefix=$(RTEMS_PREFIX)
<xiangfu> ~~~~
<xiangfu> it have error when compile latest gcc
<xiangfu> I compile base on 'trunk@189422' 'b1cd4fdd3fd08fb5096c1310ee8add05331ed7b6'
<xiangfu> I am switching to 'gcc-4.8-20120708' now.
<Jia> I'm working on 64bits system too
<Jia> and I've send you the script
<Jia> lm32-elf-gcc
<Jia> export PATH=$PATH:$PREFIX/bin
<Jia> gcc and binutils have the same PREFIX
<Jia> --prefix=${PREFIX} --target=${CROSS_TARGET} \
<Jia> --enable-interwork --disable-multilib --enable-languages=c --with-newlib \
<Jia> --disable-nls --disable-shared --disable-threads --with-gnu-as --with-gnu-ld \
<Jia> --without-headers --disable-libquadmath --disable-libssp
<wolfspraul> if possible try pasting longer scripts or error logs via pastebin etc.
<wolfspraul> perfect
<wolfspraul> thanks!
<Jia> no thanks:) and I hope it is ok
sh4rm4 has quit [Ping timeout: 276 seconds]
kristianpaul has joined #milkymist
<xiangfu> Jia, I would advise we working on this one 'https://github.com/milkymist/scripts/blob/master/compile-lm32-rtems/Makefile'
sh4rm4 has joined #milkymist
<xiangfu> Jia, merge your script file to this Makefile. add another target, like: make gcc-trunk
<Jia> I'll try
kristianpaul has quit [Ping timeout: 272 seconds]
kristianpaul has joined #milkymist
<kristianpaul> did my email about 5bit csr support arrive?
rejon_ has joined #milkymist
<wpwrak> kristianpaul: the one with the patch ?
<wpwrak> kristianpaul: or a reply to sebastien's one line rejection of the 1000+ lines patch ? :)
<kristianpaul> lol yeah, just got email this morning
xiangfu has quit [Remote host closed the connection]
<kristianpaul> wpwrak: 1000+ lines is bad?
<Jia> wolfspraul: sorry, newlib make failed.
<wpwrak> for harcoded constants, yes. you could have made it a parameter.
<Fallenou> kristianpaul: does your patch have a downside ?
<Fallenou> I mean increasing the csr id width
<kristianpaul> a bit more routing i guess
<Fallenou> does it decrease something else ?
<kristianpaul> dont think so, or not realized yet
<kristianpaul> anyway i just wanted to be there, my early atempt was even more mesier :)
<lekernel> the increased resource usage should be minimal
<lekernel> but (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 -ng
<kristianpaul> testing yes
<kristianpaul> but is your prefered way lekernel
<lekernel> seriously, adding a core to the system including DMA and such is 2-3 lines instead of a big mess
<kristianpaul> yes..
<lekernel> I can't see how you'd defend the old method
<kristianpaul> I dont
<kristianpaul> a parser we need :)
<kristianpaul> or small tools as wpwrak quoted yday
<lekernel> migen is a small tool
<lekernel> if you only use the bus interconnect generator it's what? 1.5k lines?
<wpwrak> what'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 do
<lekernel> well you can - it's just that it's not done this way
<lekernel> so this criticism should be for milkymist-ng, not migen :)
<kristianpaul> exactly !, tought i will get confused and think are the same
<lekernel> how would you like it to be?
<lekernel> and what advantage would it have?
<wpwrak> the (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.
<wpwrak> now, perhaps that can be done without having to actually parse verilog
Jia has quit [Quit: Konversation terminated!]
<wpwrak> e.g., if the task can be reduced to inserting blocks of things at specific places, you could simple have directives that do this.
<wpwrak> or maybe have a mixture - parse the parts of verilog you have to, leave the rest alone
<lekernel> generally, it can't be reduced to inserting blocks at specific places
<wpwrak> the 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 pieces
<wpwrak> for naming ? or does it also have to transform operations ?
Gurty has joined #milkymist
<lekernel> the dataflow system does some transforms, yes
<lekernel> also there are things like generic components that export abstract CSRs
<lekernel> and the CSRs from those components can be combined into the CSR area of a peripherals
<lekernel> one example is the generic interrupt controller that cores can include and map in their CSR area
<wpwrak> and you can't just break the abstract CSRs down to pieces you insert at the right places ?
<lekernel> ??
<lekernel> like #include ?
<lekernel> this makes it uglier, not nicer
<wpwrak> well, think of it as #include for now
<wpwrak> or maybe #include(param, ...) :)
<wpwrak> we can worry about making it pretty later :)
<lekernel> the 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 generator
<lekernel> this is much clearer I think than macros
Jia has joined #milkymist
<wpwrak> maybe 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)
<lekernel> but why should it be based on verilog? I don't think it's such a better language than python...
Hodapp has quit [Ping timeout: 252 seconds]
<lekernel> here you can even call into python libraries e.g. to pre compute DSP coefficients
<wpwrak> it's one of the languages people who do this sort of things are most likely to know
Hodapp has joined #milkymist
<lekernel> or even read C include files and retrieve the address at which peripherals should be mapped
<wpwrak> and if they run into trouble, they have to fall back to verilog anyway
<lekernel> not much more than they have to fall back to netlist when using verilog ...
<kristianpaul> languge not at all, perhaps a easy to read config file is a good start too
Jia has quit [Read error: Connection reset by peer]
<wpwrak> for 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.
hypermodern has joined #milkymist
<kristianpaul> wpwrak: could bison for example parse config files ans generate verilog from that?
<lekernel> ok, but it's easier to do when you already have that system
<kristianpaul> i havent never used bison, just thinking...
<wpwrak> kristianpaul: 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 :)
<lekernel> kristianpaul: 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.
<kristianpaul> why you insist on -ng ..
<wpwrak> (*) it reaches its limits with ambiguous grammars. e.g., where you only find out late that a previous parsing decision was wrong.
<kristianpaul> and yes i have some slace core in my gps branch
<lekernel> kristianpaul: because, among many other things, your 1000-line patch would be reduced to about 2 lines :)
<kristianpaul> of course your atitude is not open to suguestions anyway ng will be another one person project..
<lekernel> I'm open to suggestions, but only after people have tried the stuff they are commenting on
<kristianpaul> so why you insist on -ng so much? lets wait other year then anothe repo will be deleted from history?
<kristianpaul> well
<lekernel> not just a vague "it's over engineering", especially right after sending a messy patch that exemplifies how one problem is better solved with migen
<Fallenou> I think you are too hard on migen
<wpwrak> you have a point there ;-)
<kristianpaul> yeah
<wpwrak> but my first reaction wouldn't have been "migen" but "parameters" ;-)
<Fallenou> I find it really cool so far, but my opinion does not weight much since I have almost never used it
<Fallenou> I used it to generate the the soc.v I am using for my MMU simulations
<Fallenou> and it worked fine
<Fallenou> but indeed the kristianpaul patch is a really good example of what happens without migen : thousand lines for a simple change
<lekernel> wpwrak: well, to be honest, VHDL would have solved it (with packages) as well
<Fallenou> but yes, migen is most about data flow than having parametrazable CSR
<Fallenou> this is the real value of migen, the token thing
<Fallenou> and python object language
<wpwrak> Fallenou: 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 :)
<wpwrak> maybe he just tried to be polite :)
<Fallenou> well ok CSR thing is just not the good example for migen advertisment :)
<kristianpaul> still wishbone arbiter :)
<Fallenou> but I still think migen is awesome :D
<lekernel> well, migen does provide a very decent parameter system :)
<lekernel> of course, if you reduce it to only that, it's over engineering
<kristianpaul> fore sure it does.. but as in gnu and autotools i dont want to be trap in migen and ng ;-)
* kristianpaul troll
<wolfspraul> we need a credible path for everybody to move forward and adopt migen
<wolfspraul> and I don't think we try to build such a path right now
<wolfspraul> so there's just this great migen, if you don't understand how great it is you are an idiot and will be left behind
<wolfspraul> of course that won't work :-)
<wolfspraul> I work my way bottom up, verilog first - even that is quite high-level for me :-)
<kristianpaul> and obscure (verilog) if we remenber the synthesis tools are/still closed source...
<lekernel> if you consider that migen only emits a subset of verilog without too many of the annoying corner cases, it has a little point there ;)
aeris has quit [Ping timeout: 244 seconds]
aeris has joined #milkymist
Jia has joined #milkymist
<lekernel> Jia: is there any other patch?
<lekernel> for 4.6.3
<Jia> I can make one for you, one minute
<lekernel> please send it to devel@lists.milkymist.org
<Jia> OK, but more time, I;m not using the git tree, just tarball
<Jia> maybe 10 minutes is OK
<lekernel> sure
<lekernel> thanks!
<Jia> networking is slow...
<lekernel> great firewall people manually reviewing your data?
<Jia> I hate GFW!
<Jia> maybe they review my code and give me some comments:)
<Jia> I hope they can help me fix the bug
<larsc> hehe :)
<larsc> always think positive
<Jia> just kidding:)
<Fallenou> could we expect small performance improvement in generated assembly using new gcc 4.6.3 ?
* Jia is not sure...
<lekernel> I don't think so, this is more about having a strong and up to date toolchain...
jimmythehorn has joined #milkymist
<Jia> lekernel: sent
Jia has quit [Quit: Konversation terminated!]
lekernel_ has joined #milkymist
lekernel has quit [Ping timeout: 244 seconds]
<qi-bot> The firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120711-1748/
<Fallenou> lekernel_: do you know "Pierre Barre" ?
rejon_ has quit [Ping timeout: 264 seconds]
azonenberg has joined #milkymist
kristianpaul has quit [Ping timeout: 272 seconds]
kristianpaul has joined #milkymist
jimmythehorn has quit [Read error: Operation timed out]
jimmythehorn has joined #milkymist
jimmythehorn has quit [Client Quit]
jimmythehorn has joined #milkymist
sh4rm4 has quit [Ping timeout: 276 seconds]
sh4rm4 has joined #milkymist
wolfspraul has quit [Quit: leaving]
lekernel_ is now known as lekernel
<lekernel> no
Jia has joined #milkymist
<Jia> lekernel: I think maybe I will fix it today, in trunk and 4.7 :)