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

[eldentyrell]

hmm... it's now hard for me to help you futher...

But, you can open a cmd and you can start jtag in any directory? and if yes you can type "tdo" after connecting to the cable and get a "0" or "1" back?

yup. Maybe ET will know better, I'm not too good at debugging java.

Sorry about that; it was probably this bug; please re-download tml-0.999w.jar.

[eldentyrell]

So, good news and bad news.

Bad news first: I woke up this morning to find the mine giving back 100% invalids on more than half the boards.

Good news: having a huge sample set helped me isolate a really subtle clocking bug that is present -- to varying degrees -- in all bitstreams released so far.  It has to do with the clock domain crossing between the ring clock and the host-interface clock.  How serious the effects are varies widely from board to board, which probably explains why kakobreklaa and punin were reporting that some bitstreams were "lucky" for them.

I've fixed the bug, and my mine is now performing above its pre-switchover hashrate (which was based on a six-week-old pre-0.9 bitstream) but the non-nexus6-only bitstreams won't finish building for another 10-12 hours.  I'm stuck in meetings again all day tomorrow, but I will try to post a release candidate tomorrow evening or Friday mid-day at the latest.

[Keninishna]

hmm... it's now hard for me to help you futher...

But, you can open a cmd and you can start jtag in any directory? and if yes you can type "tdo" after connecting to the cable and get a "0" or "1" back?

yup. Maybe ET will know better, I'm not too good at debugging java.

Sorry about that; it was probably this bug; please re-download tml-0.999w.jar.

Nope, not that bug as eb posted his fixed version earlier but its odd that it gets further for him than me. Only a few things I can think of, maybe I have a differn't version of JRE or my board is just differen't than his.

[spiccioli]

Hi,

following ebereon's steps, I have programmed FPGA3 on my cairnsmore1 board serial 0008, controller rev. 1.2, with tml-davis.bit from latest version available on tricone-mining. I've programmed it as a not permanent bitstream.

Then I've attached this board to my vista laptop and started it as

Code:

java -jar tml-0.999mod.jar urjtag:FT2232 http://user:pw@pool.abcpool.co:8332/

I'm using latest available java

Code:

java -version
java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
Java HotSpot(TM) Client VM (build 23.1-b03, mixed mode, sharing)

And this is what I get

