Cairnsmore1 - Quad XC6SLX150 Board

[Isokivi]

This is a make-shift guide for windows users for faster, permanent flashing. I have not yet tested it, but apparrentley Slipbye has had succes with it. It also gets us out of the virtual machine (for good ?)

21:13] <TheSeven> http://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.6.0/libusb-win32-devel-filter-1.2.6.0.exe/download
[21:14] <TheSeven> install that, make sure the board to be flashed is plugged, start the libusb filter wizard
[21:14] <TheSeven> select the USB composite device which shows an ID of 0403 8350
[21:14] <TheSeven> install the filter driver for that
[21:14] <TheSeven> download this: https://xc3sprog.svn.sourceforge.net/svnroot/xc3sprog/trunk/xc3sprog.exe
[21:14] <TheSeven> create a new file called cablelist.txt in the same directory
[21:15] <TheSeven> put this line inside that file:
[21:15] <TheSeven> cm1 ftdi 20000000 0x0403:0x8350:
[21:15] <TheSeven> open a command prompt in the directory where the files are and run these commands:
[21:15] <TheSeven> set CABLEDB=cablelist.txt
[21:15] <TheSeven> xc3sprog -c cm1
[21:15] <TheSeven> it should detect the fpgas
a this point you want to copy the .bit files you'll be using to the same folder as xc3sprog is in.
[21:16] <TheSeven> if that worked, you can go ahead with flashing like usual
[21:16] <TheSeven> xc3sprog -c cm1 -p 0 -Ixc6lx150.bit file_to_be_flashed.bit

Enjoy your 1-3hours of spare time per day

[1714115237]

1714115237

[1714115237]

1714115237

[1714115237]

1714115237

[1714115237]

1714115237

[1714115237]

1714115237

[spiccioli]

I've written an Icarus change for cgminer that will support 3 new options:
baud rate (115200 or 57600) work divisor (1, 2, 4 or 8 ) and number of FPGA
This should even work with the old setup with only 1 of 2 FPGA working
https://github.com/ckolivas/cgminer/pull/283
Anyone interested come visit #cgminer as usual ... tomorrow ...

kano,

I'd like to ask one thing: the HW: value gives the number of invalid hashes that have been returned by a GPU, can this control be enable for FPGAs as well?

MPBM has a column in its web-page interface which tells how many invalid shares have been returned, can cgminer test returned shares to see if they're valid?

spiccioli

[hm]

board 62-0017 using cgminer
no problems with flashing, no lost usb-connections.

shipping_build.bit	don't know how well it worked
twin_test.bit	sometimes stable at around 380mh/s for up to two days, but most of the time between 40 and 200mh/s after some hours or minutes at around 380mh/s, never 0mh/s
makomk_icarus_cm1_140_test.bit	0mh/s after 2 to 4 "Accepted" messages
glasswalkers fpgaminer_top.bit	0mh/s
glasswalker2.bit (current)	running >1d21h, pool reports between 100 and 300mh/s, cgminer output see below

disabling usb power by taping the 5v connector insibe the host-side usb plug did not resolve the stability issues.

=> unstable board

latest cgminer output (glasswalker2.bit):

Code:

 cgminer version 2.6.1 - Started: [2012-07-31 00:28:42]
--------------------------------------------------------------------------------
 (5s):1509.8 (avg):948.9 Mh/s | Q:5119  A:10827  R:70  HW:0  E:212%  U:4.0/m
 TQ: 6  ST: 6  SS: 2  DW: 635  NB: 260  LW: 89625  GF: 108  RF: 13
 Connected to http://us2.eclipsemc.com:8337 with LP as user hm_worker
 Block: 000003525bdd224714873325e187e633...  Started: [21:44:19]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 187.7/186.7Mh/s | A:3542 R:21 HW:0 U:1.30/m
 ICA 1:                | 189.3/188.7Mh/s | A:3621 R:21 HW:0 U:1.33/m
 ICA 2:                | 194.7/193.8Mh/s | A:3664 R:28 HW:0 U:1.34/m
 ICA 3:                | 380.0/379.7Mh/s | A:   0 R: 0 HW:0 U:0.00/m
--------------------------------------------------------------------------------

[testconpastas2]

