Topic: [Announcement] Avalon ASIC Development Status [Batch #1] - page 21. (Read 155339 times)

I am not at all familiar with the what is the specific individual nature of the calculation being done in here, so my opinion may be garbage, just replying based on general digital design principles.

It is somewhat common misconception that if clock speed is being increased to cause timing violations in digital logic sense of the word, the result is somewhat predictable to be either the earlier or later value. In general this is not true, the result of the 32 bit word is not any of the right, ealier or later, but it is total garbage. This even what happens in practice. You are not going to get any predictability what the result is going to be.

The reason is that not all bits of a word are finished at the same time in the calculation logic before the latch, some of the bits are going much later to settle to their correct values when you have some bits that arrived much earlier to their new values. Which bits arrive late and which arrive early can also change quite dramatically. The logic can be much faster going from '0' to '1' than going the other way etc.. So in practice the 32 bit word contains some bits that correspond to the correct result and some bits that are from the earlier result. Or it can be even more complex than that. The output bits can fluctuate wildly at the end of the logic doing the calculations and be in transition when the latching occurs. It is possible that some bit that has value '0' in both the correct and earlier result, but is going to have value '1' as some intermediate calculation value before it settles to its new value '0' from the earlier value '0'. It is even possible in theory that the output of the latch after the timing violation is neither '0' or '1'. The latch might become metastable and this metastability could propagate further to the ASIC so big portions of the ASIC could become metastable ( in theory ).

I am not sure you applied these characteristics of what happens in generic timing violations when talking about this specific instance and case.

Well there may be a fix for errors, however the actual number of errors is easily seen to be small.

Good example is in the Icarus FPGA, we know the expected performance, we know the number of valid shares submitted, we know the number of invalid shares returned by the device and we ALSO know the expected number of valid shares for the given device performance.
It's not some run-away large wasted amount of work done - it IS very small.

Hmm, what is this 'golden nonce' ?

Or we could just do something stupid like this in the combinational logic:

currnonce <= nonce - 131;

and end up with a potential race condition, that does this:

LX110T:00000002d0bf3e4cd39201f1c70ff8c81c4f4d600405e89341df64ea00000163000000003ed5887 4bfd5ab6a7e30d6948d8d08bd620145fc52be75c6a9e0171801994b3250d015401a04fa62
   Got H-not-zero share 2d8ab702

0000000268558236d58cb3c63c0cf4a63edf7dc8315fa103866447710000043400000000deeb696 f29559d6319c87be74f077c369cbbc9afc9d344c97ae6ba55d201b7a650d00ae81a04fa62
Got H-not-zero share 2c04ea5f

When the core temp changes from 65 deg c to 66 deg c, as the temp increases by each degree so does the number of defects.
BUT.... and here is the million $ pinch.......,
There was not a SINGLE error last week when the ambient temperature of the room was 14 deg c now it is 21 deg. c

and this is with a core that is only 200MH/S from a single core.

I'm not having a go at anyone, but rather pointing out an issue that effects ANY multi-cored logic design.
The issue I have with all this, is that it went:

CPU->GPU->FPGA->ASIC

and now here we are talking about:
ASIC+CPU to correct for possible piss poor logic design, next it will be "HAY, I have an Idea, Let's use ASIC+GPU to find possible missed nonces ,when we might have dropped one"

At a fundamental level, loosing a "nonce" is not just a case of hay its only .00000000016% of the nonces I generated, but the fact that you wasted the resources AND its not scaleable. (all so any figure thrown about like this is unverifiable, since you would need to know ALL the nonces that were generated to obtain the figure)
Anyway  bit-coin mining is not a static field any design that does not take poor logic design into account now at this stage of the game, is going to be severely shafted as the hashing rates of the devices climb, because both the number of cores and speed is only going to climb.

My point is not that a miner is going to loose a shit load of money because of lost nonces, BUT rather a fundamental flaw in the thinking of a designer, because there is a fundamental race condition.

Can't we all just get along?  Remember, Santa is watching everything you do .

Hey its my favourite delusional idiot agreeing without another delusional idiot
You 2 chaps should compare notes on your flawed argument methods.

abeaulieu is a proven hypocrite who is also not above blatant lies despite his own words being quoted.

And Inaba, well - calling you a delusional idiot is quite harmful to regular people with delusions, you are something rather special.

Good to see you have stopped cowering in the BFL forums and come online to agree with your sock puppet.
Care to share what Avalon or Basic is currently up to ?, You seem to have more "facts" on their own development than your own.... assuming it even exists outside your delusions.

Haha dude, it's like arguing with a wall, that one.  If you search back (a few months I think), there's a post somewhere about how he was declared mentally incompetent in Australia by the government.  I think he lives out in the boonies somewhere Ted Kaczynski style... You can't argue the crazy out of him.

It cant be made any clearer as I have provided direct quotes citing your hypocrisy.

You refuse to acknowledge, ask for substance when its slapping you in the face and then attempt to side step yet again.
You a hypocrite that suffers self delusion, dont expect others to indulge your fantasy.

@mem, you really need to find something better to do with your time. I won't bother quoting your attacks because I don't really think there is anything substantive there to quote. Coloring my text red does not add some polarizing quality to make phrases contradict, much less does the content itself contradict. I'm unsure of which "issue" I have sidestepped. I have stated plainly that I am not a "shill" as you call it, and I will expound by telling you that I am in no way a representative or someone who has received compensation from BFL and I will remain an impartial member much more interested in the technology than all of this meaningless drama.

I realize you do not like Butterfly Labs, and I do suspect that one day you will get over that. Whether it simply be lapse of time or by way of you screaming from the mountain "I was right, Butterfly Labs was a scam and will never deliver."

At that note, can we please give Avalon back their thread.

Hilarious - I have highlighted you being the very definition of a hypocrite and yet you side step the issue - still this is what BFL shills are known for.

In case you are to simple minded to realise when your own actions betray you I will break it down for you.



You support Inaba trolling an Avalon thread but then ask PuertoLibre to stop trolling BFL, You are a hypocrite and an extremely transparent one at that.

Given that Inaba is an idiot prone to abusive rants deception and blatant lies even the best of days while PuertoLibre is direct and to the point.
Id argue that it makes for a very convincing argument that you are just another BFL shill.

@ Avalon

Hardcore FS release some interesting documents in this thread on actual ASIC devices:

http://hardcoreforensics.com/blog/2012/12/10/bitcoin-mining-publicly-available-vhdl-source-code-and-the-xilinx-xupv5/
http://rijndael.ece.vt.edu/sha3/chip/sha3-asic-userguide.pdf
http://www.risec.aist.go.jp/project/sasebo/

With proper design, #2 need not even be apparent to the miner software. The microcontrollers that handle communications and control of the ASICs should be more than powerful enough to verify the hash returned by the ASIC and test the range around it should it not be valid. Even at 66GH/s that's what, around 15 diff1 shares per second? No reason that cgminer would even need to know about it.

I get a feeling that a longer explanation is required for those unfamiliar with digital logic design.

The issue isn't really about losing one in billions of hashes. It is about gaining the timing margin (a.k.a. overclocking headroom) in the design.

Of course Avalon's logic is secret, but I'm going to discuss the problem based on one of the open-source FPGA hashers. It had a critical timing path in the logic that latched the "golden nonce". Since the design was 125-deep pipelined it had a hardware that subtracted constant 125 from the nonce counter before sending it out of the chip.

Now we have two ways to speed up the above design:

1) remove the 32-bit wide constant subtractor. This will gain a fraction of a nanosecond on every hash tried. It is very easy to subtract 125 in software from the nonce downloaded from the chip.

