Quote from: vs3 on July 13, 2013, 09:37:06 AM

Quote from: BkkCoins on July 13, 2013, 09:23:59 AM

New scope pr0n... with extra inverters, showing a 1 bit and two 0 bits.

I think this was at 390 MHz. Shows fixed 50nS delay on clock trailing edge on input to PIC. Note this inverts data and clock so now the code is set for falling edge capture and no longer inverts RCREG upon read.

http://i.imgur.com/NmZ6qQN.jpg

BKK - That spike in the red line at -50nS (when the yellow goes down 1->0) - is that introduced by possibly too long probes?
If not - that's 0.8V from peak to peak and I'm wondering if it introduces any other issues at higher frequencies ...
My guess is that it could be either due to the red and yellow wires being too close, or most likely sneaking in via the power lines ... maybe some more decoupling capacitors?

That's just an observation. If it doesn't cause any issues please disregard my note and let's stick with the K.I.S.S. principle

edit: there is also that huge spike when it goes from 0 to 3V3 (4.4V peak when just the red switches, or 5V when both switch). Again - if it's not an issue - don't bother fixing it.

The fast edges does tend to cause small surges in power use that can show as ringing in nearby traces. This is probably made worse by the thin wires and long exposed traces on the proto board. I don't think it's an issue as it shows up now, and the final board layout should lessen it. I was thinking of adding another decoupling cap to the PIC and this actually looks like a good place to put one.

Quote from: terrahash on July 13, 2013, 11:13:46 AM

Our sample board is now working at all the way up to 347 MHz. I was using a NTE NOR gate IC that I bought at FRYs, for both NORs (I wasn't using the one on the board). Looks like its fall or rise times are a little too much. I played around with a lot of capacitors. I finally modified the circuit to use the on-board nor gate chip for the first NOR and the FRYs one for the second. And now everything is working fine. The board is hashing very well at 300 MHz.

Excellent!

I'm treating your use of all 16 chip locations as verification of the current PCB, so that I can revise and release an update without myself having to put 12 more on. Every day counts right now. I've completed the NOR gate, inverter and fan control revisions. Next up is ferrite beads and moving the thermistor. Then the PIC QFN version, and new logo. I'm also going to move the big caps in the middle just a smidge since the latch for the PCIe connector is a bit close.

I just ran for two hours off the RasPi instead of my notebook and for whatever reason the error rate dropped to around 0.7% - over 2 hours! That made me very happy as I've been trying to get it down to <1% and this indicates that noise may be a real factor. Let's hope the ferrite beads really clean this up.

Another thought I had was whether the USB stack provide dy Microchip actually has robust error checking. If not, or if it's an option not turned on (which I didn't see) then USB errors not being re-transmitted would cause corrupt work data being sent to the ASIC. I'll have to go explore that code and find the error checking routines and see how they are treated. I thought of this since putting it on the Pi means a different USB host controller and perhaps different noise.

( btw it's nice to be able to just pop in to frys and get stuff. I stayed a while in LA for work and had a rent a car so I'd check it out almost daily. Where I am now it's impossible to find anything and overall it's a small miracle that I did as much as I have here. A lot of community support really helped. I may have packed it in long ago if not for so much interest and cheering on. )