Topic: Nanominer Announcement - page 3. (Read 11706 times)

I would definitively prefer a stand alone unit, if it's convenient to manage.
even 20$ extra for such wouldn't matter at all, because that's saved in electricity costs of having a host to run them, nevermind cost of the host machine ...

You make a good point.  I'm just doing this because it interests me and not because I want to make money mining.  However, I would be curious to know what the folks out there who are considering using an FPGA-based solution for mining would prefer:  an FPGA that plugs into a USB or serial port and requires a host like the existing systems, or one that can also run as a standalone system, possibly even on a wireless network.  Would that be worth another $10-$20 to the price tag?

Adding an SD card interface is almost free.  For the cost of a socket (around $3) and a bit of space on the PC board you're done.  The SPI interface only needs 4 connections + power.  USB (host mode) would be nicer, but somewhat more complex as you'd probably need a USB controller.

If you're going to add an MCU to the board anyway, and if you're considering an ARM processor, then you should know that there are a number of ARM9 processors that include an MMU and can run Linux if you provide them with sufficient amounts of memory.  But I suspect you may be looking at MCUs that have fixed amounts of on-board memory which is far short of what is required to run Linux.  Actually, I'm curious to know why you'd want to have an external MCU when the FPGA is fully capable of booting itself from compatible flash memory and a soft-CPU equivalent to an AVR32 would use less than a thousand LEs?

The advantage of Linux over rolling your own custom firmware is that it saves you a lot of re-inventing the wheel, especially for standalone operation.  It will be *much* faster to develop under the Linux operating system than it would be under Atmel Studio for instance.  Linux drivers exist for a lot of hardware (ethernet/sd over spi/usb/etc.) whereas the selection in Atmel Studio (or AVR Codevision for that matter) is much more limited.  And what is the added cost anyway?  An extra watt of power dissipation?  A few dollars in parts?

I was asked about how the boards are expanded upon, and gave a short answer that summarizes the solution.  I'm well aware of the challenges that are encountered when transmitting signals.  I didn't going to go into absurd detail, but in anticipation of people getting irritated that I say that a bus is indefinitely extensible, I even said that to maintain performance there would be a limit imposed on devices per bus.  That's not to say there aren't other things in place to preserve performance, but I figured it would be sufficient to say that, at least.  Apparently it isn't, and I'll try to do better when answering questions in the future.


These I am taking into account, except for perhaps an SD card slot, but I figured the good folks around here would probably just be more interested in what I'm using for hashing, and maybe what I'm using for control, and not so much the infrastructure chips that will make it all possible.  The MCU in particular might get replaced with an AVR32 or an ARM device.  I won't be running Linux on the MCU, whatever it ends up being, because that's too much overhead.  However, given the board's specifications, I'll make sure that if people would like they can program the device with Linux, provided the resources to do so don't make the board cost anymore than it already would.

Maybe you should repeat your first years electronics course, and the influence of capacitive bus loading and line inductance on speed. Please don't forget that you have only a limited driver strength. I bet just jumper wires with many connectors inbetween and no termination will give intresting results in signal integrity.


Maybe you could ask ztex for that information. In the past he had a license production offer.

Consider adding a few extra pieces of hardware that are missing from existing FPGA mining systems in order to allow it to operate in standalone mode.  I'm talking only about some SRAM, and ethernet port, and an SD slot.  The purpose of these additions is to allow the FPGA to run Linux via a soft-processor on board.  I'm assuming you're already planning to include some flash memory to hold the bitstream so that the device can coldstart by itself.

I have used just such an approach on my Altera DE2-70 development board.  It runs no-mmu uClinux on a Nios II soft processor.  Both the Nios II and a slightly modified version of fpgaminer's FPGA mining code are loaded into the bitstream.  I've nearly completed a very simple C-based miner (no-mmu uClinux is too limited for existing miners as far as I can see).  It communicates directly with mining pools via JSON/HTTP in order to fetch work and report results.  It is all somewhat preliminary at this point, but I hope to have a fully functional system running within a week or so (albeit at a measly 25MH/s which is all I can squeeze from the DE2-70).

It should also be straightforward to get uClinux running with an MMU on an FPGA which creates a lot of flexibility and opens up a lot of possibilities in terms of customizing the system.  For example, a tiny web server could be run in order to allow the user to control and configure the system (just as is done on many consumer grade wireless routers).  In fact I will probably do this myself as soon as I finish with the no-mmu system.  BTW, uClinux runs on the Xilinx MicroBlaze soft-CPU as well.

If this is of interest and if you'd like some assistance creating it, let me know.

If you read the full description you'll see that one motherboard does not limit you to a certain number of devices.  They run on a bus, which is extensible indefinitely, at least in theory.  The bus can be connected with stacked headers, or via a jumper cable, so there's no capacity limit physically either.  There will be a firmware imposed limit to ensure performance.  Since the firmware will be open source, you'll be welcome to remove said limit.

Perhaps, if there's a lot of demand for multiple-miner boards, I'll adapt the design.  Until that time, as it's been made abundantly clear, I need to prove myself, and to do so I think a good place to start is affordable, easily extensible, single core miners.

Additionally, I'd like to know where these bulk FPGA discounts are from, I've yet to find a distributor who will give more than a pittance of a discount on large orders.

Exact control and mining hardware specifications are listed in the newly updated first post.  Specifics can be found there, but the control device will be a Microchip PIC32 and the FPGA will be a Xilinx Spartan-6 XC6SLX150 running at 200 MH/s with the current firmware.

The whole idea of a multiple FPGA units per card is to actually save money on building the cards by benefiting from bulk chip orders pricing and pass that saving to the customer, since having cards with say 10 chips would likely cost around 70% of buying 10 of the singles. If you can afford a 350+250/card starter you can easily afford an upgrade card that costs around that price. And having a 4 chip card starting around $700, $1200 for 8 and so on and forth would make more sense than buy lots of boards that give no nominal performance increase... Why pay $1000 for 800mh/s in 4 daughter cards when the BFL gets you 830~mh/s for $599 without the need to buy an additional main board to plug it in? It's very poor efficiency and not cost effective to have the performance upgrades so small, they shouldn't be less than ~500mh/s per card ideally more or you will need a warehouse to store all those little boards to get any high end performance. I am sure you can't put too many upgrade cards per motherboard either, which means you will need another $350 board to add more after a few modules upgrades, speaking of which... how many upgrade modules can your main board hold before I would have to buy another board to get more cards?

They have to do with eldentyrell (as his post said). There is no price mentioned only that eldentyrell has put many hours into the work and wants money for the time spent. But no one knows how much $$ will be needed for eldentyrell to release the code, if it's ever released. It seems that the alternative is to
have people send boards so the encrypted bitstream can be loaded. Not a very popular idea I'd say.

I would expect that all the currentt board makers based on the xilinx xl150 would really like to get 300MH/s per chip.

Did you get a refund? A horse has to win a race or two before I'd put any money on it.

Being a registered company helps in that part ^_^
You might be interested as a fellow finn what i'm thinking about doing: https://bitcointalksearch.org/topic/mining-resources-hostingleasing-service-worth-it-68634

Shipping is a minor cost, the real problem is the 23% in taxes (thats 23% of the order price including shilling) when ordering electronics from outside the Eu.

You've done that before when you asked for donations. I've counted alot on that 75MH/s from 22k altera cyclone and I donated. They are in easy to assembly TQFP package and costs 36$.

Although I'm unsure of what Silicon Valley professional rates have to do with anything here, I appreciate the suggestion regarding improving the bitstream.  I did already say that the quoted 200 MH/s was a verified, proven, base rate, and if you read reasonably you'll find most of the numbers I have right now are preliminary numbers, numbers that are a worst-case scenario, numbers that I will try to improve, but that are not inflated because I do not want to promise what I cannot deliver.

