Bitcoin Forum

Here it is!
More info later
https://i.imgur.com/clEOX4X.jpg

Interesting... Cost? Hash rate?

This is how AMD supremacy ended one night in the bin... ;D

Hashrate?

I am watching this :)

Looks interesting, will wait for the spec.

let me guess... 1.5kh/second?   ::)

my thoughts exactly..

otherwise.. I'll take 10!  :P

Great!
How many buses? Have you got rid from refresh logic? Is burst mode used?

its still progress :) best I have seen so far is 45kh maybe this will beat it

Was this just a teaser?

 :D

Watching closely.

Now you have my full attention.

45 khash/sec on multi core setup or high end fpga that u will never get roi..... I bet.

I doubt was spartan6

no idea what it is and if I did know I wouldn't be aloud to tell you lol

Nice....

I'd be interested to see the numbers as well.

Good going

Watchin.

watching ;D

Hmm. If this is real... :D

Looks pretty real. Just a matter of if it works or how well it works (and if you can add multiple chips to the board)

I am thinking for 100kh+ maybe even more I am guessing it is using multiple ram sticks to get the bandwidths up and the latency down and it wont need that if its only a couple of kh

mark.

interesting to have 1..pls

Bzzzzzzzzzzz ;D

I'm not watching.

I am surprised BFL isn't already accepting pre-orders for a 1 MH/s "Litecoin Single" and 100 MH/s "Litecoin minirig" with delivery in 4-6 weeks (TM).

A million Quark question: where all the GPU hashpower will go when this thing will be released?

We don't know if this thing will be released.  It may not be economical yet.  It is an inevitability that dedicated devices to mine LTC (and clones) will eventually be created though.   The creators made sure of that by crippling it's memory hardness (LTC 128KB max scratchpad vs Scrypt default 16MB)  I would imagine when that happens most GPUs will end up on ebay.

Seems this design employs several independent memory buses, so the price of FPGAs will be measured not in LUT/$, but in pin/$. Great time for people with access to used components market.

Seems like fun project.

I waiting for numbers, but I guess GPUs are safe for now

…Looks at LTC difficulty, without existence of Scrypt Asics....

…Looks at current LTC value, without existence of Scrypt Asics....

…Idiot

Yet another FPGA with RAM.
What's new here ?

I have seen tons of pics like this in the last 3 months, and today I still can't say STFU AND TAKE MY MONEY.

You've seen tons of pictures like this?  Can you point me to those pictures because I've never seen a picture like the above.

this would be an FPGA not a ASIC!  FPGA's didn't kill the bitcoin world and they won't kill the litecoin world either

BFL CEO: U have PM, I'm not here to advertise something.

By the way, I haven't said nothing against this, I'm just saying "where is the news? It has achieved good results? There are some noteworthy hashrate?", a PIC of an FPGA with DRAM means nothing.

I hope to see a good hash rate coming out  from this device!

watching

The next great unicorn....

I'm aware that this is a FPGA which is doable with Scrypt, however I'd like to go off in a minor tangent. People seem to underestimate how difficult it will be to create a Scrypt ASIC. SHA256 Asics have been used for many many years. They were not new technology, meaning the billions of dollars of research that others had done getting SHA256 ASICs working is not there already for proposed Scrypt ASICs. All the BTC mining ASIC companies needed to do, was make a product that would work for BTC specific hashing, rather than what they were and still are used for, encrypting and decrypting files. The company that decides to start making LTC Asics will need a whole lot more than a few hundred thousand BTC to get their products out the door.

Back on topic, LTC FPGAs actually aren't that difficult to make in theory. LTC's Scrypt hashing requires actually a much lower amount of memory than other scrypt implementations (I believe its 196mb/cycle although I may be off) at that point, or whatever it actually is, I remember the math behind it, but not the actual numbers, you can provide additional hashing power at 1/2 the memory required, and you can still end up with a higher hashrate over current GPUs, while still using fairly inexpensive FPGA technology. So rather than needing to create a new FPGA board that can handle uneconomical amounts of memory, you can just work on designing a chip that will hash fast, and lose performance based on how much memory you can actually supply.

