Bitcoin Forum

I have found what I believe is a shortcut in scrypt that if implemented correctly in hardware could dramatically speed up the hashrate.
I believe it should work and I know how I would implement it if I had the resources to acquire the FPGA and tools I need.

To show good faith I will elaborate on the algo and how the shortcut would work.  
This is really over simplified, but you are free to take this idea and roll with it.

scrypt the algo used by LTC and in fact all hashing algos, are comprised of 2 predominant steps.
#1 Generate a random list
#2 Hash across it.

To generate consistent results the random algo is actually deterministic pseudo-random and the setup for it is determined by a seed.
We will call this the prng.

The other step is hashing which is pretty well understood, you take a value from list a and replace it with a value from list b.
When you are done iterating you now have a hash.

scrypt differs mostly because it uses an entirely new list so frequently.  
The setup and tear down of this list requires quite a bit of CPU time and a lot of time is wasted on the memory bus performing storage & retrieval operations.
It cannot be done concurrently because the list itself changes frequently.

The shortcut is to have a multicore setup and a ton of on-die ram.
A dedicated prng core which does the setup and teardown for the second core.

The secondary core is the hashing core.  It would tell the prng core to setup a new list.
Then it would retrieve position x off the list from the shared memory space.
Other than that it would also perform all the normal hashing functions in a dedicated memory space.

I believe the total I need to make this work is about $12k USD, the FPGA I'm targeting right now is $10k and a license for the dev tools will be about $2k.
If I can find a less expensive option then I will go for that, but there aren't that many FPGAs that meet requirements right now.  
The particular target FPGA also has a direct path to ASIC from the mfr.

If you're willing to donate to the effort, I will keep you in the loop with full disclosure including build instructions and a copy of the sources and the firmware.
I haven't decided on a license for this if it works, but you will at least have a right to personal use.  
Perhaps if enough people are interested in production level manufacturing we could go a different route.  I'm not particularly interested in making this something I do for the rest of my life, but the contrarian in me is very excited by the potential here.

The LTC donation address is below.
LKfKkRMvMf2stQMNzQdKCvaf2YueAv1QSa

You can also donate BTC to the key in my sig.
There is no maximum but if you do decide to donate please send at least 0.5 LTC or the equivalent in BTC.
Then post just the address you donated from and I'll PM you here with a bitmessage key to join the group.

Thanks in advance!

Very few people will be willing to send you money on a promise. If you really want to do this, go the BkkCoins route and open source your efforts. Once people see there's a viable design that you've put effort into, they may be more willing to contribute funds. Otherwise you're probably going to have to bankroll the thing yourself and demonstrate a working product first.

Yeah i understand that.  My other plan is to self bankroll it.  More time to save up but i keep the end result.
I would be doing this on my own anyways but i figured i would share and frankly 0.5LTC for everything you need for a miner except the chip is quite a bargain in my book.
I'll keep this thread up until my funding target is met either from contributions, my own efforts or likely some blend of the two.

If i find a cheaper fpga that will work and I haven't received any contributions by then, I'll just wrap the thread up and keep it close to my chest.
 

A $10,000 dollar FPG chip wow. What do you think the hash rate would be?
Do you think it would beat my GPU?

No r3eflection on yourself, but there are just soooo manyt scams around that nobody will trust anybody else without a show of proof.

I suggest getting a dev board, make you algo work even if highly restricted, then show the community how it will scale if you had more resources.

Dev board can be obtained for just a few hundred $$, clearly if you need special hardware setups you will need to get some funding through your own closer networks (your own $$, friends, family, put a call out to meet with LTC miners in your local area).

Yes I'm pretty certain it would be more hashing power than most mining pools.

Obviously I'm not running a scam.
I'm making an offer to to have a chance to help fund me so I can try this out.
The minimum works out to less than a dollar at current rates.  Most people spend more on satoshi dice.
In exchange you get to know everything I know, learn and discover as I go along.  
When the process is done, you get everything you need to build one yourself.

It's a $10,000 FPGA, that price includes the devboard. I know you guys are used to Xylinx and other lower end chips, but this is a chip designed for a completely different application it just has certain characteristics that make it an ideal miner.

However it is $10k.  Because it costs so dang much, I'm not going to try and build a community around it.  The only people who would be even interested at that price point are companies selling mining hardware and I really don't want to see this commercialized.  As the price comes down on the FPGA it's possible a community would crop up over time, but I really don't want to get married to a hardware project.
But it is a fascinating project and if nothing else at least folks are aware it's possible now at least in theory.

So you are assuming no one else is working on this with a potentially large head start? Let's just say that's a little overly optimistic.

"Obviously I'm not running a scam. "

Mmmm, okay... I've heard that before. Even though you may not plan on scamming people, do you have the capitol to cover your investors?

Never heard of 'Xylinx'....perhaps the I is interchangeable.

Also, correct me if I'm wrong, but 'When the process is done, you get everything you need to build one yourself.' = paying another ~$10k if you aren't mass producing your own units, no?

I bet you've never heard of Adibas or Puna either. At 10k that is a very special chip...

Um, have you heard of xylinx?  Recall that he implied xyilinx is a budget manufacturer.


 At 10k USD, it's damn sure not based on Xilinx arcs unless it's a huge cluster. Of course, that would be rubbish for sCrypt.

However, I would like to know what this magical $10k FPGA arc with large amounts of high bandwidth, low latency cache is actually called.

I was jesting. Those 2 are knock-off brands. Maybe the chip comes with a gold heat-sink. To match an entire pool it has to do some mighty hashing. Or maybe they've found a way to move electrons faster than the speed of light, going back in time and mining at a lower difficulty. After all, the chip sounds quite magic.

I m VERY interested.  tell me more.  I might fund it.

Oh oops, my mistake, I gotcha now.  ;D

The proposal is a touch too theoretical I'm afraid.

On balance, at least he isn't making wild efficiency claims that even a semi-competent electrical engineer would question (ahem BFL). lol


^ "tell me more" agreed.

What investors?  I don't recall asking for investors at all.  I'm offering to share what I learn as I do this, period.  
If the information is of no value to you, then don't stress you're probably not the target audience.  
If it's something that piques your interest, pitch in.

Yes actually I'm fairly certain no one else is working on this and no one has a significant head start.  
I'm confident, because I've read what people are doing.  This is different, if you don't understand from my description how it's different then please re-read mine vs theirs.
I've also talked to the people who are working on FPGAs for litecoin they say it's intriguing but obviously they're targeting different hardware so this clearly wouldn't work for them.  

Point of fact at today prices, dollar for dollar you will get more hashing power with theirs.  That will probably be the case for a year or two.

This isn't about that, it's about a shortcut in scrypt that can be implemented in next gen FPGAs and which eliminates the memory bus problem.  
I'm saying I want to explore that particular shortcut, I don't have the resources to do the exploration, so if you want to chip in I'll let you know what I find.
Otherwise I will do it whenever I can.

Typo in the name of a mfr, sorry for that.  I'm tired it's 1:30 AM.  As long you understood who i meant, but just to clear up confusion http://www.xilinx.com/ good company, but doesn't make what I'm working on here.

You're not wrong, but you're assuming that the FPGA & devboard will stay the same price forever.  
My experience has been that these things go down and do so rather rapidly.  
Also it's not just the FPGA, a significant portion of that cost is in the board.
There is a bunch of stuff on the board that this project doesn't need, but it's on there anyways because it's a devboard.

When completed you would have all of the knowledge that I have attained in this endeavor.  
I'm only asking for donations because I'd like to move on this more quickly than my personal budget will allow.  
I am currently in a downtime situation where I have a couple months to throw full-time into this.

I'll send you a PM in the morning, I need to get some sleep now.  The short of it is already up at the top and covers 3/4ths of the idea.  The other 1/4th is implementation specific details.

Fair enough, but I would definitely consider it an investment. IP can be just as valuable as monetary returns if not more.  ;)


I do understand your concept, actually one of the LTC devs already proposed the idea for 'setup and teardown' by a separate processor.

You are proposing both a shared and dedicated cache, correct? In essence, it would be similar to the gpu lookup gap function we see now, just without the dedicated co-processor. I would be interested in hearing the specifications of both caches and the link width (if you are attempting to avoid on-die cache like I think).

It's an FPGA with a crap ton of on-die ram.  There is nothing magical about the chip.  By the time it comes down in price there will be better chips.
If I can find a less expensive one with that much ram tacked on, I will go with that instead.

On that point I'm open to suggestions.

Oh I see I was mistaken. That's going to require both core density and a very large amount of the particularly expensive on-die cache, no? What process node is this based on? 


Are you looking to battle against 7990s and the like in both pure hashrate and efficiency?

Thanks I'll send you the same thing I do viceroy in the morning.  Need sleep now.

Okay, thanks!

This sounds interesting - watching

Sent some LTC your way, definitely interesting.

Hi Nova following along with your thread. Are you located in the United States by chance?

Perhaps Nova can tell us exactly what FPGA IC costs 10,000 dollars. I have looked at the manufactures and I dont see any chip that 10K

You haven't looked hard enough.  Some of the latest gen FPGA Stratix V development boards by Altera are running about 9k to 12k each.

I've worked with their older boards.  There is another theoretical route he can try to take which uses some of the recent innovations with SRAM.  I have my own theories and I've mocked up some code but I don't have plans to buy a board to implement them.

For Scrypt it is not worth the time and money.  The total circulation and average daily transactions of LTC does not make it a good investment.  Anyone trying to implement a FGPA for Scrypt while LTC is under $5 is a scam (not directed at OP), or has not done the math.

Yes, he did mention the extra cost due to the nature of development boards. I honestly expect any device capable of decent scrypt hashing to be rather pricey, that's one of the main points. ;)

Thanks what address did you send from?

Yes I will tell you.  In fact that is one of the reasons I started this topic.  Anderl is right about the FPGA being an Altera Stratix.

Or is interested in it for reasons of academic curiosity and not an attempt to make a commercial product or recoup investment later :)
I'm interested in hearing your SRAM idea as well as your other theories.

I'll invest 1 ltc.

Actual ammount, .898 LTC

Transaction sent
ID:ce81163ab1903c85b5f4b4ef79657472477eab20b7bc3bb85ca6529008fb0733

I'm from the USA.  Right now I'm in Ecuador, but the contract I was on ended and I'll be heading back in the next couple of weeks.
Specifically I reside in Phoenix AZ.

Thanks!  I'm seeing it.

When LTC gets over $5.  Right now I'm find using ASICs for BTC and GPUs for LTC and scrypts.

But look into what is coming to market right now in FPGAs.

I sent you a PM

I can't say as I disagree with you there at all.  My only response to that would be it's pure research.
Xerox was researching GUI's back at a time when almost no one had a home computer. 
It didn't make financial sense either it was more or less a "hey cool look what we can do" sort of thing. 
That's really all this is intended to be.

I'm new to crypto currencies and I'm looking for a FPGA implementation too.

I think the big problem is that you can't unroll salsa mixing because of its recursive form. Thus you can't parallelize calculations as you can do with sha256. The only thing you can do is to have multiple instance of your 'cores' run in parallel. But I don't think Stratix have enough on-die ram (52 Mbit max) to overwhelm a pool as you said.

I don't see the shorcut here. Are you thinking of a two stages pipeline with dual port ram in the middle ?

To conclude, I don't understand why you need funding for your idea because you can test everything with simulation. Altera provides a free web edition of their dev tools that don't allow you to target Stratix but you can target Cyclone V. You should be able to validate your idea with 12 Mb of on-die ram. Then you'll have tangible results to get funds for a dev board which are really expensive :P

That's a good idea.  I was unaware there was a free tool that wouldn't let me target the chip I'm planning to target.
Is there a compelling reason to choose Cyclone V over Stratix V?  Other than cost I mean?

Sent 1 LTC form LXj15uZkCFMecbKcLVMsswTtnWvRqqhuUm

Could you send me some info by PM?

Cyclones are a smaller, slower version of the Stratix lineup. The biggest Cyclone V is approximatively a third of the biggest Stratix V for LE count.
I suppose it should be enough to validate the shortcut.

Yes, I'm also finding out some exciting information in this thread and am trying to incorporate the new information in the writeup.

This is a public service announcement for anyone that feels inclined to start sending BTC or LTC to nearly anyone that drops the words "Litecoin" and "FPGA" in the same post, even when it's apparent to everyone with in-depth knowledge on the subject that the OP likely doesn't know what he's talking about.



The OP's claim is way worse than that.  If you look at what he posted over in the 'scrypt is "memory intensive" therefore no ASICs, but how?' thread, he elaborates a bit more on how he thinks scrypt works, that what he actually means when he talks about setting up and tearing down an entirely new list:



The OP failed the basic scrypt knowledge test, I'm afraid.  I saw a flawed explanation posted somewhere that looked like the OP's description, but can't remember where I saw it.  This is far enough "out there" that I bet the OP had to have read it in the same place.

