Bitcoin Forum
June 16, 2019, 10:04:30 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 [34] 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 ... 182 »
  Print  
Author Topic: Klondike - 16 chip ASIC Open Source Board - Preliminary  (Read 434691 times)
TomKeddie
Full Member
***
Offline Offline

Activity: 176
Merit: 100


View Profile
May 16, 2013, 07:15:57 PM
Last edit: May 16, 2013, 07:45:04 PM by TomKeddie
 #661

Finally got a chance to look at the avalon schematics.  Seems like he is using differential signalling for all the data, this guy is smart. My homebuilt FPGA rig still struggles with async noise even at 9600 baud...

*edit*

Ok not differential, can't think of the name of the encoding just now.

I wonder if it might be worth simulating an Avalon in an FPGA and wiring it to our PCB as an end-to-end test.  I don't understand SHA256 well enough to grok the significance of the pre-calculation they are doing, I do have some experience working with the open source HDL code though.
1560679470
Hero Member
*
Offline Offline

Posts: 1560679470

View Profile Personal Message (Offline)

Ignore
1560679470
Reply with quote  #2

1560679470
Report to moderator

0% MINING FEES FOR THE NEXT MONTH. GET PAID IN BTC, ETH, XMR or RVN.

www.cudominer.com Learn More
Easily run CudoOS from a USB flash drive.
Designed for rigs. Manage your mining remotely from Cudo Console.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
sensei
Full Member
***
Offline Offline

Activity: 378
Merit: 100



View Profile
May 16, 2013, 08:49:17 PM
 #662

argh last week i ordered a reflow oven from usa and now delivering is delayed because of german customs.  Angry

Knecke,

Weren't you looking into heatsinks or was that someone else?
hashblue
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
May 16, 2013, 09:01:39 PM
 #663

So, I've read thru the comm. specs and we're golden. All looks like it will work ok, and is pretty darn close to expectations.

I'd optimized out one RES line and will have to put it back in as the data is encoded across both lines. ...

It looks like there is a absolute timing dependency between the DATA_P and DATA_N signals, are you sure that you will be able to interpret the data correctly with the PIC controller? Is there are way in a PIC controller to get a timing relationship between two captured serial streams?
Knecke
Full Member
***
Offline Offline

Activity: 152
Merit: 100



View Profile
May 16, 2013, 09:05:56 PM
 #664

argh last week i ordered a reflow oven from usa and now delivering is delayed because of german customs.  Angry

Knecke,

Weren't you looking into heatsinks or was that someone else?

yes but feedback is very weak and under 1000 heatsinks i dont have to start ordering and manufacturing. sry.

i will make the amount that i need for myself, most people said there are cheaper heatsinks from taiwan if so its ok,
but manufacturing time and shipping time are important too.
TomKeddie
Full Member
***
Offline Offline

Activity: 176
Merit: 100


View Profile
May 16, 2013, 09:43:53 PM
 #665

It looks like there is a absolute timing dependency between the DATA_P and DATA_N signals, are you sure that you will be able to interpret the data correctly with the PIC controller? Is there are way in a PIC controller to get a timing relationship between two captured serial streams?

Right and there is result pair per ASIC, that's a lot of data for a micro analyse in real time.  Perhaps a CPLD in front of the PIC would be smart?
steamboat
Hero Member
*****
Offline Offline

Activity: 648
Merit: 500


View Profile
May 16, 2013, 10:24:37 PM
 #666

Even one chip would be super useful. More would be cool. 8 would be awesome as that's a full bank. And 16 would be super awesome as that's a full board. So keep me in mind when samples start popping up. You'll get them back eventually, if you want, unless I blow one up or do something retarded.


I have that in mind from day 1!
I will try to find something for you in advance before samples come out:)
When arer you going to need them Yesterday?

No jocks when do you think you will get to the point that lack of chips will stop the development?


Calm down dude.  Grin You tell me to calm down? Relax take a breath... still plenty of people out there could have chips. Probably steamboat will come through.

BkkCoins is scheduled to receive sample chips from batch one.

ASIC miners available for purchase

Those who serve best, profit most.
SebastianJu
Legendary
*
Offline Offline

Activity: 2394
Merit: 1035


Legendary Escrow Service - Tip Jar in Profile


View Profile WWW
May 16, 2013, 10:42:12 PM
 #667

argh last week i ordered a reflow oven from usa and now delivering is delayed because of german customs.  Angry

