#milkymist IRC log for Thursday, 2011-12-15

kristianpaulwhitequark: dont relly to much on xilinx specif stuff01:39
kristianpaulremenber we may want to move easilly to others fpga in the future01:39
whitequarkkristianpaul: well, that just fixes a bug in xst parser02:31
whitequarkactually, it was my own error -- some weird thing with macros -- but it still crashed the translator.02:32
wpwrakthis is why those open source hippies will never be able to compete with professional closed source work ;-)02:52
whitequarkwpwrak: fully agree.03:01
whitequarkI need some kind of barrier in my CPU...03:02
kristianpaulha, milkymist-ng not bad03:02
kristianpaulvery interesting way of creating and sinthesizing SoC :-)03:03
whitequarkcan someone hint me a way of doing dual-port _write-first_ memory in verilog?03:07
kristianpaulmilkymist have some examples of this03:08
kristianpaulin the softusb core (hdl), also minimac2 core (as xilinx lib)03:08
whitequarkok nevermind. I already invented a way03:09
whitequarknow I wonder if xst is clever enough to infer the correct BRAM03:09
kristianpaulHA !03:09
kristianpaulcheck hdl coding style guide from xilinx03:09
whitequarktrue programmers do not read documentation! :D03:10
kristianpaulhum dont think so..03:10
whitequarkthat was a joke.03:10
kristianpauland there is no xst source code to read instead ;)03:10
whitequarkwell, there is always zen03:10
whitequarkyou can look at xst veeery intently and understand everything you need.03:11
whitequark... probably. I was never able to do that :D03:11
kristianpaulHDL coding techniques03:13
whitequarkyeah, already found that03:14
kristianpaulah well..03:14
kristianpaulalso the  Libraries Guide for spartan-6?03:14
xiangfu16 years, 7 months, and 4 days of RTEMS history are moving to Git.03:18
kristianpaullink link !03:18
kristianpauli want get rid off that cvs... tooo slow03:18
xiangfukristianpaul, http://www.rtems.org/wiki/index.php/CVStoGit03:22
xiangfunot finish yet. so the git is may not sync with cvs.03:22
xiangfukristianpaul, I use git for weeks. modify. then copy to rtems.cvs and re-compile. :)03:24
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.04:41
wpwrakkewl. we'll only have the ones with the botched FPGA left :) the ones that sometimes enter hectical reset oscillation04:55
cladamwyeah... still no further idea on reset oscillation likes 0x32. :)05:07
xiangfucladamw, I still not fix the boot.bin buy. sorry.05:16
xiangfucladamw, the PHY ID I needs ask Sebastien.05:17
cladamwxiangfu, no sorry. I was thought it's easy. :)05:17
xiangfuCRC is a strange error. I tried many method.  it maybe ALIGN problem.05:17
xiangfuCRC BUG is like. all other test is working. only when press 'a -- tests_images' it will hang the system.05:18
cladamwxiangfu, 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. :-)05:21
wpwrakcladamw: (0x32) i think it's simply a damaged fpga. maybe ESD, maybe excess heat.05:25
cladamwwpwrak, okay... the worse case that I remove fpga then remount it. not decided yet. :-)05:27
wpwrakcladamw: are you confident about reworking such a large BGA ? well, it's probably fun to try and see how far you can take things :)05:31
cladamwwpwrak, 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.png05:34
cladamwit was removed.05:34
wpwraknice and clean removal indeed05:35
cladamwand this http://en.qi-hardware.com/wiki/File:M1rc3_0x74_XC6SLX45-2FGG484C_without_balls_1.png  the fpga will be placed 484 soldering balls.05:35
wpwrakphew :)05:35
wolfspraulwpwrak: we should go watch some professional reworkers in factories, you would be *amazed*05:36
wolfspraulour hands are magic05:36
wpwrakwolfspraul: yeah,. i've seen some crazy rework when we did the hxd8 tear-down experiments05:36
cladamwbad now we( me and smt vendor)'ve not made specific stencil for our spartan-6 484 balls/apertures. This I'll do soon.05:36
wolfsprauljust think what a pianist is able to do after 10+ years or more of training for hours each day05:36
wpwrakwolfspraul: 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)05:37
cladamwto make a "small" square stencil with 484 apertures.05:37
wolfspraulactually 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 problems05:38
wolfspraulso any manufacturer is well advised to not let that capability sink too low, otherwise they will have yield problems sooner or later05:39
wolfsprauljust my thinking05:39
wpwrakhmm, 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.05:41
cladamwwpwrak, ( 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).12:59
lekernel_BTN2? the button?13:06
cladamwwpwrak, 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. :-)13:07
cladamwlekernel_, yes. the BTN2 is the signal to activate bootup procedure. :-)13:07
cladamwBTN2 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.png13:09
cladamwThis 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.13:10
cladamwjust guessed in this way. I'll let it run overnight and keep an eye on that level again. :-)13:11
xiangfuthe boot.bin problem is the crc32 fault. :(14:10
GitHub82[autotest-m1] sbourdeauducq pushed 1 new commit to master: http://git.io/q6IF8A14:32
GitHub82[autotest-m1/master] Fix new compiler warnings - Sebastien Bourdeauducq14:32
Action: xiangfu have the same patch not push. 14:39
GitHub139[autotest-m1] sbourdeauducq pushed 1 new commit to master: http://git.io/2tmE_Q14:39
GitHub139[autotest-m1/master] MIDI: support new uart core, correctly this time - Sebastien Bourdeauducq14:39
GitHub69[autotest-m1] xiangfu pushed 1 new commit to master: http://git.io/PIBQuw14:57
GitHub69[autotest-m1/master] some variable names cleanup - Xiangfu Liu14:57
GitHub68[autotest-m1] xiangfu force-pushed master from fb05b90 to 50d40bb: http://git.io/FNP5fw14:59
GitHub68[autotest-m1/master] some variable names cleanup - Xiangfu Liu14:59
xiangfusorry. should be const. not static.15:00
xiangfuwhen I comment this line: https://github.com/milkymist/autotest-m1/blob/master/src/tests_images.c#L51 everything works fine. include tests_images.15:12
whitequarkwill a synthesizer eliminate common subexpressions or I should do that myself by defining explicit wirs ?17:58
kristianpaulwhitequark: yes19:05
wpwrakkristianpaul: "tea or coffee ?" "yes" :)19:13
lars_wpwrak: "teoffe"19:19
kristianpaulwpwrak: aromatica ;-)19:22
kristianpaulFines herbes tea english name is i think19:24
kristianpaulyou always making  laught of me :)19:24
kristianpaulwhitequark: yes you should define constraints i meant19:25
whitequarkkristianpaul: ah. thanks.19:34
whitequarkthen a lot of my code is horribly ineffecient :/19:35
Action: whitequark goes to rewire the whole pipeline 4th time this day19:35
kristianpaulit depends what you want to do anyway?19:35
kristianpaulif 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?19:36
whitequarkkristianpaul: I'm not sure if the subexpression elimination will be visible as waveforms19:36
whitequarkit's more of FPGA space (and speed) concern19:36
whitequarkwell, RTL looks horrible, so I guess I'm doing that wrong19:37
lars_rtl looks always horrible ;)19:51
whitequarklars_: in the more clean parts of my design, rtl is exactly like it was wired by a person19:58
lars_and what are you doing in the not so clean parts?20:14
whitequarklars_: this https://github.com/whitequark/bfcpu2/blob/master/verilog/StageExecute.v expands to this: http://rghost.ru/34951311.view20:16
lars_i can really see anything in the png. but what would you've expected instead20:23
whitequarklars_: at least an addsub20:24
whitequarkah sorry, that's my error20:25
whitequarkit actually placed an addsub, but disguised it as a mux.20:26
lars_does it execute ascii brainfuck, or do you need a compiler?20:37
whitequarklars_: ascii20:43
whitequarkI'm going to make a pipelined cpu with branch target caching20:44
wpwrakfinally i can run all my brainfuck programs on decent hardware ;)20:44
whitequarkwpwrak: at last, someone got the idea! :D20:45
lars_whitequark: yes i guess the loops are the interesting part20:45
whitequarklars_: for me, even proper hazard resolving is interesting. but yes, branching is, too20:46
whitequarkI've used the standard RISC pipeline, and modified it for bf20:47
lars_5 stages is that, right?20:48
whitequarki.e. it does not have random memory access, and all the memory logic is hence moved to EX stage20:48
whitequarkand the M stage is gone20:48
whitequarkso, it is 4-stage20:48
whitequarkI'm currently doing register (just the accumulator, in this case) forwarding20:49
whitequarklooks like I just have to wire the execute stage to itself20:51
whitequarkas per the branches, I'll make ID stage lookup the branch in cache20:52
whitequarkthen, EX will either jump to the target or forward-track it20:52
whitequarkand WB will place it to the cache20:52
whitequarkthat was for the [; ] ones are resolved just with a stack20:53
kristianpaulnice http://koji.fedoraproject.org/koji/taskinfo?taskID=358758521:56
wpwrakroh: i must say i rather like the symmetries in your case design. they may it pretty easy to reverse-engineer.22:06
whitequarklekernel: okay, got it: BRAM has a latency of 1 cycle, so I need two cycles to get a result from it23:42
whitequarkand for instruction RAM, I can pipeline to hide the latency23:43
whitequarkbut data RAM has the same property23:43
whitequarkah, got it. I can raise CE as early as at the ID stage, not EX23:45
--- Fri Dec 16 201100:00

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