You can calculate scrypt+salsa20/8(1024,1,1) as used in Litecoin with a fixed 128kB buffer + a bit of extra scratchpad memory, all day long, without calculating any sort of dynamic list that determines how much memory will be involved in calculating the hash.  And the memory access pattern will be exactly the same every time you calculate the hash.  In fact, my own FPGA implementation of scrypt with external DDR3 leveraged this fact by shifting every scrypt core 1 clock cycle from the previous one, such that a burst read or write to/from DDR3 would fetch all the data needed (or written) by each core precisely when that core was going to use (or generate) it.  This was possible because the memory access pattern and amount of memory needed is exactly the same every time.



The OP doesn't have a shortcut at all.  Even if scrypt worked the way he described, the OP's suggestion of a 2 core approach as a "shortcut" would be a retarded design for an FPGA implementation.



+1

In fact, if we look at his post in the other thread, he claims he already implemented it, and destroyed the FPGA on his dev board while it "sounded like a jet landing the whole time":



Does not compute, for anyone with technical knowledge on the subject.  In the highly unlikely case that this did actually occur, it would mean the OP already has the dev tools as well and would have no need to replace the whole dev board (as he states earlier in this thread that the dev board costs much more than the FPGA IC), it would be more cost productive to desolder the FPGA IC, clean up the BGA pads and reflow a new FPGA onto the board.



Altera's Hardcopy program is really just a mask programmed FPGA that Altera has pre-qualified for your particular netlist to run at a little higher speed.  I wouldn't call it a true ASIC, it doesn't achieve anywhere near the speed-up that you'd normally experience going from an FPGA to an actual real ASIC implementation built from your original Verilog source, and only achieves a few % cost reduction over Altera's equivalent FPGA's.  The only reason it costs less than the equivalent FPGA is that Altera doesn't have to qualify and test the FPGA for every possible design someone could load on it, they only have to test and qualify it for your specific netlist that was mask programmed on the die.  Best not point at Hardcopy as a valid route to an ASIC implementation for LTC.

Hopefully this gives people a little better idea what the odds are the OP is trying to scam people.  And I see people in this thread have already been sending LTC and BTC to him!  Wow..

OP: Take some time to learn how scrypt works.  Read Percival's original Tarsnap scrypt whitepaper.  Check out the source code for a few scrypt implementations.  That way you can have the correct details on the next BS / scam attempt.  Suggesting that scrypt's memory requirements are dynamic and determined by an expensively computed list calculated on each iteration was your biggest mistake here.

Just preserving a copy so the OP can't change his original posts in this thread or the other one to remove all the incorrect claims that are red flags:

I personally would rather leave scrypt mining FPGA or ASIC free. That's the main appeal of it to me. But if an FPGA device were created I'm sure there would be ample interest in it, but then the question is now where will all the GPU miners go???

So I take it you have a functioning FPGA for LTC?  I would actually love to know even more about your design.  You do come off sounding like you have an impressive amount of knowledge on the subject.  As for me, I'm probably still standing at the top of Mt Stupid especially when I try to relate the concepts to others.
Nevertheless I am a programmer.  I've spent half my life finding optimizations in code, I'm pretty sure I see this one.

Ok so going back to where we started from.
#1 I am not raising money to develop a super secret top of the line nuclear rocket powered FPGA.  I have said from the beginning that I think I see a way to optimize a section of scrypt away.  I would like the opportunity to explore that option.  That is why the thread is entitled A custom designed FPGA miner for LTC.  The implication is that there would be difference in the way it works, but the output should be the same but faster.

#2 I'm pretty certain it's a well known fact by now that I had a board from a previous employer, I was working on porting the OpenCL miner to it and it ran fast and it ran hot and it fried the board.  This may have had something to do with the fact that I was using a version of the dev environment which I probably should not have been.  Hence the need for legit dev tools, which by the way is not just the IDE.  Had I known I was working with a $10k board at the time I would have taken a bit more caution.  But when I left my previous employer I asked if I could buy it at cost and they sold it to me for $850.  I wasn't privy to the fact that it probably cost them a bit more and now days I'm wondering if they even knew.  I'm pretty sure I did mention those facts in the referenced thread.  If not I'm sure I've mentioned them enough in other threads that it should be considered disclosed by now.  But yes everyone, you should be aware.  My original plan was just to compile the OpenCL miner and directly run it on the hardware.  I did this with an expired/not legit version of the dev tools, but it seemed to work.  The side effect of doing it that way was that it ran great for 3 hours, got hot enough to toast marshmallows then would shut down for an hour.  After a few days of working with this in the end fried itself.  Hence I need to rule out the actual dev tools.  Also it made me look closely at the source which is where I think I see my answer. 

#3 Of course I'm going to post the simplest laymans explanation of what is going on under the hood.  I declared explicitly in the beginning when I mentioned "This is really oversimplified but here it goes..."  At which point I then explain hashing in general and that scrypt is hard to FPGA because it requires access to a lot of RAM.  If that RAM is on the die it really does help to speed things along quite a bit even in a default scrypt implementation.  Run the OpenCL miner on the chip I'm talking about and see.  I also then go on and explain that the innovation is creating what are effectively 2 cores and letting them communicate.  One core has just the gates for the PRNG, the other core has the gates for the remainder of the hashing.  They share a common memory space for the lookup table.  I believe by decoupling them and taking advantage of certain reductions in complexity that we would see a speed up.  I don't know that this is in fact the case, but it looks right to me and I'm willing to do what it takes to prove or disprove my theory.

#4 I was unaware that the Altera ASIC was not a true ASIC.  This is important information and is game changing in my eyes, since part of the point is to provide a direct path to asic for anyone who wanted to participate.  Because of this I am willing to fully refund anyone who has contributed.  All they have to do is ask.  Thank you for bringing that to my attention.  I will keep it under advisement as I try to find a new path.

Here let's preserve a copy together.  I agree, if I change anything in the original description after reading your "red flags" then I must be a scammer.  It could never be that I learned new information or tried to clarify or found out I was wrong about something. :)  So far that hasn't been the case.
By the way you have some interesting points.  They are a bit outside the realm of what I was trying to get at here, but if you see further optimizations please feel free to pitch in.  You are actually giving us all a valuable learning experience in the right way to implement an FPGA for LTC.  BTW what chipset and board are you using?  What devtools?  Thanks!

Can you write an efficient scrypt miner that we can put on the amazon cluster?  I have $100 in credit plus an offer to beat up a bunch of tesla's for 24 hours.

I'm actually not sure about that.  For instance I know that GPU mining on the telsa is horribly inefficient for bitcoin.  I can only guess that it would be even worse for, litecoin.
However I do wonder how the CPUMiner would fare on one of those 64ECU units.

From a cost perspective spinning up a ton of micro instances as spot instances may infact be your best bet there and just point them at a pool.  I did that a month ago and it caused the pool operator to shut down thinking they were under DDOS attack.  Trimmed it back from 200 units to 20 and let it mine a week and got nothing for my trouble but a big amazon bill.

I'm going to take a look at the way scrypt is implemented in the CPU miner and see if there is anyway to optimize it a bit though because now you've got my brain working in that direction, thanks!

Nova: You have blatantly misunderstood how hash functions work, and specifically how scrypt works. I agree with WindMaster, there is no way you have made, or will make a scrypt FPGA. I advise everyone to not send Nova money.

Ok, elaborate.  Please explain in laymans terms how a cryptographic hash function in general works first.  Then also explain in laymans terms how scrypt differs from the SHA-256 of bitcoin.

If I have completely misunderstood hashing over a lifetime of programming, then I really have some long hard thinking to do.

My guess is that you're focusing on an over simplified explanation, something I can present to people who may or may not have any sort of experience with programming or hardware dev and assuming that the reductions and omissions are there as an oversight or misunderstanding rather than the fact that they are not relevant to what I'm attempting to explain and thus intentionally omitted.

mtrlt, please enlighten us.

While doing so, don't try to point at the flaws in my explanation and say "it's not x but y & z".  Instead start from scratch.  Try to remember your audience here.
Frankly I'm genuinely interested in this.  I'm also impressed with all these FPGA experts chiming in with their knowledge, looks like lots of people have fully working LTC FPGAs. 

As for everyone else, the offer is still open here. 
If anyone has sent me money and decided that they no longer feel comfortable with the idea of what I've stated before they can request a refund.
Also mtrlt is half right, I have not made a fully functional FPGA for LTC yet, it's sort of why I'm asking for help to raise funds to buy the bits I need.

Some good news is that people have been suggesting alternatives to build this on which could end up being much cheaper.  I'm currently swimming in whitepapers :)

Anyways, I'm with mtrlt & windmaster on this.  I expressly advise against anyone sending me money unless they understand that what they are getting is the collective result of what I learn in this process.  While the goal is to produce an FPGA with a version of scrypt with a slower section optimized away, this effort may not produce a result other than "oh ok, so it didn't work because I was wrong about x".  If I had all the information I needed or I had the money to purchase the equipment to check it out, I wouldn't be going this route.

I am learning a lot though.  There do appear to be candidate boards that may work.  I'm studying them carefully now.

Random tidbit that may be of interest if anyone is unsure whether mtrlt knows what he's talking about.  Nova, you mention above that you've looked at the OpenCL source for scrypt mining.  Assuming that you're talking about the OpenCL kernel from Reaper or cgminer, hop back into the source, scroll up to the top and examine the copyrights at the top of the file.

https://github.com/ckolivas/cgminer/blob/master/scrypt130511.cl#L2 (https://github.com/ckolivas/cgminer/blob/master/scrypt130511.cl#L2)



This part is true.  However, most (all?) of the people that have actually done it have found that the cost/performance ratio is significantly worse than GPU's.  This was actually the case for BTC too, FPGA's never had the edge in the cost/performance ratio, only an edge on power consumption.  On the scrypt side of things, it's my position from first-hand experience that you'd have to have insanely expensive power or be willing to wait for multiple years for ROI on power cost savings for FPGA's to be worthwhile for LTC mining.  We know what we're doing on the FPGA and ASIC development side of things, and yet we have a data center full of 5850 and 6950 based rigs mining LTC.

I'm very interested in learning more about this approach.
You say that you shift every scrypt core 1 clock cycle from the previous one.
You then say that a 2 core approach would be retarded.

You either did or did not implement multiple cores, but it sounds to me like you implemented all of scrypt and loaded it to seperate cores.  You mean completely seperate chips or literal cores on the same chip?

You say it's retarded, but you make it sound like it works flawlessly for you.  Primary difference being you're calling all the way out to RAM and I'm saying let's keep that on-die.
Also I believe you're talking about all of scrypt in a single functional unit and I'm saying let's break it out into a generation core and a usage core.  You may have actually found a better solution.  I'd like to know your hashrate and platform though, if you don't mind disclosing it.

At no point did I imply he didn't know what he was talking about.
However posting the entirety of the code and pointing at it and saying look, really wasn't an option. 
I was asking him to explain what's going on in it in just a couple of sentences or paragraphs.

Now we're looking at the code.
This wasn't the exact file I had but maybe something has changed I don't know, it's close enough in the places that matter anyways.

Anyways for the crux of my argument, take lines 124 through 142 which consist of the bulk of the random number generator.
These are currently implemented as defines.

defines are a sort of macro they're going to be put into the final output as the code they represent.

Ask yourself what happens if you just have that section of code isolated as it's own separate core.
Then modify the code to call into that core rather than keep repeating that section over and over again?

Now we're on the same page.  It would be a start.  There are some other things I see a well, but I'll just keep that under my hat until I get a chance to make sure I'm right.
 

Why should I explain it to you in layman terms? I can only assume that you are indeed not a technical person. Besides, I have already proven that I know what I'm talking about (by for example writing a BTC miner from scratch, and the first ever open source GPU miner for LTC, which no-one has been able to improve significantly, at least not publicly). You haven't. The only reason you can't explain your ideas technically is that you don't know what you're talking about.


Time doesn't give you knowledge. Time gives you the opportunity to gather knowledge. When I started coding my own miner in 2011, I had no idea what a hash function even was or how to program OpenCL. Now I know. Before I started working on my Yacoin GPU miner, I had no idea how SHA-3 or ChaCha worked. After 13.5 hours, I had a fast GPU implementation.


I focus on an over-simplified explanation because that's all you have given. From what I can decipher from it, it's completely bogus.


My audience is you, and you alone.


EDIT:


They are the rounds of SHA-256... not a random number generator. I am now completely sure you are completely ignorant. You also talk about #defines like they are a completely new concept to you. Are you even a programmer?

That isn't a random number generator.  You're looking at macros for the SHA256 rounds.  Just stop, and go read the scrypt whitepaper.  Immediately, if not sooner..  I'm not trying to be rude, it's just that an immediate read of the scrypt whitepaper will be better use of your time at this point.

Well, strictly speaking scrypt is using SHA256 as a random number generator...

In a way, yes. But Nova's proposal of doing single SHA-256 rounds in a separate core is bogus. I am not very knowledgeable on FPGAs, but I'd assume you'd at least unroll it.. which would nullify what Nova is trying to accomplish in the first place.

Anyways, it's not like SHA-256 is the difficult part in calculating LTC hashes.

