This is probably what you need to know and it is quite simple.

JTAG_TCK         <= USBC_0 WHEN SWITCH8 = '0' ELSE 'Z';
JTAG_TDI         <= USBC_1 WHEN SWITCH8 = '0' ELSE 'Z';
USBC_2         <= JTAG_TDO;
JTAG_TMS         <= USBC_3 WHEN SWITCH8 = '0' ELSE 'Z';

USBC_0 is bus that runs directly from the FT4232 to the controller and USBC_0 is PortA bit0, USBC_1 is PortA bit 1, USBC_2 is PortA bit2 and USBC_3 is PortA bit3. So basically the JTAG runs off the lower 4 bits Port A on the FT4232. The only direct effect is switch8 which is the top bit of the switches at the controller. It's used as an isolator if we want to plug in a separate cable. So if you write as if it's directly connected to the FT4232 you won't go far wrong. Default setting should have this interface connected.

It is worth switching switch3 to off during programming as that stops all the clocks and makes programming more reliable.

We will add dip switch setting eventually to the user manual which needs a final pass through for release. We are still doing some changes to these on different builds to what they do exactly but for most people if they are left in the normal published defaults they won't have a problem. Once we move out of the development phase all of this will stabilise and should be much simplier. We will also remove many of the dip switch uses and they simply won't have any effect in later controller builds.

We have not proven either hardware with urjtag. Our Prog3 is a Xilinx cable clone and in theory would work urjtag as Xilinx cable is on the support list. That said there are a range of Xilinx cables and it is possible our clone is one not supported. We know Prog3 works fully with Xilinx tools and that has always been our benchmark.

The in-built FT4232 on Cairnsmore1 is a big brother version of the FT2232 that is on the urjtag support list. It has the same JTAG processing features so that is why it might work.


This one is always difficult to give a number on because every country is different and the tariff code that things ship under changes it as well even for a single country. There are tools on the courier websites but even then those are difficult to use and predict charges. As we ship to over 30 countries, and 30 different taxation and customs regulations, on a regular basis we gave up years ago trying to work out these potential taxes and duties and we always quote as local taxes and duties may apply.

Local/federal sales tax is often collected in many countries so you don't avoid that by importing. I know about the states side fiddle of buying in another state and then not doing a proper declaration of what you owe in sales tax and people do do that. However some states are now very hot on that now and they are coming down hard on tax avoiders. On low value items most countries just wave the sales tax bit as processing is more expensive than the tax. I think here it is about £20 for that threshold.

The one that varies is most is duties and that very much depends on what the item is. Trying to allocate a harmonised code that this all hangs on is incredibly hard. The lists tend to be 5 years behind real items never mind niche items like Cairnsmore1. The US did have a different tax called MFP but it was very low percentage and we never have seen it appied.

[/quote]
I'd assume you could state that you do not offer any set-up support for third party bitstreams, I personally would be fine with it. We have a strong and extremeley knoweledgeable community here, if something is possible the hive-mind that is bitcointalk will not only find the solution, but also share it publicly.

[/quote]

For the short term we really don't have any available resources to add anything to the existing workload. If the ET bitstream was pretty much stable then we might take a hit on our other stuff and put some effort there but at the moment it's going to give us more support work than we could ever keep up with. Guaranteed will be a pile of questions that we simple don't have the answers too because we didn't design it or have access to even the source. As soon as we make something officially supported that would become our problem.

As far as I understand it you can use a programming cable to run ET bitstream already and there is even a chance our front end might just work anyway. Urjtag has support for a FT2232 a very close relative of the FT4232 we use on Cairnsmore1.

Generally once we are out of the inital development period, which is still our current stage, other things will be possible to consider doing like the 3rd party support. Our first thing to do though is support what we have out there already including your one problem board out of 3 that you have which might be hardware or even something that is natively not our own development but directly related like CGminer. We choose to support that at day1 so it is in what we promised to deliver.

From ET all we are looking for is something more stable to work with. We are entirely neutral to working with 3rd parties but we have to have some control over what is a finite resource i.e. our engineering team.

Ok possibly the return on return characteristics may have changed in the last weeks by *** but of course they may not deliver as promised and then ROI actually doesn't change. Do remember 10 weeks ago we offer a product at 33% discount because it was a development and that was explicitly explained at that point. Even only running at the 50% notional performance that we are today we are not far removed in ROI of other FPGA boards.

The core of the team are already running 100hr+ weeks and have done so since the start of the project. That's part of how we have achieved the timescales. We can't ask more of them than that. Anything that we do that isn't on the plan is a very direct hit on producing the bitsream and other support work for the bulk of our customers. A further point is adding another variable to support i.e. the ET bitstream will further impact progress by virtue of more support calls. If I read it right ET just said he has taken 1 week to get his own very known setup to work again. What's that going to be like for a customer that doesn't have the technical knowledge he has or we have on the products. It's a nightmare basically. We might end up having our team work a week on one customer installation as is and still not have a solution. That's why we are not jumping into the unknown just yet. I'm not in any way saying ET can't do his stuff and sort it out but what I don't what to see is our own progress complete stopped to support a third party. It's not even good for ET to introduce another variable to try and support. As far as I am aware he doesn't even have a Cairnsmore1 to replicate problems on and allow debug of his IP.

The Rev 1.2 is already coming out of beta and is now frozen. We did a before and after test on approximately 50 boards yesterday and it looked good on every one. That taken with a few reports in from customers gives us every reason to make it the default build for now and that switch on the line is already in place. Rev 1.1 is fine as far as we know for 3rd parties but there is no work to support that. Rev 1.2 we know is better and deosn't make any difference to the interface for 3rd party developers.

No doubts. The only problem we had was 100MHz clocking and we didn't need that. It's now fixed with the Rev 1.2 controller.

I DON'T THINK YOU ARE NOT EVEN A CUSTOMER SO WHY ARE YOU COMPLAINING. YOU WERE ONE OF THE TINY FEW THAT JUMPED SHIP ON ***S ANNOUNCEMENT.

To put matters straight we did not say we would start our own bitstream development at the beginning of this process and indeed people we talked to privately we told them we would have very little resources for this in May and only a little in June. I think I said quite a lot of this in this forum as well. We have more or less kept to that schedule and we have only really had a reasonable resourcing on this for 2-3 weeks now. Ok we made a small mistake on the wiring to the second chip and the original plan of dropping in an Icarus bitstream initially into all positions didn't quite work and that was our mistake. However it was a reasonable engineering decision to fix this with our own bitstream as the fastest way to sort the issue. The Icarus bitstream was only ever a temporary solution and I think that was made clear.

I have also said that for bitstream development it isn't easy to put a precise time on and yes I might have said a few days and maybe I should have said a few weeks. This isn't a process we can do a percentage complete number on with any accuracy. Unlike a lot of FPGA things we do this function with either work or it won't there is no partial working stage to give a measure on and it will simply be working one morning when I get in the office. Do remember too it is only 10 weeks and 4 days since we announced the concept and we probably have the best FPGA hardware platform designed but have manufactured and delivered hundreds of them to customers in that timeframe. I don't want to hark on about that but most professional engineers in the electronics business would either say that was either impossible or very unlikely that it could be done.

As to ET's bitstream that has barely been working for more than a handful of days on one of Ztex's boards and has had a pile of problems on there over those days. We are watching how this develops and I am sure he will sort out the issues. We could sink our entire resource into supporting that now but it's no guarantee that it will work any quicker and if it did his server might well collapse under the weight of Cairnsmore1s trying to use the server services. That would also bring our own develop to a complete halt which would not be good and we have a pile of customers that simply don't want to be forced down that route. So this is something we have to balance our time on. When the ET solution is slightly more stable will be the time to some work.

