Any technological project is prone to delays and problems and every time I think out any project timescale I then multiple it by X3. Over my very long history in electronics that X3 number is usually about right. Putting that into simple terms the logistical and technological problems take twice as long to fix as the original timescale.

I have said before that competition is good and I think it is up to all the ASIC vendors to deliver and prove their products. I think we should leave them to just get on and prove themselves. Personally I think there are too many ASICs coming in the near future and many people won't get the return they think they will out of ASICs. It's a case of too many too soon and a slower drop in, smaller performance jump, would be much better for the health of Bitcoin. If I prove to be wrong then we will consider letting our Goliath technology into the market but we think it's way too much for now.

Yohan

During startup there are surges mainly due to the capacitors on the 12V and rails that come up more or less immediately. We have limited these surges by the way we turn on the main power supplies and that is the reasoning for the phased turn on that you will see on the board. That goes a long way to limiting surges. We don't know what the surge current peaks at as it changes dynamically as the boards power up and the highest current peak is extremely short duratiion and very hard to measure.

What do think is sometimes a problem is the rate at which the 12V rises from 0V to normal range. This rise rate depends on the number of CM1 boards in the rig and the power supply being used so it is different for more or less every rig. If is too slow then one of 2 things can happen. The first is that the Controller FPGA fails to configure. The second is that we think that the USB doesn't come out of reset correctly. To see if this is your issue try powering up with only some of your rig say half initially on the power supply. If these all come up ok repeat gradually adding boards to find where issues start to occur. If this does prove to be the root of your problems there are a couple of ways to proceed. The first argueably wasteful way is to either split your power supply into 2 power supplies or just use a bigger supply that might give a better ramp time. More crudely and needs care is to live plug in the power supply of the last few boards and after bringing up whatever of the stack will come up happily with the power supply.

It is more likely that the USB is screwed up but there is an ocassional thing that is power supply related. So try following this sequence in powering the rig up again up:

(1) Remove 12V power and ideally unplug all USB leads at Cairnsmore1s. If you happen to have a USB hub with a switch for on/off that can work as well as unplugging if it properly removes USB power. Do check that it does remove power some don't do this properly. Basically we want the boards to be fully de-powered before starting. This is also the only way also to reset the USB controller if it gets upset by sometime and we have seen that a few times.
(2) Power 12V and Controller LED is flashing on all boards and each FPGA section is powered and configured - LEDs bright.
(3) If you don't get Controller and section LEDs doing the right things modify the power up of the 12V by doing an initial momentary switch on then off and on again.
(4) Plug back in USB leads either one by one or use the hub switch if you have one.
(5) Make sure you leave enough time for USB to enumerate before firing up mining software and better still check USB ports/COMs are all correct and present in the host.

When using master/slave in Controller 1.5 it is important that both boards of the pair power up together otherwise one may fail to start up and that is only an issue for master/slave usage. We are going to try and improve the Controller to either remove, or reduce, this powering up dependence but that might be a few weeks before we have the time to do that.

You have to be a little careful on what an individual ATX PSU will do. The additive of individual rails is often more than the overall rating but conversely that doesn't mean you can get the entire 1000 watts out of the 12V rails.

In some power supplies the 12V is also split and individual sections have a limit and it is possible to exceed the limit on one section whilst under capacity either overall or even in other sections.

There is another aspect which probably isn't a big factor in modern ATX supplies but I will mention to be complete and that is where the 5V or 3.3V is underloaded and causes an issue. In older supplies there was often a primary regulation based on usually 5V loading. Low or no load on the 5V typically lowered what I will call the excitation of the power supply and basically it drops too low to provide enough energy to 12V circuits. Some of you may have noticed that we put a small loading on our PDB for 5V and 3.3V to avoid this issue.

Controller Rev 1.6 is coming.

We have a few days testing to ensure that we didn't introduce any problems in the update. It offers for the first time a revision indicator. That uses a flash code on the Controller LED when held in reset using SWITCH1. We also did some work to reduce current and we appear to have taken 80-90mA out of the controller section power consumption. That might not seem a lot but if supplied from the 12V that's about 1W out of the board consumption or 2-3% of normal consumption when mining. If power is coming from the USB side then 80mA out of a 500mA maximum USB spec is a reasonable percentage but more importantly it might improve the reliability of the USB interface for some customers. We won't really know the latter until a number of you have run it and we get enough feedback of people "seeing" a difference. USB power surges could explain some of the occassional port disconnects reported and that is what we are hoping to improve with this change.

