Cairnsmore1 - Quad XC6SLX150 Board

[zefir]

Short update before I head to work.

I got 12 boards (with all USB hubs and PSUs I could grab) up and running over night with no hiccups. Pool reports 4.3 GHps average which matches half of what cgminer is reporting as all time rate.

One problem I observed is the USB cables. With my lot I got two types with 1.8 and 1.2m, with the long ones had problems to properly operate (both directly connected to my Laptop or over a passive USB hub). While some cause aborting communication, with others the ttyUSB ports are even not detected at all. So, if you observe glitches and see from your syslog that the tty ports were disconnected, just take the USB cable from your digital cam and give a try.

For those who also ordered lots of boards, here is how I set mine up (which without persistent SPI programing is PITA), for Linux:
1.) connect all to the PSU and USB cables
2.) set DIP switches as described for twin_test PROGRAMMING plus 115kBaud:
    SW6 (array top):       1 off, 234 on (115kBaud)
    SW1 (array bottom): 3 off, 124 on (programming mode)
    SW2 + SW5 (FPGA 0+3): 1234 on
    SW3 + SW4 (FPGA 1+2): 12 off, 34 on
3.) power on all boards
4.) for every board
 a) connect it to host
 b) program all FPGAs with 190M_V3.bit
 c) disconnect from host
 d) switch SW6-3 on (red controller LED starts blinking)
5.) connect boards to host one after another (first connect the hub and then the boards to the hub)
6.) run cgminer (default Icarus at 115kBaud) with all ttyUSB
7.) note which ones are the inactive FPGAs (usually those at ttyUSBx with (x/2 % 2 == 0))
8.) run cgminer with only active FPGAs (you might need to run several times until all are detected properly)
9.) mine
10.) hope nothing goes bad, otherwise: goto 1


HTH


Edit: fixed previously swapped SW1 and SW6

[1714038038]

1714038038

[1714038038]

1714038038

[1714038038]

1714038038

[testconpastas2]

2.) set DIP switches as described for twin_test PROGRAMMING plus 115kBaud:
    SW1 (array top):       1 off, 234 on (115kBaud)
    SW6 (array bottom): 3 off, 124 on (programming mode)
    SW2 + SW5 (FPGA 0+3): 1234 on
    SW3 + SW4 (FPGA 1+2): 12 off, 34 on
HTH

Are there different board versions with different switchs positions ?

in my card the switch positions are:

                23
6(top)       ##
1(botton)   ##
                54


could you confirm your config to avoid misunderstandings.   Thank you.

[daemonic]

Im starting to think i have an issue with my board;

CGMiner

Code:

[2012-06-28 16:52:57] Icarus Detect: Test failed at \\.\COM22: get 00018791, should: 000187a2
[2012-06-28 16:52:57] Icarus Detect: Test failed at \\.\COM23: get 000187a1, should: 000187a2

MPBM

Code:

2012-06-28 16:53:28.579000 [100]: Exception: Mining device is not working correctly (returned 81cce447 instead of 5eb01f04)
2012-06-28 16:53:30.080000 [100]: Exception: Mining device is not working correctly (returned 8fa31f04 instead of 5eb01f04)
2012-06-28 16:53:31.637000 [100]: Exception: Mining device is not working correctly (returned eea21f04 instead of 5eb01f04)

[daemonic]

    SW1 (array top):       1 off, 234 on (115kBaud)
    SW6 (array bottom): 3 off, 124 on (programming mode)

in my card the switch positions are:

                23
6(top)       ##
1(botton)   ##
                54

I think zefir has SW6/SW1 the wrong way around, i was quoting it that way around also as i assumed the SW number worked clockwise around the board, it wasnt till i got a maginfying glass out i could see properly

[zefir]

Are there different board versions with different switchs positions ?

in my card the switch positions are:

                23
6(top)       ##
1(botton)   ##
                54


could you confirm your config to avoid misunderstandings.   Thank you.

Sorry if I caused confusion. I was not aware that the switch numbers are printed on the board. Now with a lens I saw them (my eyes, you know...) and in fact in my post the numbering is swapped for SW1 SW6.

Will correct it there. Thanks for the heads up.

