Cairnsmore1 - Quad XC6SLX150 Board

[zefir]

28 port powered USB hub.
http://www.amazon.com/exec/obidos/ASIN/B0074024XU/downandoutint-20

... currently not available at Amazon. Plus need to get it to Switzerland -> ~2 weeks delivery time Best deal here would be to go to a local store and buy 8x7-port hubs for ~35$ each.

Sad thing is, I prepared the up/down cables already and hoped to bring up all boards to life tomorrow without wasting money for the USB hubs - but thats life...

[1713566475]

1713566475

[Isokivi]

190M_V3.bit is running @ 401Mh/s  (1 hour average) on p2pool stats, so far so good.

I will post an update tomorrow.

Im about to get my boards later this week and it seems like your the who's reporting in with best numbers. Could you please specify what bitstream you are runnin running with what miner and what versions ?

Thank you in advance.

[zefir]

Short update (before I'm done for today): got three boards (serial# 126-128) programmed with the V3 bitstream (with eberon's howto) up and running. After around an hour the average hashrate reported by the pool is 1150 MHps, which is quite in line with 380 per board.

One important thing (lost track in the thread, might already been mentioned): do not run cgminer with automatic Icarus detection or with the script proposed by xiangfu to run all available FPGAs. Instead, do a dry run first to see which ttyUSB ports are assigned to the malfunction FPGAs (with Linux it depends on the order of how they are plugged into the hub) and then run cgminer with only the valid ttyUSB ports as parameters. Giving all ports to cgminer confuses some processing, i.e. the faulty ones get disabled but the scheduling is also messed up with the FPGAs idling most of the time.


Good night.

[kano]

... and if you add a "-S noauto" then that ensures it never does auto detection

[daemonic]

I have found MY problem

I don't know if it fixes your's also.

FIRST: Turn off the unit! Set the dip switches to the shipping configuration!
If you turn on the unit with other dip settings, the unit will not work! It will not work, no matter what you do.
Shipping configuration 50MHz:
SW1/6 all on
SW2 all on
SW3 134 on, 2 off
SW4 134 on, 2 off
SW5 all on

Keep in mind, every time you need to turn off your unit, you need to redo the dip switches to the shipping config BEFOR you turn on the unit!

1. Turn on the unit and wait until all led's turn orange. Then plug in the USB.
2. Then start up the VM (the VM automaticly takes the unit, that's really anoying). If it does not, connect it to the VM.
3. Now SW1 3 off! SW3/4 12 off, 34 on!
4. Then programm it, i think everyone knows how to do that with all that testing  
5. No change to the switches and disconnect it from the VM.
6. Turn off the VM now. Not the unit!    ...Please do that! The bump VM retakes the unit sometimes.
7. SW1 3 on.
8. SW6 1 off.
9. Start cgminer 2.4.3 with the COM-Ports your unit works.
10. cgminer show you some Mh/s, but U=0.0

Now you are at the point your were often the last day's. The unit will not hash...

But, now i find out there is a problem with the SW6 1. Donno if that is software or hardware related.

11. Just switch the SW6 1 on, and again off.
12. Wait some seconds/minutes.
13. One fpga(0) should now do something, if not repeat point 11. Take a look on the LED, the orange should go off. If it keeps getting on after a second, repeat point 11.
14. Now one fpga is working, repeat point 11. until you see the orange led from the second fpga(3) turn off.
15. Now it should work with both fpga's, but the second one is instable and don't provide hashes like the first fpga.

Please try that, it works for me now on every attempt. I hope it works for someone else too  

Are you using the same process still for the 190M_V3.bit bitstream? I can get to the step 9 and all i get is the good old "got 0000000 expecting 000187a2" error

[Doff]

The twin test is more or less a standard Icarus build. I think the ID and maybe the DCM settings were changed but that was about it.

Ok, then it's based on the 190M_V4.bit. 190M_V3.bit and less is 100% different when i make a binary compare to the twin_test.bit.
But then that's the problem with twin_test.bit. It will stop working after some time. It is not droping it will complete stop working.

50 minutes so far on the 190M_V3.bit without invalids and pool stat is still rising the Mh/s. 386Mh/s/10 minutes so far.   (fingers crossed!)

Eb when you did this did you use the twin_test.bit programing switches?

I followed what you did Ebereon I'm still unable to get hashing at over 100, I did have 1 ICA hashing for a few minutes but they always die after a little bit. I also tried the 190M_V3 bitstream but was unsuccessful on that as well.

I can program it now in Linux witch makes me happy, Thanks Zefir, and Spiccoli.

[kano]

...
Are you using the same process still for the 190M_V3.bit bitstream? I can get to the step 9 and all i get is the good old "got 0000000 expecting 000187a2" error

... and just in case anyone was wondering what exactly that error means:

An icarus is detected by sending it work and getting a reply (there is no other command you can send to it and no ACK other than a random 4 byte nonce reply)

So the code sends some work that has the expected nonce answer of 0x000187a2 (or 0xa2870100)
I searched the blockchain for a low value and the lowest I found in the small search I did was: Ozcoin block 171874
(which is certainly low enough)

For a normal Icarus this takes ~0.53ms ((0x000187a2 / 2^31) * ~11.3)
The code waits up to 100ms for the reply and then effectively returns 0

So the error means either of:
1) The work didn't get to the FPGA or the FPGA couldn't return the answer (due to some FPGA configuration settings/bitstream issue)
2) The FPGA took more than 100ms to find the nonce (EXTREMELY unlikely)

