If you read more carefully you'd notice I have no intention of using a Cyclone V. What I said was, when the new series is released it will hopefully mean price improvements on the chips that are currently giving 200 MH/s.

Verifiable: That is to say, I'm not developing a particularly novel bitstream, it's widely understood and proven that with the chips available to us we can get 200 MH/s.  The parts for the rest of it are available to purchase now, and once decisions are made on feature sets I will post what those parts are.  Again, verifiable, already in existence, not some insane thing that I need to prove.  The rest is PCB design, programming, and construction, all of which I am quite capable of doing.

Feel free to preface your comments by saying you didn't read carefully if you didn't.

I spoke with a distributor Friday, they're expecting late April, early May release of the Cyclone V.  However, these things change, or I may have been misinformed.  All that said, the philosophy stays the same: when the new set of chips come out, there will be either a performance bump or a price drop for us.  If the project is ready before the new chips come out, we'll start using one of the currently available candidate FPGAs and switch over later.  As stated in the initial post, this architecture supports upgraded chips via simple firmware updates.


Two important things there:
1) Making a PCB for 8 FPGAs forces people to buy in multiples of 8.  That's an expensive board.  Wouldn't you rather have the option of buying those 8 chips one at a time?
2) If you want to do the mass thing, you go ASIC, you don't buy 250K FPGAs.  When you pay for an FPGA you pay for a)performance and b)reprogrammabililty.  If you want a lot of them, and you don't need part b, you're going to save by making your own ASIC.  But that day has not come for bitcoin, not by a long shot.

It's my mission over the next while to prove we can.  I have the prototyping hardware at my disposal, so stay tuned.

We're going dedicated. And reasonable, no more pies in the sky, just verifiable numbers and efficient design.
It all continues here: https://bitcointalk.org/index.php?topic=68352.0

Nanominer BitCoin Mining FPGA Platform – Coming Summer 2012


Specifications (Updated)
FPGA Mining Core: Xilinx Spartan-6 XC6SLX150 (N3FGG484C Package)
Controller Device (MCU): Microchip PIC32 (MX795F512L) [Motherboard Only]
Hashrate: 200 MH/s (per mining core)
Cores per Board: 1
Control Interface: Ethernet, USB
User Interface: PC/Linux/OSX GUI
Power Consumption (estimated): <10W
Expansion Method: Mezzanine Header Expansion Port

*Exact hardware subject to change without notice; performance will not be less than the above stated.

Design Philosophy

Open source technology:
Nanominer's schematics, parts lists, FPGA bitstreams, and source code, as well as the controller software will be freely available to all.  Want to improve it and build your own?  We encourage it!

High-tech power, low-tech simplicity:
Nanominer will ship ready to use.  Simply plug in the power supply, attach Nanominer via USB to your PC/Linux/Macintosh computer, or via Ethernet to your router/switch, start your software, and enter your details in the easy-to-use GUI.
Nanominer also ships ready to customize, with open sources and configuration via Ethernet or USB, you can tweak any aspect of the device's functionality to your heart's content.

Incremental Improvement:
A system can consist of a single board, or many, depending on what you would like to spend.  If you decide to add performance later, you can.  This also means that down the road, when new FPGA devices are released, and you want to upgrade, you can keep using the old with the new.  Nanominer version 1 will be able to have later versions plugged into it, so if you buy a main board now, that means you can keep reaping those savings far down the road.

Expansion without redundancy:
Nanominer uses a single controller and power supply for the main board, then can have additional mining cores stacked via mezzanine headers to add hashing power to your mining system.  Boards can also be daisy-chained, meaning you buy one controller board, and from then on it's just mining boards. Those savings in controller and power devices are passed on to you.

Mining should not cost the miner:
Nanominer's low wattage FPGA mining cores, extensible architecture, and small form factor mean you can mine without consuming undue space and power.  This makes mining simpler, and more profitable.

Decisions, decisions...
Nanominer is currently in the component identification stage, and some questions need to be answered.

Questions you can help us with are:
-Do you prefer Ethernet or USB as the control interface? Or are there other suggestions?
-Would you like an optional WiFi interface?
-We would like to provide a warranty on Nanominer devices; what would you as a customer like to see that warranty protect you against, and for how long?
-Is there anything else you'd like to see, functionality-wise, on this device?

Questions we're answering right now:
Q: What is the best FPGA we can put on this board?  
A: Altera's new Cyclone V device is releasing soon, and new technology means potential price drops.  This means that Nanominer may perform at more than 200 MH/s, or we may simply use an older chip at less of a cost.  Either way, time will tell.
Q: How much exactly will this cost?
A: If we were to build it now with a Spartan device, the price would be $275-300 USD for the main board, slightly less for an expansion (both 200 MH/s).  Depending on the features we do or do not include, and depending on how chip costs change with new technology being released, this figure may be less.  If we include a warranty, this figure may be more.

Finally, questions you might like to know the answer to yourself:
Q: You say 200 MH/s is the hashrate, how sure are you of this?
A: We have a number of candidate FPGAs in mind, and we're quoting 200 MH/s because we've proven that with a cost effective device, we can achieve that rate. Nanominer will not perform at less than 200 MH/s per board.  There is a possibility that it will perform better, however.

Q: Summer 2012? That's a long time to wait... why the late release?
A: Part of the reason is we're waiting for new technology to be released and prices to settle, so you get the most bang for your buck.  Once that happens, developing these things takes a lot of time and effort.  Also, I'm a university student, and my time will be much freer in the summer.

Q: You say boards can be stacked or daisy-chained? How many mining chips can I connect to one main board?
A: As far as stacking the boards, we'll recommend you don't stack more than sets of four; however it's technically up to you.  Daisy-chains require a cable that will be included.  The total number of miner cores per main board is limited only by bus performance.

Q: How accurate is that $275-$300 figure?
A: That is based on a parts order for the printing and assembly of 25 boards.  So it's very accurate for the time being.  If there's more interest, we'll make more boards, and because of bulk discounts, that price will go down.  If advances in technology this spring work to our advantage, again, that price will be reduced.  If a feature like WiFi or a warranty is added (these will be optional), that price would increase some, with obvious benefits.

Q: You mention “main boards” and “expansions”, what does this mean, exactly?
A: A Nanominer system consists of one controller board ($275-$300), and as many expansion boards (~$250) as you'd like, performing at 200 MH/s each.

Q: Does that price include cables, power supply, etc?
A: It does, and that accounts for the range.  There are a few parts we have candidates for but have not fixedly decided on.

Q: This is a pretty good price, what's the catch?
A: No catch.  Designing the system to run on a single power supply and single controller saves money.  Producing many similar boards means part discounts, and adding only my design time to the price tag means I'm only making enough profit for it all to be worthwhile.  Also, this won't be a fancy board; it'll be professional, but not flashy.  That also brings down the price some.

Thanks for reading, and please let me know what you'd like to see in this design.
As always I'm open to comments and suggestions, email, PM, or post.
Cheers!

---

That said, after a lot of looking around, designing, talking, and pondering, it seems that ZTEX and BFL have some hard-to-beat boards, as some people made very clear in my other thread. 
Starting a new SoPC to mine bitcoin at this point seems to only want to draw ridicule...

So
I'll float an idea...

Option 1:
Were I to develop a board that was priced 300-350 USD that had the following features:

• Spartan-6 (or similar) @ 200MH/s (exact TBD, using XC6SLX150 Specs)
• ARM Cortex-M3 (or similar) Serving Ethernet & Control Functionality
• Optional USB configuration/communication
• Standalone Architecture (Ethernet only, no USB PC host)
• Simple Web Interface & Config (HTTP Server w/ statistics, status, config...)
• Extensible Architecture (Mezzanine [aka stackable] or similar build)

Would that be interesting to anyone?  I know the hashrate, cost, and power consumption are similar to other competing technologies, but the essentially plug-and-play configuration, web interface, and mezzanine extensibility do make it a lot easier to start using.

Option 2:
I say, forget this, I'm just going to use ZTEX, and make a motherboard for ZTEX daughter cards so that they can be controlled without a PC host, and still have a web interface for configuration/data, price ~$100 to handle multiple ZTEX boards (I need to look at more specs to know precisely how many).

---

Either of these options would be complemented with a full featured web application and configuration utility, so no more Java, no more terminals, no more OS specific utilities, or any of the other technologies crammed together to make all this work.

If people are interested, I'd love to do this.  I don't mind making "third-party" technology.
Now, importantly, I won't be asking for money to start this project.  This will be all on my own time, on my own dime, until I have a working proof of concept that I can put pictures, screenshots, and demos up of.
As always donations will expedite things, but if for some reason I need something specific, I'll mention it.
What that all means is, I just wanna know if it's gonna be worth it.  It's gonna be a lot of work to do either of these options, and I want to know that at the end, there will be people willing to purchase these.  Basically, all I need is a show of hands.

Thanks so much, and I'll continue to keep things updated.  Expect VHDL from Nanominer over the next couple weeks, and more specifications of the proposed project over the next few days.

Thanks so much!

Controlling an FPGA farm can be done with almost any microcontroller you want to use.  The new wave of all these microcomputers (beagleboard, panda etc etc) simply allows you to do so while using familiar linux kernels; if you want to control an FPGA farm with minimal power and space consumption, you have a couple of options that are simpler, really...
-Arduino w/ Ethernet Shield
-NXP mBed MCU
-Make your own board with a PIC/ARM/AVR/whatever and either tap into the GPIO on an FPGA board or put the FPGA on your board yourself.  Regardless it's gonna consume minimal power and minimal space.  And it's easy, mbed or arduino are both great platforms to start working on, from both a learning and business perspective.

And which FPGAs need an ATX PSU...?

Is the idea here that it would be smart for me to try to make an uber cheap controller board rather than try to compete with BFL or ZTEX in FPGA mining tech?  Cause that I can do, let me know the specs of what size constraints and power consumption you'd like to deal with and I'll put up a design, no problem.
By that I mean something you plug a miner into one end, the wall into the other, an ethernet cable for getworking, and control all your mining on a little LCD onboard the device without all this nonsense "uPC" overhead. 

Some of you may not be particularly impressed with my work over on "Nanominer", fine, whatever, I'm not asking anything for this, I'd like to get into the hardware design game and I don't mind doing this all on spec, what sorts of features/constraints are we talking?

You can find your answer by reading through the posts or re-checking the first post, or my site.  The FPGA currently is running at 800MH/s verified.
As far as it costing you, the software is free, and like I've said, I'll be publishing it after crunch time is over at school.  Donations, however, are always welcome.


Not related to BTC mining, but I have about 12 Arduinae among other microcontroller dev boards (PIC, ARM) here or in my lab.
They're great boards, they will not, like the man says, generate BTC though.  If you have a specific question feel free to email me; this thread should probably be kept to BTC talk.

Still doing exams, thought I'd pop my head up.

Sorry for the delays in update, it's exam time and I'm pretty busy.
To answer a few questions:

Regarding "reinventing the wheel": I'm all for working from what there is, but I'm doing this project partially as a way to augment my understanding of circuit design, HDL design, cryptography/analysis, and mathematics.  I will build my own IP for things if I deem it educational.  Will that slow things down? Sometimes. Will that also potentially improve the final product? Possibly. I'm not doing this project because it's so lucrative... it's not.  It's educational.

Regarding when you can see the code: I'll be uploading it I have in entirety to my website once I'm finished exams, it just needs to be commented and some translated into VHDL from Verilog.

Regarding whether this project is official or has a greenlight: Simply put, nope.  This is entirely of my own volition, all funding is from donations, and the time is what I can spare when I'm not designing vehicle and robotics control systems, doing homework, or attempting to have a social life.

Another comment I'd like to make regarding the design of Nanominer:  This project will be the best I/we can make it; however I know there are a lot of people working on FPGA mining technology, and I may well not have the technical edge; I certainly don't have the time/funding.  My hope is, despite the possible disadvantages, is to have it be fully open-source and extremely well documented, I'd love to make something that any of you can download and modify to your liking or improve upon with ease, Bitcoin is a great platform on which to learn a lot of topics.  The "edge" I hope for in this project is a mathematical one, which may be a pipe dream, or never work, and I won't let it get in the way of Nanominer being what we want it to, but I will put time into mathematical research, even if it seems like a dead end to people.

If you're looking for a good, solid community project you can help work on and improve, with someone at the head who's willing to learn and improve, this is for you.  I'm not here to make money, I'm here to learn.  If that bothers you, there are a lot of other projects for FPGA who are interested in profits.

I'll keep you all posted, and I'll let you know when exams are finished, that should give me a decent amount of time to get things going.

Let me restate. Would someone like to work with me to get that interfacing with the FPGA. I'm not good with python, and I'm not sure exactly how that wants its data.  It's not just a matter of slapping serial on there and linking it up with the script, though I'm sure it's a great script.

----------------------------------
I'm squeezing 26.5MH/s out of a Nano with the latest design; that's verified accepted shares.  I need to run the compile again with subscription edition, because this fitting is really poor, I'll have better numbers for your tomorrow.  I've also got some rewriting to do that'll increase that speed. This Quartus web edition is really crippled.

In looking around a little, I've noticed prices on FPGA standalone chips, Cyclone IV E series, but larger than the Nano's chip by a little more than 2x.  The chips are about $85 a pop, and would require another $30-45 in circuitry/board/etc, so about $130 but it would mean some design and manufacture on our part.  That and the shipping would be cheaper than anyone else's, since I'd do the mass orders and ship cheaply for everyone.

Using the aforementioned chip and a custom board you could get 53MH/s (likely more, but I know you guys like verified numbers) for $130 at 0.5W max.  Is that something that I should consider pursuing? I have a friend who's excellent at circuit design and expressed some interest, but I'd need to know there was interest.  I know the number isn't dazzling, though it will likely be at least 60, but that power figure and the fact that the board would be a couple inches by a couple inches is very attractive when compared to PCs...

Let me know.  Either way hopefully these improving numbers are good indicators to you all; I haven't exhausted all the optimizations I've been working on, so more better numbers to come.

DE4-230 Stratix IV GX: 800 MH/s

Who wants to write a script to handle UART interfacing rather than this JTAG business?  PM/email me if you're interested.

++More (non-mathematical) design improvements to be implemented in the near future.

I'll answer this last one here.

You're right, there's a certain value that will work 100% of the time for difficulty one on that last addition.  This answer was given for the sake of simplicity, but it was also given in non-absolute terms to illustrate how probabilistic advantages will work.  Real advantage can be taken earlier in the algorithm where we're dealing with probability thresholds, not absolute certainty.  SHA-2 at 64 rounds is random (succeeds at mathematical randomness tests).  However given certain values at certain stages, that unravels. The ultimate example is adding a round constant which is a value we know 100% for certain.  The goal we're going for is to find them a little earlier, say round 126-7 where the probability might be in the fractions of a percentage, and the relationship to check may not be greater than, less than, or equal to; it's going to be something completely different that specially relates to a SHA-2 round.

Further answers directly related to the mathematics of it will be at http://www.nonverba.org/forum.


I'm not an expert as far as GPU mining, but unless underclocking RAM actually invalidates the RAM functionally, it will not be a problem.  As far as increasing power consumption, I don't believe it should be a detectable amount, this again from an educated guess; we can see.  The reason I say so is that "not using" the RAM doesn't mean "not powering" the RAM, it means not accessing it. Now, we're just accessing it, the amount of electricity we're sending to the memory hasn't changed (the electricity related to logic signaling is absurdly small).  RAM doesn't lie electrically dormant, just logically.

From my forum at http://www.nonverba.org/forum:

So I've been talking to a number of people about the possibility of using side-channel vulnerabilities in the bitcoin mining process to speed up mining. It's all been vague until now, so I'm going to give a very tangible example.

Assume we roll up the algorithm: 2x SHA-2 = 128 clocks/mining operation.
Now, the final addition we do is to add the round constant, something that will always be the same.
In this specific situation it's 0x5be0cd19. Now, before we commit our 128th clock cycle to adding that to our previous 32-bit "h" value, we can add very resource friendly code to determine whether our "h" value is too high to yield a winning number. We can say that if "h" is greater than 0xa41f32e6, it cannot yield a winning digest and we should not waste that clock cycle. Great, that was easy, and isn't nearly the magnitude of problem I'm working on, but it's here to get the idea across. This one is a completely predictable example, the true optimization will come from probability-derived solutions earlier. Anyways...

