Cairnsmore1 - Quad XC6SLX150 Board

[ShadesOfMarble]

makomk's overclocked 200 mhz bitstream is running without any problems on my SN 26 board for two days now. U is 5.47+5.43.

Either the pre-50 boards are not that bad at all or I'm just really lucky!?

[1713571470]

1713571470

[1713571470]

1713571470

[1713571470]

1713571470

[Keninishna]

I can't get the controller 1.4 working with the up/down cables, good thing I bought a jtag cable too I knew it might come in handy someday.

[dirtycat]

are these things using all 4 chips to hash yet?

EDIT: oops just saw glasswalkers post.

[steamboat]

are these things using all 4 chips to hash yet?

EDIT: oops just saw glasswalkers post.

they have been for 2 weeks? now. makmoks been delivering a steady stream of bit...er, um, streams

[Lethos]

Ok, I have an official release here
https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner/downloads
(you want the Aug 16th release)

That's the first officially "useful" release of the HashVoodoo bitstream for the CM1 boards.

Thanks Glasswalker, will give these a go, since I do crave stability in my bitstream, No offense meant to Makomk's bitstream, my boards just are not cooperating. So for at least a while I will try the hashvoodoo and provide any feedback on them.

So these use it's own bitstream and controller and flashed the same way, via usb? Okay.

[makomk]

Hmmm. So it looks like the onboard flash on the controller FPGA is effectively Atmel DataFlash, namely an AT45DB011D. Annoyingly flashrom doesn't support programming Atmel DataFlash because if it did it might provide a way to reflash the controller from Linux. (It can detect the flash chip OK with a small patch to its FT2232 driver, just not actually do anything with it.)

[Lethos]

I'm trying Glasswalker, following your instructions, repeating the steps best I can, but I've got a fair few verified failed when trying to flash with a whole bunch of garbage outputted telling me it failed. 

[Lethos]

I'm trying Glasswalker, following your instructions, repeating the steps best I can, but I've got a fair few verified failed when trying to flash with a whole bunch of garbage outputted telling me it failed.  

Finally got 1 of the chips to flash (p3). This is progress, I don't think I did anything different, persistence prevails this time.
Tried chip p2 next, got the same error that I often get:

Verify failed at flash_page 2911
Read: fffffffffffffffffffffffffffffffffffffffffffffffffffff * alot more of these
File: *lots of random numbers* I'll post a screen shot if it really helps
Verify: Failure

I didn't change anything other than selecting p2 instead of p3, Ah the quest continues.

[makomk]

Finally got 1 of the chips to flash (p3). This is progress, I don't think I did anything different, persistence prevails this time.
Tried chip p2 next, got the same error that I often get:

Verify failed at flash_page 2911
Read: fffffffffffffffffffffffffffffffffffffffffffffffffffff * alot more of these
File: *lots of random numbers* I'll post a screen shot if it really helps
Verify: Failure

I didn't change anything other than selecting p2 instead of p3, Ah the quest continues.

Hmmmm. Try setting the SWITCH3 to Off as per Glasswalker's instructions, then toggling SWITCH1 to Off and back to On again (which power cycles the array FPGAs), wait for the LEDs next to each FPGA to light up, and then try flashing the array FPGAs again? This may be particularly necessary if you've got one of my faster bitstreams flashed to the board.

[Lethos]

Finally got 1 of the chips to flash (p3). This is progress, I don't think I did anything different, persistence prevails this time.
Tried chip p2 next, got the same error that I often get:

Verify failed at flash_page 2911
Read: fffffffffffffffffffffffffffffffffffffffffffffffffffff * alot more of these
File: *lots of random numbers* I'll post a screen shot if it really helps
Verify: Failure

I didn't change anything other than selecting p2 instead of p3, Ah the quest continues.

Hmmmm. Try setting the SWITCH3 to Off as per Glasswalker's instructions, then toggling SWITCH1 to Off and back to On again (which power cycles the array FPGAs), wait for the LEDs next to each FPGA to light up, and then try flashing the array FPGAs again? This may be particularly necessary if you've got one of my faster bitstreams flashed to the board.

