[ANN] Bitfury is looking for alpha-testers of first chips! FREE MONEY HERE!

[goodney]

That was my plan with the CPLD - 1.8v I/O within each board, 3.3v between them and the controller board.

Unfortunately I didn't think through the implications of powering the rpi independently of the 3.3v to the board during bring up - I wanted to be able to measure the board's 3.3v draw. Unfortunately if you power the rpi up before the board, you send 3.3v into an unpowered I/O pin on the CPLD and the chip goes into latchup

I would have liked to have c-scape in my design review to say 'you don't want to do it like that!' 

That seems like a short coming or bug in the CPLD. A CPLD with 3.3V tolerant I/O shouldn't care what the state of the pins are when it powers up... which CPLD did you use?

[KNK]

As promised:

It is not possible to get a good focus with a mobile, but this is the level shifter, not a death bug on my desk

[gingernuts]

That was my plan with the CPLD - 1.8v I/O within each board, 3.3v between them and the controller board.

Unfortunately I didn't think through the implications of powering the rpi independently of the 3.3v to the board during bring up - I wanted to be able to measure the board's 3.3v draw. Unfortunately if you power the rpi up before the board, you send 3.3v into an unpowered I/O pin on the CPLD and the chip goes into latchup

I would have liked to have c-scape in my design review to say 'you don't want to do it like that!' 

That seems like a short coming or bug in the CPLD. A CPLD with 3.3V tolerant I/O shouldn't care what the state of the pins are when it powers up... which CPLD did you use?

Yeah, I'm a bit surprised they're so easy to damage...

I'm using a Xilinx xc2c64 - once I've swapped this dead one out, I'll make sure I take the 3.3v feed from the rpi.

[gingernuts]

As promised:

It is not possible to get a good focus with a mobile, but this is the level shifter, not a death bug on my desk

Loving the use of strip-board - you must be a glutton for punishment! 

[vs3]

That was my plan with the CPLD - 1.8v I/O within each board, 3.3v between them and the controller board.

Unfortunately I didn't think through the implications of powering the rpi independently of the 3.3v to the board during bring up - I wanted to be able to measure the board's 3.3v draw. Unfortunately if you power the rpi up before the board, you send 3.3v into an unpowered I/O pin on the CPLD and the chip goes into latchup

I would have liked to have c-scape in my design review to say 'you don't want to do it like that!' 

That seems like a short coming or bug in the CPLD. A CPLD with 3.3V tolerant I/O shouldn't care what the state of the pins are when it powers up... which CPLD did you use?

which is why I picked to go with the KISS Principle - a few resistors, one transistor and that's all - very very few things to go wrong

[KNK]

Loving the use of strip-board - you must be a glutton for punishment! 

It takes 2 weeks to wait a for a board ... just to find out you've messed something
I've made a small board for just the chip with caps - the rest is easy to be put even on a strip-bard and this way i could also swap the chips at will and test the differences between them.
Now I am (almost) sure the prototype will work as expected

[cscape]

It takes 2 weeks to wait a for a board ... just to find out you've messed something

That's why I ordered my board in June.

[gingernuts]

That was my plan with the CPLD - 1.8v I/O within each board, 3.3v between them and the controller board.

Unfortunately I didn't think through the implications of powering the rpi independently of the 3.3v to the board during bring up - I wanted to be able to measure the board's 3.3v draw. Unfortunately if you power the rpi up before the board, you send 3.3v into an unpowered I/O pin on the CPLD and the chip goes into latchup

I would have liked to have c-scape in my design review to say 'you don't want to do it like that!' 

That seems like a short coming or bug in the CPLD. A CPLD with 3.3V tolerant I/O shouldn't care what the state of the pins are when it powers up... which CPLD did you use?

which is why I picked to go with the KISS Principle - a few resistors, one transistor and that's all - very very few things to go wrong

Well, I was going for the more-integration => less to go wrong side of the KISS principle, seems your version was more successful this time round!

[gingernuts]

Loving the use of strip-board - you must be a glutton for punishment! 

It takes 2 weeks to wait a for a board ... just to find out you've messed something
I've made a small board for just the chip with caps - the rest is easy to be put even on a strip-bard and this way i could also swap the chips at will and test the differences between them.
Now I am (almost) sure the prototype will work as expected

Does your small board even have solder-resist? I'm very impressed if you managed to put the QFN's down without it!

[KNK]

Does your small board even have solder-resist? I'm very impressed if you managed to put the QFN's down without it!

I don't have so steady hands (can be seen from the LS soldering), so a friend have helped with the chips actually.
No, it doesn't have solder mask, but most of the pins are power and they are shorted anyway, so starting from there to hold the chip in place is the way he did it.

[gingernuts]

Well, I think I may have broken a record by killing two rpi's in two days!

I switched to having the rpi power the 3.3v logic on my board, and fried the pi's 3.3v regulator 

