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

[beekeeper]

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

2112 is talking about modifications in FPGA bitstream, ofc software modification to cope with new bitstream would be trivial.

[1715017339]

1715017339

[fpf]

I know that, but the consequence of those changes is the fix/option in the mining software - Cgminer is just an example here. It's actually the best location for that task since all the functions are already implemented, there is just a special option needed to re-purpose those functions. (such as the nonce validation)

The first option would be to deduct a certain fixed value from the nonce, it's much more efficient for the mining software to do that than it's done in some of the current bitstreams. The next option would be allowing Cgminer a certain range for the nonce validation. (To do a few nonce calculations on the CPU is not a big deal and it could save that (only slightly) corrupted nonce from being ignored and regarded as hardware error...)

[beekeeper]

In my humble opinion..
There is a wall.. one side, regular BTC developer, the other side people who understand the hardware..
Stop trying to bridge, it is not worth..

[Frequency]

Any real news yet or some project update !!!!! 

[hardcore-fs]

I know that, but the consequence of those changes is the fix/option in the mining software - Cgminer is just an example here. It's actually the best location for that task since all the functions are already implemented, there is just a special option needed to re-purpose those functions. (such as the nonce validation)

The first option would be to deduct a certain fixed value from the nonce, it's much more efficient for the mining software to do that than it's done in some of the current bitstreams. The next option would be allowing Cgminer a certain range for the nonce validation. (To do a few nonce calculations on the CPU is not a big deal and it could save that (only slightly) corrupted nonce from being ignored and regarded as hardware error...)

You mean like adding lubricant to your tiers so you can go down hill faster.

The first option would be to deduct a certain fixed value from the nonce, it's much more efficient for the mining software to do that than it's done in some of the current bitstreams.

You sir are a fucking idiot.
FPGA's process in true parallel.
 I can process thousands....(nay tens of thousands) of 32 bit subtractions in an FPGA, before you have even fucking read the numbers into your CPU registers.

[Bogart]

Hmm, what is this 'golden nonce' ?

I think if you catch the golden nonce, it's worth 150 points and the match is over.

[nathanrees19]

Hmm, what is this 'golden nonce' ?

I think if you catch the golden nonce, it's worth 150 points and the match is over.

They really ought to nerf that down to 15 points. Then the rest of the team would matter.

[fpf]

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.

@hardcore-fs
Please read the context in which things were said:

The 32-bit wide constant subtractor in that design limits the whole speed of the design, you can speed up the whole design by removing that subtractor and simply deduct the constant later from the "nonce" received from the chip to get the "golden nonce"...
It's simply about gaining some overhead, the weakest link breaks the chain.

If you can gain even more overhead by assuming that the latched nonce in the chip is not the "golden" one but very close by as stated by him, a few nonce validity checks nearby will finally reveal the "golden nonce" this way you can push the chip in terms of clock and internal timings to its limits and even a bit beyond.

If this can improve the maximum speed that can be reached for the device significantly - in exchange for a bit of insignificant cpu time every nonce found (we talk about crosschecking only a hand full of nonces here vs. the workload, and that roughly every 10.7 seconds for a 200 mhz core) than yes - it's an acceptable way.

You mean like adding lubricant to your tiers so you can go down hill faster.

You need grip to make use of the car's engine, no point.. but IF the task is to get the car down the hill the fastest way possible with engaged breaks, without the need of being able to stop it and all you have is an unlimited supply of lubricant - than yes adding lubricant to both the street and the tiers to accomplish the task is the way to go.

You sir are a fucking idiot.
FPGA's process in true parallel.
 I can process thousands....(nay tens of thousands) of 32 bit subtractions in an FPGA, before you have even fucking read the numbers into your CPU registers.

Posting insults & very basic / unrelated facts (of actually any logic or programmable logic) doesn't help here.
"In the land of the blind, the one-eyed man is king"

For interest take a look at one of the ASICS floating about, they have given a proposed pinout showing 8 data lines and some strobes.
WTF.... even the nonce will require 4 CLK cycles just to get it out of the chip and they are claiming this design is good into the GH/S range?

Here we go a "truly parallel" 8bit Data-bus
Of course it's good into the GH/s range, the traffic is low since only the results ("golden nonces") need to be collected, everything else gets discarded already in the chip... The only way to make it faster than it is right now would be having a 32bit databus to get the whole nonce out of the chip in one CLK cycle, would it matter? no... waste of resources and space, 24 more pins/tracks to deal with for no real benefit... the same is true for getting the "work" to the chip of course (which is of course more than 4 bytes...)

Edit: Should be said for the sake of completeness, those 4 clock cycles needed to collect the nonce will be from an external controller and are not directly related to the internal clock used by the hashing chip, further, the clock for collecting the data will be slower than the internal clock used by the hashing chip. Changes nothing about the situation though.

[hardcore-fs]

As regards the

Posting insults & very basic / unrelated facts (of actually any logic or programmable logic) doesn't help here.
"In the land of the blind, the one-eyed man is king"

Is the above even English?

you made a hardcore statement about 'nonces/golden nonces'

The first option would be to deduct a certain fixed value from the nonce, it's much more efficient for the mining software to do that than it's done in some of the current bitstreams.

