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

[intron]

Power circuit built and tested using load resistors.   12V ATX to 0.84V +- 5mV @90A with 92% efficiency.  Going to run it for a bit collecting data while powered by an AX1200i then will rerun it at 0.835V.  Here's part of the DSO output plotted.

Nice! What DC/DC converter chip are you using?
Or is is it fully handcrafted?

intron

[1715394467]

1715394467

[1715394467]

1715394467

[ultrix]

Power circuit built and tested using load resistors.   12V ATX to 0.84V +- 5mV @90A with 92% efficiency.  Going to run it for a bit collecting data while powered by an AX1200i then will rerun it at 0.835V.  Here's part of the DSO output plotted.

Nice! What DC/DC converter chip are you using?
Or is is it fully handcrafted?

intron

LTC3829 controller, everything else is custom design.  Uses Infineon FETs and I'm testing two different coils.

[PWRMAD]

Thanks VS3, this is a simple interface but my real question is what will it take to get CG, BFG or any other miner talking to the ASICs? In this configuration there can only be 1 "H" card (16 chips) so the processing power is not really a factor but since I DO NOT do the software thing I need one of you programming gods to chime in so I can get an alpha PCB on order. If I am wasting my time just let me know.

Thanks
Randy

[vs3]

Thanks VS3, this is a simple interface but my real question is what will it take to get CG, BFG or any other miner talking to the ASICs? In this configuration there can only be 1 "H" card (16 chips) so the processing power is not really a factor but since I DO NOT do the software thing I need one of you programming gods to chime in so I can get an alpha PCB on order. If I am wasting my time just let me know.

Thanks
Randy

Randy - I'm currently messing with the PCB design and as soon as I send it for production (hopefully before Friday) I'll move onto cgminer. I know exactly what needs to change but I haven't used that set of compiler(s) and building environment, so it may take me a bit to figure out the details. I suspect I may ask ckolivas (that's cgminer's author who's also keeping an eye on this thread) or any of the other gurus for help if I get totally stuck.

edit: I'm basically going to expand legkodymov's fork so that it runs on Windows.

edit2: here is an example of a windows fork of cgminer - it's just the 3 bitfury-related files: (as translated by google)

And most importantly - it works without RasPi
bitfury-serialport.zip

[-ck]

Yes it's the bitbanging reset that I have no way to emulate so far. I can easily talk SPI to the chip via libusb and have done so, but cannot get the chip reset and talking. I pinged bitfury about this but got no response. If you have any ideas, I'm all ears and eyes. If I can get it working via libusb, it will work everywhere.

[ultrix]

Yes it's the bitbanging reset that I have no way to emulate so far. I can easily talk SPI to the chip via libusb and have done so, but cannot get the chip reset and talking. I pinged bitfury about this but got no response. If you have any ideas, I'm all ears and eyes. If I can get it working via libusb, it will work everywhere.

Possibly an endianess issue?   Have you hooked up a logic analyzer to it?

[-ck]

Yes it's the bitbanging reset that I have no way to emulate so far. I can easily talk SPI to the chip via libusb and have done so, but cannot get the chip reset and talking. I pinged bitfury about this but got no response. If you have any ideas, I'm all ears and eyes. If I can get it working via libusb, it will work everywhere.

Possibly an endianess issue?   Have you hooked up a logic analyzer to it?

Nono, I can't even send a reset to it... the sample code speaks to the MOSI and SCK by setting and unsetting GPIO pins that don't even exist on the USB-SPI chip included...

[kaerf]

We're using an MCP2210 for USB-SPI communication. Indeed the reset sequence was tricky and we're using a MUX plus two GPIOs from the mcp2210. The available open source code (linux) for the mcp2210 needs re-writing as well...quite the pain in the ass.

[cscape]

Instead of using a dedicated USB-SPI chip, it would be a lot easier to use a small USB microcontroller. Price and area would be the same, and all the hardware specific details of the bitfury design would be in the firmware, rather than on the PC.

That's what we're doing for our 2-chip bi*fury USB design, but it would be easy to replace the 2 ASICs with a H-CARD socket.

[-ck]

We're using an MCP2210 for USB-SPI communication. Indeed the reset sequence was tricky and we're using a MUX plus two GPIOs from the mcp2210. The available open source code (linux) for the mcp2210 needs re-writing as well...quite the pain in the ass.

Want to describe the sequence for me in detail please?

[vs3]

Option 1:
To be honest my initial idea was to use a RS232 serial port directly - TxD would be MOSI, RxD would be MISO (or any of the other inputs like RI, RTS, etc) and DTR would be SCK and I was going to manually drive them high/low. It works sufficiently fast (>200kHz) with built-in COM ports. Unfortunately it is horribly slow when using a USB-to-Serial chip such as FT232R (about 1kHz). It is still doable but somewhat pointless as there is a better option - see option 3.

