Modular FPGA Miner Hardware Design Development

[magik]

With what I'm used to that sounds perfectly fine.  We use a 100 MHz crystal - and the PLL/DCM can easily turn that into 100 or 50 using the least noisy clk0 output, and we can get all kinds of different ranges with the clkfx output - multiply the clock or reduce it in IIRC any integer between 1-256 over 1-256

I'm just unsure of what clock levels we can obtain we the hashing code.  You know, I'll try to run some compiles right now and see what we can get, but now that I think about it yeah, if someone else said they had it running around 100Mhz then that sounds about right, we can tune from there.

There's a lot more projects in that open source fpga miner github now heh.... hrm.... i should probably go read that thread again

btw if anyone wants to read up on it:
Spartan 6 FPGA Clocking Resources
http://www.xilinx.com/support/documentation/user_guides/ug382.pdf

[1713285188]

1713285188

[1713285188]

1713285188

[1713285188]

1713285188

[1713285188]

1713285188

[O_Shovah]

@li_gangyi:
I m fine with you offer. This procedure will simplify the money things.
So everybody who would do the firmware and software programming should get a copy.

Wow,suprise. I didn't know there were such detailed Altium schematics of a commercial board avaidable.Certainly a great source for comparison.
Maybe you want to change the clock source you propose into the MSP/FPGA setup yourself as i wont be abled to do this the next days.

[newMeat1]

Well I am surprised by this thread. I never expected a group to pull together and finish up a design. I still think you've made some poor design decisions, but that was bound to happen with this group mentality.

Let me know if you want helping moving from a 4-layer board to a 2-layer board. That should save you at least $10 for every board.

You can switch from low-ESR caps to normal caps to save a bit more money. The low-ESR caps will use slightly less energy, but they won't filter the signal any better (unless you can show me solid proof to the contrary). I get my stance from this:
http://www.ultracad.com/mentor/esr%20and%20bypass%20caps.pdf

[TheSeven]

With what I'm used to that sounds perfectly fine.  We use a 100 MHz crystal - and the PLL/DCM can easily turn that into 100 or 50 using the least noisy clk0 output, and we can get all kinds of different ranges with the clkfx output - multiply the clock or reduce it in IIRC any integer between 1-256 over 1-256

I'm just unsure of what clock levels we can obtain we the hashing code.  You know, I'll try to run some compiles right now and see what we can get, but now that I think about it yeah, if someone else said they had it running around 100Mhz then that sounds about right, we can tune from there.

There's a lot more projects in that open source fpga miner github now heh.... hrm.... i should probably go read that thread again

btw if anyone wants to read up on it:
Spartan 6 FPGA Clocking Resources
http://www.xilinx.com/support/documentation/user_guides/ug382.pdf

I had a quick try, and without any optimizations it was able to reach 50MHz. 100MHz is pretty certainly doable, and there are even reports that, with proper optimizations, a 190MHz synthesis would succeed in like 5% of the attempts. To reach optimum performance, it's very likely that we'll need CLKFX.

[li_gangyi]

You can switch from low-ESR caps to normal caps to save a bit more money. The low-ESR caps will use slightly less energy, but they won't filter the signal any better (unless you can show me solid proof to the contrary). I get my stance from this:
http://www.ultracad.com/mentor/esr%20and%20bypass%20caps.pdf

In the SMPSU, you'd want to have caps rated for the ripple current, you can get away with using standard capacitors, but you'd need multiple parallel caps. The standard ESR will also cause temps to go up, leading to bloated capacitors. Seen this way too often on cheapass PSUs.

[newMeat1]

Well, I'm talking about ceramic surface-mount caps. By bloated I guess you mean an electrolytic capacitor with leads? Why are you using one of those? I would stick to all SMT

Edit: although I agree that high-current buses whould have low-ESR

[li_gangyi]

Well, I'm talking about ceramic surface-mount caps. By bloated I guess you mean an electrolytic capacitor with leads? Why are you using one of those? I would stick to all SMT

Edit: although I agree that high-current buses whould have low-ESR

I've not seen 330uF ceramic capacitors yet, I think on digikey the highest u can find is probably 100uF. Electrolytics can be surface-mount types.

We're not trying to cut costs for the initial prototype, we're trying to make sure the chances of it working are high. If we want to, we can start removing bits to test stability after the prototype is done.

[Olaf.Mandel]

I uploaded a new version of li_gangyi's PSU schematic and board to github and dropbox. Commit log:

Bugfixes and cosmetic changes to PSU design

• Renamed power signal names (to VCCINT[01])
• Changed connectors to SMD versions (includes part in library)
• Explicitly added PSU_EN signal
• Changed labeling of components (1.2K -> 1k2)
• Changed paper format from letter to DIN-A4

I thought that going all SMD looks nicer... Undo that if you disagree.

Still TODO: There is over a hundred error messages by the design rules check: the way the traces and polygons are done is a problem for eagle. Vias to the other layers need to be added. And what about proper heat sink areas?

[li_gangyi]

It looks good, I've checked and it looks like it has the adequate number of decoupling capacitors, and routed quite well. Now we just need to see how the rest of the parts fit in.

[Olaf.Mandel]

It looks good, I've checked and it looks like it has the adequate number of decoupling capacitors, and routed quite well. Now we just need to see how the rest of the parts fit in.

Thanks. I just uploaded a new PSU version. The only important change is the names of the 1.2V nets. those were originally VCCAUX[12], which don't exist in the FPGA schematic. The rest are cosmetic changes. Comments on getting rid of the through-hole parts?

[li_gangyi]

I wanted the thru hole parts for better strength, if you're gonna be plugging the molex a couple times, the surface mount part might just shear off.

[Olaf.Mandel]

I wanted the thru hole parts for better strength, if you're gonna be plugging the molex a couple times, the surface mount part might just shear off.

Ok, so it should be changed back.

Another point: the Library parts for the switchers are a bit buggy: the symbol is too narrow and the package gives an overlap error (did you use a rectangle to extent an SMD pad?). If you copy the device to the library, this can be easily fixed. Thank you!

[li_gangyi]

Something like that yeah, let me copy that in.

Edit: Done, it's inside my folder.

[bahnfire]

Sorry about the delay in replying back - I was supposed to come back Friday night/Saturday morning from vacation and ended up coming back late Sunday night. I will look over the multiple pages posts and will see if anything major changed and where we are in the design.

[O_Shovah]

I had a look at the routing and layout plans. They look really fine and i couldn't find any mistakes so far.
So great work from Olaf.Mandel and li_gangyi, thanks.

In return. Has anybody found any mistakes in my MSP 430 setup so far ? Or what needs to be added ?

What is to be done for getting the final testboard ? Any additional requirements not added yet ?
Maybe we should set up a list of what is in now.

@ Bahnfire:
I remember you to be used to firmware programming for the MSP 430. Maybe you could give us word on that and head towards a firmware for our application.
Also maybe have an additional eye on our current Layout.



I also take it as agreed that li_gangyi produces the first testborad and ships(& sales) them to the ones of us producing the initial testing and software for it.
Any objections on this ?

I personally will dig further into the copyright matter.Please have a look on the CERN OHL and the GPL v3 ion combination as i already posted, and give me your thought if it seems applicable to you.     

[Olaf.Mandel]

I uploaded a new version of the FPGA section and of li_gangyi's PSU schematic and board to github and dropbox. Commit logs:

Routed PSU: Fixed the package of the PSU switchers (had two pads) and routed the PSU section.

Created symbols for VCCINT[01]: Added corresponding symbols to the project.lbr library and used them in the FPGA files. Also replaced the older name of the library with the correct one in the schematic.

Next is the MCU section.

[li_gangyi]

I uploaded a new version of the FPGA section and of li_gangyi's PSU schematic and board to github and dropbox. Commit logs:

Routed PSU: Fixed the package of the PSU switchers (had two pads) and routed the PSU section.

Created symbols for VCCINT[01]: Added corresponding symbols to the project.lbr library and used them in the FPGA files. Also replaced the older name of the library with the correct one in the schematic.

Next is the MCU section.

We still need to put in the clk sources as well.
I suggest 100Mhz with a 2.5v oscillator module, on pin IO L40P GCLK11 M1A5 (each FPGA has 1).

Edit: I looked at the routed PSU, you might want to put some vias under the LMZ modules to better sink heat away from the thermal pad. In fact you could use unused layers in the board to make a more effective heatsink as well.

[Olaf.Mandel]

[...]
We still need to put in the clk sources as well.
I suggest 100Mhz with a 2.5v oscillator module, on pin IO L40P GCLK11 M1A5 (each FPGA has 1).

I already suggested a suitable MEMS oscillator before:

[...] For the FPGA, I suggest the ASEM1-100.000MHZ-LC-T: it's small (3.2x2.5mm²) and should be sufficiently stable. [...]

The design as it is on dropbox and github calls for the clock to be connected to IO_L30N_GCLK0_USERCCLK_2, pin AB13. The clock is shared between the two FPGAs (no need to have a dedicated clock for each). I will put the oscillator into the design, so it is no longer routed to the MCU.

Edit: I looked at the routed PSU, you might want to put some vias under the LMZ modules to better sink heat away from the thermal pad. In fact you could use unused layers in the board to make a more effective heatsink as well.

Can do that, but wasn't there the comment that putting vias onto pads causes problems during manufacturing? And eagle doesn't like it at all (a lot of drc errors).

[TheSeven]

Can do that, but wasn't there the comment that putting vias onto pads causes problems during manufacturing? And eagle doesn't like it at all (a lot of drc errors).

If at all, that's a problem for BGA pads. The rather huge thermal pad of that voltage regulator can certainly have vias, I'd encourage that as well. (Look at any commercial PCBs, e.g. your graphics card, and you'll see loads of vias below things like voltage regulators or power MOSFETs.)

[fpgaminer]

I am not sure if this was made clear in this thread or not, but I will bring the news regardless:

Over in the Open Source FPGA Miner thread we have succeeded in getting a working, and verified design running on my LX150T dev kit. I did verification against a live pool at 50MH/s. The design can currently be clocked up to 100MH/s. I thought you folks would enjoy the good news if you hadn't heard it yet

Most of us believe the LX150 can push beyond 100MH/s, so we are working towards that end through either a dual-core design or higher clocking. I am hoping for anywhere between 150MH/s and 200MH/s.

I should also note that I use a DCM to adjust the incoming 100MHz clock to the desired frequency (I saw some discussion on that in this thread). I use the clkfx output, because it gives the range I need for testing weird frequencies. There should be no problems using a different frequency external clock, but 100MHz is what I am getting from the Avnet board.