Bounty[PAID OUT] : a bitstream for better utilizing the Cairnsmore1 157-294.5btc

[makomk]

The 140 bitstream works fine.  160 hashes a few dozen shares and then falls over.  190 simply fails Icarus detect.

Yeah, this is honestly a mystery to me. I have no idea why it wouldn't work on cgminer. What error messages did cgminer give exactly?

[1714264883]

1714264883

[1714264883]

1714264883

[Glasswalker]

Just a quick touch-base.

A few things:

Makomk: Wow, excellent work, and fast! I'm impressed!

Second: It's not my call, but does the bounty not call for "Stable for 48hours" (which I would imagine would mean "Stable for everyone" not just "stable for some"). ie: does makomk's bitstream qualify yet? If it does, I'm glad for him, and the community, awesome work! But if not, the "race" is still on

Third: May I make a "suggestion" for a possible addition to the bounty rules? That would be "If one person achieves the required qualifications to earn the bounty, they must "hold" the position for 7 days in order for it to be awarded, and if during that 7 days, the majority agrees that another submission exceeds the qualifications of the first, then the 7 days resets for that new submission"

Yes I'm saying this because I still hope to claim the bounty but also from the communities perspective, this would promote some strong competition to keep driving performance up and up very quickly (potentially). Thoughts?

Lastly:

A small update, my UART code failed. I ended up tearing it apart completely and re-writing it. I've now got that UART code tested and verified working well. It also now has centering (samples the center of the waveform), oversampling, and filtering/smoothing for noise. In addition, I'm re-writing the serial protocol completely, to be a bit more flexible, and more importantly, include error detection and correction. I still need a bit of work to get that done, and then slide the new protocol into an Icarus based miner. But it should solve most of the communications problems we've been having (and we'll see if there are still other problems remaining).

In order to achieve this, I've also re-written my own controller bitstream. My board is running it now. It still lacks usb flash capabilities, so this isn't for the general public just yet, but once I get that working, and the miner mining, I'll release them together, as well as the source code for the new controller, making it a full opensource solution for the cairnsmore.

This new setup will allow the controller to act as a "communications hub" as it was intended. You communicate with it over a single usb channel, and it relays data to the chips behind it OR up and down the up/down interface ports to neighboring cairnsmore boards (that last feature isn't fully done yet, I'll worry about that once I get it mining stable).

Anyway, this also acts as an enabler to let me finish my 100% custom bitstream. So who knows, we might see all kinds of new advancements in the next little while

Anyway, I'm getting back to work, that's my update for now.

[spiccioli]

Just a quick touch-base.

Glasswalker,

can you give us some details about the problems with FPGA3 and/or (I don't know if they're related) boards with serial number less than 50?

Do you exactly know what's wrong on the hardware side and why FPGA3 does not work with your bitstream?

spiccioli

[Glasswalker]

I don't know exactly why, no...

But from the looks of it as I've said before, there is inductive noise on the comm/clock lines.