I'll look back over my research tomorrow, and get all of the numbers and such down. I'm tired so I may have said something dumb, I'll correct it later.

LTC uses the parameters (2^10, 1, 1) which results in a token 128KB max scratchpad size.  That isn't a typo it is kilobytes.  The default Scrypt parameters (2^14, 8, 1) result in a 16MB max scratchpad size roughly 128x as "memory hard". 

To my knowledge no Bitcoin ASIC company used existing SHA-2 IP and modified it.   
 

you are correct, I was thinking it was 196kb for some reason (as mentioned tired) all Bitcoin ASIC companies had to derive their works from existing the current SHA-2 ASICs, starting from scratch would have cost far more than the Bitcoin economy could have supplied, and far more than ASIC companies could afford to spend at their current price points. Its like if current ASIC companies decided to start using 14nm chips. It would be unimaginably expensive to create a technology that doesn't exist yet, its far cheaper to modify existing designs. I haven't actually sat down and talked to the ASIC manufacturers, but I'd say its a pretty strong gut feeling.

I've got some super secret projects that would be neat if I could run by you tomorrow (ok not that super secret). I'm at the point where I have to read over my posts 30 times to make sure I spelled everything rigt, and should probably get some sleep.

That is not correct.  Bitcoin ASICs are essentially glorified SHA-2 calculators.  Input binary blob & target.  Output any nonces which result in SHA-2(SHA-2(blob+nonce)) < target.  Not to take anything away from what the Bitcoin ASIC companies did but the chips are just performing the "math" of the SHA-2 algorithm.  Most of the "smarts" is not the customs ASICs but in the cheap micrprocessor (Rasberry Pi or embeded computer).  Far more complex chips are made in universities every year as academic projects.    There was an ASIC in your hand calculator from the 1970s.  It didn't cost a billion dollars to design either and the tools were a lot more primitive back then.

Calculating for inflation it may have.

Starting from scratch is equally expensive, FYI your analogy is totally wrong. They didnt create or modify any 'technology' for the their asics, its matter of coding and tools.
next time try using google first before "I'd say its a pretty strong gut feeling."

even reading simple wiki article helps,
http://en.wikipedia.org/wiki/Application-specific_integrated_circuit

But how does one account for the fact that ASIC companies are out there in the game and have invested to try to fill a market requirement, most of the investment was the time up until now , so when you see the situation from this point of view , its easy to see that they may move in that direction , I have no doubt that it wont be ABC123 .

The more one thinks about LTC , the more one tends to start getting that little paranoid conspiratorial feeling.

Then one looks back on experience and one realizes that its humans nature to do this sort of thing.

Then one realizes that only though these events , do dullards in thier owns designs help the whole.

Ha ha the downward price pressure could be our friends trying to diversify ha ha .

Then after the Wired write up to me Nova has never looked so good.

It could turn out that Nova is one of the most honest currencies around after Nybble of course, I dont expect many to understand of course but those that do , do.

So what now, VGA mining is finally over?

yes it is over

You are just forgetting to multiply this scratchpad size by the number of "cores", "threads" or some other entities (the way how you call them depends on the underlying technology) in the miner device. All these "cores" are simultaneously doing hashes calculations, each with its own scratchpad. The reason why FPGAs and ASICs work so great for SHA-256 is that the number of gates needed for a single SHA-256 "core" is really small, so one can fit an enormous amount of such cores on a single chip. But each scrypt "core" needs a scratchpad for storing intermediate data, and if the scratchpad is implemented as a SRAM memory, then the number of gates per scrypt "core" just skyrockets. You can fit significantly less scrypt "cores" on a single chip than SHA-256 "cores". There are some tricks for the scratchpad size reduction (LOOKUP_GAP is the right keyword, you can search for it in the forum), which reduce the size of the scratchpad, but this reduction is not free and results in more computations. That's why you can see some people mentioning Space–time tradeoff (http://en.wikipedia.org/wiki/Space%E2%80%93time_tradeoff). The optimal lookup-gap setup depends on the balance between the memory size/performance and the computational power for doing arithmetic operations. It is also possible to use the external memory instead of on-chip SRAM, but the external memory must naturally have wide buses and a lot of bandwidth (memory latency is not critical for scrypt though). The scrypt GPU miners are relying on the GDDR5 speed, with a popular scratchpad size configuration being 64KB (lookup-gap=2), which indicates that the memory speed is the bottleneck and the excessive computational power is already traded off in order to reduce the burden on the memory.

