Cairnsmore1 - Quad XC6SLX150 Board

[Lethos]

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).

[rampone]

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.

[yohan]

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.

[hm]

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.

[dietwice]

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:

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

[ebereon]

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:

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

[steveme]

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 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.

[TheHarbinger]

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?

[yohan]

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?

We are looking at a pile of technology things that have a chance of being a serious contender and if we really think they are really viable and there is a need for them it will get released as a product in due course. Personally I think if *** comes up with the promised performance then the market will suffer stability issues and I don't think what they are doing is even good for their own customers or Bicoin in general. However that is their choice and I have said before that we don't actually mind competition as long as it is fair and reasonable. We will wait to see what actually happens. What we don't want to do here is add or cause the same instability problems to Bitcoin unless that is strictly necessary. We want to see all our customers have a good experience if that is possible.

Part of what we are doing now is reviewing how the Cairnsmore1 project has done technically and I think we have learned things here doing that project. I don't think it was all technically perfect but given how aggressively we released it into manufacture I am generally pleased with the solution. We are now getting the performance thanks to all the people that have helped on the bitstream and software side to make that work. We did realise at the start this would be our weakest area and part of what we have done in the 4-5 months of the Cairnsmore1 project is strengthen our ability a little in these areas. It's still far from where we want to go but commercial sense limits what we can do in this tight margin market.

Ok I know you are all keen to know about what we might do but firstly the commercial side of this is so sensitive there isn't a chance of us talking about any possibilities in advance in detail. Secondly there is also a much higher technical risk that things don't work so we don't want to announce anything that might not happen. Cairnsmore1's design was kept very simple deliberately so that we could do the promised timescales and that was a very reduced technical risk. Some of what we are looking at now is much more complicated and it could go badly wrong. So whatever we do we won't release any details until literally a product is stockpiling for shipment next time.

I'm sorry i can't tell you all more. Everyone likes to know more to make decisions on but for now everyone just has guess on what might come, or not, from us.

[LazyOtto]

Things just got more interesting.  Seems there is another ASIC builder out there now...

And, again, with some fundamental credibility problems.

From their page:
"Availability:   In Stock"
"boards are projected to ship in November/December of 2012"

[hm]

I changed the psu for #62-0017, but it didn't help.
Stats for #62-0017 and #62-0609 using mpbm and dcmwd4e 200MH/s with controller rev 1.3:



Seems I'll have to once again reflash #62-0017, this time I'll use the non-oc bitstream dcmwd4e 160.

[gyverlb]

Things just got more interesting.  Seems there is another ASIC builder out there now...

And, again, with some fundamental credibility problems.

From their page:
"Availability:   In Stock"
"boards are projected to ship in November/December of 2012"

I don't see this as a credibility problem. I suspect their website makes it difficult to sell a product which is not in stock or available at a given date. To offer pre-orders they probably had to mark them "In Stock".

[Slipbye]

@Hm I would recomend on your board 0017 try the d4e bitstream at 190 on FPGA 0+1 and a 180 Bitstream on fpga 2+3, should hopefully knock your invalids down a bit. Worth a try

[LazyOtto]

Things just got more interesting.  Seems there is another ASIC builder out there now...

And, again, with some fundamental credibility problems.

From their page:
"Availability:   In Stock"
"boards are projected to ship in November/December of 2012"

I don't see this as a credibility problem. I suspect their website makes it difficult to sell a product which is not in stock or available at a given date. To offer pre-orders they probably had to mark them "In Stock".

It is a false statement. I have zero tolerance for that.

Pleading 'technical difficulty' is insufficient excuse for falsehoods.

I did not order a BFL single until they were not only shipping product, but until the order to shipping lags had dropped to the low 50 days - the trend indicated they were finally catching up on backlog and would be able to meet their commitment on order date, with full payment taken, until ship date. Then they started slipping again on shipments and I eventually got a device in the BFL infamous 'four to six weeks'. (That is, long after their promised delivery by date.)

Enterpoint accepted my email indicating interest in x quantity of their product. They replied saying that I shouldn't expect anything until September, OK? In September I got an email from them stating sufficient quantity is available, time to pay if I still want the stuff. I paid them. They shipped the next day.

