Cairnsmore1 - Quad XC6SLX150 Board

[LazyOtto]

-- post deleted --

yohan beat me to the answer.

[1713998728]

1713998728

[1713998728]

1713998728

[1713998728]

1713998728

[Lethos]

@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.

[Glasswalker]

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!)

[Keninishna]

glasswalker you are my hero!

[tnkflx]

Glasswalker,

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

[Lethos]

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.

[Glasswalker]

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.

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

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)

[makomk]

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.

[kano]

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

[Keninishna]

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]

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 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.

[Glasswalker]

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 (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)

[Lethos]

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

[Luke-Jr]

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]

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 (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)

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]

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.

[LazyOtto]

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

[Lethos]

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.

[LazyOtto]

"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.

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]

"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.

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