Cairnsmore1 - Quad XC6SLX150 Board

[yohan]

Anything we can do in Cairnsmore1 can be done better in Cairnsmore2 where we have more technology to play with.

Any hints on what's up for specs?

There are many variables still be tied down and I also don't want to give too much away to the competition but it might be interesting. There is more that one unique idea floating round the development team and I'm not going to promise anything we have not got fully working yet. You are going to have to faith with us to deliver the interesting bit. There are many barely documented features of FPGAs that even most people designing daily with FPGAs simply don't know about and that's about all I will say for the moment.

[gyverlb]

I can confirm that the twin configuration works reliably (at least for 30hours straight on my 2 boards).

Argh: it failed on at least one of the two boards after around 48h.

cgminer marked all FPGAs OFF and on restart could only find 2 of the 4 (this is why I think only one board failed). I didn't think of checking if the USB tty where still available (/dev/ttyUSB*).

Anyway: powered down the 2 boards and reinstalled the twin_test bitstream according to the documented procedure one board at a time and it works again on the 4 FPGAs (out of 8 ).

[Doff]

Yohan, could you please clarify what you mean with 'you should be able to do that now (i.e. writing to SPI)'? As said above, right now no one successfully wrote to the SPI flash and it is really a PITA to reprogram all devices non persistently again when one of them crashed and need to be powered fully down (you do not know which one is the problematic one and need to turn off all of them).

So either it is possible with the current controller programming, then could you please provide a detailed step-by-step instruction. Or it is not doable over USB but needs to be done via JTAG.

Either way it would be very helpful to flash the Icarus bitstream into SPI until your dedicated one is ready. Any clarification is highly appreciated.

Thanks.

Yes I think all of this is currently possible and I will double check that this morning that I am not talking crap in any shape or form. We use these processes on our lines already. The load of the 4 array SPI Flash does take over 30 minutes so it does need patience to do. We do a 5-10 boards together here to stop it becoming a line blocker.

I will also see if we can somehow streamline the instructions.

I too would prefer working instructions for flashing to the SPI for the twin_test bitstream.

Personally I would prefer this now as opposed to getting the working bitstream a day earlier so then atleast I can run the twin_test bitstream without going through reflashing it every day.

I would be happy to give enterpoint an interest free loan if they could beat BFl to it.

Who's with me?

I'm not giving anyone an interest free loan.

Id rather they just focus on their bitstream or even release an early version that can hash at 300+, Ive tried for hours to get the twin, or 190_v3 working and it just wont do it on my board. I did get it working again with the shipping_test bitstream so at least I'm getting 110 hash.

[norulezapply]

Yohan, could you please clarify what you mean with 'you should be able to do that now (i.e. writing to SPI)'? As said above, right now no one successfully wrote to the SPI flash and it is really a PITA to reprogram all devices non persistently again when one of them crashed and need to be powered fully down (you do not know which one is the problematic one and need to turn off all of them).

So either it is possible with the current controller programming, then could you please provide a detailed step-by-step instruction. Or it is not doable over USB but needs to be done via JTAG.

Either way it would be very helpful to flash the Icarus bitstream into SPI until your dedicated one is ready. Any clarification is highly appreciated.

Thanks.

Yes I think all of this is currently possible and I will double check that this morning that I am not talking crap in any shape or form. We use these processes on our lines already. The load of the 4 array SPI Flash does take over 30 minutes so it does need patience to do. We do a 5-10 boards together here to stop it becoming a line blocker.

I will also see if we can somehow streamline the instructions.

I too would prefer working instructions for flashing to the SPI for the twin_test bitstream.

Personally I would prefer this now as opposed to getting the working bitstream a day earlier so then atleast I can run the twin_test bitstream without going through reflashing it every day.

I would be happy to give enterpoint an interest free loan if they could beat BFl to it.

Who's with me?

I'm not giving anyone an interest free loan.

Id rather they just focus on their bitstream or even release an early version that can hash at 300+, Ive tried for hours to get the twin, or 190_v3 working and it just wont do it on my board. I did get it working again with the shipping_test bitstream so at least I'm getting 110 hash.

Problem is that might be quite far off yet, but I'm just speculating of course. That's why I'd rather have the twin_test flashed to SPI because I'm having problems running twin_test normally also. It's just sat turned off at the minute waiting for updates.

[ebereon]

I'm tired of testing now.

