Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 15. (Read 286370 times)

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

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.

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

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

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

https://bitcointalksearch.org/topic/m.1215095

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

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.

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

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

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

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

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.

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.

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

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

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)

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

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.

Still no CM1 board