I think if Nova wants to get started in FPGA development, a more realistic idea would be for him to experiment with making an FPGA implementation of a Bitcoin miner instead.  He's already caught up on the details of SHA256 rounds afterall..  :)

Nova, consider experimenting with Bitcoin instead.  It'll be a lot easier, since SHA256D is almost the only thing you'll need to figure out (+/- some miscellaneous fiddly details and communications), and you can happily instance copies of your core all over the place until you run out of logic area.  Figuring out scrypt is much harder than that, but because it uses SHA256, you'll need to come to grips with that hashing algorithm first anyway.

*embarrassed*
That's actually a good catch and frankly something I had not seen before but should have.
It would have been a costly mistake to proceed on that and while I can see now it's Round not Rand for RND, I openly admit I did not see that before and this was a critical thinking error.  

Thank you both for showing me my mistake.
It completely breaks my premise.

There is no need to raise further funds for this.  These two have shown me a critical flaw in the plan which would have been to isolate the RND function off onto it's own core.
I'm really glad the original author came on and explained this because to me it wasn't clear and in the absence of anything resembling a comment in the source code, I find this information extremely valuable.

So here is what we've learned.

#1 I need to review closer to make sure the code is doing what I think it's doing when working with someone else code, especially when that code has no comments and all I have to go on is a whitepaper.

#2 I did in fact see the RND define as a hand written psuedo-random generator.  It is not one, and had my brain been in anyway functional I should have caught that before making an announcement of this type.  In my mind it's still a candidate for optimization, but that's probably just me being stubborn.

#3 Not that it's advisable but...
 
There are several dev boards and OpenCL FPGAs out there on the market.  
It should in theory be possible to modify the OpenCL miner to run on one of these FPGAs.
The Altera Stratix V is at the high end of these and I did burn one out trying.

That should be enough of a start, however I do plan to keep chasing this dog until it barks.  I'm no longer asking for contributions of any kind, I've gotten the information I needed.  I really appreciate everyone's patience on this.

Anyone who wishes a refund is entitled to it.

Defines are not a new concept.  My line of thinking was that yes having that section of code unroll was precisely the problem.  Yes flat code can be nice when it executes in a single stack, but if you call out to a separate device with a single instruction it's faster in most cases than executing a bunch of things on the stack.

This is not my first FPGA project, but it is my second.  My first being one I can't go into depth about, but the gloss of it was "Here is an OpenCL FPGA, we already use OpenCL on GPU farms in our datacenter.  We are adopting the technology so that we can port our software to hardware and yield better performance for lower cost.  Here's a manual, here's a devboard, we're going golfing your's truly management".

That project worked well, most of what we had ported well.  It was almost straight across compiles in most cases.  When I left that job I was able to take my devboard which I played with and decided to try it at mining LTC.

The rest has been explained here.

As for your comment about whether I'm actually a programmer or not, yes I am, but this experience is making me wonder if maybe I've started to age out.  Now I look, it's pretty obvious where I made my mistake and I didn't check a fundamental assumption, I just assumed I knew.  There is no excuse.  That leaves me looking like a fool and I plan to leave this thread up and check it everytime before I post something "I just know will work". :)

Thanks for the info.

I like you more and more all the time, nova.  you seem an upstanding guy.  don't let these neysayers get you down.

Thanks, they're not getting me down.  I don't let others control my opinion of myself.  He had a fundamentally valid point.  I've worked as a coder as a team-leader as a programming manager and as a project lead in the real world.  I love to think to myself that my mind is as clear and as sharp as it used to be.  However if a programmer came to me with that level of mistake it would have been a borderline HR issue in my book.

Coming clean and saying oops I screwed up is one thing, but examining the fundamentals of how and why a mistake occurs is actually more important.
I post-mortem everything whether it succeeded or failed because the only thing that matters to me is the knowledge gained.  I view failure as a fundamental and nessecary part of the learning process.  However the same failure twice just calls into question one's own competency.

10 years ago I made a similar mistake and it cost me a company.  Literally a company I founded failed because I looked at a vast chunk of un-commented code, thought I understood it, modified it and a year later the company was gone.  I examined that whole scenario over and over again trying to find the root cause and realized the cause had only been me.  I looked at something, believed I understood what it was doing and arrogantly thought I could make it better, faster, stronger.

From that time on I had always been careful to consult with the original developer to divine intent if intent was in anyway unclear and just in general excersize much more caution before believing that I understood.  In this case I did it all over again, and this time it wasn't a vast chunk of cryptic code with no explanation, it was a small chunk with an entire whitepaper backing it.  I did in fact read the whitepaper.  I'm still not sure what the missing thought process was here.  I freely admit this mistake was the root of this debacle.