By eating a couple of logic elements and little block ram, we can implement this check.
Now, how does that all translate into performance gain? Well, 64.11% of hashes fall into this range. That means that 64.11% of the time, we can save one clock cycle on a core, which is 1/128 or a 0.78125% speed increase.
0.6411 * 0.0078125 = 0.005% increase in performance. Pulling, say, 500MH/s, that's 2.50MH/s performance enhancement over time. (I'm pretty sure this math is accurate, but if it's not perfect, it's at least close, these are the ranges we're talking about.)

It doesn't maybe sound like a lot, but think about it, we just pulled 2.5MH/s out of thin air. Or rather, out of unused block ram. It didn't cost us time, or power, or logic. The earlier these constants can be checked out, the less their probability of success, but the higher their effect on performance.

In case this was tl;dr material: We just pulled 2.5MH/s out of thin air and can do it repeatedly.

There are a lot of these optimizations that could fit on even a Cyclone series FPGA. The only thing standing between us and them is time and mathematical analysis. Hopefully this gives you a clearer picture of what I'm talking about, and lets you know that it's actually feasible and just requires time and effort, rather than being voodoo.

Oh, and this process isn't just for FPGAs, it works on any mining platform.  These are the optimizations you can get your hands on before anyone else with donations.  Seeing the incentive yet?

The start of a repository of resources, information, and eventually tutorials has been started here: http://nonverba.org/forum/viewtopic.php?f=8&t=6

Check it out, sign up, post, get some discussion going.  There's been a fair number of people mentioning they'd like to get into FPGA programming, so let's do it.

Alright everyone, I've put up a forum on my website dedicated to Nanominer.  There's a whole bunch of new information as well as better ways to keep track of the project there, so head on over to
http://nonverba.org/forum/ and check it out!

[deleted, argumentative]

I'm very familiar with the SHA-256 algorithm and understand its complexity.  And I don't mean from reading Wikipedia.  What you fail to capture here is that I'm not looking at this to know exact values to avoid...  it's a matter of probability.  Why does SHA-256 use 64 opaque rounds? Precisely so something like this does not happen.  It might be a waste of time and resources if checking a value wasn't so resource-friendly, but it's not.

As far as "more standard" optimizations, I already mentioned I would do that.  And I know adding is the biggest resource hog here.  I'm looking into the best ways to do that, precalculation, DSP chips on custom boards (to offload logic that does not require programming and other benefits)...  I may be a student but I'm not exactly lacking in mathematical or engineering understanding.

The 200MHz issue... Actually there is a reason we're down in the "70s" range of timing.  Optimizing for high clockability is a huge challenge. It is a problem, also something I'm already looking into.  I'm looking into quad-pumping and other technologies that major manufacturers use.  I'm going to take it from your knowledge of some of this that you understand how hard it is to come by clean clocking, and then making sure that doesn't become unstable.  Have you looked at commercial IP for SHA or other block ciphers? They don't run much higher than 200MHz stably, and they cost thousands of dollars and have had many engineers optimize the hell out of them.

So all that to say, yes I know what routes of action to take.  I also won't say I'm looking into something unless I believe it's feasible and have done adequate research.

I don't expect everyone to be super gung ho on the idea, but I've been into crypto a while, and gotten pretty intimate with SHA-2.  I don't mean a midstate, I mean knowing that on the 124th round a certain value for one of the 32 bit words disqualifies the hash.  Quite possible.  The more work I do on it, the better the miner will be.  Plus, these comparative constants take advantage of the BRAM we're not using well on the Cyclone series.  Some miners... maybe... use something like this, but I'm talking a pervasive mathematical analysis. MatLab is attacking it now.

It's all proportional to time I spend really, there's so much RAM to be used for constant comparison that adding checkers along the algorithm wouldn't even prevent adding cores, it would just add performance, and a lot at that.  Just imagine knowing 5% of the time on round 124 to abort the calculation... you have to multiply those (logic savings or time savings) by millions of times per second.  It's pretty big.  It's just gonna require some expert help (check), a ****load of time (maybe?), MatLab (check), and y'alls support.  I'll see if I can come up with a tangible example.  Wiki side-channel attack, look around, it's not voodoo, it's just probabalistic finite field mathematics that I probably shouldn't be doing until grad school.  But that hasn't stopped me before.

