OK - sounds like we have a short-term opportunity (reduced selling fees) that makes this an even better possibility. So we are comparing selling a Jupiter (two workers in R6, total about 550-600GH/s) that is producing ~1 BTC every 2 days, for ~$20K. If $/BTC rises at approximately the Difficulty rise, it means that we would lose any income past the next 40 days, roughly. Correspondingly, we would capture (eliminate the uncertainty) effectively the next 40 days of income all at once.

Assuming this is a reasonably accurate description of the circumstances, I vote my 37 shares to sell.

Please, anyone, point out any misunderstandings or bad assumptions!

--DickMS

P.S. Does anyone know why the Saturn is offline?

Folks, in your paragraph 1.1, General protocol specifications, you write:

"The CoinCraft A1 uses two SPI ports, one used in slave mode as an input from the uC or
the previous A1 in the chain (pins IN_MOSI, IN_MISO, IN_SCLK, IN_CS) and one in
master mode to the next A1 in the chain (pins OUT_MOSI, OUT_MISO, OUT_SCLK,
OUT_CS), if any."

In your pin descriptions, you use completely different signal names.

http://i.imgur.com/IXQavZw.png
http://i.imgur.com/tRFsGLK.png

It seems reasonable to assume that the above mentioned slave port, meant to be connected to the MCU or a preceding A1 consists of:

Signal	Pin	Input to A1?
SCK_S	13	input
SDI_S	14	input
SDO_S	15	output
CS_I	16	input

and the above mentioned Master port, meant to drive subsequent A1s consists of:

Signal	Pin	Input to A1?
SCK_M	8	output
SDI_M	7	output
SDO_M	6	input
CS_O	4	output

and that SPI signal flow outbound from the MCU will travel from right to left when looking down on a board with "pin" 1 in the upper left corner.

Could you please verify that I have the layout correctly described, please?

In addition, could you please verify the polarity of the chip select signals? Chip select is only rarely active high, and my controller is wired for the usual active low chip selects...
I would prefer not to rework the prototype boards I am submitting due to my misunderstanding...

Thanks!
--DickMS

I am assuming that the two drawings, the first in Section 5.1 labelled "Pinout", and the second on succeeding page labelled "Bottom View" are reversed because the first is actually a top view, right?

More questions, for Zefir:

These chips will be guaranteed operational, and tested before shipping, right? We can't act as your packaged-article test because we risk having to do rework on non-functional chips. There are no sockets for these chips for us to do the testing to reduce our risk, so perhaps they are tested at the factory after packaging, and that testing is covered in the pricing? Are the chips binned for voltage/frequency of operation (that is, are you guaranteeing all chips we buy will operate in Turbo mode, and produce 40GH/s there?) Are all 32 engines guaranteed operational? You can see where this is going... a guarantee of more free chips to make up for failed ones is not sufficient to make up for the rework costs, and system customers won't pay premium prices for boards with a chip that only partially works when it arrives.... Just want to know what we can expect to get our hands on... untested random gambles, or properly in-package-tested chips?

Thanks guy!
DickMS

Z, the point of the ROI comments is to show that Bitminer has an unworkable pricing schedule, and to try to convince them that it is in their best interests to modify it. So, since they aren't looking in the speculation threads, and since Giorgio is deliberately ignoring that the advance and retreat of BTC to USD conversions does not affect our estimates at all, much less invalidate them, I thought that this was the place to change his mind... it didn't work. Oh, well.

His ignoring the numbers doesn't really affect the numbers: he prices his chips in BTC, regardless of the exchange rate. So, we can calculate the expected return for any given difficulty, in BTC, and compare it to the cost of the chips. The numbers say that for every BTC spent on a chip that is sold at 0.85BTC, and put into operation in January, it will return only about 0.3BTC over its entire lifetime - ignoring the cost of the boards, power supply, and power.
Edit: According to Mining Dashboard, assuming current difficulty increases continue without the rate increasing, the lifetime return for 1BTC is 0.33 BTC (0.6617 loss), regardless of whether you price the BTC at $100 or at $200. No shipping, no power, no boards, no case... only chip costs considered. Check for yourself.

Like I said - a very expensive hobby, and Bitminer is making things that can't be considered anything but toys for rich men.

I thank you heartily - you have been extremely polite in your responses, and I appreciate the civil discussion. Since I can't, evidently, be convincing, I won't push the point any further.

Bik, I wasn't complaining about zefir's prices - I am very grateful that he's selling small batches, and think that his prices are reasonable for that - nobody expects prototypes to make money. My point was simply that - given even optimistic assumptions about difficulty, and even considering Bitmine's CPP - there's no apparent way that anyone can make 0-ROI on anything made from chips that cost $5/GH in December. And, even if Bitmine drops the price to $3/GH in December, for the first batch, 0-ROI depends on them making their delivery dates nearly perfectly. Even a 1 week slip means loss of most of the revenue expected from the entire lifetime of the miner. 2 weeks late means that every dollar put into making a miner will only return $0.80 or less, over its entire lifetime. No-one can make a successful commercial product line at those prices which will be attractive to the well-financed professional miner - those people can and do run the numbers, and don't invest in anything that won't return a profit under any circumstances (unless they are running a money laundering business, where a negative ROI is normal). No big buys and no repeat business means no chip company, and a loss to their investors.

