Thanks for checking it out.
What was your rationale behind the PIC selection?
I just basically chose the cheapest one that had USB with as much as possible internal, so that I didn't need extra crystals/oscillators, or other parts. I've worked with the 8 bit ones and not the 32 bit so it was more familiar for me. I don't think it needs more but if I was already comfortable with 32-bit PICs, and seeing the only small price difference, I'd probably have gone that way.
At the time, there was no information on my end about how to interface with Avalon and the chip I selected had a lot of capabilities
when it comes to outputting a clock at different frequencies. Thought it might be necessary.
I was surprised when I saw on the schematic that they are feeding in a fixed clock. That means they must have the ability to adjust the
clock inside the AVALON ASIC for over/under clocking purposes.
They have a PLL to multiply the clock internally. That's why they have a second 1.2V supply. It probably needs to be noise free and the main supply is bound to be quite noisy with so much activity in the hash engine. At least that's my guess.
The protocol docs are out now so you can read up on the config word for the clock multiply/divide section.
Anyways, do you know what speed the data lines use? I was expecting a separate clock for the data, but there is none according to the
labels. This is my last concern before making a PCB. If data is expected to be around 32MHZ, we may have to consider a different micro
controller altogether. Hope Avalon releases more information about this soon.
They did today. The data is shifted in encoded on the two data lines. I forget the name for this now - brain dead, but I do recall running into it before. Anyway, I believe the period for one bit was 250nS, which makes it 4 MBits/s. Since a UART or MSSP won't be able to do that (I think, I'd have to check), it will likely be bit twiddling, and tight timing wise.
I'm seriously considering the same PIC selection you made. It's too bad we can't double the internal frequency and output it on a pin
with that PIC; we wouldn't need an external oscillator at all. That is one of the first 8 bit PICs that has auto calibration for a tight clock
frequencies to meet USB spec's.
Yes, I initially wanted to use the internal clock gen and output it as 32MHz but there appears to be no way to output the internal clock. The oscillator costs as much as the PIC roughly. But this PIC is also pretty short on memory. I think it'll be enough but with the USB stack it's already 30-50% gone (depending on optimization).
What do you think of the DCDC setup? There's a MOSFET transistor to isolate the USB port from too much capacitance and inrush current.
the transistor will need to be pulsed a few times initially to get the caps charged without drawing too much current. A large current spike
from a USB port can cause it to auto disable.
I also included an input inductor (after the MOSFET transistor) to lower the current ripple. It will make the miner go a lot easier
on the output circuity of the USB port. Given that this is going to run 24/7, it could put some serious abuse on a computer's USB port that is
very cheaply made. I know it adds a little bit more costs, but I think it will be worth it.
It sounds like a good idea. I don't really know much about this area. I've used a different buck reg and control the EN pin from the PIC. It has a soft-start control capacitor and internal current source to ramp up, and together with the PIC deferring start up of the ASIC supply I figured I'd get a workable solution (I don't really get how to calculate the soft-start current and timing from the info they provide, so if you see how then maybe PM me). The buck reg I use is the AP6502A from Diodes Inc. I'm curious if you think that will give enough control. There is a small section on programmable soft-start in the datasheet.