well after 24h testing one board with  makomks 160  it worked well for  a while but after 8-10h (in the morning)  ICA 1 was hashing at half its power... after reseting board with SW1 1-off it started to run again at full speed. it seems as one of the 4 fpga had stopped.

Are ICA 0 allways the same 2 fpgas? 0-1? 0-3?  or they are randomly assigned ?

can you detect wich fpga is frozen apart from watching which fpga green led is not blinking?  ( my boards are too high and i need to use a ladder).

I think my issues can be temperature ones. Here in Seville  40ºC (outside) is normal in summer. I would like to watch temp in my cgminer so I could analize behavior ( maybe next controller?)

I bougth a new conceptronic 4 port powered usb hub and it works perfectly in my aspire one. My old soyntec doesn't even work with my laptop

[ebereon]

Update on latest bitstreams after 17 hours:
Total 40 FPGA's = 10 boards SN#400+.

Makomk's oc bitstreams:
14x 200Mh, 22x 190Mh, 1x 180Mh, 3x 150Mh. That means 90% of all fpga's running @190Mh+ with <2.8% invalids!

Working bitstreams in percent:
200Mh oc = 35%
190Mh oc = 90%
180Mh oc = 90%
170Mh oc = 90%
160Mh = 100%
150Mh = 100%
140Mh = 100%

Next update with non oc'd bitstreams


Update Glasswalker's bitstreams:
not changed will update when new bitstream is out

eb

[Entropy-uc]

well after 24h testing one board with  makomks 160  it worked well for  a while but after 8-10h (in the morning)  ICA 1 was hashing at half its power... after reseting board with SW1 1-off it started to run again at full speed. it seems as one of the 4 fpga had stopped.

Are ICA 0 allways the same 2 fpgas? 0-1? 0-3?  or they are randomly assigned ?

can you detect wich fpga is frozen apart from watching which fpga green led is not blinking?  ( my boards are too high and i need to use a ladder).

I think my issues can be temperature ones. Here in Seville  40ºC (outside) is normal in summer. I would like to watch temp in my cgminer so I could analize behavior ( maybe next controller?)

I bougth a new conceptronic 4 port powered usb hub and it works perfectly in my aspire one. My old soyntec doesn't even work with my laptop

In windows ICA 0 will always be the com port that you point CGminer to with -S first.  I think linux might swap port assignments around if you restart.

40C is probably hot enough that you are overheating the FPGAs.  Enterpoint's thermal solution is very good, but it's constrained by cheap packaging of the Spartan-6.  With 8-9W I think you would be above the rated t-j for this device.

[testconpastas2]

well after 24h testing one board with  makomks 160  it worked well for  a while but after 8-10h (in the morning)  ICA 1 was hashing at half its power... after reseting board with SW1 1-off it started to run again at full speed. it seems as one of the 4 fpga had stopped.

Are ICA 0 allways the same 2 fpgas? 0-1? 0-3?  or they are randomly assigned ?

can you detect wich fpga is frozen apart from watching which fpga green led is not blinking?  ( my boards are too high and i need to use a ladder).

I think my issues can be temperature ones. Here in Seville  40ºC (outside) is normal in summer. I would like to watch temp in my cgminer so I could analize behavior ( maybe next controller?)

I bougth a new conceptronic 4 port powered usb hub and it works perfectly in my aspire one. My old soyntec doesn't even work with my laptop

In windows ICA 0 will always be the com port that you point CGminer to with -S first.  I think linux might swap port assignments around if you restart.

40C is probably hot enough that you are overheating the FPGAs.  Enterpoint's thermal solution is very good, but it's constrained by cheap packaging of the Spartan-6.  With 8-9W I think you would be above the rated t-j for this device.

Thank you.

there isn't 40º at home, maybe 25-27 .
After resetting it seems it's working ok, maybe was bad luck I'll keep an eye on it. twin_test sometimes give me problems so maybe  is not a bitstream issue. if it last more than two days then I'll think about using makomks'.

 

[ebereon]

Update on working miner soft with the new bitstreams:
Makomk's bitstreams:

• latest MPBM git testing branch with icarus worker
• latest cgminer
• latest bfgminer

Glassworker's bitstream

