Cairnsmore1 - Quad XC6SLX150 Board

[testconpastas2]

Unfortunately Ive never run in to that problem and don't have the coding knowledge to help fix that bug, however I did test 2.6.0 and got the makomk 140 bitstream working for the last 5 hours and its very stable.

ICA 0:                | 346.4/346.9Mh/s | A:723 R:0 HW:0 U:  4.00/m
ICA 1:                | 344.3/348.3Mh/s | A:704 R:1 HW:0 U:  3.90/m

Great numbers.

Doff when you are using makomk's  they show up as two ICA , but how much COM's are they using 2? 1 per ica, 4?

i dont know if I have to add two -S (COMXX) or four

thank you.  

I'm thinking about moving into makomk's bitstream but I had some problems with 1.3 controller and  i dont know if I should wait till they launch a new controller.

[1714206736]

1714206736

[1714206736]

1714206736

[1714206736]

1714206736

[1714206736]

1714206736

[1714206736]

1714206736

[zefir]

Doff when you are using makomk's  they show up as two ICA , but how much COM's are they using 2? 1 per ica, 4?

i dont know if I have to add two -S (COMXX) or four

thank you.  

I'm thinking about moving into makomk's bitstream but I had some problems with 1.3 controller and  i dont know if I should wait till they launch a new controller.

Doff most probably is sleeping right now, so I'll take that.

You need to start makomk's bitstream (I confirm that the 140MH one works on all my boards that run twin_test flawlessly before) with two COM ports only (like you do for twin_test), since the board is treated as two Icarus combined. The only other thing you should take care when switching from twin_test to makomk's is to enable the two back FPGAs (see readme in the bitstream archive).

Good Luck!

[makomk]

OK, thanks to some minor tweaks I've managed to create a bitstream that does actually run properly at 160 MHash/s. You can download the new set of bitstreams from http://www.makomk.com/~aidan/shortfin_icarus_cm1_20120729.zip - instructions are the same as for the previous set. Might release a mildly overclocked 170 MHash/s bitstream next.

Also, donations to 1CCorPPK8X6Px5iNxCBc5Eciw81iZPVBPh are welcome. I was actually holding off on replying to eberon's comment asking me to post a public donation address until I had good news to report; it just took a bit longer than expected.

[ebereon]

Unfortunately Ive never run in to that problem and don't have the coding knowledge to help fix that bug, however I did test 2.6.0 and got the makomk 140 bitstream working for the last 5 hours and its very stable.

ICA 0:                | 346.4/346.9Mh/s | A:723 R:0 HW:0 U:  4.00/m
ICA 1:                | 344.3/348.3Mh/s | A:704 R:1 HW:0 U:  3.90/m

Great numbers.

Doff when you are using makomk's  they show up as two ICA , but how much COM's are they using 2? 1 per ica, 4?

i dont know if I have to add two -S (COMXX) or four

thank you.  

I'm thinking about moving into makomk's bitstream but I had some problems with 1.3 controller and  i dont know if I should wait till they launch a new controller.

Only 2 COM's as it uses the controller version 1.3. It's the same as the twin_test.bit but mining on 4 fpgas.

[ShadesOfMarble]

How many bitstreams are currently in development?

- Glasswalker is re-writing the Icarus-bitstream, main problem is JTAG noise and meeting the timing?!
- Which bitstream is makomk working on? According to the filename, also some kind of Icarus-rewrite?
- Is EP still working on a (from-scratch) bitstream or are they now waiting for Glasswalker to finish his work?
- Is anyone working on making the TML-bitstream fully compatible with CM1?

[ebereon]

How many bitstreams are currently in development?

- Glasswalker is re-writing the Icarus-bitstream, main problem is JTAG noise and meeting the timing?!    YES
- Which bitstream is makomk working on? According to the filename, also some kind of Icarus-rewrite?   YES
- Is EP still working on a (from-scratch) bitstream or are they now waiting for Glasswalker to finish his work?  Don't know, Yohan?
- Is anyone working on making the TML-bitstream fully compatible with CM1?  YES, chrisp is working on it

Red means, not working/stable.
Green means working, stable and fastest.

Results tested with my 10 boards SN# 400+

 

[Lethos]

I've got my 2 boards working nice and stable for 9 days now.
This is a massive improvement and all came from me moving over to Linux, Ubuntu to be exact.
It only runs of a usb thumb drive though, so I don't have much on there, unless it's really needed.

I am tempted to try the newer bitstreams, is using [virtualbox] programming tools the easiest option even though I am already on linux, or is their another way?

[testconpastas2]

Doff when you are using makomk's  they show up as two ICA , but how much COM's are they using 2? 1 per ica, 4?

i dont know if I have to add two -S (COMXX) or four

thank you.  

I'm thinking about moving into makomk's bitstream but I had some problems with 1.3 controller and  i dont know if I should wait till they launch a new controller.

Doff most probably is sleeping right now, so I'll take that.

You need to start makomk's bitstream (I confirm that the 140MH one works on all my boards that run twin_test flawlessly before) with two COM ports only (like you do for twin_test), since the board is treated as two Icarus combined. The only other thing you should take care when switching from twin_test to makomk's is to enable the two back FPGAs (see readme in the bitstream archive).

Good Luck!

Only 2 COM's as it uses the controller version 1.3. It's the same as the twin_test.bit but mining on 4 fpgas.

thank you.  Seeing  I will need 1.3 controller and I had issues with it  . I'll try with one  card and I will see

[misternoodle]

Strange, with 2 COMS I have 1 FPGA working each instead of 2 per COM.  It only reports 140/140 not 280/280.  Board # 171. Controller version 1.3.

[spiccioli]

Strange, with 2 COMS I have 1 FPGA working each instead of 2 per COM.  It only reports 140/140 not 280/280.  Board # 171. Controller version 1.3.

misternoodle,

do you have SW3/SW4 switches correctly set?

They have to be ON-OFF-ON-ON

spiccioli.

[ebereon]

Strange, with 2 COMS I have 1 FPGA working each instead of 2 per COM.  It only reports 140/140 not 280/280.  Board # 171. Controller version 1.3.

what worker are you using? If you use mine, please use the icarus now. My worker was only for the twin_test.bit.

[misternoodle]

Strange, with 2 COMS I have 1 FPGA working each instead of 2 per COM.  It only reports 140/140 not 280/280.  Board # 171. Controller version 1.3.

misternoodle,

do you have SW3/SW4 switches correctly set?

They have to be ON-OFF-ON-ON

spiccioli.

I will check when I get home tonight. They might be all on, but not 100% sure. 

Thanks.

[misternoodle]

Strange, with 2 COMS I have 1 FPGA working each instead of 2 per COM.  It only reports 140/140 not 280/280.  Board # 171. Controller version 1.3.

what worker are you using? If you use mine, please use the icarus now. My worker was only for the twin_test.bit.

I'm using MBPM with the icarus worker.

[Doff]

New Results with makomk 160.bit running smooth so far in cgminer 2.6.0.

Its getting there!

ICA 0:                | 357.4/358.3Mh/s | A:194 R:0 HW:0 U:  4.50/m
ICA 1:                | 361.1/355.3Mh/s | A:205 R:0 HW:0 U:  4.75/m

Doff

[makomk]

New Results with makomk 160.bit running smooth so far in cgminer 2.6.0.

Its getting there!

ICA 0:                | 357.4/358.3Mh/s | A:194 R:0 HW:0 U:  4.50/m
ICA 1:                | 361.1/355.3Mh/s | A:205 R:0 HW:0 U:  4.75/m

Nice! Out of interest, did you have trouble getting the board to pass cgminer's validation? I'm hoping I found the cause of that problem and fixed it, but...

[yohan]

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.

[Doff]

New Results with makomk 160.bit running smooth so far in cgminer 2.6.0.

Its getting there!

ICA 0:                | 357.4/358.3Mh/s | A:194 R:0 HW:0 U:  4.50/m
ICA 1:                | 361.1/355.3Mh/s | A:205 R:0 HW:0 U:  4.75/m

Nice! Out of interest, did you have trouble getting the board to pass cgminer's validation? I'm hoping I found the cause of that problem and fixed it, but...

Ive never had that error before and cgminer started right up, that's also running with 2 Actual Icarus units. I stopped and started it about 5 times as I moved it from the laptop I program them on to where they actually sit and they started up great each time. I havent written these to flash yet so they are still working with the temporary flash.

One thing I added to make these work better was a powered USB from Zefir's Advice, before the powered USB I was unable to get the 140 bitstream to work.

[spiccioli]

New Results with makomk 160.bit running smooth so far in cgminer 2.6.0.

Its getting there!

ICA 0:                | 357.4/358.3Mh/s | A:194 R:0 HW:0 U:  4.50/m
ICA 1:                | 361.1/355.3Mh/s | A:205 R:0 HW:0 U:  4.75/m

Nice! Out of interest, did you have trouble getting the board to pass cgminer's validation? I'm hoping I found the cause of that problem and fixed it, but...

makomk,

I've just flashed 5 of my boards with controller rev. 1.3, one of them, serial nr 62-0104 keeps failing cgminer validation, the other four are working nicely.

spiccioli.

EDIT: a full reset (removing power), it seems SW1 switch 1 OFF is not the same, seems to have solved my issue, now all 5 boards are hashing.
 

[chrisp]

How many bitstreams are currently in development?

- Glasswalker is re-writing the Icarus-bitstream, main problem is JTAG noise and meeting the timing?!
- Which bitstream is makomk working on? According to the filename, also some kind of Icarus-rewrite?
- Is EP still working on a (from-scratch) bitstream or are they now waiting for Glasswalker to finish his work?
- Is anyone working on making the TML-bitstream fully compatible with CM1?

I'm working on adding native support to the TML-bitstream with the included FTDI chip.  I've had to rewrite the jtag interface so it's been some time, but i'm progressing nicely.

[Doff]

How many bitstreams are currently in development?

- Glasswalker is re-writing the Icarus-bitstream, main problem is JTAG noise and meeting the timing?!
- Which bitstream is makomk working on? According to the filename, also some kind of Icarus-rewrite?
- Is EP still working on a (from-scratch) bitstream or are they now waiting for Glasswalker to finish his work?
- Is anyone working on making the TML-bitstream fully compatible with CM1?

I'm working on adding native support to the TML-bitstream with the included FTDI chip.  I've had to rewrite the jtag interface so it's been some time, but i'm progressing nicely.

How does that work exactly chrisp, can you still use a miner like cgminer, or do you need a miner provided by Et? I have yet to even look at making anything work with the Et bitstream.