I also suggest checking https://github.com/ckolivas/cgminer/blob/master/SCRYPT-README to find a lot of information, which is intended to be user-comprehensible:
"--lookup-gap
This tunes a compromise between ram usage and performance. Performance peaks at a gap of 2, but increasing the gap can save you some GPU ram, but almost always at the cost of significant loss of hashrate. Setting lookup gap overrides the default of 2, but cgminer will use the --shaders value to choose a thread-concurrency if you haven't chosen one.
SUMMARY: Don't touch this"

The LTC scrypt parameters are sufficient for making sure that GPUs are required to have a lot of high bandwidth memory for decent hashing speed. It's all that matters. Increasing the size of the scratchpad is not going to bring any improvements (if by improvements you mean making CPU mining more competitive). Actually some scrypt based cryptocurrencies tried to make it more "memory hard" (https://bitcointalk.org/index.php?topic=196196.0) and failed to really fend off the GPUs (https://bitcointalk.org/index.php?topic=247782.0). Also the 128x claim is just silly because you are forgetting that bigger scratchpads also inevitably mean more arithmetic operations involved in a single hash calculation. As I mentioned earlier, it is the balance between the memory speed and the arithmetic calculations speed that is important. And the LTC scrypt somehow managed to get it right, even if this actually happened unintentionally.

Regarding the FGPA device on the picture at the start of this topic. Looks like it is going to have external memory bandwidth roughly similar to what is available for the triple channel DDR3 systems. This is still less than the memory bandwidth of a mid-range GDDR5 equipped GPU. I doubt that this FPGA device is capable of demonstrating any mind blowing hashing speed. Still if it manages to scale well with the lookup-gap increase, have low power consumption and/or low device cost, then it might be possibly competitive.

BTW, the appearance of competitive FPGA devices might make people more motivated to try better optimizing scrypt for AMD GPUs (squeeze every last bit of performance and/or reduce power consumption). Bring it on, this stuff may become fun again ;)

You used a lot of double speak.  First I am aware of the space time tradeoff however rather than explain it in every single post it is useful to look at the max scratchpad size.   128KB scratchpad is going to require less memory and less bandwidth than a 16MB scratchpad regardless of what space time tradeoff is employed.  A device only has a finite amount of computing power and while you can trade time for space needing less space to start with always helps.

As for higher parameter value having no effect on the relative performance of CPU, GPU, and FGPA/ASICs that is just false.  Scrypt was designed to be GPU and specialized device resistant.   This is important in password hashing as most servers are using CPU and attacker will likely choose the most effective component for brute forcing.  By making CPU performance superior it prevents attackers from gaining an advantage.    You can test this yourself.  Modify cgminer OpenCL kernel to use a higher p value.  Around 2^14 GPU relative performance is essentially gone.  It is comparable to a CPU throughput.  At 2^16 GPU relative performance is falling far behind.  At 2^20 the GPU never completes.

You say one one hand that the memory requirement doesn't matter and on the other hand that FPGA are hard because they need lots of memory and wide buses.  Well guess what the higher the p value the MORE memory and wider busses that is needed.  At 2^14 roughly 128x the max scratchpad size is going to mean 128x as much bandwidth is necessary.   So the lower the p value the EASIER the job is for FPGA and ASIC builders.  They can use less memory and narrower busses that means less cost, less complexity, higher ROI%.   Sure one isn't required to use max scratchpad size because one can compute on the fly but once again the whole point to the space-time tradeoff is that the advantage to doing so is reduced.  

Lastly yes the 128KB is per core but so is the 16MB using the default parameters.   If 128KB per core increases memory, bandwidth, and/or die size per core then a 16MB requirement would maker it even harder.  So yes the parameters chosen by LTC makes it 128x less memory hard than the default.  You use circular logic to say the max scratch pad size is irrelevant because one can optimize the size of the scratchpad to available resources.  This doesn't change the fact that due to the space-time tradeoff you aren't gaining relative performance.  Using a higher max scatchpad requires either more memory and bandwidth OR requires more computation.  The throughput on the FPGA,  GPU, CPU is going to be reduced.  Now if they were all reduced equally it wouldn't matter all that matters is relative not nominal performance.  However the LTC parameters chosen are horrible for CPU usage.   CPU have a limited ability for parallel execution.  Usually 4 or 8 independent cores.   128KB per core * 8 = 1MB.  That's right today with systems that can install multiple GB for very cheap cost the Scrypt paramters chosen bottleneck performance on a CPU.  GPU on the other hand are highly parallel execution engines but they have limited memory and that memory is at a higher cost than CPU have access to.



TL/DR
Whatever the relative performance of this FPGA is to a CPU miner it would be WORSE if the p value was higher.   LTC decision to use a low p value makes what otherwise would be a nearly impossible task into one which is merely challenging.  

I wish I had the time to learn how to design these things. Looks like so much fun.

Waiting anxiously to read the specs on this  :D

I doubt it.  You should have a look at Solar Designer's TMTO data with N=2^14, r=2^3, p=1.

https://i.imgur.com/4UvYvG5.png

As you can see, as memory exponentially decreases integer ops exponentially increase.  He was easily able to get the memory usage into the kilobytes and still crank out hashes.  I'd guess that exactly the same is true with N=2^10, r=1, p=1 too.  It's the same balancing act you run into no matter what value you use for N or r; at higher N you may increase the difficulty by a smaller constant factor, but overall I doubt increasing N or r will make scrypt much more FPGA/ASIC unfriendly when they finally iron out the FPGA implementation.

This look like a potentially interesting development. Capitalism really drives innovation to extremes in some cases.

I look forward to more information about this project, beekeeper.

Yes that is the space-time tradeoff and they used it to reduce the memory requirements to roughly what LTC Scrypt requires EXCEPT to do so requires a 100x increase in integer performance.  If anything you just showed how weak LTC Scrypt is.   Another way to look at it is say you had a FPGA card with output of X kh/s using the full scratchpad size of 128KB.   Now trying to run N 2^14 you don't have sufficient memory or bandwidth but like the chart shows you could use the space-time tradeoff to reduce the memory requirement to 128KB.  Great the memory requirement is similar to LTC Scrypt ... EXCEPT you now need either a FGPA with 100x the integer performance (how much do you think that is going to increase the cost) OR you are going to have 1/100th the hashrate.   

Nah, it's just you still having some trouble understanding :)

Let's have a look at the definition of what is "memory hard" in the scrypt paper (http://www.tarsnap.com/scrypt/scrypt.pdf): "A memory-hard algorithm is thus an algorithm which asymptotically uses almost as many memory locations as it uses operations; it can also be thought of as an algorithm which comes close to using the most memory possible for a given number of operations, since by treating memory addresses as keys to a hash table it is trivial to limit a Random Access Machine to an address space proportional to its running time", "Theorem 2. The function SMixr(B, N) can be computed in 4 * N * r applications of the Salsa20/8 core using 1024 * N * r + O(r) bits of storage"

You can see that scrypt is just equally memory hard for all the scratchpad sizes. The ratio between the number of scratchpad access operations and the number of salsa20/8 calculations remains the same.

What I said was "Increasing the size of the scratchpad is not going to bring any improvements (if by improvements you mean making CPU mining more competitive)". How did it turn into "no effect on the relative performance of CPU, GPU, and FGPA/ASICs"? CPU miners are at a serious disadvantage right now, so the effect on the relative performance must be really significant in favour of CPU in order to turn the tables.

