Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards

[eldentyrell]

This user is currently ignored.

Dear Entropy-usockpuppet,

Please take your trolling to another thread.

Thanks,

  - eldentyrell

[1713567872]

1713567872

[1713567872]

1713567872

[1713567872]

1713567872

[1713567872]

1713567872

[1713567872]

1713567872

[1713567872]

1713567872

[eldentyrell]

Yep.  And I'm currently working on using the onboard FTDI chip for exactly this process.  The code is improving and I hope to have it stable in around a week, but we will see!

Thank you!  I assume you are the same Chris who emailed me; I've sent you back a reply.  Let me know if you need anything else.  Also, for immediate responses to questions -- particularly software-related ones -- ask jfsebastien on #tml-support at irc.tricone-mining.com.

[eldentyrell]

The urjtag maintainers have indicated their intention to accept my patch subject to some modifications; I have made those modifications and resubmitted the patch, so hopefully urjtag svn-2027 and 0.11 will not need to be patched.

The revision changes the command syntax, so the new patch does not work with TML-1.00.  Conversely, the old patch does not work with TML-1.01 unless you add the (undocumented) -Duse_old_urjtag_command=true option, which will be removed at some point in the future.

[eldentyrell]

TML-1.01 has been released.  New bitstream "hilbert" although the performance improvement is under 1% so don't get your hopes up.  The Java code now attempts to imitate the way ztex's miner uses the USB interface; hopefully this will result in triggering fewer bugs.

Relevant changes:


03.Aug.2012  Release v1.01
             Use "pod tdo" instead of "tdo"
             Attempt to imitate ztex's USB code better
             Make is-the-clock-running-check faster
             Base clock frequency estimates on 5s sample instead of 1s
             Add -Dztex_reset_ezusb_before_upload={true,false}
             Add -Dztex_upload_ezusb_firmware={true,false}
             Add -Dztex_reclaim_ezusb_after_upload={true,false}
             Add bitstream hilbert

[eldentyrell]

so hopefully urjtag svn-2027 and 0.11 will not need to be patched.

The patch has been committed.  If you check out the latest urjtag SVN (2027) you don't need to apply any patches.

[eldentyrell]

To all the Enterpoint owners…

Chrisp has done some really amazing work, apparently implementing all the code needed to support the Enterpoint board's native USB interface.  He even got it to mine shares.  Here's the interesting parts of the log he sent me (reproduced with permission):


_________________________________________________________________________
Tricone Mining Logic, host software v1.0

   IF YOU EXPERIENCE HIGH ERROR RATES: try running just one ring at a
   time (e.g. use 'ztex:0:0.0' on command line instead of 'ztex:0').  
   If each ring works error free on its own, but you get errors when  
   running all three, it means your power supply is sagging.          

             adding work source bitcoin.cz
libLibFtdiNative-linux-i386.so
             starting long poll thread
Loaded IDCODE = 3401d093
Loaded IDCODE = 3401d093
Loaded IDCODE = 3401d093
Loaded IDCODE = 3401d093
Found chips
4
[0              ] found new board cairnsmore:0
[cairnsmore:0:3 ] found new chip
[cairnsmore:0:3 ] programming FPGA
             USERCODE before bitstream upload: 0xcafebabe
             chip already programmed and avoid_reprogramming=true; not uploading bitstream
[cairnsmore:0:3 ]   done programming FPGA
[cairnsmore:0:3 ] magic number check ok
[cairnsmore:0:3 ] chip is running bitstream version henkin, built 21d13h51m19s ago
[cairnsmore:0:3 ] chip has 3 rings
[cairnsmore:0:3 ] assuming input clock frequency of 100 Mhz
[cairnsmore:0:3 ] asserting global reset
[cairnsmore:0:3.0] disabling DCM bypass mux
[cairnsmore:0:3.0] opening signcryption channel
[cairnsmore:0:3.0] setting clock to 140 Mhz, mult=7 div=5
[cairnsmore:0:3.0]     ramping clock: mult=7 div=5
[cairnsmore:0:3.0] asserting local reset
[cairnsmore:0:3.1] disabling DCM bypass mux
[cairnsmore:0:3.1] opening signcryption channel
[cairnsmore:0:3.1] setting clock to 140 Mhz, mult=7 div=5
[cairnsmore:0:3.1]     ramping clock: mult=7 div=5
[cairnsmore:0:3.1] asserting local reset
[cairnsmore:0:3.2] opening signcryption channel
[cairnsmore:0:3.2] setting clock to 140 Mhz, mult=7 div=5
[cairnsmore:0:3.2]     ramping clock: mult=7 div=5
[cairnsmore:0:3.2] asserting local reset
             opening signcryption connection to limp.tricone-mining.com/54.247.190.151