Code:

   ******************************************************************
   *                                                                *
   *               IF YOU EXPERIENCE HIGH ERROR RATES:              *
   *                                                                *
   *  Try running just one ring at a time (e.g. use 'ztex: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.                        *
   *                                                                *
   ******************************************************************

[urjtag:0:0] programming FPGA
             USERCODE before bitstream upload: 0xcafebabe
             USERCODE after bitstream upload: 0xcafebabe
[urjtag:0:0]   done programming FPGA
[urjtag:0:0] magic number check ok
[urjtag:0:0] chip is running bitstream version davis, built 8 days, 9 hours ago
[urjtag:0:0] design is intended for input clock frequency of 48 Mhz
[urjtag:0:0] measuring clock frequency at ztex pin (csg484.L22)
[urjtag:0:0] measured input clock frequency at 0 Mhz
[urjtag:0:0] measuring clock frequency at nexus6/x6500 pin (fgg484.K20)
[urjtag:0:0] measured input clock frequency at 0 Mhz
[urjtag:0:0] measuring clock frequency at icarus/carinsmore pin (fgg484.J1)
[urjtag:0:0] measured input clock frequency at 66 Mhz
[urjtag:0:0] assuming input clock frequency of 48 Mhz
[urjtag:0:0] chip has 3 rings
[urjtag:0:0:0] opening signcryption channel
[urjtag:0:0:0] setting clock to 157 Mhz, mult=23 div=7
[urjtag:0:0:0]     ramping clock: mult=8 div=7
[urjtag:0:0:0]     ramping clock: mult=9 div=7
[urjtag:0:0:0]     ramping clock: mult=10 div=7
Exception in thread "main" java.io.IOException: DCM PROGDONE did not go high aft
er programming
        at com.triconemining.bitcoin.miner.DCM.setClockFrequency(DCM.java:173)
        at com.triconemining.bitcoin.miner.DCM.setClockFrequency(DCM.java:86)
        at com.triconemining.bitcoin.miner.Ring.setClockFrequency(Ring.java:278)
H:←[1m←[32m0←[0m←[0m/←[32m0←[0m X:0 C:0 E:←[1m←[31m0←[0m←[0m/←[31m0←[0m T:15m
|  H:←[1m←[32m0←[0m←[0m/←[32m0←[0m E:←[1m←[31m0←[0m←[0m/←[31m0←[0m A:←[32m0←[0m
R:←[33m0←[0m T:1m8s
        at com.triconemining.bitcoin.miner.Miner.enableRing(Miner.java:190)
        at com.triconemining.bitcoin.miner.Miner.enableRing(Miner.java:121)
        at com.triconemining.bitcoin.miner.Main.main(Main.java:426)
[urjtag:0:0:0] setting clock to 5 Mhz, mult=5 div=48
H:←[1m←[32m0←[0m←[0m/←[32m0←[0m X:0 C:0 E:←[1m←[31m0←[0m←[0m/←[31m0←[0m T:15m
|  H:←[1m←[32m0←[0m←[0m/←[32m0←[0m E:←[1m←[31m0←[0m←[0m/←[31m0←[0m A:←[32m0←[0m
[urjtag:0:0:0]     ramping clock: mult=67 div=48
H:←[1m←[32m0←[0m←[0m/←[32m0←[0m X:0 C:0 E:←[1m←[31m0←[0m←[0m/←[31m0←[0m T:15m
|  H:←[1m←[32m0←[0m←[0m/←[32m0←[0m E:←[1m←[31m0←[0m←[0m/←[31m0←[0m A:←[32m0←[0m
java.lang.RuntimeException: java.io.EOFException[urjtag:0:0:0]     ramping clock
: mult=66 div=48

H:←[1m←[32m0←[0m←[0m/←[32m0←[0m X:0 C:0 E:←[1m←[31m0←[0m←[0m/←[31m0←[0m T:15m
|  H:←[1m←[32m0←[0m←[0m/←[32m0←[0m E:←[1m←[31m0←[0m←[0m/←[31m0←[0m A:←[32m0←[0m
R:←[33m0←[0m T:1m8s     at com.triconemining.limp.LimpConnection.run(LimpConnect
ion.java:53)
        at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException
        at com.triconemining.util.VarInt.read(VarInt.java:16)
        at com.triconemining.limp.LimpConnection.run(LimpConnection.java:50)
        ... 1 more
[urjtag:0:0:0]     ramping clock: mult=65 div=48
H:←[1m←[32m0←[0m←[0m/←[32m0←[0m X:0 C:0 E:←[1m←[31m0←[0m←[0m/←[31m0←[0m T:15m
|  H:←[1m←[32m0←[0m←[0m/←[32m0←[0m E:←[1m←[31m0←[0m←[0m/←[31m0←[0m A:←[32m0←[0m
[urjtag:0:0:0]     ramping clock: mult=64 div=48
H:←[1m←[32m0←[0m←[0m/←[32m0←[0m X:0 C:0 E:←[1m←[31m0←[0m←[0m/←[31m0←[0m T:15m
|  H:←[1m←[32m0←[0m←[0m/←[32m0←[0m E:←[1m←[31m0←[0m←[0m/←[31m0←[0m A:←[32m0←[0m
[urjtag:0:0:0]     ramping clock: mult=63 div=48
H:←[1m←[32m0←[0m←[0m/←[32m0←[0m X:0 C:0 E:←[1m←[31m0←[0m←[0m/←[31m0←[0m T:15m
|  H:←[1m←[32m0←[0m←[0m/←[32m0←[0m E:←[1m←[31m0←[0m←[0m/←[31m0←[0m A:←[32m0←[0m
R:←[33m0←[0m T:1m8s java.io.IOException: TML acknowledgement of read operation f
ailed; expected=0x435 got=0xfffffde5
        at com.triconemining.board.MiningChip.read(MiningChip.java:65)
        at com.triconemining.bitcoin.miner.DCM.progDone(DCM.java:199)
        at com.triconemining.bitcoin.miner.DCM.setClockFrequency(DCM.java:169)
        at com.triconemining.bitcoin.miner.DCM.setClockFrequency(DCM.java:86)
        at com.triconemining.bitcoin.miner.Ring.setClockFrequency(Ring.java:278)

        at com.triconemining.bitcoin.miner.Main.run(Main.java:191)
        at java.lang.Thread.run(Unknown Source)

So it seems to be talking with FPGA3 but then it dies with some IO exception.

spiccioli

[gigantic]

Hi,

following ebereon's steps, I have programmed FPGA3 on my cairnsmore1 board serial 0008, controller rev. 1.2, with tml-davis.bit from latest version available on tricone-mining. I've programmed it as a non permament bitstream.



spiccioli

seems like EP releasing controller rev. 1.3 today, just for you to know.

[punin]

Hmmm.. I find these worrying:

[urjtag:0:0] measured input clock frequency at 66 Mhz
[urjtag:0:0] assuming input clock frequency of 48 Mhz

Earlier ebereon had:

[urjtag:0:0] measured input clock frequency at 49 Mhz
[urjtag:0:0] assuming input clock frequency of 48 Mhz

I would imagine we would need more consistency in clock frequency for reliable operation. Or am I lost here?

[eldentyrell]

[urjtag:0:0] measured input clock frequency at 66 Mhz
[urjtag:0:0] assuming input clock frequency of 48 Mhz

The clock frequency detection is done by reading an on-chip LFSR, waiting for 1 second (using the host CPU clock) reading the LFSR again, and then calculating how many times the LFSR was incremented during that 1 second window.  Any sort of extra delay (heavy CPU load on your computer, weird jtag drivers, etc) will introduce inaccuracies in the measurement.  I will increase the sampling period to 5 seconds to compensate for this.

At the moment the "detected" clock frequency isn't used for anything; it's just printed out for informational purposes.  The idea is that you run the TML, look at the frequency, then run it again with -Dtriconemining.clock_pin_freq=X based on what you saw in the logs.

[eldentyrell]

Heads up folks, I'm rolling out the final upgrades to the signcryption servers this afternoon in preparation for "production ready".  Unfortunately these changes break a lot of older pre-1.0 bitstreams… normally I wouldn't do this but as I mentioned before it turns out they're already broken in other ways, so I decided getting 1.0 done earlier outweighed continuing support for pre-1.0 bitstreams.  Going forward I will always attempt to preserve support for old bitstreams for as long as possible.

[eldentyrell]

irc.tricone-mining.com is currently down due to ongoing fail on the part of momentovps.

I'll move it to another server if they can't get their act together by the end of the day.

[eldentyrell]

irc.tricone-mining.com is currently down due to ongoing fail on the part of momentovps.

I'll move it to another server if they can't get their act together by the end of the day.

I have moved the IRC server to another VPS and removed the momentovps machine from the signcryption pool (there are 9 others).  I will not be using momentovps' services in the future.

That was a huge waste of my time.

[ShadesOfMarble]

This is how far I get using patched urjtag, 0.999w and fraenkel:

Code:

   Eldentyrell will declare this codebase ready for production use
   once he has converted his own mine to use it (yes, he pays himself
   commissions).  Until then, performance and signcryption server
   uptime are likely to be erratic.

   Here is a partial list of issues you should be aware of:

     - many kinds of errors (network, etc) cause the miner to get stuck
     - only one of the signcryption frontends is contacted
     - clock-rate adjustment is 100% manual, not automatic
     - no overheat protection >>MAKE SURE YOU HAVE A HEATSINK INSTALLED<<


   ******************************************************************
   *                                                                *
   *               IF YOU EXPERIENCE HIGH ERROR RATES:              *
   *                                                                *
   *  Try running just one ring at a time (e.g. use 'ztex: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.                        *
   *                                                                *
   ******************************************************************

[urjtag:0:0] programming FPGA
             USERCODE before bitstream upload: 0xcafebabe
             USERCODE after bitstream upload: 0xcafebabe
[urjtag:0:0]   done programming FPGA
[urjtag:0:0] magic number check ok
[urjtag:0:0] chip is running bitstream version 0x4ff5022e, built 9 days, 6 hours ago
[urjtag:0:0] design is intended for input clock frequency of 48 Mhz
[urjtag:0:0] measuring clock frequency at ztex pin (csg484.L22)
[urjtag:0:0] measured input clock frequency at 227 Mhz
[urjtag:0:0] assuming input clock frequency of 48 Mhz
[urjtag:0:0] chip has 3 rings
[urjtag:0:0] ?[31munknown gateware version 0x4ff5022e?[0m
[urjtag:0:0:0] opening signcryption channel
[urjtag:0:0:0] setting clock to 100 Mhz, mult=25 div=12
[urjtag:0:0:0]     ramping clock: mult=13 div=12
[urjtag:0:0:0]     ramping clock: mult=14 div=12
H:?[1m?[32m0?[0m?[0m/?[32m0?[0m X:0 C:0 E:?[1m?[31m0?[0m?[0m/?[31m0?[0m T:15m   |  H:?[1m?
[32m0?[0m?[0m/?[32m0?[0m E:?[1m?[31m0?[0m?[0m/?[31m0?[0m A:?[32m0?[0m R:?[33m0?[0m T:22s j
ava.io.IOException: DCM PROGDONE did not go high after programming
        at com.triconemining.bitcoin.miner.DCM.setClockFrequency(DCM.java:173)
        at com.triconemining.bitcoin.miner.DCM.setClockFrequency(DCM.java:86)
        at com.triconemining.bitcoin.miner.Ring.setClockFrequency(Ring.java:278)
        at com.triconemining.bitcoin.miner.Miner.enableRing(Miner.java:190)
        at com.triconemining.bitcoin.miner.Miner.enableRing(Miner.java:159)
        at com.triconemining.bitcoin.miner.Main.main(Main.java:426)

No share got submitted.

[kakobrekla]

Hrm, can't resist dumping it here :p

H:343/114,85,143 X:253 C:175,165,166 E:4/11,0,0 T:5m | H:257/69,94,105 E:11/13,10,12 A:74 R:0 T:20m37s




I'm sure i'm gonna push it further.

[spiccioli]

eldentyrell,

can the fpga constraints file help you in porting your bitstream to the cairnsmore boards?

http://www.enterpoint.co.uk/cairnsmore/CAIRNSMORE1_ARRAY_FPGA.ucf


spiccioli.

[eldentyrell]

can the fpga constraints file help you in porting your bitstream to the cairnsmore boards?
http://www.enterpoint.co.uk/cairnsmore/CAIRNSMORE1_ARRAY_FPGA.ucf

It has already been ported.  That board has been fully supported for several days now.

  - e

[spiccioli]

can the fpga constraints file help you in porting your bitstream to the cairnsmore boards?
http://www.enterpoint.co.uk/cairnsmore/CAIRNSMORE1_ARRAY_FPGA.ucf

It has already been ported.  That board has been fully supported for several days now.

  - e

eldentyrell,

maybe I'm missing something, but my tests and tests from other users (see previous messages) all end up with an IOException and without hashing a single share.

Do you have any hint on what I'm doing wrong?

spiccioli

[ebereon]

can the fpga constraints file help you in porting your bitstream to the cairnsmore boards?
http://www.enterpoint.co.uk/cairnsmore/CAIRNSMORE1_ARRAY_FPGA.ucf

It has already been ported.  That board has been fully supported for several days now.

  - e

eldentyrell,

maybe I'm missing something, but my tests and tests from other users (see previous messages) all end up with an IOException and without hashing a single share.

Do you have any hint on what I'm doing wrong?

spiccioli

I need also a hint how this should work. I tested tml v 0.999w.

[ShadesOfMarble]

can the fpga constraints file help you in porting your bitstream to the cairnsmore boards?
http://www.enterpoint.co.uk/cairnsmore/CAIRNSMORE1_ARRAY_FPGA.ucf

It has already been ported.  That board has been fully supported for several days now.

  - e

I guess "fully supported" does not imply "producing valid shares"?

[roomservice]

can the fpga constraints file help you in porting your bitstream to the cairnsmore boards?
http://www.enterpoint.co.uk/cairnsmore/CAIRNSMORE1_ARRAY_FPGA.ucf

It has already been ported.  That board has been fully supported for several days now.

  - e

I guess "fully supported" does not imply "producing valid shares"?

I guess a bunch of users, including me, would love to use this bitstream. But we really need some help to get it started via usb interface.

[eldentyrell]

But we really need some help to get it started via usb interface.

Please contact the company who sold you the proprietary interface and ask them to write a driver!

[eldentyrell]

I guess "fully supported" does not imply "producing valid shares"?

Of course it does, but only on properly-functioning hardware!  Regarding your specific problem, here are my thoughts:

This is how far I get using patched urjtag, 0.999w and fraenkel:


java.io.IOException: DCM PROGDONE did not go high after programming
        at com.triconemining.bitcoin.miner.DCM.setClockFrequency(DCM.java:173)
        at com.triconemining.bitcoin.miner.DCM.setClockFrequency(DCM.java:86)
        at com.triconemining.bitcoin.miner.Ring.setClockFrequency(Ring.java:278)
        at com.triconemining.bitcoin.miner.Miner.enableRing(Miner.java:190)
        at com.triconemining.bitcoin.miner.Miner.enableRing(Miner.java:159)
        at com.triconemining.bitcoin.miner.Main.main(Main.java:426)

That is not a good sign; it usually indicates that something is flaky-borderline-defective with your board.  Your DCM is not locking -- that is a hardware problem.  You are the only person who has reported this particular problem, although I have seen it on two of my boards that had solder-ball attachment problems.  You'll also get this error if you force the TML to use the wrong clock pin (by overriding its automatic clock-detection with -Dclock_pin=WRONG_PIN_HERE).

Please try TML-1.0; you may have better luck.

You might be able to hack around it by specifying the clock frequency manually and disabling clock calibration; this will result in the DCM being reset fewer times.  But long-term you should have your board, its power supply, and/or its clock input checked out.