Which FPGA pair is the right for the Icarus bitstream? P 0 and P 1?
What happens when I flash the wrong pair? Is there a risk for the FPGA IO Cells due the crossed TX/RX? Does the right DIP switch setting disconnect the net between the FPGA pairs?
Is there a block diagram which shows the position of FPGA correlating to p X
There is a new bitstream from ET, seems no connection between devices are required, every FPGA is handled as own hashing device.
When I flash the “"david”" bitstream (included in the jar file) via xc3sprog tool, am I able to use his java tool to mine? What would be the correct setting for the DIP switches?
Thx Hpman
P0 and P3 are the ones for the twin. If dip switches are set as recommended then P1, P2 are held in reset. That avoids any problems if you make sure on those dip switches. The positions go clockwise from the top left (cables to left side). No problems if flash the wrong parts you just won't get the expected peformance. The ET bitstream we have not worked with as yet so no advice we can give there as yet. We can support individual FPGAs but that might need a Controller update. |
|
|
|
|
Advance Warning
There are 1 or 2 people on our June delivery promise who have not responded to the notification that their unit is ready. We can only speculate why that might be but we do need to release reserved stock from our pending shelves in order to satisfy our general customer demand for more units and as fast as we can deliver. So some time later next week we be doing an order purge for anyone on a June delivery promise who has not responded, and that means orders will be cancelled from our side and you will lose your right to the offer price and your place in the queue.
We will do something similar in a few weeks time for July promise orders and so on until we eventually reach the point where Cairnsmore1 is a stock board with no pre-order structure.
Yohan
|
|
|
|
Just a guess, may you forgot to flash one FPGA with the twin_test bitstream and it is still the old shipping_test ? If im right perhaps you can detect the board when you check the LED activity when a share was found. Should be flash green when twin_test and red for shipping_test
xc3sprog –c cm1 –p 0 –Ixc6lx150.bit twin_test.bit <return>
xc3sprog –c cm1 –p 1 –Ixc6lx150.bit twin_test.bit <return>
xc3sprog –c cm1 –p 2 –Ixc6lx150.bit twin_test.bit <return>
xc3sprog –c cm1 –p 3 –Ixc6lx150.bit twin_test.bit <return>
My assumption is that every FPGA has its own flash and that needs to program. Unless there are any useful documentation about architecture etc. its all only a guess.
I assumed that for the twin-test it is enough to flash FPGAs 0 and 3, since the other two are not operational in that mode. Any indication that this might cause problems? No problems just doing the 2. |
|
|
|
|
Ok, I will try this a bit later, once I figure out which board it is, Would you care to comment on why the boards only work in usb3 ports for me ?
[/quote]
We have seen it the other way with USB3 being a problem in Linux systems and we think that is a driver issue. However I do need to check this but I think USB3 ports can have a much higher current specification. That might be the difference especially as you have an unpowered hub.
|
|
|
|
What do you think my issue here is:
3 Cairnsmores plugged in at an unpowered usb hub, all running the twintest bitstream and enterpoints cgminer for it. Windows seven, quad core, plenty of ram (it's a gaming pc).
5 first cores are pushing shares as is to be expected (0-4) But CM5 is doing less than a third of the shares of the other cores, with 0 rejects showing up at cgminer, whereas the other cores have a normal invalid rate (6-16 invalids at aroud 3300 shares hashed per core).
Im starting cgminer with the command: cgminer_twintest -o mint.bitminter.com:8332 -u ME -p MAHPASS --disable-gpu -S noauto -S\\.\COM22 -S \\.\COM23 -S \\.\COM26 -S \\.\COM27 -S \\.\COM30 -S \\.\COM31
If some relevant info is missing please just ask me.
As an experiment try taking out one or two of the board returning good results and see if that changes anything. Unpowered hubs do have some problems as any current taken will multiply up with the number of boards. It doesn't take much to overload an unpowered hub. Powered hubs are definately better and I would suggest this as a good thing to use for the short term One other general issue with USB is that the way it timeslots data can mean that the USB can run out bandwidth on relatively low bandwidth applications e.g. serial coms with a relatively small number of boards. I would be surprised if 5 boards caused this issue but I am not an expert in USB protocol so I can't be more specific. It can be worth spreading your boards aroung your PCs ports. This isn't always a solution as an occasional PC has an internal hub for multiple ports which only actually has one USB controller but for most PCs this is a good way forward. Once we get the up/down function sorted out these potential USB problems should more or less dissappear. |
|
|
|
I know there are not too much free space on the PDB but what about adding in future versions 3 or 6 independant power switch ( one per pci-e o per 2 pci-e) so you dont need to turn off the full array, if you have any problem.
We can put individual boards into standby and turn off various power supplies all potentially on the up/down structure so there isn't much mileage adding a lot of parts and complexity to the PDB. If anything I'd like to have current measurement so we could detect problems.Any chance of making some power boards with screw connectors instead of the phoenix ones? You'd have a much wider audience and sell many more.
[/b] Pheonix mating halves come with screw terminals. In fact there are a choice of the these and that was one of the reasons for us using this series. It's easy to make wiring looms without special tools. This also allows custom harnesses to suit individual rigs.
@Enterpoint Team & yohan: Today i almost made world first in accidently destroying a cairnsmore1 board by putting in a wrong atx power supply cable (yeah call me stupid - i deserve it). Seconds after i realized that some black smoke raised into the air over the board, i shut down the power supply. When i took a closer look at the accident i realized that i just bought the worlds best fpga board for bitcoin mining available because all i had to do is put in a non-broken fuse from another cairnsmore1 board. It works perfectly again. WOW - just awesome! Thanks for bringing in the fuse into the design - that really safed me a board  I'll contact your sales - maybe you can supply me with a new fuse.
yohan, any news on updated FPGA firmware able to use all four FPGAs per board? My boards are hashing nicely but those red/yellow leds always on (and which remind me the Spanish flag  ) make me feel a little sad spiccioli It's still moving forward. It's a piece of string task to a certain extent and until it is finished it's not. There isn't anything in the middle.
|
|
|
|
Yohan. How much the pheonix cables?? any photo of side fans setup?
We are behind on acquiring the side blow brackets. Basicaslly we need to find a little metal shop to do that for us. So no side blow fan pictures as yet. Once we find the right place it shouldn't take long to have some available. I am hoping to have a picture of PDB with a stack and showing the wiring via the Pheonix connectors soon. Probably not today but maybe tomorrow now. We have all the parts and just need 30-60 mins to work out cable lengths etc. and make the looms up. The plan is to offer something like 3-6 standard option looms where the each loom has 3 heads to power 3 boards. Price for one of these standard looms is GBP £20 / USD $32 / 26€ + tax each. We can also offer custom looms as well. Most of the cost is the connectors and labour to put them together so a bit extra length does not make much difference in materials cost. |
|
|
|
|
At the moment it's Henry Ford time and you can have any colour you want as long as it is green. We do have a military green version as well as the bright green. Our 2nd batch of PDB bare boards arrived today and they are close to the colour of the later Cairnsmore1 boards.
|
|
|
|
Power Distribution Board for Cairnsmore1 is now available. Price is GBP £62 / USD $100 / 81€ + tax (if applies).
 Local switch to turn it on but also a 3 pin header allows a semi-remote switch as well or other electronic control. How much power and boards it can handle is very dependent on the ATX power supply you pair it with but as a general recommendation 3 boards per PCIE input is a good balance of what is practical sensible level. More will be possible in some cases but you do need to check your PSU spec and cabling for what is possible. Each Pheonix header (Green connector) is rated 10-12A per contact depending on mating half so 20-24A per connector is possible subject to the PCIE limitations. That's good for 4 Cairnsmore1 boards so we anticipate that most people will only use the outer connector run and none of the inner connectors. The 3 Pheonix headers are available per PCIE input to make different wiring structures easy not necessarily as an indication of how many boards a PCIE can feed. We have also done this to make this product useful in other applications.
|
|
|
|
|
We found out why a few of you were having problems with DLLs missing on our version of CGminer. It's because we forgot to include them in the zip file. That's now fixed and updated on the support webpage.
Long term webpages are now up but temporary ones will remain for a while yet as they are faster to update.
|
|
|
|
|
yohan,
I'd say powered usb hubs are a must, I cannot attach more than three boards to my pc if not through a powered usb hub (if I try all kind of problems happen to the point that the whole pc freezes - btw, it's not a PC but an HP thin client, this could be part of my problem).
How much power (max power) does the board take from the usb port?
spiccioli.
[/quote]
Ok the running power of the controller part does vary with the clock generator setup and the build in there but generally it is about 40-80mA from what I have seen. The on-board regulator will take it from the 12V if available. We don't think this running power is an issue. It's the initial surge that might be when we plug in the USB and 12V isn't up. It's also possible that there could be current spikes when running e.g. when the controller configures and maybe in a few other occasions.
To a degree this problem will probably go away when we move to supporting the up/down structure with a resultant more limited USB usage. That said we will do more investigative work to establish a more exact cause as that is good engineering practise to at least understand that much.
I am reading through some of the other posts (i'm still doing that) and I agree the thread is getting a lot of take in but when we move from the temporary setup it will start to get better albeit probably after a slightly worse period as we transition. Documentation and other things should get a lot better post bitstream release as we swing more resources into that side of thimgs and stuff stops changing significantly every day.
|
|
|
|
|
Ok a couple of things we have observed partially from all your comments and things we have see here:
First thing is on Linux machines there may be a problem with USB3 ports. We think that might be a Linux driver problem.
Powering up the 12V supply to your Cairnsmore1 before plugging in USB may help as will a reasonable power USB hub. We think there is an inital surge that in some PCs upsets the host controller. With the 12V powered first the on-board regulator supplies the power rather than a big impluse demand on the USB. A powered USB hub shields the host from the main part of the inital surge which is why it helps. Power hubs can have different rating but if sepcs are available go for one with 500mA capability, or better, on each port.
|
|
|
|
Hello,
Please tell me which FPGA pin is used for the primary clock input and what frequency that clock input runs at.
Please email me the answer; I don't read this thread.
@eldentyrell: thanks for taking a look in here @yohan: please give eldentyrell that information! Details sent. |
|
|
|
Pricing structure post a standard performance level bitstream is now published on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1.html. I will post here in this thread when the changeover happens. Anyone who has ordered already remains at the offer price even if delivery is later and is paid for July-September. The re-order offer remains in place until the end of September. For anyone that doesn't know about it you can order the same amount again July to September as what you have ordered and paid for under the current pre-order offer. This offer is closed now to new orders. Only orders already placed will benefit. |
|
|
|
I have just put what I think is the simplified instructions for Windows users to flash the Twin build into Cairnsmore1. It's linked on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html . I have not tested the flow yet of this document so there might be something I missed but I will test it on myself probably in the morning. If anyone using it spots anything let me know and I will update it accordingly. yohan, on page 11, of Virtual Box Installation Windows, there still is a space between -I and xc6lx150.bit. spiccioli It's sorted and I also changed the bistream filename to be correct as well. Changed font as well to make spaces more obvious. |
|
|
|
I have just put what I think is the simplified instructions for Windows users to flash the Twin build into Cairnsmore1. It's linked on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html . I have not tested the flow yet of this document so there might be something I missed but I will test it on myself probably in the morning. If anyone using it spots anything let me know and I will update it accordingly. |
|
|
|
Ok before programming the twin bitstream set dip switches as this picture. I would recomend programming the SPI flash as you can do power cycles etc without pain. It's just slow to do.
 Once it is verified ok set dip switches like this 
|
|
|
|
Ok at this point I'm just completely frustrated. I re-flashed the controller update just in case, then tried adding the twin test to SPI a few time, it works just fine. Then I go to mine and it finds one share and dies.
Only p0 works anyhow, p3 just errors out in Cgminer, so only 1 FPGA is even attempting to hash. Ive tried the switch 6 on and off trick and it does nothing for me unfortunately.
The question is how to I go back to the shipping_test.bit when I try to change it to load it to spi it errors out each time with verify failure.
Ok I think we should send you out another unit pre-loaded with the twin bitstream and latest controller for you to try and we will retest your existing unit. It's more likely to be a software issue than hardware but let's eliminate as much as we can by the hardware re-test. Wow, yes that would be great. I really wasn't angry with the Hardware, I was I guess more just frustrated that everyone else was having some success with the twin bitstream and mine well just doesn't seem to like it I'm sure its just software as well, but since I don't have the full picture I just don't know what else try. Do I need to resend any of my info to you for that, or are you all set? Thank you for the awesome customer service Yohan. You are nearly in Canada if I pulled up the right record. If I am wrong let me know. Hopefully we can get it there for Tuesday. But let's work out what the problem is. No point being frustrated if we can do something about it. It might be that you have a board that has a real fault. It is very unusual for one of our standard boards to fail in the field having been though one of our tests. I think it's about 2-3 boards in the last 9 years but it's still always a possibility. We are still at the stage of being bit of rough and ready in terms of documentation, software and bitstreams and we will do our best to get you all past that bit as fast as we can. Hopefully this coming week will see the next major step forward and we will meet at least some of the expectations out there. I am nearly finshed the document that will hopefully make this simplier for Windows users and that will have dip switch settings. 90% of that will still be useful to you as a Linux user so you could try and follow that. It some be available tonight or early tomorrow. I will have some more dip switch setting pictures that I am doing for that now and I will try and post those here shortly as a short term help. |
|
|
|
Ok at this point I'm just completely frustrated. I re-flashed the controller update just in case, then tried adding the twin test to SPI a few time, it works just fine. Then I go to mine and it finds one share and dies.
Only p0 works anyhow, p3 just errors out in Cgminer, so only 1 FPGA is even attempting to hash. Ive tried the switch 6 on and off trick and it does nothing for me unfortunately.
The question is how to I go back to the shipping_test.bit when I try to change it to load it to spi it errors out each time with verify failure.
Ok I think we should send you out another unit pre-loaded with the twin bitstream and latest controller for you to try and we will retest your existing unit. It's more likely to be a software issue than hardware but let's eliminate as much as we can by the hardware re-test. |
|
|
|
|
One little tip for people running Linux and programming is that we have found the xc3sprog is more stable running as a VM under the main Linux. There also seems to be a machine speed relationship as well. This all suggests that there might be software timing loops in xc3sprog and that is part of the problems some of you have.
On the Windows side I am about alter/create a set of instructions specifically for loading the SPI Flash with the twin design. These should be available later today. It's not really any new info but hopefuly it's in a better format to follow and maybe less chance to make a mistake.
|
|
|
|
|
Show Posts