[cairnsmore:0:3.0] initializing cipher state
[cairnsmore:0:3.0]   new cipher state = 0x13a39da433f663f53a50e0af
[cairnsmore:0:3.0] loaded job  bc307cb5acfb1884855fc9e3948c07ee0cbaf804a405d9e2ee9d3ba9f57f261f:f6880a81501ea5eb1a083cc9
[cairnsmore:0:3.1] initializing cipher state
[cairnsmore:0:3.1]   new cipher state = 0x971575f48f3b62f24776676e
[cairnsmore:0:3.1] loaded job  f20550dd69fb55a68482848ebf4d738bc22eccc38755ca8936cffdb1ac975672:ca075355501ea5ee1a083cc9
[cairnsmore:0:3.2] initializing cipher state
[cairnsmore:0:3.2]   new cipher state = 0xd040624874dbee74718e75d9
[cairnsmore:0:3.2] loaded job  1ea890fd73d9f9e82ce5d5ec07f30c77456120f3cddddcdd2a9b1ffbbe6589d5:62ed09ce501ea5f01a083cc9
[cairnsmore:0:3.0] decrypting nonce at address 0x00000001
[cairnsmore:0:3.0]   encrypted nonce = 0xb85eb745
[cairnsmore:0:3.0]   found a share: 0xd050f955
[cairnsmore:0:3.0]   pool accepted share
[cairnsmore:0:3.0] decrypting nonce at address 0x000000b8
[cairnsmore:0:3.0]   encrypted nonce = 0xffa071d7
[cairnsmore:0:3.0]   found a share: 0xef5d2ca8
[cairnsmore:0:3.0]   pool accepted share
...
[cairnsmore:0:3.2] loaded job  83ef10a9d7d736cabfdeccef6c9fe5dadfb0df0e74f341c2f199765608f845fa:181fb3ea501ea5f21a083cc9
java.io.IOException: DCM did not lock
   at com.triconemining.miner.DCM.checkDcmLocked(DCM.java:215)
   at com.triconemining.miner.DCM.checkLocked(DCM.java:207)
   at com.triconemining.miner.RingWrapper.recalibrateClock(RingWrapper.java:382)
   at com.triconemining.miner.ChipWrapper.recalibrateClock(ChipWrapper.java:152)
   at com.triconemining.miner.BoardWrapper.reCalibrateAndPlot(BoardWrapper.java:166)
   at com.triconemining.miner.BoardWrapper.run_(BoardWrapper.java:120)
   at com.triconemining.miner.BoardWrapper.run(BoardWrapper.java:73)
   at java.lang.Thread.run(Thread.java:722)


At the moment it appears that the DCM is losing its lock after a while.  I've sent some code to Chris that attempts to work around this in software; hopefully it does.  We'll see.

[ebereon]

Nice to see some success here too

I don't know if it is posible, but makomk got the icarus bitstream working with a dcm watchdog which is reseting the dcm on the cairnsmore boards when it's losing its lock. Can you include something like that in you bitstream or software?

I have this dcm problem on 3 of my 10 boards only on FPGA1, so it is not a generell problem to all boards.

Dunno if that helps

eb

[eldentyrell]

I don't know if it is posible, but makomk got the icarus bitstream working with a dcm watchdog which is reseting the dcm on the cairnsmore boards when it's losing its lock. Can you include something like that in you bitstream or software?

Yes, that's one of the two possible fixes I sent to Chris.  But I'm more hopeful about the other one.  Waiting to hear back.

[eldentyrell]

From the Enterpoint thread, using the TML:

Just a quick update.. I was able to get one of the FPGAs to run stably at clocks of 160,160,160 -> 240 Mhash/s.
I'll keep you guys updated!

Nice!

[rph]

This project rocks. 248MH/s, 39.5C, 1.279V (girard on a -2C)

-rph

[norulezapply]

Elden,

Is it possible to run the tricone mining host software on a Raspberry Pi?

[punin]

Elden,

Is it possible to run the tricone mining host software on a Raspberry Pi?

I've tried it some time ago without success. You can experiment with it also by using ARM version of BTC miner http://blog.villekangas.com/?p=23. I believe some libs used by TML need to be ported. Maybe you can get Ville to do it with a small donation

[eldentyrell]

Is it possible to run the tricone mining host software on a Raspberry Pi?

The TML host software is 100% pure Java.  It will run on any device that Java runs on.

If you're using a JTAG cable you'll need to have urjtag installed, but the TML doesn't link to it -- it forks it as a separate process and talks to it over stdin/stdout.  This way it doesn't have to be recompiled when moving to a new platform.

[eldentyrell]

I've tried it some time ago without success. You can experiment with it also by using ARM version of BTC miner http://blog.villekangas.com/?p=23. I believe some libs used by TML need to be ported. Maybe you can get Ville to do it with a small donation

I think you have this backwards -- the TML host software is 100% pure Java and does not need to be "ported" or even recompiled.  It does not use any libraries (the libFtdiNative.so in the jar file is only for my own nexus6 boards).  The ztex code, on the other hand, has a large native-library component that has to be ported and recompiled for each platform you want to use it on.

[chrisp]

Unfortunately the added fixes to adjust DCM locking and relocking provided no benefit.  Currently only the chip closest to the clock source is functioning stably (250 Mhash/sec).  I also have a serial # <50 board, so I'm uncertain as to if that is related, as enterpoint hasn't stated the change that was made for serial #>50 or a possible RMA plan for those <50.  I will continue plugging along however...

Chris

I don't know if it is posible, but makomk got the icarus bitstream working with a dcm watchdog which is reseting the dcm on the cairnsmore boards when it's losing its lock. Can you include something like that in you bitstream or software?

Yes, that's one of the two possible fixes I sent to Chris.  But I'm more hopeful about the other one.  Waiting to hear back.

[spiccioli]

Unfortunately the added fixes to adjust DCM locking and relocking provided no benefit.  Currently only the chip closest to the clock source is functioning stably (250 Mhash/sec).  I also have a serial # <50 board, so I'm uncertain as to if that is related, as enterpoint hasn't stated the change that was made for serial #>50 or a possible RMA plan for those <50.  I will continue plugging along however...

Chris

I don't know if it is posible, but makomk got the icarus bitstream working with a dcm watchdog which is reseting the dcm on the cairnsmore boards when it's losing its lock. Can you include something like that in you bitstream or software?

Yes, that's one of the two possible fixes I sent to Chris.  But I'm more hopeful about the other one.  Waiting to hear back.

Chrisp,

good news in that the running FPGA runs at 250MH/s and is stable. Bad news in that it is not working for the other three.

Are you going to release your code so that it can be tested with a board with serial number higher than 50?

spiccioli

[Keninishna]

Unfortunately the added fixes to adjust DCM locking and relocking provided no benefit.  Currently only the chip closest to the clock source is functioning stably (250 Mhash/sec).  I also have a serial # <50 board, so I'm uncertain as to if that is related, as enterpoint hasn't stated the change that was made for serial #>50 or a possible RMA plan for those <50.  I will continue plugging along however...

Chris

I don't know if it is posible, but makomk got the icarus bitstream working with a dcm watchdog which is reseting the dcm on the cairnsmore boards when it's losing its lock. Can you include something like that in you bitstream or software?

Yes, that's one of the two possible fixes I sent to Chris.  But I'm more hopeful about the other one.  Waiting to hear back.

Glasswalker mentioned in the enterpoint thread that the bitstream he is working on doesn't require a DCM also hes working on a controller bitstream that fixes for the jtag line and such. I'm guessing the TML bitstream could be made the same way but it would take a bit of work to get it working without the DCM tho :/

[eldentyrell]

Glasswalker mentioned in the enterpoint thread that the bitstream he is working on doesn't require a DCM

Link?

I assume you mean he's using a PLL instead of a DCM.  I would find it pretty hard to believe he was using neither.

[Keninishna]

Glasswalker mentioned in the enterpoint thread that the bitstream he is working on doesn't require a DCM

Link?

I assume you mean he's using a PLL instead of a DCM.  I would find it pretty hard to believe he was using neither.

Sorry I ment the bitstream bounty thread, here https://bitcointalk.org/index.php?topic=94317.msg1077989#msg1077989 and he may have edited his last post but you can read what hes saying in this post about the LVDS clock source.

oh wait he did post in the enterpoint thread https://bitcointalk.org/index.php?topic=78239.msg1088554#msg1088554

