Bitcoin Forum

As atleast everyone who onwns one knows these boards arent performing to expectations because we do not have a proper bitstream yet. Im starting a bounty for it so that the brilliant individuals working on one can miss work if need be to provide us with one. As of now Im opening the discussion up for what should be the terms for this bounty. I personnally would be somewhat satisfied with a solution that can mine continuously for 48 hours without need for any manual upkeep at a hashing speed exceeding 750Mhs. At this time I think Im pledging one bitcoin per board owned and I feel such a sum from everyone owning a board would be reasonable. As far as I know there are atleast 450 of these boards in the wild, presumably more.

One of the issues up for discussion is wether the bounty applies to a solution requiring a 3rd party web-service Ie. eldentyrells solution.

I'll wait for replies for a couple of days before finalizing the bounty.

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.
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.
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'm no expert here, need help on the wording of this term)
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.

Current amount pledged:

Participating forum members and pledge amounts:

Isokivi  3btc
roomservice 10btc
dietwice 1btc (per board owned, total unknown)
misternoodle 1btc
steamboat 9btc
daemonic 1btc
spiccioli 20btc
Chefnet 1btc
Hpman 1btc
salty 1btc
Lethos 5btc
Gomeler 10btc
Arvicco 30btc
Slipbye 50btc
ShadesOfMarble 2btc
Feefox 5btc
julz 1btc
Cranky4u 2btc
tf101 2btc
doff 2btc

total: 157btc

31.8.12 (8-31-12) deadline bounty:
zefir 75btc
Entropy-uc 50btc
tnkflx 12.5btc

total: 294.5btc

Zefir will be holding the bounty in escrow. He's address is 1CM1bj7jxVskkvKE2kcw6L16rHMXL38aFm
PM zefir when you send your btc.
Theres a spreadsheet about it at https://docs.google.com/spreadsheet/ccc?key=0Au2jspuzErkedHhDSEt5aTVPcUNMMjg4STVnOWV3VkE#gid=0 (https://docs.google.com/spreadsheet/ccc?key=0Au2jspuzErkedHhDSEt5aTVPcUNMMjg4STVnOWV3VkE#gid=0)

Great idea, thanks for opening this thread.

Putting 10 BTC into the Bounty myself!

I would like to see a bitstream that can be loaded via usb interface. Dont wanna mess with jtag cable.

I'm in.

Count me in for 1BTC.

i'm in for 9

add another 1BTC to the pot :)

I'm in with 10 BTCs

spiccioli

You should send a board to ZTEX ;)

I am willing to support this bounty, but also agree with Entropy-uc that it does only makes sense if the folks mining with CM1 can profit from it.

Right now the greatest uncertainty factor is how 'soon' Enterpoint will provide their dedicated CM1 bitstream unleashing the full power of the board. Nobody would start working on a new bitstream when we fully make it dependent on non controllable third party events - it must be a combination of intra- and interdependent compensation.

This is how I would word my contribution to the pledge:

1) I will pay out 50 BTC to the first community member that develops and releases a bitstream for CM1 before 2012-08-31 that provides long term operation with an average hashrate of at least 760 MHps per board. The bitstream does not need to be open sourced itself, but the API must be provided along with a proof-of-concept implementation support for an established open source miner (cgminer, MPBM, etc.) and full step-by-step documentation to reproduce the correct set-up.

2) Starting from the release day of the developed bitstream and until 2012-10-30, for each day I will pay the developer a performance bonus of (B - N) / 200, where B is the bitstream's hashrate and N is the hashrate of the second best publicly available bitstream. Example: if B was 840MHps and twin_test.bit still the fastest one with 380MHps, I'd pay a daily bonus of 2.3 BTC until end of October. The bonus payments are calculated daily, i.e. from that day Enterpoint provides a bitstream operating at 760MHps, the bonus drops to 0.4BTC/day for the remaining period.


I must admit that I don't have a clue on how long it takes to develop a new bitstram from scratch (seeing that ngzhang is already months late for Lancelot raises some doubts). Also I did not put much thinking on whether the both incentives are well balanced. It is a first shot, but this is basically what I would be willing to contribute.

I agree with most of that.
Open source would have to be part of the deal, I'd gladly put some bitcoins towards that.
Don't care who makes it, could even be enterpoint themselves, might encourage them to speed up the process.

I agree that it is unfair to cut off the bounty solely on an Enterpoint release, and would discourage anyone from working on it.  Part 2 of your proposal makes me dizzy and you're going to get into debates on the actual values for each delta to calculate it.

I will make one caveat here. I will not pay a single Satoshi for delivery of a bitstream with any form of copy protection, that includes ET's sharecropping scheme or anything else that would prevent loading on any compatible board.

I will match Zefirs commitment of 50 BTC for any bitstream that meets or exceeds the 750 MH/s rate and 48 hour stability up until August 31st, or the earliest Enterpoint release of a 4 processor hashing bitstream whichever happens last.

Further I offer 100 BTC as a bonus under the following conditions:
1.  At least 300 BTC including my 50 BTC above is committed to the bounty by the community under the terms finally agreed upon (minimal free riders)
2.  All the files required to build the bitstream are published and released under a version of the GPL or more permissive license terms.
3.  The bitstream is released on or before August 5th.
4.  No Enterpoint bitstream using all 4 FPGAs has been released beforehand.

Well damn, im glad this thread is here. It shoulden't be too hard to get the other pair of fpgas working with an icarus bitstream that would be a good amount of btc for not much effort. Unless of course the controller has issues, which I think it does then an open source bitstream just for the controller would be a good idea.

I also prefer requirements to be kept simple. But I had one specific thing in mind with my second part: competition for higher speed. We have two measures to achieve here, getting a fast bitstream and getting it soon. Paying only the developer that shows up first biases the development effort towards a bitstream that just passes the minimum requirement but no more. Say someone that is already working on a bitstream and delivers 750MHps begin of August, but someone else had an idea for a 900 one, but this will take him at least end of August to finalize. The second part of my proposal would allow him at least to earn the delta for some while and motivate him to finish his work even when we had already a 'winner'.

I do not like ET's approach either, but if someone succeeds to run it on CM1, I will use it. Alas, this would not qualify to get the bounty we are discussing here - fully agree that it must be a transparent bitstream that operates with any established pool without third party interaction.

Not sure if 'whatever happens last' is ok. What if Enterpoint releases a bitstream late (say: never)? I am not going to pay for that in 2013. Shouldn't it be more 'whatever happens first'?

To
1: if there are 400+ boards in the wild and anyone is willing to contribute 1BTC per board, we should reach that.
2: a) there might be NDA information that prevents open sourcing
    b) also preferring open source, but does it really help here? we have Icarus source available, but nobody is able to correct one RX/TX line swap ???
    c) if it goes open source, those who contributed to the bounty should get it 4 weeks before it goes public (incentive against free-riding)
3: is this realistic? this are only two weeks from now on, do you think Enterpoint had not already provided a bitstream if it was that easy?


All in all, we should reach a consensus soon and have 500-1000BTC waiting for a smart developer, which (besides theymos' offer for rewriting SMF) should be one of the largest bounties around :)

in with 1BTC

I'v already tried to generate an icarus based bitstream few weeks before. ISE project files were missing but there was a short description http://en.qi-hardware.com/wiki/Icarus#FPGA_core how it works. Without manual optimization and with the included sythesis tool the build fails during place and route. Guess using synplify instead may helps but i did't have access to that and i would be surprised if enterpoint have a license. I did'nt spent much time and i did'nt check anything around(verilog, ucf files..) so maybe there are other options like reducing pipes to get a slower but usable bitstream for the two lazy cores.

Hpman

I forget one thing - I'm in with 1BTC too.

Once things get started, they are getting momentum ;)

Yohan's announcement (https://bitcointalk.org/index.php?topic=78239.msg1044709) to me sounds like Glasswalker successfully took a major hurdle and might finalize what he is working on soon.

I am still committed to support the bounty, but do we need to clarify that the winner can't be Enterpoint or someone already being paid for his work by Enterpoint? Or do you think it would be ok to pay the bounty on top of the payment as additional incentive to hurry up?

Given that we're using our boards at half their speed (or even less) I'd say I'm willing to send Glasswalker my bounty if he is the one behid Yohan's announcement if he can give us a solution and he is willing to support it for as long as it takes to have a stable bitstream/miner program.

spiccioli.

First let me say thank you very much for your consideration and support for my "troubles" of late :) It's nice to not have someone crying for my blood these days ;)

Also to clarify the speculation on this thread. Yes I have made a fairly major breakthrough on the bitstream... And I would be GREATLY appreciative of any help this bounty can give me (provided I can satisfactorily meet your criteria).

Some quick pieces of info:

- I am working on a 100% custom bitstream, which I am not very close to completing (weeks away at the least, it's EXTREMELY complicated as ET, Enterpoint, and ngzhang can all confirm for you I'm sure). And it takes a HUGE amount of time just to do a test compile/synthesis. Even more for optimization.

- In light of the large delay from a better release, I have shifted my efforts back to an opensource bitstream port of the Icarus bitstream. I had some inspiration/realizations that I thought would allow me to succeed getting an Icarus based bitstream (with several modifications and many fixes/tweaks) to run well on the Cairnsmore1. So I began working on it again.

