Bitcoin Forum
December 10, 2016, 10:44:42 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 [114] 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 »
  Print  
Author Topic: Cairnsmore1 - Quad XC6SLX150 Board  (Read 251448 times)
LazyOtto
Sr. Member
****
Offline Offline

Activity: 476


View Profile
September 22, 2012, 03:59:21 PM
 #2261

-- post deleted --

yohan beat me to the answer. Smiley
1481409882
Hero Member
*
Offline Offline

Posts: 1481409882

View Profile Personal Message (Offline)

Ignore
1481409882
Reply with quote  #2

1481409882
Report to moderator
1481409882
Hero Member
*
Offline Offline

Posts: 1481409882

View Profile Personal Message (Offline)

Ignore
1481409882
Reply with quote  #2

1481409882
Report to moderator
1481409882
Hero Member
*
Offline Offline

Posts: 1481409882

View Profile Personal Message (Offline)

Ignore
1481409882
Reply with quote  #2

1481409882
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481409882
Hero Member
*
Offline Offline

Posts: 1481409882

View Profile Personal Message (Offline)

Ignore
1481409882
Reply with quote  #2

1481409882
Report to moderator
Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
September 22, 2012, 04:54:30 PM
 #2262

@Lethos  Thanks for the advice. After modified some parameter it working fine now!

Based on the default setting of CM1 it gave 760 to 763Mh/s(avg) with bfgminer. Should it be enhanced after tweak the DIP switches or updating the Controller FPGA firmware and array FPGAs firmware? How could I know the version of my CM1 board's currently firmware for determine the necessity of updating?

Test it for stability first, sounds like Enterpoint (Yohan) is starting to putting fully working bitstreams into them for you.
Most of us posting here, did not get them in this state so we well use to having to update the bitstream firmware ourselves.

If it ends up being stable ask about the mak 200+ bitsteam or hashvoodoo if it is not stable.

Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
Glasswalker
Sr. Member
****
Offline Offline

Activity: 350



View Profile WWW
September 23, 2012, 06:16:57 PM
 #2263

Latest HashVoodoo Release is up at https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner/downloads

This one uses dynamic clocking (so far to my knowledge only officially supported in MPBM, waiting for word from Kano if he is working on support for cgminer).

It still supports icarus protocol, but only at 150Mhash, the enhanced protocol is required to get beyond that.

Included in the zip are the NCD/PCF files needed to use fpga_editor. If anyone wants to tweak it (ie adjust the "default" frequency by hand, or whatever).

This release has been tested for over 24h on my boards, and is seeing speeds over 200Mhash/s on all 4 chips with stability. It does take a bit of time to reach that speed, as it ramps up. And it may appear invalids are higher at first, (as high as 5%) but that's just the averages being skewed by the rampup process. It will stabilize at around 1% approximately using the defaults in MPBM. (After 24h I'm seeing speeds totalling 840MHash/s for a single CM1 board, with U value of about 11.5, and invalids (for the whole board) at about 0.3%)

Due to the dynamic clocking, this one will vary from board to board. It will find the optimal clock with minimal invalids for each chip individually. So it should be highly efficient.

NOTE: I reccomend putting a limit in MPBM of 200MHz per chip, until we have confirmation from Enterpoint if the power draw and temperatures on this bitstream at higher clocks are "safe". I'm running it higher for testing, but I don't "reccomend" you do it. Do so at your own risk! Hopefully Yohan will chime in soon on this.

Let me know your comments, and if you have any success.

Here is the readme:
Code:
Woohoo! Dynamic Clocking!

This bitstream is now mining stable on all 4 slots on both the old (pre-50) and newer CM1 boards.

For me this bitstream is stable, and doesn't suffer from the unfortunate longterm stability problems of the last release. (it's been tested for the past 24h stable on my dev boards)

I no longer need to include multiple speeds. As the dynamic clocking allows this chip to run at any speed the software chooses. It will automatically hone in on an optimal clock speed.

NOTE ON DYNAMIC CLOCKING:
The bitstream only adds a new command to the enhanced protocol. It allows the mining software (mpbm, cgminer, whatever) to send a command to set the clock multiplier to X. This allows stepping up/down the clock speed in 2.5Mhz incriments. I have put hard limits of 50Mhz - 220Mhz in the bitstream (which could be unlocked with fpga editor, I'm not telling you how though lol). For safety. That said, MPBM's feature allows you to set a soft cap on the clock speed. Which it will not clock above. I reccomend setting this limit to 200Mhz for longterm use. As Enterpoint has expressed concerns about pushing the clock higher. On my tests it worked fine up to 220Mhz, but it did increase the external temperature. Enterpoint has been sent a sample of this bitstream for validation, I would reccomend waiting on their response before pushing the chips higher.

Also, be aware, dynamic clocking will take about 30Min - 1Hour to reach the initial peak speed. Then it could take up to 24h total to fully stabilize all your stats. (using MPBMs features, since it's in the software, others may do it differently).

I've also measured the thermals on this one, on my dev board with an IR thermometer, sampled across wide area, over 10 seconds, taking peak reading. After the board is running for 24h on the bitstream (while under solid mining load).

On the previous 175oc Release which has been the stable one up until now:
Ambient Room Temperature 23.5C
Heatsinks 32.1C
Bottom of board 46.5C

On the current release with limits set to 220Mhz to do thermal testing, after 24h of runtime:
Ambient Room Temperature 25.1C
Heatsinks 34.8C
Bottom of board 49.1C

This controller is the same as the previous releases. If you aren't already running a HashVoodoo controller, you must install it. Otherwise you can leave the controller alone.

The controller generates a 25Mhz comm clock, and a 25Mhz LVDS source clock, which is then stepped up. We'll be cleaning that up in a future release, which may improve stability a little more due to less noise.

The LEDs on the array FPGAs work as follows:
RED: Heartbeat (clock blinker) blinks on a divider of the hashing clock, also lights solid in the event of DCM failure
GREEN: Found Nonce (lights up and fades out)
BLUE: Serial Activity LED (lights on RX or TX, then fades out)
AMBER: Idle, lights when the FPGA is not currently busy hashing.
The heartbeat will also light SOLID if the DCM has lost it's lock or the clock is somehow "invalid"

Note: This will work with any Icarus compatible Miner. BUT it will not allow the dynamic clocking feature to work unless the miner supports the new HashVoodoo enhanced protocol. Without dynamic clocking this bitstream will end up locked at it's "safe" clock speed of 150Mhz.

Currently the only "confirmed" supported miner is MPBM. Using the latest version of the "testing" branch from:
https://github.com/TheSeven/Modular-Python-Bitcoin-Miner
Using the cairnsmore worker module.

For those who want to tinker, I've included the appropriate build files (NCD and PCF files) allowing you to use the Xilinx FPGA Editor utility to poke around at the bitstream. Please only do this if you know what you're doing. If you fry your board I can not be held responsible!

For Flashing:
I have included both the normal bit and the MCS file (for flashing the SPI in Impact) in this release.
Only the bit is included for the controller, as an MCS is not needed for it.

NOTE: When programming via either method, you should follow the following suggestions closely, these have been tried on a number of "troublesome" boards, and have helped in every case, so this is now the "official" reccomended method of flashing the SPI:
- Always disconnect power AND USB from the board, THEN set dip switches for programming
- Once dip switches set, re-apply power
- Wait until the FPGAs have all settled before plugging in JTAG or USB
- When programming, first WIPE all 4 SPI chips, starting with chip 0, working up to chip 3
- After all chips are wiped, you can begin programming
- Program the chips one at a time, in reverse order (starting with chip 3, working back to chip 0)
- When done do a full power cycle, allowing chips to settle again before connecting USB
 
To flash via USB use the instructions provided by enterpoint. Attached is a JPG with the dip switch diagram, and here is a table of what the dip switches do:
SWITCH1 - Manual Reset when OFF (default is ON)
SWITCH2 - Override Fan Speed Sense when OFF (default is ON)
SWITCH3 - USB Programming Enable when OFF (default is ON)
SWITCH4 - MUST BE ON ALWAYS!
SWITCH5 - MUST BE ON ALWAYS!
SWITCH6 - Controller USB SPI Flash Enable when OFF (default is ON)
SWITCH7 - NOT USED CURRENTLY
SWITCH8 - JTAG Select (ON=Internal USB) (OFF=External JTAG)

For mining all switches should be in the ON state.

To flash via Xilinx ISE Impact with a supported JTAG cable:
Flash the controller first:
- Plug into controller jtag
- Let impact create a new file, and scan the jtag.
- It will identify the Spartan3, and prompt if you wish to pick a configuration file
- Choose the controller bit file.
- In the actions menu choose the option to program FLASH and FPGA.

Then do the array FPGAs:
- Plug into array jtag
- Let impact create a new file and scan the jtag
- when prompted, choose the hashvoodoo bit file for configuration file
- When prompted to add an SPI flash, say yes
- Choose the MCS file provided
- When prompted for the type of SPI PROM choose the M25P128
- Repeat for the other 3 chips
- When done a dialog with some settings will pop up, accept the defaults.
- Select one of the SPI Flash chips in the graphical display. It will turn green
- In the action menu choose Program.
- Repeat for the other chips. (no need to do the FPGAs themselves they program from the SPI on power cycle)
- Power cycle the board

When done programming, please do a FULL power cycle of the board before mining with it.

Please share your results with this bitstream on the forums.

Upcoming features:
- HashVoodoo Core (when the REAL performance should start happening!)

Just trying to make Bitcoin a Success... One crazy project at a time. (13rwPKskyATcAq3PpnCikfFG8989DQ8M3c)
HashVoodoo Open Source FPGA Mining Bitstream: https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner
Keninishna
Hero Member
*****
Offline Offline

Activity: 551



View Profile WWW
September 23, 2012, 07:15:34 PM
 #2264

glasswalker you are my hero!
tnkflx
Sr. Member
****
Offline Offline

Activity: 346


View Profile
September 23, 2012, 08:36:56 PM
 #2265

Glasswalker,

Why should I use the hashvoodoo bitstream over Makomk's bitstream?

| Operating electrum.be & us.electrum.be |
Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
September 23, 2012, 09:11:13 PM
 #2266

Latest HashVoodoo Release is up at https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner/downloads

This one uses dynamic clocking (so far to my knowledge only officially supported in MPBM, waiting for word from Kano if he is working on support for cgminer).

I have been looking forward to this, Thank you Glasswalker, I've always liked your dedication to a stable bitstream.
Downloaded it, will take a look over it, but give it a while before installing to it has it's full support.
I've always used Cgminer, it's what I'm use to. Would like to give a bit of time, but hopefully cgminer will support your protocol soon.

Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
Glasswalker
Sr. Member
****
Offline Offline

Activity: 350



View Profile WWW
September 23, 2012, 09:16:58 PM
 #2267

Glasswalker,

Why should I use the hashvoodoo bitstream over Makomk's bitstream?

Up to you really. Makomk's is performing about equal to this one. Try them both see which ones perform better on your particular boards.

Right now this just gets hashvoodoo up to par with makomk's latest. So now my attention can shift to getting the "real" HashVoodoo core working, (the sea of hashers one) which should push me well beyond any other opensource bitstream available in performance (I hope) lol. Wink

So it's totally up to you. (basically a personal preference thing, combined with how your particular boards like each bitstream)

Right now the dynamic clocking does provide some benefits, in that it will tune each chip individually to it's optimal clock. But if you're already seeing 220Mhz from all 4 chips with makomk, then you're likely better sticking there.

I'm not claiming mine's "better", only that it's a different approach Smiley

makomk and myself did collaborate after all so many of the performance benefits are similar between the 2 bitstreams. The main difference is makomk's is still fairly close to the original icarus, focusing on pure performance tweaking, where mine is almost a complete rewrite, working towards a platform to support the sea of hashers core. (and currently using the icarus/ztex core, now with a bunch of modifications, as a stand-in until the other core is ready)

Just trying to make Bitcoin a Success... One crazy project at a time. (13rwPKskyATcAq3PpnCikfFG8989DQ8M3c)
HashVoodoo Open Source FPGA Mining Bitstream: https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
September 23, 2012, 09:39:30 PM
 #2268

Glasswalker,

Why should I use the hashvoodoo bitstream over Makomk's bitstream?
Well, I'm not really going to encourage anyone to use mine on new boards going forward - bitstreams without dynamic clocking are probably unnecessarily risky now we have one that actually supports it. Aside from that, some people have been seeing a speed increase I think, particularly on more difficult older boards? Your mileage may vary.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
September 23, 2012, 10:22:59 PM
 #2269

Latest HashVoodoo Release is up at https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner/downloads

This one uses dynamic clocking (so far to my knowledge only officially supported in MPBM, waiting for word from Kano if he is working on support for cgminer).
...
Still no CM1 board Smiley

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Keninishna
Hero Member
*****
Offline Offline

Activity: 551



View Profile WWW
September 24, 2012, 01:04:36 AM
 #2270

Glasswalker, is your newest bitstream max 220mhz? I ask because I set the limit to 230 in mpbm however I only see the boards go to 220. I ask because I have several boards which are completely stable with your bitstream at 220 mhz and generate 0 invalids.
steamboat
Hero Member
*****
Offline Offline

Activity: 648


View Profile
September 24, 2012, 01:52:27 AM
 #2271

Glasswalker, is your newest bitstream max 220mhz? I ask because I set the limit to 230 in mpbm however I only see the boards go to 220. I ask because I have several boards which are completely stable with your bitstream at 220 mhz and generate 0 invalids.

Quote
I have put hard limits of 50Mhz - 220Mhz in the bitstream (which could be unlocked with fpga editor, I'm not telling you how though lol)

he hard-coded the 220 limit, though you can raise it if you're know how to mess w/ the bitstream.

ASIC miners available for purchase

Those who serve best, profit most.
Glasswalker
Sr. Member
****
Offline Offline

Activity: 350



View Profile WWW
September 24, 2012, 01:58:45 AM
 #2272

Glasswalker, is your newest bitstream max 220mhz? I ask because I set the limit to 230 in mpbm however I only see the boards go to 220. I ask because I have several boards which are completely stable with your bitstream at 220 mhz and generate 0 invalids.

I see steamboat beat me to the response... Either way:

You're not the first to encounter this. Yes I hard locked it at 220 in the bitstream itself for safety...

If after some testing (and word from Enterpoint) it's decided this number should be higher, I can push it higher, in a future build. The concern is even if the boards are mining stable, pushing it much past that could cause damage over the longterm. We need more data before I know if it's safe to exceed 220MHz on this hashing core.

That said, in THEORY (though makomk has confirmed it's damn near impossible) you can use fpga-editor to edit out the hard-lock to essentialy "unlock" the bitstream to go as high as you want... I won't stop anyone from doing that, the files you need are in the release... That said it will be fairly difficult to do Wink (And as I said earlier. Do it at your own risk!)

It's possible we may be able to push higher, but the concern is either temperature (due to the poor packaging the S6LX150 is in), or the VRMs can't deliver the current needed to push much higher with this hashing core.

Going to the HashVoodoo core (the sea of hashers) should allow pushing it beyond 220Mhash/s easily (though that won't be at 220MHz then, as the clock->hash relationship won't be 1:1 as it is now but you get the idea) Smiley

Just trying to make Bitcoin a Success... One crazy project at a time. (13rwPKskyATcAq3PpnCikfFG8989DQ8M3c)
HashVoodoo Open Source FPGA Mining Bitstream: https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner
Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
September 24, 2012, 07:19:34 AM
 #2273

I caved, installing MPBM and the new HV bitstream now, I want to go it a go.

Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
September 24, 2012, 07:29:04 AM
 #2274

I'll probably be releasing BFGMiner 2.8.1 with HV support in a bit, FWIW.

Edit: But I need to find someone who can test it first...

yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
September 24, 2012, 08:13:07 AM
 #2275

Glasswalker, is your newest bitstream max 220mhz? I ask because I set the limit to 230 in mpbm however I only see the boards go to 220. I ask because I have several boards which are completely stable with your bitstream at 220 mhz and generate 0 invalids.

I see steamboat beat me to the response... Either way:

You're not the first to encounter this. Yes I hard locked it at 220 in the bitstream itself for safety...

If after some testing (and word from Enterpoint) it's decided this number should be higher, I can push it higher, in a future build. The concern is even if the boards are mining stable, pushing it much past that could cause damage over the longterm. We need more data before I know if it's safe to exceed 220MHz on this hashing core.

That said, in THEORY (though makomk has confirmed it's damn near impossible) you can use fpga-editor to edit out the hard-lock to essentialy "unlock" the bitstream to go as high as you want... I won't stop anyone from doing that, the files you need are in the release... That said it will be fairly difficult to do Wink (And as I said earlier. Do it at your own risk!)

It's possible we may be able to push higher, but the concern is either temperature (due to the poor packaging the S6LX150 is in), or the VRMs can't deliver the current needed to push much higher with this hashing core.

Going to the HashVoodoo core (the sea of hashers) should allow pushing it beyond 220Mhash/s easily (though that won't be at 220MHz then, as the clock->hash relationship won't be 1:1 as it is now but you get the idea) Smiley

Ok we starting to look more in depth at what is a problem and what isn't. The invalids do seem to some sort of measurement about how much power is going into the chip which is what we most concerned about. Although there is no official limit published by Xilinx of how much current is ok in a Spartan-6 FPGA. Bitcoin mining obviously does operate these FPGAs outside normal expected range at best and there is always going to speculation about how much is too much. It's also likely that even the logic placement within the FPGA makes a difference and that is in part why some bitstreams do better and others don't do so well. What we have seen somewhat subjectively is that "better" bitstreams seem to use use less power at a given performance level. So it's chicken and egg time and the question is the performance better because of lower current or is it incidential to a tight design.

What we can see in the work that have done here already is that power goes up in an exponential curve once you reach a certain frequency which does vary by chip and to some degree ambient temperature. So a lot more power goes in with very little extra performance. That is where we think the problem lies. What isn't 100% clear is what failure mechanism occurs. Is either simply getting the die too hot or bond wires failing or a combo. These 2 things can be interlinked as well so it is complicated.
Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
September 24, 2012, 02:43:04 PM
 #2276

As I said I caved and did try out MPBM, the hashvoodoo dynamic bitstream works a treat and can perform very well at 200 or more.
Some of them will perform fine at 210, some even 220. So far I've managed to keep Invalids down to a low 0.1% since I mine on HHTT and getting an invalid 32 or more difficulty to me stings.
I don't push it, since I really dislike invalids and have spent a long time time using the previous 175 version which never gave me any hardware errors.

Still getting use to MPBM, miss many of the nice features of CGminer, but it works and I'm sure I could get use to it if I could find abit more documentation on things. I've not found much yet other than how to get it installed.

Good Job Glasswalker, impressive.

Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
LazyOtto
Sr. Member
****
Offline Offline

Activity: 476


View Profile
September 24, 2012, 03:17:04 PM
 #2277

Lethos, what is your room's ambient temperature, please?
Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
September 24, 2012, 03:20:01 PM
 #2278

Lethos, what is your room's ambient temperature, please?

I live in England, so probably somewhere between 15-17 Celsius atm, why? I don't like it warm in my house.

Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
LazyOtto
Sr. Member
****
Offline Offline

Activity: 476


View Profile
September 24, 2012, 03:25:27 PM
 #2279

"why?" - Because it is relevant to the temps the chips run at. I.e., their stability at various speeds / overclocks.

I live in Texas. We start putting heavy coats on at your temps. Smiley

And, it would be bloody expensive to cool the house to that temp when it is over 100f / 38c outside.

-- edit --

The room where mine sit is usually around 27c during Summer.
steamboat
Hero Member
*****
Offline Offline

Activity: 648


View Profile
September 24, 2012, 06:12:46 PM
 #2280

"why?" - Because it is relevant to the temps the chips run at. I.e., their stability at various speeds / overclocks.

I live in Texas. We start putting heavy coats on at your temps. Smiley

And, it would be bloody expensive to cool the house to that temp when it is over 100f / 38c outside.

-- edit --

The room where mine sit is usually around 27c during Summer.

lol, I think the "why?" was referring to why it's so cold in his house Smiley

ASIC miners available for purchase

Those who serve best, profit most.
Pages: « 1 ... 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 [114] 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!