Knecke,

Weren't you looking into heatsinks or was that someone else?

yes but feedback is very weak and under 1000 heatsinks i dont have to start ordering and manufacturing. sry.

i will make the amount that i need for myself, most people said there are cheaper heatsinks from taiwan if so its ok,
but manufacturing time and shipping time are important too.

I never heard of your offer. Are you located in thailand too? It would be best probably to have it all running through bkkcoins so that in case someone wants to buy the heatsinks with the set he can get it. I know i would most probably buy it to save the hassle of searching heatsinks and so on. At least if its not too overpriced.
But why do they need to be created? Arent there matching ones? And are you experienced in this? I could imagine something about airflow and heat dissipation has to be known to create one.

The most preferred option for me would be to buy the boards fully assembled with all needed stickers and heatsink to get importet into EU. So that i only have to add the ASIC's myself.
Second best option would be to buy the whole set, including heatsink and stencil. This option i would go when assembly in thailand wont work or the CE-Sign works too long.

Please ALWAYS contact me through bitcointalk pm before sending someone coins.
TomKeddie
Full Member
***
Offline Offline

Activity: 176
Merit: 100


View Profile
May 16, 2013, 11:12:51 PM
 #668

The most preferred option for me would be to buy the boards fully assembled with all needed stickers and heatsink to get importet into EU. So that i only have to add the ASIC's myself.

I think you would struggle to solder the asics with the heatsinks installed, the solder won't melt.
mike2kt
Member
**
Offline Offline

Activity: 80
Merit: 10


View Profile
May 16, 2013, 11:23:39 PM
 #669

It looks like there is a absolute timing dependency between the DATA_P and DATA_N signals, are you sure that you will be able to interpret the data correctly with the PIC controller? Is there are way in a PIC controller to get a timing relationship between two captured serial streams?

Right and there is result pair per ASIC, that's a lot of data for a micro analyse in real time.  Perhaps a CPLD in front of the PIC would be smart?




Looking at the protocol specification...DATA_P and DATA_N don't have to be 100% synchronous. The protocol indicates a transition period of *at least* 125ns (250ns respectively).
 
SEND0 State
P = 300ns HIGH
N = 150ns LOW
N = 125ns HIGH
 
SEND1 State
N=260ns LOW
P=130ns LOW
P=125ns HIGH

Should all be valid.

 
Going over the amount slightly does not violate the defined protocol in the PDF (real world may not be the same, ha).
 
Back of the envelope math (please correct me...long day)
 
Assuming 100% efficiency, that's 4,000K SPS (symbols per second). The only deterrent going over the 125ns/250ns signal speed is a reduction in bandwidth.

Looking from the response side...

REPORT_P and REPORT_N traffic is nothing. Sampling these at double the transition rate or 62ns is required.


If the PIC is running at 48MHz or 32MHz, we are still talking an order of magnitude+ faster than the ASICs SPS.
 

My educated guess is that Avalon's use of an FPGA has to do with features like direct Ethernet pool connection capabilities, web user interface, etc...
allten
Sr. Member
****
Offline Offline

Activity: 450
Merit: 250


You Don't Bitcoin 'till You Mint Coin


View Profile WWW
May 17, 2013, 12:02:13 AM
 #670

It looks like there is a absolute timing dependency between the DATA_P and DATA_N signals, are you sure that you will be able to interpret the data correctly with the PIC controller? Is there are way in a PIC controller to get a timing relationship between two captured serial streams?

Right and there is result pair per ASIC, that's a lot of data for a micro analyse in real time.  Perhaps a CPLD in front of the PIC would be smart?




Looking at the protocol specification...DATA_P and DATA_N don't have to be 100% synchronous. The protocol indicates a transition period of *at least* 125ns (250ns respectively).
 
SEND0 State
P = 300ns HIGH
N = 150ns LOW
N = 125ns HIGH
 
SEND1 State
N=260ns LOW
P=130ns LOW
P=125ns HIGH

Should all be valid.

 
Going over the amount slightly does not violate the defined protocol in the PDF (real world may not be the same, ha).
 
Back of the envelope math (please correct me...long day)
 
Assuming 100% efficiency, that's 4,000K SPS (symbols per second). The only deterrent going over the 125ns/250ns signal speed is a reduction in bandwidth.

Looking from the response side...

REPORT_P and REPORT_N traffic is nothing. Sampling these at double the transition rate or 62ns is required.


If the PIC is running at 48MHz or 32MHz, we are still talking an order of magnitude+ faster than the ASICs SPS.
 

My educated guess is that Avalon's use of an FPGA has to do with features like direct Ethernet pool connection capabilities, web user interface, etc...

The design challenge is sampling the REPROT_P/N with the PIC. You need to be able to execute 2 instructions on the PIC16 architecture (one for sampling and the other for storing).
This will take a total of: 2 instructions * 4 Clock Cycles / 48MHz = 167 nS.

I think the CPLD is a good idea for the KLONDIKE; I even found some for a dollar; however, for the single Avalon mining device, "The Avalon Quarter Stick", it isn't a pretty solution.
I'm going to try to use the Programmable logic on this controller to smooth out the signal some:
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en552961
We can use the SR latch to merge the two signals into one and double the amount of time for sampling.
The results: 167nS sampling rate for a 250nS+ signal.

Do you think this is possible? If not, CPLD looks like the best solution.


loshia
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


View Profile
May 17, 2013, 08:11:15 AM
 #671

BKK,

Please comment allten post about I/O timing.
10X

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
May 17, 2013, 09:19:01 AM
 #672

BKK,

Please comment allten post about I/O timing.
10X
This did look tricky at first and a software only solution would be difficult or impossible. I went to bed last night thinking about how to make this work. Woke up this morning with the answer.

I'm using a single NOR gate on the REPORT_N / _P outputs. This combines the two data signals to extract a separate CLK. I use the EUSART on the PIC in Synchronous Slave Mode. This accepts stateless data RX, CLK as input and shifts in data at high speed. I take REPORT_N as data (either will do) and the combined CLK. The UART has a 2 char FIFO and interrupt, so the instruction cycle isn't a constraint any more. Oh, and I've added a small capacitor to delay the clock edge slightly because the NOR gate doesn't have much delay. This should make data sampling reliable.

I already had the UART pins routed to the ASIC but was expecting asynchronous data. So had to change plans on that.

Total cost for solution is 0.12 gate, 0.015 cap = $0.135.

I've already discussed this with allten and we also discussed being able to remove the oscillator and use the internal oscillator in the PIC. This saves about $1 cost but will depend on whether the ASIC can live with the jitter as the PIC PLL is not as good as an oscillator. I don't know how sensitive the ASIC PLL will be, but I'll leave the oscillator pads on board so that either method can be used.

 What does 10X mean?

loshia
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


View Profile
May 17, 2013, 09:26:22 AM
 #673

BKK,

Please comment allten post about I/O timing.
10X
This did look tricky at first and a software only solution would be difficult or impossible. I went to bed last night thinking about how to make this work. Woke up this morning with the answer.

I'm using a single NOR gate on the REPORT_N / _P outputs. This combines the two data signals to extract a separate CLK. I use the EUSART on the PIC in Synchronous Slave Mode. This accepts stateless data RX, CLK as input and shifts in data at high speed. I take REPORT_N as data (either will do) and the combined CLK. The UART has a 2 char FIFO and interrupt, so the instruction cycle isn't a constraint any more. Oh, and I've added a small capacitor to delay the clock edge slightly because the NOR gate doesn't have much delay. This should make data sampling reliable.

I already had the UART pins routed to the ASIC but was expecting asynchronous data. So had to change plans on that.

So total cost for solution is 0.12 gate, 0.015 cap = $0.135.

I've already discussed this with allten and we also discussed being able to remove the oscillator and use the internal oscillator in the PIC. This saves about $1 cost but will depend on whether the ASIC can live with the jitter as the PIC PLL is not as good as an oscillator. I don't know how sensitive the ASIC PLL will be, but I'll leave the oscillator pads on board so that either method can be used.

 
You are a star!
My suggestion is to live oscillator  if possible. 1 USD is not deal breaker at all. If i understand it right oscillator  will work better compared to  internal PIC oscillator, right? It might be a stupid question as long as i am not hw expert but  having both oscillator + NOR Gate will not do any harm to design. If yes please leave external oscillator.
10X

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
May 17, 2013, 09:48:35 AM
 #674

You are a star!
My suggestion is to live oscillator  if possible. 1 USD is not deal breaker at all. If i understand it right oscillator  will work better compared to  internal PIC oscillator, right? It might be a stupid question as long as i am not hw expert but  having both oscillator + NOR Gate will not do any harm to design. If yes please leave external oscillator.
10X
No, the NOR gate and the oscillator are unrelated. Just both design changes made today. The spot for the oscillator will still be there but during testing I will be able to test without it by shorting two pads, bypassing it. Doing this and seeing how stable the ASIC is will tell me if it can be removed entirely. Typically at these clock speeds the jitter isn't an issue but since the ASIC multiplies the clock to get up to 300 MHz it could be, and so it needs to be tested and probably scoped before any decision. The PIC clock is good enough for USB specs and it would just be nice to remove unnecessary parts.

loshia
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


View Profile
May 17, 2013, 09:52:05 AM
 #675

You are a star!
My suggestion is to live oscillator  if possible. 1 USD is not deal breaker at all. If i understand it right oscillator  will work better compared to  internal PIC oscillator, right? It might be a stupid question as long as i am not hw expert but  having both oscillator + NOR Gate will not do any harm to design. If yes please leave external oscillator.
10X
No, the NOR gate and the oscillator are unrelated. Just both design changes made today. The spot for the oscillator will still be there but during testing I will be able to test without it by shorting two pads, bypassing it. Doing this and seeing how stable the ASIC is will tell me if it can be removed entirely. Typically at these clock speeds the jitter isn't an issue but since the ASIC multiplies the clock to get up to 300 MHz it could be, and so it needs to be tested and probably scoped before any decision. The PIC clock is good enough for USB specs and it would just be nice to remove unnecessary parts.
Super!

Thanks!

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
alfabitcoin
Sr. Member
****
Offline Offline

Activity: 476
Merit: 250


View Profile
May 17, 2013, 10:19:31 AM
 #676

10x eg thanks
Man, you are genious. I guss you are in advance brain mode so its hard to lower mentality to deduct what 10x mean Smiley
ektwr
Full Member
***
Offline Offline

Activity: 130
Merit: 100



View Profile WWW
May 17, 2013, 11:27:43 AM
 #677

May i suggest something?
It would be a great idea to arrange an online meeting web camera stream.
Watching all experiments and adjustments, with tools, logic analyzers etc.
That event can be arranged and announced as soon as the ASIC samples arrived.
that would be awesome

My cool bitcoin ASIC sites http://mining-bitcoins.co and http://mineasics.com and http://litecoinx.gr
My tip pot: 11bwtjmaNBFX88MParnc7xPxSHmVxjaBJ
miztic
Newbie
*
Offline Offline

Activity: 21
Merit: 0


View Profile
May 17, 2013, 02:15:42 PM
 #678

Going back to the unique ID per board, I think there's an easier solution instead of using a serial number, why not have a set of say 8 jumpers or dip switches on the boards, so we can configure our own unique IDs with those, that'll give you 256 different board ids, assuming the PIC can read the jumpers.

BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
May 17, 2013, 02:28:49 PM
 #679

I've updated github for new Gerbers, parts list and 3D renders.
Now takes into account changes for Avalon protocol docs.

Need to stew on this a few days to find errors and then can order first boards.

Going back to the unique ID per board, I think there's an easier solution instead of using a serial number, why not have a set of say 8 jumpers or dip switches on the boards, so we can configure our own unique IDs with those, that'll give you 256 different board ids, assuming the PIC can read the jumpers.
No free pins for that on the PIC, and that method costs money and requires user intervention. Putting a serial# in the firmware is transparent to the user and doesn't cost anything.

sensei
Full Member
***
Offline Offline

Activity: 378
Merit: 100



View Profile
May 17, 2013, 02:45:37 PM
 #680

I've updated github for new Gerbers, parts list and 3D renders.
Now takes into account changes for Avalon protocol docs.

Need to stew on this a few days to find errors and then can order first boards.

Going back to the unique ID per board, I think there's an easier solution instead of using a serial number, why not have a set of say 8 jumpers or dip switches on the boards, so we can configure our own unique IDs with those, that'll give you 256 different board ids, assuming the PIC can read the jumpers.
No free pins for that on the PIC, and that method costs money and requires user intervention. Putting a serial# in the firmware is transparent to the user and doesn't cost anything.

Thanks for the good work! I really like the idea of a single line serial data serial number chip, but they are prohibitively expensive. The next best solution is to put it in firmware. That's actually what we did on a card we did at my work. Making sure they are unique and staying that way when reprogramming can be tricky.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 [34] 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 ... 182 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!