Also as far as I understand ETs solution can't support multiple units working together as yet. We don't have any problems with customers using this bitstream as such and we will do our best to support it. We do believe we have the best chance of any of the FPGA boards of being able to support that bitstream given our power and cooling systems but right now it looks like a pile of development work and server hardware to install before it is actually a viable solution. I will have a look at what he needs once I find a utility to open a jar file and see if we can do anything quickly. If it is days of work then it won't happen this week for an unstable solution the time is better spent stabilising our own product and we have made good progress this week already with the new controller update.

Round up for today was that we day excellent results with the Rev 1.2 Controller at several different levels including the best utility factor we have see with the twin bitstream. Absolutely no adverse effects have been seen with the new controller either and we will start using this on the line from tomorrow for boards going through the final assembly/test line.

We will continue to look at the other driver/CGminer issues and updates on those as we find out more.

[/quote]

Ok, now I'm even more confused, that's exactly where I got the info from. The problem with the loader PDF document in that zip is it doesn't show you what SW  2, 3, 4, and 5 are supposed to be set to, so I assumed they should all be off. Maybe that's why I never got the last one working.

Can you look at that document and make give me the exact switch settings for the controller update? Id like to try one more time on the broken board. I'm going to drop it off for shipment back to you guys tomorrow as well.

Also I'm using Linux currently and the new board you sent seems to be working great with the FTDI drivers and Cgminer 2.4.3 without any modifications.

Thanks,

Doff
[/quote]

Ok I will try and rework the document to make this clearer. Meanwhile have a look at the pictures on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html. The dip switch numbers have been made bigger and clearer on these.

USB Problem

We have found a bug in the FTDI drivers/CGminer used with/for the Twin bitstream. At the moment we know this is an issue in Windows7 64bit but may extend to other OS versions or even Linux. Basically we are seeing some COM ports "lost" when the host plugs and plays a new device. That can be any device e.g. memory stick. We are looking at this to determine the cause and potential fixes.

Ok we don't know if this will fully fixes all problems because as yet we don't setups here that show the same problems some of you have and that is why we need work on each problem individually. We do need each board that you have a problem with to be reported to the bitcoin support email with the full circumstances. Not everyone on the team has the time to wade through the forum and they don't unless they stop work on new features or support work so that means problems can be missed. I will try to patch the gaps but I also have a limit in what I can find time to do. It's much better if the information arrives at the correct place and several people get to see it. It also acts as a log we can go back through then also.

Ok what we do know is that this build appears to improve the clocking at 100MHz i.e. that used for the Twin build. We do have some more tests to check this out and that is why it is beta. What we don't know is whether the clocking is the problem failure of the golden nonce test. I wasn't aware of that issue and that is much more likely to be a setup, software or firmware issue. We think that the FPGA DCMs lose lock sometimes and we already have fixes for this also in the working FPGA end which will be available in our own bitstream design that we can't do to the Twin which basically isn't our design.

We also think a few rigs may be suffering from power surge issues particularly at start up. This a problem in several parts including the host power supply quality, wiring quality, and even the Cairnsmore1 itself. This might explain some of the USBs not enumerating but there are also other possibilities for that including faulty USB cables that we did have a few problem ones of. Rev 1.2 has power startup sequencing so that we power each of the 4 power sections in a sequence over 4 seconds and that switch on sequence will be very obvious when you power the boards. This softens the surge on the board and we will extend this rig wide when the up/down becomes functional. One the things that is different with Cairnsmore1 is that there are several large rigs using Cairnsmore1 the size of which have not been seen before in Bitcoin mining. These bring new design challenges in things like power and cooling and we have designed Cairnsmore1 to cope with these extra challenges. Cairnsmore2 when we do that will take the concept to a much bigger level again.

We have also phased on board clocks in the new controller build to reduce "beat" cycles on the power supply. Every FPGA doing exactly the same thing at the same time is a very good way to cause beat surges on the PSU so if we can move those slightly apart then that is good thing to do and make life easier for the power supply.



Wrong For the Controller I don't thing you need to change dip switches from normal settings but I will check that.

Look in document xc3s50an_loader_v1.1.bit that is in the zip for the 1.1 update for the dip switch settings.

An update (Rev 1.2) to the controller is available on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html. I would not update your board to this unless you have a unit that is underperforming with the twin bitstream. As with all controller updates please be careful that you understand the instructions (Rev 1.1 update) fully before starting and ensure that your power is unlikely to be interrupted. If a controller update goes wrong it is likely that a programming cable will be necessary to perform a unit recovery but do take note of the first line recovery method if first attempt goes wrong another go is possible if unit remains powered.

We will do some more testing and work on the controller this week and there may be further updates.

Whatever revision 1.2+ we reach in the next few days will remain available to support 3rd party bitstream providers longterm but is then likely to be frozen when our own original bitstream becomes available. At this point the controller get a major update to Rev 2.0 signifying the major changes in functionality and all development will be on this branch.

One thing we have found is that a small percentage of the USB cables we supply have been faulty and may explain a few of the coms failures. We are changing our testing to include the cable that ships with the unit rather than assuming the externally supplied cable is ok. Some of you may have faulty USB cables and if possible you should try problem units with a different cable.

On USB hubs we just got a few USB hubs for our test setup and also so that we can start to put together a recommended list. Some of the cheaper ones do have an inadequate power supply e.g. 1A for 10 ports. However one that we do have http://www.ebuyer.com/123772-d-link-dub-h7-usb2-0-7-port-hub-dub-h7-b looks very good on paper and I will update you on real use of this particular hub when we do some testing.

On a totally different point how are you guys finding the cooling system performance? We are interested in feedback on that as well.

Can you send as much information into the bitcoin support email so that everyone relevant gets to see the problem. Outside what's already been mentioned on the forum, and thanks to all that have already forwarded into our support, we have not had any reports like this come in. So as yet we don't have a big statistical base to work on. We also haven't had a faulty unit arrive back to us yet to analyse. One I think is on it's way. So bear with us for a few days whilst we get enough information to give us a clue where to look. Probably the first thing to do is to try and create a model setup as similar to Zefir's as we can. We do think there is more than one aspect here and elements of software and firmware are probably the main place to look. However we can't rule out a hardware failure so that also needs to be part of the analysis. From what we have seen here on the line USB failures are very low and all down real identifable things like solder shorts.

Email isn't a perfect system.

There are a few reports like that and we will try and investigate them. We have a couple of theories to look at but we will have to pull personnel off the new stuff to do that so it's a compromise of when we do that looking. We think there is a good chance a lot of this type of problem will simple dissappear with the next major releases of bitstreams and associated items.

I think there was a post earlier in the thread that mentioned a CGminer issue a bit like this but I am struggling to find that again.

Are you running the correct version of CGminer?

When you flashed the units dip you have the dip switches in the correct position for flashing and then afterwards set them to running position for the twin bitstream?

[/quote]

Reflashing does not appear to of have worked, neither has moving the board to it's own usb3-port. Im starting to wonder if I have a defective one. it's pushing one tenth of the shares of the other cores atm. When tested individually at a regular pool after the re-flash it kept jammering about the pool not providing work fast enough (my gpu miners report nothing of such at the same time at the same pool). On p2pool it appeared to work for some reason, so Im guessing the rapid longpolls have something to do with this. The board reported in at 365MH/s on the 10 minute mark at p2pool.

I am now going to double check this by pointing all 3 boards to p2pool in the same worker... and if that reveals nothing then Im propably going to see how they behave in induvidual cgminer instances, does anyone have experience of running multiple cgminer copy's on the same system ?

[/quote]

What ia your board serial number and what environment that you are working in?

If I have made the correct association you should have had an email on the 23rd of June. I will forward it again to you.