|
How soon are we proposing to get these boards out? I need to clear some storage space for the parts and boards.
$65 is with or without the cost of populating these 5 boards?
|
|
|
|
Since there are two regulators for VCCINT it's better if they are separate even if they are happily connected together. ( most dc-dc don't like this).
With separate planes you can have individual feedback from each FPGA.
You don't need the VCCINT planes to cover the whole board, just under the FPGA extending out the the caps surrounding it and a super fat trace to the DCDC switcher.
We can swap up to the current sharing capable LMZ modules, and make the Vccint 1 single supply, that'll need an external clock to make sure both modules run at the same frequency though. Can be a simple 555 or driven off the MSP430. With the MSP430, u can even generated a 180deh phase shifted clock, to reduce ripples in the output. Good note on the Vccint plane, it should decrease routing complexity some. |
|
|
|
|
I don't know how much memory the final design will need, but at the start if we want to just use the MSP430 as a glorified USB to Jtag adapter the current part should be fine, if we wanna say load the bitstream and everything from the uC, I don't think it'll be a good idea, we should just leave that for the motherboard design stage.
Basically I don't see a need to move to a bigger/more powerful MSP.
|
|
|
|
|
No specific reason why I went in from the other side, for the termination resistors. I've done up the PSUs for both Vccints, feel free to move them around if there is a need to.
We need to roughly combine the work together, else there's no way to put in the rest of the parts, i.e I need to ripup alot of your work to get stuff to fit in.
I've also reworked the PSU and the FPGAs to bond their GNDs to the 2nd layer pls check the layout. Vccio is mostly routed except for the SMPS module itself.
|
|
|
|
|
Personally it doesn't look too bad to me, I just need to check that we are meeting requirements for decoupling capacitors.
GND on layer 2 would be best, however we'd have to put in blind vias to link up the top to 2nd in order to still make the rest of the space usable. I might have gone overboard when testing it out though, I had vias going from almost every node to the 2nd layer.
I'll add in the PSUs to the new board layout later.
Edit: Ok added it in, we're gonna have to touchup the IO routing abit, let me finish up the rest in the next few hrs.
|
|
|
|
|
I can add a LDO to power the MSP430 if you guys think the hibernation mode on the FPGA is critical, I don't think leaving the Vccaux on all the time while the device is hibernating is a good engineering practice. Only Xilinx can answer if that's a good long term strategy, because it seems like it might work, since you're holding the FPGA from turning on.
The next best thing (instead of switching off the PSUs as well), is to just put the FPGA into what's know as the "Quiescent Current Level" stage, UG394 describes more of this.
O_shovah: nice work, I'll add the MSP in later into the combined board we have now.
|
|
|
|
|
With blind vias it'd be easier to put gnd on the 2nd layer and route the gnd pins down to that, it's not strictly necessary though. Can you finish routing up the rest of the board? It's pretty close to done. Look in the main folder.
We still need a clk source and MSP430 hooked up. I've freed up 1 layer of the board, so that should make things easier. We'd need the FPGA and MSP guys to come in now and offer some input on how best which IOs go where and the clock source.
|
|
|
|
|
Ok, I've splitted in the schematic VccINT into 1 and 2, and seperated them + put down the planes that're for power. Also merged Vccaux and VccIO into VccIO, the Vccaux layer is now freed up for IO purposes, renamed the layers to match.
Also merged the schematic properly so the ratnest comes out right.
Still to do:
Optimise the capacitor layout, finish routing the PSU and link it up actually to the board. We can actually afford to route the feedback from the Vccint layer, as long as we keep the resistor physically close to the LMZ module.
Slight OT: Adding blind vias = alot more $$$?
|
|
|
|
Please guys, use a full unbroken GND plane for the entire board ( preferrably on layer 2 right below the FPGA ) The core voltage should also be a power plane under the fpga (layer 3 is best), extending out to the decoupling caps (as unbroken as possible). Feedback to the core regulator should come from the power plane so it "sees" what the fpga "feels" ^_^ Just route out the IO pads you get "for free" down the the connector. 4 Layers should give you plenty without having to compromise on power integrity. Merging VCCAUX and VCCIO is smart as there is very little IO toggling to generate noise into the PLL's anyway. Good decoupling is always a must. Add decoupling footprints at the back of the board directly under the FPGA just in case. (not mounted for now) Have a look here: http://www.xilinx.com/support/documentation/user_guides/ug393.pdf The decoupling section is kinda overkill but lots of nice tips on several topics. My recommendation is to add a few 4.7 or 10uf caps and several 100nF as near the power pins as possible for each rail. VccInt is the one to give priority if there is a conflict. I'm sorry if this stuff is well know to you already, but better safe than sorry  Looks like we're gonna need to redo this, I don't see a quick way to change the current layout to make it happen. Need to do: Reroute Layer 2 = GND Layer 15 = VccINT and split it at the same time Layer 16 = VccIO+AUX |
|
|
|
|
Uploaded new sch and brd files to the main folder, which combines both the FPGA routed so far and the PSU, I haven't layed out everything yet, about to hit the sack, it's now 4AM here.
What I've done:
1. Put layer names for better clarity
2. Put in the PSU in a new sheet
3. Layout most of the components on the board
Need to do:
1. Split up the VccInt for both FPGAs (I'm planning to power them seperatly)
2. Complete routing the PSU
3. Maybe provide a little bit of seperation for the Jtag traces, I don't like how they are all in the same plane right now.
4. Put in suitable clock(s).
5. Put in the MSP430
|
|
|
|
|
Yeah, that's what I was afraid of, let's not do that, in fact I think we can leave Vccaux and Vccio seperate still and join them upstream later in case we need to put in some filters to make it work. We still need to split the Vccint. I'm trying to route in the PSU as part of the board.
|
|
|
|
|
Alright, so we're pretty much basically set in terms of IOs required. Do we still want to route IOs out? IMO it's a waste of time, but if it helps debugging I'm all for it.
|
|
|
|
What I was saying RE: the extra pins was to take as many as you can and connect to individual test points not to just one. If you are working on a prototype this is the way to do it since you have easy access to pins if you need extras and will not need to do a whole new board spin (especially since this is a BGA). For production you can remove as many of these points as you can without sacrificing your future debug capability.
My opinion (and based on many years of experience): The goal should NOT be to design the first prototype(s) with the final dimensions (PCB size) as this will bit you later. You should always build a larger PCB that has all components and maybe a few extra items for testing to allow for easier debugging, dead bugging, and testing. Once the prototype is proven you can move to a smaller iteration of the PCB. Designs similar to this module could take several PCB runs from prototype to production.
If we do not do this we will run the risk of this adventure costing a lot of money and time.
This would be why we need those FPGA guys right now, what kinda IOs are gonna be required? Is jtag and what not we have now sufficient? If we need more IOs that what we have planned now, I don't think a 4 layer board is gonna to suffice, if we want to route out ALL the IOs, that's gonna take at least another 2 layers IMO. Do we need some sorta external memory for 'bitcoining'? If we later decide that we need it, it's going to require a new run of boards, there's no easy way to add the functionality later. I.E even with all the IOs routed out it's not much help. I'm willing to fork out money to produce the 1st batch of boards, but without these critical bits of info, we're shooting in the dark. We're gonna need some guy or girl for that matter who has dabbled with this, and knows for sure what we need, otherwise we'll just end up producing a dev board in the end to get to the results. We're working on a smallish budget, let's put in solutions that are known to work, instead of stuff that 'should work', if it's new ground, we should trash it out and discuss it before putting it into the design. |
|
|
|
I've looked at some calculations, if we assume the 10A is spread out across all vias and traces, 0.3mm will handle 1/2 an amp safely, most of the pads have 2 traces supplying Vint. I have no idea how well Vint is spread out internally in the die.
To increase tolerances, we can goto a slightly thicker top layer, the only real way to test if we can continue to use 35um is probably to manufacture one test piece.
So will you do that test piece for the power supply or shall somebody else do this ? The main purpose of using the LMZ modules is so that we wouldn't have to do this, I have real life experience with these modules already, and I know they work as advertised, if anyone still wants to make a test PSU, I can ship out some LMZ modules for free to cut down on costs (this are like $15 a pop), eval kits are also available if you just wanna see how well they work. I propose we route out the rest of the board, make a test batch of PCBs and then I can populate the board with say 1 FPGA to cut down on costs, and then ship them out to software devs who can then figure out what to do with the MCU and FPGA coding. Right now I'm not too worried about the hardware design, I can see active development, but no software dev has stepped up to offer help just yet (or maybe I'm just missing their posts). I'm no good with MSP430s just yet, so I can't help here. |
|
|
|
|
GNU GPL is the simplest and most convenient way to go about protecting this collaborative effort.
|
|
|
|
|
I've looked at some calculations, if we assume the 10A is spread out across all vias and traces, 0.3mm will handle 1/2 an amp safely, most of the pads have 2 traces supplying Vint. I have no idea how well Vint is spread out internally in the die.
To increase tolerances, we can goto a slightly thicker top layer, the only real way to test if we can continue to use 35um is probably to manufacture one test piece.
|
|
|
|
|
Since we have dedicated layers for power, I don't think thickness is an issue at 10A, we'd just need a wider trace. 35um is cool, VccINT is also on the backside, exposed to free air (instead of say in the middle), that really helps out alot on heat.
|
|
|
|
|
I've looked at the new layout, it looks alot better then the previous one we had. I wouldn't stack the signals like that, the PCB material in between effectively becomes a capacitor and can cause all kinds of weird things to happen. I think we should route it as per normal on 1-2 layers.
I'm thinking of splitting the FPGAs in the middle, and then adding the MCU and VccAUX PSU in there, and the VccINT supplies individually above each FPGA. It'll simplify the routing for the output of the PSU (we still will have challenges related to the 12V in bus, but I think that's solvable) and create a lower ohmic drop since current doesn't have to travel from left to right.
|
|
|
|
Actually, could you not share those? The VCCaux supply powers the frequency synthesizers in the FPGA and needs to be filtered to a better degree than VCC_O. This is apparently normally done by taking a supply to generate VCC_O and then adding an LC-filter to get VCCaux.
I've looked at the spec sheet for Vccaux specifications, only real limitation is I do not allow more then 5% ripple to be exceeded on the design. At the current number of IOs that we need (non of our IOs need to be driven very hard, or very fast), that's not going to be a problem. As long as we include the suggested number and layout for decoupling caps it's going to be sufficient. I've looked at the Xilinx forums regarding this matter, and nothing seems to suggest otherwise. http://forums.xilinx.com/t5/Spartan-Family-FPGAs/Doubt-regarding-VCCAUX-voltage-level-and-its-separate-power/td-p/162346 |
|
|
|
|
We can always minimise risks, populate the PSU first before the FPGA, populate only 1 FPGA at the start, and if all else fails, remove and reball the FPGAs and list em on ebay I guess...
How are we planning to power the MSP430? 2.5v? And does bitcoin mining require any sort of external memory buffer? I'm not familiar with FPGAs enough. We also need to think about the clock source.
Maybe some1 can draw up a block diagram of what the final result will look like and then we can solve each one step by step.
|
|
|
|
|
Show Posts