P.S. The midstate etc. calculations most clients use are to avoid collisions on the network, thus not getting stale packets.  It's not to save clock cycles. ^^

P.P.S Also check out the SHA-2 wiki's pseudocode, if you're into that kinda thing, you'll see where this could be useful pretty fast.

P.P.P.S.
Donations have bought me 2 DE0 Nanos for cluster testing;
As always my time is hard to spare, so if you feel generous (even a little), the more the merrier.  I seriously spend hours on this stuff, I'll log them if you like.  Plus it's high level math you all don't have to do .
I know results are important so I can post up some more of how the math stuff works, maybe implement a proof-of-concept, but it will take me some time.
As far as things I need to continue, donation wise, the 2 fpgas are paid for, the website and hosting are paid for, and I know it's nice to donate for tangibles but at this point I have all the tools I need, i just need motivation and hopefully some money for my time.  As per usual it's an investment.  If this math thing sounds like a good idea, talk to me about it, I'm happy to explain etc.  Given that most people mining today don't use custom miners and I've sifted through the code of all the standard ones, this mathematical edge would put anyone using it quite a bit ahead of the game.

In fact, would access to proprietary mathematical data/code/programming files be incentive for donation? The numbers and formula I develop will be available for FPGA but I also work with coders who could integrate this benefit into your existing open source miners.

Something like:
First 100 donors have access to weekly updates to how to look for bitcoin "smarter" up until official release, then it becomes open source?
Amount and degree of advantageous code could be proportional to donation...  it would be something like "if round 122 maj function has xyz properties, abort" plus pseudocode or C or VHDL.

Sound interesting?

No problem, it wasn't the most brilliant question.

Anyways, here are the stats we have cooking, no screenshots yet, this project is requiring more math than I might have liked.  One of the ways I'm optimizing the mining is checking late-round values against (to be determined, but known) constants to determine whether or not they will (or are likely to) yield a win.  If not, the SHA algorithm aborts early, saving resources.  It's gonna be a lot of work, and that's a big way of how we will be shrinking approximately 60 MH/s (number based on more recent data) onto a Cyclone IV Nano.  The work begins today.

SHA-2 hashes are unpredictable at 128 rounds, or 64 rounds, but if we have access to the data all the way through, and know what our starting and end data should look like, we can side-channel it.  I'm speaking to our school's cryptanalysis expert.

The above may sound like heresy but block ciphers are weakened by attacking their implementation, and we have full access to this one.   I'm going to keep working, on all fronts of optimization. 

Donation-wise, there have been about 45 BTC and $50 USD/CAD donated, allowing me to buy a couple of DE0 Nanos from our friends at Terasic and paying for a bit of the countless hours I've been pouring into learning all of this.  Hopefully that's something you're all happy with.

There's something important I wanna ask about as far as rating hashrates: we say GPU hashrates are such and such a speed, but that is not something hardcoded into the core, that's how the GPU breaks down the instructions, and that's why it varies a little over time, and per card, as well as with other factors.
Is it more reasonable to quote an effective hashrate (i.e. calculated based on share production) or a hardcore rate? Since the effective rate will be a fair bit higher than the hardcode rate.

Let me know, I want to quote you guys the right numbers.  Either way I'll show you shares/sec rates as well as hashrates.

Expect some numbers soon, what they'll be, I dunno .

People have wanted to see some progress so:



This is modified fpgaminer code getting 125MH/s on one unrolled core.  Like the picture says, 4 of this core will fit on a Stratix IV GX 230, yielding 500MH/s.  I've been working on this all day, and will continue tomorrow, I'll post a 4-core variation then.

I know 500MH/s for a $2995 board isn't real impressive, but you can refer to the resource allocation to see why.

This figure doesn't touch what the performance of Nanominer will be once we implement DSP, custom SHA-2 core, and cluster computing (i.e. A helper FPGA alongside a high-power one to get the best use out of each for the least power & money).

We've got big things coming, people.