Option 2:
The next option I looked at was MCP2210. But you can't switch the SPI pins into GPIO. I can tweak the SCK pin (by switching the phase) but I can't do anything about the MOSI one. The only (cheap) solution was going to be to sort of short-circuit it with another GPIO pin via a small resistor like this:
(MOSI) ---[200]--- (GPIO) ---[2k2]--- (BitFury INMOSI) ---[2k2]--- GND
I would put the GPIO as an input normally so that it doesn't interfere, and during RESET I would make it an output and use it to override the MOSI pin. It's ugly though. And the MCP2210 chip is waaaay overly complicated.

Option 3:
My next option was actually reusing the FT232R. In async bitbang mode it uses its 8-bit DBus and does a write followed by a read. I can just deserialize all pins - e.g. if I need to send-and-read one bit (let's say "1") and bit 0 is MOSI, bit 1 is SCK (both outputs) and bit 2 is MISO (input) I would write to the chip:
1) 0000-0?01 - set MOSI
2) 0000-0?11 - set SCK
3) 0000-0?11 - dummy - just to even out SCK 0s and 1s (and possibly optimize the code down the road by skipping 4 bytes)
4) 0000-0?01 - clr SCK
Since it does a read after each write I would read the result after 4) and that would be my MISO read bit.
I liked the simplicity of that chip - barely a few components. On the downside it would be a lot of manual labor rolling out the SPI protocol. But on the good side you can set the clock speed at 3MHz, so you effectively get 750kbps SPI. (at roughly 75 bytes per transaction that's 1000 chip-requests per second).
I tested that with a FT232R board that I had handy and confirmed that this will work.

Option 4:
And then I found the CY7C65211 chip. Oh joy of joys!
You can switch each of the SPI pins to GPIO if you want (so here is the RESET sequence). My plan is for the RESET sequence to manually drive each of the GPIO pins, and once done to switch them back to SPI mode.

[vs3]

Instead of using a dedicated USB-SPI chip, it would be a lot easier to use a small USB microcontroller. Price and area would be the same, and all the hardware specific details of the bitfury design would be in the firmware, rather than on the PC.

That's what we're doing for our 2-chip bi*fury USB design, but it would be easy to replace the 2 ASICs with a H-CARD socket.

I agree. I think at the end this will be the best solution. You can get a very cheap PIC with USB support for about $1-1.5 and it can take care of the heavy lifting and drive multiple (bitfury) chips. But - that would require more development for the PIC coding.
As an interim solution - the FT232R chip is about $2-2.5 and the CY7C65211 is $3-4 which I think is bearable for a start.

[cscape]

We're using LPC11U. I'm just finishing the firmware for it. PC interface is a simple virtual com port over bulk endpoint. The PC software just sends 'work <job id> <work>' to send work to the chip(s), and the firmware sends back 'submit <job id> <timestamp> <nonce>' whenever it finds something.

[-ck]

Option 2:
The next option I looked at was MCP2210. But you can't switch the SPI pins into GPIO. I can tweak the SCK pin (by switching the phase) but I can't do anything about the MOSI one. The only (cheap) solution was going to be to sort of short-circuit it with another GPIO pin via a small resistor like this:
(MOSI) ---[200]--- (GPIO) ---[2k2]--- (BitFury INMOSI) ---[2k2]--- GND
I would put the GPIO as an input normally so that it doesn't interfere, and during RESET I would make it an output and use it to override the MOSI pin. It's ugly though. And the MCP2210 chip is waaaay overly complicated.

The btc101 usb device has an MCP2210 chip. I keep poking it like a little kid with stick does to a dead animal, and that's how it behaves in response...

The mcp2210 chip shows up as an HID device under linux, and you're not really meant to use the SPI on it directly, yet the cgminer forked code opens it using the spidev interface on linux by mmap directly into /dev/mem and using some magic constants for memory offsets that correspond with the RPi ... that approach is about as portable as a brick shithouse.

[kaerf]

We're using an MCP2210 for USB-SPI communication. Indeed the reset sequence was tricky and we're using a MUX plus two GPIOs from the mcp2210. The available open source code (linux) for the mcp2210 needs re-writing as well...quite the pain in the ass.

Want to describe the sequence for me in detail please?

Well, my method only works for us because we have a hardware MUX. The mcp2210 doesn't allow us to directly control SCK, so need to switch to a GPIO during the reset sequence.

The reset sequence is as follows:
---
Switch SCK to high (no oscillations)
Toggle MOSI 16 times. (at 1 MHz)
Switch SCK to low
---
That's how bitfury's reference code works on the RPI. However, you do have greater freedom if you need. Here's a response I got from Tytus about the reset sequence:

- any sequence
- at least 3 MOSI toggles (better more) on CLK high
- speed < 20MHz

In order for us to set SCK to high during the reset, we toggle the MUX select line and switch from the mcp2210's SCK pin to a GPIO pin so INCLK on the bitfury chip sees a constant high level. Then we toggle MOSI (send 16 bytes of 0xff or 4 bytes of 0xAA or 0x55 as long it toggles MOSI). Then we set our GPIO pin to low and change the MUX select line back, so INCLK on gets SCK from the mcp2210.

Unless you have the MUX, I don't think this will work for you, but maybe it can give you some insight into how that sequence works.

[cscape]

- any sequence
- at least 3 MOSI toggles (better more) on CLK high
- speed < 20MHz

Note that you need 3 MOSI toggles for each chip in the chain.

[kaerf]

Instead of using a dedicated USB-SPI chip, it would be a lot easier to use a small USB microcontroller. Price and area would be the same, and all the hardware specific details of the bitfury design would be in the firmware, rather than on the PC.

That's what we're doing for our 2-chip bi*fury USB design, but it would be easy to replace the 2 ASICs with a H-CARD socket.

I agree. I think at the end this will be the best solution. You can get a very cheap PIC with USB support for about $1-1.5 and it can take care of the heavy lifting and drive multiple (bitfury) chips. But - that would require more development for the PIC coding.
As an interim solution - the FT232R chip is about $2-2.5 and the CY7C65211 is $3-4 which I think is bearable for a start.

This was our initial thought as well, but the mcp2210 has such poor documentation and incomplete API that I've wasted far more time trying to get the mcp2210 to work than a normal microcontroller. On the plus site, the USB to SPI connection can provide the mining software for more control/flexibility since it can directly send commands to chips/SPI bus. Also, you don't need to flash firmware updates...

[vs3]

In order for us to set SCK to high during the reset, we toggle the MUX select line and switch from the mcp2210's SCK pin to a GPIO pin so INCLK on the bitfury chip sees a constant high level.

Ha! I was so focused on driving the MOSI pin that I overlooked the idea of messing up with the SCK pin .. and that's even better!
By the way - the trick with the resistors would work just fine. (I've done it countless times on PICs - just pick the resistors so that current doesn't go over 2-3mA). And it's much cheaper than the MUX option

[-ck]

We're using an MCP2210 for USB-SPI communication. Indeed the reset sequence was tricky and we're using a MUX plus two GPIOs from the mcp2210. The available open source code (linux) for the mcp2210 needs re-writing as well...quite the pain in the ass.

Want to describe the sequence for me in detail please?

Well, my method only works for us because we have a hardware MUX. The mcp2210 doesn't allow us to directly control SCK, so need to switch to a GPIO during the reset sequence.

The reset sequence is as follows:
---
Switch SCK to high (no oscillations)
Toggle MOSI 16 times. (at 1 MHz)
Switch SCK to low
---
That's how bitfury's reference code works on the RPI. However, you do have greater freedom if you need. Here's a response I got from Tytus about the reset sequence:

- any sequence
- at least 3 MOSI toggles (better more) on CLK high
- speed < 20MHz

In order for us to set SCK to high during the reset, we toggle the MUX select line and switch from the mcp2210's SCK pin to a GPIO pin so INCLK on the bitfury chip sees a constant high level. Then we toggle MOSI (send 16 bytes of 0xff or 4 bytes of 0xAA or 0x55 as long it toggles MOSI). Then we set our GPIO pin to low and change the MUX select line back, so INCLK on gets SCK from the mcp2210.

Unless you have the MUX, I don't think this will work for you, but maybe it can give you some insight into how that sequence works.

Thanks very much for at least that information. I'm still not even sure if it's going to be possible then, but I'll keep poking.

[vs3]

Instead of using a dedicated USB-SPI chip, it would be a lot easier to use a small USB microcontroller. Price and area would be the same, and all the hardware specific details of the bitfury design would be in the firmware, rather than on the PC.

That's what we're doing for our 2-chip bi*fury USB design, but it would be easy to replace the 2 ASICs with a H-CARD socket.

I agree. I think at the end this will be the best solution. You can get a very cheap PIC with USB support for about $1-1.5 and it can take care of the heavy lifting and drive multiple (bitfury) chips. But - that would require more development for the PIC coding.
As an interim solution - the FT232R chip is about $2-2.5 and the CY7C65211 is $3-4 which I think is bearable for a start.

This was our initial thought as well, but the mcp2210 has such poor documentation and incomplete API that I've wasted far more time trying to get the mcp2210 to work than a normal microcontroller. On the plus site, the USB to SPI connection can provide the mining software for more control/flexibility since it can directly send commands to chips/SPI bus. Also, you don't need to flash firmware updates...

Ohhhh... tell me about it! I hated that documentation when I read it the first time. And then I saw the chip on your boards and went back and reread it ... and hated it even more... I think you pretty much qualify for a hero for figuring it out!