BFL ASIC mining board project

[MrTeal]

Unfortunately the chip I have mounted is terrible, 8 engines pass the test cases. It's pretty apparent that the samples shipped appear to be the rejects that didn't pass QA for the BFL products. Those that do run do so pretty well, running at 330MHz ~2.64GH/s. Testing continues...

[-Redacted-]

That's pretty much in line with what Lucko discovered.  It seems the sample chips are likely those that didn't even make D grade and would have been discarded.

[MrTeal]

I'm curious too. Did you got engine 0 working. I'm pretty sure it is a hardware problem but still interested if I'm wrong...

Not yet. We might do some firmware fiddling to see if we can get it to work, but enabling E0 just causes it to spew errors.

[Lucko]

I'm curious too. Did you got engine 0 working. I'm pretty sure it is a hardware problem but still interested if I'm wrong...

Not yet. We might do some firmware fiddling to see if we can get it to work, but enabling E0 just causes it to spew errors.

Same hire... And I fell like doing search for God. There is no way you can prove that he doesn't exist. You can only prove where he can't be... But get it to work would mean that you get one free chip for every 15 chips... Not such a small gain...

But since BFL given up on it I would guess it is hardware error...

[Mobius]

I thought it was mentioned that engine 0 was not working on the first run of chips and it would be remedied in subsequent runs

[jborkl]

I have seen Conman mention that if engine 0 is enabled all the other engines do not work. That was awhile back, and maybe things have changed but I am sure he knows

[mmmerlin]

I thought it was mentioned that engine 0 was not working on the first run of chips and it would be remedied in subsequent runs

That is both interesting and plausible... I wonder how this fits in with the chip orders - has it been confirmed that they are being made in a separate run?

I think whether or not it is fixed depends on what layer the error is on. It is not unrealistic to expect that they would change the metallisation layer to enable the engine, as this gives a ~7% boost in speed, but there is no way they are going to have a full mask made up to fix the problem. Has anyone read anything about this? Is it known where the error lies?

[MrTeal]

Because some people wanted pictures.
Test setup

Running at 363MHz (11.36MHz * 64 for the PLL clock, with 2 divisor)

Putting out 2.9GH/s on 8 cores

[mufa23]

Very awesome! Keep up the work

[creativex]

Nice work MrTeal, congrats.

[pacojones]

This sounds very exciting!  I'll keep an eye on this thread too 

[mmmerlin]

Because some people wanted pictures.
Test setup

Running at 363MHz (11.36MHz * 64 for the PLL clock, with 2 divisor)

363MHz is incredible! Did ChipGeek manage to get similar clock speeds on his board with 14/15 engines running, or is this only possible because of the much lower TDP due to the low engine count?

[Lucko]

Putting out 2.9GH/s on 8 cores

Isn't that 2.4?

Because some people wanted pictures.
Test setup

Running at 363MHz (11.36MHz * 64 for the PLL clock, with 2 divisor)

363MHz is incredible! Did ChipGeek manage to get similar clock speeds on his board with 14/15 engines running, or is this only possible because of the much lower TDP due to the low engine count?

With less working engines you can get higher frequencies but even more engines will fail tests... So hi frequency is not necessarily good. We got it as hi as 428 but got less out then at lower frequency... You need to find a balance how many engines will work at how many HW errors and frequency...

[freedomno1]

Feel free to ask any questions, and I will keep everyone updated as milestones are retired and the project goes along.

Was wondering where in the milestone list the pictures above are and nice setup

Project Status
Done:
June 1st - BFL announces chip sales, basic design ideas begin
June 16th - Group buy initiated
June 22nd - Group buy order placed
July 3rd - Sample chips shipped
July 12th - Samples received, final PCB review
July 14th - Test PCB sent for manufacture
July 18th - Estimated PCB ship date
Upcoming Estimates:
Week of July 22th to 28th - Begin building and testing of PCBs
Week of July 29th to August 4th - Continue testing, incorporate results into the production version
Week of August 5th to 11th - Begin taking orders for PCB sales, send out a small quantity of production boards for manufacture, finalize assembly information
Week of August 12th to 18th - Receive and build production test boards. Test, and if necessary, modify and respin board
Week of August 19th and beyond - Prepare for production, further testing and rework if needed, extra lead time. Final PCBs produced. Components ordered and stocked.
Mid September - Chips arrive and head to assembly

[MrTeal]

Isn't that 2.4?

No, it's 2.9. The one showing 2.4GH/s bounces around all the time depending on when shares are discovered, but the average was 2.9GH/s.

[jborkl]

Incredible job, getting 3 GH out of a reject chip is better than I expected. imagine what you will get out of better grade.

[Lucko]

Isn't that 2.4?

No, it's 2.9. The one showing 2.4GH/s bounces around all the time depending on when shares are discovered, but the average was 2.9GH/s.

Unless you have a build of cgminer that has this turned it is the other way around first one is showing 5s average and second is average...

EDIT:
If that was the case I had 10GH jala(with our firmware)


But the pool say I don't. It has up and downs but it average on 8,5 to 8,6...

Still not bad since stock 1.2.5 got only 7.3 out... And modified got 7.8

So it should be 2.4 not 2.9

[MrTeal]

Unless you have a build of cgminer that has this turned it is the other way around first one is showing 5s average and second is average...
So it should be 2.4 not 2.9

Ah, you're right on the order, my mistake. If you'd really like I can take a video of it hashing on 8 cores at 2.9GH/s on Monday, this time making sure I zero the stats after fiddling with things. I'm not sure why you find it so hard to believe that it's producing 2.9GH/s though considering the cores aren't giving hardware errors and that is the expected hashrate for that clock speed and number of engines.

[Lucko]

I have no problem believe that. I'm just saying I don't see that... I know you get 1MH per core for every 1MHz... So yes it should be 2904MH

But I must say your CGminer is realy strange. Data on top and at device should be about the same for only one device... Unless you pluged it in at later date and mined before that. But since you have same number of accepted shares this is not the case...

[sr_miner]

Because some people wanted pictures.
Test setup
http://i40.tinypic.com/2n6t3lg.jpg
Running at 363MHz (11.36MHz * 64 for the PLL clock, with 2 divisor)
http://i44.tinypic.com/20qnkg3.jpg
Putting out 2.9GH/s on 8 cores
http://i42.tinypic.com/2884j06.png

Awesome!
Congrats MrTeal...