it is irrelevant in "what" context it was made,no matter how you try to spin it, A VERY clear statement was made and I cannot think of ANY situation where the "mining software" is going to be able to do that in a more efficient way than pure logic.
EVEN IF the value was subtracted at EVERY stage of the nonce calculation.
In fact in at least one public core IT IS done this way, and do you know what... the  calculation as regards time is ABSOLUTELY FREE.

The 32-bit wide constant subtractor in that design limits the whole speed of the design, you can speed up the whole design by removing that subtractor and simply deduct the constant later from the "nonce" received from the chip to get the "golden nonce"...
It's simply about gaining some overhead, the weakest link breaks the chain.

nope!!!!, it does not "limit the speed", because the subtraction CAN be done at the SAME TIME INSIDE the logic, because you ALREADY KNOW THE VALUE OF THE NONCE BEFORE you start the SHA256(SHA256(x)) Hash.



Notice "nonce" & "currnonce" & clock, one lags the other by 131 in this case , because that is the depth of the current nonce calculations, but we can clearly see the calculation between the two nonces  occurs & ends on the same clock cycles, making it effectively "free" to calculate the difference.


if you cannot understand the basic principles of digital logic, then I'm not going to waste my time trying to explain it further.

[Dhomochevsky]

I don't mean to interrupt this most interesting and totally not boring argument, but I feel like I need to second Frequency above: Are there any chances to get another update soon? Maybe one last update before christmas? Also, as far as I understood it, there was a test/demo planned for the end of December. Is that still the case? Or has the demo been moved to January?

Thanks.

[PuertoLibre]

I don't mean to interrupt this most interesting and totally not boring argument, but I feel like I need to second Frequency above: Are there any chances to get another update soon? Maybe one last update before christmas? Also, as far as I understood it, there was a test/demo planned for the end of December. Is that still the case? Or has the demo been moved to January?

Thanks.

Seconded, great question.

Add to that, is the schedule looking good so far?

[tacotime]

Hmm, what is this 'golden nonce' ?

I think if you catch the golden nonce, it's worth 150 points and the match is over.

http://www.youtube.com/watch?v=HPVhmZodaLA#t=1m35s

[kano]

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

Well that's just using the term 'golden' to mean 'valid' or 'share'

(yes I have spent a lot of time looking at nonces )

I was meaning that: Was there a specific 'test' nonce that had been referred to as 'THE golden nonce'?
I take all the replies to mean the answer is 'no' - it's just being used as a term for a valid nonce.
Your device generates ~20,116 of them per day per GH/s - so 'golden' seems a bit of an over zealous name

In Icarus, what happens to detect the device, is to send specific work to the device and expect a reply with an expected nonce value
Xiangfu called this nonce the 'golden_nonce'
What I did on the cgminer code was find a faster (better) one that took ~0.53ms to calculate so when Xiangfu had roughly 40 Icarus it didn't take long to test them all - only a few seconds.
I just didn't know that people referred to the valid values, in general, as 'golden' - I was wondering if there was a specific work+nonce that was called 'golden' due to some special attributes of it (which the answer is 'no')

[hardcore-fs]

I don't mean to interrupt this most interesting and totally not boring argument, but I feel like I need to second Frequency above: Are there any chances to get another update soon? Maybe one last update before christmas? Also, as far as I understood it, there was a test/demo planned for the end of December. Is that still the case? Or has the demo been moved to January?

Thanks.

Seconded, great question.

Add to that, is the schedule looking good so far?

Its all the same, Everyone says a 'demo' is coming soon , OCT,NOV,DEC, Jan?
and yet we do not EVEN see ANY prototype devices or simulations, If I can simulate "non-existant" logic on a PC, then surely people with designs should be able to show some "waveform" diagrams..... and yet we see nothing.


I'm going to be releasing my own ASIC product and unlike the competition I will release a die picture.


4 cores  divided up into 20*2 engines each core giving ~250Ghs or about 25GHs each engine, which is well within the figures currently being bounce about by various teams.
These 4 cores are going to be multiplexed by 8 internal FIFO's, and whilst I won't be delivering product until early April 2013, I think it is well worth getting involved in the investment now.

[Bogart]

I'm going to be releasing my own ASIC product and unlike the competition I will release a die picture.
http://postimage.org/image/5jqixucf3/

A die picture, you say?  It even shows the purdy rainbow diffraction effect.

You would seem to imply that the described die has already been produced.

Surely our collective leg is being pulled...

[nathanrees19]

Its all the same, Everyone says a 'demo' is coming soon , OCT,NOV,DEC, Jan?

Really? I've only noticed Avalon having a specific, clear goal of demonstrating a working chip around the end of the year.

and yet we do not EVEN see ANY prototype

If they had one, then that would be the demo...

[PuertoLibre]

@ Team Avalon

What happened to the last Thursday update? (from TSMC?)

[ngzhang]

@ Team Avalon

What happened to the last Thursday update? (from TSMC?)

everything is going well, everything is going on time.

[nathanrees19]

@ Team Avalon

What happened to the last Thursday update? (from TSMC?)

everything is going well, everything is going on time.

Great! Any chance of pictures of chips or PCBs any time soon?

[Bogart]

I see the website has a countdown to shipping time now.

http://www.avalon-asics.com/