Probably is the answer. I'll talk it through with the team on Monday to see if there are any issues in doing this e.g. partner IP that we can't release.

This sounds a bit like the FTDI issue I described yesterday. I don't have the full details but there is a utility from FTDI to do a clean-up which followed by clean install might solve the issue. Normal uninstall doesn't appear to be enough if it is this. I think some registry entires are left that cause the issue and hence the utility. I will try and get more details of the how and what on this on Monday.

On a more mundane level have you tried a complete power-off and boot as opposed to reboot and clean plugin and bring up afterwards?

Also if you had dip switches set for programming did you put them to the correct settings for running?

If we put support into the Controller and the array FPGA supports reset on a suitable pin (and uses it suitably internally) it's possible to do 2 things on CM1 for a frozen/under-performing FPGA issue. The first is we can apply a reset to an individual array FPGA or any combination of them. We can also switch off the 1.2V rails individually from the controller. The 3.3V can be turned off as well but that is across all 4 FPGAs.

The are several ways these things can be implemented. Anything from in-band messaging to using spare I/Os from the FTDI interface.

We are going to try and cross compile the existing windows utility to Linux but it is a case of stopping work on other things to do this. Not a promise but I will see if we can do that this week.

At the moment you can't. I will look at getting in some sort of flash code on the LED into the controller but it's not there yet.

We are using http://www.ebuyer.com/279682-xenta-13-port-usb2-0-hub-mains-powered-n-uh1301 for our big test rigs. Fired up in the correct sequence, i.e. hit the USB hub on switch after 12V is up and runing, they are working well here. I imagine these are available, with suitable power adaptor, in most counties. The ones on Ebuyer come with a UK plug/brick so not very suitable for other markets directly. I believe have seen the same one on Ebay as well.

Controller chip will take power from either 12V or USB. It's a simple diode OR of the 2 supplies. It can even be a share in some cases. It depends on the exact voltage 5V on the USB, and the tolerance of the regulator in the 12V feed, which will input lead in supplying current although typically we would expect that to be the 12V if it is available.

We are still looking at this but to be honest we are just struggling to keep up with the things we have to do like buying parts to make boards, testing boards, shipping and support and so on without adding another variable to deal with. Glasswalker's recent bad experience is also something we are looking at and that's something that we are cautious of.

 

This might not be the problem but we have seen cases where the USB gets screwed up in Windows and once it does the com port is never seen again. However if this is the problem all is not lost. Basically there is a FTDI utilility to do a driver removal and cleanup after which a clean install of the driver usually sorts the issue. If anyone things this is their problem send an email to our bitcoin support email "bitcoin.support" AT "enterpoint.co.uk" and the relevant person will see it early next week when they are back in. Once I have the full details of how to do this myself I will try and get the recovery process listed on one of our webpages so it is easy to find.

On a different point if we do happen to have a DCM issue with power noise then we already have a tested fix. That's what we used to test a Glasswalker2 variant last week at 200MHz operation on an early board and it's very stable. It's not the same as the Controller build as publically available but because we built in a very flexible clocking system into Cairnsmore1 we don't actually have to use DCMs within array FPGAs. Simply we can direct supply a 200MHz clock, or anything similar 0-300MHz , straight to the FPGA to run the logic on. If this looks the way to go we will expand testing of this technique over a larger board sample.

Over the last 2 days we have been running Makomk's 190 build on rig of 20+ boards and we have very good results on our testing.

We can't 100% rule that out but it's very unlikely as the problem. You can always power it from a seperate power supply using the slow fan override to avoid the protection mechanism operating.

The nature of hashing with Icarus style bitstreams is inherently "noisy" and we did take special measures in the design to account for this e.g. using heavy weight power planes in the design. Obvious we probably use some more but it all costs somewhere down the line. There is always more that can be done for the future in the PCB design that will bring improvements but probably much more can actually be done in changing the hashing design and the way it operates.

We will work on understanding the particular problems and eventually work this into later products. We also know the design has it's good bits as well. The cooling has working welll as has the power supplies. It's actually hard to get the heatsinks more than a few degress above ambient. In our testing operating 1-2 FPGAs at 200MHz on our test boards has been amazingly stable given we don't actually meet timing at this speed. Once we have a reason bitstream available for most boards we can get back to the more interesting things we have planned for this design and start to show a little more of what we plan to do at a system level.

You can plug in the fan to any position. Our safety feature looks for a minimum of one fan rotating. You can override this using SWITCH2 and run a fan totally independently powered.

Boards 0001 to 0050 we will either replace with later issue boards or offer you a credit against new purchases as compensation if you still have an issue in 4 weeks time when we might have some unallocated board stock available again.

