Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 79. (Read 286370 times)

Ok some running dip switch settings. These are now on support page as well.

I normally program with SW6 1 on as per the pdf, but ive tried with SW6 #1 off for both programming and operation and its definately COM22/COM23 for me;


CGminer works at 115,200 baud, so thats why SW6 1 needs to be off for it

to daemonic:

Programming fpga 0 and 3  my COM ports are 21 and 22. i Had your problem using stock cgminer 2.4.3 till i changed the sw6 1 to off
( 115k)  ( dont remember who said that but he's got all the credits)

switch 6 in my board is up acording with pdfs

try it!

Sorry if I caused confusion. I was not aware that the switch numbers are printed on the board. Now with a lens I saw them (my eyes, you know...) and in fact in my post the numbering is swapped for SW1 SW6.

Will correct it there. Thanks for the heads up.

I think zefir has SW6/SW1 the wrong way around, i was quoting it that way around also as i assumed the SW number worked clockwise around the board, it wasnt till i got a maginfying glass out i could see properly

Im starting to think i have an issue with my board;

CGMiner

MPBM

Are there different board versions with different switchs positions ?

in my card the switch positions are:

                23
6(top)       ##
1(botton)   ##
                54


could you confirm your config to avoid misunderstandings.   Thank you.

Short update before I head to work.

I got 12 boards (with all USB hubs and PSUs I could grab) up and running over night with no hiccups. Pool reports 4.3 GHps average which matches half of what cgminer is reporting as all time rate.

One problem I observed is the USB cables. With my lot I got two types with 1.8 and 1.2m, with the long ones had problems to properly operate (both directly connected to my Laptop or over a passive USB hub). While some cause aborting communication, with others the ttyUSB ports are even not detected at all. So, if you observe glitches and see from your syslog that the tty ports were disconnected, just take the USB cable from your digital cam and give a try.

For those who also ordered lots of boards, here is how I set mine up (which without persistent SPI programing is PITA), for Linux:
1.) connect all to the PSU and USB cables
2.) set DIP switches as described for twin_test PROGRAMMING plus 115kBaud:
    SW6 (array top):       1 off, 234 on (115kBaud)
    SW1 (array bottom): 3 off, 124 on (programming mode)
    SW2 + SW5 (FPGA 0+3): 1234 on
    SW3 + SW4 (FPGA 1+2): 12 off, 34 on
3.) power on all boards
4.) for every board
 a) connect it to host
 b) program all FPGAs with 190M_V3.bit
 c) disconnect from host
 d) switch SW6-3 on (red controller LED starts blinking)
5.) connect boards to host one after another (first connect the hub and then the boards to the hub)
6.) run cgminer (default Icarus at 115kBaud) with all ttyUSB
7.) note which ones are the inactive FPGAs (usually those at ttyUSBx with (x/2 % 2 == 0))
8.) run cgminer with only active FPGAs (you might need to run several times until all are detected properly)
9.) mine
10.) hope nothing goes bad, otherwise: goto 1


HTH


Edit: fixed previously swapped SW1 and SW6

I think the Icarus design is built off the Ztex one but I might be wrong on that. If anyone happens to have the NCD files for either these and wants to supply them I will try a couple of modifications to see if they will work seperately of the main team on our original bitstream. It's a process not guaranteed to work but sometimes it does but most importantly these sorts of hack can be done in 30 mins not 2 days of a rebuild. I know you all are keen to see the performance side of this and I don't think we will have any major problems getting to about the 800MH/s mark it's more a case of how long to get there.

Quite understandable, "Only one to build upon the original, freely provided code."

http://www.youtube.com/watch?v=WxmUKVrT0iI

Could you repeat that statement in english please? ;p

I believe that should be did his own work on top of that freely provided work.

Aren't all the bitstreams from ztex to icarus to x6500 to modminer all based on code that was previously published by someone else for free? Hence the exact same performance of those devices. They just made hardware designed to use available code.The only person to do his own work was ET.

Isn't the ZTEX firmware open-sourced? I believe ZTEX's quad is treated as 4 individual FPGAs, which if I understand, Cairnsmore1 supports besides the inter-FPGA link to mimic Icarus. I could be wrong, but I don't think you'd need to be a ninja.

You'd have to be quite a ninja to write a bitstream even of that performance in 2 weeks.

I will try that and use cgminer for it on win7 64. Let's hope something changes for me, but i have to wait to tomorrow evening, need my notebook workstation for daily work. I must say the flashing part looks "faster" on my workstation notebook as on my netbook (lesser tries). hmm... but can be luck 

+1 

I personally would just prefer a 750-800 MH/s firmware to get my boards running. After all that's what I was sold on (double Icarus performance for $640). Any additional work would be icing on the cake.

I will be very surprised if you will be able to produce a bitstream of 220MHs+ performance in a reasonable timeframe (1-2 weeks). From what I've heard, it's a pain in the neck to work with Spartan-6 in such high performance application. I believe TML would be much faster to implement.