Pages:
Author

Topic: Bounty[PAID OUT] : a bitstream for better utilizing the Cairnsmore1 157-294.5btc (Read 21934 times)

sr. member
Activity: 397
Merit: 500
Will this bitstream also work with the "classic" Icarus Boards ?

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
sr. member
Activity: 349
Merit: 250
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 Smiley
legendary
Activity: 2660
Merit: 1240
Hmm damn.. I get about 420MH/s from the Cairnsmore (one pair of spartan 6) but only 380MH/s from one Icarus..
sr. member
Activity: 476
Merit: 250
Keep it Simple. Every Bit Matters.
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.
legendary
Activity: 2660
Merit: 1240
Will this bitstream also work with the "classic" Icarus Boards ?
sr. member
Activity: 476
Merit: 250
It's in his signature Wink
Thank you. I'll have to turn them on long enough to see his.  Undecided
hero member
Activity: 686
Merit: 564
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.
donator
Activity: 543
Merit: 500
sr. member
Activity: 476
Merit: 250
Yes it does. Thank you.

--

edit: I'll just search this thread to find the git link.
sr. member
Activity: 407
Merit: 250
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?
sr. member
Activity: 476
Merit: 250
This question is directly related to 'the bounty'.
Maybe there are still a few loose threads to be resolved. Smiley

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.
legendary
Activity: 2506
Merit: 1010
sr. member
Activity: 476
Merit: 250
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.)
sr. member
Activity: 476
Merit: 250
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. Smiley
hero member
Activity: 810
Merit: 1000
all stable now with <1% errors...I added "--icarus -timing long" and now have stabilised 2 CM1s at 380~399MHs...very happy camper


hero member
Activity: 686
Merit: 564
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.
I can confirm that I've received my portion of this. Thank you!

Development will of course continue, and we hope to improve features, reliability and peformance significantly over the next little while.
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.
sr. member
Activity: 407
Merit: 250
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!
hero member
Activity: 648
Merit: 500
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.
donator
Activity: 919
Merit: 1000
Bounty transferred: 200 BTC sent to 1KqMBXSmZDFzCsZqp84mNB3QM3t2bV3BaB
Transaction: 2a6823eb8a6c578e5c66f6f9af94fae952acf1329e28b609c9ae09d2a006a707


Thank you all for the support. And of course thanks to Glasswalker, makomk, TheSeven, and all others for their enormous effort.
donator
Activity: 919
Merit: 1000
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.
[...]

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+).
Pages:
Jump to: