Cairnsmore1 - Quad XC6SLX150 Board

[Milan77]

Yes, I am very aware of potential losses and profits from Bitcoin gambling with diff and price.
So, litecoin mining may be possible on CM1 modded. Hmm, that is very interesting...

May there will be some trade-in for CM1 customers in next months, or not an option?
If your project 500Ghash/25k euros is still an option, I am looking for loans to make it happen. Of course, if august is still deadline for shipping.

I am open for all kind of ideas, here or in pm.

[yohan]

Yes, I am very aware of potential losses and profits from Bitcoin gambling with diff and price.
So, litecoin mining may be possible on CM1 modded. Hmm, that is very interesting...

May there will be some trade-in for CM1 customers in next months, or not an option?
If your project 500Ghash/25k euros is still an option, I am looking for loans to make it happen. Of course, if august is still deadline for shipping.

I am open for all kind of ideas, here or in pm.

No plans for a trade-in on CM1. Our original margin was so small that it isn't practical to do that. The difficult part for Litecoin is just having people to do the IP work but we can make the memory module available fairly easily. It will just be a derivative of our XC6SLX150 X1 Coprocessor and that makes the design time easy to find. It can offer up to 1GB of memory. The weakest part of this will be data link that will use the up/down connectors to pass data.

We are not fully sorted out on Goliath and still looking for replacement people to take on some of the work. That doesn't mean the project is stopped dead. It is just much slower than we would have been originally so no promises on timescales.

[kakobrekla]

We are going to offer a memory add-on to CM1 to help a potential Litecoin implementation running on CM1 and I expect if we do that and then either us or someone else does the Litecoin IP profit lifetime could be extended. It is only an well educated guess that the memory add-on will help a Litecoin mining implementation so don't use that fact for any financial analysis.

Yeah I wouldn't touch anything you do with a 10ft pole. I had my hands on all fpga from all manufacturers that were available, yours were clearly far worst.

Good luck anyway.

[norulezapply]

We are going to offer a memory add-on to CM1 to help a potential Litecoin implementation running on CM1 and I expect if we do that and then either us or someone else does the Litecoin IP profit lifetime could be extended. It is only an well educated guess that the memory add-on will help a Litecoin mining implementation so don't use that fact for any financial analysis.

Yeah I wouldn't touch anything you do with a 10ft pole. I had my hands on all fpga from all manufacturers that were available, yours were clearly far worst.

Good luck anyway.

This seems a bit unfair on Enterpoint/yohan.

My CM1 boards are still running strong after about a year of continuous usage

[2112]

Yeah I wouldn't touch anything you do with a 10ft pole. I had my hands on all fpga from all manufacturers that were available, yours were clearly far worst.

This seems a bit unfair on Enterpoint/yohan.

My CM1 boards are still running strong after about a year of continuous usage

I think you and kakobrekla are talking about two completely different measures of quality.

kakobrekla is talking about the signal integrity dimension of the overall quality.

norulezapply is talking about the manufacturing and reliability dimension of the overall quality.

Those two dimensions are nearly ortogonal and incommesurate.

This thread is proof for both: it took the longest time from the delivery of assembled hardware to the delivery of correctly and efficiently operating bitstream. Apparently CM1 has some sort of ringing/standing wave problem in the clock distribution networks and the USB interface on the PCB.

But once working CM1 proved themselves much more reliable than the majority of the consumer grade GPU boards used for mining. Those GPU boards had almost no problems with statrting up minning but became a real challenge to operate continuously because of the component failures.

I'm just an observer here but there is one striking thing about all the Enterpoint PCBs: they are all very symmetric geometrically. On the other hand I know that the PCB designers often intentionally make their designs geometrically asymmetric as a simplest and cheapest way to reduce the Q-factor of the possible parasitic resonators made of the PCB traces.

yohan had mentioned several times that the CM1 product was not developed using the full human resources of Enterpoint. It makes me wonder if Enterpoint even has a full time analog signal integrity specialist. I certainly have seen several organizations where the signal integrity issues were resolved purely by trial-and-error process.

I'm just contrasting Enterpoint's approach with bitfury's approach: he seem to be the only one who made the analog simulations of the signal and power distribution when designing his ASIC. Professionally I have only experience with the methodology very much like bitfury's which results in the software (bitstream) being delivered ahead of the hardware (PCB).

[shawtux]

hi again.
well i was fooling around with my cm1 trying to make it work in cm1 (i want it there hahaha hardheaded me). so i did
https://bitcointalk.org/index.php?topic=94317.msg1073047#msg1073047

to update the bitstream using shortfin_dcmwd4e_ed_test_220_overclock.bit found here https://www.wuala.com/ebereon/Shared/bitcoin/bitstreams/

the thing is everything went kinda ok (at some point i think i flashed the controller onto the bitstream) but then i reflashed the above mentioned bit following the steps.

now i have a red blinking light permanetly on and it doesnt mine

my dip switches are SW6-1 off and in SW1 are all on


any ideas?

edit:
for the record i tried upgrading to controller 1.5 putting the dip switches as described in cm1quickstart and when i do SPIProg.exe CAIRNSMORE1_CONTROLLER_REV_1_5.bit
all i get is:
SPIProg V1.0 Copyright Enterpoint Ltd ⌐ 2012
Cairnsmore Control FPGA Loader

Bitfile OK
NumPages: 207

[ebereon]

hi again.
well i was fooling around with my cm1 trying to make it work in cm1 (i want it there hahaha hardheaded me). so i did
https://bitcointalk.org/index.php?topic=94317.msg1073047#msg1073047

to update the bitstream using shortfin_dcmwd4e_ed_test_220_overclock.bit found here https://www.wuala.com/ebereon/Shared/bitcoin/bitstreams/

the thing is everything went kinda ok (at some point i think i flashed the controller onto the bitstream) but then i reflashed the above mentioned bit following the steps.

now i have a red blinking light permanetly on and it doesnt mine

my dip switches are SW6-1 off and in SW1 are all on


any ideas?

edit:
for the record i tried upgrading to controller 1.5 putting the dip switches as described in cm1quickstart and when i do SPIProg.exe CAIRNSMORE1_CONTROLLER_REV_1_5.bit
all i get is:
SPIProg V1.0 Copyright Enterpoint Ltd ⌐ 2012
Cairnsmore Control FPGA Loader

Bitfile OK
NumPages: 207

Take a look here -> http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html

If you have 1.5 controller, scroll to the bottom on this page. The switches are named Switch1 to Switch8. Make sure Switch6 is on when mining or off (+Switch3 off) when programming SPI. I can remember that in one controller version they messed up the Switch settings, so you can also play with Switch 5, 6 and 7. If you have only one cm1 with version 1.5 make sure Switch 4 is on (Master).

The red led on the controller have to flashing to be able to mine, permanetly on means clock is set to 0Mhz and you can program the controller or the 4 fpga's depends on Switch settings.

I hope it helps a bit. Can't remember correctly because i don't have a cm1 anymore.

Greets,
ebereon

[shawtux]

thanks man!

i can flash the bitstream... but it seams like i cant flash the controller


D:\App Download\cm1\cm1\Cairnsmore Bitstreams>xc3sprog.exe -c cm1 -p2 -Ixc6lx150
.bit shortfin_dcmwd4e_ed_test_220_overclock.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 724 $ OS: Windows
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
        http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
        http://sourceforge.net/projects/xc3sprog/develop

Using Libftdi,
DNA is 0x9991f13d8d73e5f8
JEDEC: 20 20 0x18 0x00
Found Numonyx M25P Device, Device ID 0x2018
256 bytes/page, 65536 pages = 16777216 bytes total
Verify: Success!


will have to fight some more with the controller

edit:
https://bitcointalk.org/index.php?topic=94317.msg1073047#msg1073047

this worked for me... but the 5th blinking light does not go away :S


edit2:

seems like i had to go back to hashvoodoo bitstream and controller... no cgminer for me with this board craptastic hahahaha

[Newar]

[...] On the CM1s that I am running personally [...]

What is your average uptime before you have to reset?

[mighq]

hi,

I'm experiencing weird cm1 behavior and I'm running out of ideas.

I was hashing fine with 800 Mhps using 200 MHz bitstream (makomk shortfin_dcmwd4e_ed_test_200_overclock.bit).
Then I've reinstalled my OS (xubuntu 13-> xubuntu 12.04) and now I can't get more than ~650 Mhps.

When using bfgminer, which sees it as 2 devices ECM0+ECM1, it seems like first chip is only getting to ~250 Mhps and second one ~400. This is in the beginning, after some time both chips are stabilized at ~330 Mhps.
There are some HW errors and messages about increasing queue length in the beginning, then after lowering to 650 Mhps, it is fine.

I tried to change the miner to mpbm. Same result.
I tried to flash the bitstream to 180 Mhz one (makomk shortfin_dcmwd4e_ed_test_180.bit). No change.
I tried to use another OS: mpbm under win7. Didn't help.

It looks like one of chips is not doing well.

What can I do now to diagnose or fix the problem? Thanks for any ideas.

[lenny_]

hi,

I'm experiencing weird cm1 behavior and I'm running out of ideas.

I was hashing fine with 800 Mhps using 200 MHz bitstream (makomk shortfin_dcmwd4e_ed_test_200_overclock.bit).
Then I've reinstalled my OS (xubuntu 13-> xubuntu 12.04) and now I can't get more than ~650 Mhps.

When using bfgminer, which sees it as 2 devices ECM0+ECM1, it seems like first chip is only getting to ~250 Mhps and second one ~400. This is in the beginning, after some time both chips are stabilized at ~330 Mhps.
There are some HW errors and messages about increasing queue length in the beginning, then after lowering to 650 Mhps, it is fine.

I tried to change the miner to mpbm. Same result.
I tried to flash the bitstream to 180 Mhz one (makomk shortfin_dcmwd4e_ed_test_180.bit). No change.
I tried to use another OS: mpbm under win7. Didn't help.

It looks like one of chips is not doing well.

What can I do now to diagnose or fix the problem? Thanks for any ideas.

You using bfgminer. Please add

Code:

2>> cgminer.log

to you command line, so we can read your log.

[mighq]

hi,

I'm experiencing weird cm1 behavior and I'm running out of ideas.

I was hashing fine with 800 Mhps using 200 MHz bitstream (makomk shortfin_dcmwd4e_ed_test_200_overclock.bit).
Then I've reinstalled my OS (xubuntu 13-> xubuntu 12.04) and now I can't get more than ~650 Mhps.

When using bfgminer, which sees it as 2 devices ECM0+ECM1, it seems like first chip is only getting to ~250 Mhps and second one ~400. This is in the beginning, after some time both chips are stabilized at ~330 Mhps.
There are some HW errors and messages about increasing queue length in the beginning, then after lowering to 650 Mhps, it is fine.

I tried to change the miner to mpbm. Same result.
I tried to flash the bitstream to 180 Mhz one (makomk shortfin_dcmwd4e_ed_test_180.bit). No change.
I tried to use another OS: mpbm under win7. Didn't help.

It looks like one of chips is not doing well.

What can I do now to diagnose or fix the problem? Thanks for any ideas.

You using bfgminer. Please add

Code:

2>> cgminer.log

to you command line, so we can read your log.

here it is:
http://pastebin.com/i3nQaDMz

I expect avg hashrate to be around 720 (with 180 mhz bitstream), but it isn't. No hw errors shown in this 10m session, but hashrate went down from 720 in one moment to stable 640. If I let it run for 24h+ it avg will be only around 650.

[lenny_]

Can you run it for 1 hour for example? 10 minutes it's too short time for your pool difficulty (4).

[mighq]

Can you run it for 1 hour for example? 10 minutes it's too short time for your pool difficulty (4).

sure, here is 90m run:
http://pastebin.com/hsjtbVHa

[LazyOtto]

It looks like one of chips is not doing well.

What can I do now to diagnose or fix the problem? Thanks for any ideas.

Have you tried after following this start-up sequence?

• stop mining software
• disconnect CM-1 USB cable
• disconnect USB hub cable to computer
• power down CM-1
• power down computer
• power up / boot computer
• power down USB hub
• power up CM-1
• wait until CM-1 fully stable (or, two solid minutes to be sure)
• power up USB hub
• connect USB hub cable to computer
• connect CM-1 USB cable
• start mining software

Yeah, it seems pretty nit-picky. But I've had that sequence resolve things for me before.

[tigerbit]

It looks like one of chips is not doing well.

What can I do now to diagnose or fix the problem? Thanks for any ideas.

Have you tried after following this start-up sequence?

• stop mining software
• disconnect CM-1 USB cable
• disconnect USB hub cable to computer
• power down CM-1
• power down computer
• power up / boot computer
• power down USB hub
• power up CM-1
• wait until CM-1 fully stable (or, two solid minutes to be sure)
• power up USB hub
• connect USB hub cable to computer
• connect CM-1 USB cable
• start mining software

Yeah, it seems pretty nit-picky. But I've had that sequence resolve things for me before.

^^ that definitely helps, and if you're using the up/down cables with boards you might need more than one restart as the boards seem even more finicky when they're running master/slave.

Just a thought from a different angle - any telltale visual indicators from the boards?  What are the leds doing (predominately)?

Are you seeing any yellow leds when in routine running?  That might give a clue if the cause of your low hash rate is that the boards are starved of work and going idle.

[lenny_]

I would also suggest to flash them to HashVoodoo. You will always know, which FPGA chip is doing what (as they can be over/down clocked on the fly, and every chip can have different frequency).

[dodegkr]

im sitting at 800Mh per CM1 and have been since I bought them, shame I bought them too late.
Oh well hopefully a Lite coin bolt on will recoup some loss as goliath isn't here yet, if I was yohan I would build something so awesome it would let me retire, but I am not so your all lucky :-(

cheers

[tigerbit]

Well, unless my calculations are very much mistaken next difficulty update will be so long and thanks for all the fish time for my CM1s  

With one more circa. 30% increase in difficulty I'll only just be covering my power costs @ £0.09926 per kWh including VAT @ 5%.

Well, the temperature will be dropping soon here in the UK - perhaps I'll redeploy them into a less friendly environment as a frost protection heater for the winter

[norulezapply]

Incase anyone is interested, I am selling my two Cairnsmore1 boards, final revision, fully working. Comes boxed with cables, instructions and stacking kit.

Any price (reasonable) will be accepted.

Delivery available.

Thanks