...
If you still don't get any feedback from the chip, please double check that the RSTn is kept at 18V for at least 1s before your first command to the chip.
...
I think you mean 1.8V ! Sure 1.8V. But from the datasheet it states that signal is active low. So it must be kept for 1s 0V. Or do you mean that after it goes 0V for 1s it must be kept at 1.8V for another 1s before first command? Reset is low active, you need to drive it low for at least 1s, then drive it to 1V8 and keep it stable there. Give the chip 1s before you send the first command, see the pseudo code snippet you referred to here: https://bitcointalk.org/index.php?topic=294235.msg5205169#msg5205169One other question here: are there known PLL settings for faster speeds?
I tried manually running through your set_pll_config code for this but the result didn't come out so well (I might very well have done this incorrectly). I wasn't quite sure what the extents of the various fields are as the data sheet looks to be different to your code (and to the various PLL settings posted).
Assuming you have a 12MHz ref clock, try this: - set pll_postdiv and pll_prediv to 2
- set fbdiv to (target_sys_freq / 3), i.e. you can set your sys_clock in increments of 3MHz, with fbdiv being 9 bit you can go to 1.5+GHz
reg[0] = 0x84 | (fbdiv >> 8)
reg[1] = fbdiv & 0xff
|
|
|
|
Having some trouble with getting 0x04 responce on the 0x04 reset command.
I'm doing the HW reset as described. The signals from raspi passed through level shifters.
Chip select DI CLK are ok. I see 0x04 passing into the chip but there is nothing at the output.
The VDDcore is 0.7 volts. Maybe it is too low?
That's pretty likely too low. I had similar issues when I was running the chip that low. 0.8V seems to be pretty reliable for at least basic comms for most chips. A couple wouldn't hash at that voltage but once I brought it up to about 0.84V they were fine. Of course, now those chips run hotter than the others  This. The sample chips need 850mV min, not sure if the chips from the production batch are better suitable for down-volting - but obviously everybody is looking to up-volt them anyway Before going faster I need to get some cooling in there though. I noticed on your bring up page you mention keeping the temps below 50C. Is this a hard limit?
I was just doing a longer test where I kept all four chips completely busy with your test vector and verified that the correct nonces came out. Running at 240Mhz a couple of the chips did get a little hot. The two running at 0.8V stayed well below 50C but the two at 0.84V got up to about 61C.
No errors during the 12 minutes I ran the test. Theoretical hash rate is 32 * 240Mhz = 7.68GH/s and actual turned out to be 7.62GH/s.
But, how bad is it to run the chips that hot? Is that a might get bad results now and then or a might damage chips?
No, it is not a hard limit but given to us by chip manufacturer during bring-up to exclude temperature as root-cause for troubles. And the 50°C were for heat-sink, so there should be some margin left. If you reach the hot area, you'll notice invalid results first. What I noticed is a fail-safe behaviour (not sure if intended): if chip gets way too hot, it eventually will reset itself and stop working. With that, you corrupt the chain (that chip won't respond until after next HW-reset and re-enumeration), but it survives potential burnouts. Wish I had such a burnout protection built-in I have just tested with 0.84V. Still no responce.
zefir mentioned earlier that at the startup chip is configured at 12MHz reference clock. And the SPI speed must not be > system clock. I wounder what is the PLL multiplier at the startup to calculate the system clock.
Or maybe it doesn't matter what SPI speed to use for initialization? I guess what i wrote above is applied to SPI speed between the chips not between uC and 1st chip.
Currently when i run cgminer i see 500khz SPI speed. Is that sufficient?
The reset value for PLL multiplier is 800/12, i.e. with 12MHz ref clock chip is clocked at nominal 800MHz. As long as you do not hash, you do not need to modify the PLL register at all, even without proper cooling. The default SPI divider is 64, so you should measure 12.5MHz inter-SPI clock. Your host clock needs to be below that, which with 500kHz it is. If you still don't get any feedback from the chip, please double check that the RSTn is kept at 1V8 for at least 1s before your first command to the chip. Oh, and maybe to state the obvious: if you have a chip chain and you write a broadcast command, you need to send zeros to push the command to the last chip and back. See how the polling in the reference driver ensures to write enough data to get the commands through the chain. |
|
|
|
Interestingly, I get six nonces? The four you post, the one I assume that was overwritten and an extra. Same results for all four chips (haven't tried the second board).
That's ok. The reference job was taken from a nightly session where I collected the share log of a BE blade miner and picked up a work item with a high number of winning nonces. It does not necessarily mean the blade found all of them, so if you happen to verify the 6th result as valid, I will add to the related post. Thanks for feedback and good luck (you're almost there  ) |
|
|
|
Update: bring-up-howto fixes, real target processing Fix in reference test-vectortotalslacker, burnin and all who tried to test the chip with the test vector I gave some pages ago: I had a copy-paste error there with the first byte (8c instead of 8d). Can't explain how that happened, but fixed it in that post. Really sorry about that, I hope you did not lost to much time with that but instead tried to feed the chip from cgminer directly. So for reference, this is the exact SPI trace for the job processed by the A1: spi mode: 1
bits per word: 8
max speed: 800 kHz
--
TX: 58 bytes:17 01 8D 1F A3 18 D8 0A 25 2C E4 B7 CD 6D 12 2F 80 8F 17 DC D8 10 04 17 EA 3F E8 F3 71 41 70 F3
4B 49 D6 98 8E 01 27 1F 66 52 B6 0A 10 19 00 00 00 00 FF FF 00 1D FF FF FF FF
RX: 58 bytes:00 00 17 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Processing command 0x0a01
TX: 2 bytes:0A 01
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:1A 01
Cmd 0x1a ACK'd
TX: 6 bytes:00 00 00 00 00 00
RX: 6 bytes:46 C8 21 85 01 20
Processing command 0x0a01
TX: 2 bytes:0A 01
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:1A 01
Cmd 0x1a ACK'd
TX: 6 bytes:00 00 00 00 00 00
RX: 6 bytes:46 C8 21 84 01 20
Processing command 0x0800
TX: 2 bytes:08 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:18 01
Got nonce for job_id 1
TX: 4 bytes:00 00 00 00
RX: 4 bytes:18 8D B1 99
Nonce: 4 bytes:18 8D B1 99
Golden**************************: 4 bytes:18 8D B1 99
Processing command 0x0800
TX: 2 bytes:08 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:18 01
Got nonce for job_id 1
TX: 4 bytes:00 00 00 00
RX: 4 bytes:3F 8F 64 DE
Nonce: 4 bytes:3F 8F 64 DE
Golden**************************: 4 bytes:3F 8F 64 DE
Processing command 0x0800
TX: 2 bytes:08 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:18 01
Got nonce for job_id 1
TX: 4 bytes:00 00 00 00
RX: 4 bytes:B9 9C C7 09
Nonce: 4 bytes:B9 9C C7 09
Golden**************************: 4 bytes:B9 9C C7 09
Processing command 0x0800
TX: 2 bytes:08 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:18 01
Got nonce for job_id 1
TX: 4 bytes:00 00 00 00
RX: 4 bytes:EC C1 4E 74
Nonce: 4 bytes:EC C1 4E 74
Golden**************************: 4 bytes:EC C1 4E 74
Processing command 0x0800
TX: 2 bytes:08 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:00 00
TX: 2 bytes:00 00
RX: 2 bytes:08 00
Output queue empty
What is happening here is: 1) feed the A1 with the given job 2) loop over register read until chip is jobless 3) read out found results You will notice that you get back 4 results, although the job has 5 winning nonces. That is because the A1 has an output queue of 4 elements, so one of the results is overwritten. To get them all, you need to pull the results early enough while chip is still hashing. Have a look at the reference driver to check how to do this continuously. Result validity / real targetIs this correct? Should the final hash be below the target (the "false positive" comment is unclear to me). Guess I need to learn more about cgminer What you get back from the chip is a valid Diff1 share, while your pool is obviously asking for higher difficulty shares. That's absolutely normal, i.e. you will see this trace log with every HW that produces Diff1 shares. cgminer then drops all those below pool's difficulty. Having Diff1 shares returned is a good feedback for you to know that chip is still alive and kicking. But once you know it works stable, the communication load to the A1 chain can be reduced by providing the real difficulty. I have already implemented this in the driver variant for the CoinCraft and will get it into cgminer upstream, but until I have the time here is the related source code snippet: uint32_t get_diff(double diff)
{
uint32_t n_bits;
int shift = 29;
double f = (double) 0x0000ffff / diff;
while (f < (double) 0x00008000) {
shift--;
f *= 256.0;
}
while (f >= (double) 0x00800000) {
shift++;
f /= 256.0;
}
n_bits = (int) f + (shift << 24);
return n_bits;
}
static uint8_t *create_job(uint8_t chip_id, uint8_t job_id, struct work *work)
{
static uint8_t job[WRITE_JOB_LENGTH] = {
/* command */
0x00, 0x00,
/* midstate */
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
/* wdata */
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
/* start nonce */
0x00, 0x00, 0x00, 0x00,
/* difficulty 1 */
0xff, 0xff, 0x00, 0x1d,
/* end nonce */
0xff, 0xff, 0xff, 0xff,
};
uint8_t *midstate = work->midstate;
uint8_t *wdata = work->data + 64;
uint32_t *p1 = (uint32_t *) &job[34];
uint32_t *p2 = (uint32_t *) wdata;
job[0] = (job_id << 4) | A1_WRITE_JOB;
job[1] = chip_id;
swab256(job + 2, midstate);
p1[0] = bswap_32(p2[0]);
p1[1] = bswap_32(p2[1]);
p1[2] = bswap_32(p2[2]);
p1[4] = get_diff(work->sdiff);
return job;
}
That's maybe not the easiest way (I'm pretty sure that value is available from cgminer structs somewhere), but for now it works. Good Luck, zefir
|
|
|
|
Thanks for fast reply.
I have implemented low level access to the GPIO pins. Will try tomorrow.
Before you do, just a reminder (otherwise you'll kill the chips): you're aware that all pins are 1V8 - if you are using RPi's 3V3 GPIO you need to have level-shifters in place. Seems that there is a mistake in schematics. Check the gerbers to be 100% sure. Yes, I received several more bugs via PM, which either means this is not the latest revision - or the HW guys tweaked the board after assembly. Unfortunately the eval board was done by external resources, so it will take time to get fixes back into the repository. I'd assume the community will be faster with that. General comment for the eval board: I have been asked for permission to rebuild the board and sell it. A related license file was added to the git repository today that explicitly allows for that. But please note: this eval board was developed exactly for that - evaluate the chip and bring it up. Design guidelines re signal integrity, efficiency, thermal, etc. were not taken into account as you would do for a final product. Therefore, please consider the design only as reference but not for field deployment. |
|
|
|
I would like to ask about HW reset signal for raspi. In my version of cgminer is see the following: #ifdef NOTYET
a1_nreset_low();
cgsleep_ms(1000);
a1_nreset_hi();
cgsleep_ms(1000);
#endif
So it is not implemented yet. Maybe it is implemented in a newer version of cgminer? Another question. Can the lack of HW reset at the beginning be responsible for chip not to reply on the 0x04 (RESET) command? It is not implemented because it is HW dependent. You need to have your means of driving RSTn low and 1V8 high. This can't be done generic, since some design will have a level-shifted GPIO, others an i2c driven GPIO port expander, whatever. Every design will need to have its own HW reset routine implemented in the driver. As for your second question: yes, it was stated from the beginning and multiple times: you need to always start with a HW reset before you try to access the chain. That is not only for startup, but also for regaining access if chip chain got corrupt (which happens with unstable power or SPI communication failures). |
|
|
|
I pulled it from git and compiled it on the RPi yesterday with no issues. I'm not sure why you'd receive that error.
This source code is only RPi work? I try to activate Windows 7. Oh sorry, I thought it was obvious. Already wrote it several times it is designated for Linux and works only if you have an SPI interface in your system. How do you plan to access it from Windows? If you are using some USB->SPI bridge, check some posts above: drinkmorecoffee and others work toward such approaches that will allow to decouple the driver from the OS. In the driver I provided there is already an initial abstraction from the SPI interface: just write your own spi-context module that wraps direct access to SPI over that bridge (cgminer has already support for MCP2210). I could help with that once I am done with the SW for Bitmine, but I'm sure it will be already done by then. |
|
|
|
Also I believe that bitmine DID ramp up their production NOW - but they didn´t do so in the last months it seems.
Where do you know this? What if I tell you I saw 2000 PCBs that were prepared to ramp up production as soon chips arrive kicked in the trash-bin after testing showed the DCDC was not powerful enough? GeorgeM is absolutely right.
Might be, but after I replied in a polite and civilized manner he put all his anger at me for no reason. That is not the way I discuss. At the time when bitmine offered the first CoinCraft batch they should have known very well why almost all other mining hw manufacturer had massive delays (except KNC that is). Also they themselves had experienced the huge Avalon betrayal or fuck-up (Asic chip delivery) at that time - and should have known how to minimize such delays in the future and to plan accordingly.
Building a hardware company is a shitload of work; I think everyone is aware of that.
But to step on the plate and offer these products and emphasize as well as promise the special reliability of Swiss work ethics and blah blah is one thing - but then not even be able to communicate to their customers is as bad or worse than BFL, Avalon and the likes.
That is exactly the point. Why do you highlight KnC as the only successful company delivering (almost) as promised? I tell you why: they were the only one where the PCB was designed by the same company that did the chip. They knew exactly what to do to get the chip hashing as soon as put on the board. Everybody else had to go over (numerous) prototype revisions to learn the chip and adapt the HW - this is what is happening here. HashFast are no idiots, CoinTerra are not, and Bitmine engineers are neither. Also, look at my DIY thread: I supplied 20 projects with chips for weeks now (among them the usual suspects: burnin, c-scape/intron, WASP, marto74) and only marto74 has demonstrated a working product so far - for a simple reason: he had a board for Avalon rev2 chips with verified DCDC block where he more or less replaced those chips with A1. No other project has provided a working design so far. See, it can not be that easy then. Communications is a hugely important part of every successful company and transparency is a huge part of that.
We had exactly ZERO transparency as to what was happening!
This transparency does not come for free. It needs someone to collect the information and present it - which can only be done by Giorgio right now who has to take care on a ton of other things. This does not mean I am not agreeing with you that transparency is bad so far. But we need to find a good balance between people asking for raltime updates on hourly basis and current practice of 'it is done when it is done' announcements. I see the issue and I am willing to improve it. My idea would be to have something like a) weekly status updates b) immediate announcement if previously stated deadlines can not be met Is this something we could start with? Giorgio this lying pos doesn´t even have the balls to tell the community what the hell is happening with the CoinCraft Rigs for example. Like a small child he is just ignoring the fact that customers (who paid for the most expensive products!) have a right to get informed because it influences their further investment decisions.
Please try to somehow control your anger. It is not helpful to get personal and insulting. |
|
|
|
|
Announcement: Clarification on my personal Involvement with Bitmine
Dear DIY folks and miners,
as written in the OP, with the chips I ordered and distributed here, I have been Bitmine's largest customer from the beginning. With my ongoing work as consultant for SW and support during bring-up phase, I must have made at least something right: I have been offered a substantial stake of the company's shares and with that since this week I am also a board member.
How does this change the DIY chip distribution?
Definitively only for the better. Running this proxy service for the community already turned out to be error prone and impractical for higher demands. With manual processing, I already messed several orders up (delaying them or sending twice). The first action implemented for that was to make sample chips available from Bitmine's online shop.
Now that the first wave of DIY volumes was delivered, I expect not much further demands for 50+ volumes - those with working design will sure go for 500+ chip orders. To keep the door always open for late comers, I will pursue the integration of smaller order quantities in the online shop.
From this position I have a better influence on Bitmine's day business, so if there is something that can be improved for the DIY scene (I know there is), please let me know, either by posting here publicly or via PM.
Thank you all for the trust and support so far,
zefir
|
|
|
|
Somebody already got chips on hand from BITMINE CoinCraft? For the second month brain stem with supply ASIC.
Sorry for my english.
Of course chips were delivered. There are more that 20 projects supplied with chips - read this thread for some confirmations. |
|
|
|
Since Bitmine AG doesn't provide us with useful information, I started collecting them by myself. Can you say anything about the information-policy of Bitmine AG?
Beeing shareholder isn't the same thing as beeing on the board of directors, which makes you liable if the company if fuck** up.
Do you want to say anyithing about the chines contractor? Fud?
Thanks for your reply.
Well, information-policy you say? It is obviously sub-optimal. If you are from Switzerland, you maybe should go and visit their offices in Ticino. You'll find hard working engineers who can't do their real job because their mobile is ringing every 20 seconds. You'll find that business is not always going as planned (actually: it never does) and folks are doing their best to meet their obligations towards customers. Believe me, those guys are very unhappy about the delays - I have them on Skype every night when I remotely work on fixing things and be sure none of us slept more than 4h a night over the past 2 months. In light of that, all this talk about Bitmine having already working rig and self-mining is plain stupid. Even without the slightest idea on economical or mining context, it should be obvious that finalizing and selling products is the most profitable way to re-cover the enormous NRE costs that were spent. We made the first fully populated CoinCraft Desk working some days ago and mass production is ramping up just now. There are some users in this thread you can not convince by facts, but this is how things currently are. To your other points: There is no fuck**up happening in Bitmine. Things went differently than planned, but the company will keep their ToS products were sold after. That is, soon first buyers are entitled to request for refunds which will be granted. The more patient ones will get the CPP as agreed - we all have vital interests to make those rightfully angry and impatient buyers long term customers. CPP will cost a lot and eventually eat up all potential profits, therefore my personal fuck**up will be to lose all I invested so far. As for the Chinese contractor: define FUD. At the beginning, there was someone from Asia who wanted to invest in Bitmine but finally did not. That's basically why there were shares left to offer to me. I think swissmining questions your independence and bias towards bitmine. I don't think he doubts your workethic and efforts.
Until now I too had the impression you were some kind of independent consultant, but now it starts to look completely different.
Since you are on their payroll now, we can't expect you to say ANYTHING critical about them. That's a problem.
Seriously: check my post history. I never posted anything else than facts - nothing negative, nothing positive. How would that change the situation in any way? For those waiting for their miners it is irrelevant. Above that, I am engineer with zero PR or convincing capabilities. If you doubt my objectivity now as shareholder, why didn't you do when I was a paid consultant? In both cases I would not badmouth the feeding hand, obviously. So you invested in Bitmine SA? Or why do you hold a board position?
Because they think I am a nice guy who should be in the board? Because I put ~5k BTC into Bitmine? Because I work like a horse and delivered good results? I don't know, but that's how it is. Hope I helped you to resolve some concerns. Now going back to finalize the CCD firmware and work on the rig variant. Sorry if I should not respond in realtime, but for sure you understand that there are more important things to do for now. |
|
|
|
Look at the Bottom, Kurtisi Zefir, Member of Bitmine AG? Is this the Zefir Guy in the forum talking about the chips, promoting them, doing group buys?
Yes, it's definitively the Zefir guy who posts in this forum. Look at the e-mail in his profile. It's quite interesting to look at the FB-Profiles of people involved in Bitmine AG to see the faces behind this componay. Doesn't really increase my trustworthiness /edit in this company, lol Why don't you ask instead of flooding this thread with speculation / conspiracy? Yes, of course I am the one who is listed in the document - how many other zefirs you know in the bitcoin community who happen to work for Bitmine over the last few months? I already posted in this thread to work as a consultant for the SW side and am Bitmine's largest customer. And after the fact that I ripped off my butt working on the chips bring-up, Bitmine decided that I am valuable enough for the company to offer me company shares. That's where we are now and that is nothing worth speculating. Also, I am not doing group-buys or other suspicious things here - contrary I supply over 20 DIY projects (like marto74, WASP, etc.) with chips I bought and paid before to support building up a solid open-source scene around the A1 chip and keep mining rig available for the small scale miners. Feel free to ask if you need to know more, there is really nothing secret in here. zefir |
|
|
|
OK, so got boards back this week and initial checks all look good! Have reliable SPI comms with all four chips and power looks to be nice and stable (for at least low frequency operation, need to add cooling before pushing them). Zefir, your bring up instructions were very helpful - thank you! I was having trouble getting the chip to accept a job and then I finally realized I wasn't reading your instructions properly (had skipped a section). Fixed that and the chips are hashing But, I'm not getting the same result as you test vector at https://bitcointalk.org/index.php?topic=294235.msg4454746#msg4454746The registers all look to be good. I can submit the first and second job. The appropriate job active bits are set and the correct job id is set. But, I only get one nonce: 47 b8 a6 62 I get this same single nonce on both jobs and the two chips I've tried. I've looked over the test vector and compared it to my code as well as capturing the SPI bus on a SPI analyzer and it all looks correct… Might anyone have some suggestions on what I'm missing? Thanks! So I realized that the midstate and wdata might be in the improper byte order so I swapped them using the create_job function from zerfir's driver as a reference. No joy though as now I'm not getting any nonce solutions. It was interesting though that the first chip initially was taking a very long time to run the two jobs - as in a good 30 seconds (at 90Mhz PLL). Chips 2 and 4 ran it in a few seconds as expected (chip 3 in my chain doesn't seem to be functional - SPI communications look to be good until I send it a job at which point it stops responding). I powered the system down for a while then tried again, chip 1 was back to running at normal. So that's a tad concerning (the PLL had successfully locked in the first test where it was slow and the SPI clock was at the correct frequency for 90Mhz operation). Maybe some hash engines weren't functional (even though it reported all 32 as good)? Any pointers on my incorrect nonce results would be greatly appreciated! Thanks! Hm, this to me looks like a power issue - at least the effects you observe are similar to what we had here until we got the DCDC stabilized. First of all, try to not go below 200 MHz sysclock, since I am not sure if the PLL settings are correct for low values or how low it can really get. Operating the chip at 200MHz even without cooling is no problem. Then ensure the supply voltage is above 0.85V and ripple is within valid tolerance. Same goes for reference 1V8, reset and SPI signals. If you got access to the register, I guess you did that correctly. You can try to stress-test the inter-chip SPI by continuously reading the register of each chip over a longer period to ensure there are no issues. Usually, the serious troubles begin when you supply the chips with work and they start to hash. The power draw immediately spikes for order of magnitudes and if DCDC is not capable to handle that, the voltage ripple eventually will exceed the tolerance. The chip then usually resets itself, and with that you usually lose access to it, since the chip becomes unaware that it is part of a chain. To regain access to it, you need to HW reset the whole chain and re-enumerate the chips again. A strong indication that the chip was reset after it started hashing is the inability to read out its register, i.e. you e.g. write 0x0a02 to get register of chip 2, and you read back 0x0a02 instead of 0x1a02, meaning there is no chip 2 in the chain any more. We detected problems in the DCDC by scoping the levels long term and triggering for levels outside the tolerance range. As for your other issue with the endianess of the job command: the provided driver uses 8bit transfers and the create_job() function prepares the data for byte-wise operation. If you are not using 16bit and did not modify the source code, please post a trace of the related SPI transfer and I will double check with my logs. |
|
|
|
which is in line with the expectations based on physics (consumption proportional to (clock^2 * voltage)).
..that should be clock * voltage˛ Thanks P. for the correction, fixed that in the post. I did not notice since I used similar increase factors for both parameters, resulting in same results with correct and wrong formula. |
|
|
|
Gratz on 1GH/W. I was wondering how you did it until I realized it's 12x A1 chips per board. 210GH/12 = 17.5Gh per chip @ 1GH/W. For the guys asking about overclock 35GH per chip has been reached by Technobit Hex8A1, but you need 4500rpm fans and huge heatsinks. Potentially 12x 35GH x 5 = 2100GH but it would have to outside the case. Correct math, but wrong assumptions. What has been shown on the video is a fully populated CoinCraft Desk, which has 5 boards with 8 chips each running at 800MHz and reaching 25GHps. That's exactly the 1THps you can see. The updated Rig board were added 2 chips to be able to provide the nominal hashrate with under-clocked chips. With that, the chips can run below 700MHz, resulting in controllable system temperatures As for the over-clockabilities in general: with extreme cooling I pushed the chip to 1.15GHz / 36.8GHps (47%+). For that, the voltage needs to be raised from 0.85 to 1.1V, resulting in the degradation of power efficiency of 0.7J/GH to over 2J/GH - which is in line with the expectations based on physics (consumption proportional to (clock * voltage^2)). Bottom line: while chips are over-clockable as advertised, do not expect to reach the full potential with the CoinCraft products. For one, getting 50% more hashrate requires 3x more power - which the PSU is not dimensioned for; consequently for the other you can not get 3x more heat out of a closed box unless you submerge it or live close to the poles. For those who ordered the CoinCraft rig with extreme overclocking in mind, I frankly tell you to better expect max 20% above nominal speed. You might top that if you modify cooling and power yourself, but then Bitmine's turnkey products that plug-and-mine are maybe not the right choice for you. |
|
|
|
If I see it correctly they already had eleven chips on the "old" board, so it would be "only" one more chip on the new board compared to the old one. But most probably they meant two more chips compared to their initial design where, as I would assume, they might have planned with ten chips "only". Based on these pics, I really look forward to the outcome of the Rig System and ist final Performance. Nope, the picture quality is not good enough to see at once, but the 11th chip on the old board was the STM32 controller which was moved to the center of the new PCB. |
|
|
|
Update: 2-Chip Evaluation Board Reference Design published by Bitmine I have been approached numerous times from designers asking for a A1 reference design. Today, Bitmine added their 2-chip eval board design to their GitHub repository. We used this board for initial verification - it runs with the provided cgminer driver as is over RPi's SPI interface.
|
|
|
|
In the A1_scanwork function I see the following code: hexdump("A1 RX", a1->spi_rx, 8);
if ((a1->spi_rx[5] & 0x02) != 0x02) {
work_updated = true;
struct work *work = wq_dequeue(&a1->active_wq);
assert(work != NULL);
I assume this is checking a "work done" flag in the register, however I don't see this bit defined in the data sheet? Actually, while I'm here it also seems that the driver code is setting the PLL values differently than in the data sheet. The code sets pre_div to be the first two bits in the register data whereas the data sheet defines it as being bits 44:40. Is the data sheet wrong or am I just reading this incorrectly? Both I must have started developing the driver based on an initial version of the specs and did not modify naming to the updated ones. Will be fixed in the driver I'll provide for upstream integration. As for the 'work done' flag: this is something I found out tracking the register (already described somewhere in this thread) and which is currently being worked on to get integrated into the data sheet update by Bitmine. They are currently in the final steps of ramping up production, so please be patient for that. Will the A1 driver you've written in your github be ported back to the main cgminer development?
This was already addressed in this thread somewhere. Generally: yes I plan to push it upstream and also remain maintainer of that driver. Since that involves quite some initial and ongoing efforts, I need to be sure that it is useful for other projects. Right now, all projects I know do not communicate directly to the A1 but use FW to wrap control over the chip chain from some uC. At the same time, it turned out that for driving Bitmine's products it was required to add lots of HW specific code (like for programmable potis, i2c multiplexers, voltage regulators, temp sensors), so that I doubt the specialized drivers will be usable for anyone beside Bitmine. Here my approach is to wait and see other direct SPI based designs and modularize the driver in a generic part (basically what is already out + some cleanups and updates) and derivate code. |
|
|
|
No need to speculate about that. What we use when testing locally in the Bitmine labs is a meanwell 3kW PSU - the wall of PSUs in the picture posted is exactly that. The RSP-3000-12 delivers only 2400W. Bitmine say on their web site: Power consumption: from 300W (400 GH/s, power save) to 3000W (2.8 TH/s, turbo mode) on a standard 110-230 V, 50/60 HZ AC power supply (included).I assume the unit they plan to ship at sometime this year does not mine at 2.8 TH/s with the included power supply then? Or they expect the power supply to deliver more than the rated power (continuously). Have been visiting Bitmine for more testing and explicitly asked about that one: the rig uses 24V input, with that, the RSP-3000-24 delivers 3kW continuously. |
|
|
|
Hi Zefir,
Can I order 50 chips from you? any chips still available?
Thanks
Jbcheng
Yes, please follow the order process described in the OP. |
|
|
|
|
Show Posts