Thanks Makomk, I've just done a verbose of the process, since it was pretty repeatable.

sudo ./xc3sprog -c cm1 -v -p 2 -Ix150.bit hv175oc.bit

It does manage to flash all 17 sectors, but when it verifies it finds their is a difference between what is on the file and on the chip I presume that is what it's telling me.

I did have one of your 210 bitstreams on their before, I don't have a jtag cable, so I'm a little concerned to do anything that is not suggested here.
I'll give your suggestion a go. Will let you know it a bit.

[Lethos]

We have progress, I've had no luck perma-flashing them. But temp-flashing does works now (I did try that first, apparently gave up too quickly).

It lasted all of 7 minutes mining, before the entire board disabled.

[Lethos]

We have progress, I've had no luck perma-flashing them. But temp-flashing does works now (I did try that first, apparently gave up too quickly).

It lasted all of 7 minutes mining, before the entire board disabled.

Tried again and it's more solid with the temp-flashing this time it appears, Pretty solid 9u for the entire board.
I can't get perma-flashing working so if anyone feels like helping me out and point what I'm doing wrong (if at all) then I'd welcome it.

[roomservice]

I'm trying Glasswalker, following your instructions, repeating the steps best I can, but I've got a fair few verified failed when trying to flash with a whole bunch of garbage outputted telling me it failed.  

Finally got 1 of the chips to flash (p3). This is progress, I don't think I did anything different, persistence prevails this time.
Tried chip p2 next, got the same error that I often get:

Verify failed at flash_page 2911
Read: fffffffffffffffffffffffffffffffffffffffffffffffffffff * alot more of these
File: *lots of random numbers* I'll post a screen shot if it really helps
Verify: Failure

I didn't change anything other than selecting p2 instead of p3, Ah the quest continues.

Got excactly the same issue, so you are not alone (Board SN 21 here).

EDIT: Confirm the bitstream works perfectly on all 4 fpga of this early board in temp mode now! Glasswalker did an awesome job.

[yohan]

I can't get the controller 1.4 working with the up/down cables, good thing I bought a jtag cable too I knew it might come in handy someday.

I will try and get some pictures for which way to connect as that might be part of the problem. You also have to use SWITCH4 set to master on the board with USB and slave for the second board. Otherwise it don't work.

We think Rev 1.5 is ok and programmer is fixed but we will do a little more testing with it before we release that formally.

We have progress, I've had no luck perma-flashing them. But temp-flashing does works now (I did try that first, apparently gave up too quickly).

It lasted all of 7 minutes mining, before the entire board disabled.

Tried again and it's more solid with the temp-flashing this time it appears, Pretty solid 9u for the entire board.
I can't get perma-flashing working so if anyone feels like helping me out and point what I'm doing wrong (if at all) then I'd welcome it.

Depending what Controller version you have the details may vary a little but for most versions SWITCH3 set to "off" during programming of the array FPGAs/SPI Flash is usually recommended. SWITCH8 at "on" (default) for using the internal programmer. Remember to put SWITCH3 back to "on" when finished programming. It's always best to power cycle the board before programming as sometimes FPGAs get hung up in strange states.

[Lethos]

I'm trying Glasswalker, following your instructions, repeating the steps best I can, but I've got a fair few verified failed when trying to flash with a whole bunch of garbage outputted telling me it failed.  

Finally got 1 of the chips to flash (p3). This is progress, I don't think I did anything different, persistence prevails this time.
Tried chip p2 next, got the same error that I often get:

Verify failed at flash_page 2911
Read: fffffffffffffffffffffffffffffffffffffffffffffffffffff * alot more of these
File: *lots of random numbers* I'll post a screen shot if it really helps
Verify: Failure

I didn't change anything other than selecting p2 instead of p3, Ah the quest continues.

Got excactly the same issue, so you are not alone (Board SN 21 here).