2) acknowledge that the timing violation may occur and the nonce latched may not be the exact one that solved the block, but a next one or previous one, depending on the details of the latching logic. It is somewhat more involved, but still easily doable in software: recompute the hashes for nonce values n-126,n-125,n-124 and use the one that solved the block. Again this will make the design more tolerant to overclocking for every hash tried inside the chip.

Obviously 1) cannot be applied to the ASIC chip or closed-source FPGA bitstream. But the method 2) remains applicable, just use a different set of test values.

Well, I was enjoying the technical talk between the three others. I actually want to hear what they have to say.

I want to see what they hash out [pun intended] between themselves on how they think the process should be handled. I dunno about anyone else, but at the end of that discussion I am going to ask Avalon teams members...."So your thoughts on this technical discussion is...?"

Then they will say something clever (one hopes) and let us in on some insight into how they handled the problem at the firmware or silicon level. That will benefit all of us, don't you think?

I'm actually quite impartial, and most certainly not being paid by BFL. You're just an idiot, mem, and there's no cure for that.

so... troll, reverse troll, counter troll, counter reverse troll, triple sow cow double hypocrisy back flip =  useful thread?  

I think it's better to keep things on topic.   Back on topic about the ASIC design of The Avalon Team - Thanks, Inaba for the thoughtful feedback.

abeaulieu is a hypocrite that knows exactly what he is doing and only does an average job of trying to hide it.
Your goal spread FUD against avalon while propping up the polished turd BFL.
Shill is a Shill is a Shill.

Actually, no. You or I are somewhat impartial. Inaba is a competitor. Any information he might put forth is extremely biased and anti-useful.

Just as much useful information as you or I may have...