Klondike - 16 chip ASIC Open Source Board - Preliminary

[TomKeddie]

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.

[sensei]

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

Knecke,

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

[hashblue]

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]

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

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]

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]

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.   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.

[SebastianJu]

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

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.

[TomKeddie]

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]

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]

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]

BKK,

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

[BkkCoins]

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]

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

[BkkCoins]

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]

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!

[alfabitcoin]

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

[ektwr]

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

[miztic]

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]

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]

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.