On the upside, I did get it hashing for a while before I shorted killed the rpi - and I can probably replace the regulator and reanimate it...

So, which is the best S/W to use with Bitfury chips - chainminer or the cgminer fork?

Cheers.

[goodney]

So, which is the best S/W to use with Bitfury chips - chainminer or the cgminer fork?

Cheers.

Two things. One, you're not allowed in my lab ;-p Two: I get better results with the cgminer fork.

Good luck! And be nice to your RPi's. On the other hand, I think they just announced that 2M RPi's have been sold, so they're not exactly scarce.

-a[g

[cxboyminer]

I am very interested in being a beta tester for this chip. i can speak chinese (very well, from Hong Kong) and hopefully this will help.

[bee7]

I am very interested in being a beta tester for this chip. i can speak chinese (very well, from Hong Kong) and hopefully this will help.

The beta testing is over long time ago.

[cxboyminer]

oh... that's disappointing...

[goodney]

Here is another shot of my dev board. Cool thing to note here is that the SPI is being handled by a FTDI MPSSE based USB chip. No microcontoller required! It is kind of messy, but the KNK cgminer fork only required changes to a couple of source files.

Everything seems to work, however I have a couple of questions I hope the other developers on here can answer:

What drives the total hash rate of the BitFury chip? When connected to the RPi the board averages 2.0GH/s long term, which when it is connected to my Mac it averages around 1.6-1.7 GH/s.

The short stats message also differs between the RPi and my Mac version. On the RPi it reports ~180MHz with a target hash rate of 2.1GH/s or so. On the Mac it reports around 140MHz with 1.75 GH/s. I looked at the code that calculates these values, but it hurts my head to look at. Can someone give me a summary? I've also played around with the clock bits, but this doesn't seem to do much.

There also seems to be some timing based voodoo for talking to the chip that is based on sleeping for 100ms between SPI transfers. Can someone explain how this plays into the hash rate and the number of shares found?

Thanks!

-a[g

[KNK]

I looked at the code that calculates these values, but it hurts my head to look at. Can someone give me a summary?

It's backward calculated hashrate ... because we don't have the actual number for it nor for the frequency they are calculated from the time it takes to scan a full range of nonces, but of course it also depend on the delay it takes to measure it and that's why it shows different values on Win and Mac - scheduler delays and sleep times accuracy.

There also seems to be some timing based voodoo for talking to the chip that is based on sleeping for 100ms between SPI transfers. Can someone explain how this plays into the hash rate and the number of shares found?

It affects the calculated stats values precision but not the actual hashrate (IMHO) - it takes over a second to scan a range of nonces and 100ms sleep does not affect it in any way, just gives  some time for the CPU to prepare more work and process results before the next scan. If you increase it too much, you may miss a share (if more than 15 are found after the previous check) and if reduced too much will increase the CPU load and even bring the hashrate down, because of the absence of 'fresh work' in time.

[goodney]

I looked at the code that calculates these values, but it hurts my head to look at. Can someone give me a summary?

It's backward calculated hashrate ... because we don't have the actual number for it nor for the frequency they are calculated from the time it takes to scan a full range of nonces, but of course it also depend on the delay it takes to measure it and that's why it shows different values on Win and Mac - scheduler delays and sleep times accuracy.

There also seems to be some timing based voodoo for talking to the chip that is based on sleeping for 100ms between SPI transfers. Can someone explain how this plays into the hash rate and the number of shares found?

It affects the calculated stats values precision but not the actual hashrate (IMHO) - it takes over a second to scan a range of nonces and 100ms sleep does not affect it in any way, just gives  some time for the CPU to prepare more work and process results before the next scan. If you increase it too much, you may miss a share (if more than 15 are found after the previous check) and if reduced too much will increase the CPU load and even bring the hashrate down, because of the absence of 'fresh work' in time.

Thanks KNK! Just the information I need. Given this information I think I need to verify that my OSX-ified process-time and wall-clock time routines are returning good numbers (because of course OS X doesn't have clock_gettime()).

-a[g

[gingernuts]

So, which is the best S/W to use with Bitfury chips - chainminer or the cgminer fork?

Cheers.

Two things. One, you're not allowed in my lab ;-p Two: I get better results with the cgminer fork.

Good luck! And be nice to your RPi's. On the other hand, I think they just announced that 2M RPi's have been sold, so they're not exactly scarce.

-a[g

  That's fair enough - but I am getting pretty good at surface-mount rework now!

I'll give the cgminer fork a go. It doesn't seem the most reliable at detecting my small string of chips though, perhaps I need to play with the SPI code as I only have a few chips hooked up.

[goodney]

I'll give the cgminer fork a go. It doesn't seem the most reliable at detecting my small string of chips though, perhaps I need to play with the SPI code as I only have a few chips hooked up.

Do you have INCLK grounded? I didn't at first but once I did it made a huge difference.

-a[g