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

[eldentyrell]

Inspector 2211 already mentioned it and it is also hidden in the datasheet ("Simultaneous switching" issue):

Err, isn't "Simultaneous switching" issue about I/O pins?  not internal core logic.

Yes, it is -- at least in the Xilinx datasheets (SSO = Simultaneous Switching Outputs).

Could you clarify your comment, ztex?  Also, do you have a link to Inspector2211's comment?

The internal GND traces of the S6 seem to be a little bit weak.

I suspect so as well (or that the VCCINT traces are weak).  However, any details from Xilinx on this would be useful -- at least an acknowledgement that XPA isn't fully aware of the device's limitations.

[1714464653]

1714464653

[1714464653]

1714464653

[1714464653]

1714464653

[1714464653]

1714464653

[ztex]

Inspector 2211 already mentioned it and it is also hidden in the datasheet ("Simultaneous switching" issue):

Err, isn't "Simultaneous switching" issue about I/O pins?  not internal core logic.

Yes, it is -- at least in the Xilinx datasheets (SSO = Simultaneous Switching Outputs).

Could you clarify your comment, ztex?  Also, do you have a link to Inspector2211's comment?

The internal GND traces of the S6 seem to be a little bit weak.

I suspect so as well (or that the VCCINT traces are weak).  However, any details from Xilinx on this would be useful -- at least an acknowledgement that XPA isn't fully aware of the device's limitations.

According to the Xilinx docs SSO's *does*  influence internal logic / other components (especially the MCB).  Did you ever asked why?

One possible explanation would be a too large internal GND resistance. If there are large currents (e.g. from I/O's) voltage at internal GND rises to much and voltage between VCCINT and GND falls to much ...

[Dexter770221]

And that's why Spartans6 are called low power devices. They just can't handle to much power, not becuse they consumes little amounts...

[eldentyrell]

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.

[eldentyrell]

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.

[ngzhang]

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?

[eldentyrell]

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.

[ShadesOfMarble]

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?

[Keninishna]

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?

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.

[eldentyrell]

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.

[Inspector 2211]

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.

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.

[Chefnet]

is it only for the 1.15x or also for the y?

[eldentyrell]

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.

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.

[eldentyrell]

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.

[eldentyrell]

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

[ztex]

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

[eldentyrell]

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.

[roomservice]

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.

[eldentyrell]

http://pastebin.com/61iDAAHS

… 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.

[roomservice]

http://pastebin.com/61iDAAHS

… 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.