In practice, increasing the size of the scratchpad will make it harder to fit in CPU caches. To mitigate the unwanted latency of random accesses, scrypt uses parameter 'r'. Basically if r=1 (the default for LTC), then the  scratchpad is accessed as 128 byte chunks at random locations. If r=8, then the memory accesses are done as 1024 byte chunks at random locations. In the former case, the cache miss penalty is hit once per 128 bytes. In the latter case, the cache miss penalty is hit once per 1024 bytes (the sequential accesses after the first cache miss are automatically prefetched, at least in theory). Having high 'r' value reduces the effect of memory access latency penalty for the CPU. And the latency is not an issue for the GPU in the first place. Additionally, if the CPU has to access the memory, then the memory controller must have enough bandwidth. For example, my Core i7 860 processor currently has ~29 kHash/s performance in cpuminer. And the STREAM (http://www.cs.virginia.edu/stream/FTP/Code/stream.c) benchmark (built as multithreaded with OpenMP support) shows ~10GB/s of practically available memory bandwidth. These ~10GB/s of memory bandwidth would translate to the theoretical hard hashing speed limit ~38 kHash/s if the CPU caches were not helping. There is not much headroom as I can see, and my processor does not even have AVX2.

This is confusing, did you actually mean the 'N' value? Please just provide the patches for your changes to cgminer and cpuminer that you used for this comparison.

But in general, the GPU tuning is not easy because there are many parameters to tweak. Poorly selected configuration can result in poor hashing performance even for the LTC scrypt. You can find many requests for help with the configuration in the forum. So your poor performance report does not mean anything.

And surely you can raise the memory requirements so high, that they would make mining problematic on the current generation of the video cards purely thanks to insufficient amount of GDDR5 memory. But guess what? In a year or so, the next generation of video cards will have more memory and suddenly GPU mining will again become seriously better than on the CPU. Designing the algorithm around some magic limits which may become ineffective at any time is not the best idea. The current "small" scratchpad size for scrypt focuses on memory bandwidth instead of relying on artificial limits such as memory size (which can be easily increased, especially in the custom built devices).

Yes, but only if also backed by roughly 128x more computational power. And likewise, the enormous computational power of FPGA/ASIC must be backed by a lot of memory bandwidth, otherwise it will be wasted.

They can't use slower external memory, because it already needs to be damn fast.

Yes, the absolute hashing speed would just drop significantly with the 16MB scratchpad. But it would drop on CPU, GPU, FPGA or any other kind of mining device.

Sigh. Please just read the definition of "memory hard" in the scrypt paper.

Wait a second, where does this "reduced equally" come from? The space-time tradeoff just means that if you have a system with excessive computational power but slow memory, then you can still tweak lookup-gap to trade one for another. That is instead of being at a huge disadvantage compared to more optimally balanced system. This kinda "equalizes" the systems with vastly different specs, which is a total opposite of "reduces equally".

This just means that you don't know much about the CPU mining. The point is that modern superscalar processors can execute more than one instruction per cycle, this is called instruction level parallelism. Also there are instruction latencies to take care of. In order to fully utilize the CPU pipeline, each thread has to calculate multiple independent hashes in parallel. Right now cpuminer calculates 3 hashes at once per thread (or even 6 with AVX2). Now do the math.

The memory must be also fast, not just large.

TL/DR

For the external memory, I'm assuming that sufficient size is available to be used for as many cores as practically useful (in this case only the memory bandwidth is an important factor). For the on-chip SRAM memory, the bandwidth should be not a problem as the memory can be tightly coupled with each scrypt core, but the size does matter and can't be large enough (the CPU caches are really small when compared with the DDR memory modules for a reason). The current best performing scrypt mining devices (AMD video cards) are relying on the external memory bandwidth. This FPGA design seems to be essentially a GPU clone.

lmao. STFU and take my BTC LTC YAC!!!!

Why can't we pre-order a 10GH Scypt-Jane unit through BFL at this time?

You see that 600gh/s Card? I think I'll pass....Still have not received my Jalepeno.. but bought a bunch of block erupters and a blade from http://www.wtcr.ca and got it next day in the US.

So cutting through all the " im smarter and understand "

It is basically is I stated before that an ASIC will just be a more effectient version of a GPU system as opposed to say a reorganization of the fundamentals .

I.e an ASIC may provide from 4x to maybe 10x  efficency and less power / heat .

So therefore sCrypt may be the domain of ASIC in the future .

And then if there were to be a next possible iteration it would be out quicker .


BFL CEO

2 to 4 weeks ?

Wheres the XPM FGPA ???

...lolz

It's fucking amazing the patient you all have. Fuck-ing-a-ma-zing. Must be something in the air...

Where are the specs!?!

I think its just that people are not quite as retarded as they were , or the ones that are still retarded all have BFL orders pending.

and if an effective FPGA has been developed , do you think they are going to be sold to you?

then there is that next bit that suggest that FPGA's are not going to be the super device you think they are.

ASICs are in the works., and some released likely , which are also not going to give the super performance that you might think either for the cost..

So where is the sense of urgency coming from ?

Looks like a cool gadget. Do you have instructions for building these?

Is there any connection with this? - https://bitcointalk.org/index.php?topic=285656.0

I hardly believe. So, No.

Yeah, mistery solved

There is NO ASIC for Scrypt !!!...there is NO fucking FGPA for scrypt @ this point (proven)

So far we have a picture of a fgpa....WOW Awesome !!  It may be able to mine scrypt but at what 1 hash for 1k investment

Spec????????????????????????
Price????????????????????????
Available on...???????????????
Watching.

Donno if it will see the light of day. He has also develop a BTC FPGA. Never sold or marketed, only for his private use.

I don't belive this...yet.  ;)

Doesn't really matter what the specs are if he's not going to share...?

Looks promising.....

Fapping value.

False!
https://github.com/kramble/FPGA-Litecoin-Miner

hmmm watching

Max hash rate on raw scrypt with external ram is ram_transfer_freq * bus_width / (1024 bits * 2048 rw). With special tricks can go more than double. For example, a ddr3 stick working at 350 mhz will produce raw 22khs, as in this basic design:
 https://vimeo.com/m/74955720
Power consumption is 3W. Costs less than 1.5$/khs.

Show me the Kilowatt reading, please.

What kilowat, lol, its about wats, 300 mA on 10 Volts..

I wanted to see the meter reading at the outlet instead of you just saying what the power consumption is...

Man, no offense, for 3w you cant count at power plug..

Wtf is this scam? Its been 3 weeks with no info

Okay, I just wanted to see your reply.    ;)

