FPGA development board "Icarus" - DisContinued/ important announcement

[TheSeven]

If you change the serial protocol a bit, it might work with the SimpleRS232 interface that MPBM provides. This would also fix some other flaws that I've spotted in the interface you're currently using.
Alternatively the SimpleRS232 interface module could be adapted to fit the current bitstream, but I'd really go for the other way round.

Changing the FPGA firmware is much mode difficult and time-consuming than just modifying the mining software.

Sure, doing it from the software side is certainly easier, but fixing it on the FPGA side would also fix some other issues at the same time and allow for a generic interface:

• Possible desyncs if a byte gets lost on RS232
• Not knowing which work a nonce belongs to that's sent shortly after (or during) work upload
• Wasting mining time by needing a new job after finding a nonce for no good reason? (at least if I understood the protocol specification right)
• No generic way of figuring out the actual hash rate (why don't you split the work into even and odd nonces instead of low and high half?)

[1713531594]

1713531594

[1713531594]

1713531594

[1713531594]

1713531594

[1713531594]

1713531594

[xiangfu]

Hi all

I setup the miner.py under TP-Link wr1043nd home router. there is the steps:
  http://en.qi-hardware.com/wiki/Icarus#Using_TP-link.2Ftl-wr1043nd_as_host

it is using Openwrt. since the python package is too big for the flash. so I cut down a lot of the python stuff. only works fine with miner.py.
and for now it only support monitor only one worker.

if you also want try. please let me know if it doesn't work.

thanks
xiangfu

[ngzhang]

If you change the serial protocol a bit, it might work with the SimpleRS232 interface that MPBM provides. This would also fix some other flaws that I've spotted in the interface you're currently using.
Alternatively the SimpleRS232 interface module could be adapted to fit the current bitstream, but I'd really go for the other way round.

Changing the FPGA firmware is much mode difficult and time-consuming than just modifying the mining software.

Sure, doing it from the software side is certainly easier, but fixing it on the FPGA side would also fix some other issues at the same time and allow for a generic interface:

• Possible desyncs if a byte gets lost on RS232
• Not knowing which work a nonce belongs to that's sent shortly after (or during) work upload
• Wasting mining time by needing a new job after finding a nonce for no good reason? (at least if I understood the protocol specification right)
• No generic way of figuring out the actual hash rate (why don't you split the work into even and odd nonces instead of low and high half?)

hi. i review these issue, and :
1, if a byte lost during the communication, it will generate some wrong data, but at the next work push, it will return to normal. it uses only a simple 512bits shift register to receive work. 
2, it's a problem.  but not a frequent occurrences. it can be fix by a workID model, as the V1 firmware, but this function generates lots of BUGs... so i return to a simple protocol. 
3, this "behavior" is changed in a under-test firmware. the FPGA will continue working until nonce_to. 

check it here: https://github.com/ngzhang/Icarus/tree/master/Downloads/bitsteam/V4

4, at first, i set the time-out manually, so i just used this work split method, i think it's easier. 

regards.

BTW:

and a script with watch dog timer is pushed to github, check it here:
https://github.com/ngzhang/Icarus/tree/master/miner_software/queue_ver_with_auto_restart

[TheSeven]

hi. i review these issue, and :
1, if a byte lost during the communication, it will generate some wrong data, but at the next work push, it will return to normal. it uses only a simple 512bits shift register to receive work. 

How does it know when the next 512bit packet will start? By means of a timeout? I see no other way to determine packet boundaries once a desync has happened with the current protocol. It would wait for the missing byte, and then steal the first byte of the next packet, and so on.

2, it's a problem.  but not a frequent occurrences. it can be fix by a workID model, as the V1 firmware, but this function generates lots of BUGs... so i return to a simple protocol. 

No need for identifying work, the only thing you need is some feedback on when exactly work was accepted. You could for example add a leading byte to the nonce response that identifies the packet type (nonce found or work accepted, possibly some more in the future). Every nonce sent before the work accepted packet would belong to the old work, every nonce sent after that would belong to the new work.

3, this "behavior" is changed in a under-test firmware. the FPGA will continue working until nonce_to. 

Sounds good. Would be perfect if you also made sure that nonces won't get lost because of that by having a small nonce queue.
Having a work queue would also help in using the full keyspace (and thus reducing pool load), but that's not quite as important.

4, at first, i set the time-out manually, so i just used this work split method, i think it's easier. 

Well, it doesn't really matter if the fixed bit (per FPGA) is the first or last one right? Tying the LSB value to the FPGA ID is much better from a software point of view (it just behaves like one faster FPGA).

[pieppiep]

How does it know when the next 512bit packet will start? By means of a timeout? I see no other way to determine packet boundaries once a desync has happened with the current protocol. It would wait for the missing byte, and then steal the first byte of the next packet, and so on.

For easier example I change 512bit to 32bit

FPGA buffer starts at some value 0x??

New value is 0x12345678

Computer sends a byte 0x12
FPGA buffer is now 0x???12
Computer sends a byte 0x34
FPGA buffer is now 0x????1234
Computer sends a byte 0x56
FPGA buffer is now 0x??123456
Computer sends a byte 0x78
FPGA buffer is now 0x12345678

New value is 0x87654321

Computer sends a byte 0x87
FPGA buffer is now 0x34567887
Computer sends a byte 0x65 but FPGA doesn't receive
FPGA buffer is still 0x34567887
Computer sends a byte 0x43
FPGA buffer is now 0x56788743
Computer sends a byte 0x21
FPGA buffer is now 0x78874321

FPGA calculates with wrong value

New value is 0xCAFEBABE

Computer sends a byte 0xCA
FPGA buffer is now 0x874321CA
Computer sends a byte 0xFE but FPGA doesn't receive
FPGA buffer is still 0x4321CAFE
Computer sends a byte 0xBA
FPGA buffer is now 0x21CAFEBA
Computer sends a byte 0xBE
FPGA buffer is now 0xCAFEBABE

FPGA calculates with correct value

[TheSeven]

Ah so this is just a shift register without latches? So the FPGA works on corrupt data (instead of the old work) while work is being uploaded?
Is the nonce counter being reset whenever a byte is received, or how is that handled?

[pieppiep]

I do think so.
This is what I base my answer on,

1, if a byte lost during the communication, it will generate some wrong data, but at the next work push, it will return to normal. it uses only a simple 512bits shift register to receive work. 

So if the rs232 is at 115k2 you waste 512 / 115200 of a second, 4.444444ms which is at 200MH/s a total of 888,889 hashes each time you send new work.

[ngzhang]

Ah so this is just a shift register without latches? So the FPGA works on corrupt data (instead of the old work) while work is being uploaded?
Is the nonce counter being reset whenever a byte is received, or how is that handled?

haha, yes, i use the simplest way as described above. there are no byte counter or some other useless stuff. just a 64 bytes wide shift register.
and the nonce counter will reset when a byte is received, as a very barbarous way.  
it's really doesn't matter if the FPGA generates some wrong data, or not calculate all nonce range. the work push need only 5.6ms for 512bit data transform, so i think the loss is acceptable.

I do think so.
This is what I base my answer on,

1, if a byte lost during the communication, it will generate some wrong data, but at the next work push, it will return to normal. it uses only a simple 512bits shift register to receive work. 

So if the rs232 is at 115k2 you waste 512 / 115200 of a second, 4.444444ms which is at 200MH/s a total of 888,889 hashes each time you send new work.

cause a 1/2000 speed loss.

[andrehorta]

Can you post a video?

It´s necessary to connect the boards (Icarus) on PC? To connect to the internet? Or Icarus has connection to internet?

[TheSeven]

Can you post a video?

It´s necessary to connect the boards (Icarus) on PC? To connect to the internet? Or Icarus has connection to internet?

Yes, you do need to connect these boards to a PC which runs the mining software. The board play's the graphics card's role in mining.


BTW, I'm happy to announce that (experimental) Icarus board support was added to the Modular Python Bitcoin Miner some minutes ago

[hardpick]

i am lost to what software i should be now using
for more reliable mining under windows 7

bitsteam  v4 and queue_ver_with_auto_restart
is this correct?

[ngzhang]

it's ok

[xiangfu]

things get eaiser, I create a openwrt package for the router:
  http://downloads.qi-hardware.com/people/xiangfu/icarus/icarus-miner_20120209_all.ipk

wiki page have updated:
  http://en.qi-hardware.com/wiki/Icarus#Using_TP-link.2Ftl-wr1043nd_as_host

xiangfu

I setup the miner.py under TP-Link wr1043nd home router. there is the steps:
  http://en.qi-hardware.com/wiki/Icarus#Using_TP-link.2Ftl-wr1043nd_as_host

it is using Openwrt. since the python package is too big for the flash. so I cut down a lot of the python stuff. only works fine with miner.py.
and for now it only support monitor only one worker.

if you also want try. please let me know if it doesn't work.

[ngzhang]

i suggest every one switch to Modular Python Bitcoin Miner
https://bitcointalk.org/index.php?topic=62823.0

[coblee]

i suggest every one switch to Modular Python Bitcoin Miner
https://bitcointalk.org/index.php?topic=62823.0

Yes, it's really good.

[server]

i suggest every one switch to Modular Python Bitcoin Miner
https://bitcointalk.org/index.php?topic=62823.0

Ok, but... I get this with curses installed...

C:\TheSeven>miner.py
Traceback (most recent call last):
  File "C:\TheSeven\miner.py", line 331, in <module>
    exec("import " + configfile + " as config")
  File "<string>", line 1, in <module>
  File "C:\TheSeven\default_config.py", line 9, in <module>
    import frontend.theseven.cursesui
  File "C:\TheSeven\frontend\theseven\cursesui.py", line 32, in <module>
    import curses
  File "C:\Python27\lib\curses\__init__.py", line 15, in <module>
    from _curses import *
ImportError: No module named _curses

[TheSeven]

C:\TheSeven>miner.py
Traceback (most recent call last):
  File "C:\TheSeven\miner.py", line 331, in <module>
    exec("import " + configfile + " as config")
  File "<string>", line 1, in <module>
  File "C:\TheSeven\default_config.py", line 9, in <module>
    import frontend.theseven.cursesui
  File "C:\TheSeven\frontend\theseven\cursesui.py", line 32, in <module>
    import curses
  File "C:\Python27\lib\curses\__init__.py", line 15, in <module>
    from _curses import *
ImportError: No module named _curses

Which one of the curses for windows modules are you using?
It has been reported that the second one listed in README.txt works fine, not sure about the other one. If it doesn't, I'll probably remove it.

[server]

Which one of the curses for windows modules are you using?
It has been reported that the second one listed in README.txt works fine, not sure about the other one. If it doesn't, I'll probably remove it.

I tried both.
I'm using w server 2008 x64 and python 2.7. but nevermind... I will try something else

Code:

C:\TheSeven>miner.py
Traceback (most recent call last):
  File "C:\TheSeven\miner.py", line 331, in <module>
    exec("import " + configfile + " as config")
  File "<string>", line 1, in <module>
  File "C:\TheSeven\default_config.py", line 9, in <module>
    import frontend.theseven.cursesui
  File "C:\TheSeven\frontend\theseven\cursesui.py", line 32, in <module>
    import curses
ImportError: No module named curses

C:\TheSeven>miner.py
Traceback (most recent call last):
  File "C:\TheSeven\miner.py", line 331, in <module>
    exec("import " + configfile + " as config")
  File "<string>", line 1, in <module>
  File "C:\TheSeven\default_config.py", line 9, in <module>
    import frontend.theseven.cursesui
  File "C:\TheSeven\frontend\theseven\cursesui.py", line 32, in <module>
    import curses
  File "C:\Python27\lib\curses\__init__.py", line 7, in <module>
    from _WCurses import *
ImportError: No module named _WCurses

C:\TheSeven>

[TheSeven]

Did you install the curses module for the correct python installation? There are separate packages for each combination of python version and architecture (32/64bit), and this needs to match with the python version you're running the miner on.

[Defkin]

Very nice.....thank you TheSeven

Just need to change the blue font so i can read it, something to do over the weekend, lol