Sounds good. I will review thread history tonight to see what has been done (decisions, links, etc). I do agree that adding in support for future expansion would be nice, since this could be a nice training/development platform as well as for the BTC market. I will post any recommendations on this thread. What is the time line - when are you expecting to hit the PCB house for the first run?
I am trying to contact the admin/owner of the asicminer site through reddit as I have engineers in China near where his production/design house is located. The cost that he has mentioned on the website is $250*5000 ASICs which would place the total cost around $1.25million, BUT that is the sell cost (profit, etc). To build a custom ASIC you would need around $1million - to build a semi-custom (pre-done core, load your code onto their design to fit, etc) it would cost around $500K. It is possible to do but I do not know if you would see the high hash rates that he is claiming - especially since he is VERY quiet on any specifications.
Topic: Modular FPGA Miner Hardware Design Development - page 18. (Read 119276 times)
Im happy to hear that.
Adding leds shouldn't be a problem.You just have to tell us how many you would consider best and how to add them into the design.
There hasn't been any prototype so far and there are still some parts to be design finalised ( Bus system,Power supply,....).The BUS system is currently thought to consist of USB, SPI and bitbanging JTAG with the MSP430 in oder to talk to the FPGA and the USB connection on the DIMM as also the Motherboard.
Considering this newspost : http://asicminer.net/?p=58 we should also think of a way to make our design capable of processing more than just the bitcoin hashes. (more IO's connected ?) Just as a fail back, to keep it worthy, even if ASIC would rush the market now(altough i still consider this offer quite fishy).
There hasn't been done anything on the software side so far.
I asume you get the most things already finalised in my firstpost.So feel free to comment on those.
Adding leds shouldn't be a problem.You just have to tell us how many you would consider best and how to add them into the design.
There hasn't been any prototype so far and there are still some parts to be design finalised ( Bus system,Power supply,....).The BUS system is currently thought to consist of USB, SPI and bitbanging JTAG with the MSP430 in oder to talk to the FPGA and the USB connection on the DIMM as also the Motherboard.
Considering this newspost : http://asicminer.net/?p=58 we should also think of a way to make our design capable of processing more than just the bitcoin hashes. (more IO's connected ?) Just as a fail back, to keep it worthy, even if ASIC would rush the market now(altough i still consider this offer quite fishy).
There hasn't been done anything on the software side so far.
I asume you get the most things already finalised in my firstpost.So feel free to comment on those.
I can check what you have. I have time after my day job (product design; company has factory in China) and am more then willing to help with what I can.
For debug, it is best to have at least 1 LED but more would be great (this way you indicate breakpoints easier using a morse code or binary method). Test points are essential especially if this device has not been fully verified before full production. In production it is useful to have so that you can automate the test using a "bed of nails" tester. Are you in the EVT, DVT, or PVT stage (engineering validation - design is being prototyped and initial kinks worked out; design validation - prototype works now checking to see if it works well with repeated testing (etc) and initial manufacturing issues are found/fixed; or production validation - testing the final manufacturability/production)?
I design programming and test fixtures for the products that I work on and can help with that as well. I am well versed in ASM and C - what code is complete for the MSP (if any)? What specific functions need to be added, etc?
For debug, it is best to have at least 1 LED but more would be great (this way you indicate breakpoints easier using a morse code or binary method). Test points are essential especially if this device has not been fully verified before full production. In production it is useful to have so that you can automate the test using a "bed of nails" tester. Are you in the EVT, DVT, or PVT stage (engineering validation - design is being prototyped and initial kinks worked out; design validation - prototype works now checking to see if it works well with repeated testing (etc) and initial manufacturing issues are found/fixed; or production validation - testing the final manufacturability/production)?
I design programming and test fixtures for the products that I work on and can help with that as well. I am well versed in ASM and C - what code is complete for the MSP (if any)? What specific functions need to be added, etc?
We're still during the initial design phase, currently dealing with the PCB. I don't think any µC code has been written so far.
I can check what you have. I have time after my day job (product design; company has factory in China) and am more then willing to help with what I can.
For debug, it is best to have at least 1 LED but more would be great (this way you indicate breakpoints easier using a morse code or binary method). Test points are essential especially if this device has not been fully verified before full production. In production it is useful to have so that you can automate the test using a "bed of nails" tester. Are you in the EVT, DVT, or PVT stage (engineering validation - design is being prototyped and initial kinks worked out; design validation - prototype works now checking to see if it works well with repeated testing (etc) and initial manufacturing issues are found/fixed; or production validation - testing the final manufacturability/production)?
I design programming and test fixtures for the products that I work on and can help with that as well. I am well versed in ASM and C - what code is complete for the MSP (if any)? What specific functions need to be added, etc?
For debug, it is best to have at least 1 LED but more would be great (this way you indicate breakpoints easier using a morse code or binary method). Test points are essential especially if this device has not been fully verified before full production. In production it is useful to have so that you can automate the test using a "bed of nails" tester. Are you in the EVT, DVT, or PVT stage (engineering validation - design is being prototyped and initial kinks worked out; design validation - prototype works now checking to see if it works well with repeated testing (etc) and initial manufacturing issues are found/fixed; or production validation - testing the final manufacturability/production)?
I design programming and test fixtures for the products that I work on and can help with that as well. I am well versed in ASM and C - what code is complete for the MSP (if any)? What specific functions need to be added, etc?
Is any more help needed to support this development? I am an electrical engineer with >8 years of embedded experience and have worked with USB, CPLDs, FPGAs, and a slew of microcontrollers (MSP430, PIC, ARM/LPC, etc). I also have >8 years of schematic/PCB design experience and have designed with BGA (I use Altium for my PCB designs). Let me know!
Your help is very welcome.
As li_gangyi already said you could check up on our design so far. Especially i would like you to give a comment on our current BUS system wich is crucial to the project.Eg the MSP430 would need your attention.
I dont know how much time you are abled or willing to invest into our development. But having someone with higher experience to backcheck the works and maybe even to come up wit an own layout (I also use Altium so i could look it up) would be a great help.
So i hope you to become one of our frequently active developers.
Is any more help needed to support this development? I am an electrical engineer with >8 years of embedded experience and have worked with USB, CPLDs, FPGAs, and a slew of microcontrollers (MSP430, PIC, ARM/LPC, etc). I also have >8 years of schematic/PCB design experience and have designed with BGA (I use Altium for my PCB designs). Let me know!
Would be nice to have an extra pair of eyes to check the work before we send it out for production, sure could use some layout optimization as well. Are you good with coding? We'd preferably want a little bit to code to run some tests on the fresh hardware that rolls out, I'd suppose you'd need to wait for more routing details to come up before you can do anything though.
Do you think adding 1-2 debug LEDs will be useful? Or maybe testpoints.
We haven't sorted out how best to share updates, I have done up the power supply section (at least the schematic).
Is any more help needed to support this development? I am an electrical engineer with >8 years of embedded experience and have worked with USB, CPLDs, FPGAs, and a slew of microcontrollers (MSP430, PIC, ARM/LPC, etc). I also have >8 years of schematic/PCB design experience and have designed with BGA (I use Altium for my PCB designs). Let me know!
[...]
@ Olaf.Mandel: how are you doing with your routing any changes so far ?
@ Olaf.Mandel: how are you doing with your routing any changes so far ?
Unfortunately, nothing yet. I hope to do more tomorrow. I missed your post that sets the min width and clearance: found it just now. pcbcart can also do 0.15mm(=6mil) each. If you reduce the pad diameter to 0.4mm, then 0.2mm(=8mil) wire thickness and 0.15mm(=6mil) clearance are possible. But if you use 0.5mm pads, you need to use 0.15mm(=6mil) for the wire thickness.
On a related topic: what is the correct layer setup string in Eagle? I can only do vias from all layers to the top. I also need vias from layer 2 to the bottom. So an "all layers to top and all layers to bottom" setting is needed.
The 8mil line width and line spacing are a problem, though: I cannot get an 8mil wire between two pads of the FPGAs: the clearance is too small. This problem can be solved by using more vias and routing everything on the other layers, but is is less than ideal.
Out of interest, is 6mil trace + 6mil space good enough? That's what Laen's PCB group order for hobbyists provides, and supposedly someone's done a PCB with this pitch of BGA on that service. Of course, the turnaround times on that are probably less than ideal, especially if you're not in the US.- What does pcbcart mean when they ask for the "Min. Annular Ring"? The width of the ring on one side ((D_via-D_hole)/2) or the sum of the width on both sides of the hole (D_via-D_hole)?
Thank you
for the tipps.
I ve routed the FPGA so far. Next is the MSP and capacitors.
@ li_ganyi i will not use vias under pins any more seems it also works without.
@ Olaf.Mandel: how are you doing with your routing any changes so far ?
for the tipps.
I ve routed the FPGA so far. Next is the MSP and capacitors.
@ li_ganyi i will not use vias under pins any more seems it also works without.
@ Olaf.Mandel: how are you doing with your routing any changes so far ?
[...]
One last thing : how do i tell eagle that certain parts (eg capacitors) are located on the backside of the board so it doesn't require me to rout those lane back to the top?
[...]
One last thing : how do i tell eagle that certain parts (eg capacitors) are located on the backside of the board so it doesn't require me to rout those lane back to the top?
[...]
MIRROR the part. You will notice the color for the pads changing. Make sure the bPlace, bOrigins, bNames, bValues layers are active.
O_Shovah, you want to use the mirror command to put a component on the backside.
Doing the power supply, do I just draw up the schematic so we can route later into the main board ? I'm having some fun creating the part library though LOL.
Vias directly under pads, I wouldn't recommend it, that hole, even if solder doesn't suck down into it, can create voids due to air migrating up.
Best to connect up the rest of the supply pins together in a criss cross net and via that centre point.
Vias directly under pads, I wouldn't recommend it, that hole, even if solder doesn't suck down into it, can create voids due to air migrating up.
Best to connect up the rest of the supply pins together in a criss cross net and via that centre point.
Thanks a lot people.
I am currently trying to rout it without vias under teh FPGA pins. Its tricky but it works. On the other hand i try using the minimum settings allowed by PCBcart wich are 4 mil for spacing and annular ring,
but that would increase the board costs from 39 $ to 63$ in my calculation.
Considering me as a newbe in eagle i'm afraid i will not be abled to contribute a complete layout very soon.I hope everyone else is bit more sucessfull.
One last thing : how do i tell eagle that certain parts (eg capacitors) are located on the backside of the board so it doesn't require me to rout those lane back to the top?
@li_gangyi: Please confirm if you take over the power supply part so we know who is doing what.
I am currently trying to rout it without vias under teh FPGA pins. Its tricky but it works. On the other hand i try using the minimum settings allowed by PCBcart wich are 4 mil for spacing and annular ring,
but that would increase the board costs from 39 $ to 63$ in my calculation.
Considering me as a newbe in eagle i'm afraid i will not be abled to contribute a complete layout very soon.I hope everyone else is bit more sucessfull.
One last thing : how do i tell eagle that certain parts (eg capacitors) are located on the backside of the board so it doesn't require me to rout those lane back to the top?
@li_gangyi: Please confirm if you take over the power supply part so we know who is doing what.
A DRC error in Eagle doesn't mean it won't let you do it. It's more of a warning. You can clear the errors by clicking "Approve." Still, the warning may have some merit as I've read that it can be very bad for reflow soldering to have a via under a pad. We should ask our reflow expert, li_gangyi, if he has an opinion on this.
[...]
But i think its inevitable to place vias directly under FPGA supply pins. There's just no space to do it otherwise.(i never had problems doing so in Altium, but hey its 4000 bucks a year so maybe thats a feature worth the buggy thing
)
[...]
But i think its inevitable to place vias directly under FPGA supply pins. There's just no space to do it otherwise.(i never had problems doing so in Altium, but hey its 4000 bucks a year so maybe thats a feature worth the buggy thing
) [...]
I am not su sure that you should be placing vias directly at the pad. The Xilinx UG393 certainly suggests puting the vias in the centre between four neighbouring pins. If that doesn't fit, your drill or annulus is too large. I think Xilinx actually argues against placing the via in the middle of your pad (they call that a "land"):
Quote
Due to manufacturing constraints of PTH technology, it is rarely
possible to place a via inside the area of the land. Instead, this technology uses a short
section of trace connecting to a surface pad.
possible to place a via inside the area of the land. Instead, this technology uses a short
section of trace connecting to a surface pad.
I thougt switching from Altium to eagle wouldn't be a big deal but i'm feeling like a school boy
I try to connect my GND pins of the FPGA to my GND layer ( LAYER 3) but it seems eagle doesn't allow me to place vias (between surface and Layer 3) directly under one GND pin.
It displays this overlap error everytime i try.
But i think its inevitable to place vias directly under FPGA supply pins. There's just no space to do it otherwise.(i never had problems doing so in Altium, but hey its 4000 bucks a year so maybe thats a feature worth the buggy thing)
I hope that describes my problem better.
I try to connect my GND pins of the FPGA to my GND layer ( LAYER 3) but it seems eagle doesn't allow me to place vias (between surface and Layer 3) directly under one GND pin.
It displays this overlap error everytime i try.
But i think its inevitable to place vias directly under FPGA supply pins. There's just no space to do it otherwise.(i never had problems doing so in Altium, but hey its 4000 bucks a year so maybe thats a feature worth the buggy thing
) I hope that describes my problem better.
One question in addition: is there any way to playe a connected via directly under a FPGA pin without violating any of eagles design rules.
i allways get "can't set via to layer Vcc on xx xx xx " when i try to rout a pin to the Vcc layer ? what do i do wrong
i allways get "can't set via to layer Vcc on xx xx xx " when i try to rout a pin to the Vcc layer ? what do i do wrong
Can you describe more what you are doing and what is happening? I'm guessing you have two problems? The first is that Eagle gives you a DRC "overlap" error, and the second is this other error? Or are they the same thing?
For the Dropbox folder, I suggest this organization scheme:
- Each person keeps a folder for their own "branch" of development. A person can also have multiple branches if they are working are different things.
- Later, we can create a "trunk" that is closer to the final design. We will have to be careful about checking this out so as not to overwrite someone's work right after they finished it.
- Create a parts library file for any new parts we create for this project. This can be accessed in Eagle using Library->Use, or with a ln -s to Eagle's lbr directory, or simply copied.
I don't have access yet, so if an organization scheme is already in place, feel free to ignore my suggestion.
Ok so we will have i2c out of this i m fine wit that.
concerning dropbox : you dont need to download and install anything, the web surface works just fine(never used anything else)
One question in addition: is there any way to playe a connected via directly under a FPGA pin without violating any of eagles design rules.
i allways get "can't set via to layer Vcc on xx xx xx " when i try to rout a pin to the Vcc layer ? what do i do wrong
concerning dropbox : you dont need to download and install anything, the web surface works just fine(never used anything else)
One question in addition: is there any way to playe a connected via directly under a FPGA pin without violating any of eagles design rules.
i allways get "can't set via to layer Vcc on xx xx xx " when i try to rout a pin to the Vcc layer ? what do i do wrong
Just to get an update.
Since dicussion almost cheased on this. Is it decied to use SPI I2C and USB on the bus or have there been any further ideas or objections.?
Since dicussion almost cheased on this. Is it decied to use SPI I2C and USB on the bus or have there been any further ideas or objections.?
I think we agreed to not use I2C for the connection to the FPGA because it eats too many resources compared to SPI. For the DIMM connector: we haven't finished discussing that, yet. The use case was reading out an EEPROM, but if we place an MCU on the DIMM, that is no longer an issue: the MCU can identify itself via any of the other busses. And you need dedicated busses or extra switchers on the backplane for I2C, so my feeling is to get rid of I2C altogether.
[...]
Where are we going to share future files ?
Do we use my dropbox or someones github?
Where are we going to share future files ?
Do we use my dropbox or someones github?
Sorry I didn't use your dropbox before. I didn't want to download an extra program for that, but I had git installed... My feeling is that for all programmers, using a version control system should be easy. The problems arise when you have binary files (like Eagle), as there it is not possible to easily detect what was changed. Many of the cool features of any version control software fail here. But you still have branches, webpages for direct file access (no software to download) and to forth.
For Dropbox: Should be easy enough so even Windows users can use it
(*ducks*). And there is a basic versioning control. I just cannot get "warm" with it.Currently, there are several independent designs. Once these start merging, the service to use will emerge by itself.
Jump to: