Cairnsmore1 - Quad XC6SLX150 Board

[Lethos]

"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

I like it cold, lets just say I am abit unusual my natural body temperate is 3 degrees Celsius above normal and often runs higher than that.
It never gets to 27, my partner is lucky if the house gets over 20 in the house. I could never survive in a hot environment like Texas.

[1713547844]

1713547844

[1713547844]

1713547844

[ocminer]

Kano when can we expect a working cgminer version with the new hashvoodoo bitstream ?

[LazyOtto]

Kano when can we expect a working cgminer version with the new hashvoodoo bitstream ?

https://bitcointalk.org/index.php?topic=78239.msg1215095#msg1215095

[ocminer]

Would remote access to a board with the latest (dynamic) bitstream be helpful ?

[kano]

Would remote access to a board with the latest (dynamic) bitstream be helpful ?

As I have mentioned elsewhere - not really.
cgminer can mine on a CM1 - and even has extra options I wrote to support other hardware - but that's about as far as I'll go without having the hardware.

Supporting the hardware does require having the hardware - simple.

Good example of that was the recent HW: change I did in cgminer to make all devices go through the same place.
I don't have a ztex and the code there is very different to the other devices.
I looked at it and since I can't test it when I'm working on it - I asked about it on the forum to get help.
Someone replied, but by then I didn't have time (my fault not their fault) so in the end - I just left the ztex code alone.

If, every time I make a change, I need to chase up and find someone with hardware - it's not gonna happen.

All the timing code, supporting different speed bitstreams, etc was simply coz I have 2xIcarus
I actually wrote it a while before I put it in git - and of course used extensively to work out the timing numbers.
Without having the Icarus hardware, I would never have written it.

With the hardware - I of course have an incentive to make it perform better and listen to suggestions, and no need to find someone if I do make a change - which in my case certainly kills the creative process.

Actually I'm not quite sure why I'm explaining this - coz it really is obvious - but I guess for my own sake

[Luke-Jr]

If, every time I make a change, I need to chase up and find someone with hardware - it's not gonna happen.

Totally sympathize with kano on this point. I've got code for the dynamic clocking, but it's a real pain to try to keep up with different people availability for testing and debugging...

[yohan]

Controller Rev 1.6 is coming.

We have a few days testing to ensure that we didn't introduce any problems in the update. It offers for the first time a revision indicator. That uses a flash code on the Controller LED when held in reset using SWITCH1. We also did some work to reduce current and we appear to have taken 80-90mA out of the controller section power consumption. That might not seem a lot but if supplied from the 12V that's about 1W out of the board consumption or 2-3% of normal consumption when mining. If power is coming from the USB side then 80mA out of a 500mA maximum USB spec is a reasonable percentage but more importantly it might improve the reliability of the USB interface for some customers. We won't really know the latter until a number of you have run it and we get enough feedback of people "seeing" a difference. USB power surges could explain some of the occassional port disconnects reported and that is what we are hoping to improve with this change.

[Lethos]

Not always easy for the testers either you know Luke and Kano. I love you work, but there are two sides to it.

[kano]

Not always easy for the testers either you know Luke and Kano. I love you work, but there are two sides to it.

Yeah 2 sides
The free software and the profit from mining

[LazyOtto]

Latest HashVoodoo Release

Two questions:

1) Does anyone have duration / stability data yet for this release? I.e., is it staying up continuously for days?

2) Has it been tested reverting the controller from the 'Glasswalker' flash/firmware back to the Enterpoint 1.x flavor?


-- edit --
BTW, status report on my units' stability.

Seven days continuous operation so far with makomk's 200mhz version on two CM1's 'daisy-chained'. (Single USB cable to the two of them with in master/slave configuration.)

Ambient temperature about 80f / 27c.

Invalid rate of: 0.13 / 0.20 / 0.34 / 0.35 percent.

[LazyOtto]

Latest HashVoodoo Release

Controller Rev 1.6 is coming.

Glasswalker, do you have any thoughts about how your controller compares to the Enterpoint 1.5 and upcoming 1.6 versions in regard to the power consumption issues discussed by yohan in the post referenced above?

[Lethos]

Latest HashVoodoo Release

Two questions:

1) Does anyone have duration / stability data yet for this release? I.e., is it staying up continuously for days?

2) Has it been tested reverting the controller from the 'Glasswalker' flash/firmware back to the Enterpoint 1.x flavor?

1) I've been using it since it's release pretty much. Yes it's stable and is fine to be used continuous for days.
Invalids are always below 1% on my boards.
I have tried 2 programs to mine on it, both MPBM and I have been one of the testers for Luke-JR (BFGMiner), so that is the only stops I've made in mining.
MPBM is atm a little easier to tell invalids and rejects. Invalids are in the long term easily below 0.5% and it not unusual that some chips will report 0.1% or less invalids. I have experimented with all the way up to 220, it didn't create crazy amounts of invalids (still under 1% on average), it just sometimes for a short time went over 1%, to me that was unacceptable.
MPBM has pretty good set of rules, so it's speed increases are halted as soon as it steps over 0.1% invalids. I'd gotten use to essentially 0 invalids on his previous HV 175 bitstream, so I set the bar high on what I expect from it.
Still testing BFGMiner, so it's best if I don't comment on that at the moment.

2) Not tried reverting back to the enterpoint controller so I could use Makomk's bitstreams.
Stability has been really good since moving so not felt the need. Is there a reason to believe we can't revert back?

[LazyOtto]

2) Not tried reverting back to the enterpoint controller so I could use Makomk's bitstreams.
Stability has been really good since moving so not felt the need. Is there a reason to believe we can't revert back?

No.

Just looking for solid confirmation.

Merely looking for warm fuzzies that no bridges are being burnt.

--
TY for your response, Lethos.

[Slipbye]

I've upgraded to Glasswalkers controler while testing it and downgraded back to 1.3, back up to glasswalker, then back to 1.5 before going back to Glass's. Did this to check it would be down gradable. Works fine on the 2-3 boards i tested that theory on.

[Glasswalker]

Glasswalker, do you have any thoughts about how your controller compares to the Enterpoint 1.5 and upcoming 1.6 versions in regard to the power consumption issues discussed by yohan in the post referenced above?

Yes actually, talked to yohan about this a day or two ago.

So they disabled parts of the controller (most notably the dynamic clock generator chip) (not sure if this means they actively did something to "turn it off" to reduce power, or just "aren't using it").

The parts they disabled, I'm also not using in my controller bitstream right now. BUT I haven't done anything explicitly to reduce power consumption.

So... I'll need to clarify with them, to confirm if I have to add in some explicit code to disable the clockgen for example to reduce power usage. But ultimately that shouldn't be a problem (and possibly, we're already saving because I'm not using it, not sure, though I suspect I need to "turn it off").

As for the up/down chaining, we've discussed that. It's on the roadmap, but not there yet.

Hope that helps.

[LazyOtto]

Latest HashVoodoo Release

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

Well, it appears that something went wrong during flashing on one of my two boards. (The other one is happily hashing now with dynamic clocking.)

Cannot get p2 or p3 to successfully flash. (p0 and p1 do flash and successfully verify.)

When attempted to revert the controller firmware to Enterpoint's 1.5, spiprog states that "Device NOT XC3S50AN" and asks if I've set the correct DIP Switch.

Looks like I'll have to buy a jtag cable.
(Unless someone has magic advice to offer.)

Does anyone have experience with this one:
http://www.amazon.com/SainSmart-Download-Programmer-Xilinx-Platform/dp/B0057OC5VQ/ref=pd_cp_pc_0

--
Yes, I know I could find something cheaper via eBay, but this Amazon purchase could be delivered tomorrow.

[LazyOtto]

Glasswalker, do you have any thoughts about how your controller compares to the Enterpoint 1.5 and upcoming 1.6 versions in regard to the power consumption issues discussed by yohan in the post referenced above?

Hope that helps.

Satisfies my itch to know.

Yes, thank you.

[Slipbye]

Lazyotto: To downgrade from glasswalker back to 1.5 try dip switch 3 and dip 6 both in the off position. once back on 1.5 then try to flash fpga 2+3 with glass's bitstream and then upgrade the controler back to glass's if you want to hash with it.

I've found on a couple of boards you get stubborn fpga's when flashing from makomk>glass if you have already upgraded the controler to glass's.

What i do now is flash all the fpga's first to glass's while still on 1.3/1.5 and then once all fpga's are flashed update the controler to glass's.

Let me know if this helps, if not hop on irc into #cm1 and i'll grab one of my boards and confirm the dip switchs for you.

[LazyOtto]

Lazyotto: To downgrade from glasswalker back to 1.5 try dip switch 3 and dip 6 both in the off position.

Yep, that's what I thought I was doing.

I'll go back and retry, again, just in case one of the DIPs is acting a bit flakey.

BTW, I did bring it up in the current 'bad' condition and it successfully mines with dynamic clocking on two of the four COM ports. (Still booted in Windows atm.) The other two COM ports are not recognized by the MPBM Cairnsmore worker.

[LazyOtto]

Nope, something low level went wrong with this board.

Got out the VOM and verified that the DIP switches are on/off working correctly.

I've ordered the jtag cable I referenced a few posts ago. (Dithered too long and I won't get it until Monday rather than tomorrow.)

If it can't be fixed with the jtag cable I'll have to start a conversation with yohan about an exchange. bummer