That is how to build a good reputation.

[Keninishna]

I changed the psu for #62-0017, but it didn't help.
Stats for #62-0017 and #62-0609 using mpbm and dcmwd4e 200MH/s with controller rev 1.3:



Seems I'll have to once again reflash #62-0017, this time I'll use the non-oc bitstream dcmwd4e 160.

What I would try to do is flash the 0017 board with the glasswalker 175 bitstream and controller it has a much lower error rate.

[kano]

In case anyone was interested
My current cgminer git source has a bunch of changes in it waiting to go into ckolivas git, including a code change for handling HW: errors - which of course means that cgminer will report HW: errors for all devices now by default - including using the Icarus driver being used for CM1

It does still have the HW: error jump bug that I've seen (twice now) and spiccioli had before.
That bug doesn't negatively affect anything in any but a minor way when it happens, and I now have a full debug log showing it - just need to find the time to analyse it and work out the cause.

So other than that, you will now get proper HW: error counts with that version (which will hopefully will be in the next version of cgminer)

Feel free to try it (if you can compile from source) and report any other problems with it.
https://bitcointalk.org/index.php?topic=28402.msg1158924#msg1158924

My git: https://github.com/kanoi/cgminer

The pull request: https://github.com/ckolivas/cgminer/pull/310
(that is just my master as a pull request to ckolivas)

[hm]

@Hm I would recomend on your board 0017 try the d4e bitstream at 190 on FPGA 0+1 and a 180 Bitstream on fpga 2+3, should hopefully knock your invalids down a bit. Worth a try

What I would try to do is flash the 0017 board with the glasswalker 175 bitstream and controller it has a much lower error rate.

thank you for the suggestions. I have now flashed d4e 190@0+1, 180@2+3 to 0017.
I had to restart the board about ten times until I got it running stable with less than 3% invalids. the other times, it had up to 99% invalids or did not pass the golden nonce test. board 0609 does not have these problems when using the same psu, usb cables and hub.

[Cranky4u]

To those with bigger brains than me....   

I have 2 *CM1s, in the 400 series range, that have been flashed with makoam's 220 bitstream. Overall the boards have performed very well with rejects being <1%. However....on both boards, FPGA 1, drops from U of ~6 to U ~3.5 and the orange data light becomes constant after a random time frame i.e. 10 minutes > 10hours. I have tried flashing these down to a makoam 210 and even a 200 MHs bitstream with the same results. So what I am asking from the group is, does anyone have further suggestions on how to get these last FPGAs stable at the same U rate as the other FPGAs?

My config is;
Win7
CM1 bitstreams; P0 = 220, P1 = 210, P2 = 220, P3 = 220 for both boards (mokoam latest bitstream)
CM1 controller: factory setting of 1.3
Power: 250W ATX using molar connections from 2 different lines
USB: 2 configurations tried. 1st: Gigabyte extra power USB ports (side by side). 2nd: Gigabyte extra power USB for 1 CM + standard front of case USB for other CM

With the high electricity costs in Australia, 22ckW/hr, I really need these babies going so I can shut down my 6770 arrays.

I shall chuck a sheckle or two of gratitude (0.5~1BTC) towards whom helps me achieve the desired stability.

Regards,

Cranky

[gyverlb]

To those with bigger brains than me....   

I have 2 *CM1s, in the 400 series range, that have been flashed with makoam's 220 bitstream. Overall the boards have performed very well with rejects being <1%. However....on both boards, FPGA 1, drops from U of ~6 to U ~3.5 and the orange data light becomes constant after a random time frame i.e. 10 minutes > 10hours.
...
CM1 controller: factory setting of 1.3

You might want to try 1.5. I recently switched from the original controller (1.1 IIRC) to 1.5 and it seems to have solved my FPGA1 problems.
I didn't test 1.3 before 1.5.

Good luck.

[LazyOtto]

My boards are in transit. So, I'm trying to get everything I can ready to go before they arrive.

Two questions:

1) What version of the controller is installed on the currently shipping boards? 1.5?

2) Is "spiprog", which is constrained to MS Windows, the only way to upgrade the controller?

In other words, am I going to have to dig up some Windows machine in order to upgrade the controller firmware?