But in both cases, yes there is no point trying to mine on it:
1) It doesn't work
2) It will be mining at less than 2MH/s

Just an FYI in case anyone was wondering

[spiccioli]

rjk,

here the image of the boards, on the left serial nr 62-008 and on the right, 62-104 with its military green hue



By the way, if someone needs it (and trusts my build) here it is cgminer 2.4.3 built as a 32 bit linux program without OpenCL/ADL and with icarus support only.

http://p2pool.soon.it/cgminer/cgminer-2.4.3

Download it, issue a

Code:

chmod 755 cgminer-2.4.3

to make it executable and it's ready to go.

Given that it is easy to build one, I'll remove it in a few days.

spiccioli

[ebereon]

Eb when you did this did you use the twin_test.bit programing switches?

I followed what you did Ebereon I'm still unable to get hashing at over 100, I did have 1 ICA hashing for a few minutes but they always die after a little bit. I also tried the 190M_V3 bitstream but was unsuccessful on that as well.

In most cases when it will not work is the frequency/noise problem. See my post here -> https://bitcointalk.org/index.php?topic=78239.msg992167#msg992167

I use the programming switches for the shipping bitstream. But i got it also work with the switch settings for the twin_test.bit.

190M_V3.bit is running @ 401Mh/s  (1 hour average) on p2pool stats, so far so good.

I will post an update tomorrow.

Im about to get my boards later this week and it seems like your the who's reporting in with best numbers. Could you please specify what bitstream you are runnin running with what miner and what versions ?

Thank you in advance.

I use:
Original Icarus bitstream "190M_V3.bit"
MPBM latest git with some changes on Win7 32bit
Worker setting in MPBM 115200 baud, jobinterval 11.34

Standard unit switch settings:
SW1 1234 on
SW6 1 off, 234 on
SW2 1234 on
SW3 2 off, 134 on
SW4 2 off, 134 on
SW5 1234 on

Programming switch settings:
SW1 3 off, 124 on
SW6 1234 on
SW2 - SW5 same as Standard

I can programm only in the temporary mode, if i turn off the unit then it have the shipping bitstream again.

I hope this helps a bit 

greets,
eb

[spiccioli]

ebereon,

did you try the 200MH/s bitstream available for icarus?

https://github.com/ngzhang/Icarus/tree/master/Downloads/bitsteam/200MHz_for_test

spiccioli

[ebereon]

ebereon,

did you try the 200MH/s bitstream available for icarus?

https://github.com/ngzhang/Icarus/tree/master/Downloads/bitsteam/200MHz_for_test

spiccioli

yes, works with huge invalids.

At the moment also the 190M_V3.bit have invalids, i think we can't do anything, it's the Frequency/noise problem and it looks like after some hours hashing it gets more and more invalids. I'm off now for work i will report my hashing rate later today.

[rjk]

rjk,

here the image of the boards, on the left serial nr 62-008 and on the right, 62-104 with its military green hue

http://p2pool.soon.it/cgminer/cm1.jpg

Cool!

[gyverlb]