https://bitcointalk.org/index.php?topic=283977.msg3192292#msg3192292

Also, not a scam even if that were true.

He is actually talking about Kill A Watt

http://www.inspectortools.com/Kill-A-Watt-EZ-P4600-p/kawp4460.htm?gclid=CKeYtrG02LkCFWJp7AodVC8ABA

A device you plug your FPGA into and while it is running you can accurately see the watts being used.

Then you take a picture of your FPGA plugged into the Kill A Watt and prove you are only using 3 watts.

Just saw it 22kh so basically useless lol. 22kh x 4 sticks still useless.

I dont think so, a 4 stick device would deliver about 100 Khash/seg, with 15 w power, 10 devices would deliver 1000 Khash/seg with 150 w power or less ,performance 1 Ltc/day -----> 2€/day and 3.6 Kwh/day = 1.3€ clean at day , 0.13 each one, 0.0013 BT/day/device , 0.039/month /device


I would pay, 0.12 BT for each one with 4 sticks


Its a beginin

he is probably running it on a lab power supply and that will use more than 3w on its own so you wont get an accurate reading from the wall

https://i.imgur.com/kRX7QNB.png
https://i.imgur.com/T1urC4E.jpg
same revision A

I am so curious and want to know what is the reason for the vawe form of the cupper tracks on the pcb.
Thanks

It's to keep all tracks the same length. This is required for buses that have many parallel signals so that all data arrives at the same time.

Reviving a dead thread, and a little ironic the same things are being said almost 2 years later

Not quite the same (7 months little to no info) lol

Yea is funny how the process just keeps repeating.  As if theirs some kind of pattern to it😜😎