I did a temp flash instead, which did still work, with switch 3 and 6 off. It sometimes cooperates to flash with:

Code:

sudo ./xc3sprog -c cm1 -p0 hv175oc.bit

Do the above for p0, p1, p2 and p3 (think I remembered the above correctly)

[Lethos]

We have progress, I've had no luck perma-flashing them. But temp-flashing does works now (I did try that first, apparently gave up too quickly).

It lasted all of 7 minutes mining, before the entire board disabled.

Tried again and it's more solid with the temp-flashing this time it appears, Pretty solid 9u for the entire board.
I can't get perma-flashing working so if anyone feels like helping me out and point what I'm doing wrong (if at all) then I'd welcome it.

Depending what Controller version you have the details may vary a little but for most versions SWITCH3 set to "off" during programming of the array FPGAs/SPI Flash is usually recommended. SWITCH8 at "on" (default) for using the internal programmer. Remember to put SWITCH3 back to "on" when finished programming. It's always best to power cycle the board before programming as sometimes FPGAs get hung up in strange states.

I tried that Yohan, however only a quick temporary flash would go through and worked fine. The one I wanted to do and is usually suggested that properly flashes it, fails verification after the flash. I don't know if that is my fault, the hardware or the bitstream.

It works right now, with a quick temp flash, so I'm just testing it's stability, to see if it's worth doing the same to the other board.

[atsoat]

Ok, I have an official release here
https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner/downloads
(you want the Aug 16th release)

That's the first officially "useful" release of the HashVoodoo bitstream for the CM1 boards.

It includes instructions, dipswitch diagrams, it's own controller (required), and files for flashing both via USB and via jtag/impact.

This one runs at 175Mhz, and is overclocked a bit. It's been tested fairly heavily at this point and is stable on both the current boards, and the pre-50 boards.

....

Please report any issues to the issue tracker on github and/or on IRC in #cm1 on freenode.

Early days, but after flashing this to a pre-50 board that was giving lousy results with anything but the twintest bitstream, I am now seeing the best numbers I've seen for this board:

 ICA 0:                | 368.3/370.7Mh/s | A: 77 R:0 HW:0 U:  2.42/m
 ICA 1:                | 373.4/373.8Mh/s | A: 68 R:0 HW:0 U:  2.14/m
 ICA 2:                | 374.4/373.1Mh/s | A: 78 R:0 HW:0 U:  2.45/m
 ICA 3:                | 374.0/372.5Mh/s | A: 86 R:0 HW:0 U:  2.70/m

NB - this is one board - you add all USBs with this bitstream (and ignore the MH, just look at the U)

Obviously, this is only half an hour in. But looking good so far. Thanks.

[Lethos]

Ok, I have an official release here
https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner/downloads
(you want the Aug 16th release)

That's the first officially "useful" release of the HashVoodoo bitstream for the CM1 boards.

It includes instructions, dipswitch diagrams, it's own controller (required), and files for flashing both via USB and via jtag/impact.

This one runs at 175Mhz, and is overclocked a bit. It's been tested fairly heavily at this point and is stable on both the current boards, and the pre-50 boards.

....

Please report any issues to the issue tracker on github and/or on IRC in #cm1 on freenode.

Early days, but after flashing this to a pre-50 board that was giving lousy results with anything but the twintest bitstream, I am now seeing the best numbers I've seen for this board:

 ICA 0:                | 368.3/370.7Mh/s | A: 77 R:0 HW:0 U:  2.42/m
 ICA 1:                | 373.4/373.8Mh/s | A: 68 R:0 HW:0 U:  2.14/m
 ICA 2:                | 374.4/373.1Mh/s | A: 78 R:0 HW:0 U:  2.45/m
 ICA 3:                | 374.0/372.5Mh/s | A: 86 R:0 HW:0 U:  2.70/m

NB - this is one board - you add all USBs with this bitstream (and ignore the MH, just look at the U)

