|
Glasswalker
|
|
August 09, 2012, 01:09:24 PM |
|
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
|
|
August 09, 2012, 01:40:58 PM |
|
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.)
|
Quad XC6SLX150 Board: 860 MHash/s or so. SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
|
|
|
Glasswalker
|
|
August 09, 2012, 02:17:11 PM |
|
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
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
August 09, 2012, 02:31:21 PM |
|
...
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
|
|
August 09, 2012, 02:44:55 PM |
|
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
|
|
August 10, 2012, 07:08:28 AM Last edit: August 10, 2012, 11:20:40 AM by 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
Donator
Hero Member
Offline
Activity: 543
Merit: 500
|
|
August 10, 2012, 10:16:05 AM |
|
@Hpman I guess you have a board with S/N >50?
|
|
|
|
Hpman
|
|
August 10, 2012, 11:20:14 AM |
|
@Hpman I guess you have a board with S/N >50?
Happily yes. Its > #150.
|
|
|
|
yohan (OP)
|
|
August 10, 2012, 01:20:25 PM |
|
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
Member
Offline
Activity: 107
Merit: 10
|
|
August 10, 2012, 04:04:57 PM |
|
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
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
August 10, 2012, 05:18:03 PM |
|
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 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 should show something like 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 ./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 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 $ 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. 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
Member
Offline
Activity: 107
Merit: 10
|
|
August 10, 2012, 07:20:39 PM |
|
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
|
|
August 10, 2012, 08:30:35 PM |
|
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
Donator
Hero Member
Offline
Activity: 919
Merit: 1000
|
|
August 10, 2012, 08:55:58 PM |
|
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
|
|
August 10, 2012, 09:36:29 PM |
|
Have to say that is a very pretty usb hub.
|
|
|
|
makomk
|
|
August 10, 2012, 10:06:51 PM |
|
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.
|
Quad XC6SLX150 Board: 860 MHash/s or so. SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
August 10, 2012, 10:24:37 PM |
|
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: echo -n 'devdetails' | nc 127.0.0.1 4028 ; echo
or linux and windows: 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: $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: $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: $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
|
|
August 11, 2012, 03:32:00 AM |
|
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: echo -n 'devdetails' | nc 127.0.0.1 4028 ; echo
or linux and windows: 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: $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: $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: $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
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
August 11, 2012, 07:29:08 AM |
|
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: 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
|
|
|
|
|