Ok we starting to look more in depth at what is a problem and what isn't. The invalids do seem to some sort of measurement about how much power is going into the chip which is what we most concerned about. Although there is no official limit published by Xilinx of how much current is ok in a Spartan-6 FPGA. Bitcoin mining obviously does operate these FPGAs outside normal expected range at best and there is always going to speculation about how much is too much. It's also likely that even the logic placement within the FPGA makes a difference and that is in part why some bitstreams do better and others don't do so well. What we have seen somewhat subjectively is that "better" bitstreams seem to use use less power at a given performance level. So it's chicken and egg time and the question is the performance better because of lower current or is it incidential to a tight design.

What we can see in the work that have done here already is that power goes up in an exponential curve once you reach a certain frequency which does vary by chip and to some degree ambient temperature. So a lot more power goes in with very little extra performance. That is where we think the problem lies. What isn't 100% clear is what failure mechanism occurs. Is either simply getting the die too hot or bond wires failing or a combo. These 2 things can be interlinked as well so it is complicated.

Generally it's not easy to tell but anything recently sent out will most likely have Controller 1.5 and a 190 bitstream. Controller 1.6 when it releases will have a flash code to indicate what it is.

To use the temperature sensors it will need bitstream support as these each temperature sensor hang off their respective adjacent FPGA. Even with such support the accuracy of these won't be great or even very responsive as they will effectively be measuring the PCB temperature and or the air temperature under the heatsink. That's a lot of delay/variation between actual die temperature and what is measured. It is one weakness in using Spartan-6 for Bitcoin mining that they don't have internal diodes for temperature measurement that more expensive parts do have. Otherwise we would be using that feature and have a much better measurement.

However they are not totally useless in thermal management and it is our intention to add some Controller support once we have the support in bitstreams. Until the bitstreams have the support and we know how to access them in there isn't much we can do.

When we designed CM1 we did obviously knew about these temperature measurement limitations so that is why we put so much work into the heatsink and fan solution. You might ask why we didn't use the CSG package for the Spartan-6. It is a bit better than the FGG that we use in transferring heat from the silicon die to the case surface. The biggest reason we didn't use the CSG was that we couldn't offer the price we did. The second big reason is that the project would have been 2 months later than it was. The FGG also wins over the CSG in some other respects in the PCB design. We would have had to use a lighter copper weight on the power planes with a CSG package and most likely the PCB would have been more expensive again affecting the product cost. The copper weight does have some bearing on the thermal solution as well but probably more importantly the electrical performance on the power supply side. So in summary it's a toss up designers choice of which is actually best. For a first attempt, in a new market, I don't think we did too bad as a product.

If we had the luxary of maybe 2-4 more months development time we might have done 2 or 3 prototype levels and established the better of the 2 package options but CM1 probably wouldn't have happened at all then.

To do anything we would need a market to sell them into or their processing power and whilst we have heard of a couple of small customers that might take a few CM1s at the right price there is nothing currently that we know of that would take that many boards.

The chips themselves don't really have a resale market unless they become obsolete and hard to get. That's about a 15-20 years wait. The costs in time and money to recover FPGAs from boards is very large and they would be hard to sell because of "quality" issues related to recovery process. The recovery costs would almost certainly exceed whatever resale value there might be in the chips.

The number that can be used as good or bad can be debated. It is only an indicator and I doubt totally accurate. I would suggest a slow bitstream with less invalids might be a better earner anyway if you were at 5% invalids. The invalid number also has it's own debate here about what it actually means.

In CGminer I would think the U value will also give an indication of this.

We are doing more work on this and should know more as we gather more data about what causes an issue.

Throughout the Cairnsmore1 build we have been grading out lower performance boards and sticking them on a shelf to look at later. We have about 50 of these Grade-B boards to sell and we are going to offer them in 2 ways.

First way is you can go on our webshop and buy them at GBP £370 (+ vat if it applies), or equivalent in USD or Euros, with carriage on top of that. Local taxes and duties may apply as well to non-EU countries.

Second way is a Bitcoin purchase and we have set a fixed price for board and carriage in BTC. The only variation is if you live in the EU we have to apply VAT at 20%. For non-EU the fixed price will be 60 btc. For EU buyers it will be 72 btc. Non-EU customers may have local taxes or duties as well charged by the courier.

This grade will guarantee 700MH/s as performance. We will configure boards here to what we think is optimal configuration and may disable programming features so these cannot be changed from the set performance level. We will trickly these out over the next 2-3 weeks as we go through the process of setting them up and verifying the grade level.

