I’m planning to do an article on how to convert Ebay scrap FPGA into bitcoin miners.

Target cost is going to be about $100USD per 200MH/s (cost mostly on the ebay scrap)
so in the case of this…

4 FPA rig..

It would only cost you $400usd!!!!!

Now obviously it is not going to have the same ‘expert’ polish as this top of the line product.. but what do you want for 400 bucks..

Yep I know ASICS are coming soon and that Avalon is already on the market.
This is not a ‘get-rich’ quick scheme
Rather it is a last ditch attempt for people to have a final dabble in bitcoin, before the shit hits the fan and mining becomes impossible for most ‘normal’ people.
Who knows this shit may even sell for $250,000USD in 30 years just like the Apple 1

Litecoin… well lets see what is possible….., but from early experiments it is not cost effective even at $100Us because the KH/s rate is way too low

So if anyone is interested post a comment, maybe even check out the advertisers.

The coins?
Well everyone else does it so I can too…….

So today I went out and purchased a couple of Xilence PSU (XP500), specifically because they were rated at 30.0A at 3V3.

We needed a fairly strong 3V3 supply rail to feed a couple of maxim buck converters down to 0.98v for an FPGA project.

You would think that 3V3@30A would be able to handle such a simple situation.

Well you would be dead wrong..
After loading the PSU upto 6A the supply rail dropped to 3v1 we then added another 6A load and the rail hit 2V98 Also the 12V rail began to sag down to 11v8 volts and the 5V rail hit 4V8, even with no loading applied to anything other than the 3V3 rail.

Considering these supplies are rated at 3V3@30A, we should not see such poor power degradation with what is basically a 12A loading on the 3V3 rail.

By the time we were at 18A@3v3 the 3v3 rail was below 2v9 and the 12V rail was also in decline.

Furthermore the power supply started to make a sound as if there was a screw loose in the cooling fan, removal of the load caused the sound to disappear.
I’m of the mind that something was breaking down inside the PSU whenever the 3V3 supply was loaded.

OK fine let us contact their support…
After finally getting their support system to accept the email request and supplying the PSU serial number
I STILL have NOT had a reply after 7 Days….

Is the quality of the Xilence PSU bad or is the application unsuitable?
Well, to put this in perspective, I also purchased a really shitty Chinese made ATX-320T PSU that claims it can supply 3v3@14A, this thing cost less than $11USD(I kid you not)
After 4 months at an overload of 18A@3v3 the supply rail on the Chinese PSU has dipped down to 3V2 the 12V rail is at 12V2 and the thing is still as quiet as a whisper, plus no magic blue smoke daemon has appeared.

Recommendation
Do not EVER buy Xilence PSU’s, it may even be better to purchase that shittly little Chinese brand after all.

Conclusion
Xilence PSU’s appear to suck ass so badly that you would NOT want one inside your computer.
By the way their internal build quality on the PSU is basically ‘Fucking abysmal’, parts of the inline filter are ‘flapping about’ in the air as if it was an afterthought needed to pass the EMI standards.
Whilst there may be many Xilence the market, such poor power regulation can only lead to seriously stressed computer parts and early failure of equipment.

Time to return this Xilence crap to the shop and save some serious money.

Since the ASIC order went tits up at Tom’s ASIC fuckfest and BFL STILL have not delivered product, we spent the time working on our existing FPGA miner.

Improved in every way
Xilinx development boards are actually very good and it is a testament to the design of the Power-supplies that we managed to push the Bitcoin mining design to 200MH/s ,But why was the board consuming 47W when hashing hit 200MH/s?

The secondary issue was why the logic would not go faster than 200MH/s, even with improved FIFO & UART communication routines, try as we might I would not work, I had pushed the same FPGA to 250MHZ for another project, so it was unlikely to be clock related.

A new Beginning
It now seems that all these issues have now been solved after designing a completely new Power supply with improved layout (we also added two MASSIVE power planes which also act as a heat sink).

