Update: bring-up-howto fixes, real target processing

Fix in reference test-vector
totalslacker, 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:

Code:

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 target

Quote from: totalslacker on February 18, 2014, 04:00:56 AM

Is 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:

Code:

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