Hi, Yes I've been working on a separate project, and yes it does work (100Mhash/s at this moment). I can share what I've learnt so far though. I didn't post for awhile because I've nothing constructive to add (being unfamiliar with the MSP430).
Decoupling: whatever the Xilinx datasheet has spec'd is adequate, I've not had noise issues with the minimum number, never tried going below though.
Power Supply: At 100Mhash the entire board was consuming 6+W of power, real life measurements indicate at least 80% of this is through VccInt. A 5A supply for VccIO and VccInt is more then enough. I stuck with the resistor values previously calculated, and came up with 1.18V on VccINT (measured) and 2.48V on VccIO/AUX (measured).
Heatsinking: In an effort to improve decoupling/capacitor performance, I placed alot of the capacitors on the topside right up to the edge of the FPGAs, the smaller 4.7uF capacitors are fine, they are lower then the chip itself, however the larger 100uF caps can be situated away or on an edge where the heatsink will not 'cross'. In the end with my layout I was forced to use a small heatsink (2.5x2.5cm foot print) with a small fan, couldn't find a heatsink that was super tall to get away with a passive design. The heat output itself at 100Mhash/s is significant, you can actually measure an increase in current consumption as the part heats up (possibly due to leakage increasing), and drop when u cool it.
FPGA itself: I've trouble sourcing for the LX150-N3 part in the Fgg484 package in single quantities, forcing me to use a -3 part and thus raising costs. I'm not sure if it's the same situation where you guys are though.
My help and whatnot: I'm still willing to solder the first few prototypes for free. However right now I don't see a very clear direction and idea of what's to be done next (still no MSP430 guys in the fray), especially with the USB to FPGA interface hardware+software side of things, so I can't say for sure if I'll fund the initial boards.
|
|
|
It does make things easier with a UART port, maybe with a USB to TTL converter instead of a MAX232, however we'd now need to add an SPI flash to load the bitstream initially. I was thinking more of a custom Jtag to USB solution using FTDI chips for eg.
|
|
|
I have to admit I'm kind of jealous of you guys. ![Embarrassed](https://bitcointalk.org/Smileys/default/embarrassed.gif) But isn't the Board overengineered? Those voltage regulators look like they could drive at least a dozen spartan-6s. Out of curiosity how much LUTs do the 32bit rotations consume? Molecular: I can register the mail and then we'd be able to track it, I can't seem to find how much it'll cost to register everything, but I do know the base charges. Shouldn't cost more then USD$12 to get this packed and shipped to you registered. ElectricMucus: wow what a nick, yeah it was over-engineered, I had no idea how much current the 1.2V rail will consume in the future, didn't want to re-roll or re-work everything if there is a limitation, going by the measurements I've carried out so far, that size (10A capable) is about right for VccINT, so I wouldn't say it'd be enough to power a dozen Spartan-6s, maybe another 1 at the current power consumption levels. The VccIO and VccAux rails require fair less current then I thought it would, a lower spec part is avail in the same footprint, I'll put it into the remaining production boards.
|
|
|
Go ahead, we've got no reputation at this point of time, and we need to build the confidence. Alternatively we can use offer to use paypal or something. Whichever the buyer prefers.
|
|
|
Jtag itself is fairly scalable, you can chain multiple devices into the loops I.E use the same Xilinx Platform cable to manage multiple boards with a modified harness.
I've yet to test this out properly though, so it'll take some time to implement (software side).
The cool thing about this minimalist design is that, with this as the base, we can add functionality later without having to ditch the entire board and dropping support. This avoids us having to re-spin the entire board, going through all the testing processes and then screwing the previous buyers over.
And yes, the bandwidth required is trivial.
|
|
|
Hi, yeah I've been busy lately. I've no problems with 0402s, but it'll probably slow things down abit. Do we really need the 0402s at this stage?
Regarding the heatsinks, I don't see a problem with the clipons as long as it isn't bumped around. Alot of times I see them thermal epoxied or thermal taped to the package. I don't think we'd be able to find a heatsink that'll cover both the FPGA and Vregs, since they have vastly different heights. The 100uF decoupling capacitors around the perimeter of the FPGA will also probably prevent a long heatsink from being used to cover both chips.
|
|
|
Been busy with another related project recently. I've looked at the PSU section, everything looks ok except for 1 thing that I missed earlier, pin 3 (1 and 2 are for Vin) needs to be grounded, that mistake was probably there when I created the LMZ library.
Can't comment on the current discussion about how to hook up the respective busses with the MSP430, really no experience in this area.
|
|
|
li_gangyi: do you think there will be an inrush current issue with the voltage regulators you suggested?
I don't see it as a problem, if it is, we could always tie a suitable capacitor onto it's softstart pin to ram up the voltages slower.
|
|
|
You'd need seperate resistors to each FPGA and yes, 2 seperate oscillators is better then anything. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif)
|
|
|
That's what I planned on doing, populate 1 board, test it out and if it works, populate the rest. I have no idea how to test the functionality yet except for the PSUs and stuff, unless some1 can come up with some smallish test firmware to be loaded on the FPGA + MCU.
We could just get 1 cheaper FPGA to populate on the 1st board, if that works (meaning the PCB is adequate), I'll then populate the rest of the boards with LX150s.
@Olaf: I'd think a 50Ohm resistor should suffice, however you'd need to route the oscillator traces to only have stray capacitances between it and ground (so it doesn't pickup stuff from power or other IOs). The oscillator you've in mind is pretty good (10ppm), however you'd be pissing away that performance if we do this, I'd prefer to have the oscillator dedicated to each FPGA and keep everything nice and tight, it doesn't take up much board space anyways.
|
|
|
[...] For the FPGA, I suggest the ASEM1-100.000MHZ-LC-T: it's small (3.2x2.5mm 2) and should be sufficiently stable. [...] The oscillator you've suggested runs @ 3.3V, we'd need a 2.5V unit. 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.
I'm not sure how you plan to do this, to do it properly you'd need to buffer the oscillator and/or series termination at each end to reduce reflections. FPGAminer: certainly good news, when this board get's made, I'm sure one of them will go to you.
|
|
|
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.
|
|
|
Something like that yeah, let me copy that in.
Edit: Done, it's inside my folder.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.pdfIn 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.
|
|
|
I can fund all 5 initial boards and then some1 come up with a simple test procedure, say a Jtag boundary scan, I run the tests and if they pass I sell the board at cost + shipping to whoever needs them. How's that? Regarding the clk source, I know the AVnet boards that the guys over on the Open Source FPGA thread are using, have an external 100Mhz oscillator. http://www.files.em.avnet.com/files/178/xlx_s6_lx150t_dev-sch-revd090810.pdfSheet 20 shows the clocks. (Thanks to Fpgaminer for pointing me in the right direction.) We should go with this known working solution. Once Olaf is done, including the MSP430, I can route in the PSU, I think we should leave out the external LDO for the MSP for now and just use suspend, to keep it simple. Then we'd be able to let every1 vet through the design, spot any major errors and move on to production.
|
|
|
|