Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
stekern [stekern!~stefan@nblzone-224-141.nblnetworks.fi] has joined #milkymist
rejon [rejon!~rejon@72-161-255-93.dyn.centurytel.net] has joined #milkymist
errordeveloper [errordeveloper!~Dmitriche@host86-173-185-170.range86-173.btcentralplus.com] has joined #milkymist
<kristianpaul> whitequark: dont relly to much on xilinx specif stuff
<kristianpaul> remenber we may want to move easilly to others fpga in the future
<whitequark> kristianpaul: well, that just fixes a bug in xst parser
<whitequark> "fixes"
<whitequark> actually, it was my own error -- some weird thing with macros -- but it still crashed the translator.
<wpwrak> this is why those open source hippies will never be able to compete with professional closed source work ;-)
<whitequark> wpwrak: fully agree.
<whitequark> hmmmokay.
<whitequark> I need some kind of barrier in my CPU...
<kristianpaul> ha, milkymist-ng not bad
<kristianpaul> very interesting way of creating and sinthesizing SoC :-)
<whitequark> can someone hint me a way of doing dual-port _write-first_ memory in verilog?
<kristianpaul> milkymist have some examples of this
<kristianpaul> in the softusb core (hdl), also minimac2 core (as xilinx lib)
<whitequark> ok nevermind. I already invented a way
<whitequark> now I wonder if xst is clever enough to infer the correct BRAM
<kristianpaul> HA !
<kristianpaul> check hdl coding style guide from xilinx
<whitequark> true programmers do not read documentation! :D
<kristianpaul> hum dont think so..
<whitequark> that was a joke.
<kristianpaul> and there is no xst source code to read instead ;)
<whitequark> well, there is always zen
<whitequark> you can look at xst veeery intently and understand everything you need.
<whitequark> ... probably. I was never able to do that :D
<kristianpaul> HDL coding techniques
<whitequark> yeah, already found that
<kristianpaul> ah well..
<kristianpaul> also the Libraries Guide for spartan-6?
<whitequark> sure
<kristianpaul> ok..
xiangfu [xiangfu!~xiangfu@124.205.34.122] has joined #milkymist
<xiangfu> 16 years, 7 months, and 4 days of RTEMS history are moving to Git.
<kristianpaul> link link !
<kristianpaul> i want get rid off that cvs... tooo slow
<xiangfu> not finish yet. so the git is may not sync with cvs.
<kristianpaul> ah..
<xiangfu> kristianpaul, I use git for weeks. modify. then copy to rtems.cvs and re-compile. :)
rejon [rejon!~rejon@72-161-255-93.dyn.centurytel.net] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<cladamw> ( rc3's yield ) still 79pcs, but just fixed another 3 sets except PHY id/midi/crc not tested. so yield will soon go over from 80 to maybe 82 sets.
<wpwrak> kewl. we'll only have the ones with the botched FPGA left :) the ones that sometimes enter hectical reset oscillation
<cladamw> yeah... still no further idea on reset oscillation likes 0x32. :)
<xiangfu> cladamw, I still not fix the boot.bin buy. sorry.
<xiangfu> cladamw, the PHY ID I needs ask Sebastien.
<cladamw> xiangfu, no sorry. I was thought it's easy. :)
<xiangfu> CRC is a strange error. I tried many method. it maybe ALIGN problem.
<xiangfu> CRC BUG is like. all other test is working. only when press 'a -- tests_images' it will hang the system.
<cladamw> xiangfu, for those packed rc3, i can just directly update it without crc testing. Since I can surely those m1 h/w worked pass already. For remaining new boards without f/w, i can temporarily skip phy id/midi/crc tests. No problems. :-)
<wpwrak> cladamw: (0x32) i think it's simply a damaged fpga. maybe ESD, maybe excess heat.
<cladamw> wpwrak, okay... the worse case that I remove fpga then remount it. not decided yet. :-)
<wpwrak> cladamw: are you confident about reworking such a large BGA ? well, it's probably fun to try and see how far you can take things :)
<cladamw> wpwrak, i can't do this. No confidence at all. :-) I usually let senior fpga reworker to do this. Like 0x74: http://en.qi-hardware.com/wiki/File:M1rc3_0x74_fpga_removed.png
<cladamw> it was removed.
<wpwrak> nice and clean removal indeed
<cladamw> and this http://en.qi-hardware.com/wiki/File:M1rc3_0x74_XC6SLX45-2FGG484C_without_balls_1.png the fpga will be placed 484 soldering balls.
<wpwrak> phew :)
<wolfspraul> wpwrak: we should go watch some professional reworkers in factories, you would be *amazed*
<wolfspraul> our hands are magic
<wpwrak> wolfspraul: yeah,. i've seen some crazy rework when we did the hxd8 tear-down experiments
<cladamw> bad now we( me and smt vendor)'ve not made specific stencil for our spartan-6 484 balls/apertures. This I'll do soon.
<wolfspraul> just think what a pianist is able to do after 10+ years or more of training for hours each day
<wpwrak> wolfspraul: it was fun. i just had to point at a chip, and two minutes later it was gone, and the board still worked (and, of course, still faithfully showed the bug)
<cladamw> to make a "small" square stencil with 484 apertures.
<wolfspraul> actually I think precision reworking is valuable not just as a way to bring a product back to working or even sellable state, but also to aid in tracking down yield problems
<wolfspraul> so any manufacturer is well advised to not let that capability sink too low, otherwise they will have yield problems sooner or later
<wolfspraul> just my thinking
<wpwrak> hmm, maybe. it has great value for R&D, of course. so at least from that angle, i'd agree that this is a skill worth nurturing.
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
mumptai [mumptai!~calle@brmn-4db716f8.pool.mediaWays.net] has joined #milkymist
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has quit ["Leaving"]
r33p [r33p!~rep@bon31-2-89-85-157-97.dsl.sta.abo.bbox.fr] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
elldekaa [elldekaa!~hyviquel@vpn3.enssat.univ-rennes1.fr] has joined #milkymist
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
azonenberg [azonenberg!~azonenber@cpe-67-246-33-188.nycap.res.rr.com] has joined #milkymist
lekernel_ [lekernel_!~lekernel@g225044243.adsl.alicedsl.de] has joined #milkymist
r33p [r33p!~rep@bon31-2-89-85-157-97.dsl.sta.abo.bbox.fr] has joined #milkymist
wolfspra1l [wolfspra1l!~wolfsprau@p5B0AC2C0.dip.t-dialin.net] has joined #milkymist
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
<cladamw> wpwrak, ( rc3, 0x32 ) forgot to tell you. I found that actually BTN2 level is 2V which is not correct so that causing reset oscillation( tp36/tp37 to randomly pulse).
<lekernel_> BTN2? the button?
<cladamw> wpwrak, now the BTN2 level (i.e. is the middle btn's ctrl signal) works well though. :-) This result is done after I "heavily heat fpga BTN2 area by blow air @ 325 ℃" and blow air in four edges of fpga too. I was so much "stupid" & "brave" without thinking too much. Just took risk. :-)
<cladamw> lekernel_, yes. the BTN2 is the signal to activate bootup procedure. :-)
<cladamw> BTN2 is the AA4 ball which is nearby our 'reset circuit' area. http://en.qi-hardware.com/wiki/File:M1rc3_fg(g)484_bga_package-AA4-AB17-AB21.png
<cladamw> This result makes me strongly doubted and thought that it's a mix composed by flux and cleaning liquid stocked under BTN2 ball area during several times rework nearby 'reset circuit' to cause it.
<cladamw> just guessed in this way. I'll let it run overnight and keep an eye on that level again. :-)
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<xiangfu> the boot.bin problem is the crc32 fault. :(
<GitHub82> [autotest-m1] sbourdeauducq pushed 1 new commit to master: http://git.io/q6IF8A
<GitHub82> [autotest-m1/master] Fix new compiler warnings - Sebastien Bourdeauducq
* xiangfu have the same patch not push.
<GitHub139> [autotest-m1] sbourdeauducq pushed 1 new commit to master: http://git.io/2tmE_Q
<GitHub139> [autotest-m1/master] MIDI: support new uart core, correctly this time - Sebastien Bourdeauducq
<GitHub69> [autotest-m1] xiangfu pushed 1 new commit to master: http://git.io/PIBQuw
<GitHub69> [autotest-m1/master] some variable names cleanup - Xiangfu Liu
<GitHub68> [autotest-m1] xiangfu force-pushed master from fb05b90 to 50d40bb: http://git.io/FNP5fw
<GitHub68> [autotest-m1/master] some variable names cleanup - Xiangfu Liu
<xiangfu> sorry. should be const. not static.
antgreen [antgreen!~user@bas3-toronto06-1177890176.dsl.bell.ca] has joined #milkymist
kristianpaul [kristianpaul!~kristianp@unaffiliated/kristianpaul] has joined #milkymist
<xiangfu> when I comment this line: https://github.com/milkymist/autotest-m1/blob/master/src/tests_images.c#L51 everything works fine. include tests_images.
antgreen [antgreen!~user@bas3-toronto06-1177890176.dsl.bell.ca] has joined #milkymist
Martoni [Martoni!~chatzilla@arc68-5-88-188-247-92.fbx.proxad.net] has joined #milkymist
mumptai [mumptai!~calle@brmn-4db716f8.pool.mediaWays.net] has joined #milkymist
<whitequark> will a synthesizer eliminate common subexpressions or I should do that myself by defining explicit wirs ?
<whitequark> *wires
lekernel [lekernel!~lekernel@g225044243.adsl.alicedsl.de] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
<kristianpaul> whitequark: yes
<wpwrak> kristianpaul: "tea or coffee ?" "yes" :)
<lars_> wpwrak: "teoffe"
<kristianpaul> wpwrak: aromatica ;-)
<kristianpaul> Fines herbes tea english name is i think
<kristianpaul> lol
<kristianpaul> you always making laught of me :)
<kristianpaul> whitequark: yes you should define constraints i meant
<whitequark> kristianpaul: ah. thanks.
<whitequark> then a lot of my code is horribly ineffecient :/
* whitequark goes to rewire the whole pipeline 4th time this day
<kristianpaul> it depends what you want to do anyway?
<kristianpaul> if still the cpu think i think icarus and some prints will be more that enought perhaps? or the a test bench with gtkwave to confirm results?
<whitequark> kristianpaul: I'm not sure if the subexpression elimination will be visible as waveforms
<whitequark> it's more of FPGA space (and speed) concern
<whitequark> well, RTL looks horrible, so I guess I'm doing that wrong
<lars_> rtl looks always horrible ;)
<whitequark> lars_: in the more clean parts of my design, rtl is exactly like it was wired by a person
<lars_> and what are you doing in the not so clean parts?
<lars_> i can really see anything in the png. but what would you've expected instead
<lars_> ?
<whitequark> lars_: at least an addsub
<whitequark> ah sorry, that's my error
<whitequark> it actually placed an addsub, but disguised it as a mux.
<lars_> does it execute ascii brainfuck, or do you need a compiler?
<whitequark> lars_: ascii
<whitequark> I'm going to make a pipelined cpu with branch target caching
<wpwrak> finally i can run all my brainfuck programs on decent hardware ;)
<whitequark> wpwrak: at last, someone got the idea! :D
<lars_> whitequark: yes i guess the loops are the interesting part
<whitequark> lars_: for me, even proper hazard resolving is interesting. but yes, branching is, too
<whitequark> I've used the standard RISC pipeline, and modified it for bf
<lars_> 5 stages is that, right?
<whitequark> i.e. it does not have random memory access, and all the memory logic is hence moved to EX stage
<whitequark> and the M stage is gone
<whitequark> so, it is 4-stage
<whitequark> I'm currently doing register (just the accumulator, in this case) forwarding
<whitequark> looks like I just have to wire the execute stage to itself
<whitequark> as per the branches, I'll make ID stage lookup the branch in cache
<whitequark> then, EX will either jump to the target or forward-track it
<whitequark> and WB will place it to the cache
<whitequark> that was for the [; ] ones are resolved just with a stack
aeris- [aeris-!~aerith@home.aerith.fr] has joined #milkymist
<wpwrak> roh: i must say i rather like the symmetries in your case design. they may it pretty easy to reverse-engineer.
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
r33p [r33p!~rep@bon31-2-89-85-157-97.dsl.sta.abo.bbox.fr] has joined #milkymist
errordeveloper [errordeveloper!~Dmitriche@host109-154-145-160.range109-154.btcentralplus.com] has joined #milkymist
<whitequark> lekernel: okay, got it: BRAM has a latency of 1 cycle, so I need two cycles to get a result from it
<whitequark> and for instruction RAM, I can pipeline to hide the latency
<whitequark> but data RAM has the same property
<whitequark> ah, got it. I can raise CE as early as at the ID stage, not EX