Ok, quick update. Unfortunately my last build once again (sigh...) had a bug in the new LVDS clocking. (literally oversight on my part, I put a FALSE where it should have been TRUE for LVDS signal termination... DOH!) anyway, that resulted in continuing stability issues, and caused my latest week long marathon build to be a waste of time... Grumble...

Anyway, this has prompted me to apply another round of code fixes. And I think this one should wrap it up. I've fixed the couple minor bugs that existed, so those problems should be solved. AND I've applied several new fixes as well. Including backporting ALL (that I could find) of makomk's shortfin fixes into the HashVoodoo core now. (With the exception of the DCM watchdog, because it was just to fix the failing DCM, but with the LVDS clock signalling there actually is no DCM at all, so nothing to slap a watchdog on lol).

Anyway, this one has several new fixes, and all of makomk's improvements. Plus I've fixed the nonce range problem (which will cause wrong hashrate to report, and wierd U numbers and such) the chips *should* (provided I didn't bork something up again) hash a full nonce range per chip.

So anyway, just posting this up, these changes are already committed, and pushed up to the github, so they are there for everyone to see And I'm doing a first round build on it now.

Also, I should have a new controller coming very soon (as in within the next day or two) to match this build, which will provide the following improvements/fixes:
- Should solve jtag instability and usb flashing capabilities, meaning people without jtag cables *should* be able to install it (but need to confirm this first for safety)
- It now supports dynamic clocking, it will be crude at this point, but it will allow 2 dip switches to be used to select from 4 different hashing clock rates (while leaving the communications clocks alone to keep stable baud rate)
- 180Mhz
- 190Mhz
- 200Mhz
- 210Mhz

This way with a given board, you can tune it within that range to find the optimal hashing rate without having to reflash various bitstreams (easy overclocking) I'm building the bitstreams to close timing to 180Mhz now, so that lowest one will be the "100% in spec", but typically the chips can easily reach a bit beyond their spec (much like CPUs, they are graded in batches based on quality, and some chips may overclock better than others). In some cases I get lucky and exceed timing. So for example, if I'm shooting for 180Mhz, and manages to close timing, that means that no path within the FPGA will exceed a delay of 5.555ns, but if I manage to close timing with 0.55ns of slack, that means that it's actually only got 5ns of delay, which means it's technically fully "in-spec" for 200Mhz clock. And if I exceed timing by a full 1ns, then we're super lucky, and that means it's in-spec for a 219Mhz clock. Now that doesn't take into account power draw of all the components in the chip, noise at those frequencies, and thermal stability. But it means the more "in-spec" we are, the more "universally stable" it should be at a given clock. So the new overclocking options (however crude for now) should help people dial in what's "best" for their given board.

Down the road this will become an auto-tuned thing in software based on invalid rates to find the optimal share yield per second per chip. (yes technically we can tune each chip independently)

Anyway, just a quick update. I'll post more once I've been able to test it.

Oh and also my new board arrived, so I now have both my #0001 serial number board, and a newer #04xx (can't remember exact number) board, so this lets me test and validate on "both sides of the coin".

[Glasswalker]

Glasswalker mentioned in the enterpoint thread that the bitstream he is working on doesn't require a DCM

Link?

I assume you mean he's using a PLL instead of a DCM.  I would find it pretty hard to believe he was using neither.

Hey, to clarify we're now feeding the clocks directly from the controller chip. The controller provides the hash clock, and the communications clock as 2 seperate signals (hash clock using LVDS signalling, and comm clock using normal single ended clocking at 25Mhz) from the controller. The Enterpoint board has a programmable PLL chip seperate from the controller, which can generate up to 4 seperate clocks, up to like 500Mhz, and it has a 25Mhz oscillator on the board for the primary clock for everything else.

Right now the controller is taking a 200Mhz clock from the clock generator, using a DCM internally to phase shift it 90deg per chip, and taking the 0 deg clock phase, and stepping it down with a /8 divider to get the 25Mhz comm clock. It's then feeding these out to the array FPGAs using LVDS for the 200Mhz, and a regular IO pin for the 25Mhz clock

This way there is no DCM at all, just a standard BUFG for the comm clock, and an IBUFGDS for the LVDS clock. This is still not fully tested though, right now I had a bunch of bugs, which I've fixed, and am running through another smartxplorer batch to close timing after my changes.

My source is now public if that helps you on the TML bitstream dev, it's up on github at https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner

Let me know if you have any specific questions, or if I can help at all.

I don't watch this thread, so you might have to ask in one of the enterpoint threads, or just send me a PM.