This noise (and it's severity) is different for each FPGA position, due to the routing of the wires, and proximity to other FPGAs, and so on. Position 3 seems to be the worst, so it is the least stable.

As for why the sub50 boards are bad, from what I understand, they added additional line termination to reduce noise/ringing and so on on the 50+ boards. So potentially the sub-50 boards suffer even worse from these problems.

Though most of this is conjecture, from observations, and the odd speculative chat back and forth with Yohan, so I won't say for certain that these are the problems. And there are still plenty of "tricks" that can be used to work around these problems. I still think the hardware is good, a few bugs sure, but I don't think these problems are killers.

I'm still hoping to get ahold of mokomk to find out exactly what he did to get it to work as stable as he did, from what he said to me on IRC only 2 minor tweaks to the raw icarus source code, which is to be frank, SHOCKING since I tried a standard build of icarus (with the appropriate pin swap and such) and it failed miserably. And I've been tweaking, and trying various builds for months now. So if he made specific changes for a reason, then I'd love to know his reasoning (might help identify the root cause of the problems). But if he just tried some random fixes and lucked into a solution that's fine too (either way it could help us narrow down the root cause).

Does that help?

[Hpman]

Just flashed the Controller 1.3 update and the Makomk bitstream. I didn't try other bitstreams than twin_test so i cant compare. At the moment it seems very good, the one board i have delivers 2000 share (40 rejected) and cgminer reports u=10.0. BUT, i have had problems during flashing the controller file. With original cable it fails multiple times  (verify error on different positions), but replacing cable without removing power! helped. Xilinx cable was available too but not needed . Board number is 015X.

Why does the icarus bitstream uses 2 coms on cairnsmore and not as expected only one?  Thought only one pair has crossed TX/RX.
Does makomk uses comx for P0 and P1 and comy for P3 and P2? Still miss public documentation about the cairnmore board itself.

[spiccioli]

I don't know exactly why, no...

[...]

Though most of this is conjecture, from observations, and the odd speculative chat back and forth with Yohan, so I won't say for certain that these are the problems. And there are still plenty of "tricks" that can be used to work around these problems. I still think the hardware is good, a few bugs sure, but I don't think these problems are killers.

Does that help?

Yes thanks,

it eases my mind to know that you still have tricks up your sleeve to work around FPGA3 issues

spiccioli

[ebereon]

...
I'm still hoping to get ahold of mokomk to find out exactly what he did to get it to work as stable as he did, from what he said to me on IRC only 2 minor tweaks to the raw icarus source code, which is to be frank, SHOCKING since I tried a standard build of icarus (with the appropriate pin swap and such) and it failed miserably. And I've been tweaking, and trying various builds for months now. So if he made specific changes for a reason, then I'd love to know his reasoning (might help identify the root cause of the problems). But if he just tried some random fixes and lucked into a solution that's fine too (either way it could help us narrow down the root cause)...

Thats now really hard to read...

First you ask about changing the bounty rules to have the ability to claim it as Makomk already reached it...

and now you hoping for help from Makomk to get yours running and claim the bounty?  What is that please?

Explain this.

eb

[Glasswalker]

Lol stop reading too much into things.

Do I want to claim the bounty? yes

Am I glad makomk built a working one, and would I be happy for him if he claimed the bounty? yes

Do I want to help the bitcoin community by solving the problems on the enterpoint boards? definitely

I'm not trying to steal his ideas. I'm already going in a completely different direction. But if he made a couple tiny tweaks (as he said on irc "2 minor tweaks to icarus") and that solved most of the stability problems, those 2 tweaks could go a long way to helping everyone here. (by identifying the root cause of at least the worst of the stability issues). The engineer in me is curious as hell how he did that (when I struggled for so long to achieve it). ie: "where did I go wrong?"

As for how he got to 190Mhash, I'm not concerned about that. My 175Mhz bitstream should run just as well at 190Mhash if I had clocked it that high (if not better), but my 175Mhz bitstream is closed to "Xilinx specified timing". For now I'm focusing on trying to win stability, then I'd push as much performance as possible. Makomk managed to get stability early, so he released "overclocked" versions which are outside spec (and run fine). Because my bitstream never overcame the communications problems it made no sense to push it further (yet).

My suggestion was to open the bounty up for competition beyond the "first one to reach point X wins" approach, because I thought it would be an interesting race, which could drive up performance quickly. And yes to some degree, that leaves the door open for me to win the bounty. It also means if I achieve the bounty, (and release the source to it) that someone else will come along and beat my performance within a week, requiring me to "defend my title" and so on. And through all this back and forth, the bitcoin community wins by seeing fpga hash rates go up and up and up...

Makomk has released the source to his bitstream.

I've released the source to mine.

This isn't a war of secrets

Oh and a clarification:

First you ask about changing the bounty rules to have the ability to claim it as Makomk already reached it...

I don't believe makomk has claimed it YET, but I do think he's made an amazing breakthrough. Just because You believe that he has won it because you're having success, doesn't mean the majority is having stability with it yet (I see people posting it doesn't run at all on some boards, on others it's only 3 chips, and so on). But it's not my call. If the majority of the contributors agree, then great he wins! and I'm happy for him. I wanted to clarify in that post since you were claiming all over the place that he has won now, that we should wait and see if it's actually stable, reliable, documented, and so on as the requirements state. AND I posted a suggestion which I thought would make things more interesting.

[Isokivi]

Regarding the Makomk's shortfin icarus 190mhs bitstream.

Bounty terms and pledges.

These are the final terms:

1. We need to be able to upload the bitstream on to boards with an usb cable.
2. The bitstream needs to achieve an average speed of 760Mhs/board. Reports of this not happening on some boards, lets wait for more reports on this.
3. The bitstream does not include any forced donation of hashingpower.
4. The bitstream needs to be able to run stable without manual intervention for 48 consecutive hours. Were not there yet, waiting for more reports on this
5. Enterpoint's own bistream development is excluded from recieving the bounty, however if they deliver before anyone else does it closes the bounty.
6. The bistream needs to be open sourced and documented I dont see this being the case now.
7. Many people have pledged more, under very specific terms, I will not count those pledges in to the total in this post, just to keep things simple.
8. If the bistream is released before 31.8.12 (8-31-12 for confused Us-residents) there are signifigant additions to the bounty that will be listed in a separate total, ilnluding the entire bounty.
9. glasswalkers solution, even if released by enterpoint will qualify for the bounty if all other qualifications are met.
/ccc?key=0Au2jspuzErkedHhDSEt5aTVPcUNMMjg4STVnOWV3VkE#gid=0[/url]

This is my opinnion of the state of the bounty, imho the race is still on, but we do have a clear leader.

[spiccioli]

I don't know exactly why, no...

But from the looks of it as I've said before, there is inductive noise on the comm/clock lines.

This noise (and it's severity) is different for each FPGA position, due to the routing of the wires, and proximity to other FPGAs, and so on. Position 3 seems to be the worst, so it is the least stable.

[...]

Can the noise that FPGA3 suffers come from the fan which in all my boards is connected to the pins beside FPGA3?

spiccioli

[steamboat]

More important to me than 760 mh/s is stability. I work and go to school and I simply don't have time to be resetting my rig every day. I'm very grateful to Mamomk for all his work but I do agree with Glasswalker that the solution needs to be stable across a wide cross section of boards before it's deemed a winner. I also like the idea of having to hold the title for 7 days before claiming the prize, though I imagine some spirited competition may drive the claiming the bounty into sept/oct

All that being said, regardless of who wins the bounty, I will donate an additional 1btc per board (9 currently) to the runner up, whether it be glasswalker or mamomk or surprise competitor #3, as I appreciate both of them working on this, and hope it will motivate them to continue to improve on their respective bitstreams.

[Glasswalker]

You know, that's an interesting thought...

I believe on the default controller bitstreams it monitors fan rpm, and kills mining if the fan isn't turning, so it might be hardcoded right now for that port. But you could always try moving the fan to one of the other fan headers and see if it affects the noise.

Once I get a bit further with mine I'll test the same (if I still have problems with communications)

[spiccioli]

You know, that's an interesting thought...

I believe on the default controller bitstreams it monitors fan rpm, and kills mining if the fan isn't turning, so it might be hardcoded right now for that port. But you could always try moving the fan to one of the other fan headers and see if it affects the noise.

Once I get a bit further with mine I'll test the same (if I still have problems with communications)

I've just tested it on one board, controller 1.3, moving fan connector to the one beside FPGA0 does not stop the board, so it seems that it is not hard-coded.

spiccioli

[Glasswalker]

Any noticeable difference in mining with any of the bitstreams that presented problems on that slot before?

[spiccioli]

Any noticeable difference in mining with any of the bitstreams that presented problems on that slot before?

I don't know, board kept hashing.

I think I should test it on board #8, but on that board I can't install makomk's bistreams and I have the old twin_test.bit running.

Yohan, on the other hand, should have the means to test if it is the power to the fan creating problems.

spiccioli.

[yohan]

You know, that's an interesting thought...

I believe on the default controller bitstreams it monitors fan rpm, and kills mining if the fan isn't turning, so it might be hardcoded right now for that port. But you could always try moving the fan to one of the other fan headers and see if it affects the noise.

Once I get a bit further with mine I'll test the same (if I still have problems with communications)

I've just tested it on one board, controller 1.3, moving fan connector to the one beside FPGA0 does not stop the board, so it seems that it is not hard-coded.

spiccioli

You can plug in the fan to any position. Our safety feature looks for a minimum of one fan rotating. You can override this using SWITCH2 and run a fan totally independently powered.

[Entropy-uc]

The 140 bitstream works fine.  160 hashes a few dozen shares and then falls over.  190 simply fails Icarus detect.

Yeah, this is honestly a mystery to me. I have no idea why it wouldn't work on cgminer. What error messages did cgminer give exactly?

On the 160 Version CGminer reports an Icarus failure and changes the board status to 'off'.

For the 190 version, it fails Icarus detect.  'get 000000 should...'  I tried the 190 on a couple different boards with the same result.  The best I ever got was one half of the array detecting successfully.  This hashed for about 6 hours before failing in the same manner as the 160.

I will try a couple different boards and USB cables later tonight and let you know how it goes.

I really appreciate all the work you have done.

[Lethos]

Until I can get it to work on my machine, which has been happy and stable on the standard v1.3 version from enterpoint for almost 2 weeks now uninterupted, I can't consider it a valid bounty payout. I'm still in the process of getting Makomk bitstream working via my linux machine, which proving harder than I expected it to be.

I'm sure it could be bounty worthy, but give a few days, until more people can say it definitely lasts long enough to be a stable release.

[makomk]

On the 160 Version CGminer reports an Icarus failure and changes the board status to 'off'.

Weird. Unless I'm missing something - which I might well be - the only thing that would cause that to happen would be the USB serial device disappearing out from underneath CGminer. While that has been happening to a lot of people, it shouldn't be affected by which bitstream you use. Then again, nothing's impossible, particularly with the CM1.

For the 190 version, it fails Icarus detect.  'get 000000 should...'  I tried the 190 on a couple different boards with the same result.  The best I ever got was one half of the array detecting successfully.  This hashed for about 6 hours before failing in the same manner as the 160.

Now that's more common unfortunately. I don't suppose you have the numbers it reported?

[Isokivi]

Regarding the Makomk's shortfin icarus 190mhs bitstream, things for me after the 14h testrun.

Bounty terms and pledges.

These are the final terms:

1. We need to be able to upload the bitstream on to boards with an usb cable. Check.
2. The bitstream needs to achieve an average speed of 760Mhs/board. Reports of this not happening on some boards, lets wait for more reports on this. 719Mhs, I do have 2/16 cores in there that arent apparrentley working and I have the option of plugging in a slower bitstream to these fgpa pairs. In my opinnion a solution achieved via this is kind of touch and go in relation of the bounty terms. AND im not going to try it for now because asfar as I know the recommended "swap is if fail" bitstream (makomk's 160mhs) wont detect the boards in cgminer... correct if im wrong here.
3. The bitstream does not include any forced donation of hashingpower.
4. The bitstream needs to be able to run stable without manual intervention for 48 consecutive hours. Not there yet, but things are looking good.
5. Enterpoint's own bistream development is excluded from recieving the bounty, however if they deliver before anyone else does it closes the bounty.
6. The bistream needs to be open sourced and documented. Not yet.
7. Many people have pledged more, under very specific terms, I will not count those pledges in to the total in this post, just to keep things simple.
8. If the bistream is released before 31.8.12 (8-31-12 for confused Us-residents) there are signifigant additions to the bounty that will be listed in a separate total, ilnluding the entire bounty.
9. glasswalkers solution, even if released by enterpoint will qualify for the bounty if all other qualifications are met.
/ccc?key=0Au2jspuzErkedHhDSEt5aTVPcUNMMjg4STVnOWV3VkE#gid=0[/url]

This is my opinnion of the state of the bounty, imho the race is still on, but we do have a clear leader.