| kristianpaul | whitequark: dont relly to much on xilinx specif stuff | 01:39 |
|---|---|---|
| kristianpaul | remenber we may want to move easilly to others fpga in the future | 01:39 |
| whitequark | kristianpaul: well, that just fixes a bug in xst parser | 02:31 |
| whitequark | "fixes" | 02:31 |
| whitequark | actually, it was my own error -- some weird thing with macros -- but it still crashed the translator. | 02:32 |
| wpwrak | this is why those open source hippies will never be able to compete with professional closed source work ;-) | 02:52 |
| whitequark | wpwrak: fully agree. | 03:01 |
| whitequark | hmmmokay. | 03:01 |
| whitequark | I need some kind of barrier in my CPU... | 03:02 |
| kristianpaul | ha, milkymist-ng not bad | 03:02 |
| kristianpaul | very interesting way of creating and sinthesizing SoC :-) | 03:03 |
| whitequark | can someone hint me a way of doing dual-port _write-first_ memory in verilog? | 03:07 |
| kristianpaul | milkymist have some examples of this | 03:08 |
| kristianpaul | in the softusb core (hdl), also minimac2 core (as xilinx lib) | 03:08 |
| whitequark | ok nevermind. I already invented a way | 03:09 |
| whitequark | now I wonder if xst is clever enough to infer the correct BRAM | 03:09 |
| kristianpaul | HA ! | 03:09 |
| kristianpaul | check hdl coding style guide from xilinx | 03:09 |
| whitequark | true programmers do not read documentation! :D | 03:10 |
| kristianpaul | hum dont think so.. | 03:10 |
| whitequark | that was a joke. | 03:10 |
| kristianpaul | and there is no xst source code to read instead ;) | 03:10 |
| whitequark | well, there is always zen | 03:10 |
| whitequark | you can look at xst veeery intently and understand everything you need. | 03:11 |
| whitequark | ... probably. I was never able to do that :D | 03:11 |
| kristianpaul | http://milkymist.org/wiki/index.php?title=HDL_guidelines | 03:12 |
| kristianpaul | http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/xst.pdf | 03:13 |
| kristianpaul | HDL coding techniques | 03:13 |
| whitequark | yeah, already found that | 03:14 |
| kristianpaul | ah well.. | 03:14 |
| kristianpaul | also the Libraries Guide for spartan-6? | 03:14 |
| whitequark | sure | 03:15 |
| kristianpaul | ok.. | 03:15 |
| xiangfu | 16 years, 7 months, and 4 days of RTEMS history are moving to Git. | 03:18 |
| kristianpaul | link link ! | 03:18 |
| kristianpaul | i want get rid off that cvs... tooo slow | 03:18 |
| xiangfu | kristianpaul, http://www.rtems.org/wiki/index.php/CVStoGit | 03:22 |
| xiangfu | not finish yet. so the git is may not sync with cvs. | 03:22 |
| kristianpaul | ah.. | 03:23 |
| xiangfu | kristianpaul, 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 |
| wpwrak | kewl. we'll only have the ones with the botched FPGA left :) the ones that sometimes enter hectical reset oscillation | 04:55 |
| cladamw | yeah... still no further idea on reset oscillation likes 0x32. :) | 05:07 |
| xiangfu | cladamw, I still not fix the boot.bin buy. sorry. | 05:16 |
| xiangfu | cladamw, the PHY ID I needs ask Sebastien. | 05:17 |
| cladamw | xiangfu, no sorry. I was thought it's easy. :) | 05:17 |
| xiangfu | CRC is a strange error. I tried many method. it maybe ALIGN problem. | 05:17 |
| xiangfu | CRC BUG is like. all other test is working. only when press 'a -- tests_images' it will hang the system. | 05:18 |
| 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. :-) | 05:21 |
| wpwrak | cladamw: (0x32) i think it's simply a damaged fpga. maybe ESD, maybe excess heat. | 05:25 |
| cladamw | wpwrak, okay... the worse case that I remove fpga then remount it. not decided yet. :-) | 05:27 |
| 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 :) | 05:31 |
| 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 | 05:34 |
| cladamw | it was removed. | 05:34 |
| wpwrak | nice and clean removal indeed | 05:35 |
| 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. | 05:35 |
| wpwrak | phew :) | 05:35 |
| wolfspraul | wpwrak: we should go watch some professional reworkers in factories, you would be *amazed* | 05:36 |
| wolfspraul | our hands are magic | 05:36 |
| wpwrak | wolfspraul: yeah,. i've seen some crazy rework when we did the hxd8 tear-down experiments | 05:36 |
| 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. | 05:36 |
| wolfspraul | just think what a pianist is able to do after 10+ years or more of training for hours each day | 05:36 |
| 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) | 05:37 |
| cladamw | to make a "small" square stencil with 484 apertures. | 05:37 |
| 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 | 05:38 |
| wolfspraul | so any manufacturer is well advised to not let that capability sink too low, otherwise they will have yield problems sooner or later | 05:39 |
| wolfspraul | just my thinking | 05:39 |
| 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. | 05:41 |
| 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). | 12:59 |
| lekernel_ | BTN2? the button? | 13:06 |
| 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. :-) | 13:07 |
| cladamw | lekernel_, yes. the BTN2 is the signal to activate bootup procedure. :-) | 13:07 |
| 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 | 13:09 |
| 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. | 13:10 |
| cladamw | just guessed in this way. I'll let it run overnight and keep an eye on that level again. :-) | 13:11 |
| xiangfu | the boot.bin problem is the crc32 fault. :( | 14:10 |
| GitHub82 | [autotest-m1] sbourdeauducq pushed 1 new commit to master: http://git.io/q6IF8A | 14:32 |
| GitHub82 | [autotest-m1/master] Fix new compiler warnings - Sebastien Bourdeauducq | 14: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_Q | 14:39 |
| GitHub139 | [autotest-m1/master] MIDI: support new uart core, correctly this time - Sebastien Bourdeauducq | 14:39 |
| GitHub69 | [autotest-m1] xiangfu pushed 1 new commit to master: http://git.io/PIBQuw | 14:57 |
| GitHub69 | [autotest-m1/master] some variable names cleanup - Xiangfu Liu | 14:57 |
| GitHub68 | [autotest-m1] xiangfu force-pushed master from fb05b90 to 50d40bb: http://git.io/FNP5fw | 14:59 |
| GitHub68 | [autotest-m1/master] some variable names cleanup - Xiangfu Liu | 14:59 |
| xiangfu | sorry. should be const. not static. | 15:00 |
| 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. | 15:12 |
| whitequark | will a synthesizer eliminate common subexpressions or I should do that myself by defining explicit wirs ? | 17:58 |
| whitequark | *wires | 17:58 |
| kristianpaul | whitequark: yes | 19:05 |
| wpwrak | kristianpaul: "tea or coffee ?" "yes" :) | 19:13 |
| lars_ | wpwrak: "teoffe" | 19:19 |
| kristianpaul | wpwrak: aromatica ;-) | 19:22 |
| kristianpaul | Fines herbes tea english name is i think | 19:24 |
| kristianpaul | lol | 19:24 |
| kristianpaul | you always making laught of me :) | 19:24 |
| kristianpaul | whitequark: yes you should define constraints i meant | 19:25 |
| whitequark | kristianpaul: ah. thanks. | 19:34 |
| whitequark | then a lot of my code is horribly ineffecient :/ | 19:35 |
| Action: whitequark goes to rewire the whole pipeline 4th time this day | 19:35 | |
| kristianpaul | it depends what you want to do anyway? | 19:35 |
| 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? | 19:36 |
| whitequark | kristianpaul: I'm not sure if the subexpression elimination will be visible as waveforms | 19:36 |
| whitequark | it's more of FPGA space (and speed) concern | 19:36 |
| whitequark | well, RTL looks horrible, so I guess I'm doing that wrong | 19:37 |
| lars_ | rtl looks always horrible ;) | 19:51 |
| whitequark | lars_: in the more clean parts of my design, rtl is exactly like it was wired by a person | 19:58 |
| lars_ | and what are you doing in the not so clean parts? | 20:14 |
| whitequark | lars_: this https://github.com/whitequark/bfcpu2/blob/master/verilog/StageExecute.v expands to this: http://rghost.ru/34951311.view | 20:16 |
| lars_ | i can really see anything in the png. but what would you've expected instead | 20:23 |
| lars_ | ? | 20:23 |
| whitequark | lars_: at least an addsub | 20:24 |
| whitequark | ah sorry, that's my error | 20:25 |
| whitequark | it 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 |
| whitequark | lars_: ascii | 20:43 |
| whitequark | I'm going to make a pipelined cpu with branch target caching | 20:44 |
| wpwrak | finally i can run all my brainfuck programs on decent hardware ;) | 20:44 |
| whitequark | wpwrak: at last, someone got the idea! :D | 20:45 |
| lars_ | whitequark: yes i guess the loops are the interesting part | 20:45 |
| whitequark | lars_: for me, even proper hazard resolving is interesting. but yes, branching is, too | 20:46 |
| whitequark | I've used the standard RISC pipeline, and modified it for bf | 20:47 |
| lars_ | 5 stages is that, right? | 20:48 |
| whitequark | i.e. it does not have random memory access, and all the memory logic is hence moved to EX stage | 20:48 |
| whitequark | and the M stage is gone | 20:48 |
| whitequark | so, it is 4-stage | 20:48 |
| whitequark | I'm currently doing register (just the accumulator, in this case) forwarding | 20:49 |
| whitequark | looks like I just have to wire the execute stage to itself | 20:51 |
| whitequark | as per the branches, I'll make ID stage lookup the branch in cache | 20:52 |
| whitequark | then, EX will either jump to the target or forward-track it | 20:52 |
| whitequark | and WB will place it to the cache | 20:52 |
| whitequark | that was for the [; ] ones are resolved just with a stack | 20:53 |
| kristianpaul | nice http://koji.fedoraproject.org/koji/taskinfo?taskID=3587585 | 21:56 |
| wpwrak | roh: i must say i rather like the symmetries in your case design. they may it pretty easy to reverse-engineer. | 22:06 |
| whitequark | lekernel: okay, got it: BRAM has a latency of 1 cycle, so I need two cycles to get a result from it | 23:42 |
| whitequark | and for instruction RAM, I can pipeline to hide the latency | 23:43 |
| whitequark | but data RAM has the same property | 23:43 |
| whitequark | ah, got it. I can raise CE as early as at the ID stage, not EX | 23:45 |
| --- Fri Dec 16 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!
