TML-1.0 has been posted.
Please see the update to the first post in the thread regarding development; new features will be on hold until 07-Sep, but we will be posting bugfixes and new bitstreams (resulting from sweeping the space of Xilinx synthesis tool options) in the meantime.
Topic: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards - page 19. (Read 119429 times)
July 20, 2012, 05:18:05 AM
July 20, 2012, 05:17:50 AM
TML-1.0 has been posted.
Please see the update to the first post in the thread regarding development; new features will be on hold until 07-Sep, but we will be posting bugfixes and new bitstreams (resulting from sweeping the space of Xilinx synthesis tool options) in the meantime.
Please see the update to the first post in the thread regarding development; new features will be on hold until 07-Sep, but we will be posting bugfixes and new bitstreams (resulting from sweeping the space of Xilinx synthesis tool options) in the meantime.
How about cluster support?
July 20, 2012, 05:17:41 AM
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)
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.
July 20, 2012, 05:13:49 AM
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!
July 20, 2012, 04:53:30 AM
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
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 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.
July 20, 2012, 04:21:45 AM
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
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
July 20, 2012, 04:09:37 AM
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
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.
July 20, 2012, 04:06:26 AM
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
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
July 20, 2012, 04:00:37 AM
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
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
July 18, 2012, 08:00:57 AM
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.
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.
July 16, 2012, 05:05:48 PM
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.
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.
July 14, 2012, 05:12:43 AM
This is how far I get using patched urjtag, 0.999w and fraenkel:
No share got submitted.
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.
July 13, 2012, 06:55:13 PM
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'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.
July 13, 2012, 05:57:11 PM
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'll move it to another server if they can't get their act together by the end of the day.
July 13, 2012, 05:49:49 PM
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.
July 13, 2012, 05:47:34 PM
[urjtag:0:0] measured input clock frequency at 66 Mhz
[urjtag:0:0] assuming input clock frequency of 48 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.
July 12, 2012, 05:38:30 PM
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?
[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?
July 12, 2012, 11:00:33 AM
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
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.
July 12, 2012, 10:55:46 AM
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
I'm using latest available java
And this is what I get
So it seems to be talking with FPGA3 but then it dies with some IO exception.
spiccioli
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:[email protected]: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
July 12, 2012, 01:12:40 AM
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?
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.
Jump to: