Topic: Klondike - 16 chip ASIC Open Source Board - Preliminary - page 116. (Read 435369 times)

Brief Status Update

I've done the I2C code now and everything is pretty close to code complete excepting a bootloader (for on-the-fly firmware upgrades). I'll be spending today doing testing of I2C master mode output signalling but it's not going to get further with just one PIC wired up.

Fortunately, later today I'm off to Bkk again to pick up K1 boards, scope and more parts that arrived. When I get back I should be able to assemble 3 K1 boards and test the chaining fully, and re-program one to act as fake ASIC for some loopback testing.

For those interested in this type of thing, right now the code size is 5602 and data 818 compiled with the PRO mode turned on. Max possible on this chip is 8K and 1K respectively so I think we're looking pretty good right now.

I've written up a Technical Reference document that I'll upload fairly soon. So far it has a brief hardware description and details the command protocol (for driver writing) but I hope to expand it later with a lot more design info.

Oh yeah, MPLAB-X, in my opinion, sucks.  I still use 8.8X.  MPLAB-X was such a resource hog and seemed quite unstable.  I have nearly zero issues with PICKIT3 and MPLAB 8.8X - Other than the occasional loss-of-mind that I mention above, they work great for $40 programmers.  Even the loss of mind is quite infrequent.

Enigma

Thanks. I'll try that. I've also discovered that using Programmer To Go mode is more reliable. Disconnect from my circuit, program as To Go mode, then connect and press button - works almost always, which seems to indicate it's not a problem with my circuit hookup but MPLAB-X software (since it goes off the deep end and can't recover).

I've got dozens of PICKIT3s, and they all do this once in a while.  The simple solution, almost every time, is to set MPLAB to a different chip family (PIC121840, for instance), then connect the pickit.  It will tell you that a new firmware must be downloaded to the PICKIT to work with that different chip family.  Say ok.  Then switch it back to your real chip.  Again, it will say it needs a new firmware.  Say ok again.  Should be functional.

Enigma

Thanks BKK, (as the tech lead in another project) definitely appreciate your openness!

I'll just confirm that any info I uncover from testing sample chips will be made freely available. And time permitting if specific tests are requested I'll try to provide answers for them as long as I don't think that chip damage could occur due to testing, or that it interferes with finishing my own tests.

If I had to reduce testing to a level where I was comfortable saying "ok this works", I'd say 2 chips per bank and there is 2 banks on a K16 board, ie. 4 chips. This allows testing the ASIC chain, the result wire-ORing, and nonce range splitting between banks. Having more chips would not help much with testing stacking or multiple K16 chaining as those functions are independent. It possibly could help with detecting timing issues in the code under heavier utilization.

The primary reason to have more test chips would be to test the K16 under heavy power use and heat dissipation and I think that's useful, of course, but will have to be approached according to how many samples I end up receiving. Sure, more would be better and allow more complete testing such that board users/assemblers/mfrs can be more sure that some use conditions won't have problems. If I can't test everything I'll try what I can and probably simulate what I cannot.

(I'll cross post this in the ASIC sample-news thread for completeness)

Cross-post in all threads of projects that are registered for Avalon sample chips from my order.

Delivery of sample chips seems to have started.

If you have chips ordered with me that you want to support this project with, do it now.

If you are the owner of this project, please provide me your shipping address.


Find the details here.

That micro USB is a power header, not a communications bus. If it were an actual communications port, the physical port size wouldn't matter, as it would be no big deal to make a cable for it. However, power headers are pretty worthless for anything other than supplying power.

And, as I said before, the flash size is too small anyway.

702N also has much less RAM/FLASH 2MB/8MB (or vice versa - half the 703N AFAIK) and is not supported by OpenWRT.

Ahh yes, it has only a micro usb. Thanks for your answer.

I think the 702n is missing the USB connector, which would make it useless for this application. It also has too small a flash size to run the openwrt firmware.

Still a decent little knock-around router for general purposes though.

Whats the difference between 702N and 703N? Can 702N flashed with OpenWRT and used for K16 mining? I have a dealer who sells 702N very cheap. Or should I order 703N?

Thanks.

Yes better keep to Avalon DIY by Bkkcoins. At this stage his focus is pretty much on Avalon DIY Chip, as you see they is a huge chip buy...hopefully sample is coming soon

Ya not Avalon chips... so why do we need to talk about that here. Send PM to people. Keep the thread clear of this stuff guys please.

Bitfury is it's own project and they are not avalon chips if the translator is not off it is a unique chip
The thread adano posted has a lot of spec info and details BKKCoin should evaluate it to reserve some chips
Pad diagram: https://mega.co.nz/#!SctDlaJY!TMVG_E6gOVI-MMky8BS0hTy_h-AqpBeVfgrKF_d0J7g
https://bitcointalksearch.org/topic/m.2408216
English
https://bitcointalksearch.org/topic/what-is-the-story-with-metabank-and-bitfury-miners-225695
Link on specifications
http://www.bitfury.org/bitfury110.html
Chip research
http://www.bitfury.org/xc6slx150.html
Russian
https://bitcointalksearch.org/topic/bitfury-asic-65nm-183368
Other info
https://bitcointalksearch.org/user/bitfury-58469
https://bitcointalksearch.org/topic/m.2198248

Edited compressed leaves only for reference to avoid it being re-spammed

Are they Avalon chips?

BkkCoins, I m sorry for distracting you, but did you see this?

https://bitcointalksearch.org/topic/ann-bitfury-is-looking-for-alpha-testers-of-first-chips-free-money-here-228677

Bitfury gives away his chips to testers. Are you in?

I kind of convinced myself the when both config signals go low that it resets the internals and gets ready to receive configuration and when both config signals go high that it would release the chip from config mode and start hashing.

Ya, it's vague and I wondered about that. Currently I do go idle between data sections but I don't have to. I made it explicit so if the idle causes it to reset, then I'll move it to the end. I put it after each section now as it makes it easy to see the sections on the LA.

Do you ever go idle during the 108 byte transfer? I was wondering if going idle on the config bus would result in the ASIC starting its search before all the config data is transferred. The documentation did not seem complete on this.