Cairnsmore1 - Quad XC6SLX150 Board

[spiccioli]

I've built cgminer 2.6.4 for linux 32bit with zefir patch and icarus support only.

http://p2pool.soon.it/cgminer/cgminer-2.6.4-zefir

spiccioli

[1714139630]

1714139630

[1714139630]

1714139630

[1714139630]

1714139630

[1714139630]

1714139630

[Glasswalker]

Ok, quick update. Unfortunately my last build once again (sigh...) had a bug in the new LVDS clocking. (literally oversight on my part, I put a FALSE where it should have been TRUE for LVDS signal termination... DOH!) anyway, that resulted in continuing stability issues, and caused my latest week long marathon build to be a waste of time... Grumble...

Anyway, this has prompted me to apply another round of code fixes. And I think this one should wrap it up. I've fixed the couple minor bugs that existed, so those problems should be solved. AND I've applied several new fixes as well. Including backporting ALL (that I could find) of makomk's shortfin fixes into the HashVoodoo core now. (With the exception of the DCM watchdog, because it was just to fix the failing DCM, but with the LVDS clock signalling there actually is no DCM at all, so nothing to slap a watchdog on lol).

Anyway, this one has several new fixes, and all of makomk's improvements. Plus I've fixed the nonce range problem (which will cause wrong hashrate to report, and wierd U numbers and such) the chips *should* (provided I didn't bork something up again) hash a full nonce range per chip.

So anyway, just posting this up, these changes are already committed, and pushed up to the github, so they are there for everyone to see And I'm doing a first round build on it now.

Also, I should have a new controller coming very soon (as in within the next day or two) to match this build, which will provide the following improvements/fixes:
- Should solve jtag instability and usb flashing capabilities, meaning people without jtag cables *should* be able to install it (but need to confirm this first for safety)
- It now supports dynamic clocking, it will be crude at this point, but it will allow 2 dip switches to be used to select from 4 different hashing clock rates (while leaving the communications clocks alone to keep stable baud rate)
- 180Mhz
- 190Mhz
- 200Mhz
- 210Mhz

This way with a given board, you can tune it within that range to find the optimal hashing rate without having to reflash various bitstreams (easy overclocking) I'm building the bitstreams to close timing to 180Mhz now, so that lowest one will be the "100% in spec", but typically the chips can easily reach a bit beyond their spec (much like CPUs, they are graded in batches based on quality, and some chips may overclock better than others). In some cases I get lucky and exceed timing. So for example, if I'm shooting for 180Mhz, and manages to close timing, that means that no path within the FPGA will exceed a delay of 5.555ns, but if I manage to close timing with 0.55ns of slack, that means that it's actually only got 5ns of delay, which means it's technically fully "in-spec" for 200Mhz clock. And if I exceed timing by a full 1ns, then we're super lucky, and that means it's in-spec for a 219Mhz clock. Now that doesn't take into account power draw of all the components in the chip, noise at those frequencies, and thermal stability. But it means the more "in-spec" we are, the more "universally stable" it should be at a given clock. So the new overclocking options (however crude for now) should help people dial in what's "best" for their given board.

Down the road this will become an auto-tuned thing in software based on invalid rates to find the optimal share yield per second per chip. (yes technically we can tune each chip independently)

Anyway, just a quick update. I'll post more once I've been able to test it.

Oh and also my new board arrived, so I now have both my #0001 serial number board, and a newer #04xx (can't remember exact number) board, so this lets me test and validate on "both sides of the coin".

[makomk]

Ok, quick update. Unfortunately my last build once again (sigh...) had a bug in the new LVDS clocking. (literally oversight on my part, I put a FALSE where it should have been TRUE for LVDS signal termination... DOH!) anyway, that resulted in continuing stability issues, and caused my latest week long marathon build to be a waste of time... Grumble...

Hmmm. You should've been able to fix that up post-build in FPGA Editor... oh well. Also, you might've been able to get away with using the .ncd from that run as a SmartGuide guide file (or not, I've been having some annoying routing issues with SmartGuide even with totally unchanged designs).

Anyway, this one has several new fixes, and all of makomk's improvements. Plus I've fixed the nonce range problem (which will cause wrong hashrate to report, and wierd U numbers and such) the chips *should* (provided I didn't bork something up again) hash a full nonce range per chip.

Bear in mind this will still require changes to mining software to avoid weird problems with hash rate reporting. (I had a cunning idea to try and work around this, but it turned out that the Xilinx mapping tool really didn't like it so it's probably best to just change the software, heh.)

[Glasswalker]

Yeah I could have done it in fpgaeditor, but I had several other changes that needed doing too, so I used that as a base. I'll try the fpgaeditor option as well, while I'm waiting on this build to run through smartxplorer. I've found even minor changes to the design, tend to bork up the tools even if I'm using smartguide from a previous successful run. But maybe that was just an isolated experience.

And yeah I'm still aware of the software issues. TheSeven mentioned it to me on IRC. I've got a fork of MPBM which has a cairnsmore module in it, and I'll be fixing the hash reporting in that eventually.

Thanks!

[kano]

...

Down the road this will become an auto-tuned thing in software based on invalid rates to find the optimal share yield per second per chip. (yes technically we can tune each chip independently)

Anyway, just a quick update. I'll post more once I've been able to test it.
...

Hopefully by this you mean that like with a ztex, the miner software can tell it to increase and decrease the MHz clock on the fly
So it is up to software control (and HW: error counts) to decide the optimal MHz

[Glasswalker]

Hopefully by this you mean that like with a ztex, the miner software can tell it to increase and decrease the MHz clock on the fly
So it is up to software control (and HW: error counts) to decide the optimal MHz

That's correct, I intend to expose a more advanced serial protocol which will allow the mining software to (among other things) adjust the clock rate for the hashing clock. That's a ways off for now though, so initially we're working with the more crude "dip switch coarse clock settings" option...

[Hpman]

Short feedback from me side,  old shortfin_190 and dcmwd2_200 running great without any problems on my board. Waiting for 2xx versions . Unfortunaly at the moment I'm still using original cgminer 2.6.1/2.6.1 without zefirs patch, but 'll compile new binary next days. Great work guys, hopefully bounty will shared to all who spend a lot of spare time for that project. Still missing somethings news from enterpoint itself ...

Hpman

[ShadesOfMarble]

@Hpman I guess you have a board with S/N >50?

[Hpman]

@Hpman I guess you have a board with S/N >50?

Happily yes. Its > #150.

[yohan]

July Order Close Out

A few of you, on a July delivery promise, have not responded to emails saying boards are available. In order that we can delivery ASAP to customers waiting for boards we are about to close down the July order list. We will wipe anything remaining that we have the July list on Monday so you will lose that order place unless we have heard from you either to reschedule the order or to pay for it. So if you think you have been missed do check your spam box and/or contact us if you still want your order.

[hm]

still using twin_test @ 62-0017 ... I'm lucky at the moment as hash rate seems to be OK for the last half of test period:



I'm waiting impatiently for a mature bitstream for cm1 boards <50, and I'm confident once again that something (that's not just usable but also produces stable hash rates) will be released within next two or three weeks, after my disappointment in the last days.
I know I shouldn't be disappointed because of the project still being in development phase rather than being production ready, but I still couldn't help it.

Now I'll test again a makomk shortfin_dcmwd2_test bitstream, although this will probably interrupt my period of luck regarding above hash rates with twin_test...

[spiccioli]

Right now, on linux, at every reboot of the host pc the order in which serveral boards map themselves to the various ttyUSB ports is mostly random.

There is though, in this early stage, the need to know which board ended up on each ttyUSB port.

I've found that, on my ubuntu 12.04 server, there are symlinks inside /dev/serial/by-id/ which map every board/port using their serial number to their respective ttyUSBnn port.

So, having several boards, all that is needed is plug them one by one and issue a

Code:

sudo lsusb -v | grep iSerial

to know the serial number of each one.

Knowing, for example, that board 62-0134 has serial number FTVJ59WC, a simple

Code:

ls -l /dev/serial/by-id/

should show something like

Code:

lrwxrwxrwx 1 root root 13 Aug  9 21:50 usb-FTDI_Cairnsmore1_FTVJ59WC-if00-port0 -> ../../ttyUSB4
lrwxrwxrwx 1 root root 13 Aug  9 21:50 usb-FTDI_Cairnsmore1_FTVJ59WC-if01-port0 -> ../../ttyUSB5
lrwxrwxrwx 1 root root 13 Aug  9 21:50 usb-FTDI_Cairnsmore1_FTVJ59WC-if02-port0 -> ../../ttyUSB6
lrwxrwxrwx 1 root root 13 Aug  9 21:50 usb-FTDI_Cairnsmore1_FTVJ59WC-if03-port0 -> ../../ttyUSB7

From which we know that board FTVJ59WC if02/if03 are the serial ports ttyUSB6/7.

Cgminer names the various ICA nn using the same order in which they are listed using the -S parameters, so if I have a command line like

Code:

./cgminer -S ... -S ... -S /dev/ttyUSB6 -S /dev/ttyUSB7 ...

I'm now able to say that my ICA 2 and ICA 3 are my board with serial number 134 written ontop.

Maybe this was clear to everybody here but me

Anyway, this is just half of what we can do.

On ubuntu there is a rule inside /lib/udev/rules.d which is named 60-persistent-serial.rules which is the rule set creating those symlinks inside /dev/serial/by-id/.

I've copied it inside /etc/udev/rules.d as 99-cairnsmore-links.rules and I've modified it to create more meaningful links inside /dev

Code:

ACTION=="remove", GOTO="persistent_serial_end"
SUBSYSTEM!="tty", GOTO="persistent_serial_end"
KERNEL!="ttyUSB[0-9]*|ttyACM[0-9]*", GOTO="persistent_serial_end"

SUBSYSTEMS=="usb-serial", ENV{.ID_PORT}="$attr{port_number}"

IMPORT{builtin}="usb_id"
ENV{ID_SERIAL}=="", GOTO="persistent_serial_end"

SUBSYSTEMS=="usb", ENV{ID_USB_INTERFACE_NUM}="$attr{bInterfaceNumber}"
ENV{ID_USB_INTERFACE_NUM}=="", GOTO="persistent_serial_end"

ATTRS{serial}=="FTVJ59WC", SYMLINK+="cm-62-0134-if$env{ID_USB_INTERFACE_NUM}"
ATTRS{serial}=="FTVJ5AGN", SYMLINK+="cm-62-0135-if$env{ID_USB_INTERFACE_NUM}"
ATTRS{serial}=="FTVJ88QX", SYMLINK+="cm-62-0136-if$env{ID_USB_INTERFACE_NUM}"
ATTRS{serial}=="FTVJ88VS", SYMLINK+="cm-62-0137-if$env{ID_USB_INTERFACE_NUM}"
# ... and so on for every board ...

LABEL="persistent_serial_end"

With these rules I have now

Code:

$ ls -l /dev/cm*

lrwxrwxrwx 1 root root 7 Aug  9 21:50 /dev/cm-62-0134-if00 -> ttyUSB4
lrwxrwxrwx 1 root root 7 Aug  9 21:50 /dev/cm-62-0134-if01 -> ttyUSB5
lrwxrwxrwx 1 root root 7 Aug  9 21:50 /dev/cm-62-0134-if02 -> ttyUSB6
lrwxrwxrwx 1 root root 7 Aug  9 21:50 /dev/cm-62-0134-if03 -> ttyUSB7
lrwxrwxrwx 1 root root 8 Aug  8 21:51 /dev/cm-62-0136-if00 -> ttyUSB24
lrwxrwxrwx 1 root root 8 Aug  8 21:51 /dev/cm-62-0136-if01 -> ttyUSB25
lrwxrwxrwx 1 root root 8 Aug  8 21:51 /dev/cm-62-0136-if02 -> ttyUSB26
lrwxrwxrwx 1 root root 8 Aug  8 21:51 /dev/cm-62-0136-if03 -> ttyUSB27
lrwxrwxrwx 1 root root 8 Aug  8 22:11 /dev/cm-62-0137-if00 -> ttyUSB28
lrwxrwxrwx 1 root root 8 Aug  8 22:11 /dev/cm-62-0137-if01 -> ttyUSB29
lrwxrwxrwx 1 root root 8 Aug  8 22:11 /dev/cm-62-0137-if02 -> ttyUSB30
lrwxrwxrwx 1 root root 8 Aug  8 22:11 /dev/cm-62-0137-if03 -> ttyUSB31

Which are valid links that I can use when I start cgminer instead of the ever changing ttyUSBnn ports.

Code:

cgminer -S /dev/cm-62-0134-if02 -S /dev/cm-62-0134-if03 -S ...

Calling cgminer like this gives me the assurance that ICA 0 will always be port 2 of board 62-0134 and ICA 1 port 3.

ICA names/numbers do not depend anymore on the order in which my host PC sees the boards and/or the usb port to which I plug them.

I hope this helps

spiccioli

[hm]

I flashed shortfin_dcmwd2_test_200_overclock.bit @ 62-0017:

• board was off and disconnected and had twin_test flashed
• set DIP switches according to new bitstream + flashing procedure: SW1-3 off, SW6-1 off, SW3-2 and SW5-2 off, the rest to ON position
• started up VM, logged in as root
• waited more than 5 minutes
• connected usb cable (disabled 5v power line to prevent the controller from switching the power source)
• waited more than 5 minutes
• xc3sprog -c cm1 -j => OK
• xc3sprog -c cm1 -p0 -Ixc6lx150.bit shortfin_dcmwd2_test_200_overclock.bit
  xc3sprog -c cm1 -p1 -Ixc6lx150.bit shortfin_dcmwd2_test_200_overclock.bit
  xc3sprog -c cm1 -p2 -Ixc6lx150.bit shortfin_dcmwd2_test_200_overclock.bit
  xc3sprog -c cm1 -p3 -Ixc6lx150.bit shortfin_dcmwd2_test_200_overclock.bit
  all OK
• powered off and disconnected usb
• set SW1-3 to ON, others not changed
• powered up the board
• reboot PC
• fpga LEDs orange, then waited more than 10 minutes
• connected USB and checked device manager
• successfully started cgminer with first try: cgminer.exe -G -S "\\.\COM22" -S "\\.\COM23" --icarus-timing long -c eligius.conf

=> some red flashes, some green flashes, not always "Accepted" messages when green flashes occur



..let's wait some hours for better stats...

[Lethos]

One my boards is currently happy on the shortfin200 and the other can only cope with the shortfin190.
Not sure why, can't get both to run without a lame duck effect occurring. It is good progress and I'm happy with the results.

[zefir]

To all 20+ CM1 boards operators: I went bananas with cascading my 4- and 7-port USB hubs and searching for the one unstable cable in the mess over the past weeks now.

Ordered this


35-port hub (powered with a 5A brick) here (there are other sources, but I found that to be the cheapest one) and got the package delivered to Switzerland after 5 days.

Confirming that it is working with 26 CM1 boards flawlessly for 48h+ so far.

[Lethos]

Have to say that is a very pretty usb hub.

[makomk]

OK, with a bit of help from ebereon running lots of SmartXplorer runs, the following should apparently hit 200 MHz on the pairs that couldn't manage it before: http://www.makomk.com/~aidan/shortfin-eb-20120809.zip Unfortunately, it doesn't have a functioning DCM watchdog, so you have to watch out for pairs falling over. Apparently ebereon has managed to get all of his FPGAs running reasonably stably at 200 MHz by combining this with the dcmwd2 ones. A good starting guess would probably be 200 MHz http://www.makomk.com/~aidan/shortfin-dcmwd-20120808.zip on FPGA0/1, 200MHz shortfin-eb on 2/3, switch to shortfin-eb if you have too many invalids on 0/1, switch to dcmwd if the U/m of 2/3 drops off spectacularly after a few hours (should be 5+, if it's 2 to low 4s something's up), fall back to 190MHz dcmwd if either of those still doesn't work reliably.

[kano]

Right now, on linux, at every reboot of the host pc the order in which serveral boards map themselves to the various ttyUSB ports is mostly random.

...

Calling cgminer like this gives me the assurance that ICA 0 will always be port 2 of board 62-0134 and ICA 1 port 3.

ICA names/numbers do not depend anymore on the order in which my host PC sees the boards and/or the usb port to which I plug them.

I hope this helps

spiccioli

To help with viewing the configuration:
Though you probably know, there is also the API devdetails that will tell you the ICAn -> /dev/ttyUSBn mapping
(or in your case the ICAn -> /dev/cm-* mapping)

In linux:

Code:

echo -n 'devdetails' | nc 127.0.0.1 4028 ; echo

or linux and windows:

Code:

java API devdetails

However .......

If you use the latest github miner.php to view your boards you can easily add a custom summary button to show the mapping.

In miner.php, the default $customsummarypages is:

Code:

$mobilepage = array(
 'DATE' => null,
 'RIGS' => null,
 'SUMMARY' => array('Elapsed', 'MHS av', 'Found Blocks=Blks', 'Accepted', 'Rejected=Rej', 'Utility'),
 'DEVS+NOTIFY' => array('DEVS.Name=Name', 'DEVS.ID=ID', 'DEVS.Status=Status', 'DEVS.Temperature=Temp',
                        'DEVS.MHS av=MHS av', 'DEVS.Accepted=Accept', 'DEVS.Rejected=Rej',
                        'DEVS.Utility=Utility', 'NOTIFY.Last Not Well=Not Well'),
 'POOL' => array('POOL', 'Status', 'Accepted', 'Rejected=Rej', 'Last Share Time'));
$mobilesum = array(
 'SUMMARY' => array('MHS av', 'Found Blocks', 'Accepted', 'Rejected', 'Utility'),
 'DEVS+NOTIFY' => array('DEVS.MHS av', 'DEVS.Accepted', 'DEVS.Rejected', 'DEVS.Utility'),
 'POOL' => array('Accepted', 'Rejected'));
#
# customsummarypages is an array of these Custom Summary Pages
$customsummarypages = array('Mobile' => array($mobilepage, $mobilesum));

But to add one that shows the /dev/tty*:
Add this:

Code:

$devdetpage = array(
 'DATE' => null,
 'RIGS' => null,
 'DEVS+DEVDETAILS' => array('DEVS.Name=Name', 'DEVS.ID=ID',
                        'DEVS.Temperature=Temp', 'DEVS.MHS av=MHS av',
                        'DEVS.Accepted=Accepted', 'DEVS.Rejected=Rej',
                        'DEVDETAILS.Device Path=Device'));
$devdetsum = array(
 'DEVS+DEVDETAILS' => array('DEVS.MHS av', 'DEVS.Accepted', 'DEVS.Rejected'));

and change this:

Code:

$customsummarypages = array('Mobile' => array($mobilepage, $mobilesum),
'DevDet' => array($devdetpage, $devdetsum));

Then the DevDet button will show each device in a brief single line summary with the "Device Path" value (/dev/tty* or /dev/cm-* or ...)

... and of course if you have them on multiple cgminer's you just edit $rigs to point to each of them and have it all on one page

[Doff]

Right now, on linux, at every reboot of the host pc the order in which serveral boards map themselves to the various ttyUSB ports is mostly random.

...

Calling cgminer like this gives me the assurance that ICA 0 will always be port 2 of board 62-0134 and ICA 1 port 3.

ICA names/numbers do not depend anymore on the order in which my host PC sees the boards and/or the usb port to which I plug them.

I hope this helps

spiccioli

To help with viewing the configuration:
Though you probably know, there is also the API devdetails that will tell you the ICAn -> /dev/ttyUSBn mapping
(or in your case the ICAn -> /dev/cm-* mapping)

In linux:

Code:

echo -n 'devdetails' | nc 127.0.0.1 4028 ; echo

or linux and windows:

Code:

java API devdetails

However .......

If you use the latest github miner.php to view your boards you can easily add a custom summary button to show the mapping.

In miner.php, the default $customsummarypages is:

Code:

$mobilepage = array(
 'DATE' => null,
 'RIGS' => null,
 'SUMMARY' => array('Elapsed', 'MHS av', 'Found Blocks=Blks', 'Accepted', 'Rejected=Rej', 'Utility'),
 'DEVS+NOTIFY' => array('DEVS.Name=Name', 'DEVS.ID=ID', 'DEVS.Status=Status', 'DEVS.Temperature=Temp',
                        'DEVS.MHS av=MHS av', 'DEVS.Accepted=Accept', 'DEVS.Rejected=Rej',
                        'DEVS.Utility=Utility', 'NOTIFY.Last Not Well=Not Well'),
 'POOL' => array('POOL', 'Status', 'Accepted', 'Rejected=Rej', 'Last Share Time'));
$mobilesum = array(
 'SUMMARY' => array('MHS av', 'Found Blocks', 'Accepted', 'Rejected', 'Utility'),
 'DEVS+NOTIFY' => array('DEVS.MHS av', 'DEVS.Accepted', 'DEVS.Rejected', 'DEVS.Utility'),
 'POOL' => array('Accepted', 'Rejected'));
#
# customsummarypages is an array of these Custom Summary Pages
$customsummarypages = array('Mobile' => array($mobilepage, $mobilesum));

But to add one that shows the /dev/tty*:
Add this:

Code:

$devdetpage = array(
 'DATE' => null,
 'RIGS' => null,
 'DEVS+DEVDETAILS' => array('DEVS.Name=Name', 'DEVS.ID=ID',
                        'DEVS.Temperature=Temp', 'DEVS.MHS av=MHS av',
                        'DEVS.Accepted=Accepted', 'DEVS.Rejected=Rej',
                        'DEVDETAILS.Device Path=Device'));
$devdetsum = array(
 'DEVS+DEVDETAILS' => array('DEVS.MHS av', 'DEVS.Accepted', 'DEVS.Rejected'));

and change this:

Code:

$customsummarypages = array('Mobile' => array($mobilepage, $mobilesum),
'DevDet' => array($devdetpage, $devdetsum));

Then the DevDet button will show each device in a brief single line summary with the "Device Path" value (/dev/tty* or /dev/cm-* or ...)

... and of course if you have them on multiple cgminer's you just edit $rigs to point to each of them and have it all on one page

I tried to test this out but I'm obviously doing something wrong because I just get a blank page. I have 2.6.4 from git is that also the latest miner.php? Also where within miner.php do I need to paste this code? or do I need to replace something with it? I have rigs currently working with 2.6.4 version.

Thanks for the help.

Doff

[spiccioli]

Right now, on linux, at every reboot of the host pc the order in which serveral boards map themselves to the various ttyUSB ports is mostly random.

...

Calling cgminer like this gives me the assurance that ICA 0 will always be port 2 of board 62-0134 and ICA 1 port 3.

ICA names/numbers do not depend anymore on the order in which my host PC sees the boards and/or the usb port to which I plug them.

I hope this helps

spiccioli

kano,

I've never used the API, so thanks for the example with it and miner.php.

To help with viewing the configuration:
Though you probably know, there is also the API devdetails that will tell you the ICAn -> /dev/ttyUSBn mapping
(or in your case the ICAn -> /dev/cm-* mapping)

In linux:

Code:

echo -n 'devdetails' | nc 127.0.0.1 4028 ; echo

my biggest 'problem' was not mapping ICAn to ttyUSBn, but ttyUSBn to the 'correct' board (I have ten of them) so that, for example, I can flash a slower bitstream to the pair with too many errors.

spiccioli