18 days of testing to get the unit hashing faster, but no success here.

What I tested:
PC:
1 netbook 1666MHz Intel Atom 1GB ram Win7 32
1 notebook 1800MHz AMD something 2 GB ram Win7 32
1 notebook workstation Intel I7 2720 8GB ram Win7 x64

Checked energie options for USB Ports etc.
Tested with powered USB Hub (Logilink 10 Port) and without.

SW:
cgminer 2.4.3 (115200 baud)
cgminer ep version (57600 baud)
mpbm (115200 and 57600 baud)

Bitstreams:
shipping = 60Mh/s/week (120Mh/s/hour max)
twin_test = 60Mh/s/day (386Mh/s/hour max)
190M_V4 = same as twin_test
190M_V3 = 120Mh/s/day (401Mh/s/hour max)
200beta = 5Mh/s/day (280Mh/s/hour max)

Every bitstream is hashing 1 minute and up to 14 hours at nice rates, but after this I get many invalids (>80%) and the unit will stop working correctly, 0Mh for about 3 hours then again some shares and so on.

I'm really upset at the moment, I invested ~6 hours a day 18 days long to test things, I thougth I was doing something wrong and tested every switch settings I know. The answere from enterpoint that there is a frequency/noise problem did't help me futher. And they said that they "think" to work around the problem with their bitstream scares me too. Hardware problem?

Today I did my last test and after that, the cairnsmore1 has learned to fly from one corner to the other in my room, god thanks it landed on the couch but jumped again up and fall down and dropped in the package in which it was delivered...  I think it will go back to home ..."E.T(P). phoning home"...  (someone knows that?)  

So this baby is now waiting in the package... I don't know what I should do now.


@yohan: any news or piece of software we can play with?



EDIT:
Tested PSU:
ATX 1000W
And a 60W switching psu with phoenix connector

Cables:
5 different USB cables

[spiccioli]

I'm tired of testing now.

18 days of testing to get the unit hashing faster, but no success here.

Ebereon,

while I can feel you're tired and I don't have definitive answers, I'd like to add some thoughts.

Am I right that you are on p2pool?

See this, three boards, serial: 8, 104, 136

Code:

cgminer version 2.4.3 - Started: [2012-06-27 21:01:05]
--------------------------------------------------------------------------------
 (5s):2492.7 (avg):2080.6 Mh/s | Q:116837  A:42219  R:381  HW:0  E:36%  U:14.5/m
 TQ: 6  ST: 7  SS: 225  DW: 7010  NB: 278  LW: 14068  GF: 226  RF: 272
 Connected to http://pool.abcpool.co with LP as xxxxxxxxxxx
 Block: 00000167d598249e60d7faab8784a2c8...  Started: [21:22:44]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 379.9/346.6Mh/s | A:7188 R:63 HW:0 U: 2.47/m
 ICA 1:                | 379.8/346.7Mh/s | A:6279 R:57 HW:0 U: 2.16/m
 ICA 2:                | 379.9/346.8Mh/s | A:7242 R:68 HW:0 U: 2.49/m
 ICA 3:                | 379.8/346.8Mh/s | A:7144 R:56 HW:0 U: 2.45/m
 ICA 4:                | 379.9/346.8Mh/s | A:7227 R:61 HW:0 U: 2.48/m
 ICA 5:                | 379.6/347.0Mh/s | A:7140 R:76 HW:0 U: 2.45/m
--------------------------------------------------------------------------------

on ABC.

Can you try/did you try a different pool?

Maybe the fast p2pool chain creates some problem which I don't seem to have.

Maybe it's just me that was lucky with the cards... I don't know, I see that ICA1: is slower than the others, this is FPGA3 on serial nr. 8, but sometimes it is ICA0: which is slower but it never slowed down (up until now, at least) to a few MH/s.

And I don't have any icarus-timing thing in my command line which is:

Code:

./cgminer -S /dev/ttyUSB2 -S /dev/ttyUSB3 -S /dev/ttyUSB5 -S /dev/ttyUSB6 -S /dev/ttyUSB8 -S /dev/ttyUSB9 -o http://pool.abcpool.co -O  x:y -o http://p2pool.soon.it:9332 -O w:z -Q 7 --failover-only

I have p2pool as failover pool, but it was used just a little today in the early morning, CET time, while ABC was having problems.

I'm powering them through PCIe connectors from a 500W Antec ATX PSU and on board 8 I did not reprogram the spartan 3.

spiccioli.

ps. I'm also waiting for something that makes it possible to use all FPGAs on each board, though.

[yohan]

@yohan: any news or piece of software we can play with?

Ok nothing too exciting today. The Power Distribution Boards PCBs arrived today and we part built one of them and tested the ATX turn on function and that all worked as we expected. We are going to fit one of the switch positions with a header so a semi-remote switch can be used to turn on the stack. There will be a local switch as well. We will do a full board build up on Monday when the Pheonix connectors arrive and we should have some available to ship Tuesday or Wednesday next week.

Bitstream moved another notch closer but nothing out of the ordinary there. The first release isn't far away. I believe we are talking days now but as this is very hard to predict I won't totally promise that.

On the programming today was busy and I have not managed to go through that process yet. However I have a board with me to test in the relative peace of my home office. I will attempt the programming of a board using Win7/64 machine as the host to start with following the instruction you all have to work with. From that I will see how I do and hopefully identify things that are not totally clear and what we might do better. We do have a couple of further development activities planned to improve the programming but that will be after we get the first bitstream going.

[Coinoisseur]

I'm interested in the product but how are you able to quality test the FPGAs if you don't have a bitstream yet? Do you have a web page that spells out the warranty info (who pays what, shipping, warranty duration etc.)?

[ebereon]

hmm, I can't let my fingers from it...  

I found the problem with flashing the bitstream to the SPI flash:


There is no blank betwen "-I" and the filename "xc6lx150.bit". I try now this, hope it works better when the unit is starting with the bitstream already loaded.

Edit:
When it's done it should look like this:


Wait until you see "Verify: Success". It takes 7:40 minutes per fpga!

[Doff]

hmm, I can't let my fingers from it...  

I found the problem with flashing the bitstream to the SPI flash:


There is no blank betwen "-I" and the filename "xc6lx150.bit". I try now this, hope it works better when the unit is starting with the bitstream already loaded.

Edit:
When it's done it should look like this:


Wait until you see "Verify: Success". It takes 7:40 minutes per fpga!

Nice, seems like an easy enough fix. Hope it works out for you ebereon.

[Keninishna]

hmm, I can't let my fingers from it...  

I found the problem with flashing the bitstream to the SPI flash:


There is no blank betwen "-I" and the filename "xc6lx150.bit". I try now this, hope it works better when the unit is starting with the bitstream already loaded.

Edit:
When it's done it should look like this:


Wait until you see "Verify: Success". It takes 7:40 minutes per fpga!

What an odd bug... I'll have to give this a try on my board when I get home. I'm guessing this will load the SPI with the twin_flash.bit? So it won't need to be reprogrammed everytime I power off.

[ebereon]

... I'm guessing this will load the SPI with the twin_flash.bit? So it won't need to be reprogrammed everytime I power off.

Yep! And it's working 

[testconpastas2]

Ebereon you are great.  here 2:24 am and just finished my first fpga of 12 boards.

all night awake!!!! thanks  man

[ebereon]

If you want to flash both with one command, just do:

Code:

xc3sprog -c cm1 -p 0 -Ixc6lx150.bit twin_test.bit && xc3sprog -c cm1 -p 3 -Ixc6lx150.bit twin_test.bit

This will flash the first (0) and if it was ok, then the last one (3). And that takes ~16 minutes to finnish, just take a cup of coffee  

[ebereon]

...  here 2:24 am ...

Same here 

[testconpastas2]

thanks I'll do it.  with this persistent way at least we'll be able of  reseting in a fast way when any fpga become disabled.

[gyverlb]

The -I no space trick is ... working!

This was the only thing that really prevented me to move the rig I use for the boards to the basement. No if there's a problem, in the worst case I can simply cut the power, wait a couple of seconds and restore the power and everything is back again mining.

Ok ebereon give us an address for donations.

[ebereon]

Nice to see it's working for others too 

1KWGtSxo5b52Adk3Pvw14E3o9kp96JZJm2 

[daemonic]

well done ebereon, ill sort another donation when im at my wallet machine

did you stick to the twin_test.bit or go with the 190M_V3.bit bitstream for the SPI

and proof for the -I<bitstream.bit> is in the man page (http://xc3sprog.sourceforge.net/manpage.php) d'oh

[testconpastas2]

please take my coffee invitation


Thankyou again