Serials 110 and 111 delivered today. They are now hashing for more than 2 hours with twin_test.bit at a total of ~770MH/s as reported by Ozcoin.

Couldn't store the bitstream in flash with xc3sprog "-I" parameter though
This is the same problem than the one reported here by others ("ISF Bitfile probably not loaded").

Hope the rig remains stable...

[testconpastas2]

Well now i have all my boards. only opened one, and using your advices could hash with shipping bitstream (and twin_test).

I (temporaly) programed 0 and 3 fpgas but couldn't permanent program them.  anyone with permanent programming has a piece of advice?



I`ve used "--icarus-timing short" and speed's still weird




looking forward your  ribbon cables support.

[mrb]

We did look at putting in the 4x2 PCIE as well but could not find the part number for the special keying it has and the Molex website doesn't help very much.

This is the Molex 45586 series, which should be available here: http://www.molex.com/molex/products/crawllistview.jsp?query=45586&npp=20&sType=s&fs=&channel=Products
But for some reason it returns 0 results on molex.com...

Edit: Apparently the 8-pin PCIe power connector is a trade secret; that would be why it appears impossible to source outside of the group of PCI-SIG members: http://www.electro-tech-online.com/datasheets-manuals-parts/103572-pcie-8-pin-header-part-number-2.html#post896634
Quite unbelievable for such a simple stupid part...

[rjk]

We did look at putting in the 4x2 PCIE as well but could not find the part number for the special keying it has and the Molex website doesn't help very much.

This is the Molex 45586 series, which should be available here: http://www.molex.com/molex/products/crawllistview.jsp?query=45586&npp=20&sType=s&fs=&channel=Products
But for some reason it returns 0 results on molex.com...

Looks like Mouser has them, and when I click the datasheet link on Mouser's page, it brings me here on Molex's werbsite: http://www.molex.com/molex/products/datasheet.jsp?part=active/0455860004_MOLEX_PARTS.xml which looks like the right part.

EDIT: PDF datasheet here: http://www.molex.com/pdm_docs/sd/455860004_sd.pdf

[rjk]

Actually, I think the 45586 has the wrong keying, but the 50-36-1744 looks like it might work? The PDF shows a 10-pin version, but I can't tell what the keying is on the 8-pin version.

[mrb]

rjk: nope. This 45586 part (there are many of them) and the other do not have the plastic bridge between pins 7-8, and (as you pointed out) do not appear to have the right keying which should be:

  LL
RRSS
SRRR

L = Latch
R = Round
S = Square

[rjk]

rjk: nope. This 45586 part (there are many of them) and the other do not have the plastic bridge between pins 7-8, and (as you pointed out) do not appear to have the right keying which should be:

  LL
RRSS
SRRR

L = Latch
R = Round
S = Square

Sorry my bad! I got mixed up between 8-pin PCIe and EPS12V. The thing is, the additional 2 pins on a PCIe 8-pin connector are unnecessary - they are just signals connected to ground and do not carry current.

EPS12V goes like this:

 LL
RSSR
SRRS

[yohan]

We did look at putting in the 4x2 PCIE as well but could not find the part number for the special keying it has and the Molex website doesn't help very much.

This is the Molex 45586 series, which should be available here: http://www.molex.com/molex/products/crawllistview.jsp?query=45586&npp=20&sType=s&fs=&channel=Products
But for some reason it returns 0 results on molex.com...

Edit: Apparently the 8-pin PCIe power connector is a trade secret; that would be why it appears impossible to source outside of the group of PCI-SIG members: http://www.electro-tech-online.com/datasheets-manuals-parts/103572-pcie-8-pin-header-part-number-2.html#post896634
Quite unbelievable for such a simple stupid part...

It doesn't surprise me that PCIsig would try and keep a secret of this. It's a very greedy organisation. The amount they charge just for a PCIe spec is enormous. However I would not be surprised if there isn't a Chinese clone available somewhere out there. It's the identifying and getting hold of the parts that is the biggest issue.

On a side note we are looking at the emails send to the new support email and we will try and make a proper response on these before too long. Please bear with us on this we aren't doing *** style response here and deliberately ignoring you all but at the moment our main focus is the new design bitstream which is now getting more time and resource to bring that into shape. Once we have the first version of that the up/down function won't be far behind and the Cairnsmore1 design will start to show what we think it is really capable of doing.