My guess is that the A1 batch will cost about $40/chip, with the exotic new package and some reasonable development & NRE amortization. That's a little over $1.5/GH, and even a $2.5/GH sales price, in December, first batch, would give them a good return on their investment while allowing their customers to shoulder some reasonable risk with reasonable rewards possible. These are conditions for big investments, and for return business. Selling boxes at $6-7/GH that will never pay off unless all the competitors stop delivering will only sell to hobbyists who don't care about ROI. There aren't that many of them, and they probably won't absorb 50,000 chips from the first batch. Certainly not enough to give Bitmine's investors a return for their development costs.

I love designing embedded systems, building them and programming them. I've been doing it as a professional since 1982, and have built systems that will never generate any money, just for fun, as well. Those were toys, and a hobby. Bitmine needs to price its chips at a point where well-funded professionals can make money for their risk, or it's just in the toy business. Just my prediction, based on nothing more than professional experience, with no insider information - no need to do anything but wait a few short months to see how accurate it is. I'd love to be proven wrong by Giorgio dropping the chip price from $5 to $3 for the December deliveries, and then to $2.5/GH for deliveries in January. Til then, others with more money to spend on their hobbies will have to take my place in the buyers' line.

Thanks, zefir - I was just trying to remind Giorgio that he said he was going to update the spec today... there are a lot of unanswered questions that impact any board design.... and if you expect orders only from DIY's who will assemble chips like that to boards themselves, I suspect you will have little call for chips - hot-air/infrared assembly is not for the inexperienced or the faint of heart, and at over $100/chip, the risk is quite high. I think I will take your advice, and put a hold on the order that I sent you earlier this morning. It's mostly wasted effort, after the buck controllers and microprocessor are laid down, until the real specs arrive. The window hasn't closed on getting boards fabbed and assembled (omitting A1's) by the time the chips turn up - I was going to HARW them onto two already assembled boards, so I've got some time yet...

Here's hoping Giorgio (or rather one of his engineering minions) gets some free time soon....

Thanks, but that's the one that's been out for a few days, and doesn't have much if any useful information in it (no electrical, no power pinouts, etc, etc). Giorgio & Zephir have both said that the spec will be put on github, and G said it would be updated today... that's what I was looking for.

BTW, zefir said the specs would be on github.... link please?

So, let me get this straight....

in return for bare chips, delivered the same time as the first fully operational hardware boxes, we are to pay 0.85BTC per chip (25GH). At $150/BTC, that's $127.50 per 25 GH, or $5.1/GH. No guarantee that all 32 engines are working on every chip purchased, at least so far as I can see. Mining dashboard says that difficulty would have to stay below an increase of 80% per month to reach 0-ROI, some time in APRIL, so the chip costs eat up the first 90 days income, even if power costs are ZERO.

At these prices, I think this is a very expensive hobby.

Kinda hard to see how anyone would make a successful business out of it, unless chip prices were dropped into the $3-4/GH range, and even then a 2 week slip in delivery destroys all the expected profit for the life of the product, and then some.

Ah, well - I've had more expensive hobbies, I suppose.

What's the usage of V_ref?
Could you verify that all SPI pins are signaling at 1.8V, please?
Which pin is supplying the 1.8V input?
Have you decided which rail is GND yet?
Edit-1: Or are both rails supplying the internal voltage, and the only GND is the central pad?
Edit-2: I hope both rails aren't V_internal, since that would force either a 4-layer board, or high inductance breaks in either the cooling GND plane or the V_internal plane. There is a reason that prior chips didn't use a plugged-tunnel approach to pinout...
P.S: a link to the github location of these specs would fulfill one of your previous promises....

Thanks!

Hey, DZ, all, - I want to buy 10 shares in R8, for $600... but how is the translation determined into BTC? Would it be acceptable to simply PP-gift the money to Thomas_s?

Thanks!
DickMS

My bad - the profusion of alternatives some times get jumbled... Of course, the same questions can be leveled at the Avalon, both old & new. Same data is missing, funny thing...

Thanks for the thoughts, even when I was way off topic.

--DickMS

Yep - I suspect that there is a well known (by the designer, not by the DIY community) method for selecting nonce initialization data, to prevent engine overlap, and hence lost utilization efficiency. I'd really like to understand those semantics - they have serious implications for chip-chaining lengths, polling times, and so forth, which could result in significant performance optimizations on systems that are "in-the-know", versus ours, where we just poke in the dark.

To be TRULY open source, all the magic sauce needs to be known publicly - companies like SCO, who sold OS based systems and concealed all the build instructions and parametrization necessary to get the systems working from the "open source" base they provided were bankrupted, eventually, by lawsuits. They used the fruits of others' development efforts, and conspired to ensure that no-one could use their derivative works to compete with them.