- I am working on 2 parallel forks right now, mainly because I have 2 workstations, my powerhouse (which is actually owned by my employer, but they let me use it for "side projects" when it isn't tied up with work for them) and the other is my home machine. My home machine is not a super-powerhouse, but it can still do fairly decent compiles, so I use it for my main development machine, and for doing initial builds of the bitstream (a single "compile" to a finished bitstream takes about 4 and 48 hours on my home machine, yes it varies that much depending on several factors). The work machine can run about 12 compiles in parallel at about the same speed. And so Xilinx has a tool called SmartXplorer, which basically spawns off a cluster of every possible compile option, attempting to optimize the hell out of the bitstream to improve clock timing, or placement, or resource utilization, or whatever... I use my work machine for this tool, it runs 12 in parallel, and it runs around 100 passes to come to a full optimization.

- I have built a 200Mhash/fpga (so 800mhash on the cairnsmore1) bitstream on my home machine, but it did not meet timing (it was only able to achieve about 50% clock). I then started it running the optimization at work about 1 week ago. As of Friday it was about 75% complete, but one of the "candidate" builds was VERY close to meeting timing. So I sent it to enterpoint to do testing on their test rig. They were able to achieve some good results (200mhz per chip stable for 30min straight, but it locks up when doing real hashing). This particular candidate was only off from meeting it's timing by about 5%. So a minor additional improvement may help.

- Since that build, last week... I started a second "fork" of the code, with several additional adjustments, fixes, and a few new added features to hopefully improve stability greatly of both the clocking, and the communications code. This fork right now is built around a 175Mhz clock, meaning that each FPGA would pull 175MHash/s (700MHash/s for the whole board). But it can easily be tuned in 25Mhz increments. (meaning 200Mhash is a fairly short step up for it, and it's a minimal modification).

- Once the 200Mhz build is done optimizing (which it should be today, but I need to head into my office to confirm if it finished and check status). I'll fire up the optimization pass on the 175Mhz version. The "original" build of the 175Mhz one is MUCH closer to meeting timing than the 200Mhz one was, and it has improvements for communications and stability. So hopefully it will close timing much faster (ie one of the early attempts will meet the timing requirement, providing a rock solid stable build). If this happens I will send it immediately to Enterpoint, for testing and "official" release.

- My hope is that either the 200mhz one will have succeeded, and that's a quick win later today, or that the 175mhz one will succeed early on, and allow a quick incrimental improvement up to 200mhz after initial release.

- Once I achieve a successful build of the opensource bitstream, I will resume my work on my "from scratch" bitstream. It should significantly outperform the opensource one, but it's a ways off still...

- As for compensation agreement. I have an agreement with enterpoint for the "from scratch" one, that if I release it before they finish their own, they will license it from me for a fixed fee. As for the opensource one, it's opensource. So when I'm done I'll gladly release the source (right now it's in too high a state of flux, and I don't have the spare time to deal with releasing/documenting it right). One concern though, one of the main problems with the icarus code is that it wasn't released by ngzhang in a way that allows an easy build. It's missing all the project files, and so it took a fair bit of work just to get it to build. And I found out (through much digging) that ngzhang requires the use of another third party tool which is commercial, and very expensive to even successfully build his code in the first place (which I believe he pirated). So the code derived from the icarus code may be useful to someone with a fair bit of experience, but it's not the kind of thing that could be setup so "anyone can build it" because the original source requires special tools and so on which aren't free... And I've had to carry this over unfortunately, even with my modifications. But I will do my best to release it in a way that is documented well and includes as many of the missing pieces as possible, so hopefully someone with more time in the community can improve upon it further.

- Anyway, so that's all the facts laid out in the open for you. I'd be extremely happy for any help this bounty can provide once I actually deliver a working bitstream. My motivation for this was never the direct compensation from Enterpoint, though that helped sweeten the pot some, but more so the fact that the syndicate was buying a large amount of cairnsmore boards and this would help us profit from them better. And hopefully I could make a few bucks on the side for my work (which is not being done as part of the syndicate by the way).

- As a rough gauge as to level of effort... For the "from scratch" bitstream, I have put approximately 200 hours of work into it so far (in my own time outside my day job). And the opensource bitstream has required another approximately 80+ hours of the same so far on getting it to the stage it's at now. So this is not a simple task by any means.

- Not that it should matter in your decision making process, but if this works out and I can claim the bounty, I will use the money to help rebuild the syndicate in light of the money that was stolen. But that said, I want to be clear in my intentions. I do not believe I am at fault for what happened, and I stand by my decisions. It was tragic that the money was stolen from myself and the syndicate in the way it was. This work was always "my" work, not the syndicates. And so while I will use the money to help rebuild the syndicate, I will not directly "give" the money to the syndicate. Both because I don't feel it's neccisary, and because I feel that doing so would in a way, be an admission of guilt (and I am not guilty of anything here). What I propose to do (provided my shareholders agree) is to use money you provide, and any "compensation" from enterpoint to aquire Cairnsmore boards, which will be loaned to the syndicate to mine for the syndicate until the syndicate is caught back up to 12Ghash of it's own mining power (which is where it was before the theft). I will likely mine for them longer than that to help build it up further of course, but that's the approach I intend to take if I can gain this bounty.

Anyway I hope that helps clarify for you, I'm going to quit writing a giant wall of text now, and get back to work on that bitstream!

(oh and one last thing, in addition to the money, it would be nice to throw in condolences to my wife for loosing her husband for the past couple months while I worked on this in addition to my already demanding day job) lol.

Let me know your thoughts. And it would be nice to see a single centrally clarified post of what the "criteria" are for this bounty, so I know where my "goalposts" are.

Thanks!

I think if enterpoint also honor him it is only fair to give the bounty.
I will send my BTC to you.

To clairify, I haven't achieved an improved bitstream YET... But hopefully soon ;)

I hope you didn't mean you'd send ME your money now (but the OP so he can gather the bounty) :)

Just clarifying, didn't want a misunderstanding. I DO however hope to succeed very soon. I'm busting my ass to get this working.

Thanks to you!  I can imagine how much time it consumes and how difficult it is find this time beside the daily business.

Do you work on the array controller also? What additional third party tools was in the game ?


 

Glad we got people like Glasswalker working on this.

Thank you!

Fair enough. Thanks for all of your support.

I hope I can stand up to your expectations and deliver very soon.

As for the controller, It was built purely by enterpoint. I have access to their source code and I have played with it (and made several suggestions to them, some of which have been implemented) but all the code at this point has been written by them. I have some ideas for it, but I'm focusing 100% on the matrix chips for now.

I'll post more information once I have it. It's a slow process but I definitely feel like I'm VERY close right now. At the very least you should start seeing several incremental improvements over what you have now in the coming days.

Thanks again.

To be fair to ngzhang, he lists the software he uses and the fact that it's pirated. Piracy is legal in China and makes up a sizeable chunk of their economy.


From the icarus thread:

4, DEV kit include a XILINX platform cable USB, a USB stick with XILINX ISE 13.2/ altium 10/ synplify 2011.03, modelsim 10, all with crack but use as your own risk, commercial use is  illegal in my country (but legal for personal use in my country )) .

Yes I agree, I wasn't intending that as an "accusation" but more of a statement as to why it's complicated for anyone else to recreate his results from his source code.

Also it should be clear this software isn't all used in synthesizing his bitstream, only Xilinx ISE and Synplify.

And the part that is a pain though, is his opensource code doesn't include any project files, settings, or configurations, and it requires a fairly elaborate setup mixing multiple tools for various subsections of the bitstream in order to get it to build at all without failing hard. None of this is documented or provided (without extraordinary measures in digging up the info) :)

I was mostly trying to be clear that I will in fact release the source (I must because it's opensource) including my work and modifications for cairnsmore, but when I do it will be challenging for others to recreate without these tools (though I will do my best to provide better resources to at least assist in the process).

My own bitstream will not be using anything but the default Xilinx ISE to do the build. But once again, that one is a long way off (and the model for it to be released is still "undetermined", if I beat Enterpoint to the punch, they will license it from me, but that's not an exclusive license, so I may still release it in another form). Depending on the circumstances at the time, I may very well opensource it completely, that's all to be determined still...

Either way the opensource bitstream built off ngzhang's code (which is in turn derived from Ztex code) should provide a SIGNIFICANT boost over the existing options, and provide a means for the cairnsmore to get up to at least 2x Icarus type performance (760Mhash), with a hope I'll hit 800Mhash with it. I won't try to push it much beyond that unless we have any more major breakthroughs. But after that I'll release the code, and the community is welcome to go nuts with it :) while I shift my focus to the 100% custom bitstream which is far more optimized for the cairnsmore's unique benefits.

Also there is a chance once I'm done with it, that enterpoint can "tweak" it to get a bit more of a boost out of it. We'll have to wait and see where they take it.

Anyway, I'm going to get back to work, I'll post back more info once we have it.

Why don't you guys just open a kick starter page?

Here, if you're lazy :P

http://www.kickstarter.com/

I can't start a Kickstarter because I'm canadian, Kickstarter only works for US residents with a US SSN. You can't start a kickstarter if you're not. You can only contribute to a kickstarter from outside the US.

A bitcoin friendly kickstarter type site was one of the many projects I had planned for the Syndicate to develop and launch, but it's a long way off at this stage :)

As for the bounty group starting a kickstarter, the problem there is the one starting the kickstarter would be "responsible" for delivering on any promises. Might be a bit tricky to get around the limitations.

First draft of the bounty terms is up, 2nd post in this thread, you have 2 days to suggest changes or show approval.

Incidentally:

 - http://www.BitcoinFunding.com
 - http://Booster.io
 - http://Propster.me

I'm happy to match Zefir and Entropy-uc with 50btc for a bitstream before the 31/8/12 as per Isokivi Bounty terms.

I'll keep my fingers crossed that Glasswalker is first over the line  ;)

You should be able to build ngzhang's Icarus miner using just ISE's built-in synthesis tools, it's actually a relatively straightforward combination of bits from various existing miner projects that were originally meant to be built that way. The options to achieve this are a bit esoteric though - it's the nature of the beast really. I just did a SmartXplorer run on a dual-core and it hit Fmax = 166 MHz in under 24 hours; not quite what I was aiming for but not too shabby.

Can you please tell us what options you use? I think that is the biggest problem to get something out the works.

Whole bunch of the nicked pretty much wholesale from ztex's project files, which is where the hashing code comes from originally. Unless I've screwed something up the cairnsmorewip branch at https://github.com/makomk/Icarus/tree/cairnsmorewip should have them in. It's probably just a problem of running SmartXplorer against that to search for a seed that works well.

I agree that you *should* because it's derived from ztex, and if you found a way to do it in pure ISE using some of ztex's notes that's awesome.

The main problem is that the icarus code as-is fails par because it can't fit it into the chip. I've tried several optimization options and it just downright fails. And based on posts from ngzhang himself, I was able to confirm he in fact uses a bit of a strange method, he synthesizes the sha256 core itself seperately in a seperate ise project, using some specific optimization flags, then he passes the ngd into the fpgaminer_top project, and synthesizes that using synplify pro, and THEN does an implementation phase based on the synthesized top level, and the already built sha256 core.

So I've reversed my build out of this. Plus my build now includes some custom logic, and a bunch of custom constraints, and completely different clocking code. Plus some other modifications.

But ultimately yes, closing timing is just a function of a massive smartxplorer run. I can hit lower clock rates fairly easily on a couple passes. But optimizing for 200Mhz is a problem. (my last smartxplorer run ran for nearly a week, and was unable to close 200Mhz, but it came damn close).

Anyway, if you want to try to pull this off on your own, then more power to you, My primary day to day job isn't FPGA development, so I'm probably not as skilled as someone who is a professional at this day in and day out :). I'm always up for a little competition. Or if you want to collaborate, we can likely negotiate terms to share the bounty if you want to contribute to my existing effort.

Either way I'll keep pushing on this, and I hope to have the bitstream running very soon. :)

I'd like to chime in as well to ask for clarification on this. Since chances are it will be Enterpoint that release my work. That said I'll be the one opensourcing it after the fact, and I'm sure Yohan will have no trouble verifying that I am the source of the bitstream. That said if them releasing it on my behalf will exclude me from the bounty, then that may be a problem. So I'll need to discuss that with them if that's the case, so please let me know which way this will be in the "official" requirements?

Thanks!

FYI quick teaser for you ;)

About 10 minutes ago I managed to close timing on the 175Mhz build. This means that according to the Xilinx tools, I have a viable 175Mhash/chip bitstream that should run stable on all 4 chips.

Now comes some additional work required to ACTUALLY run it on a hardware and verify this. And I need to test it for stability for 24h or so. So we're not "there" yet, but this is a fabulous leap forward. In addition, my machine is still chewing on it optimizing, and hopefully it will squeeze another 0.75ns out of the clock cycle. Which means I could push this to 200Mhash and keep it within "spec" (and honestly, the one enterpoint is testing now is using worse clocking code, and was out of spec by over 1.5ns and it was still semi-stable for them, showing the cairnsmore hardware can run a bit out of spec if needed).

Anyway, just a quick update, to be clear this is NOT yet a stable bitstream, but it's a jump forward. And barring any major bugs, within 24/48h I hope to deliver much better news to you ;)

"3. The bitstream does not include any forced donation of hashingpower."

I would change that to

"3. The bitstream does not include any form of online DRM/forced donation, e.g. relaying work to 3rd-party server"

---

Furthermore, add 2 BTC from me.

Were hoping to have hundreads of ppl pledge in to this, I cannot and will not maintain everyones conditions in the bounty, especially since everyone seems to be tossing in different terms, sorry. If someone else has the time and devotion to do this, I will gladly step down from organizing things.

Term update:
"9. glasswalkers solution, even if released by enterpoint will qualify for the bounty if all other qualifications are met"

I hope this pleases all ?

This may be perfect timing. My CM1's are scheduled to ship this week :)

My 5 btc to this cause, is simple. I'd want the CM1 to be working to it's fullest potential quick as possible. While also ensuring if I'm paying this bounty, I'm keeping this an open source project. It would be more, but that is all I have in btc right now.

Aslong as a bitstream exist that is open source, uses all 4 cores and does within ~90% of what many of us expected the CM1 to do (800Mh/s) without any outside infulences. It doesn't bother me, if enterpoint makes use of, or even pays in this case Glasswalker.