• latest MPBM git testing branch with glasswalkers worker
• latest cgminer should work as Kano wrote it supports 57600 baud with the new options

If other miner soft works with one of the bitstreams, please info to me and i will update this.

eb

[kano]

I've written an Icarus change for cgminer that will support 3 new options:
baud rate (115200 or 57600) work divisor (1, 2, 4 or 8 ) and number of FPGA
This should even work with the old setup with only 1 of 2 FPGA working
https://github.com/ckolivas/cgminer/pull/283
Anyone interested come visit #cgminer as usual ... tomorrow ...

kano,

I'd like to ask one thing: the HW: value gives the number of invalid hashes that have been returned by a GPU, can this control be enable for FPGAs as well?

MPBM has a column in its web-page interface which tells how many invalid shares have been returned, can cgminer test returned shares to see if they're valid?

spiccioli

It is enabled.
I don't filter anything out of the return data.
If I understand the Icarus bitstream source correctly (though I'm not sure), the only invalids I should get are if the share value is something like less than 256
Thus you should find ... on average ... around one HW: per 8 to 10 blocks you find.
I've actually never had any HW: in the months I've been mining on 2 Icarus boards (I just searched all my logs)
In cgminer a HW: is when the device returns a share, but it's not actually a share according to a re-hash of it.
All shares are checked that way in cgminer (i.e. Icarus also)

Having seen the recent problems with BFL - I suspect it's either a case of the Serial/USB driver queues data to avoid overwriting, or discards corrupt data before it gets back.
However, MPBM accesses the device via USB so I'm not sure exactly why it shows regular HW errors.

For anyone curious:
... and if you did actually add my pull request to the compile, the new option (as per the changed FPGA-README) is --icarus-options
Normally people would just specify --icarus-options 57600 to change the baud rate for all boards to 57600 instead of 115200
It also has a 'work_division' value which would normally be the default 2 (meaning the board divides the work in half for the FPGAs - you can specify 1, 2, 4 or even 8 )
And lastly 'fpga_count' which would normally be the same as work_division (but defaults to 2), however the earlier bitstreams had the issue where only one of 2 FPGA were hashing and thus setting that to 1 (instead of 2) will give back the correct MH/s
i.e. as per the example in FPGA-README --icarus-options 57600:2:1 would match a CM1 that hashes at standard icarus speed but only uses 1 of the 2 FPGA - and thus should display the MH/s correctly (and I/O at 57600 instead of 115200)
Of course, anyone specifically using --icarus-options please say so, so I can be sure if it actually is working correctly

[zefir]

I've written an Icarus change for cgminer that will support 3 new options:
baud rate (115200 or 57600) work divisor (1, 2, 4 or 8 ) and number of FPGA
This should even work with the old setup with only 1 of 2 FPGA working
https://github.com/ckolivas/cgminer/pull/283
Anyone interested come visit #cgminer as usual ... tomorrow ...

kano,

I'd like to ask one thing: the HW: value gives the number of invalid hashes that have been returned by a GPU, can this control be enable for FPGAs as well?

MPBM has a column in its web-page interface which tells how many invalid shares have been returned, can cgminer test returned shares to see if they're valid?

spiccioli

Hi spiccioli,

that bothered me too, since the information about invalids is missing completely in the Icarus stats.

What you can do with the original cgminer is enable verbose output. Do this either by adding --verbose to cgminer command line parameters or enable it interactively:
a) press D for display menu
b) press V for verbose
c) press <return> to get back to main menu

Invalid shares will be displayed with 'Share below target'. That helps to see if a board / bitstream combination is instable.

To track invalids long term, I use the following patch:

Code:

diff --git a/driver-icarus.c b/driver-icarus.c
index 5f2c78a..82d06f3 100644
--- a/driver-icarus.c
+++ b/driver-icarus.c
@@ -563,7 +566,12 @@ static int64_t icarus_scanhash(struct thr_info *thr, struct work *work,
        nonce = swab32(nonce);
 #endif
 
-       submit_nonce(thr, work, nonce);
+       if (!test_nonce(work, nonce)) {
+               applog(LOG_INFO, "%s%d: Share below target", icarus->api->name, icarus->device_id);
+               thr->cgpu->hw_errors++;
+               return 0;
+       }
+       submit_work_sync(thr, work);
 
        hash_count = (nonce & 0x7fffffff);
        if (hash_count++ == 0x7fffffff)

It will add those invalid shares to the HW counter displayed in the stats, quite useful to see how well a board did overnight with a given bitstream.

[kano]

Yep - looks like I'm wrong.
I thought the hash check was automatically called inside test_nonce()
(well there is certainly no reason I can think of why it shouldn't for all devices )
I'll chase up getting that fixed ...

Edit: oh it is called in there, just the HW counter isn't incremented generically, the driver code has to ...
Well ... don't I look stupid
Meh, I guess I shouldn't have assumed the original code (back when I started changing it) did that properly.

[zefir]

Yep - looks like I'm wrong.
I thought the hash check was automatically called inside test_nonce()
(well there is certainly no reason I can think of why it shouldn't for all devices )
I'll chase up getting that fixed ...

Edit: oh it is called in there, just the HW counter isn't incremented generically, the driver code has to ...
Well ... don't I look stupid
Meh, I guess I shouldn't have assumed the original code (back when I started changing it) did that properly.

I was not sure if it would be semantically right to increment the hw_error counter in submit_nonce() generally without adding side effects. Just searching the code for places that modify it shows that some drivers do it privately, so adding it to the generic function might account events twice.

Anyhow, it was meant to be a temporary hack helping us to tackle down the problems with CM1. If you think it is correct to use it for Icarus in general (which IMHO is, since a wrong share is a HW error), I can submit it as pull request, or I'm also fine if you just add it to one of your staging patch sets.

Thanks, zefir

[tenzor]

Can I pay for my order in BTC? If not, what are the options?

[kano]

No, the problem has been there since luke-jr first wrote the bitforce code (xiangfu copied the original bitforce code and then we rewrote ... most of it )
I suspect bitforce has the same problem - I'll check later.

It should be done in cgminer.c in my opinion and I'll discuss with ckolivas if he can think of a reason why it shouldn't
(i.e. yes all the drivers will need changing)

[ebereon]

Can I pay for my order in BTC? If not, what are the options?

Here are some informations about this board -> http://www.enterpoint.co.uk/cairnsmore/cairnsmore1.html

Payment options are also shown on it, just scroll down a bit.

eb

[Keninishna]

This is a make-shift guide for windows users for faster, permanent flashing. I have not yet tested it, but apparrentley Slipbye has had succes with it. It also gets us out of the virtual machine (for good ?)

21:13] <TheSeven> http://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.6.0/libusb-win32-devel-filter-1.2.6.0.exe/download
[21:14] <TheSeven> install that, make sure the board to be flashed is plugged, start the libusb filter wizard
[21:14] <TheSeven> select the USB composite device which shows an ID of 0403 8350
[21:14] <TheSeven> install the filter driver for that
[21:14] <TheSeven> download this: https://xc3sprog.svn.sourceforge.net/svnroot/xc3sprog/trunk/xc3sprog.exe
[21:14] <TheSeven> create a new file called cablelist.txt in the same directory
[21:15] <TheSeven> put this line inside that file:
[21:15] <TheSeven> cm1 ftdi 20000000 0x0403:0x8350:
[21:15] <TheSeven> open a command prompt in the directory where the files are and run these commands:
[21:15] <TheSeven> set CABLEDB=cablelist.txt
[21:15] <TheSeven> xc3sprog -c cm1
[21:15] <TheSeven> it should detect the fpgas
a this point you want to copy the .bit files you'll be using to the same folder as xc3sprog is in.
[21:16] <TheSeven> if that worked, you can go ahead with flashing like usual
[21:16] <TheSeven> xc3sprog -c cm1 -p 0 -Ixc6lx150.bit file_to_be_flashed.bit

Enjoy your 1-3hours of spare time per day

GLORIUS, thank you sir! I was hating spending so much time flashing my boards.

[bitcowok]

Here's a little write-up on my efforts last night with CM1 serial 62-0023.

Fired it up for the first time (been sitting gathering dust waiting for some worthwhile bitstreams etc), used my gaming pc (windows) to update controller to 1.3

Connected to the mining PC (gentoo), compiled xc3sprog with some help from arne and others in the IRC channel, and programmed makomk's 190 bitstream.

Configured MPBM, and mucked around with baud rates and dip settings till it was all working, again with more help from ebereon and others (thanks) on IRC. Note with controller 1.3, SW6 #1 dip controls 50/100mhz clock, which also sets 115200/57600 baud. This needs to be reset in the miner worker if changed. At one point the dip switch looked like it was off but hadnt properly "clicked" into the position somehow. It took me a while to realise, a click on and off (and powercycle board) fixed it. You can see the red flashing light next to the controller flashes at half the speed in 50mhz mode quite clearly.

Results for 190mhz: 100% invalids.

Reprogrammed with 150 makomk bitstream:
Results for 75mhz (hadnt quite figured out the dip setting problem above at this stage) : 30% invalids

Reprogrammed with 140 makomk bitstream:
Results for 140mhz: 80% invalids
Results for 70mhz: ~25% invalids

Thats how it stands currently, at 70mhz I get 280MH/s for the whole board, with 25% of that being invalid.

Well its no wonder Enterpoint had difficulties initially and limited the shipping test bitstream to 50mhz.

I've sent an email to Enterpoint asking about the possible capacitor fix that applies to the first 50 boards, or complete RMA.

[Doff]

0   ICA   0   Y   Alive   0.00°C   379.81   379.73   14,494   22   0   U5.33/m   
1   ICA   1   Y   Alive   0.00°C   379.81   379.62   14,317   33   0   U5.27/m   

SUMMARY   1day 21h 17m 27s

So far so good with makomk's 190 bitstream, getting to that 48h Mark.

[spiccioli]

I've written an Icarus change for cgminer that will support 3 new options:
baud rate (115200 or 57600) work divisor (1, 2, 4 or 8 ) and number of FPGA
This should even work with the old setup with only 1 of 2 FPGA working
https://github.com/ckolivas/cgminer/pull/283
Anyone interested come visit #cgminer as usual ... tomorrow ...

kano,

I'd like to ask one thing: the HW: value gives the number of invalid hashes that have been returned by a GPU, can this control be enable for FPGAs as well?

MPBM has a column in its web-page interface which tells how many invalid shares have been returned, can cgminer test returned shares to see if they're valid?

spiccioli

Hi spiccioli,

that bothered me too, since the information about invalids is missing completely in the Icarus stats.

What you can do with the original cgminer is enable verbose output. Do this either by adding --verbose to cgminer command line parameters or enable it interactively:
a) press D for display menu
b) press V for verbose
c) press <return> to get back to main menu

