Things just got more interesting. Seems there is another ASIC builder out there now...
http://www.btcfpga.com/index.php?route=product/product&product_id=58
Yohan, I know you said that you guys had a trick up your sleeve if/when BFL ever got their ASIC out of the vaporware stage. How are you guys felling about this new contender?
Is it time to roll up your sleeves and show us what you've been hiding?
Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 25. (Read 286370 times)
Hi All,
I tried different bitstreams and several cables but can't make the board work stable longer than 24 hours.
It fails after about 2 to 20 hours: Win7 x64 lose ports so I have to power cycle the board and then restart cgminer to make it see it again.
The board is marked 62-417.
Now it runs latest makomk 20120822 bitstream @190 Mhz (lower and higher frequencies are less stable) and controller 1.5
I tried different bitstreams and several cables but can't make the board work stable longer than 24 hours.
It fails after about 2 to 20 hours: Win7 x64 lose ports so I have to power cycle the board and then restart cgminer to make it see it again.
The board is marked 62-417.
Now it runs latest makomk 20120822 bitstream @190 Mhz (lower and higher frequencies are less stable) and controller 1.5
I'm getting 878.4 Mh/s from shortfin_dcmwd4e_ed_test_220_overclock.bit + CAIRNSMORE1_CONTROLLER_REV_1_5.bit on board 62-0444 (with cgminer-2.7.4 on Ubuntu 12.04 32bit & also tested with Win764bit)
All of the problems I'd been seeing (flashing & mining) were down to a poor quality 'brick' PSU - It worked as expected once I plugged it into my desktop PC PSU (4 pin Molex drive connector), and now I've got a decent external PSU rated for 5A@12v (60w) it's working like a charm.
Hi All,
I tried different bitstreams and several cables but can't make the board work stable longer than 24 hours.
It fails after about 2 to 20 hours: Win7 x64 lose ports so I have to power cycle the board and then restart cgminer to make it see it again.
The board is marked 62-417.
Now it runs latest makomk 20120822 bitstream @190 Mhz (lower and higher frequencies are less stable) and controller 1.5
I'm going to try Glasswalker's solution but getting some strange behavior when trying to flash the hashvoodoo controller via USB cable:
The same error shows when I try to flash 1.5 or 1.3 controller.
Switches when trying to flash are: 6 is OFF, all others are ON, as it is recommended in PDF.
Does anybody knows what does that mean?
Thanks
I tried different bitstreams and several cables but can't make the board work stable longer than 24 hours.
It fails after about 2 to 20 hours: Win7 x64 lose ports so I have to power cycle the board and then restart cgminer to make it see it again.
The board is marked 62-417.
Now it runs latest makomk 20120822 bitstream @190 Mhz (lower and higher frequencies are less stable) and controller 1.5
I'm going to try Glasswalker's solution but getting some strange behavior when trying to flash the hashvoodoo controller via USB cable:
Code:
D:\cairnsmore\bitstream\hashvoodoo-controller>SPIProg.exe hashvoodoo_controller_25.bit
SPIProg V1.0 Copyright Enterpoint Ltd й 2012
Cairnsmore Control FPGA Loader
Bitfile OK
NumPages: 207
Manufacturer: FF Family: FF MLC/Product: FF ExtendedData: FF
SPIProg ERROR - Device NOT XC3S50AN. Have you set the correct DIP Switch?
The same error shows when I try to flash 1.5 or 1.3 controller.
Switches when trying to flash are: 6 is OFF, all others are ON, as it is recommended in PDF.
Does anybody knows what does that mean?
Thanks
When you have 1.5 at the moment, you need SWITCH3 off too. Only SWITCH6 off does not work.
eb
Hi All,
I tried different bitstreams and several cables but can't make the board work stable longer than 24 hours.
It fails after about 2 to 20 hours: Win7 x64 lose ports so I have to power cycle the board and then restart cgminer to make it see it again.
The board is marked 62-417.
Now it runs latest makomk 20120822 bitstream @190 Mhz (lower and higher frequencies are less stable) and controller 1.5
I'm going to try Glasswalker's solution but getting some strange behavior when trying to flash the hashvoodoo controller via USB cable:
The same error shows when I try to flash 1.5 or 1.3 controller.
Switches when trying to flash are: 6 is OFF, all others are ON, as it is recommended in PDF.
Does anybody knows what does that mean?
Thanks
I tried different bitstreams and several cables but can't make the board work stable longer than 24 hours.
It fails after about 2 to 20 hours: Win7 x64 lose ports so I have to power cycle the board and then restart cgminer to make it see it again.
The board is marked 62-417.
Now it runs latest makomk 20120822 bitstream @190 Mhz (lower and higher frequencies are less stable) and controller 1.5
I'm going to try Glasswalker's solution but getting some strange behavior when trying to flash the hashvoodoo controller via USB cable:
Code:
D:\cairnsmore\bitstream\hashvoodoo-controller>SPIProg.exe hashvoodoo_controller_25.bit
SPIProg V1.0 Copyright Enterpoint Ltd й 2012
Cairnsmore Control FPGA Loader
Bitfile OK
NumPages: 207
Manufacturer: FF Family: FF MLC/Product: FF ExtendedData: FF
SPIProg ERROR - Device NOT XC3S50AN. Have you set the correct DIP Switch?
The same error shows when I try to flash 1.5 or 1.3 controller.
Switches when trying to flash are: 6 is OFF, all others are ON, as it is recommended in PDF.
Does anybody knows what does that mean?
Thanks
Yesterday I switched from makomks dcmwd4e to glasswalkers hashvoodoo_2012-08-20 and from cgminer to mpbm (glasswalkers fork).
Of course I upgraded controller and I wiped all FPGA before flashing in reverse order.
But I can't get p2 to work at all (not quite, I just saw that it has 2 accepted shares
), and p3 has very low accepted shares (less than 6% compared to p0).
Now, after 14h30m, only p0 is delivering shares that get accepted, the others give error msg: "Timeout waiting for validation job to finish".
Perhaps I should reconsider my waiting for a bitstream that fixes the issues I have with #62-0017.
But first I have to get another four boards to work, that were delivered to a friend of mine today.
makomk's dcmwd4e is the best bitstream with my board, reaching between 600 and 700 MHash/s as reported by pool.
Of course I upgraded controller and I wiped all FPGA before flashing in reverse order.
But I can't get p2 to work at all (not quite, I just saw that it has 2 accepted shares
), and p3 has very low accepted shares (less than 6% compared to p0).Now, after 14h30m, only p0 is delivering shares that get accepted, the others give error msg: "Timeout waiting for validation job to finish".
Perhaps I should reconsider my waiting for a bitstream that fixes the issues I have with #62-0017.
But first I have to get another four boards to work, that were delivered to a friend of mine today.
makomk's dcmwd4e is the best bitstream with my board, reaching between 600 and 700 MHash/s as reported by pool.
Something of production update in that we expect to fullfill most September delivery promises that were reconfirmed within the next 2 weeks. Do keep a lookout for emails from Enterpoint saying that your board/s are available as numbers reconfirmed are very close to what we are planning to make this month.
Anything left over once all these pre-orders are shipping will appear as general stock in our webshop and once these have all gone there will be possible lead time on new boards. I will update the thread once more information is available on boards left after the pre-order completes and how we stand on delivery on Spartan-6 silicon to make more. Generally Spartan-6 silicon is going on longer lead time that it was previously and this will limit how fast we can react to any new orders.
Anything left over once all these pre-orders are shipping will appear as general stock in our webshop and once these have all gone there will be possible lead time on new boards. I will update the thread once more information is available on boards left after the pre-order completes and how we stand on delivery on Spartan-6 silicon to make more. Generally Spartan-6 silicon is going on longer lead time that it was previously and this will limit how fast we can react to any new orders.
EnterPoint exchanged my board, new one runs like a boss. do not know what is was delivered with (190mhz seems a good bet) but put makomk dc4e 220 on it, seems to run flawless so far. next step into the flash, but for now...
I like. Good Job enterpoint/makomk/glasswalker/theseven and whom i forgot.
I like. Good Job enterpoint/makomk/glasswalker/theseven and whom i forgot.
Hashvoodoo bitstream, which shows the chips as separate rather than pairs is a little better for picking up those which can't handle it well (hardware errors).
How can I read out Invalids per ICA in CGMiner instead of MPBM ? Or are these included in the HW: (Hardware Error) count ?
They are Hardware Errors, but you can't read them out at the moment. Even with the source patch which is available somewhere it have some bugs and count it wrong.
Only with MPBM you can count invalids correctly and also count per FPGA, not only per pair (Makomk bitstream).
eb
How can I read out Invalids per ICA in CGMiner instead of MPBM ? Or are these included in the HW: (Hardware Error) count ?
Great, thanks for the update.
Now that Makomk, TheSeven and Glasswalker worked out a high performing bitstream, I'm glad to hear this will become a regularly stocked item (and suspect others are as well).
Now that Makomk, TheSeven and Glasswalker worked out a high performing bitstream, I'm glad to hear this will become a regularly stocked item (and suspect others are as well).
Hi Yohan,
Just curious if you have an updated ETA for when the boards will be available again. Is October still expected?
Thanks!
Just curious if you have an updated ETA for when the boards will be available again. Is October still expected?
Thanks!
We are aiming for October as a general availability again but I can't be precise at the moment of what date in October. A lot depends on how fast we satisfy our existing pre-order list and we are working our way though those orders now. It also depends on supplies of FPGA and other components. What we are aiming to do from October is to have some level of stock boards but if we get large purchases we will have short periods where boards are on some sort of lead time as we manufacture another batch.
Hi Yohan,
Just curious if you have an updated ETA for when the boards will be available again. Is October still expected?
Thanks!
Just curious if you have an updated ETA for when the boards will be available again. Is October still expected?
Thanks!
Code:
cgminer version 2.7.0 - Started: [2012-08-23 02:13:30]
--------------------------------------------------------------------------------
(5s):368.3 (avg):797.2 Mh/s | Q:133386 A:71374 R:332 HW:0 E:54% U:9.7/m
TQ: 0 ST: 3 SS: 1 DW: 2761 NB: 787 LW: 0 GF: 115 RF: 6 WU: 11.1
Connected to http://pool.50btc.com:8332 with LP as user
Block: 000004ff4340c97b50e0a7d4bf7ac798... Started: [04:11:09]
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
ICA 0: | 403.5/398.8Mh/s | A:39039 R:188 HW:0 U: 5.32/m
ICA 1: | 399.8/398.4Mh/s | A:32335 R:144 HW:0 U: 4.41/m
--------------------------------------------------------------------------------
20120828 04:30 - stop cgminer
Code:
cgminer version 2.7.0 - Started: [2012-08-28 04:31:23]
--------------------------------------------------------------------------------
(5s):749.6 (avg):793.3 Mh/s | Q:16444 A:8514 R:29 HW:0 E:52% U:9.4/m
TQ: 0 ST: 3 SS: 0 DW: 376 NB: 94 LW: 0 GF: 23 RF: 1 WU: 11.1
Connected to http://pool.50btc.com:8332 with LP as user
Block: 00000012c6c47dc749525c7b182e6036... Started: [19:31:45]
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
ICA 0: | 401.6/397.5Mh/s | A:4832 R:15 HW:0 U: 5.35/m
ICA 1: | 399.1/395.9Mh/s | A:3685 R:14 HW:0 U: 4.08/m
--------------------------------------------------------------------------------
20120828 19:35 - stop cgminer
(spikes around 3:00 are caused by the mining pool.)
makomk's 200 dcmwd4e @ #62-0017 is running stable but still with problems at ICA1.
For some days now, I didn't have time to test other bitstreams.
Also I noticed in mpbm that my workers under the work source would go from my pool to null status and the fpga leds would turn orange. I went under the work source settings and set the getwork connections from 1 to 3 and now my fpgas are flllyyying and no longer are waiting for work. 
what exactly do you mean by getwork connections? do you mean the getwork timeout? or the job fetching connections maybe?
Sorry, I forgot the exact wording but Job fetchter connections.
Also I noticed in mpbm that my workers under the work source would go from my pool to null status and the fpga leds would turn orange. I went under the work source settings and set the getwork connections from 1 to 3 and now my fpgas are flllyyying and no longer are waiting for work.
what exactly do you mean by getwork connections? do you mean the getwork timeout? or the job fetching connections maybe?
Also I noticed in mpbm that my workers under the work source would go from my pool to null status and the fpga leds would turn orange. I went under the work source settings and set the getwork connections from 1 to 3 and now my fpgas are flllyyying and no longer are waiting for work.
This new version of mpbm is working well for me. Definitely helps to see which boards are producing invalids but I would switch to a slower bitstream if the error rate is above even 5% because at that point its as slow as the next bitstream down anyways. Thanks for the help eb.
Sorry, I forgot this step lol! Post edited, thanks Keninishna!
This new version of mpbm is working well for me. Definitely helps to see which boards are producing invalids but I would switch to a slower bitstream if the error rate is above even 5% because at that point its as slow as the next bitstream down anyways. Thanks for the help eb.
How to optimice bitstream on every FPGA using MPBM:
First of all, set up MPBM with all boards(Workers), name them as I did with SN# and such and one worksource. And let it run!
Now load all FPGA's on the board with 220 dcmwd4e bitstream, if you have many boards, load all boards first with the 220Mh:
I hope I didn't forget a step
Attention! Do not let it run for hours with invalids >20% !!! It can damage the FPGA's with that amount! It's like overclocking a CPU and let it run while it have errors!
While you doing all this with a separate flashing machine, MPBM is mining away with every board connected exept the one you load at this one moment. This is very nice and the advantage of MPBM compared with cgminer/bfgminer.
I hope this helps a bit
eb
PS: For better understanding how you have to count the invalids on a pair(this have 4,5%), here is what I note in the text editor:
You see FPGA1 have 10 invalids, FPGA0 only 2, so I have to load a lower bitstream on FPGA1. FPGA0 is ok with only 2 invalids in the same time.
First of all, set up MPBM with all boards(Workers), name them as I did with SN# and such and one worksource. And let it run!
Now load all FPGA's on the board with 220 dcmwd4e bitstream, if you have many boards, load all boards first with the 220Mh:
- 0. set the logwindow settings in MPBM to 200!
- 1. connect the USB to your flashing machine
- 2. SWITCH3 off
- 3. SWITCH1 off and on to reset the board
- 4. wait for the bitstream loaded from SPI to the FPGA's (light blue LED)
- 5. fire up: sudo xc3sprog -c cm1 -p0 {bitstreamname220} && sudo xc3sprog -c cm1 -p1 {bitstreamname220} && sudo xc3sprog -c cm1 -p3 {bitstreamname220} && sudo xc3sprog -c cm1 -p2 {bitstreamname220}
- 6. wait 10 seconds(ubuntu!) and it should be done
- 7. SWITCH3 on
- 8. connect the USB to your mining machine
- 9. look on MPBM, it should reconnect this unit automaticaly!
- 10. watch the invalids for 10 minutes!
- 11. note the pairs which have >55% invalids - if the invalids are lower start with 14.
- 12. load the next slower bitstream only to this pair(start again as described above with 1. ) , you must load all 4 like: sudo xc3sprog -c cm1 -p0 {bitstreamname220} && sudo xc3sprog -c cm1 -p1 {bitstreamname220} && sudo xc3sprog -c cm1 -p3 {bitstreamname210} && sudo xc3sprog -c cm1 -p2 {bitstreamname210}
- 13. repeat 2. -12. until invalids <55%
- 14. now we have only <55% invalids
- 15. as you see every invalid logged in MPBM log window
- 16. note only one pair(Worker) at a time in a text editor like: "CM54 SN#62-564 | 220/220 | wd4e | 08-rig2 | 3: Got K-not-zero share 721e2931" search for this pair and note them up to 10 times
- 17. now you have 10 lines in you text editor, the second last digit of the invalid share tells you which FPGA is it. 0-7 = FPGA0 -- 8-9+a-f = FPGA1
- 18. I have now the above line like "CM54 SN#62-564 | 220/220 | wd4e | 08-rig2 | 3: Got K-not-zero share 721e2931 ->0" (this is FPGA0 as the second last digit is the "3", do this and count how many invalids shares have FPGA0 or FPGA1 on that one pair
- 19. load the next slower bitstream only to this FPGA!, you must load all 4 like: sudo xc3sprog -c cm1 -p0 {bitstreamname220} && sudo xc3sprog -c cm1 -p1 {bitstreamname220} && sudo xc3sprog -c cm1 -p3 {bitstreamname210} && sudo xc3sprog -c cm1 -p2 {bitstreamname200}
- 20. repeat 16. -19. until invalids <3% (Edited, sry I forgot this...)
- 21. All this can take time, it took me 1 hour for 10 boards
- 22. You are done optimicing every fpga
I hope I didn't forget a step
Attention! Do not let it run for hours with invalids >20% !!! It can damage the FPGA's with that amount! It's like overclocking a CPU and let it run while it have errors!
While you doing all this with a separate flashing machine, MPBM is mining away with every board connected exept the one you load at this one moment. This is very nice and the advantage of MPBM compared with cgminer/bfgminer.
I hope this helps a bit
eb
PS: For better understanding how you have to count the invalids on a pair(this have 4,5%), here is what I note in the text editor:
Code:
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: Got K-not-zero share 8b318881 1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: Got K-not-zero share 99fe4dbe 1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: Got K-not-zero share fb6d419e 1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: Got K-not-zero share 8e2469b9 1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: Got K-not-zero share 6beffd87 1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: Got K-not-zero share 5951eecd 1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: Got K-not-zero share 5f4fa9ae 1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: Got K-not-zero share ed6444dd 1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: Got K-not-zero share a5fca58b 1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: Got K-not-zero share 1518088d 1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: Got K-not-zero share b90e3421 0
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: Got K-not-zero share 86a3044d 0
You see FPGA1 have 10 invalids, FPGA0 only 2, so I have to load a lower bitstream on FPGA1. FPGA0 is ok with only 2 invalids in the same time.
Jump to: