Cairnsmore1 - Quad XC6SLX150 Board - page 50.

zefir

donator

Activity: 919

Merit: 1000

Quote from: Glasswalker on July 26, 2012, 08:56:31 PM

[...] Anyway keep reporting results, [...]

since you asked for results Wink

, here are mine collected over the past 20h:

I re-programmed an array of 12 boards with the given controller FW and bitstream. Before the boards operated in twin_bitstream mode with

7 boards being stable (both U values above ~2.3)
3 boards impaired (at least one FPGA below ~2.3U)
2 unstable boards (both FPGA below 1U)

They totaled somewhere at 44U.

After the programming I have:

6 boards working 'ok', with all 3 FPGA per board at more than 2.3U
5 boards that do not mine. they pass the golden nonce test, but even after an hour still did not generate a single share.
1 board that does almost not mine, i.e. after 1h all three FPGAs are below 0.1U

Running the 6 'good' boards for ~20h:

Code:

cgminer version 2.5.0 - Started: [2012-07-27 10:04:11]
--------------------------------------------------------------------------------
 (5s):10425.6 (avg):9003.0 Mh/s | Q:8973  A:23300  R:76  HW:0  E:260%  U:43.3/m
 TQ: 24  ST: 25  SS: 0  DW: 3006  NB: 65  LW: 129448  GF: 0  RF: 0
 Connected to http://eu.ozco.in:8332 with LP as user zeta-mining.1
 Block: 000003b506a76f202a4544008ce4ed0e...  Started: [19:01:42]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA  0:                | 373.1/373.6Mh/s | A:1286 R:8 HW:0 U: 2.39/m
 ICA  1:                | 371.0/373.7Mh/s | A:1307 R:4 HW:0 U: 2.43/m
 ICA  2:                | 378.4/373.7Mh/s | A:1266 R:1 HW:0 U: 2.35/m
 ICA  3:                | 380.0/379.9Mh/s | A:   0 R:0 HW:0 U: 0.00/m
 ICA  4:                | 379.3/373.0Mh/s | A:1382 R:4 HW:0 U: 2.57/m
 ICA  5:                | 370.4/373.7Mh/s | A:1288 R:3 HW:0 U: 2.39/m
 ICA  6:                | 374.2/373.4Mh/s | A:1291 R:5 HW:0 U: 2.40/m
 ICA  7:                | 380.0/379.9Mh/s | A:   0 R:0 HW:0 U: 0.00/m
 ICA  8:                | 376.6/373.6Mh/s | A:1291 R:4 HW:0 U: 2.40/m
 ICA  9:                | 378.1/373.7Mh/s | A:1266 R:5 HW:0 U: 2.35/m
 ICA 10:                | 373.7/373.6Mh/s | A:1272 R:3 HW:0 U: 2.36/m
 ICA 11:                | 380.0/379.9Mh/s | A:   0 R:0 HW:0 U: 0.00/m
 ICA 12:                | 378.8/373.7Mh/s | A:1266 R:3 HW:0 U: 2.35/m
 ICA 13:                | 372.3/373.4Mh/s | A:1314 R:2 HW:0 U: 2.44/m
 ICA 14:                | 370.4/373.4Mh/s | A:1308 R:3 HW:0 U: 2.43/m
 ICA 15:                | 380.0/379.9Mh/s | A:   0 R:0 HW:0 U: 0.00/m
 ICA 16:                | 377.9/373.8Mh/s | A:1260 R:6 HW:0 U: 2.34/m
 ICA 17:                | 373.3/373.8Mh/s | A:1296 R:3 HW:0 U: 2.41/m
 ICA 18:                | 373.2/373.5Mh/s | A:1291 R:9 HW:0 U: 2.40/m
 ICA 19:                | 380.0/379.9Mh/s | A:   0 R:0 HW:0 U: 0.00/m
 ICA 20:                | 375.8/373.4Mh/s | A:1297 R:6 HW:0 U: 2.41/m
 ICA 21:                | 371.8/373.5Mh/s | A:1255 R:4 HW:0 U: 2.33/m
 ICA 22:                | 372.7/373.0Mh/s | A:1364 R:3 HW:0 U: 2.54/m
 ICA 23:                | 380.0/379.9Mh/s | A:   0 R:0 HW:0 U: 0.00/m
--------------------------------------------------------------------------------

... I get almost the same total U value as I had before - but now I can power down half of the boards

One important observation to note is, that the now working boards are not exactly those that worked stable before - and vice versa. To me it looks completely random whether a board is going to mine with a given bitstream or not. And this bothers me even more than the lack of a bitstream to unleash the full potential of CM1. With all the fights I had so far to get at least some of the FPGAs mining, If I had a choice I would highly prefer a 600 MHps FW that runs on 100% of the boards flawlessly over a 1000 MHps one that runs on 70% of boards.

Hope your ongoing improvement of the communication module will resolve the current flaws.

Good Luck and thanks for your efforts.

Glasswalker

sr. member

Activity: 407

Merit: 250

Quote from: kano on July 26, 2012, 09:26:32 PM

Odd, I've never had either of my orignal Icarus fail during hashing since I got them ... almost 5 months ago.
Runtime is random (coz I often restart to test cgminer code) ...
but the longest runtime is 164.5 hours before I stopped it.

That's fair, many people had a great time with them, and ngzhang offered great service and was helpful. I'm not slamming him as an individual. But to provide a counterpoint to your argument, my icarus boards froze fairly frequently, or randomly locked up, and exhibited all kinds of unstable behavior. Some of this was attributed to the usb->uart chip he used. But now that I've dug into his code, there is a vulnerability there, that when combined with the different clocking structure on the cairnsmore and a little bit of noise on the clock lines, it results in a problem. On his boards, his code was fine, but on other boards it has the potential (under the right circumstances) to be highly susceptible to noise.

The reason for this is the way his UART samples the waveform. It ends up sampling very near the edge, so in a situation where there might be bounce or ringing on the serial lines, the edge might not be clear, and the result could be the UART clocking in a 0 instead of a 1, or vice-versa. The other problem is that it can cause the UART to "lock" onto the wrong spot in the waveform, resulting in garbled nonsense coming into it altogether. This works as a cheap and dirty UART concept, but ideally you want sampling reliably in the center of the waveform, and in a perfect world, you want oversampling, with filtering to smooth out noise. In my case I'm using the center of waveform method, with oversampling to detect the center effectively, but not using smoothing as that's a bit more complex. Though I can go that route if I have to.

Anyway, hopefully that explains a bit better what I'm doing here.

On my "from scratch" bitstream, I intend to use a proper serial protocol, with checksums for validation and error checking/correction. The current icarus protocol is fairly crude (it spews bytes out which are just shifted into a register, there is no synchronization attempted, no error checking, nothing. So if it ends up shifted by even a single bit, from then on the data is garbage, and it will keep on going as if nothing has gone wrong). But that's an overall design thing, and changing it on the icarus would likely be a fair bit of work.

As for why the noise on the lines exists, Yohan can likely explain that better. It's likely a combination of things. (for one, cairnsmore has a programmable, synthetic clock, rather than a single fixed crystal, also because of the different board layout it might be more sensitive to inductive noise in places the icarus was not for example, but overall I'm not really sure, like I said, that's a question for Yohan)

misternoodle

member

Activity: 108

Merit: 10

Finally got MPBM working, using the Makomk's 140 Bitstream. Followed the settings, SW1 & 6 per the Twin Build Running settings.

SW2-5 on low performance mode. Only 2 of my chips are mining right now.
http://i.imgur.com/df6ne.jpg

Any idea? The two that are hashing, don't have any issues.

Board#171

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Glasswalker on July 26, 2012, 08:56:31 PM

Quote from: ebereon on July 26, 2012, 07:49:21 PM

Glasswalker's bitstream hangs after 1h 11min :-/

To confirm this is on your worst board though right? Any longer success on your other boards?

The reason I ask is this bitstream still uses the "flaky" original icarus UART code, among other things
...

Odd, I've never had either of my orignal Icarus fail during hashing since I got them ... almost 5 months ago.
Runtime is random (coz I often restart to test cgminer code) ...
but the longest runtime is 164.5 hours before I stopped it.

rampone

sr. member

Activity: 339

Merit: 250

dafq is goin on

sn:62-0016

glasswalker v1.0 sp3
fpgamining_top.bit flashed

all flash red when getting work/goldennonce test
fpga 0: stays yellow
fpga 1: sometimes after power up wrong golden nonce returned, sometimes like fpga0
fpga 3: like fpga 1
fpga 2: like fpga 0

(tested via mpbm, 57600 bps, dips sp3 all on, dips fpga1/2 #1 off, rest on (thats the right setting?!?!!!)
if i switch dips fpga1/2 with #12 both off like twintest build fpga1 seems to hang (no yellow, no heat), and golden nonce test is even more wrong on fpga3.

long walk home to 2*50mh/s build now Wink

Glasswalker

sr. member

Activity: 407

Merit: 250

Quote from: ebereon on July 26, 2012, 07:49:21 PM

Glasswalker's bitstream hangs after 1h 11min :-/

To confirm this is on your worst board though right? Any longer success on your other boards?

The reason I ask is this bitstream still uses the "flaky" original icarus UART code, among other things, and Enterpoint has tweaked drive strength and other stuff to reduce noise to help along the uart. But the new bitstream I'm building now has new UART code which should solve that problem, in concert with the improvements from enterpoint it should even be rock solid on the most unstable of board.

The part that confuses me is that on the same board the 140Mhz makomk bitstream is stable... (which from what I understand is also a direct port of the icarus code)... Which is odd indeed...

Anyway keep reporting results, I should have a new bitstream soon. This next one will be 150Mhz, and then I'll push for faster, but at least you can plop the 150Mhz onto any "poor" chip positions, and the 175 on the others for a hybrid boost... Once that one is confirmed stable, I'll start pushing to get it's speed up higher.

I'll post more once I've got something to report.

ebereon

sr. member

Activity: 397

Merit: 500

Short comparison of the two new bitstreams:

Glasswalker's bitstream:
(special glassworker controller rev.)
fpga0: working but bad U ~1.8
fpga1: not working
fpga2: not working
fpga3: working but bad U ~1.6

Makomk's bitstream 140:
(controller rev. 1.3)
fpga0: working
fpga1: working
fpga2: working (invalids <1%)
fpga3: working (invalids <1%)

Makomk's bitstream 150:
(controller rev. 1.3)
fpga0: working (invalids >10%!!)
fpga1: working (invalids >10%!!)
fpga2: working (invalids >15%!!)
fpga3: working (invalids >15%!!)

thats on my worst board SN#62-409 with MPBM as miner soft.

eb

EDIT: Glasswalker's bitstream hangs after 1h 11min :-/

zefir

donator

Activity: 919

Merit: 1000

Quote from: kano on July 26, 2012, 07:01:53 PM

Isn't that easier to just flick a switch?

As far as I understood Yohan and Glasswalker, the Baudrate is dependent on the array controller's clock. And Glasswalker's recent bitstream operates in 25MHz mode, effectively requiring to set serial line to 57.6 kBd. Just posted a pull request to add support in fpgautils.c as preparation for a CM1 driver for cgminer.

ebereon

sr. member

Activity: 397

Merit: 500

Quote from: kano on July 26, 2012, 07:01:53 PM

What happened to the switch that changed it from 57,600 to 115,200?
Isn't that easier to just flick a switch?

That was in controller rev. 1.0 i think or 1.1 and shipping_test bitstream, but glasswalkers bitstream needs a complete different controller rev. with much changes in the dip settings. I don't think there is a dip that change it.

eb

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: zefir on July 26, 2012, 03:53:52 PM

Quote from: Doff on July 26, 2012, 03:47:33 PM

When I apply the Patch Zefir I get

Hunk #1 FAILED at 53.
Hunk #2 FAILED at 195.
2 out of 2 hunks FAILED -- saving rejects to file driver-icarus.c.rej
patching file fpgautils.c
Hunk #1 FAILED at 210.
1 out of 1 hunk FAILED -- saving rejects to file fpgautils.c.rej

I tried to add it manually to the file but then got errors building cgminer.

Let's fix that outside this thread, I'll contact you personally.

What happened to the switch that changed it from 57,600 to 115,200?
Isn't that easier to just flick a switch?

ebereon

sr. member

Activity: 397

Merit: 500

For Glasswalker's bitstream and his MPBM worker you need to change the following lines to get the correct MH/s in the Webinterface:

cairnsmoreworker.py:

Code:

          # Calculate the hash rate based on the processing time and number of neccessary MHashes.
          # This assumes that the device processes all nonces (starting at zero) sequentially.
          self.stats.mhps = nonceval / 500000. / delta

to:

Code:

          # Calculate the hash rate based on the processing time and number of neccessary MHashes.
          # This assumes that the device processes all nonces (starting at zero) sequentially.
          self.stats.mhps = (nonceval / 500000. / delta) / 2

eb

PS: That's a dirty temporary fix!

zefir

donator

Activity: 919

Merit: 1000

Quote from: Doff on July 26, 2012, 03:47:33 PM

When I apply the Patch Zefir I get

Hunk #1 FAILED at 53.
Hunk #2 FAILED at 195.
2 out of 2 hunks FAILED -- saving rejects to file driver-icarus.c.rej
patching file fpgautils.c
Hunk #1 FAILED at 210.
1 out of 1 hunk FAILED -- saving rejects to file fpgautils.c.rej

I tried to add it manually to the file but then got errors building cgminer.

Let's fix that outside this thread, I'll contact you personally.

Doff

sr. member

Activity: 327

Merit: 250

Isokivi

hero member

Activity: 910

Merit: 1000

Items flashing here available at btctrinkets.com

If someone compiles cgminer with the proper baudrate, I'd like to leech a copy off him, I hit my "learn new softwares per day limit" some time ago for today : /
pretty please.

ebereon

sr. member

Activity: 397

Merit: 500

For those that have problems setting up a worksource in MPBM:

ebereon

sr. member

Activity: 397

Merit: 500

Screenshot of makomk's 140Mh/s bitstream on 4 fpga's:

Combined U 74.88 after only 3 hours. For a more accurate result it need ~24 hours or longer.

zefir

donator

Activity: 919

Merit: 1000

Quote from: Doff on July 26, 2012, 02:57:46 PM

How do I set the Baudrate in Cgminer Zefir? I have 2.5.0 built already just need to set that Baudrate and I think I'm good.

You need to build from source with the following patch applied:

Code:

diff --git a/driver-icarus.c b/driver-icarus.c
index 5f2c78a..ab98ac9 100644
--- a/driver-icarus.c
+++ b/driver-icarus.c
@@ -53,7 +53,7 @@
 #include "miner.h"
 
 // The serial I/O speed - Linux uses a define 'B115200' in bits/termios.h
-#define ICARUS_IO_SPEED 115200
+#define ICARUS_IO_SPEED 57600
 
 // The size of a successful nonce read
 #define ICARUS_READ_SIZE 4
@@ -195,7 +195,7 @@ static void rev(unsigned char *s, size_t l)
        }
 }
 
-#define icarus_open2(devpath, purge)  serial_open(devpath, 115200, ICARUS_READ_FAULT_DECISECONDS, purge)
+#define icarus_open2(devpath, purge)  serial_open(devpath, ICARUS_IO_SPEED, ICARUS_READ_FAULT_DECISECONDS, pu
 #define icarus_open(devpath)  icarus_open2(devpath, false)
 
 static int icarus_gets(unsigned char *buf, int fd, struct timeval *tv_finish, struct thr_info *thr, int read_
diff --git a/fpgautils.c b/fpgautils.c
index 0ebee7f..2cf8c15 100644
--- a/fpgautils.c
+++ b/fpgautils.c
@@ -210,6 +210,10 @@ serial_open(const char*devpath, unsigned long baud, signed short timeout, bool p
        switch (baud) {
        case 0:
                break;
+       case 57600:
+               cfsetispeed( &my_termios, B57600 );
+               cfsetospeed( &my_termios, B57600 );
+               break;
        case 115200:
                cfsetispeed( &my_termios, B115200 );
                cfsetospeed( &my_termios, B115200 );

To build:

Code:

./autogen.sh
./configure --disable-opencl --disable-cpumining --enable-icarus
make clean
make

And finally run with

Code:

./cgminer -S /dev/ttyUSB0 -S /dev/ttyUSB1 -S /dev/ttyUSB2 -S /dev/ttyUSB3

assuming you have a valid ~/.cgminer/cgminer.conf

Doff

sr. member

Activity: 327

Merit: 250

Quote from: zefir on July 26, 2012, 01:52:32 PM

Got Glasswalker's test bitstream programmed and working.

Took my most stable board (2.63 + 2.63U with twin-test), programmed to SPI and seems to work. After ~25 minutes I get:

Code:

cgminer version 2.5.0 - Started: [2012-07-26 19:20:12]
--------------------------------------------------------------------------------
 (5s):1599.3 (avg):1495.8 Mh/s | Q:95  A:209  R:0  HW:0  E:220%  U:7.5/m
 TQ: 4  ST: 4  SS: 0  DW: 17  NB: 5  LW: 778  GF: 0  RF: 0
 Connected to http://eu.ozco.in:8332 with LP as user zeta-mining.1
 Block: 000008e19c79451adacd7c603a91be7f...  Started: [19:40:07]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 367.8/372.6Mh/s | A:73 R:0 HW:0 U: 2.61/m
 ICA 1:                | 364.1/372.4Mh/s | A:75 R:0 HW:0 U: 2.68/m
 ICA 2:                | 373.9/372.8Mh/s | A:63 R:0 HW:0 U: 2.25/m
 ICA 3:                | 380.0/378.0Mh/s | A: 0 R:0 HW:0 U: 0.00/m
--------------------------------------------------------------------------------

As Glasswalker mentioned, one FPGA is idling (orange LED lit), but 7.5U is way better than 5.3U

For programming the DIP switches are to be set as Yohan was explaining in the post here, while for mining the mini-howto is almost complete: you need to switch all FPGA DIP switches (2-5) ON.

For those working with Linux, I am using the xc3sprog toolsuite natively, built from SVN with the patch I posted here and the following script (ran as sudo):

Code:

#!/bin/bash

BS=fpgaminer_top.bit

./xc3sprog -c cm1 -p0 -Ixc6lx150.bit $BS && \
./xc3sprog -c cm1 -p1 -Ixc6lx150.bit $BS && \
./xc3sprog -c cm1 -p2 -Ixc6lx150.bit $BS && \
./xc3sprog -c cm1 -p3 -Ixc6lx150.bit $BS && \
    echo "Fertig" | zenity --info || { echo "Fatal error!" && echo "Fehler" | zenity --error; }

You'll need to build cgminer from source with the Baudrate set to 57.6k to mine.

Edit: copy-paste garbage fixed

How do I set the Baudrate in Cgminer Zefir? I have 2.5.0 built already just need to set that Baudrate and I think I'm good.

Glasswalker

sr. member

Activity: 407

Merit: 250

Quote from: Isokivi on July 26, 2012, 02:29:30 PM

2012-07-26 21:28:10.378   [100]   Untitled Cairnsmore worker:    Traceback (most recent call last):
  File "E:\Crainsmore\pmumby-Modular-Python-Bitcoin-Miner-c1ad5e1\pmumby-Modular-Python-Bitcoin-Miner-c1ad5e1\modules\glasswalker\cairnsmore\cairnsmoreworker.py", line 299, in _listener
   nonce = self.handle.read(4)
  File "C:\Python32\lib\site-packages\serial\serialwin32.py", line 236, in read
   raise SerialException("ReadFile failed (%s)" % ctypes.WinError())
serial.serialutil.SerialException: ReadFile failed ([Error 6] The handle is invalid.)

What do you have in the serial port field when creating new workers?

This error means it can't open the serial port. Are you in windows? if so you need to specify the port as COMX (ie COM1 COM5 COM23) without any leading slashes and such like cgminer.

If you are in linux it should be /dev/ttyUSBx

Try that and let me know if it helps.

Isokivi

hero member

Activity: 910

Merit: 1000

Items flashing here available at btctrinkets.com

Quote from: Glasswalker on July 26, 2012, 01:47:31 PM

Glad to hear you guys are getting positive results!

Can you post a screenshot of your miners in MPBM?

Also is MPBM reporting hashrate correctly? (I hoped I had fixed that but have yet to test it). If it is that's awesome.

Well so far so good!

I've just finished the rewrite of the UART code, it should solve the 4th slot problem (I hope). This build will be 150Mhash, but it's better than an idle chip. (so flash the 175 on the 3 that work, and on the 4th flash the 150).

It's still synthesizing and could be up to 24h for me to close timing on this one, but I hope it will be quick.

This one also has several more improvements. So once this is working, and tested. I'll hit it headon with all my compute power to optimize and push for a higher timing (as high a hash rate as I can get out of it).

We're getting closer!

EDIT:

Also those of you who have it working, can you post your board serial numbers with success? I hear from Enterpoint that boards under ~50 will possibly have more issues than the higher number ones. My dev board at home is #1 so it's the "worst case", but would be good to know if all of you so far are in 50+ boards, or if anyone is having success with an early board.

Thanks!

2012-07-26 21:28:10.378   [100]   Untitled Cairnsmore worker:    Traceback (most recent call last):
  File "E:\Crainsmore\pmumby-Modular-Python-Bitcoin-Miner-c1ad5e1\pmumby-Modular-Python-Bitcoin-Miner-c1ad5e1\modules\glasswalker\cairnsmore\cairnsmoreworker.py", line 299, in _listener
   nonce = self.handle.read(4)
  File "C:\Python32\lib\site-packages\serial\serialwin32.py", line 236, in read
   raise SerialException("ReadFile failed (%s)" % ctypes.WinError())
serial.serialutil.SerialException: ReadFile failed ([Error 6] The handle is invalid.)

2012-07-26 21:28:16.695   [100]   Untitled Cairnsmore worker:    Traceback (most recent call last):
  File "E:\Crainsmore\pmumby-Modular-Python-Bitcoin-Miner-c1ad5e1\pmumby-Modular-Python-Bitcoin-Miner-c1ad5e1\modules\glasswalker\cairnsmore\cairnsmoreworker.py", line 186, in main
   self._sendjob(job)
  File "E:\Crainsmore\pmumby-Modular-Python-Bitcoin-Miner-c1ad5e1\pmumby-Modular-Python-Bitcoin-Miner-c1ad5e1\modules\glasswalker\cairnsmore\cairnsmoreworker.py", line 362, in _sendjob
   self.handle.write(job.midstate[::-1] + b"\0" * 20 + job.data[75:63:-1])
  File "C:\Python32\lib\site-packages\serial\serialwin32.py", line 255, in write
   raise SerialException("WriteFile failed (%s)" % ctypes.WinError())
serial.serialutil.SerialException: WriteFile failed ([Error 6] The handle is invalid.)

2012-07-26 21:28:16.695   [100]   Untitled Cairnsmore worker:    Traceback (most recent call last):
  File "E:\Crainsmore\pmumby-Modular-Python-Bitcoin-Miner-c1ad5e1\pmumby-Modular-Python-Bitcoin-Miner-c1ad5e1\modules\glasswalker\cairnsmore\cairnsmoreworker.py", line 299, in _listener
   nonce = self.handle.read(4)
  File "C:\Python32\lib\site-packages\serial\serialwin32.py", line 236, in read
   raise SerialException("ReadFile failed (%s)" % ctypes.WinError())
serial.serialutil.SerialException: ReadFile failed ([Error 6] The handle is invalid.)

This is what im seeing, Im clueless with mpbm too.
Board 108

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