My early LX150 miner prototypes had a 60A switcher for vccint for 8 chips -> 7.5A each... and that later turned out to be not enough.
So, how come the German guy (Stefan) of ZTEX gets by with a [very compact] 8 Amp converter for VCCINT? His dynamic clocking now achieves > 200 MH/s on a -3 device. Impressive. (Even more impressive considering the fact that he has less than half of the Xilinx-mandated amount of bypass capacitors surrounding the Spartan-6.) Btw, one thing that made me go WTF when looking at interior pics of copacobana a few years ago... a single massive AC->1.2V converter for vccint and really heavy cables + busbars to route it around...
Here's a picture: http://www.copacobana.org/photos/photo_b4.jpg |
|
|
|
are these from a SUN Sunfire based on ultraSPARC processors? I know SUN sold converters at one time...
No, its a power supply for HP/Compaq blade servers. Usually two such PSUs per rack, and three blade enclosures per PSU (six total). Check out http://vicorpower.com/cms/home/product-selector?productCategory_filter=DC-DC%20Converters. Vicor DC/DC converters go up to 750W, and you could use multiple ones. I have tons of Vicor AC/DC power supplies with 12V output and plan to use them for mining purposes later this year. |
|
|
|
Now as far as the KC705 boards, I am guessing that they will be about the same price as the ML605s, around $2000. Now, you have to watch out because the first runs of the boards are going to be ES parts (there can be bugs).
At work, we have actually already built boards (not for bitcoin of course!) using ES K7 325T devices. I haven't found any huge speed advantages over the V6 devices, so would not expect any huge frequency increases. However, the device that's going on the KC705 board is going to be larger than the ML605 (240 vs 325?), so you'll have more room for your design. However, the amount of DSP48s is about the same.
The KC705 board is now available (well, at least advertised on the Xilinx webpage) and costs $1700. It sports an XC7K325T, which has about twice the resources (logic cells, slices, flip-flops) of the Spartan6-150. I would guess that one can put two complete miners in there, and probably run them at 300 MHz instead of 200 MHz. In other words my best guess is that the mining performance of this board might be around 600 MH/s, give or take. Which doesn't seem to be cost-effective, needless to say. |
|
|
|
hi, guys. the holiday is finally over. i'm going to have some meeting with my supplier and factory, and place some order for the 3rd batch. it's sure there will be some BOM changes to increase power efficiency, enhanced cooling, and so on. so later 2-3 days i will very busy. PM and email reply will much slower. please forgive me. confirm an accurate manufacture plan is the most important thing to do now. regards everyone.  I thought the Chinese New Year holiday is 15 days long ?!?! Wikipedia seems to say so: http://en.wikipedia.org/wiki/Chinese_new_yearSo, if day 1 was Jan. 23rd, day 9 is Jan 31st, day 10 is Feb 1st and day 15 is Feb. 6th <confused> |
|
|
|
You're probably trying to open the PDF link with "Save Link as". That won't work on gitHub because it sends an html page (probably 25k size). You need to open the PDF page and use the "Save Link as" option on the "View Raw File" link they provide.
That link will save the actual pdf file.
Yes, you are correct. Got it now. [bangs head against wall] |
|
|
|
Also the DE4 dev board at 3k US$ seems to be (much) cheaper than the individual chip, from what I can tell. What's up with that?  As far as the discrepancy between actual chip cost and dev board cost, I'm not sure, I noticed that myself on Digikey. No idea. You find that a lot: For instance, Xilinx now has a Kintex-7 eval board for $1700, with a (device-locked) copy of the design software thrown in, but when you look up the price of the Kindex-7-325 that is on the eval board, it is well above 2 grand. Thus, I'm not surprised. |
|
|
|
Lets not confuse unrolling with pipelining. Current open-source designs are fully-unrolled, but I have yet to see a proper pipelined design that is open-sourced. Maybe pipelining is what BFL did? By pipelining the unrolled design they could significantly crank up the clock, since the FPGAs are limited more by the propagation delay in the signal routing than in the propagation delay in the actual logic.
My understanding is that the lack of pipelining is due to the lack of registers in an FPGA, is this correct or not? A Spartan6-LX150 has 184000 flipflops, and for a double SHA-256 only 32768 flip-flops are needed. 128 stages x 256 width = 32768. Fits easily if you have 184000 at your disposal. Thus, I find it very hard to believe that current designs are not pipelined. Also, a typical design such as the ZTEX design achieves 200 MH/s with 200 MHz. Assuming it is not a fully pipelined design, that would mean that all 128 (or 125) stages have to percolate through in a mere 5 ns, because 5 ns is the clock period of 200 MHz. 40 ps (picoseconds) per stage? I don't think so. |
|
|
|
2 weeks after that. ADD: sorry guys. i just found a serious mistake in the code. it result in unstable. i will fix this issue in 1 week. Hi, I was trying to look at your PDF schematic, but Adobe reader says it's damaged or incomplete. Can you please double-check that? Thanks! it's ok here, how about change to another version of pdf reader? I can assure you, my Adobe Acrobat 10.1.2 is fine - and I tried this on multiple computers. When downloaded from github, the file Icarus_V1.pdf has a length of only 25474 bytes, not enough for a schematic. Can you attach it to a PM? Is that possible? Or upload it somewhere else? |
|
|
|
lulz - OK I need to repeat the question ... But firstly, I know the sha256 code very well - otherwise I wouldn't have mentioned P() ... here's a fully unrolled, optimised as high as possibly needed for gcc's -O2, C sha256 that I generated myself quite a while back ... and yes it works. It is generated and optimised by code I wrote to produce that entire file. You cannot actually optimise it any better in C and gain anything but an extremely minor performance increase when you use -O2 with gcc on this. http://pastebin.com/sxdVSJF1Also as I said, 122, not 128 (or 178) coz: the 1st 64 is constant over a nonce range (commonly the midstate), you don't need to do the first 3 of the 2nd 64 inside the loop (also in the midstate) nor the last 3 ever of the 3rd 64 with bitcoin My question is how do FPGA's work internally (if that youtube video really does answer this, oh well, but I've yet to see anything useful on youtube in my life that couldn't be replaced by a TINY web page of text so I ignore youtube links) As I asked before, do they execute in a manner like dominoes where the clock process advances data through the FPGA in steps? My googling on the subject suggests this is correct - but I was curious if anyone here knew that much about the internal workings of FPGA and could confirm or otherwise explain that. Also, that would mean that inside the FPGA there would be something like the discrete steps to hash a nonce range and thus I was wondering if they do really actually hash multiple nonce at the same time each one 1 or 2 discrete steps behind the previous nonce. Thus if the clock steps data through at X cycles per second, and the process is 1300 steps (a random number of my choosing), you aren't just waiting 1300 cycles for each nonce calculation, you are actually waiting (assuming each nonce is 2 steps apart) 2 cycles for each nonce result but with a startup time of 1300 cycles before the first nonce result comes out. Yes, current FPGA designs are fully pipelined, as long as they *fit* into the FPGA, and thus you get a hash rate of 200 MH/s at a clock frequency of 200 MHz. And it's not 1300 cycles, but literally 122 (or 128 or something like that). |
|
|
|
2 weeks after that. ADD: sorry guys. i just found a serious mistake in the code. it result in unstable. i will fix this issue in 1 week. Hi, I was trying to look at your PDF schematic, but Adobe reader says it's damaged or incomplete. Can you please double-check that? Thanks! |
|
|
|
I'm happy to report that the "15d3a" version works for me now - it starts at 200 MHz, goes to 204, then 208, then 212, but the error rate is too high at 212 and it settles at 208. Good job, Stefan! 1.0e3 thanks! |
|
|
|
A testing release of BTCMiner has been published: http://www.ztex.de/btcminer/ZtexBTCMiner-120130.jar . The bitstream is a bit faster again and should achieve 210 MH/s on average. The package contains 3 firmwares for LX150 FPGA Boards: | firmware file | frequncy step | note | | ztex_ufm1_15d1.ihx | 8 Mhz | stable | | ztex_ufm1_15d3.ihx | 6 Mhz | experimental | | ztex_ufm1_15d3a.ihx | 4 Mhz | experimental |
(In order to avoid conflicts with old bitstreams the new 4/6 MHz firmware has been named ...d3) I am happy to report that the 15d3a bitstream works for me now. I didn't try the 15d3 bitstream. The 15d3a starts at 200 MHz, then goes up to 204, then 208, then 212 (error rate > 1%), then back to 208 (error rate < 0.1%), seems to stay at 208 now. Cool! Thanks! Note that this is NOT with the Xilence cooler, but with a 12 mm high VGA cooler from China via eBay for $2.79 (including shipping). Yes, it does have a fan. It gets warmer than the Xilince cooler, but I can still touch it and leave my fingers on it without feeling pain. Like a warm coffee mug. |
|
|
|
So my guess is, that they use EP3SL200 or 260.
It is definitely possible to put 3 fully unrolled pipelines into the 260
(at 150MH/s each) and, with some tuning, gain the advertised speed. One question. Do you think it is possible for anyone with the experience necessary to design a custom FGPA board to get the power draw so wrong like BFL claims they did. Yes, in fact that's an easy mistake to make. Case in point: The CEO (and probably sole proprietor) of ZTEX did. Before the 1.15x module, with its 8 Amp core voltage supply, came the 1.15d module, and the originally recommended supply for it http://www.ztex.de/usb-fpga-1/pwr-1.0.e.html only sported a 3 Amp core voltage supply! He found out the hard way that all these unrolled loops of SHA-2 cause something like 50% of all flip-flops on the FPGA to switch simultaneously, and thus blowing even the most conservative power estimations out of the water. Now he has discontinued the power supply module 1.0 and is instead offering the power supply module 1.1 http://www.ztex.de/usb-fpga-1/pwr-1.1.e.html with an 8 Amp core voltage supply, i.e. the same number of Amps that module 1.15x has. Q.E.D. |
|
|
|
Could it somehow be that they're using the pcb as an interconnect and using the 2 fpgas as one? So they only need to implement 1/2 the sha circuitry on each?
Unlikely because a single hash is trivially easy. Splitting work between two "nodes" only makes sense if one node can't handle it in a timely manner. It is never more efficient there is always intra-node overhead. So building dependent parallel solutions is something you do when you have no choice. A supercomputer for example can never be built with a single petaflop chip. Thus you have no choice but to accept the overhead and build it with a 1000 terraflop chips. If a single petaflop chip existed you would just use that because it would be more efficient. Well from what I understand the issue is that the intra-chip routing takes away a lot of the fpga circiutry away from what could be used to hash. So if you could somehow use the PCB to route, you would kind of have a ghetto sASIC with 2 logic units (the fpgas) and the interconnect (pcb). Also, if the cross-chip communication (through the pcb) were pipelined there should be no overhead of the across-chip communication, correct? yes and no. Yes, it's a compelling idea. FPGA prices rise super- linear, i.e. an FPGA with twice the gates typically costs more than twice the dollar amount. No, it's not a practical idea because SHA-256 means 256 bits wide, so you need to route 256 signals from FPGA 1 to FPGA 2. While this is possible, think 10-layer PCB. Think $$$. |
|
|
|
I just looked at the screen output, the number on the far right side. And yes, I did wait a minute or two to see whether I get a non-zero hash rate.
This is the "submitted hash rate". Never, ever, ever use this value for performance evaluation if you run the board only for a few minutes. Use the frequency or the "hash rate" in the center of the line. (Maybe I should put the actual "hash rate" to the end of the line and the "submitted hash rate" into the center. This will save al lot of support time ;-) ) What I noticed is, the software kept switching frequencies like crazy, in 6 MHz increments, whereas the old software switched in 8 MHz increments and only very rarely.
It switches more often at start-up but will stabilize after a while. No, this new version really doesn't work. It tries and tries, gradually reducing the PLL frequency down to 126 MHz, that's when I gave up. I have sent you a log by email. |
|
|
|
I think that might be it. It runs stable with the d1 firmware so I am sticking with that for now. Here is a part of the log showing that it clocks up and down, sometimes really low. It runs stable at 192Mhz with the d1 and sometimes it will run stable with the d2 as well, but it inconsistent. I will trim the entry once you have seen it.
Seen it. I'll send you a new firmware for testing next week. If it cant be fixed I'll switch back to d1. BTW, with d1 your boards should achieve 200 MHz, with d2 198 MHz or 204 Mhz. I'm assuming that in the December firmware, the PLL denominator, which divides the 48 MHz input clock (from the Cypress microcontroller) is 6, and thus the numerator is multiplied by 8 MHz, leading to frequency adjustments of granularity 8 MHz, whereas in the January firmware, the PLL denominator is 8, and thus the numerator is multiplied by 6 MHz, leading to frequency adjustments of granularity 6 MHz. Correct? |
|
|
|
I know that, but I am thinking out on a limb. Perhaps they want to become the next Altera  Which is why I would like to know whether a purpose-built FPGA could be faster for encryption operations than a "general-purpose" FPGA. I don't think you understand. FPGA are horribly horribly inefficient compared to ASICs. The reason for FPGA is because ASICs have such a huge upfront cost that despite FPGA being utterly lackluster they provide "good enough" performance (per $ and per Watt) compared to an ASIC. So if you want the best performance nothing beats an ASIC but say you only want 10,000 or 1,000 chips. That multi-million dollar costs is no prohibitive. FPGA give you flexibility of making the chip do anything you want but that flexibility comes at a steep price in terms of cost (in $ and Watts). A single purpose FPGA is an oxymoron. It would be like making a hybrid vehicle which is gas inefficient. Nothing else comes even close to the performance: An 45nm ASIC SHA-256 processor would be in the ballpark of $0.20 per MH and 50 MH/w. (probably better if there was demand for 100K units per year). Even keeping die size reasonable you could get 4 or 5 GH/s per chip. Someday when AMD/Intel move on to smaller processes you could roughly double (slightly less) those specs by taking advantage of excess 32nm fab capacity. Of course the multi-millions of dollar in capital, huge risk, and limited market means we likely won't see an SHA-256 ASIC any time soon. Based on BFLs own statement "The BitForce processor card is a proprietary implementation of both FPGA and ASIC technology", I'm almost certain what they use is what Altera calls "HardCopy" and what Xilinx calls "EasyPath", namely a FPGA design converted into an ASIC. Such a conversion costs "only" about 300 grand or so and pays for itself once you sell, say, 5,000 ASICs (which, in BFL's case, translates to a mere 2,500 boxes, and, assuming an average of 2.5 boxes purchased per customer, into a mere 1,000 customers). (Disclaimer: I have pre-ordered four singles at this point, so maybe LESS than 1,000 individual customers suffice to make this profitable.) Altera/Xilinx tend to give their HardCopy/EasyPath customers optimistic projections on the power consumption and maximum clock rate, which a HardCopy/EasyPath customer (BFL in this case) tends to believe (after all, it's Altera/Xilinx saying this) and pass on to their retail customers. Which is exactly what happened! It's a fairly common mistake to make and not a big deal. Some people went all ape-shit over this here, but underestimating the power draw and overestimating the maximum clock rate is really a fairly common mistake. Thus, based on the pictures that seem to show an Altera device, its quite safe to assume that what we have here is an Altera HardCopy implementation of an Altera FPGA. |
|
|
|
Don't forget the new firmware: -f ztex_ufm1_15d2.ihx
The Java software detects which firmware it is targeted at, and will complain if you try to run it against the wrong (== too old or too new) firmware. |
|
|
|
Did you evaluate the "submitted has rate" or "has rate"?
If you find no shares within the fist few minutes the "submitted hash rate" is zero because you submitted nothing.
The actual hash rate is the frequency minus errors, because the FPGA calculates on hash per clock. In the new version this value is called "hash rate" and can be found ind the logs/output between "maxErroRate" and "submitted <n> new nonces".
I just looked at the screen output, the number on the far right side. And yes, I did wait a minute or two to see whether I get a non-zero hash rate. What I noticed is, the software kept switching frequencies like crazy, in 6 MHz increments, whereas the old software switched in 8 MHz increments and only very rarely. |
|
|
|
I tried it this morning, pointing it at deepbit.net (just like I was doing with the December 2011 version).
Result: 0.0 MH/s
After a few minutes of getting 0.0 MH/s, I reflashed the "old" (December 2011) firmware and was back to my usual 199 MH/s again.
Any ideas?
Send me the logs / output. Will do, but right now I'm at work, so by the time I can send them, it'll be [early] Saturday morning in Germany. I'm mining in a small office I rent in Silicon Valley, mostly with HD 5830 cards. (Yes, it gets "toasty" in there...) |
|
|
|
|
Show Posts