[testconpastas2]

to daemonic:

Programming fpga 0 and 3  my COM ports are 21 and 22. i Had your problem using stock cgminer 2.4.3 till i changed the sw6 1 to off
( 115k)  ( dont remember who said that but he's got all the credits)

switch 6 in my board is up acording with pdfs

try it!

[daemonic]

I normally program with SW6 1 on as per the pdf, but ive tried with SW6 #1 off for both programming and operation and its definately COM22/COM23 for me;

Code:

 [2012-06-28 17:29:37] Icarus Detect: Test failed at \\.\COM20: get 00000000, should: 000187a2
 [2012-06-28 17:29:38] Icarus Detect: Test failed at \\.\COM21: get 00000000, should: 000187a2
 [2012-06-28 17:29:38] Icarus Detect: Test failed at \\.\COM22: get 00018799, should: 000187a2
 [2012-06-28 17:29:38] Icarus Detect: Test failed at \\.\COM23: get 000187a1, should: 000187a2

CGminer works at 115,200 baud, so thats why SW6 1 needs to be off for it

[yohan]

Ok some running dip switch settings. These are now on support page as well.

[testconpastas2]

surelly port number is not important it will depend of windows driver installation.

When i received yesterday my boards first of all i unsuccessfully try to use the default shipping bitstream and the default shipping switch settings  sw6 all on sw1 all on and got your error:

 [2012-06-27 12:37:35] Started cgminer 2.4.3
 [2012-06-27 12:37:35] Icarus Detect: Test failed at \\.\COM20: get 00000000, sh
ould: 000187a2
 [2012-06-27 12:37:35] Icarus Detect: Test failed at \\.\COM21: get 00000000, sh
ould: 000187a2
 [2012-06-27 12:37:35] Icarus Detect: Test failed at \\.\COM22: get 00000000, sh
ould: 000187a2
 [2012-06-27 12:37:35] Icarus Detect: Test failed at \\.\COM23: get 00000000, sh
ould: 000187a2
 [2012-06-27 12:38:05] Error reading from BitForce (ZGX)


simply changing the sw6 1to off ( 115k) it started to hash  with default cgminer (2.4.3)  ( first i installed all usb drivers).
once i checked it worked i temporaly programmed the twin.bit and worked too.


 cgminer -o http://eu.ozco.in:8332 -u xxxx -p xxxx --disable-gpu -S noauto -S "\\.\COM21" -S "\\.\COM22"

Are you using the standart cgminer and the sw6 (1 off) thingy?


PS: i 've just remembered you had to wait to the amber lights before start cgminer.

[zefir]

Ok some running dip switch settings. These are now on support page as well.

Your pic says more than my 1000 words, yohan. Thanks!

The Icarus setting is exactly what I am using to mine with unmodified cgminer 2.4.3. For programming, I just set SW1-3 off and than back to on - works reliably.

I found another mini USB hub and attached 4 more boards. Looking at the cgminer output after a hour or so:

Code:

--------------------------------------------------------------------------------
 (5s):10926.6 (avg):11799.3 Mh/s | Q:1397  A:1364  R:0  HW:0  E:98%  U:65.8/m
 TQ: 56  ST: 58  SS: 0  DW: 256  NB: 3  LW: 4553  GF: 3  RF: 0
 Connected to http://eu.ozco.in:8332 with LP as user zeta-mining.1
 Block: 000008eb5cae1b4d3a1d0ebf00a7342e...  Started: [17:49:15]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 379.8/366.0Mh/s | A:54 R:0 HW:0 U:  2.61/m
 ICA 1:                | 379.9/370.3Mh/s | A:13 R:0 HW:0 U:  0.63/m
 ICA 2:                | 380.0/365.6Mh/s | A:51 R:0 HW:0 U:  2.46/m
 ICA 3:                | 379.9/374.7Mh/s | A:21 R:0 HW:0 U:  1.01/m
 ICA 4:                | 379.8/372.6Mh/s | A:56 R:0 HW:0 U:  2.70/m
 ICA 5:                | 379.9/372.1Mh/s | A:58 R:0 HW:0 U:  2.80/m
 ICA 6:                | 379.5/370.3Mh/s | A: 0 R:0 HW:0 U:  0.00/m
 ICA 7:                | 379.3/369.5Mh/s | A: 0 R:0 HW:0 U:  0.00/m
 ICA 8:                | 379.9/369.4Mh/s | A:53 R:0 HW:0 U:  2.56/m
 ICA 9:                | 379.9/369.3Mh/s | A:46 R:0 HW:0 U:  2.22/m
 ICA 10:                | 379.8/369.8Mh/s | A:45 R:0 HW:0 U:  2.17/m
 ICA 11:                | 379.9/370.1Mh/s | A:27 R:0 HW:0 U:  1.30/m
 ICA 12:                | 379.8/368.1Mh/s | A:60 R:0 HW:0 U:  2.90/m
 ICA 13:                | 379.8/369.3Mh/s | A:53 R:0 HW:0 U:  2.56/m
 ICA 14:                | 379.9/368.7Mh/s | A:49 R:0 HW:0 U:  2.37/m
 ICA 15:                | 379.8/368.8Mh/s | A:46 R:0 HW:0 U:  2.22/m
 ICA 16:                | 379.7/371.6Mh/s | A:57 R:0 HW:0 U:  2.75/m
 ICA 17:                | 379.8/372.4Mh/s | A:61 R:0 HW:0 U:  2.94/m
 ICA 18:                | 379.9/368.8Mh/s | A:60 R:0 HW:0 U:  2.90/m
 ICA 19:                | 379.7/369.8Mh/s | A:73 R:0 HW:0 U:  3.52/m
 ICA 20:                | 379.9/368.8Mh/s | A:43 R:0 HW:0 U:  2.08/m
 ICA 21:                | 379.9/368.2Mh/s | A:43 R:0 HW:0 U:  2.08/m
 ICA 22:                | 379.8/372.7Mh/s | A:38 R:0 HW:0 U:  1.83/m
 ICA 23:                | 379.9/373.6Mh/s | A:55 R:0 HW:0 U:  2.66/m
 ICA 24:                | 379.8/368.0Mh/s | A:44 R:0 HW:0 U:  2.12/m
 ICA 25:                | 379.6/369.5Mh/s | A:55 R:0 HW:0 U:  2.66/m
 ICA 26:                | 379.9/368.9Mh/s | A:44 R:0 HW:0 U:  2.12/m
 ICA 27:                | 379.9/366.1Mh/s | A:48 R:0 HW:0 U:  2.32/m
 ICA 28:                | 379.7/365.0Mh/s | A:48 R:0 HW:0 U:  2.32/m
 ICA 29:                | 379.9/368.2Mh/s | A:63 R:0 HW:0 U:  3.04/m
 ICA 30:                | 379.8/372.0Mh/s | A: 1 R:0 HW:0 U:  0.05/m
 ICA 31:                | 379.7/372.0Mh/s | A: 0 R:0 HW:0 U:  0.00/m
--------------------------------------------------------------------------------

There are always some units that remain at a very low U, i.e. not generating valid shares. Seems to be the instability eberon was reporting.

Looking forward for the real bitstream

[gyverlb]

I can confirm that the twin configuration works reliably (at least for 30hours straight on my 2 boards).

No luck storing it in flash though so if the power to the boards is lost I'll have to go to their location to reset them manually as it involves moving dip switches.

@yohan : is bitstream flashing supposed to need a manual intervention forever or will it be possible to do so remotely (without touching the dip switches) in the future ?

[yohan]

I can confirm that the twin configuration works reliably (at least for 30hours straight on my 2 boards).

No luck storing it in flash though so if the power to the boards is lost I'll have to go to their location to reset them manually as it involves moving dip switches.

@yohan : is bitstream flashing supposed to need a manual intervention forever or will it be possible to do so remotely (without touching the dip switches) in the future ?

Programming wise it's our intention that everything becomes resident in the SPI flash and doen't need to be live loaded every time. You should be able to do that now but obviously that's not straightforward for all of you and we are going to come back and look at that in more detail and try and make it better. We still have the ultimate fallback of using stand alone cables if that is necessary. It should not be necessary to go this far though.

We are looking to make things nicer and that you all don't have to fiddle with dip switches very much if at all. On the array FPGAs it's our intention that the dip switches will be totally unused. So once we have that SW2, SW3, SW4, and SW5 won't even be a consideration. The dip switches SW1 and SW6 for the controller will at least be simplified. We are still debating if we need a "safety" dip switch to act as a block to accidentially programming a board but pretty much everything else can become software controlled and I think that is the way it will go. At the moment only 7 of the 8 switch bits of SW1/6 are used but that's still 127 possibilities to get it wrong.

The drive for all of this will be the delivery of our original bitstream design and with that we will have the next controller build. With the first version of that our aim will be stability but achieving at least the circa 800MH/s everyone is looking for. It's a very radical design but I think everyone will be pleased with the results assuming it works the way we think it should. Either that we have totally lost our touch at doing these sorts of things. Hopefully that's not the case. It's now our big focus to deliver this now we are more or less sorted on the hardward bits of the design.

[Gomeler]

Thanks for the update. I'm sure you guys know by now how helpful it is to calm down customer's fears with the turmoil that recent announcements have created. Look forward to your official bitstream and hopefully we'll all just consider Cairnsmore1 as a proof of market product for Enterpoint.

edit: I should clarify. The BFL announcement has me shitting bricks and consulting soothsayers, fortune tellers and beer bottles as to how legitimate it is. Not sure if any other miners are in the same boat but it isn't a fun one At least in the end I'm hoping Enterpoint will be there with future products that leverage better technologies.

[Doff]

I'm looking forward to a new Bitstream, I have tried everything and every now and again I can get 1 ICA to work at around 120mhash. I'm bummed I'm not able to get the 300+ following the others instructions, and trying things on my own. It definitely seems to program but just wont do anything after that on one of the ports.

[jjshabadoo]

Unfortunately, too many members of the community have allowed greed to be their primary motivating force while hiding behind the concept of "protecting the network" which is a crock of shit. Last time I checked, no one has attempted a 51% attack and an army of people with FPGA's could very easily sustain the network over the long haul.

Unfortunately we have this great company in enterpoint coming into the market and BFL has once again used their unethical business practices to essentially halt the purchase of FPGA's while the lemmings line up once again to give these thieves no interest loans to fund their ASIC project.

Greed is such a bitch and it's going to destroy bitcoin before it has a chance to gain any real traction if people are going to flock to vendors like BFL.

This type of behavior is exactly what goes on in the central banking world that bitcoin was designed to help people gain freedom from, but once people start seeing those dollar signs, ethics and morals dissolve rapidly.

BFL has turned mining into the worst type of pyramid scheme and those who worship BFL are blindly following like crazed scientologists.

I can't believe people are willing to give a company like this upfront cash and these clowns can't even clearly articulate their buy back program until the community essentially forced them to do so.

I'd be bankrupt in a week and have my medical license taken away if I pulled half the stunts they have pulled.

I just wish there was a way to re-purpose or find some resale value for these FPGA's because I would buy dozens if that were the case.

Okay, sorry, rant over.

[zefir]

Programming wise it's our intention that everything becomes resident in the SPI flash and doen't need to be live loaded every time. You should be able to do that now but obviously that's not straightforward for all of you and we are going to come back and look at that in more detail and try and make it better. We still have the ultimate fallback of using stand alone cables if that is necessary. It should not be necessary to go this far though.
[...]

Yohan, could you please clarify what you mean with 'you should be able to do that now (i.e. writing to SPI)'? As said above, right now no one successfully wrote to the SPI flash and it is really a PITA to reprogram all devices non persistently again when one of them crashed and need to be powered fully down (you do not know which one is the problematic one and need to turn off all of them).

So either it is possible with the current controller programming, then could you please provide a detailed step-by-step instruction. Or it is not doable over USB but needs to be done via JTAG.

Either way it would be very helpful to flash the Icarus bitstream into SPI until your dedicated one is ready. Any clarification is highly appreciated.

Thanks.

[yohan]

Programming wise it's our intention that everything becomes resident in the SPI flash and doen't need to be live loaded every time. You should be able to do that now but obviously that's not straightforward for all of you and we are going to come back and look at that in more detail and try and make it better. We still have the ultimate fallback of using stand alone cables if that is necessary. It should not be necessary to go this far though.
[...]

Yohan, could you please clarify what you mean with 'you should be able to do that now (i.e. writing to SPI)'? As said above, right now no one successfully wrote to the SPI flash and it is really a PITA to reprogram all devices non persistently again when one of them crashed and need to be powered fully down (you do not know which one is the problematic one and need to turn off all of them).

So either it is possible with the current controller programming, then could you please provide a detailed step-by-step instruction. Or it is not doable over USB but needs to be done via JTAG.

Either way it would be very helpful to flash the Icarus bitstream into SPI until your dedicated one is ready. Any clarification is highly appreciated.

Thanks.

Yes I think all of this is currently possible and I will double check that this morning that I am not talking crap in any shape or form. We use these processes on our lines already. The load of the 4 array SPI Flash does take over 30 minutes so it does need patience to do. We do a 5-10 boards together here to stop it becoming a line blocker.

I will also see if we can somehow streamline the instructions.

[norulezapply]

Yohan, could you please clarify what you mean with 'you should be able to do that now (i.e. writing to SPI)'? As said above, right now no one successfully wrote to the SPI flash and it is really a PITA to reprogram all devices non persistently again when one of them crashed and need to be powered fully down (you do not know which one is the problematic one and need to turn off all of them).

So either it is possible with the current controller programming, then could you please provide a detailed step-by-step instruction. Or it is not doable over USB but needs to be done via JTAG.

Either way it would be very helpful to flash the Icarus bitstream into SPI until your dedicated one is ready. Any clarification is highly appreciated.

Thanks.

Yes I think all of this is currently possible and I will double check that this morning that I am not talking crap in any shape or form. We use these processes on our lines already. The load of the 4 array SPI Flash does take over 30 minutes so it does need patience to do. We do a 5-10 boards together here to stop it becoming a line blocker.

I will also see if we can somehow streamline the instructions.

I too would prefer working instructions for flashing to the SPI for the twin_test bitstream.

Personally I would prefer this now as opposed to getting the working bitstream a day earlier so then atleast I can run the twin_test bitstream without going through reflashing it every day.

I would be happy to give enterpoint an interest free loan if they could beat BFl to it.

Who's with me?

I'm not giving anyone an interest free loan.

[yohan]

Yohan, could you please clarify what you mean with 'you should be able to do that now (i.e. writing to SPI)'? As said above, right now no one successfully wrote to the SPI flash and it is really a PITA to reprogram all devices non persistently again when one of them crashed and need to be powered fully down (you do not know which one is the problematic one and need to turn off all of them).

So either it is possible with the current controller programming, then could you please provide a detailed step-by-step instruction. Or it is not doable over USB but needs to be done via JTAG.

Either way it would be very helpful to flash the Icarus bitstream into SPI until your dedicated one is ready. Any clarification is highly appreciated.

Thanks.

Yes I think all of this is currently possible and I will double check that this morning that I am not talking crap in any shape or form. We use these processes on our lines already. The load of the 4 array SPI Flash does take over 30 minutes so it does need patience to do. We do a 5-10 boards together here to stop it becoming a line blocker.

I will also see if we can somehow streamline the instructions.

I too would prefer working instructions for flashing to the SPI for the twin_test bitstream.

Personally I would prefer this now as opposed to getting the working bitstream a day earlier so then at least I can run the twin_test bitstream without going through reflashing it every day.

I would be happy to give enterpoint an interest free loan if they could beat BFl to it.

Who's with me?

I'm not giving anyone an interest free loan.

Let's not worry about the name that shall not be mentioned. Let's see firstly how the technology gong into Cairnsmore1 works. If it achieves even some of what think it can, and that is still an if, but and maybe, we have something that that is potentially a major step forward. Anything we can do in Cairnsmore1 can be done better in Cairnsmore2 where we have more technology to play with.

[rjk]

Anything we can do in Cairnsmore1 can be done better in Cairnsmore2 where we have more technology to play with.

Any hints on what's up for specs?