I am part of the community that cares about results, the means of those results I am not too fussed by. It allows the community at large to make use of the bitstream, aswell as see the bitstream be improved in an open source way that has work so well with other projects so far.

Glasswalker will probably win the bounty, but whom ever it is, is soon to get a long of bitcoins, as their is a lot of interest in seeing these full operational that is for sure.

I'll throw 10 btc in the hat.

Ok, Im giving you guys a couple of more hours on the terms, before finalizing them as they are uless any objections rise.

put me down for 5 BTC

Terms finalized, so now untill wehave a bitstream we should just see the bounty ticking up as more ppl join, just as a reminder: I would like to urge anyone who has these boards to donate 1btc per board, it's very likeley that it will turn out a good investment.

In for 1BTC

2BTC pledged as I have 2 * CM1 right now

do we give this to a 3rd party or straight to the winner once bitstream is tested?

Think Isokivi is only acting in an organiser capacity. Aslong as the winner states his bitcoin address I'm sure the rest can be done from there.

Yes, I will not be holding anyones money. Im not a long enough time member, nor well enough known to do this, should a figure the community trusts step up, it can be done, but for now I expect everyone to pay their pledges separateley when a bitstream qualifying is out.

I think we should have a member of the community holding the bounty in an escrow account to ensure the winner gets all pledged btc. someone w/ rank step up.

Voting for Zefir. A really trustworthy guy who is running a solid mining bond on glbse.

Of course only if he is willing to do the escrow.

2nd proposal is Chefnet - he also proved himself as very trustworthy for selling lots of stuff on the forums.

Thank you for your trust and support. If majority is fine with me, I'll do the escrow.

In fact, I think the coins should be collected beforehand, instead of waiting the bitstream to be finalized. Due to the persistent dynamics in the Bitcoin world, too many potential events (like BTC skyrockets to 100$, pirate loosing all our coins in Vegas ;), etc.) can make it harder to collect the coins later people are willing to contribute today.

If everyone is ok, I'll set up an offline address for the bounty and a Google Docs spreadsheet to account the contributions.

Cheers, Zefir

+1 zefir. A really trustworthy guy. And thanks for your vote for mine.

i'm cool with that

Ok folks, here we go.

I have put up a spreadsheet (https://docs.google.com/spreadsheet/ccc?key=0Au2jspuzErkedHhDSEt5aTVPcUNMMjg4STVnOWV3VkE) where I will account the contributions for this bounty.

The coins will be deposited to 1CM1bj7jxVskkvKE2kcw6L16rHMXL38aFm (https://blockchain.info/address/1CM1bj7jxVskkvKE2kcw6L16rHMXL38aFm).

I am not going to send every contributor a personal address for correct assignment. Instead, send your money to the given address and at the same time PM me (forum mail to zefir or via email (zefir@web.de)) with how much you contributed. That should be enough information to match the payment to sender.


Did I forget something? If not, let the coins roll!


@Isokivi: could you please copy the related info to the first post? Thanks!

 ;D

Let it grow up fast and we will have a first (smaller) bitstream today!
I think the faster and bigger the Bounty, the faster we will have the goal!

That's an internal information, the announcement will come shortly form the bitstream guru and he's only working 3 day's on it =D

Sorry! couldn't resist!

3 ppl agreeing on the escrow is just not enough, imho. I have nothing agaist zephir, nor can I say anything for him. Just havent paid that much (or any) attention to he's doings in the bitcoin world. So ramp up some more support and I'll change the post.

Just a quick update, I now have a copy working at 175Mhash/s stable for a long period. But there are still some issues with the controller that are impacting communications (which is contributed to a bit by the serial comms code that ngzhang used on his core as well, which I've modified, but it's still based on the same design).

Enterpoint has released a new controller which will solve some of the problems, I believe it will work on 3 of the 4 FPGA positions stable, but I have to do some tests on this tonight before I release the actual bitstream.

In the meantime I've started another round of improvements based on what we've learned, and hope to have an optimized build soon.

Sorry for the delays.

Eberon: only 3 days and you have a working bitstream?  :o that's pretty amazing. Is it based on one of the existing opensource builds? or written from scratch? If so I'm curious what fMax your getting on the chips? (or did you just get super lucky and it closed timing on your first try by fluke lol). Also has this been tested on the actual cairnsmore yet?

I'll post an update once I've done testing tonight.

Make that 4, I agree.

Cross post from main cairnsmore thread:

Ok, I've changed my mind... This is a little against my better judgement. I'm releasing the bitstream that accompanies the new glasswalker controller that enterpoint released. Keep in mind I have not tested this myself yet. I won't be able to do that until later tonight when I get home from work. I will confirm once I've done that.

But if any of you who are a bit more technical want to dive in and flash this along with the new controller, and let me know how it works, I'd appreciate it. As Enterpoint said, it should work in 3 of the 4 positions. the 4th may or may not work, and may be flaky.

It should mine stable at 175Mhash/s on the chips it does work on (I've tested it on one position for over 24h at a stable 175Mhash/s on my board).

In the meantime Enterpoint is still poking at the problem from the controller side, and I'm re-writing the UART core entirely from scratch which should fully solve the problem, so between the two we should have a stable bitstream very soon. Then we can just worry about driving the hashrate up to the max attainable. Then following that I'll move my focus back to my 100% "from scratch" bitstream which should offer much improved performance.

In addition, one last tidbit. I've begun work on a "from scratch" opensource version of the controller bitstream as well, with some advanced features. That should both be useful for this bitstream, and my future, but also having the opensource controller out there should help any other developers with this in the future. That one is a ways off though, it's low priority and I'm only working on it in my down cycles between the other bitstream work.

Oh and I missed the final bit, I've forked off MPBM as I prefer it to cgminer. I have added cairnsmore support to it in the form of a custom module. It's still reporting hashrate wrong, but I hope to fix that soon. This version of MPBM was tested with this released bitstream.

Here is the link to the bitstream: http://www.btcsyn.com/bitstreams/glasswalker_untested.zip
Here is the link to MPBM github: https://github.com/pmumby/Modular-Python-Bitcoin-Miner
(you want the "testing" branch)

Let me know how these work for you.

EDIT:

Quick update, here's the source. As said it's useless to most in this state, but here it is as per the license. This does not include my new fixes to my newest version, this is the exact version of the code which resulted in the 175Mhz bitstream linked above.

When I get my final version out it will include all the fixes, and hopefully be in a more easily "buildable" state, as well as include documentation on how to build. how to install, and how to run.

EDIT2:

Helps when I post the link:
http://www.btcsyn.com/bitstreams/cairnsmore_os_175_source_temp.tgz

EDIT3:

See this post on the main thread for some (very vague) instructions. I'll post better instructions once it's tested:
https://bitcointalk.org/index.php?topic=78239.msg1056016#msg1056016

Another note from Yohan. The first ~50 boards suffer a bit more from the line noise than the remaining boards. My dev board is #1 (first board) so I may have poorer results than those of you with serial numbers above ~50. Hopefully the combined efforts from Enterpoint on the controller, and myself in rewriting the UART will fully solve the problem once and for all, resulting in nice stability on all boards.

Hi Isokivi,

sorry if I got it wrong: you as the thread owner and bounty initiator should have done the escrow, but AFAIR you refused to do that and since some of the folks here know and trust me, I took the initiative. That might have been premature, but anticipating the bitstream to be ready this week it was not too early. If you changed your mind and want to take the responsibility, I'll be glad to send you the collected coins or give you the private key to the existing address.

Otherwise (as already stated somewhere) having 50 CM1 boards I have a personal vital interest that the advanced bitstream shows up as fast as possible and the bounty gets paid. If you need to check whether you want to trust me, just visit my mining bond thread (see my sig) and read the second post.


Thanks, Zefir

All I would like to see is that the majority of pledgers agree that you are "ok" to do the escrow, got no other problems with this.

I'm happy for Zefir to hold escrow for my bounty. I'm away from my wallet till the weekend so i'll have to send the coins over on sunday.

I've added my 5btc to that account and sent my PM to Zefir.

Another 10 btc just rolled into the bounty address.

Zefir's escrow status added to bounty terms post.

Thank you for the support. And thanks to all contributors so far, we just entered the three-digit range (113BTC as of writing).

Keep it rolling!

2BTC bounty sent....as small time operator thats a big % for me...comon CM1 owners...1BTC per board will not send you bankrupt

Sent my 10BTC a couple of days ago.

spiccioli

Ummm kickstarter isn't US only. I'm Canadian too and I can set up a kickstarter campaign right now.

Since I haven't actually tried to do it, I won't directly dispute you, if you have first hand experience of this, then I guess I stand corrected.

But I sourced my information posted here directly from the Kickstarter policies pages.

Specifically their policies on Eligibility requirements at: http://www.kickstarter.com/help/faq/creators#EligRequ

First heading titled "Am I eligible to start a Kickstarter project?"

Quote:

That's the reason I said it was US only. I actually have several projects I'd LOVE to run over Kickstarter, so if you are right maybe I'll do that lol ;)

Also on an unrelated note, My 125Mhz version doesn't appear to work. I just got home, and I'm actually staying home from work Monday/Tuesday (I will be working from home, but I'll have cycles in-between to work on the bitstream, and having direct access to my dev board will help) to try and get some serious progress on the bitstream. I'll post more when I have more info.

When /if you release a 200MHs per FPGA bitstream, will you be doing up a PDF on how to "install" said bitstream? In a similair vain to what enterpoint has for their controllers...

Short answer: yes. :)

Long answer:
Initially I will likely push out "development" versions that will be lacking in support and documentation, mostly because I'm still busy "finalizing" things. But yes, once I do achieve a "complete" and "successful" bitstream, I will then take the time to fully test it, and document the procedure well, including exact versions of software/files used in the process.

Makomk's 190Mh bitstream have qualified for the bounty!

760Mh on 8 of my 10 boards, the 2 boards are not stable on the 0/1 pair and running the 180Mh bitstream on this pair. I think that is no bitstream issue, it's hardware.

I have allready donated some btc to him, thats why i'm not donated to the threads bounty wallet address.

eb

He says "the bitstreams in the following archive are overclocked bitstreams. This means that they run the FPGAs on your board outside of their specified limits. This may void your warranty, damage your hardware, and/or cause cats and dogs to sleep together. Use at your own risk.".

I don't know if this is something I want to run on my board.

I don't know where the specified limits are for an spartan6lx150, but it's surely not at 190Mh?! And you can't rise the voltage with the bitstream only.

It's up to you, just use the shipping bitstream ....

I couldn't get the 160 to run for more than a few dozen shares.

pdf "how to" guide of what bitstreams used, config, how to flash, etc...?

Did you downloaded the zip file? If not take a look in it, there are some how to's text files, source etc. :)

EDIT: oh! sorry, the source files etc. is in the zip for the 160MH bitstream ...

You are awfully eager to declare the winner of a bounty you didn't even participate in don't you think?

190 fails Icarus detect in CGminer every time I try it.

can u point to the 160MHz file and the associated read me...I can only find the 170~190Oc zip batch

Sorry, but today i'm to lazy to seach  ;)

I am trolling github with no success   :(

I would say you board is broken then. In irc channel #cm1 on freenode are many people that flashed the bitstreams from Makomk and it's working for them too. I'm not the only one.

eb

Hmm, ok here is it -> https://bitcointalk.org/index.php?topic=78239.msg1064960#msg1064960 (https://bitcointalk.org/index.php?topic=78239.msg1064960#msg1064960). I just clicked the name "makomk" in the thread and so you can see his last posts.

eb

thnx...trolled the records and found it
http://www.makomk.com/~aidan/shortfin_icarus_cm1_20120729.zip
link added for others...read me is about switch settings not "how to" install..which i think is on enterpoint

To install this bitstream you can take the information from the twin_test.bit bitstream. You need the VirtualMaschine from Enterpoint and flash is like the twin_test.bit bitstream. There is nothing special.

But is it stable?

help!!!!!...trying to install new bitstream on VM virtual box and having a problem

on step 3 of the carinsmore guide from enterpoint..I am unable to mount the USB drive (Fat32 then NTFS formats tried)

so far I can get it to be found as [sdb] or [sdf] but my mnt commands just giving me grief. so far I have tried

mount -t auto /dev/sdb /mnt    (as per book...error ="mount: you must specify the filesystem tpe"))
mount -t ntfs /dev/sdb /mnt     (error =  "mount: special device dev/sdf/ does not exist")
mount -t auto /dev/sdf /mnt      (more errors as per above)

and a few permetations on this...

I am not a linux guru but can navigate the usual help files and can get around a system ok

any help from the floor?

try this

mount -t auto /dev/sdb1 /mnt

What serial number is the board you are testing on?

Cranky4u,

in #cm1 someone said there is no need to transfer the data via USB-drive, just use wget and download it directly. Not tried myself, though.

Good Luck!

finally mounted the fkn thing and now the cp cmd wants a destination...fkn manual is shitting me

now cmd is missing destination operand

cp /mnt/*bit <return>

this is the cmd line in the book but it asks for a destination - the later cmd to DL to CM1 is "xc3sprog -c cm1 -p 0 *.bt" so I assume the cp cmd copies teh file to the root...is this correct? if so how can I cp to the root directory as desitnation

 I am learning

cp /mnt/*bit /root

this got a copy into the root dir for sc3sprog

Crank4u,

you can use "." to mean current directory, like in


spiccioli

ok...*.bit file is copied to root directory

xc3sprog -c cm1 -p X *.bit   ---> works as I get the correct DNA repsonse successfully

BUT next steps fails..the write to the FPGA

I am using

xc3sprog -c cm1 -p 0 -l *.bit  ----> the VM just bashes out a page plus of command options but does not write to the FPGA...

HELP PLEASE...is -l correct as the new command (as per enterpoint guide)

xc3sprog –c cm1 –p 0 –Ixc6lx150.bit bitstream.bit

                                 ^  without space

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?

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.

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

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? :)

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.

Yes thanks,

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

spiccioli

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

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:
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.

Regarding the Makomk's shortfin icarus 190mhs bitstream.

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

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

spiccioli

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 :P

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.

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

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.

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.

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.

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.

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.

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

As the starting party of the bounty...dare we say "Supreme holder of the terms"...we must bow to your view on the completion rate of the bounty before an award is given...

THE GAME IS STILL AFOOT!!! Tally ho  chaps...tweak those bit streams

I have now got the shortfin190 bitstream by Makomk working on 2 of my boards (~2 hours).

It seems to perform well, early days but I appear to be getting 650-700Mhash/s out of each board according to my pool.
It's U rating in cgminer seems to indicate this is fairly accurate averaging about 10 per board.

I would once again like to urge more people who own cm1's to contribute to this bounty, you know there are a handfull of brillian individuals workin very hard at the moment to provide us a more efficient tool for earning. Most of you are allready benefitting from this. Im not saying it's only because of this bounty.. but Im fairly sure the pace things have been progressing for the last week or so has much to do with this bounty and as any well-informed virtual miner knows time is everything in this game.

As of now just 12 of us have sent some coins.

https://blockchain.info/address/1CM1bj7jxVskkvKE2kcw6L16rHMXL38aFm

spiccioli

I got a couple of these, working pretty well, a little cheaper too.

http://www.monoprice.com/products/product.asp?c_id=103&cp_id=10303&cs_id=1030302&p_id=5447&seq=1&format=2

i didn't send to the bounty wallet because I don't stick with the rules. For me the winner was the first one that got my boards faster then the twin_test, even if it would become chrisp with the TML bitstream, i had send my BTC to him.

But the first was Makomk and he got 10 BTC so far from me, the first 5 with the 140Mh bitstream.

Sorry for the bounty winner, my donation is already done.

eb

I'm not achieving 760Mh/s, maybe at most 675Mh/s on the shortfin190.
So while it appears stable, it to me does not yet count towards the bounty, it however is a great achievement and I'm sure he is very close.

The rule for the 760Mh is not related to your Pool! As my Pool shows sometimes 8.2Gh with my 10 boards, but MPBM shows me ~7.55 at the moment...

Just use MPBM or the new cgminer and what this soft shows you is the correct Mh your boards running at.

O_o

You are right, the expectation (rule) of 760Mh/s does not have to be related to my pool, maybe because it's not stated how it is to be measured. It's also not mention that I have to use a very specific piece or version of software either, however I will update from 2.5 to 2.61, to see if it makes any difference, out of curiosity sake.

With how you structured your reply, it could be seen as a hostile retort, why?
I'm providing feedback and since many other bitstreams so far on CM1 can be a little off when it comes to the reported numbers in the software you use to mine with (cgminer / MPBM), what my pool reports is usually a reliable method to determine an accurate number. My U average per board is 10 in cgminer, so it is a little under double what I use to get before, that is about in line with my stated numbers above. I'm sure others get better results, I am however I am not one of those yet.

You choose not to be part of the bounty, you've already paid him directly. Fair enough. I however did choose to take part in the bounty, so what is the problem?

I for sure have no problem with the bounty, but when people post wrong/mixed numbers that are not related to any rule as far as I know. Posts like that let it misinterpret that you wont to grudge Makomk as a potencial winner...

What is when your internet connection have problems, pool have problems, stales etc. You can't count what your pool says to the rule. The 760Mh rule was just taken from the standard hashrate of 2x icarus which is hashing at 380Mh. The hashrate of the unit is importand to the rule, not what the pool shows you. Thats all what i want to say.

eb

Did you even read the second line of what I said?


I'm happy with his work, I've made that clear when I've mentioned in this thread and Enterpoint's. It's better than what I had before, so I'm not complaining.
I have struggled to get my cm1's to cooperate with me from time to time, but not due his bitstream, it was software suggested by enterpoint (which is not necessarily their fault) and me having to ask the community the best way around it, which I tipped nicely for their help.

I don't have a grudge against Makomk, I of course expected glasswalker to win, as a early entry and had an advantage with his connection to enterpoint but I made it clear I didn't care who done it. But he appears to came close then ran into problems, bad luck I guess, it allowed others a chance at it. Makomk came in as the 2nd major entrant and provided an great bitstream that works all 4 chips just fine and has improved it regularly since to this point where I decided to try it.

But make no mistake, my numbers are not wrong or mixed just because they aren't the same as yours. It's feedback to show their might be a little variance in results, it's known that not all cm1 boards react the same, maybe mine is one of those. It's stable so I'm happy, but "no cigar" on it doing the results for the bounty yet for everyone. I have no doubt Makomk can pull that off in the next few days. Apparently their is a 200 version floating around, but I've not tried it yet.

Btw since I updated to 2.6.1, while it's early days, my average U went down from 10 to 9.5 per board. So I might be switching back, to 2.5 unless their is a tweak to be done that provides better results.

Donating 12.5 BTC. 25 if it's released before 31/08.

I have trialled a few other bitstreams of Makomk. All stable, and now settled back on the 190 (is their a 200?)
It does now appear to be performing a bit better, maybe all that re-flashing did it some good, U rate more like 11-12 per board, rather than 10 or lower.
Guess even though it verified as success, re-flashing it sometimes is needed.
The U rates are not all uniform yet, but it's an improvement over last time.

Either way, this according to Cgminer translates to a 750Mhash/s average, which does qualify for the bounty.
One of my boards certainly does mine better than the other, Need to find out if their is something wrong with the board, thus needs me to send it back to enterpoint or if further improvements in the bitstream can solve it.

If I remember rightly my boards are numbered 62-0418 and 62-0419, so I got one of the later boards.

Well done Makomk.

are you able to list bitstream and miner app used to achieve these figures?

I am having some technical difficulties flashing my cm1 boards (62-0432 & 62-0433). I can follow the guides and bitcointalk.org hint to get down to step 4 in the manual - "Programming the bitstream". I then put in the command "xcsprog -c cm1 -p 0 iIxc6lx150.bit *.bit" but get an error of;
Can't open datafile xc6lx150.bit: No such file or directory
JDEC: ff ff 0xff 0xff
unkown JDEC manufacturer:ff
ISF Bitfile probably not loaded
root@cairnsmore:~#

I am using a Win 7 64 bit PC...any help on solving?

I did, I'm using Cgminer 2.5 (tried 2.61 aswell, no improvement), using Makomk's shortfin190 bitstream.

The command line works the same in linux and windows I believe, so I think you may have a small error in how you are using yours.
I notice you have a space between "-p" and the "0", also it's "-I" after that. Then the name of the first file and the second file, there is no space between -I and the first filename.
While that does not match the error completely it would be good to correct. Also make sure the bitstreams using the names you use are in the same directory as the xcsprog file, so it can find it. Renaming files is fine, as long as it is accurately named when you use it in the program.

I use:

xc3sprog -c cm1 -p0 -Ixc6lx150.bit shortfin190.bit
xc3sprog -c cm1 -p1 -Ixc6lx150.bit shortfin190.bit
xc3sprog -c cm1 -p2 -Ixc6lx150.bit shortfin190.bit
xc3sprog -c cm1 -p3 -Ixc6lx150.bit shortfin190.bit

(I renamed the shortfin files to be abit shorter to type out)
That flashes all 4 of the Chips. That finishes the flash then you just need to get it back into a mining state.


The below are two notes I copied from the main CM1 thread that I use to remind myself how to flash the Makomk bitstreams.
They explain essentially the same thing two different ways.

Good one, didn't notice that one.

Put me in for 2...

Work looks good so far.

flashed successfully and tried mining with cgminer 2.6.1 but not working...test fails on startup

can someone post a picture of the dip switch settings for 190MHz settings so I can make sure they are right

Cranky,

they're the same of the first image in Dip Switch Settings section on this page

http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html

BUT for SW6 switch 1 which has to be on the OFF position (to the right looking at the image).

spiccioli

http://static.lethosdesigns.com/i/cm1_mak_dip_settings.jpg

I quickly did an image up for you.
Follow these instructions and you should flash okay.
All the steps are important, worst comes to the worst try do them again from the start.

Unplug the usb cable on all other boards if you have more than 1.
Set one board to the above setting (SW1 - #3 enables programming btw)
Plug it again (this should make sure the program detects the board as ready)

At the command line type:
xc3sprog -c cm1 -j
This should show the board with it's 4 chips are visible.

At the command line type:
xc3sprog -c cm1 -p0 -Ixc6lx150.bit shortfin190.bit
then
xc3sprog -c cm1 -p1 -Ixc6lx150.bit shortfin190.bit
then
xc3sprog -c cm1 -p2 -Ixc6lx150.bit shortfin190.bit
then
xc3sprog -c cm1 -p3 -Ixc6lx150.bit shortfin190.bit

This flashes each of the 4 chips individually. It takes a few minutes for each one, be patient.
(make sure you update it for different bitstreams and changes in filename, ensuring obviously the bitstreams are in the same directory as xc3sprog)

Unplug the cable on the board.
Move SW1 switch 3 to ON (labeled mine), so it's like all the others next to it.
Move SW1 switch 1 to OFF (labeled reset) then after a few seconds to ON again
When just the yellow leds next to the 4 chips are on all, plug the board again

a work of art...THANKS!

No problems, I was just to make it clear one part is not one big command line and is 4 seperate commands where you wait for it to flash.
Also that is merely a photoshopped image of one on their site, modified for the right settings.

@Cranky4u Please try to avoid quoting whole posts and/or images... this really clutters the thread.

apologies for the mash up...

2 boards flashed and now undergoing 48hr stability test...thnx ppl...it has been about 5 years since I touched any Linux flavoured OS hence some rustiness

Best of luck, All it takes is a little refresher.

I've programmed 20 odd boards with the Makomk 190 Mhz bitstream.  They are mostly all hashing at over U: 5 / m.  There are a few ~10% hashing painfully slow 1 or less.  I won't have time to debug those, so I'm just letting everything run.

Startup was painful in a few cases, but generally, replacing cables and power cycling the boards seemed to resolve those problems.

Makomk, regardless of whether you with the bounty, there will be significant bitcoins coming your way from me!

Do you think you can push it farther?

I have a new development to post...

As you all know makomk jumped in with some of his icarus improvements, and that resulted in a mostly stable bitstream which had some great jumps in performance for everyone.

In addition, I was working on trying to work around some of the board level issues on the cairnsmore and also making several other improvements to the bitstream as a whole. (some new fixes just came down the pipe this morning from Enterpoint which might help improve stability further).

Lastly, I've been working on another mining core on the side which I had hoped to make some money off of.

Well in light of all this, I had a chat on IRC with makomk, and we have decided that I'm going to release all my work so far, (even though it's still unstable, we're rapidly working on fixing that). And makomk will share all his "tricks" and work so far. Together we're working with some additional help from TheSeven as well. To collaborate on a single opensource bitstream project which hopefully will have many improvements for everyone.

Initially this will be targeting the Cairnsmore, but we're going to try and keep it "hardware agnostic" if possible. And of course 100% opensource, including project files required to build it, and it can be built purely in Xilinx ISE (no third party tools).

In addition, I'm now officially open sourcing my new bitstream (the new hashing core) which is still incomplete, but has huge potential I think. So with all this combined, this bitstream has the potential of being a great new boost to the bitcoin FPGA mining community as a whole.

Anyway, with this agreement, we've agreed, that if the community decides that we "qualify" for the bounty, we will be splitting the bounty down the middle 50/50.

This way we're no longer competing, but instead cooperating to deliver a new improved bitstream to the community. Which is good for everyone.

Hopefully makomk will pop in here shortly and confirm this from his end with a post.

And of course, here is the shiny new github where all our work will now live directly in the public eye:
https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner

So if any of you find problems/issues, please use the issues tracker on github to submit them, so they can be worked on as they are found. If you submit issues, please provide as much detail as possible.

Also if anyone has anything to contribute, ideas, suggestions, or wants to work on porting to another board, let me know, I'll let you get involved as a collaborator.

I'll post more news once I have it!

Just a quick note to (mostly) confirm this. I may still be releasing my own bitstreams in parallel to working on the new project - they're focused on very rapid testing of small incremental improvements, whereas developing a new hashing core is really hard - but regardless of which "wins" in the end I'll still be splitting the bounty down the middle with Glasswalker. The duplication of effort was seriously getting out of hand and I didn't realise quite how much so until recently.

Nice to see you guys working together. Look forward to what comes from this.

Great news for everyone involved - cooperation is better than competition. As soon as I get my board (T minus 6 weeks) I'll send some coin your way. 

Great news, ill be adding 2 to the bounty in that case. Ill be sending it later today after work.

My two sent~!

Thanks

Doff

Truly great news,

I'll double my BTC later today, early tomorrow, so +10 to the bounty.

spiccioli.

Yeah sorry didn't mean to imply you wouldn't be working on any other projects but this one ;) only that we'd be putting our heads together on this one (in addition to any other side projects any of us have on the go) lol.

This is the best news ever, imho you will qualify for the bounty.

Great to hear!

While competition for sure is the key factor to maximize performance in the long run, in this particular environment collaboration will guarantee to get the best possible result in the shortest possible time. Just great you joined your forces now.

To all CM1 operators out there: now there is no reason to withhold your contribution to the bounty. If you agreed to support it initially but did not send your coins by now, please consider doing it. If you did not commit initially, still please consider contributing 1BTC for each board you have (this is less than one week's mining income from the additional hashing power you gained with the bitstreams already provided). Be fair, people are working hard and deserve some compensation. The 122 coins collected so far are only almost half of what was committed to - please consider supporting.


@Glasswalker: now since you work together, how's the chance to get up/down functionality supported soon? I figured that half of the instability I have is due to USB cable and / or hub problems. If the related controller FW can save me from buying new cables and hubs (again), I will increase my contribution by another 25BTC.


Thank you all for the enormous efforts and the great outcome.

For now the focus is getting past the main stability issues and getting the bitstream running on all 4 chips in some sort of reliable way.

Before we get up/down working we'll need to finalize a new communications protocol. The communications protocol needs to stay fairly robust and flexible. And I've gotten several suggestions/ideas on that from TheSeven, so I'm sure that will change somewhat with the collaboration we have here now.

That's the kind of thing you want to hammer down and get 100% right from the beginning.

Once the protocol is decided, we'll roll it into the controller and get it working purely with the controller and the 4 worker fpgas...

Once that's tested, and validated, adding the same on the up/down port is a fairly minimal addition.

So basically, probably not for a bit still. Even if I used my previously defined protocol as-is as a temporary measure, it still needs to be finished and tested on the workers (and we still don't have stable clocks yet).

Right now the clocks seem to be the last real barrier, and so that's what's being worked on to solve many of the remaining issues.

ok...after 18 hours of testing, well short of the 48 hours I hoped for, here is my 190 bit stream findings;

System - Win 7 64bit, cgminer 2.6.1 + phatk, cm1 #62-0432 & #63-0433
Average hash rate per cm1 = ~725MHs at pool & via cgminer Note: neither board is reaching the bounty threshold of 750MHs
Average U = 17.5~17.8/m
HW & R are very low. HW = 0 & R <5
Maximum run time between failures (resulting in need for system reset to recover e.g BSD or non-responsive) - 14 hours
Minimum run time between failures (resulting in need for system reset to recover e.g BSD or non-responsive) - 0.5 hours
Average restarts of cgminer before both boards detect successfully - 3
Identified conflicts - use of 2nd 6770 GPU for mining causes system to BSD on start up of cgiminer or intedpendent start of of phoenix miner when cgminer is FPGA only. Note: Can mine on 1st 6770 GPU though.

I hope this helps developers...
Tweakers, any idea on how to tweak to get up to 750MHs and improve stability?

What are your per worker U values? U=17.5 on 2 boards looks like 1 fpga isn't hashing which is a common issue with that bitstream.

running as pr above but on + poclbm gives (approx)
ICA 0: 360/360    U: 4.30/m
ICA 1: 355/360    U: 4.15/m
ICA 2: 355/355    U: 2.05/m
ICA 3: 360/360    U: 6.75/m

overall U: 17.3/m

hint? is ICA2 not flashed properly despite VM saying it was a success?

Hi,

I've sent my second 10 BTCs bounty part.

https://blockchain.info/tx-index/14400138/b6f539f3d23fe868d1e204f88c8e91f417435134b62bd64f79ffbc3844c5ab88

spiccioli

It probably did flash properly, it's just that one of the FPGAs on ICA 2 has frozen. Probably FPGA1, that always seems to be the one that falls over first on ebereon's boards.

so after some time...I stabilise around the U: 5/m ICA line in cgminer...is this right for the 190MHs bitstream?  basically what sort of rate should I be getting? My pool is reporting about 1200~1400MHs for 2 * CM1 190bit flashed systems

Multiply U with 71.5827883 to get the MH/s.

@ cranky4u

I've got 2 boards and 1 of my boards does that. The other mines full throttle.
Reflashing sometimes helps. I am 50/50 on if it's a hardware or bitstream issue.

I do figure however since one works perfectly it atleast has a chance of being fixed by an improved bitstream.

ok..so I have finally deduced what functions the cm1 board lights represent and no, I didn't find it in any enterpoint instruction manual.

FPGA on standby or idle (not mining)
Orange, constant - standby

FPGA mining
Green, flash - found a successful result
Orange, flash - normally with green flash, mining
Orange, constant - FPGA not responding  ---shit itself or controller not communicating with it

I have p1 on 62- 0433 presenting a constant orange during mining so I assume it is playing up...will reflash 190MHs bitstream tonight and report back

ny1 know if I can run different bitstreams in each FPGA..eg p0,p2,p3 = 190MHs bitstream whilst p1=180MHs

thinking of this as p1 is unstable and keeps shitting itself. NOTE: "Shitting itself" is a professional engineers term for fucking up or crashing

To be exact, the LED meanings in the "standard icarus" bitstreams (such as makomk's current 190oc release for example) are:
0 - Found a Share (flashes, then fades out)
1 - RX (FPGA received data on the serial port)
2 - TX (FPGA sending data on serial port)
3 - Idle (this lights when the FPGA has no current work to do)

The colors in order are:
0 - Green
1 - Red
2 - Blue
3 - Amber

Those functions are static (ie: they don't change depending on what "mode" the fpga is in).

For the HashVoodoo bitstream (Still not working right as of yet) the LED meanings are:
0 - Found a Share (flashes, then fades out)
1 - Clock Heartbeat (flashes on a heavily divided clock signal to indicate the FPGA is getting a good clock signal and hasn't locked up)
2 - Serial Activity (blinks on transmit or receive on the serial port)
3 - Idle (lights when the FPGA has no current work to do.

It should be noted that on both bitstreams currently the serial rx/tx LEDs light so fast typically you hardly notice them (if at all). I intend to add a (faster) version of the "fader" code from the share found LED code to the serial activity LED, to stretch out the blink duration some, to allow it to be more obvious when the FPGA is communicating.

To answer your question about multiple bitstreams:

In theory that should work fine. The comm clock, and hashing clock are different clock domains, so the communications code should keep on working just fine, while the hash clock can be at different rates. It may end up resulting in the entire nonce range being missed sometimes though (ie the 190 is in "front" and 180 in "back" the 190 starts the job, and forwards half it's nonce range to the 180 bitstream, but the 190 will finish before the 180 has finished, resulting in a small percentage of the second half of the nonce range being "skipped"). I don't think that will hurt overall hashrate, but it might skew some of the other stats slightly. Ultimately the impact should be nearly nothing.

Hope that helps :)

Also a quick status update on HashVoodoo development:

The first test bitstream using LVDS clock signalling was completed, but we're still having communications issues. So I'm now doing some debugging of the comms stuff.

The good news is that the LVDS clocks seem to be stable in all 4 slots, even on my 0001 serial number board! So I think if we can solve the comms issues, we're really onto something with this one!

Please note, I don't reccomend installing this bitstream just yet, (the .bit isn't released) because it's not quite working right. Once I get it hashing on my end, I'll release the full binary bitstream for you all to test out. I don't want to cause more headaches by releasing a malfunctioning bitstream (and I've encountered some wierdness on the jtag lines now, so I want to rule out the bitstream as a cause. The last thing I want to do is release an update that breaks your usb updating ability).

I'll post more when I have it.

Glasswalker...thank you for that great update!

the escrow held by Zefir is now up to 185 btc. lets go glasswalker/makomk/mystery genius, we need more MH/s!

Right now I'm mostly waiting to hear how Glasswalker's latest bitstream will turn out. It sounds really promising, touch wood.

Well I closed timing (175Mhz target, with about 1us to spare) this morning. Unfortunately the build was missing termination on the LVDS clock lines. So that will hurt overall performance. When I get home I'll run that through fpgaeditor and see if I can correct it and do a bitgen from that. Then I'll test that out.

Also I'll try to get the controller fixed so USB programming isn't broken. Then we can get the .bit for the current source code released so everyone can try it out.

If we can get this thing up to 200Mhash, and reliable on all the boards, then I'll shift my focus back to the HashVoodoo core, to replace the ztex/icarus core I'm using now. Which will shift us to a "sea of hashers" style approach.

Anyway I got super busy this past week roughly, so haven't been able to spend as much time on it. Luckily I had a like 5 day long smartxplorer build going, so I wasn't wasting time completely.

Also FYI: the current source code on github is what I've done the current build based on.

If this works (even marginally) then the next step is to backport any of makomk's tweaks into this bitstream, and a few other fixes/adjustments I've thought up. Then provided we can get roughly 200Mhash out of this one, I'll leave it there.

The 200Mhs bitstream in this pack seems like a winner. I need more ppl testing it, input on wether or not the documentation is as required.
http://www.makomk.com/~aidan/shortfin-dcmwd4c-20120811.7z

Im seeing an average speed of 800Mhs reported at poolside, one troublesome core-pair is pooping out an invalid rate of 3,15%. but it seems like we have a winner, I dont have a long enough test-run yet, but there should be no uptime-issues to be expected.

If you want your word in on wether or not this qualify's for the bounty: the time to act is now, test it, call out about missing or insufficient documentation, do something.

I will start testing the 200 MH/s bitstream on my SN 26 board tomorrow.

I'm running it now on 9 boards. will tell you in 24 hours how it looks.

update:
after 2 hours cgminer shows 6942 total, 771 per , pool shows 6761, 751 per , 99.9% accepted on both.

22 hour update: cgminer shows 6839 total, 759.8 per, pool shows almost exactly the same, 99.98% accepted on both.

I should note that whilst I have released the source corresponding to those bitstreams, there are no instructions to build similar bitstreams from the source because you can't do so trivially. That source is actually back-modified to match several direct edits I made to the compiled .ncd in FPGA Editor - you can download that from http://www.makomk.com/~aidan/shortfin_dcmwd4c_ed_ncd.7z if you want to poke about yourself. You should be able to get fairly close by pointing Smart Guide to that ncd (unzip it, right-click fpgaminer_top in the Hierarchy pane in ISE, choose Smart Guide and point it at the NCD, then click the green Implement arrow in the toolbar) but that dents performance by several tens of MHz. You'll also need to run mkrelease.sh which executes some FPGA Editor scripts that are needed to get the bitstreams to run.

(Honestly, if you want to do development the halffin-dev branch in my git repository (https://github.com/makomk/Icarus/tree/halffin-dev) is much nicer to work with, it just doesn't quite have the same performance yet. Or there's Glasswalker's stuff, which is quite nice too.)

As far as my boards are concerned the latest 200Mhs bitstream takes the bounty. I have been hearing about issues with pre #50 boards,but Im fairly sore most or all of us can agree that that has got to be a hardware issue.

My boards (62-0110 and 62-0111) aren't happy yet :

This is with the 190 version in the same batch after 1 hour on cgminer 2.6.4 with --icarus short:

ICA 1 and ICA 3 are linked to the third ttyUSB interfaces of each cairnsmore 1 board on my systems (the latest udev rules published on the forum are quite nice) :
ICA1: /dev/cm-62-0111-if02
ICA3: /dev/cm-62-0110-if02

From what I can tell (orange LED often on), these are the interfaces linked to the 1st and 2nd FPGA on each board. The #62-111 board has indeed both FPGA 1 and 2 orange leds on most of the time. I can see the FPGA 2 orange LED on #62-111 quite often too.

I had a run with 190 on all FPGAs except FPGA 1 where i put the 160 bitstream from the same batch on each board.
Here is the result after 6 hours :
60-110-if02: 3,84
60-110-if03: 5,03
60-111-if02: 3,44
60-111-if03: 5,05

My main problem is that results are quite inconsistent and most of the time hard to get: the tty interfaces vanish often and unpredictably. Some days I have to reset boards by removing power/USB half a dozen times.

My problem might be that I can't update the controller and still use the 1.1 firmware on it but I don't have any solution for it (no Windows license here).

I would just try and download a copy of Windows 7 install it without a key, you get 30 Days trial, or borrow someones Win7 Cd and load it from that. That way you could at least get to 1.3, or 1.4 now. You don’t actually need to own the copy just get it installed and use it for 30 days.

There are 2 problems that make this impractical:

• I've not installed Windows since XP (and even then it was a one-shot because I had to for work) I'd probably spend several days on this in my free time. Last time I saw a Windows system I didn't even know where to begin, its UI is now a total stranger to me.
• I don't have any system on which to install Windows 7. The only available system I have is a test system without a harddrive, booting from an USB key. I'd have to buy a drive or install Win7 on an USB key (is it possible yet?). I thought of using virtualisation on my laptop, but I'm afraid I don't have the disk space on my SSD (I've ~15GB left and that would stretch it).

My best bet if Enterpoint doesn't release a Linux version is to find someone with a Windows install (can't think of any friend with that) and pray that I won't trash his/her system. I could sell the boards too... Ironically I wanted to buy some more, but there's no way I'd knowingly buy something that requires me to spend time on something I don't want to. Especially if it's related to mining: time is money.

gyverlb, sorry that things are not working out for you. but why did you purchase a hardware when you don't know how to do updates etc.

This is not the way I would buy hardware. When I know I have limited opportunities to work with hardware like this (dev board, no informations, not know software to update, forced to use only Linux etc.), I would better go for something that is better supported and documented. It's just my point of few.

But to give you also an other hint to update from the controller from Linux. Buy an simple JTAG cable, then use the xc3sprog with the -Ixc3s50an.bit option. This way Zefir managed to flash the controller from Linux successfull. Just ask him about the used cable. I think it will not cost the world (~10-20$) and it would make you also happy with your boards =o)

eb

There is another possibility and that is to acquire a programming cable that will work with Xilinx ISE tools. Webpack versions of ISE are free, will run under Linux, and whilst they won't build for a LX150 Spartan they I believe will allow programming on these devices and certainly will for the XC3S50AN used for the controller. Some details http://www.xilinx.com/support/download/index.htm. There are several options for cables that will work with this software including our Prog2 (cheap parallel port cable) and Prog3 (dearer). Digilent, Xliinx and various Chinese clones are available as well. Don't ask me if the Chinese ones work. I have never tried them. 

Because I had no idea that there still were hardware manufacturers that wouldn't support Linux by default today. Especially in this very case: addressing the Bitcoin mining community: many (most?) of us have Linux rigs some even use the RasperryPi or home routers to connect to their FPGAs. Bitcoin is open-sourced at its roots.
The only question that I asked myself is if the board could be updated via USB (this is why I didn't purchase a JTAG cable). Even the documentation of the controller programming interface would be enough. In fact no Linux support isn't the problem, having to rely on an obscure utility that only runs on some OS versions without the safety net of documentation of the interfaces it uses is a recipe for transforming anything in a paper weight mid or longterm.
This is not the first time I purchase hardware for which I have to code the driver or some tools myself: you can still grep my name in the Linux kernel for the support of some long forgotten IDE controllers. So usually I'm not especially worried, but reading that there is some IP in there that can't be disclosed to build the tools I need is worrying me.


We knew very little of the details when we pre-ordered. Everyone took a risk, myself included.
But having the thing closed to me because I can't have access to the information I need to make it work the way I want is exasperating. I'm a tinkerer : if I can't hack it I won't like it and it better make itself forgotten (which it doesn't do well currently). It's already too bad that Xilinx won't sell you the right to hack the Spartan6 with it but separately. I already had difficulties wrapping my mind around this fact, seems the FPGA world is not for me.


That's a good alternative thanks for the heads up.

Hi gyverlb,

totally agree with you, the information on what SPIProg.exe should be disclosed. If you are a Linux kernel developer you for sure know that programming an SPI device is no rocket science, and one would basically just need to know how the Spartan3 is wired to the FTDI port to access it. There are several SPI programming tools available as open source (like this SPIProg (http://www.afthd.tu-darmstadt.de/~dg1kjd/)) that can be easily extended to use the related channel over libftdi.

But in the end it is not worth the effort. I found a Xilinx Parallel Cable IV (http://www.xilinx.com/support/documentation/data_sheets/ds097.pdf) that does the job well. It is fairly outdated and slower than the USB variant (plus you might have troubles finding a parallel port at your host meanwhile), but as recovery tool for sure good enough. You can find it at Ebay for less than 10$, while the USB Platform Cable is available for around 35$.

The cable is fully supported by xc3sprog, and since it comes with the 14pin 2mm pitch cable it is plug-and-play ready (in contrast to other cable I tried first and failed).

Programming the controller is done like ebereon described: use the left-hand JTAG port (the one directly at the Phoenix connector) and run

Good Luck!

If you want / need to offload your CM1 collection...msg me to discuss prices    ;D

I opted for this instead (will probably get it in 3 weeks):
http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewItem&item=120927703340
I hope it works as advertised, I could have bought the cheaper parallel version, but I have far more USB ports than parallel ports...

With some pains and various makomk bitstream combinations I think I can hit a ~650MH/s per board configuration which doesn't crash every day while waiting for it. I really hope the new controller firmwares are worth it!

What's the current status regarding the bounty? The way I see it, all requirements for paying out the bounty are met... (I cannot judge point 6, documentation)

When I had it stable I agreed with many, that yes it did meet the requirements. However I've had stability problems since and I don't know what the cause is.
However they haven't really finished a polished version yet and apparently working together now, so I guess that new combined one once ready will win it.

Keep in mind that your recent experience with the 2 boards dropping off, that is not a bitstream issue (or rather I'm 99.9% sure it's not a bitstream issue).

For 2 physically different boards to drop off at nearly the same time, all 4 ports to vanish from the OS, but the chips keep the heartbeat going. That's not a bitstream problem. It's either hardware (board level) or infrastructure (cabling, host PC, software, driver, hub, ports, whatever) which is unfortunately outside our control. The only part of the bitstream that it could be (on a long shot) is the controller, as that interfaces directly to the FTDI and could impact the performance of the FTDI (and therefor cause this "dropping off". But the fact that 2 boards did the same thing in approximately the same time leads me to believe it was something outside the mining boards themselves.

That said I'll do my best to try and help you identify the issue, as many others will I would hope as well. Hopefully it either never happens again, or it happens again but you're able to get more detailed info from it to help diagnose.

Just wanted to clarify that the future bitstream releases will be focusing on first the dynamic clocking, and next the new hashing core. Neither of which would have any impact at all on this particular issue. So I wouldn't waste time hoping that the new versions will solve this particular issue. That said the FINAL goal of the new controller, with the completely new communications protocol (that would use only a single USB for an entire cluster of boards) would likely help aleviate this, due to an architectural change, but it wouldn't actually solve the problem (merely work around it). But that one is a long way off.

Just wanted to make sure we're not setting the wrong expectation :)

I've had more problems than most, I wouldn't disagree there. Also I'm not blaming your bitstreams, just like I said before I don't know what is causing the problems I am experiencing. I get it working eventually, it just doesn't always stay stable, I can't pin down what is causing it yet.
Documentation is the only thing left, you guys working flat out, I don't expect a lot, It's why I do my best to write mine up.

For sure, I just wanted to make sure I wasn't setting wrong expectations ;)

Yeah documentation will come soon. The readme is there and it is "complete", but it is rather vague. And doesn't cover any "special" cases, or odd problems. It basically just covers hardware settings, and installing (referring out to the enterpoint instructions, or assuming access to ISE Impact and a JTAG cable).

Once we have the next version out that's the last major feature change. After that the bitstreams should remain functionally identical, just with performance improvements or internal structural improvements (without changing overall functionality at all).

Eventually way down the road more documentation will be needed for the new protocol but that's a ways off still.

Once I get the next release out and it's working, (dynamic clocking) then I'll take a bit of time to do a full documentation writeup, and hopefully the community can help me flesh it out once I get a foundation laid down.

If you want any help writing up documentation, you know I've tested it enough ;)

I will give my opinion.  Others may think differently, there is such a broad range of hardware performance that everyone is going to have different experiences.

Below is the performance of 8 recently build boards (>04xx) after running Makomk's latest 200MHz bitstream for 4 days.

cgminer version 2.6.4 - Started: [2012-08-17 13:46:13]
-------------------------------------------------------------------------
 (5s):6241.1 (avg):6106.0 Mh/s | Q:998120  A:576799  R:366  HW:0  E:58%   U:79.1
 TQ: 1  ST: 16  SS: 0  DW: 26304  NB: 840  LW: 0  GF: 2106  RF: 8
 Block: 000005866228c10025bc465254296925...  Started: [15:04:14]
-------------------------------------------------------------------------
 ICA  0:                | 381.4/381.9Mh/s | A:38392 R:34 HW:0 U:  5.27/m
 ICA  1:                | 387.2/382.1Mh/s | A:39066 R:26 HW:0 U:  5.36/m
 ICA  2:                | 390.1/382.1Mh/s | A:39067 R:20 HW:0 U:  5.36/m
 ICA  3:                | 388.1/382.0Mh/s | A:38908 R:25 HW:0 U:  5.34/m
 ICA  4:                | 386.1/384.1Mh/s | A:38836 R:22 HW:0 U:  5.33/m
 ICA  5:                | 380.6/381.9Mh/s | A:39043 R:21 HW:0 U:  5.36/m
 ICA  6:                | 390.7/384.2Mh/s | A:38854 R:31 HW:0 U:  5.33/m
 ICA  7:                | 385.1/382.0Mh/s | A:38711 R:23 HW:0 U:  5.31/m
 ICA  8:                | 390.9/384.4Mh/s | A:39281 R:24 HW:0 U:  5.39/m
 ICA  9:                | 382.9/382.0Mh/s | A:38805 R:24 HW:0 U:  5.32/m
 ICA 10:                | 371.0/375.4Mh/s | A:15949 R: 9 HW:0 U:  2.19/m
 ICA 11:                | 371.0/375.4Mh/s | A:16269 R: 9 HW:0 U:  2.23/m
 ICA 12:                | 384.3/382.2Mh/s | A:38974 R:22 HW:0 U:  5.35/m
 ICA 13:                | 378.8/382.1Mh/s | A:38997 R:36 HW:0 U:  5.35/m
 ICA 14:                | 386.5/382.1Mh/s | A:38864 R:25 HW:0 U:  5.33/m
 ICA 15:                | 392.9/382.0Mh/s | A:38784 R:15 HW:0 U:  5.32/m
-------------------------------------------------------------------------
               

The total utility of 79.1/minute corresponds to 708 MH/s per board but this is being dragged down by one badly performing board.  If I remove that board from the calculation, I get an average performance of 740 MH/s.  That is still a hair under bounty target.

But it is close enough that I think the spirit of the offer has been satisfied. There is also some risk that the value of bitcoin will dump in the near term as the pirate dust settles (or hits the fan).  I don't want them to get shorted in such a situation. So, I intend to pay out my share of the bounty reward equally to Makomk and Glasswalker as they agreed.  I have an address for Makomk already; Glasswalker if you PM me a deposit address, I will pay out the bounty the next time I have access to my wallet.

PM Sent.

I also want to apologize for the delays in the last few days. My day job kind of exploded (critical project went into crisis mode, and I got pulled in to deal with it, so starting this past weekend I've been working from about 8am till 1am every day. Today I'm working from 3am until god knows when due to a timezone shift with one of our partner offices... So I've had to pause my work on the bitstream for the past few days.

This insanity should be resolved by this weekend.

In the meantime, I have released an updated 200Mhz bitstream that runs at 200Mhz with almost no invalids. BUT it has some stability problems. In my absence, makomk has been working on the problem, as he began experiencing similar instability in his bitstreams as well. I thinks he has found the solution to the problem and is doing some test builds of his bitstream to see if it resolves them. If it does, we'll backport those changes to the HashVoodoo bitstream. In addition, collaboration with TheSeven has resulted in a few more improvements we plan on dropping in to the next build as well to once again re-inforce stability.

This should get us to a usable 200Mhz plus bitstream with the rock-solid stability we saw in the previous hashvoodoo bitstream (so working on ALL boards, including the older gen, sub50 serials, and any "problem" boards). At least that's my hope.

Then we're going to take a short break from releases for an unavoidable step:
We'll be building (and releasing with the source) a full testbench for use with the Xilinx simulator, allowing simulation of the bitstream before building. This will allow us to debug (in a more conventional software dev form) the bitstream, by walking through clock cycles, and seeing where things muck up. This will also allow faster problemsolving as the simulation can happen after only a partial build (basic synthesis) not requiring mapping, or placement and routing, and timing closure. So with the simulation we can test new features, ensure they work, saving build time drastically...

Making a testbench isn't quick or easy (at least not doing it properly) but I think it's the right thing to do. I've been avoiding it until now, but at the urging of TheSeven and makomk, I think it's the right thing to do to have a single solid bitstream we can all easily develop and debug. This will likely mean a week or so "pause" in any future releases (once I get back to it) so aside from this next "bugfix/stability" release using makomk's fixes, I wouldn't expect any additional releases until approximately the end of Aug, maybe first week of Sept.

After which, progress should be faster, and our ability to squash bugs will be greatly improved ;)

Anyway, what I'm getting at is a rediculous amount of effort has gone into these bitstreams, and both the HashVoodoo, and makomk's direct fork have benefited greatly by our cooperation and collaboration since we decided to join forces. And we still have several surprises coming once we get the foundation laid and the core features settled (the new hashing core promises to present a significant boost in performance, once we've ironed the kinks out).

Development isn't going to halt on this bitstream, it's just going to keep getting better. But I also think we're lightyears ahead of where we were with the cairnsmore. We now have several "semi-stable" bitstreams in the 200Mhz range as posted by several others on this and the other thread. And for those of you having problem boards, the 175Mhz hashvoodoo bitstream (08_16_2012 release on github) has been tested thuroughly on many boards, including some of the most troublesome boards that were already packed up for RMA, and it works beautifully and 100% stable. So give that a shot to revive your lost-cause boards.

If you're having problems flashing, please read the readme in the latest HashVoodoo release. It has several tips/tricks for flashing that help in problem cases.

Anyway, just wanted to post that update (I had a few minutes waiting on an email response, so had some time to breathe between marathon work sessions). So you were all aware of where we're at.

Thanks for your support!

Ah, that could be the bitstream bug I just fixed, though it doesn't generally seem to cause problems with the 200 MH/s bitstream. Please do reflash the badly-performing board with the new dcmwd4e bitstream when you get back home and have got a moment - this is a pain for me to test because the issue takes a while to show up and affects some boards more than others.

Curious. Have you been getting a lot of warnings from cgminer about your pool not providing work fast enough? It's not just the U/m that's underperforming, the MH/s reported by cgminer is lower than it should be and I think that's generally caused by a slow pool.

OK, thank you! I see Glasswalker has spotted this and replied already. Hopefully (touch wood) with the fixes above and/or the new 210 and 220 MH bitstreams I've already released performance should be comfortably over the line and you won't regret paying out. My testing board is actually at 855 MHash/s of a theoretical 860 based on the U/m reported in MPBM right now, though it's only been running for 12 hours. I believe ebereon was seeing similar speeds on his farm with the bitstream this is based on before it started falling over, so (fingers crossed) the new one ought to be able to manage that stably on a decent proportion of boards.

I've actually released full-performance bitstreams (dcmwd4e) with the fix now and am waiting to hear how they work out. My own testing is looking really, really promising though.

Ouch. No wonder you didn't have any time for bitstream development.

Glasswalker: I gave your 200 and 210 versions of the hashvoodoo a try. I can attest to the stability issues, so reverting back to what is rock solid performance of your 175 version.

Hope work allows you to some down time soon, I commend you for still being able to do much else while working those sort of hours.

I do think the total performance issue is a function of my network performance and pool performance.  I also think a little more time tweaking icarus-timing might push it over the hump.

Thanks for the advice Makomk.  I will give the new bitstreams a try once things settle out and my brain is on the same time zone as my body.  ;)

Paid
25 BTC to Glasswalker
25 BTC to Makomk
5 BTC to Kano

Thanks for all the hard work you've put into this guys!

Awesome! Thanks Entropy-uc! We really appreciate your support! (I know I do, and I'm pretty sure I can speak for makomk and kano in that regard too) :)

Thanks!

Question on stability...

I am running the 200MHs bit stream by Makomk on 2 * CM1s, series 460-ish (at work and using memory) and mining using cgminer 2.7.0 (have used 2.6.1 for a few weeks previous to upgrade).

My concern is that the CM1 boards hang several times a day with all orange lights coming on. This is normally preceded by a "lame duck" event were one of the FPGAs go offline first (normally #2 and rates drop to 2~4u/m). The red "heart beat" still continues. The only way to get them mining again is to shutdown cgminer, then disconnect power to reset the boards and fire it back up. 75% of the time I also need to disconnect the USB comms cable whilst off inorder to reset the comm port. The boards are connected to independent USB ports on my gigabyte MB which has "power boost" dedicated lines so I dont think USB brown outs are the issue.

Is it peoples opinion that the poroblem lies in;
1. the bitstream is unstable, or
2. the CM1 hardware is unstable, or
3. the independent USB lines are causing EMI/EMC issues resulting in the system being unstable, or
4. cgminer has a bug, or
5. something else.

Your help in providing the most popular line of investigation is appreciated.

Hi Entropy,

great to hear you kept your promise and also compensated kano for the CM1 related tweaks in the Icarus driver.

Generally, I was following the development process most of the time at #cm1 and understand that reaching the current state is the outcome of a great teamwork between Glasswalker and makomk, with lots of help from more supporters. Going through the chat logs I'd say that TheSeven contributed significantly, not only with real-time updates to MPBM to support CM1 bitstream development, but also with bitstream development itself and code reviews.

Even if I do not use MPBM, I feel that his contribution deserves some compensation, but this is only my personal view. For the bounty that is soon to be paid out, I therefore suggest to not split the pledged coins to individuals by ourselves, but to send them to Glasswalker and let him distribute them in a fairly manner. He proved his professionalism and can best rate whom to thank for getting where we are now.


@Isokivi: I understand that most of us testers agree that the terms are sufficiently met to pay out the bounty. From my personal contacts with contributors I'd guess that 60% are ok with it. Are you going to initiate a vote and define acceptance criteria to get that officially passed?

Vote up. ..as soon as I can figure out how to make one. As soon as someone tells me where the fuq do I find tools to post a poll.

Actually screw that: If someone is opposed to paying out the bounty speak up in 24h.
After the latest run of flashing my boards, my mpbm reported hashrate is 854Mhs/ board, my average U is 5,78 and the hashrate reported at poolside is 845Mhs/ board. This leaves little room for doubt that the conditions have been met imo.
If your pre #50 board dosent get there, it's hardly the bitstream developers fault.

I'd pay the bounty out and suggest we do so unless relevant and valid arguments emerge and ppl not testing the bitstreams is no argument.

Think it has to be done as a new topic, but instead you select "post new poll". Might be able to do it on an existing post, but it think it's fine to just make a new one.

https://bitcointalk.org/index.php?action=post;board=76.0;poll

I dont see way to exclude every forum member that did not pledge, so I feel the poll is a useless tool for our purposes.

I'm more than happy that my personal requirements have been pretty much met. Everyone has been working hard to get it where it is and i'm only to glad to hand over the bounty now. Hopefully other people feel the same way. Overall i'm very impressed :)

Let the coins roll  :D

Mine might be unstable-ish...but I dont think it is the bitstream and I want to encourage work not stamp it out...

I vote for a release of the bounty....run free with the buffaloes oh wild bitcoins

As I said, I'm ok with paying out the bounty.

I agree, let's release the bounty to the devs for their hard work.   :)

Im good to release also :)

Ok, updated the votes so far in the spreadsheet (https://docs.google.com/spreadsheet/ccc?key=0Au2jspuzErkedHhDSEt5aTVPcUNMMjg4STVnOWV3VkE#gid=0).

For those of you not using Google Docs, this is the current state:

Contributor    BTC       Payment accepted
-----------------------------------------
Arvicco        30        UNKNOWN
Cranky4u        2        YES
dietwice        1        UNKNOWN
Doff            2        UNKNOWN
Fefox           5        UNKNOWN
Hpman           1        UNKNOWN
Isokivi         3        YES
julz            1        UNKNOWN
Lethos          5        UNKNOWN
misternoodle    1        YES
roomservice    10        YES
salty           1        UNKNOWN
ShadesOfMarble  2        YES
Slipbye        10        YES
Slipbye        20        YES
Slipbye        10        YES
Slipbye        10        YES
spiccioli      10        UNKNOWN
spiccioli      10        UNKNOWN
steamboat       9        UNKNOWN
tf101           2        UNKNOWN
zefir          50        YES
-----------------------------------------
           Total BTC: 195
Accepted for Payment: 118 BTC / 61%


Like guessed, we already have 60+% support to release the funds. Please consider dropping me an ACK/NACK either here in the tread, via PM, or in #cm1 to approve your support. As soon as spiccioli and Arvicco (who contributed a large amount but was silent thereafter) confirm, we are at 85+% and ready to transfer.

zefir,

I agree to release funds.

spiccioli

I agree to let the funds to be paid out.
I have a stable and good speed bitstream working (hashvoodoo175) on my 2 boards.
They do not appear to like the faster ones, but with so many reporting good reports for the faster ones I can't blame the bitstream.
So it's achieved what I want and I do look forward to improvements.

thought i had agreed, guess not. I'm down to give em the bounty. (don't quit workin on it though gents :P )

I agree to release funds.

Thanks for your feedback. We are at almost 80% now.

Will contact the remaining folks and we should have a full acceptance tomorrow.

My boards are 430 series yet are unstable too. They often need resetting several times a day.

Can your hashvoodoo175 bitstreamed CM1s run for days or better without needed to be reset?

I don't have a board yet, but the reported rates and stability in the 2 CM threads are good enough for me  - well done and thanks in advance for when I get my board in September :)

The prior release of the 175 (the 175 OC from the 16th) has so far been rock solid stable on all boards I'm aware of it being tested on. (on my boards the highest uptime I had without problems was like 4-5 days, but the only reason I interrupted that was for reflashing or development. Several others reported success reviving pre-50 boards which had major stability problems using this bitstream and now they mine fine).

If you're having stability problems please try out that bitstream and let me know how it goes.

My hope (once I have time to tackle it) is to update a new release to have this kind of stability again (the current release is far less stable).

Yes it appears so. Usually it was something else on the board that gave out first with other bitstreams, but this one lasted so long (2 days+) that it proved their was a small fault with my usb hub. They don't use that now and it's been completely solid since.

what U value should I be expecting from the shortfin200 and 210 streams?

If my memory serves me correct 200 should be above 5.2 (right now I have a 52h run saying 5.44 and 5.54 on 200mhs) I dont have a pair running 210 atm. Currently Im running a mix of 220-200mhs bitstreams, with U:'s between 5.44 and 6.06.

(MH/s) div 71.5 = (U/min) :)

I believe the U factors in invalids too, am I right ? ..what about rejects ?

Utility in cgminer is defined as (total accepted shares / total uptime in minutes), i.e. it is what the pool is paying you for. It considers HW errors, invalids and rejects and is therefore the best available measure for your effective hashing power in the long term.

In contrast to that, the MH/s value reported for Icarus / CM1 may be off if your board has problems. That is due to the lack of explicit reporting when the FPGA searched the whole nonce range without finding a share. If after the given or calculated timeout you do not hear from your CM1, you assume that it processed the range and add 2^32 (or more precisely: the number of hashes you assume should have been processed during this period) to the share counter. In fact, the FPGA might have entered a hang condition and just stopped before being restarted by the watchdog. Then your MH/s value looks better than it actually is.

If your board has no problems, in the long run MH/s = U * 71.58. If you find your board's values are too far off from this relation, watch your board and you should find it being restarted by the watchdog regularly (see the orange LEDs lit).

Note, the orange LED doesn't directly mean the watchdog is firing. All that means is that literally the chip isn't currently hashing, it's waiting for more work from the host.

If the Orange LED is lighting though, it does mean your board isn't hashing during that period (So at least a small percentage of the time, depending on how much the led is lit, it's idle, and not making money). This can simply mean that the job interval is incorrect, or the pool is not providing work fast enough (if the led is only lighting for short bits here and there) but if it's staying on for longer periods of time, like a minute plus, and does it frequently then it likely signifies a hardware (or at least a bitstream) problem.

There is a watchdog in the software typically that attempts to send fresh work down if it hasn't heard from the miner in too long a period. The other watchdog in the FPGA itself is purely for detecting if the DCM goes unstable, and restarts the DCM to acquire a new clock lock.

Yep, that's all true.

My statement is based on the observations I have with some of my boards running makomk's latest 200MHz bitstream. To be safe on the timeout value on SW side, I always run cgminer with --icarus-timing long, which effectively prevents FPGAs from running out of work and idling. What I observe are boards (that always have been 'problematic') flash their orange LED quite often (in the range of every 2 to 5 seconds), which I interpret as watchdog restart. The calculated hashrate for those boards is obviously inaccurate, i.e. the relation between U and MH/s does not match the 71.6 ratio in the long run (12h+).

Bounty transferred: 200 BTC sent to 1KqMBXSmZDFzCsZqp84mNB3QM3t2bV3BaB
Transaction: 2a6823eb8a6c578e5c66f6f9af94fae952acf1329e28b609c9ae09d2a006a707 (https://blockchain.info/tx-index/17241428/2a6823eb8a6c578e5c66f6f9af94fae952acf1329e28b609c9ae09d2a006a707)


Thank you all for the support. And of course thanks to Glasswalker, makomk, TheSeven, and all others for their enormous effort.

after 14 hours 16/18 pairs running the new 210 bitstream on cg 2.6.something are reporting U between 5.46 and 5.72, which seems to be falling into the range of +/- 7% that i have been seeing with the streams.

2 pairs are reporting 3.95 and 4.8, which i will test the 200 stream on on monday to see if I can bring that up to the low 5's.

assuming it's only p3 on the pairs that are failing, that means 94% stable w/ the 210 on 9 boards, though they're only producing ~200mh/s.

nice work guys, keep it up.

Hey, just wanted to say on behalf of Makomk, TheSeven and Myself, thank you all for your support and contributions!

I wanted also to confirm reciept of 200BTC for the bounty payment.

I have redistributed it in the way that makomk, TheSeven and myself discussed:
90BTC was sent to Makomk via TXID: d7381ae9e651f18d8ecb65b98e8d87f77010336b248dca13c97bf09f49ae585b
20BTC was sent to TheSeven via TXID: 063beec9f0cf6cfc602e0e734054d9ff3d9daeaf628d975ce0eb8d6e6d87789d

Bounty has officially been distributed.

Development will of course continue, and we hope to improve features, reliability and peformance significantly over the next little while.

Thanks again!

I can confirm that I've received my portion of this. Thank you!

Indeed, though there's probably not going to be any huge performance improvements from my end of things in the immediate future. The latest dcmwd4e bitstreams are already into ztex territory speed-wise, even though getting your rigs there requires more manual fiddling than it ought to.

all stable now with <1% errors...I added "--icarus -timing long" and now have stabilised 2 CM1s at 380~399MHs...very happy camper

Is it now time to close/lock this thread and redirect all conversation over to "Quad XC6SLX150 Board - Initial Price £400/$640/520€"?

I'm in favor of having one less thread to watch. :)

Oh, BTW, thank you Glasswalker and makomk.

Once I actually *have* some of these boards, I'll send some BTC to y'all.

(And, TheSeven. Which is high time since I'm using MPBM with my BFL Single. And I've enjoyed hacking the Python some myself.)

Link:

 - http://bitcointalk.org/index.php?topic=78239.0

This question is directly related to 'the bounty'.
Maybe there are still a few loose threads to be resolved. :)

Even though the bounty has been paid, IIRC, one of the conditions was that it be solved by an open-source solution with a clearly defined tool-chain and build process.

Have those conditions actually been met?
If so, I'm having a bit of a problem chasing down the info.

Can we have some 'close-out' posts summarizing all that, please.

--

I'm not saying I don't appreciate all y'all's hard work to date, but I am interested into digging into the guts of this stuff myself.

For hashvoodoo, I still need to flesh out the documentation a bit more. But the project files and all required metadata are included in the github, the release is fully opensource.

Using Xilinx ISE 14.1 just clone the git repo, open the project, and synthesize/implement the project. All settings and whatnot are included in the project file already.

Eventually I'll flesh out some documentation on how to do that in detail, but ultimately that's getting into the grey area of using ISE in general, and being familiar at least on some level with FPGA development.

I also believe Makomk's version includes the same project files, but not 100% sure.

I've also included an NCD/NGD of the built version, and the project is setup to use smartguide so you at least get "close to useful" performance...

If you have specific questions, I'll do my best to answer for now, and soon we'll update the docs with more details. But even with the current release, it is a fairly straightforward process to *build* it. The problem is making a release worthy (ie: with useful performance) bitstream isn't a straightforward process regardless of how well we document it. There is a fairly steep learning curve to working with FPGAs in general versus for example compiling a C program.

Does that help?

Yes it does. Thank you.

--

edit: I'll just search this thread to find the git link.

It's in his signature ;)

Mine's a bit annoying in that you can't actually build it from source and get the same level of performance that the released bitstreams reach. There's a source archive in the dcmwd4e release, and if you unpack that, download and unpack the .ncd from http://www.makomk.com/~aidan/shortfin_dcmwd4e_ed_ncd.7z, and add the unpacked .ncd to the supplied project as a SmartGuide file (right-click fpgaminer_top in the left pane in ISE, select SmartGuide, point it at that file) you ought to be able to get speeds that are good enough for testing purposes. If you're willing to do a long SmartXplorer run you ought to be able to get the speeds up to release levels; I didn't because it's a bit hit and miss and would delay the release by quite some time.

Edit: As I've said before, honestly you might be better off using the hexanchus branch if you want to build from source right now ("git clone https://github.com/makomk/Icarus.git; cd Icarus; git checkout -b hexanchus origin/hexanchus"). Slightly slower than the released bitstream, but I think it's the fastest of mine that can actually be built from source, and you should literally just be able to open the project file up in ISE and build it.

Edit 2: hexanchus requires different DIP switch settings though; on all the FPGAs where you'd normally set switch 2 to off, you also need to set switch 4 to off as well.

Thank you. I'll have to turn them on long enough to see his.  :-\

Will this bitstream also work with the "classic" Icarus Boards ?

From what I can tell, they used the bitstream which was originally used for them as a base and modified it for the specific needs of this board.
So no it wouldn't work any more.

Hmm damn.. I get about 420MH/s from the Cairnsmore (one pair of spartan 6) but only 380MH/s from one Icarus..

Sounds about right...  You can try and flash the 220 version to your Cairnsmore for that extra 10MH/s :)

The makomk bitstream don't work for both Icarus FPGA's, but you can try a mix of original icarus bitstream on the first fpga and makomk to the second one or vise versa. This could work.

The makomk bitstreams have the RX/TX changed for the second fpga, as this was the fault of CM1.

eb