Thanks! I just now finished the same calculation and got the same results (didn't check the forum first)   

Not yet. I also wanted to incorporate the suggestion by TheSeven to increase the 1.2V rail to 1.26V, and I haven't thought about how to find the closest matching resistor values for a given ratio.

Good question, the exact current can probably be given by TheSeven, as he compiled (some version of) the HDL code that runs on the FPGA and the tools can give a power estimate. He insists these numbers are highly unreliable, but they are still the best we have at the moment. That said, we can also look at the datasheet: the maximum current for VCCAUX should be 600mA per FPGA, but there is no power consumption specified for VCCIO. As we don't connect many io pins, my guess is that this is low (100mA, maybe). So a 2A switcher may be sufficient. But a guess is all it is! We have to build the prototype and measure the currents in each path.

There are caps on the back (the smallest ones, only). The board is only 1.2mm thick, in which case the Xilinx PCB design guide assigns them to the back. Instead of an image, how about a PDF with the schematics, views of the board with all layers, from the front and back and a BOM? This PDF is available on GIThub if you don't have Dropbox access. The only problem: it's too large for direct download from the webpage, you need to clone the repository.

I think moving the resistors below the FPGAs is a given by now. But if we increase the core voltage to achieve higher clock rates, then I would ask how close we want to cut it: is there a risk of having any EMF mess with the trace from the resistors to the switcher, so that the switcher runs at a too high voltage? What about required or suggested resistor tolerance: is 1% sufficient?

And our of curiosity: what is the gain in terms of clock rate for a voltage increase of 0.05V? I am willing to take ISE estimates after whichever stage you feel is remotely reliable.

I went ahead and merged the different parts temporarily. I still feel that at least the MCU is unfinished enough to warrant not doing the final merge, but this temporary merge lets us see where we are going:



The BOM total for one board is about 340EUR (a few components are still missing, but those should fit in that price limit). The board price at pcbcart is 27EUR per board plus 135EUR one-time costs with the following settings:

• Material: FR4
• Layers: 4 layer
• Material Details: Standard Tg 140C
• Board type: single unit
• Board Size (width): 135mm
• Board Size (height): 95mm
• Quantity: 5pcs
• Thickness (Finished Board): 1.2mm
• Layer Stack: As pcbcart default
• Layer Stack Details: -
• Impedance Control: No
• Surface Finish: Lead Free HASL - RoHS
• Outer Layer Copper Weight (Finished): 35um
• Inner Layer Copper Weight: 35um
• Min. Tracing/Spacing: 0.15mm
• Min. Annular Ring: 0.10mm
• Smallest Holes: 0.30mm
• Holes Number: Over 600
• Buried/Blind Vias: No
• Times of Buried/Blind Via: --
• Surface Mount: 2 sides
• Soldermask: Both Sides
• Peelable Soldermask: None
• Soldermask Color: Green
• Matt Color (only add to Green or Black): None
• Silkscreen Legend: 2 sides
• Silkscreen Legend Color: White
• Gold Fingers: Yes
• Gold Fingers Number: 240
• Gold Fingers Chamfer: 60°
• Slots in Board: No Slot in Board
• Slots quantity in board: -
• Testing: Yes
• UL Marking: Yes - as pcbcart default
• Date Code Marking: Yes - as pcbcart default
• Lead Time: in 18 days
• Special Requirement Note: -

So a full set of 5 prototypes is about 5x400EUR = 2000EUR.

PS: When doing the merge, I also found two small bugs in the PSU (not replaced the resistors, yet), so reuploaded that, too.

This has already been discussed and is on the roadmap. Basically, the plan is as follows: First we walk, then we run.  Meaning that first we get something working that requires a computer and then we change the backplane to include an embedded, ethernet capable computer. This will leave the FPGA design completely untouched (it being on a different PCB and all). We haven't discussed which CPU to use later, because we first have to get this one working...

I just looked through the LMZ12010 datasheet. According to eq. (4), li_gangyi's resistor choice should get us VCCIO=2.484V and VCCINT[01]=1.193V. The recommended resistor values in the table on page 2 would give us  VCCIO=2.474V and VCCINT[01]=1.210V, instead. So li_gangyi's seems better to me, as it is closer to correct in both cases.

Can any of the MSP430 guys give their opinion here?

Looks good. I didn't pay attention when looking at / changing the USB connector. How many LEDs do people envision we need? We have 11 free pins on the MCU, but that seems excessive. Maybe 3? How many each for the FPGAs: five each?

I uploaded a new version of the BOM to github and dropbox. Commit log:

Finished updateavail script:

• updateavail.sh now works correctly with avnet
• Merged in new version of the database from fizzisist
• Changed the package for the FPGAs to what is being used
• Added second supplier for the FPGAs and big switchers
• Updated extended database: runtime = 45s

Back to the boards. I will now look at fizzisist's new MCU.

Actually, concerning the update-script: this does not (easily) work for Windows-users. This should be convertible to Eagle ULP if you try. Does anyone think that effort is justified?

I uploaded new versions of the PSU design and a BOM script to github and dropbox. Commit logs:

• Fixed LMZ22010 <-> LMZ12010 mixup:
  
  • Renamed GND back to AGND and PGND in LMZ22010
  • Changed description and default device name for LMZ22010
  • Added an explicit LMZ12010 device and symbol to the library (the symbols have the same pin lications for easier exhanges)
  • Used the new LMZ12010 in the PSU design
• Added script to update BOM database: The script updateavail.sh (POSIX systems only) queries the distributors webpage for each part in the *.tsv file and adds columns for number of on-stock parts and prices for different price-breaks. The project.tsv file has been reformatted to match the expected input of this script. TODO: Currently supports only DigiKey as a supplier. Need to add Avnet support.

I haven't used fizzisist newest database as the basis for my reformated one. Will do so by the next upload.

There are currently only SMD connectors, but as li_gangyi already pointed out these should be changed (in some cases: changed back) to through-hole. I just haven't done it, yet.


That is a bit problematic: the Xilinx PCB design guide calls for 0402 imperial size caps. Does anyone have a good feel what happens if that size is changed? If the caps should stay 0402, then my second question is: does it make sense to keep the 0402 caps for the FPGAs but make all other 0402 size devices larger (for the MCU for example) or is there no extra difficulty on using more 0402 packages than absolutely necessary?


Didn't even notice that. The thing had different names in the library: the symbol was called LMZ22... and the device LMZ12... I just selected the symbol name to open the datasheet and then renamed the device. As far as I can see the current design is fit for both devices, though: pin 3 (the only difference between the devices) is grounded, which it needs to be in both cases. For the LMZ22..., it also needs to be grounded because we do not connect a frequency source.

I uploaded new versions of the FPGA, MCU and PSU designs to github and dropbox. Commit logs:

• Updated LMU22010 in library and in PSU:
  
  • Changed pin SMD pad sizes and count to match datasheet
  • Changed schematic symbol to have correct number of pins
  • Updated PSU schematic and board to use new device
  • Set SYNC pins to GND as per li_gangyi's instruction (and datasheet)
• Renamed SPI bus to FPGAs and synced designs:
  
  • Renamed the SPI bus to the FPGAs in the MCU section from *_D to *_F (F standing for FPGA)
  • Changed the names in the FPGA design to match these
• Finished MCU connection:
  
  • Connected SPI clocks to multiplexed pins (CHECK THAT THIS IS USABLE!!!)
  • Connected all other signals to some GPIO

I am happy with that choice. But please consider avnet for the actual FPGAs and switchers, as they are significantly cheaper. I just had a look at the switchers: there is not much stock (64 and 90, respectively) for the LMZ12010.


For the caps in the FPGA section, these are based on the recommendations in the XIlinx PCB design guide. I would opt not to change those. The resistors in the FPGA section were chosen by me: no particular reason for this size, I just wanted something small that should still be able to stand the dissipated power. For the PSU section, li_gangyi chose the component sizes. I replaced all packages with something found in the rcl library (I prefer to have a common look of the symbols and I try not to have several non-standard libraries in the project). If any of the parts there strike you as odd, I either made a mistake when doing the conversion or you should get li_gangyi's input as to his package choices (I am really bad at analogue stuff, so I wouldn't want to comment). As for the MCU section: I replaced most of the choices in O_Shovah's original design with something else. The idea was to minimise the number of different components: for example in several places where 100nF would have been sufficient I wrote 470nF instead so as to use the same parts as for the FPGA.

Didn't pay attention to that. On the other hand: the schematic symbol is identical, so changing that is easy.


Availability: yes. And li_gangyi has an XLS BOM on dropbox. But I would prefer an Eagle database for the bom.ulp program. If you could get started, that would be cool!

Of course not. There are two 2.5V supplies in the PSU design:

VCC: Fed by the 3.3V LDO in the MSP430. Powers the MSP430 and nothing else.

VCCIO: Fed by the +12V connector. Powers the VCCio rail of both FPGAs.

Not much work. I said it to make you learn the "eagle way" of schematic entry. I guess transitioning from a different program is tough.

I just read through the MSP430 docu and found two things:

Good news: multiple SSEL signals are no problem. The STE signals provided by the serial engine are different from the SSEL signals. They are to facilitate multiple masters on one bus, so we don't need them. This means we can set UCMODEx=00 (3-wire mode) in both UCA1CTL0 and UCB1CTL0.

Bad news: the way the two serial engines are multiplexed onto the output pins, it is impossible to configure one engine to 4-wire mode and use the second engine at the same time. We don't need to to that, but this raises the question if two concurrent 3-wire SPI engines on the same port are even possible at all. Can anyone who knows their MSP430 forward and backward answer this? Alternatively we could use a 64-pin package (the 5510IRGC).