We now know from the work we are doing that the outer copper layers on these boards is slightly thinner that the boards 0051 onwards have. We can now more or less bring these boards back up to the 0051 onwards level by simply adding a few simple capacitors. That can be done in a few minutes and we are doing further testing on these boards to find out more and make those mods on any available boards we have. It's entirely possible we may also come up with firmware solution to solve this as well.

Ok I have just added what is our official Glasswalker2 release to zip that you download from http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html for the Glasswalker Controller. With serial nos 0051 and onwards boards we would expect 3 FPGA positions to run with this build at 175MHz. You probably only get 2 to run on a pre-0051 at the moment with this particular build.

We do have other taylored versions of this build running at 200 MHz, in 2 FPGAs, on a couple of pre 0051 test boards that we have for testing. We are looking at a pile of options and seeing what we can achieve on these earlier boards and this will take some time to complete. We are looking to get this up to 3 or 4 FPGAs if it is possible and we are investigating the possible issues that are currently restricting us going to 3 or 4 FPGAs.

In a similar vein we are also looking to get 4 FPGAs on the post 0050 boards. We are running a large sample with the 175MHz build on 3 FPGAs as an extended production test now and those appear stable in this setup.

I am struggling to find time to be on this forum currently so I may well be out of date or not aware of things happening here currently due to many commitments including helping the team to make this all work. So I am not answering things here it's because  I am otherwise engaged.

If you are using the new controller check the new dip switches usage.


[/quote]
This is for the bitstream that will come from glasswalker.

Ok what I should have said, or done, is that dip switches have changed a little again. Programming mode is still available but you need to set a dip switch to enable it. This because we are using all 4 ports now as com ports so the function needs to be changed over to use programming modes.

If you happen to be using an external programming cable there is now an automatic clock shutdown whilst the JTAG chain is running. It's not 100% perfect yet and you can still force clock shutdown using SWITCH3.

Here is the info.

Cairnsmore controller for Glasswalker2 build is noe available on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html. This is only for the Glasswalker build and won't work with any other bitstream. Currently only properly supporting 3 FPGAs with 4th running very poorly. Expect a U of about 7.5 from what we have seen and power usage less than 30W.

Ok a short update on progress with glasswalker's build that we are playing with. We have this now running on 3 FPGAs with a good stability and good mining results currently at a 175MHz clock rate. The 4th FPGA position still has some problems and we have a few more things that may make it viable in it's current form yet to try. Either running as 3 or 4 FPGAs we will aim to make a controller release available for it later today as it will give you all better hashing rates and U values. We will discuss with glasswalker how current bitstream is released and there may be more than one variant of the bitstream to suit each FPGA's particular needs.

The current issues are related to noise on the com lines which coupled with a weak UART design which either allow a false edge trigger and/or incorrect data to be received. At the penalty of a rebuild this can be fixed with a more robust UART design should the other methods that we are currently playing with fail.

The 175MHz build also looks like it might run at 200MHz on many boards as well but we have more work to do on that. We will concentrate on the 4th FPGA issue first before looking more at this possibility.

Ok guys just to let know I'm not ignoring you all for any other reason than I am working on something interesting and won't be on the forum for the rest of the weekend and may be also limited in my visits during the coming week for the following reason:

Courtesy of one of our development partners, who has been working on this since we started, we now have a bitstream running a golden nonce test at 200MHz clock and without issue on all 4 FPGAs on a couple of boards for 30mins+. Now don't get too excited yet as this build still has problems running a full nonce range for mining and we are looking to see if we can stabilise this to run full range or to see if our partner can improve timing. Technically at the moment timing isn't met yet for 200MHz but there is a reasonable possibility that timing can be totally closed for 200 MHz or at 175MHz that is our 2nd fallback target level. We also have to expand testing to a wider number of boards to be more certain of design stability. The new build can run Icarus pair style or individually with the pinout we are using but we are getting better results running as individual processing units on 4 individual com channels.

Our own native development bitstream continues in parallel.

I know there will be a pile of questions ypu all want to ask on this but I am going dark, on all forms of contact, for at least the rest of the weekend so i stand a chance of progressing the design through to better stability and being more useful.

No formal instructions but I will try and get that into the user manual which is still in progress.

All you need to do is to remove the screws from the 4 feet. On the bottom board you are going to reuse the feet with the stacking pillar so the stacking pillar screws into the foot instead of the normal screw. Sometimes you may have to hold a foot with grips or pliars to allow you to tighten in the stacking pillar enough. The next board you do something similar except this time you screw into the first set of stacking pillars rather than a foot that the first board does. Apart from a screwdrive to remove screws and maybe a grip to hold feet you should be able to hand tighten everything else.

Array FPGA pin constraints are now available for bitstream developers and customers on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html.

We will have a talk internally on Thursday/Friday when we have the relevant people back from holiday but it's more or less guaranteed that we will go to 2.5.0 of CGminer as the level we are working with.