The FPGA design is now consuming 10W-15W per board and we have pushed the core to 370MH/s… yep a single core doing 370Mh/s….

So where is the power going?
0v95 Supply is sitting at about 6-7 Amps!!!
3v3 Supply is consuming about 1 amp, but that can be reduced since we have about 16 diagnostic LED’s strung off the IOAUX power line.
We may need to try and parallel up a couple of the 0v95 supplies in an attempt to cool the switching FETS down, we could just change the Capacitor/Inductor fet configuration, but that can be a real pain to get working efficiently, far easier to just parallel up a couple of supplies.

What is the point with ASICS being released soon?
Well:

Litecoin?
Yep in good old hacker style, we may have discovered a weakness in the Litecoin system that would allow us to mine without consuming massive amounts of ram.
We say ‘might’ because we have only looked at the system very superficially, but if we are correct then with a minor performance hit we could limit down the ram size.

We have recently re-gained control of this site, back from an admin-user.
This person was given the ability to post as the admin of the site.
A number of forums related to bit-coin (https://bitcointalk.org) have been linked here, these links will remain as will the research.

Unfortunately, the person involved is still causing mischief on some sites, mainly by reusing certain monikers and requiring payment for the release of them.
We attempted to re-route the ownership of the accounts via email, but failed.
The person in question has also been issued a cease and desist letter from our solicitors.

To make matters more complex these monikers have been in use for several years on other non bit-coin sites and since the SEO connected to these monikers has some value they have also been appearing in Eastern-Europe.

For the record, most of the technical analysis posted on various bit-coin forums (https://bitcointalk.org) is not under the ownership of the person using the moniker, but rather from a secondary source and then re-worded.
The plan was to build SEO links of ‘intelligent and useful material’ related to various aspects of bit-coin.

As regards the email address:
har***re@hardcoreforensics.com, this is now under control of a different admin.

Site owner.

As is the way, we were sidetracked into taking a look at getting WiFi working on the Samsung 2440 embedded control board, the idea being that we could have a backup system for when:
1.HongKong telecom manage to cut the telephone lines.
2.The shitty little HKT ADSL modem or its PSU burst into flames again, yep it only takes them 3 DAYS to get a replacement to you.
3.Dock with my mobile phone, since that has unlimited data rate, which means I can cut one ADSL & one router from the mix I am currently using.

Sadly getting WIFI working on an embedded board is not that easy, EVEN with linux

Tried downloading ‘compat-wireless-2012-12-17′, but unfortunately the integral bash scripts wont run under busy box on the embedded system.

Tried downloading Bash for the embedded system, but it won’t compile, instead giving a segmentation error.

Tried cross compiling the needed wireless libraries… fail……

It’s not that I cannot figure it out, but rather how much is my time worth to get WIFO working on what is basically a dead out of date underpowered board.

Solution

http://www.hardkernel.com/renewal_2011/products/prdt_info.php

For $89USD+$30USD shipping we can get an up-to-date Quad core samsung4412 at-least 4 times faster than a Pi and with enough memory to run a miner controller for a good many ASIC miner units and it comes with a functioning wireless installation of linux.

In a previous posting we outlined the use of a FIFO between the Bitcoin engine (SHA256(SHA256(x))) and the communication circuit.
There have been a number of discussions about the futility of this implementation, along with the posting of various quantities of ‘dubious’ facts used by a number of people to backup the claim of why a FIFO is an exercise in futility.(a little thought into the actual statements, shows a massive & glaring mistake, that shows the same level of ineptitude as the greek governments ability to understand their current situation)

One key fact in my usage of a FIFO was to separate the Clock circuits of the communication & generation logic, failure to perform this, results in the need to continually adjust the counters used in the UART to match the master clock, this in-turn prevents the UART being “black-boxed”, because the UART needs to be continually re-routed in the logic, each time the clock frequency is changed, this in turn causes continual problems with the routing resources producing “random” results.

To date the 220MH/s core with the integral FIFO has been performing admirably, so what we are now going to do , is replace the handwritten FIFO VHDL with an integral core that is hardware specific to the virtex5.
It turns out that those clever people over at Xilinx added extra circuitry to the RAMB32 infrastructure to handle FIFO implementation in the RAM logic, even more interestingly, the FIFO is capable of operating at up to 550Mhz.
Since we are not actually using all the integral ram inside the Virtex 5, it is about time we replaced our generic VHDL FIFO with this infrastructure. At the very least it is additional logic that will no longer need to be routed to the same extent as it currently is, the only down side is that the minimum sized FIFO we can implement is 512 levels deep….., rather than our current 16 levels in the generic FIFO.

Let’s dooooo it!!
We can simulate this modification to death, but that is really not going to give us any insight into the actual results once it is implemented in the logic.

The first task will be to implement a single clock FIFO to replace the generic implementation.

After that, we will implement a dual clocked version with dual port ram, this will allow us to separate the clocks for the nonce communication & generation circuits, and if that works then we might start looking at inserting a FIFO BETWEEN the SHA256 generators, again it might be possible to use this to ‘break up’ the logic and increase the speed at which the SHA256 calculations can be operated.

In our last article, we were of the mind that the YL2440 sucked so badly as a bit-coin miner control board, that it could easily outperform a Dyson Cleaner.

As is the way, things come to light that change our interpretation of the data.

It now turns out that the “boot-loader” developed by the Chinese company to pre-load the kernel, was not actually passing the available ram size(64Mb) to the Linux Kernel on boot up.
For whatever reason, the user configurable settings were not being passed in, as a result the kernel was launching with only 16Mb of ram….. The fact that Linux could even run a system including Python in less that 16Mb of ram ,really is a testament to the design of Linux.

Python sucks at the best of times, and limiting its available memory only makes it worse.

New Improved YL2440
After making some modifications to the Linux kernel and forcing a new command line on boot up,
we now have the full glorious 64Mb of ram, and boy what a difference it makes.
No longer do we need to wait 3 minutes for an SSh login, and even the web-front end of the python miner is more responsive.
Total ram consumed… is now sitting at 20Mb, most of which is being used as buffers.

Our next task is to try and get the Stratum Mining proxy working, since this will cutdown on the data bandwidth needed by the miner, plus there is a 2% fee reduction with Stratum Mining.

Once that is done, we will be re-visiting the issue of the RS232 ports and why they are unable to function at 230400 baud.

The Good News….
Well, we finally got a fully functional YL2440 up and running a python miner client.
The good news is that it has not crashed in the last 48 hours, AND we fixed that bloody stupid clock bug…

The bad news…..
Unfortunately the bad news is that it sucks ass.

1. Even though the YL2440 has THREE hardware UARTS , none appear to function with the miner at 230400 Baud
This is despite the bloody thing running fine IF I plug in a FTDI USB UART connector into the only available USB connection and use that for the python (even worse the data-sheet for the CPU states that “it is capable of running at upto 921kb), but looking into the linux kernel UART code, there is a comment from the programmer about the UART speed multiplication bits being wrong.(9 instead of the 44 shown in the data-sheet)

2. For some reason there is only 16Mb of ram available to the system, even though the system has 64Mb of ram onboard.(well that is if the shitty ’64mb’ ram chips are not China fakes, that have been re-branded)
or possibly it’s an error when I ported the linux kernel.
3. Being an embedded Board, it uses Nand-Flash as storage, unfortunately this does not bode well for the massive log files continually written by the Python miner, specifically it hammers the wear leveling of the Nand-Flash card.

So the likely-hood of this board ever working for more than one ASIC miner is starting to look rocky.

I’m going to take a look at the ram issue, because I know linux always performs better with more ram, and just maybe we can rescue this situation.

If we do indeed rescue this complete dogs bollock of a project, then for the networking I have a nice 12db Antenna + 1 watt amp for a wireless connection.
Why pay to run a router/ADSL connection when you can leach off all the open ‘noobie’ routers in your area?

*Handy tips:
1. Always download your porn using the local ‘open’ Church router.
2. Always use “WEP” as your router protocol.
3. If you are a dumb-ass Chinese company making copying other companies development boards, FFS DON’T Use a Hearing aid battery to support the RTC. use an INDUSTRY-STANDARD mother board battery.

Since I have been playing about with bitcoin mining for the last few weeks, it has given me the opportunity to look at some of the publicly available source code.

We decided to take a gander at the communication channels used to communicate the results back from the FPGA’s to the master computers.
On the whole the code is mostly abysmal…., seemingly written by people that have absolutely NO comprehension about how real hardware actually works… or in some cases even basic binary maths.

Take for example the Serial communication:
https://github.com/progranism/Open-Source-FPGA-Bitcoin-Miner/blob/master/projects/VHDL_Xilinx_Port/uart.vhd

Lots of fixed constants that cause the code to fall apart as soon as you try to increase the clock rate of the design.
Why? Because the counters and values in the design are dictated by the clock rate and as you increase the clock rate you need to increase the length of the counter chains in this code.

Hahar… you say..
I can vary the clock rate for the main design but then keep the clock rate for the UART at a fixed rate.

NOPE!!!!!!

Because of this low quality code in miner.vhd

hit <= '1' when outerhash(255 downto 224) = x"00000000" and step = "000000" else '0';


As the SHA256(SHA256(x)) code does its magic, a new hash result is calculated off the base nonce at the edge of EVERY clock cycle of the master clock.
Therefore any valid result has to be recovered in a SINGLE clock cycle of the master clock before the result is lost.
Now if the UART is running on another clock, it may very well miss the value that has been transferred to the TX logic, at the very least you would need to syncronise the clock edges.

So Unless we want to totally re-write the VHDL we are stuck with the UART code running on the master clock

The next problem
The actual UART code is written so badly that even if it were the ONLY core in the FPGA, it would max out if the master clock value was increased past 140Mhz

However with a SINGLE change, its maximum operating frequency can be taken up to about 294.898Mhz.
yep... that is correct, a SINGLE change to the VHDL code can more than DOUBLE the frequency that the UART can operate at. That is before we even start to take a serious look at the code construction.

To buffer or not to buffer that is the question
We now come to the issue of buffering(FIFO) the results of hash searches and nonce hits.
Since the generation of hashes is a continual process there is no guarantee about the quantity of collision hashes you get when checking the full range nonce from 0x00000000 to 0xffffffff.
Furthermore, there is no guarantee that two valid nonces will not appear within a few clock cycles of each other( Other than mounds of research that say changing a single bit radically changes the whole has value, but they don't take into account the fact that bit-coin is looking for a hash whose top-end is populated with zeros).
So, a question arises:
How can a UART core operating at a baud rate of 115,200 possibly service a nonce generator running at 120Mhz?

Well, only under the pretense of multiple nonces NOT turning up within the 'send' window used for notifying a successful nonce back to the master controller.

From this we can ascertain that there is probably a need for a FIFO to be inserted between the SHA256(SHA256(x)) engine and the UART (yes...yes.. I know some people think it is very rare for nonces to be close, but I'm afraid I have seen them regularly within 1ms of each other, plus that value only gets smaller as the SHA256(SHA256(x)) system speed increases)

So we implemented a FIFO
We had to provide our own FIFO code, because the shitty Xilinx core generation tool only allow a FIFO to have a minimum size of 512 places. (yep like 512 places * 64 bits is going to help with the routing issues we already have!!)
The results were actually quite interesting: There was a noticeable INCREASE in stability of the whole system, as well as an increase of successful nonces discovered.

0x1dc5323a
0x1e376d41
diff 0x723b07 (7486215D)

Above we can see two nonces detected and reported correctly within 32ms of each other, yep we can say that this is STILL well within the capability of the UART to report these without a FIFO, but the difference is that a NONCE can be detected at any time, even when the UART is currently sending data.

This code is difficult to test, almost impossible to simulate, because you need to be able to generate viable hashes that are very close together, and for that you need to know the base hash (x) PRIOR to the SHA256(SHA256(x)) that is going to produce the final results.
(if we knew that we could "mine" bit-coins without actually doing any work and we would be very rich).

Nevertheless even with these difficulties, we managed to capture the following:

Here we see two nonces within 1ms of each other namely:
0xc1f5cf25
0xc1d627ba
Diff 0x1fa76b(2074475d)
A quick subtraction of these two nonces, tell us that they are:
0x1fa76b apart (2074475) or 2074475 clock cycles....
Hang on a minute
2074475*5ns(at 2002MH/s) =10372375ns , which is 10.3ms but the timing above says they are 1ms apart.
and from this we can see our fifo Is actually saving data, because something 10.3ms apart is being compressed into 1ms apart(the FPGA was sending a nonce to the controlling system, but during the send a second nonce was discovered, preserved in the FIFO and then TAGGED onto the end of the send straight AFTER the first nonce).

If indeed the two nonces were generated closer together and not a potential interruption of the UART, then the subtracted result above would be SMALLER.
But the nonces would still be received by the controlling system within 1ms of each other(according to the python reporting, but that's what you get for using a gash interpreted programming language to code a front end to a hardware design).

And finally a "zero time nonce":

0x75c67f66
0x75e079f9
Diff 0x19fa93 (1702547D)

The Future
Now that we have a working FIFO we can FINALLY, split out the shitty UART code from the master CLK.
Why? Well now we can start to look at running the SHA256(SHA256(x)) at a higher CLK rate without having to worry about resources that will not route correctly due to them failing to meet the timing requirements.
This means the design has the chance to compile at a far higher operating frequency, looking at the design, over 70% of the timings are due to routing delays.

Cut the bullshit, anyone can say code is bad
OK, So how far have we improved the miner?:
The current STABLE speed (200MH/s) is almost double when compared to the Public domain code.

And this is without even trying to work on the routing or adding constraints to the xilinx files.

The Future
Interestingly a research project for NIST has already accomplished a working ASIC for SHA3.
If you read the paper very carefully it states "It contains all the SHA-3 five finalists".. SO WHAT!!
Then it goes on to state: "and a reference SHA256"
Catch the link here:
SHA256 in ASIC
and something far more interesting related to die sizes and processes
ASIC Die sizes

ZFS was supposed to be a super cool file system with basically unlimited storage and the potential to correct ANY sort of corruption within the ZFS file system. (seriously when you have >50TB of storage capability from most modern disk systems, HFS+ just does not cut it. )

Several attempts have been made to port the full ZFS file system to OSX,
Apple made a good attempt at it, until Sun went tits up and oracle purchased the assets.
Then there was ‘Ten’s complements’, who appeared to make a further attempt at bringing the ZFS system to OSX. but then the deadlines started to slip.
It now appears that ‘Ten’s complements’ attempts have ALSO gone tits up.

so here we are …. Round three.
GreenBytes, appears to be the new owners of the latest failed attempts for ZFS

http://www.getgreenbytes.com

They have released a “community version” of ZFS, but they appear to be of the mind that OSX is just not powerful enough to run ZFS:

“ZEVO is a current implementation of ZFS that has been adapted to integrate within the constraints of Apple’s Mac OS X runtime.”

http://www.getgreenbytes.com/zevo/

Greenbytes, seems to be of the opinion that OSX is just not capable of running the full ZFS stack, which is possibly why there is a community version, (let the REAL programmers of the world fix it up, do the leg work and then commercialize it LATER, by adding a spiffy GUI)

So lets all wait and see where this spiffy file system , ends up.