Obviously, this is only half an hour in. But looking good so far. Thanks.

What flashing method did you use, and if you can remember all your steps can you share it.
I would really love to have these flash properly if I could. With yours being a pre-50 board It's great to see it working well for you. I get similar results, right now on 2 boards.

[kano]

Ok, I have an official release here
https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner/downloads
(you want the Aug 16th release)

That's the first officially "useful" release of the HashVoodoo bitstream for the CM1 boards.

It includes instructions, dipswitch diagrams, it's own controller (required), and files for flashing both via USB and via jtag/impact.

This one runs at 175Mhz, and is overclocked a bit. It's been tested fairly heavily at this point and is stable on both the current boards, and the pre-50 boards.

....

Please report any issues to the issue tracker on github and/or on IRC in #cm1 on freenode.

Early days, but after flashing this to a pre-50 board that was giving lousy results with anything but the twintest bitstream, I am now seeing the best numbers I've seen for this board:

 ICA 0:                | 368.3/370.7Mh/s | A: 77 R:0 HW:0 U:  2.42/m
 ICA 1:                | 373.4/373.8Mh/s | A: 68 R:0 HW:0 U:  2.14/m
 ICA 2:                | 374.4/373.1Mh/s | A: 78 R:0 HW:0 U:  2.45/m
 ICA 3:                | 374.0/372.5Mh/s | A: 86 R:0 HW:0 U:  2.70/m

NB - this is one board - you add all USBs with this bitstream (and ignore the MH, just look at the U)

Obviously, this is only half an hour in. But looking good so far. Thanks.

--icarus-options :2:1

[Glasswalker]

--icarus-options :2:1

Oh awesome, will this convince cgminer to adjust the hashrate estimations for single-chip setup?

Also Kano, come see me on IRC (#cm1 on freenode) or PM me. We're working on an addon to the icarus protocol to the hashvoodoo bitstream as a temporary measure until we can do the full protocol overhaul. It is technically in place in the current bitstream but it's broke, so it is basically un-used (I'll be fixing it in the next couple days). This addon leaves it backwards compatible with icarus, but with 2 major differences:

1 - It can now support specially constructed icarus style packets which act as "control" packets, to send other commands to the FPGA (right now the implemented one is "Set Clock Multiplier" for a given chip, allowing dynamic clock tuning)

2 - It is potentially vulnerable to malicious work sources. (if a pool operator knows the "special" packet format, they could send work down so a miner using the conventional icarus protocol and unaware of our additions would simply pass that work along to the fpga. This would allow the pool to directly control the clock of your FPGAs... We do have min/max in place to keep from physical damage to the chips, but it could still serve as a DOS (set clock to minimum multiplier effectively killing mining output, or setting it to max, potentially overheating it over time).

So this will require miners to add in special support for the newer hashvoodoo bitstreams on CM1 (or any other board it gets ported to) which will catch any packets which meet our "command packet" protocol coming from the pool and drop them (they should never occur in real mining, so it would be obviously either severely corrupted, or malicious).

And hopefully add support to actually use the clock tuning from the mining software.

Anyway, come see me, and I can help give you the details on this so you can start working it into cgminer.

I'm likely at LEAST weeks, if not a month or more away from the "final" protocol change, which will be a completely new protocol, so in the meantime this is a nice stop-gap measure that provides added functionality with minimal work, and provides backwards compatibility. And buys enough time to really think through the new protocol and make sure we "do it right" from the beginning.

Thanks!

EDIT:
For a TLDR version of this for those of you using the current bitstream:
- You are not at any risk at all, the "enhanced" protocol doesn't work currently in the existing bitstreams
- Once I release one where the dynamic clocking DOES work, you will want to use mining software which supports the "enhanced" protocol for security reasons.
- Even without said software support, it will still mine on older "unsupported" software fine, and the only real risk is if your pool decides to act maliciously (which is unlikely for most).
- That said, you will want to use this feature once it's out anyway, as it will allow faster mining.

Thanks!