[Announcement] Avalon ASIC Development Status [Batch #1]

[MrTeal]

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.

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.

[1714057097]

1714057097

[1714057097]

1714057097

[PuertoLibre]

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

[mem]

On second thought, don't talk to me Inaba.

Talk to me when you actually have delivered 100 [ASIC] units of a product your company sells. Until that time shooo....I disown you as a legitimate vendor. Begone from my sight!

Edit: and uh, best of luck.

Wonderful PuertoLibre, does this mean you will leave this BFL thread and go to the actual ASIC vendor's thread? We will be deeply saddened by this loss.

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.

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.

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.

Wonderful PuertoLibre, does this mean you will leave this BFL thread and go to the actual ASIC vendor's thread? We will be deeply saddened by this loss.

Inaba has no idea whatsoever how Avalon is doing things, so he has no useful info to add to the thread, therefore he's just trolling as usual.

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

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

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.

[abeaulieu]

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

[mem]

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

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.

[Inaba]

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

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.

[mem]

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

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.

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.

[bce]

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

[crazyates]

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

[hardcore-fs]

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.

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

[hardcore-fs]

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.

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.

[kano]

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' ?

[ab8989]

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.

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.

[MrTeal]

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"

We already have that kind of combination, and it's no like ASIC will directly interface the network any time soon. Baring some pool op correcting me, I don't think any pools are using GPGPU code on their backend, and Bitcoind is obviously using CPU cycles to deal with the output of the mining device.

Anyway, regarding piss-poor design, I really can't speak on this case (and honestly neither can you). We don't know how Avalon has implemented their design, all we know is that they have a serial interface and there's no reason to think that will be a bottleneck in their design, even will multiple devices sharing the bus.

[beekeeper]

Hmm, what is this 'golden nonce' ?

Lol man, you ever were curious to look over HDL files from those public FPGA projects?

[kano]

Hmm, what is this 'golden nonce' ?

Lol man, you ever were curious to look over HDL files from those public FPGA projects?

No, I just remember the golden nonce (that xiangfu put) in the Icarus code that I replaced with a better one - so I'm curious about there being some 'generic' golden nonce being referred to since it was indeed named above without reference.

[beekeeper]

Hmm, what is this 'golden nonce' ?

Lol man, you ever were curious to look over HDL files from those public FPGA projects?

No, I just remember the golden nonce (that xiangfu put) in the Icarus code that I replaced with a better one - so I'm curious about there being some 'generic' golden nonce being referred to since it was indeed named above without reference.

One example ( fpgaminer_top.v):

Code:

		// Check to see if the last hash generated is valid.
		is_golden_ticket <= (hash2[255:224] == 32'h00000000) && !feedback_d1;
		if(is_golden_ticket)
		begin
			// TODO: Find a more compact calculation for this
			if (LOOP == 1)
				golden_nonce <= nonce - 32'd131;
			else if (LOOP == 2)
				golden_nonce <= nonce - 32'd66;
			else
				golden_nonce <= nonce - GOLDEN_NONCE_OFFSET;
		end 

[nathanrees19]

loosing a "nonce" is not just a case of hay its only .00000000016% of the nonces I generated

To an end-user, that's exactly what it is. If lost nonces (even if they happen in pairs) are a less common failure mode than internet dropouts, pools going offline and stale shares, then only logic-purists will care.

you wasted the resources

Look at it this way: If a 1GH/W chip has a 1% nonce loss rate, and a 0.5GH/W chip has a 0% nonce loss rate, then one would be wasting power by using the latter chip, even if it is logically perfect.

Tldr;

[fpf]

Hmm, what is this 'golden nonce' ?

The one (or more) out of the 4294967296 nonces that solve the work and can be submitted & can/will be accepted by the pool server for the task/workload received.

About loosing some nonces because of hardware errors, yes that can happen, and I don't think that is some new issue, should also have been the case with GPUs especially when you overclocked them...

@The one concerned (Forgot where I read this)
using & loosing a clock cycle or multiple clock cycles, to read out the found "golden" nonce from any dedicated mining hardware is totally no issue at the clock rates they run on...

A lot of the current hardware on the market looses a lot more time doing that than "4 clock cycles" and I really mean a loooot more.
Let's take the Icarus as an example, even if it can latch the result in one clock cycle it will need a lot of actual clock cycles until the result is finally at it's destination. At the end of the day, does it matter? no.... because for a full range scan you need 4294967296 clockcycles... (assuming the device does 1 nonce per clock cycle and scans the whole range)
4294967.296 clock cycles would cost 0.1% of the performance of the device.... It's still totally insignificant.

Icarus Response:
(4 bytes + 4 x start and 8 x stop bits at 115200 bps (it uses 2 stop bits for each byte if I remember right) or twice this time in case the nonce came from the cascaded FPGA and the nonce gets "forwarded" + the delays by the USB to uart chip + the delays caused by the USB system itself (package based) and the drivers for the usb to uart chip.. + the operating system + the actual miner software + the whole thing again even longer this time because uploading a new "task" takes even longer... - at the end of the day, does it matter? no.... - now you know why even thousands of "clock cycles" are still totally insignificant for such devices...

About multiple cores on a single chip - there are 2 ways - either each of them get their own "work" or the range gets split, it's possible that there is more than 1 "golden nonce" to the "work" - however having more than one golden nonce at the exactly same clock cycle is very unlikely.

FPF

[fpf]

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.

Yes, would be great if Cgminer would have such a option, where we could manually define such prefixed nonce modifications or even a certain range for a "rescan" over the PC's CPU in a defined range. As I know, Cgminer checks already if the "golden nonce" submitted to it is valid and if not counts it as hardware error, so a implementation should be rather easy and also work with any hardware supported by Cgminer...

FPF