Since you are initially targeting the well-known Spartan6-150, maybe you can focus your youthful energy and enthusiasm on fitting three SHA-256 instances into the FPGA, and then fine-tuning these instances to about 100 MH/s each (300 MHs/s total), and then releasing the binary, unencrypted bitstream into the public domain.

That would make you a hero and a living legend on this forum.

While I admire Eldentyrell's technical expertise, I admit that I do have issues with his idea of getting "fully compensated" for his near genius-level optimization. Fully compensated at what hourly rate? A technical consultant (hardware, software) in Silicon Valley will typically bill at an hourly rate of $100 & up. A Silicon Valley lawyer bills at $300 & up. A psychiatrist bills at $400 & up. An anesthesiologist bills at an hourly rate of $700 & up. So, if he has invested 500 hours into this, does he expect $50,000? $100,000? $200,000? I seriously doubt that he will be able to raise amounts of this magnitude on Kickstarter, which leaves the FPGA mining community stuck at 210 MH/s (ZTEX bitstream).

Please consider it.

Compatibility and integration with existing systems are a great idea, we want this to be as versatile and easy to use as possible. There will need to be a dedicated GUI/toolkit for Nanominer, if only for configuration and use of features unique to this system. As he's mentioned, Azelphur is my man handling the software side.  He does good work and I'm lucky to be working with him.  He's the one to talk to with ideas on how to make the user experience better .

As far as 28nm technology goes, Nanominer's first iteration will not be on a 28nm chip, it wouldn't be economically feasible.  However, to answer your question, in the future when it's within a reasonable price range, we'll be more than capable of delivering miners on whatever technology is available, 28nm or otherwise.  That is, unless my research, work experience, ECE degree (in progress), and hobbies all go to waste, which I doubt they will .

And no, as to the Nano running at 75 MH/s that figure was a well meant but frankly uneducated estimate on my part.  Maybe I should say here that I'd like to apologize for promising the moon in the earlier stages of this project.  I know that people offering more than they can deliver is not something you all want to hear.  That's why, with this project, I'm offering nothing more than what I know is possible.  If you'd like to know how I came to a decision about a feature, or have a question about how I intend to achieve what I promise, please do ask.  It's all being planned out with the help of others with various areas of expertise, and always conservative estimates.  I'll be happy to release something that outperforms what I promise, but in engineering there are always unforeseen hurdles, so I'm trying to be realistic, and even a little pessimistic.

More to come...

Integration with cgminer would be really great, since it already supports the BFL Single and the Icarus, and it also supports RPC for frontend/easy remote management, if required.

No need to reinvent the wheel, I'd say!

Make the browser the GUI.  Doing a GUI any other way is not so portable plus they always require all the extra gui packages, etc.
Everyone/everything has a browser already. And keep it simple so command line tools can use it too.

Very early days yet, but I'll most likely be making the front end for this. My basic ideas for that so far are...

A python library, to enable easy communication with the miner in your own code should you want to
Command line and GUI tools (which use the library).
For the GUI I'm still not settled on a GUI framework. What ever I choose I intend for all of it to be cross platform of course. I may also make a web front end?

comments on this also welcome

I have read that the smaller-size/lower-power curve of FPGA ends with 28nm. So it seems that the 28nm designs are going to take more work than in previous generations. Is the sha-256 code required simple enough that the 28nm design won't provide new stumbling blocks and/or increase time-to-product?

wonderminer,
Were you able to get 75MH/s on a de0-nano or is that just a theoretical number? Is there a git repo somewhere?

I'm based in Canada, however I know that the demand for these boards will be international. 
My goal is to mitigate some of the shipping cost by decreasing the profit margin, like I say my goal is only to make enough to be worthwhile and pass on the rest of the savings.
As well, small form factor and an off-board power supply will also help with this, though I know this holds for most FPGA mining technologies.