It can't take but a few sentences to describe how the internal semantics work, at least to the extent that we need for designs - answering these questions would be a good 5-minute break from heads-down development.... Take a break, Fury!

Please excuse the simplistic question, but does anyone know how the BitFury chip works? It apparently has about 700+ rolled-up double SHA256 engines, each of which must have a unique nonce to be useful. It seems (according to what I read in this forum and the supporting links) to claim that it can perform a complete pass through each of those engines in about 65 clocks, at several hundred MHz. On the other hand, someone has displayed a scope trace showing a load sequence, with Merkle data, pre-calc, and block data, along with about 110 uS of nonce initialization. Since the init sequence in total is over 300 uS long, and there are only a few nonces in it, I have two questions:

1. How does ~800 bits of nonce initialization data set up the 700 * 4 * 8 = more than 22,000 bits of nonce needed for all 700+ engines?

2. If, indeed, the engines run for about 65 clocks, at say 300MHz - which is about 1/5 of a microsecond - at which point they have used that nonce data, how is the chip getting more than a small fraction of 1% utilization: run for 0.2uS, init for 300uS, repeat as desired...

I am presuming that somewhere out there is a document that exposes what the chip internals do with the initialization nonce data, and what happens to the nonces once each round of 65 clocks has passed.

WHERE IS THAT INFORMATION?

Presumably, the initialization nonce data is expanded some way, by a factor of 22k/800 = 28 to get initial nonces for all 700 engines, then each round of 65 clocks results in those nonces being incremented or shifted, or something. With only a one-bit "I found one!" notice coming from the whole chip, decoding which nonce was the golden one becomes rather time consuming and depends upon knowing the number of 65 clock rounds since the startup...

So where is all this crucial information? I've searched and searched, and the best that I've found is to reverse engineer one or more of the miners, but there is a crucial step missing - I see what the program does, but I can't see how that data is manipulated before being shipped into the chip via that Manchester encoded serial pair.

Does anyone have a pointer to the real information? Has anyone analyzed the WU readouts of the demo'd miners to see if we are actually getting the number of results expected for the hash rate, and not just getting trillions of duplicated hashes on duplicated nonce streams?

Thanks for any help or pointers, folks.... making boards and firmware for this kind of a system should be a piece of cake for any experienced design team - I've run such teams for nearly 45 years, and we've done many more complex systems. But it's impossible if the chip semantics aren't available, unless you have a government lab at your disposal that can treat it as a black box and run dozens of probing tests at a time. They don't open-source the results.

and in answer to the question about merging, that I missed: Sure - put them all together under either name - that payout address is certainly the same...

Thanks, Bob!

Sigh - I used to work for American Totalisator - the folks who make the horse-racing track displays and betting-ticket selling systems. Their standard system at the time was a pair of racks, with 3 Varian minis in each, connected by a DRUM storage system!!! The first time I was shown into the "'tote-room", which is where the racks are installed, and where the odds are continuously calculated with each ticket purchase (parimutuel, dontcha know), I stood in the middle of the room, pointed at the racks, and said "Why does it take THAT much horsepower to sell bets?"... At that very moment, in both racks in perfect parallel, the minis stopped, consecutively, from top to bottom. Blink, blink, blink... blank. As the implications of a contractual $10,000 penalty for every hour in which a single minute of down-time occurred sank in, I was hustled out of the room. I am now (still, 30 some years later) banned from every tote-room in the US.... and they made up a sign for my desk: "Shorter and his trail of broken equipment..."

Edit: I'm just glad they didn't label me "Typhoid Dickie" or "Basilisk" or some such - I was 15 feet away from the racks at the time!

Edit#2: I PROMISE I WON'T VISIT THE CO-OP's CO-LO! EVER!

Sigh - my post was supposed to be light-hearted, too - I appreciated your joke, and surely no harm was imputed.... Just goes to show how skewed life gets when stress is high.

Good work, folks - y'all get kudos, and drinks of your choice when the hashing starts - on me!

Dick

Bob, remember the old Pennsylvania Dutch saying: "Annoying the cook will result in smaller portions!"
The same applies to the hosting engineer, I think.....

In truth, all of you are going beyond the pale to sort out this goat-press - our thanks for all your hard work!

DickMS

Hi aoshea!

I'd like to get one set each of ghost, scorp, tobacco, and lemon.... how do I go about it? What's the expected germination ratio? And, do you have any cultivation information on them (such as required-min outside temps, watering, sun-vs-shade, etc).

Thanks!
DickMS (Seattle)

Well, my non-contact laser thermometer says the hottest point in either blade is about 40 degrees C. That's the column of chips that is furthest from the 110 cfm fan, on the front board (no air channel in front of it, so the far end gets less flow). Both heatsinks register at 25-30 deg C (lower nearest the fan).

I guess I'll just be satisfied with the hashing reported by BitMinter. Sure seems pathetic to pay $500/board, and not have the firmware be even vaguely accurate. You'd think that the manufacturer would open source the firmware, if only to get more quality in his next round of boards, more quickly. I'd sure spend the time to buff up the firmware if they did!