Quote from: mike2kt on May 16, 2013, 11:23:39 PM

Quote from: TomKeddie on May 16, 2013, 09:43:53 PM

Quote from: hashblue on May 16, 2013, 09:01:39 PM

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.