We have seen what appear to be one or two total internal FPGA failures in the field which we are still gathering data and information on. It may be coincidence but 220 bitstreams were running on these boards. From some of the work we have done here we can see there is usual a big increase in power used when 210 and 220 bitstreams are in used and that is what we are worried about. Tied to that there is very little real performance to be gained particluarly on a 220 bitstream on most boards and often boards will actually give better return on a 200 bitstream. So for now our official recommendation is 200 or less bitstreams. 210 is probably ok but we need more data to confirm that.

behind all of this there is an effect called thermal runaway that is likely to be happening where the presence of heat allows higher currents to flow and hence more heat generated again i.e. runaway. We think all of the higher end bitstreams above 180 have an noticable element of this it is really down to how bad. Plotting performance against current isn't linear as it should be if clock rate was the only effect so we are pretty sure that is what is happening. There will be variations of this effect with silicon and to some small degree an enviromental effect. The cooling solution we have on CM1 is good but fundamentially the FPGA package is the main limitation to extracting heat given the performance of what we have in cooling. If room temperature is cold that will help a little and conversely if the room is hot.

We think the real problem comes when the devices go unstable often manifesting as high invalids and it is possible in this senario the currents go even higher than when we have measured on "stable" boards. Eberon has made some comments on this previously in one of the threads somewhere. The "damaging effect" may be one of a couple of things. First is the die just getting to hot. It's also possible that internal bond wires fail with too high a current and something basically melts. It is going to take us a while to get anything more solid than we know now so that is about as much as I can tell you all now.  

First version of Cairnsmore1 user manual is now available on http://www.enterpoint.co.uk/cairnsmore/CAIRNSMORE1_MANUAL_ISSUE1.pdf. I doubt it is perfect and we will try and improve this again in a few weeks time.

To be honest we are still looking at technology options of what we might do if anything. So there isn't a definate yes or no on that so far. We do want to do any new project in a very different way and any new design would be much more developed before we announce it. We are aware that a lot of Bitcoiners would like us to do a product and if it is viable for us to do it we will. We have learned a massive amount about Bitcoin mining and Bitcoins in general since we started and that knowledge is highly valuable to us in doing a more advanced project.

We also still have a lot of staff time going into the CM1 build and other supporting things that is a limit to what we can do currently on a CM2 project. That will throttle back in September but then we will be into designs and prep for our only exhibition show that we will do this year. Until that is past mid-November everything else will be on slow motion. So even if we go ahead on one of our concepts as a production item we are likely to be behind the competition in time unless they happen to slip a lot or we somehow work some magic.

 

We have seen USB ports be lost when something else is plugged in like a memory stick. We also think that sometimes a surge of current taken from the USB also causes a disconnect and a power USB hub seems to help here. It might be the plugging in of something else is actually a power problem. We have seen some machines (particularly laptops) prone to this and it sort of suggests maybe a dip on a shared internal power rail in the laptops might be a cause. Short of analysing every combo out there it's going to be very hard to totally identify this issue and our preference is to reduce the dependency on USB if not remove it totally with our rack controller concept.

If anyone has seen a benefit if cutting 5V on the USB wire as input to their CM1 we would like to know. We have been short on people to look at our test boards properly where we have done effective the same at board level so any data on the effect would be useful to us. We should be back to full staffing strength later this week for the first time in 10 weeks but there is something of a backlog to catch up on so it will still be a bit slow here for a few weeks.

You can't combine the 3.3V and 5V as they usually have a common ground/0V. You will simply short a rail and expect burning wires and flames.

Also be careful of power in individual sections and combining those as a capability. Often there is an overall limit as well as section limits and the overall is usually less than individual sections combined.

102W of the 12V is just about enough to run 2 boards but may struggle on the highest power using bitstreams. Probably ok for 190/200 bitstream but probably not 210/220 ones. The Cairnsmore1 has a normal maximum of about 60W but might go to 70W if we had bitstreams that needed and took 12A.

As long as the supply is actually 14V or under you should be ok. Thew current at 14V will be a little less than at 12V but you will have slightly higher inefficiency in the linear regulator supplying the Controller.

I think the weakest component in the 12V input is rated 16V so that is the absolute technical maximum. However watch with power supplies for the tolerance range. 5-10% is not unusual so 15V PSU might be 16.5V and over the limit. There are plenty of 12V 5A supplies around for LCD monitors if you want a brick style at low cost. For efficiency an ATX supply is a good choice for even a smallish rig like yours. Even without our PDB to do the turn on they are fairly simple to force on even if you don't have a hosting motherboard already to power and provide the turn on switch.   

No direct simple way to tell at the moment but one difference to tell between 1.3 and 1.5 is if master/slave works. It's not in 1.3 but is in 1.5. I think on your boards there is a better chance you have 1.5 but otherwise it is 1.3.

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.