It still catches my eye as not optimal.  That's not to say it's suboptimal in anyway and I concede that it's probably optimal for a GPU, but it doesn't feel right for what I'm trying to accomplish, so I'm struggling with a new challenge.

Which honestly is exactly where I like to be.  I just need to be more careful next time.  :)

Silly kitchen psychology coming right up..

I don't think your problem is your age. Then again, I don't know your age, and I'm not old enough to know the effects of aging for sure. (I'm 24.) I think your problem is overconfidence. When you generate a hypothesis out of thin air (which is a valid way of generating hypotheses, and without any information indeed the only way), you assume it must be close to the truth, instead of finding out whether it's even related. Example: You assumed RND meant random, because that was probably the first thing to pop into your head. (Incidentally, this is how I deduced you don't know much about hash algorithms in general, since all hash algorithms I know of have rounds, and if I see RND being used in a hash algorithm, I'm naturally going to assume it's referring to rounds.) Then you decided that this is obviously the place where scrypt does its memory-hard magic, and is thus the bottleneck of the algorithm, without even looking at surrounding code to see how it was being used. Am I even close to the truth? Just curious.

Op reminds me of a younger me trying to do a digital scope without any knowledge of FPGAs as my final thesis. It sampled up to 20kHz from a 130Mhz clock. The interface looked killer though and the guys judging it knew even less about FPGAs than I did so everything went better than expected. God that was an awful implementation  ;D

Close but reverse.
I had read the whitepaper and got what I thought was a good understanding, of the way scrypt was supposed to work.
Then I looked at the code and I saw RND being called repeatedly.  Of course to my mind it all made perfect sense at that point.  You were clearly re-seeding a random number generator. (rounds of SHA256 had dropped out of my head).  The reference to SHA256 in the function name didn't really register, but the couple of times I did see it, my internal explanation was along the lines of "ok so he took the framework from the SHA256 algo and modified it to the scrypt algo".  At this point SHA256 rounds in scrypt had completely fallen out of my head.

Anyways, yeah I saw RND, realized in my infinite wisdom that you would need a custom seedable random number generator, tracked down the RND at the top said to myself "ok that could in fact work as a way of generating a random list".  Never crossed my mind to compare it to SHA256.  I get the concept of rounds, but at this point my mind saw that as being somewhere in a loop somewhere.  I didn't need to account for it just then.

Once I saw the section though, that's where I realized that this could be optimized and probably should be optimized by a custom core with only the logic to perform this function.  Putting it in the stack unrolled or as a function call would likely be much slower than a call out to a logic unit optimized to the specific task.  However the reads and writes in memory would be problematic, hence the idea of sharing on-die memory.  Still hadn't quite worked out the nuts and bolts of how it would fit together.

I still feel that way.  I'm still studying it, but I do still feel that way.

 

Whitepapers can leave one very confused, I for one have never read the scrypt whitepaper. I've just taken a cursory glance at it and decided I can't possibly understand its complex language within a reasonable time. Looking at code is far more productive. And yes, the SHA-256 rounds can be in a loop, but usually it's unrolled for speed.

If you still feel that way, you have to strive to discard that feeling from your mind as quickly as possible, because that way is wrong. SHA-256 is neither the problem nor the hard part in LTC mining.

Agreed.  Wishing I had a proper profiler about now though :)

Go on Cryptostocks.com and list there. There is another group offering FGPA shares. You should do the same and try and pull an ASICMiner type deal.

Let me save you some time and say the SHA256 overhead is around 0.1% of the overall processing time involved in scrypt, +/- a bit.  That's why mtrlt is saying not to bother with that, since there's an upper bound of about 0.1% you could gain even if you could optimize it down to zero overhead to calculate SHA256 hashes.

Great. Now GPU miners will be completely obsoleted. Way to go. :P

Lol

just from an economic stand point I believe , with regard to sCrypt one will see ASIC before FPGA - in this iteration of the cycle .


here is why I'm correct:


1. Because SHA256 was A  "first of a first" 

2. The ASIC market is much more well developed generally now in the cycle.

3. The whole environment is more developed the whole Crypto market .

4. high difficulty of SHA256 will drive market forces "desire" to push ASIC makers to build it.

5. They/some will do what the market want.

After a month and a half? Just curious.