Invalid shares will be displayed with 'Share below target'. That helps to see if a board / bitstream combination is instable.

To track invalids long term, I use the following patch:

Code:

diff --git a/driver-icarus.c b/driver-icarus.c
index 5f2c78a..82d06f3 100644
--- a/driver-icarus.c
+++ b/driver-icarus.c
@@ -563,7 +566,12 @@ static int64_t icarus_scanhash(struct thr_info *thr, struct work *work,
        nonce = swab32(nonce);
 #endif
 
-       submit_nonce(thr, work, nonce);
+       if (!test_nonce(work, nonce)) {
+               applog(LOG_INFO, "%s%d: Share below target", icarus->api->name, icarus->device_id);
+               thr->cgpu->hw_errors++;
+               return 0;
+       }
+       submit_work_sync(thr, work);
 
        hash_count = (nonce & 0x7fffffff);
        if (hash_count++ == 0x7fffffff)

It will add those invalid shares to the HW counter displayed in the stats, quite useful to see how well a board did overnight with a given bitstream.

Hi zefir,

thanks for the info and patch, I'm seeing several share below target now!

This explains also while a few fpgas have U: lower than others.

spiccioli

[Cranky4u]

I get the same error as Ebereon I have 62-0013. The xc3sprog –c cm1 –p 0 twin_test.bit works, but loading to SPI Flash with xc3sprog –c cm1 –p 0 –I xc6lx150.bit twin_test.bit gives me the error below. 

JEDEC: ff ff 0xff 0xff
unknown JEDEC manufacturer: ff
ISF Bitfile probably not loaded

Also looking forward to programming these in Linux.

Thanks!

trying to flash 2 * FPGA boards and get this same problem on my Win 7 64 bit PC...any help on solving?