Topic: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards - page 22. (Read 119444 times)
July 10, 2012, 09:38:30 AM
Which cable did you use?
July 10, 2012, 08:50:28 AM
hi eldentyrell,
i have tried the last TML version on cairnsmore1 with the following result with the buildin usb to jtag FTDI chip FT4232:
But urjtag show:
Do you know what's wrong here? jtag connect to the cable and "idcode" shows 4x XC6SLX150 FPGAs. It also look's like successfully patched with the "tdo" command.
Can you help here?
Thank you!
eb
i have tried the last TML version on cairnsmore1 with the following result with the buildin usb to jtag FTDI chip FT4232:
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. *
* *
******************************************************************
'xception in thread "main" java.io.IOException: garbled output from urjtag; did you rememeber to apply the patch? got character '
at com.triconemining.jtag.UrJtag.getTDO(UrJtag.java:78)
at com.triconemining.jtag.JtagChainFromRawWires.(JtagChainFromRawWires.java:42)
at com.triconemining.board.UrJtagHost.getBoard(UrJtagHost.java:27)
at com.triconemining.bitcoin.miner.Main.main(Main.java:413)
But urjtag show:
Code:
C:\>jtag
UrJTAG 0.10 #2026
Copyright (C) 2002, 2003 ETC s.r.o.
Copyright (C) 2007, 2008, 2009 Kolja Waschk and the respective authors
UrJTAG is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
There is absolutely no warranty for UrJTAG.
warning: UrJTAG may damage your hardware!
Type "quit" to exit, "help" for help.
jtag> cable FT2232
Connected to libftd2xx driver.
jtag> idcode
Reading 0 bytes of idcode
Read 10010011(0x93) 11010000(0xd0) 00000001(0x01) 00110100(0x34) 10010011(0x93) 11010000(0xd0) 00000001(0x01) 00110100(0x34)
10010011(0x93) 11010000(0xd0) 00000001(0x01) 00110100(0x34) 10010011(0x93) 11010000(0xd0) 00000001(0x01) 00110100(0x34)
00000000(0x00) 00000000(0x00) 00000000(0x00) 00000000(0x00)
jtag> help tdo
Usage: tdo
jtag> tdo
0
jtag>
Do you know what's wrong here? jtag connect to the cable and "idcode" shows 4x XC6SLX150 FPGAs. It also look's like successfully patched with the "tdo" command.
Can you help here?
Thank you!
eb
July 10, 2012, 03:16:42 AM
Elden, is there enough info on the icarus through the wiki http://en.qi-hardware.com/wiki/Icarus for usb support?
I only have 1 jtag cable and therefor can only support 1 of my 4 devices that way.
kind regards
I only have 1 jtag cable and therefor can only support 1 of my 4 devices that way.
kind regards
July 10, 2012, 03:02:47 AM
Just a heads up, I have finally managed to convert my entire mine over to the same code that I'm distributing from tricone-mining.com. This took about a week longer than I expected, but the process forced me to fix a lot of software bugs that would have been pretty embarrassing. If it keeps running smoothly for another day or two I will post the latest stuff and declare it production-ready. I'll also be updating the thread topic with the latest performance numbers after a bit more tuning.
July 10, 2012, 02:47:15 AM
I have no clue if this may or may not be usefull for you Eldentyrell
Neither do I! But if they or one of their users submit a driver for their proprietary USB interface (i.e. a Java class implementing either JtagRawWires or else MiningChip -- whichever is easier; if they use an FTDI chip like I do they're welcome to cut-and-paste from the nexus6 implementation) I will certainly include it. Until then carinsmore is supported via JTAG like all other boards.
July 09, 2012, 02:08:11 PM
Quoting from the Cairnsmore thread:
quote author=yohan link=topic=78239.msg1017131#msg1017131 date=1341773836]
An update (Rev 1.2) to the controller is available on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html. I would not update your board to this unless you have a unit that is underperforming with the twin bitstream. As with all controller updates please be careful that you understand the instructions (Rev 1.1 update) fully before starting and ensure that your power is unlikely to be interrupted. If a controller update goes wrong it is likely that a programming cable will be necessary to perform a unit recovery but do take note of the first line recovery method if first attempt goes wrong another go is possible if unit remains powered.
We will do some more testing and work on the controller this week and there may be further updates.
Whatever revision 1.2+ we reach in the next few days will remain available to support 3rd party bitstream providers longterm but is then likely to be frozen when our own original bitstream becomes available. At this point the controller get a major update to Rev 2.0 signifying the major changes in functionality and all development will be on this branch.
[/quote]
I have no clue if this may or may not be usefull for you Eldentyrell, but taking a look in hopes of getting some actual RoI on my investment in these boards would be greatly appreciated.
quote author=yohan link=topic=78239.msg1017131#msg1017131 date=1341773836]
An update (Rev 1.2) to the controller is available on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html. I would not update your board to this unless you have a unit that is underperforming with the twin bitstream. As with all controller updates please be careful that you understand the instructions (Rev 1.1 update) fully before starting and ensure that your power is unlikely to be interrupted. If a controller update goes wrong it is likely that a programming cable will be necessary to perform a unit recovery but do take note of the first line recovery method if first attempt goes wrong another go is possible if unit remains powered.
We will do some more testing and work on the controller this week and there may be further updates.
Whatever revision 1.2+ we reach in the next few days will remain available to support 3rd party bitstream providers longterm but is then likely to be frozen when our own original bitstream becomes available. At this point the controller get a major update to Rev 2.0 signifying the major changes in functionality and all development will be on this branch.
[/quote]
I have no clue if this may or may not be usefull for you Eldentyrell, but taking a look in hopes of getting some actual RoI on my investment in these boards would be greatly appreciated.
July 07, 2012, 03:46:22 PM
Hm i want to try this but i dont know if my Cooling of The Singles is Good enough..... Im using the stock heat sink (xilence) and no cooler on the underside of the board.
I do have the heat pads provided with the cooler and some not so cheap but 5mm thick (phobya, really expensive leftovers of my oc trials
) ones.
I think the stock pad is to thin but the phobya one are to thick ....
Witch one did u use (I recall that u used some under your cooler?)
I do have the heat pads provided with the cooler and some not so cheap but 5mm thick (phobya, really expensive leftovers of my oc trials
) ones. I think the stock pad is to thin but the phobya one are to thick ....
Witch one did u use (I recall that u used some under your cooler?)
July 07, 2012, 01:48:37 PM
Quote
I'm not sure I understand the question… but if you have any board other than the ztex 1.15x then you must use a JTAG cable. Did that answer it?
I think I already answered my question when I posed it, but yes, you confirmed it. I must have the jtag cable to use your bitstream.
At the moment, just bumping my icarus boards up from 190 to 200mhz makes them have heating issues. 1 has a 40mm fan and the other 3 have 50mm fans, ill be getting 4x120mm and making a flow through enclosure for them next week. That should enable me to test out your bitstream too.
kind regards
July 07, 2012, 12:59:54 PM
How about eilenberg
Ah, how could I forget! For some reason Wikipedia left him off the list. I ought to use my bookshelf instead of their page.
or euler?
Eminent, but not eligible.
July 07, 2012, 12:58:27 PM
Am I reading it right that I have to run your bitstream while attached to my jtag setup?
I'm not sure I understand the question… but if you have any board other than the ztex 1.15x then you must use a JTAG cable. Did that answer it?
July 07, 2012, 08:59:47 AM
Elden, im getting some better cooling for my icarus next week so ill give your bitstream a shot on one of them once im setup.
Am I reading it right that I have to run your bitstream while attached to my jtag setup?
kind regards
Am I reading it right that I have to run your bitstream while attached to my jtag setup?
kind regards
July 07, 2012, 08:33:42 AM
Let me guess.. next bitstream will be called fraenkel? 
Yes, but only because I couldn't find a name that starts with "E".
How about eilenberg or euler?
Or Elden?
July 07, 2012, 06:12:30 AM
I spent over one whole day fiddling with this and I am kind of giving up for now,... I can't replicate any of these results, yet they were real.
I saw
davis, 1.313v, 30m
davis, 1.35v, 15m
Right now one in 5 or 10 runs starts with returning valid results and they mostly end up like this:
(1.307v: 10m, 12m, 15m, 22m)
-Dtriconemining.recalibrate_clock=false and/or -Dtriconemining.allow_local_reset=true didn't seem to help.
EDIT: After running ztex over night, board seems to respond to TML again. At least the first try... we'll see.
Got again just one short run out of that.
I saw
Code:
H:181/34,78,92 X:256 C:168,172,172 E:9/22,0,11 T:15m | H:181/34,78,92 E:9/22,0,11 A:34 R:3 T:14m31s
with my own eyes. And upon it, i ran Code:
H:138/38,23,84 X:254 C:165,172,172 E:14/0,50,0 T:15m | H:124/35,23,84 E:14/0,50,0 A:29 R:0 T:16m19s
with fixed clocks. Ring 1 was still a bit too hot apparently, but after that I didn't get any good runs. Maybe one.davis, 1.313v, 30m
davis, 1.35v, 15m
Right now one in 5 or 10 runs starts with returning valid results and they mostly end up like this:
(1.307v: 10m, 12m, 15m, 22m)
-Dtriconemining.recalibrate_clock=false and/or -Dtriconemining.allow_local_reset=true didn't seem to help.
EDIT: After running ztex over night, board seems to respond to TML again. At least the first try... we'll see.
Got again just one short run out of that.
July 07, 2012, 04:16:44 AM
July 07, 2012, 03:23:18 AM
Let me guess.. next bitstream will be called fraenkel?
Yes, but only because I couldn't find a name that starts with "E".
How about eilenberg or euler?
July 06, 2012, 05:36:35 PM
Attempted the new bitstream and java jar on enterpoint. Able to program the bitstream, however, clock detection fails. It will the majority of the time detect erratic results on the CSG package pin L22 and often not continue to the J1 detection. K20 doesn't seem to be an issue and reliably detects 0. Then when detecting the J1 pin should it get that far, the results are quite unreliable.
Chris, you'll need to be more specific than that. Please post a log file for each of these behaviors.
Both runs completed back to back. Input clock should be 50 mhz on cairnsmore pin.
Chris, a few things:
1. Please post (a link to) the logs, not a screenshot of the logs.
2. Please don't use -Dtriconemining.avoid_reprogramming=true unless you're 100% sure you know it won't cause problems. In this case that option is preventing the chip from being reset between runs, which is causing at least part of your clock-pin-detection problems.
3. The logs you posted are incomplete; it seems like you either truncated them or killed the software after the first "ramping clock" line -- please let it keep running until you get an error and/or things work (or get stuck).
July 06, 2012, 02:56:14 PM
Attempted the new bitstream and java jar on enterpoint. Able to program the bitstream, however, clock detection fails. It will the majority of the time detect erratic results on the CSG package pin L22 and often not continue to the J1 detection. K20 doesn't seem to be an issue and reliably detects 0. Then when detecting the J1 pin should it get that far, the results are quite unreliable.
Chris, you'll need to be more specific than that. Please post a log file for each of these behaviors.
Both runs completed back to back. Input clock should be 50 mhz on cairnsmore pin.
http://s15.postimage.org/cni27ojaz/Capture.png
http://s10.postimage.org/44qjz8rs9/Capture2.png
July 06, 2012, 01:49:56 PM
Attempted the new bitstream and java jar on enterpoint. Able to program the bitstream, however, clock detection fails. It will the majority of the time detect erratic results on the CSG package pin L22 and often not continue to the J1 detection. K20 doesn't seem to be an issue and reliably detects 0. Then when detecting the J1 pin should it get that far, the results are quite unreliable.
Chris, you'll need to be more specific than that. Please post a log file for each of these behaviors.
July 06, 2012, 01:47:40 PM
Let me guess.. next bitstream will be called fraenkel?
Yes, but only because I couldn't find a name that starts with "E".
July 06, 2012, 12:37:57 PM
TML-0.999 is posted.
Please upgrade if you care about performance; all previous versions have a serious performance bug that causes valid shares to silently be "lost". The number of shares-per-second lost scales non-linearly with clock rate which is why I didn't notice it before. Please do not report performance numbers using anything earlier than 0.999; those numbers will be skewed low. The bug manifests itself as the hashrate (H: number) being much lower than the expected hashrate (X: number) even when the error percentage is zero -- that should never happen!
Attempted the new bitstream and java jar on enterpoint. Able to program the bitstream, however, clock detection fails. It will the majority of the time detect erratic results on the CSG package pin L22 and often not continue to the J1 detection. K20 doesn't seem to be an issue and reliably detects 0. Then when detecting the J1 pin should it get that far, the results are quite unreliable.
Chris
Jump to: