Topic: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards - page 26. (Read 119440 times)
June 24, 2012, 04:27:00 PM
if he can't do it ill do it tomorrow (late evening german time) on one of my 6 singles
June 24, 2012, 04:19:08 PM
My host has currently 20 Ztex 1.15x
Did you get a chance to unplug one of those and move it to another machine?
June 24, 2012, 04:58:01 AM
… ztex:20 …
Multiple boards aren't supported yet. Please use a machine with exactly one ztex board attached to it (and, therefore, change the command line to ztex:0 instead of ztex:20) instead of a machine with more than 21 (!?!?) ztex boards.
I see
My host has currently 20 Ztex 1.15x and 3 1.15y connected. If it helps i'll be happy to give you remote access in order to implement multi fpga support.
June 23, 2012, 06:35:23 PM
… ztex:20 …
Multiple boards aren't supported yet. Please use a machine with exactly one ztex board attached to it (and, therefore, change the command line to ztex:0 instead of ztex:20) instead of a machine with more than 21 (!?!?) ztex boards.
June 23, 2012, 01:26:06 AM
Just tried it out - but experience some java errors:
http://pastebin.com/61iDAAHS
Using latest Ztex Firmware (ZtexBTCMiner-120622.jar) if that matters. Any help would be appreciated.
http://pastebin.com/61iDAAHS
Using latest Ztex Firmware (ZtexBTCMiner-120622.jar) if that matters. Any help would be appreciated.
June 22, 2012, 05:20:26 PM
TML-0.91 posted. 153mhz = 230MH/s/chip on my ztex board.
I'll be spending the weekend converting my own mine over to this branch of the code, so things will be kinda quiet.
I'll be spending the weekend converting my own mine over to this branch of the code, so things will be kinda quiet.
June 22, 2012, 04:05:16 AM
is it only for the 1.15x or also for the y?
I've only tested in on the 1.15x. USB is definitely only supported on the 1.15x.
Since the 1.15y takes the same clock input on the same pin, you can in theory use the same bitstream, but you'll have to talk to it via a JTAG cable because the FPGA-USB connections are different.
The source is in the jarfile; if somebody sends me a patch to support communication over USB with the Y board I will include it. I don't have (or really want) a board to test it on, though. Look in com/triconemining/board/Ztex.java and create a new ZtexBoard class whose getNumChips() method returns 4 instead of 1. Let me know if the I/O pins need to be moved; hopefully they don't.
1.15y FPGA Boards require a few modifications, see the porting guide for details: http://wiki.ztex.de/doku.php?id=en:ztex_boards:ztex_fpga_boards:porting_to_1_15y
June 22, 2012, 04:04:09 AM
Also, you can play around with different clock frequencies by changing the command line. For example, to use a 144mhz clock, change it from the default
java ….ztex:0 http://mypool
to
java …. ztex:0@144 http://mypool
java ….ztex:0 http://mypool
to
java …. ztex:0@144 http://mypool
June 22, 2012, 03:23:37 AM
is it only for the 1.15x or also for the y?
I've only tested in on the 1.15x. USB is definitely only supported on only the 1.15x and not other boards.
Since the 1.15y takes the same 48mhz clock input on the same pin L22 of each of the four chips (smart thinking, ztex), you can use the exact same bitstream on the 1.15y -- but you'll have to talk to it via a JTAG cable because the FPGA-USB connections are slightly different.
The source is in the jarfile; if somebody sends me a patch to support communication over USB with the Y board I will include it. I don't have (or really want) a board to test it on, though. Look in com/triconemining/board/Ztex.java and create a new ZtexBoard class whose getNumChips() method returns 4 instead of 1. Let me know if the I/O pins need to be moved; hopefully they don't.
June 22, 2012, 03:14:49 AM
Would you be so nice and tell me whether this JTAG software you are using supports the original Xilinx JTAG tools?
Because that's all I have.
Because that's all I have.
Tml-0.9 supports the ztex 1.15x boards via the USB interface. You don't need a JTAG cable.
You can use a jtag cable for other boards, but they'll need to have a 48Mhz clock input on the same pin as the ztex chip: L22 in the csg484 package or J22 on the fgg484 package.
Here's the page that lists the cables supported by urjtag:
http://sourceforge.net/apps/mediawiki/urjtag/index.php?title=Cables
I'm quite happy to generate bitstreams for other boards; just let me know what pin is the clock input, what frequency it is, and whether you're using the csg484 or fgg484 package -- I'll get you a bitstream that works with any urjtag-supported JTAG cable within 48 hours so you can start trying things out. If you want to use some sort of non-JTAG communication (typically USB) you'll need to submit a board kit API implementation. Download the jarfile and refer to README.bdk for instructions. It's not as hard as it sounds and you can cut-and-paste from the two existing implementations (crappy-tyrell-corporation-boards and ztex-1.15x boards) as you please.
June 22, 2012, 01:56:49 AM
is it only for the 1.15x or also for the y?
June 22, 2012, 01:44:38 AM
Okay, I'm gonna pull the trigger on this thing. I have posted tml-0.9.jar.
Only 222MH/s right now, but it's a start, and this way I can start to get feedback and independent confirmation. Don't expect 222MH/s unless you have a really good cooling setup. No commissions for at least the next week.
There will be another small speed bump in the morning or early afternoon tomorrow when the next build finishes; once that's out I'll make a more formal announcement. No press releases this time, though… I've depleted all $89 of my press budget.
The jar file also includes the final version of the board developer API.
Only 222MH/s right now, but it's a start, and this way I can start to get feedback and independent confirmation. Don't expect 222MH/s unless you have a really good cooling setup. No commissions for at least the next week.
There will be another small speed bump in the morning or early afternoon tomorrow when the next build finishes; once that's out I'll make a more formal announcement. No press releases this time, though… I've depleted all $89 of my press budget.
The jar file also includes the final version of the board developer API.
Would you be so nice and tell me whether this JTAG software you are using supports the original Xilinx JTAG tools?
Because that's all I have.
June 22, 2012, 01:21:39 AM
Okay, I'm gonna pull the trigger on this thing. I have posted tml-0.9.jar.
Only 222MH/s right now, but it's a start, and this way I can start to get feedback and independent confirmation. Don't expect 222MH/s unless you have a really good cooling setup. No commissions for at least the next week.
There will be another small speed bump in the morning or early afternoon tomorrow when the next build finishes; once that's out I'll make a more formal announcement. No press releases this time, though… I've depleted all $89 of my press budget.
The jar file also includes the final version of the board developer API.
Only 222MH/s right now, but it's a start, and this way I can start to get feedback and independent confirmation. Don't expect 222MH/s unless you have a really good cooling setup. No commissions for at least the next week.
There will be another small speed bump in the morning or early afternoon tomorrow when the next build finishes; once that's out I'll make a more formal announcement. No press releases this time, though… I've depleted all $89 of my press budget.
The jar file also includes the final version of the board developer API.
June 21, 2012, 12:02:27 AM
eldentyrell, are you (or is anybody) working on a tricone mining bitstream for enterpoint/cairnsmore1 boards?
It looks like it's next to impossible to get an answer to this question, because this question got asked numerous times already...
If there is a reason you don't want to answer this question, can you at least say that?
1) no comment on enterpoint hardware
2) support is planned
3) no support is planned
...which one is is?
It looks like it's next to impossible to get an answer to this question, because this question got asked numerous times already...
If there is a reason you don't want to answer this question, can you at least say that?
1) no comment on enterpoint hardware
2) support is planned
3) no support is planned
...which one is is?
I imagine he plans on supporting the enterpoint boards as it increases his revenue, I'm sure hes just busy with the ztex boards atm. I understand there is a board dev kit on the tricone site that needs to be submitted to him with the pinouts and such.
June 20, 2012, 06:09:01 AM
eldentyrell, are you (or is anybody) working on a tricone mining bitstream for enterpoint/cairnsmore1 boards?
It looks like it's next to impossible to get an answer to this question, because this question got asked numerous times already...
If there is a reason you don't want to answer this question, can you at least say that?
1) no comment on enterpoint hardware
2) support is planned
3) no support is planned
...which one is is?
It looks like it's next to impossible to get an answer to this question, because this question got asked numerous times already...
If there is a reason you don't want to answer this question, can you at least say that?
1) no comment on enterpoint hardware
2) support is planned
3) no support is planned
...which one is is?
June 20, 2012, 04:18:51 AM
Bad news: no bitstreams just yet. This is a first-impression situation, so I figure it's counterproductive to post anything until it provides a meaningful improvement over what people have already got. I've set a fairly arbitrary threshold of 225MH/s/chip on the ztex board for that.
Good news: I have at least three different bitstreams that get above 200MH/s/chip on the ztex boards, so we're getting close here.
Better news: I think I found a crude, clumsy workaround for the middle-ring problem. I have one bitstream -- the very latest one -- running at 144mhz on all three rings (=216MH/s/chip) with no errors (yet -- still need to let it run overnight) on the ztex board, so we're almost there.
Good news: I have at least three different bitstreams that get above 200MH/s/chip on the ztex boards, so we're getting close here.
Better news: I think I found a crude, clumsy workaround for the middle-ring problem. I have one bitstream -- the very latest one -- running at 144mhz on all three rings (=216MH/s/chip) with no errors (yet -- still need to let it run overnight) on the ztex board, so we're almost there.
June 20, 2012, 03:31:32 AM
And that's why Spartans6 are called low power devices.
Actually they're called low power devices because somebody in the marketing department decided to call them that.
have you tried to run the 3 cores together but with a 120 degree clock phase separation?
June 20, 2012, 03:22:42 AM
And that's why Spartans6 are called low power devices.
Actually they're called low power devices because somebody in the marketing department decided to call them that.
June 20, 2012, 02:49:58 AM
According to the Xilinx docs SSO's *does* influence internal logic / other components (especially the MCB).
Er, I agree that this is true, but I haven't been able to find anywhere that Xilinx actually admits this for all-fabric (no I/O) designs. Have you found any place where Xilinx admits that excessive switching of fabric (not outputs) can cause fabric (not output) errors?
That's the frustrating part. Clearly the device is not operating the way XPA predicts, and the the XPA results are effectively part of the datasheet. Or maybe I'm just spoiled by StarRC.
June 19, 2012, 03:32:07 AM
And that's why Spartans6 are called low power devices. They just can't handle to much power, not becuse they consumes little amounts...
Jump to: