Topic: Modular FPGA Miner Hardware Design Development - page 16. (Read 119276 times)
Does anyone have any data on the LX150 hash power in the real world? I've been hearing wild figures on the forum and IRC from 60mhash/s to 200mhash/s? I was told yesterday that in ISE he (irc user) was playing around and was pretty easily able to obtain an estimated >150mhash/s on the LX150. In another thread someone is saying it would take 9,000$ to make a spartan 6 LX150 board with 1.2ghash/s. Yet I'm finding processor online in bulk for less than 160$ a pop. Which information is real, which is not?
I was wondering if anyone had a dev board they were playing with? If so, what model? The only one I was able to find online was a monster 995$ 4x pci-e card with a ton more features than are needed. It also happened to be out of stock.
I must say: I wasn't interested in joining or starting a company (no clue how my employer would feel about that!). For a software project, this is strictly not necessary, just define a license for what you publish and keep track of who owns copyright to what.
I see the point for a hardware development: the prototypes are expensive, and you only get good prices if you pool many orders. For my own part: I just want to get a workable design and possibly not have to sell organs to pay for a small number of boards
For the purposes of the development effort, these are two separate issues, though: we can assign a license to the designs without having to go to the hassle of incorporating ourselves. The prototypes may even be doable by enthusiasts with deeper pockets than the rest. The mass order requires a company. That needs not be founded by us, though: Seeed Studio is for this sort of thing.
As for license preferences: I would be happy with many of the OSI approved licenses, but GPLv3+ or maybe GPLv2+ would be my preferences.
I see the point for a hardware development: the prototypes are expensive, and you only get good prices if you pool many orders. For my own part: I just want to get a workable design and possibly not have to sell organs to pay for a small number of boards
For the purposes of the development effort, these are two separate issues, though: we can assign a license to the designs without having to go to the hassle of incorporating ourselves. The prototypes may even be doable by enthusiasts with deeper pockets than the rest. The mass order requires a company. That needs not be founded by us, though: Seeed Studio is for this sort of thing.
As for license preferences: I would be happy with many of the OSI approved licenses, but GPLv3+ or maybe GPLv2+ would be my preferences.
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.
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 ?
GNU GPL is the simplest and most convenient way to go about protecting this collaborative effort.
On the copyright matter
You are pointing out an important issue i already had some headake about.
I certainly will not claim ownership for the projects copyright all alone.This would be angainst any principles i had in mind when starting this project.
I did some research on this matter and now strongly consider founding a company with all those of you contributing to this project.All rights for hardware and software would be confered to this entity giving equally shared rights to each participator.I Considered the german legal company form of the "Unternehmergesellschaft(haftungsbeschränkt)". Wich transferes in english to literally "entrepreneur association (Limited private liability)".
It is similar to the british limited but has some advantages in my eyes.
This way of organising our legal issues would offer the following advantges :
There also would be some downturns :
I therefore would state that this way is the most secure in a legal way. I asume it is easier to control this as it would be bound to national law.
So please give your comment on that.
I hate to draw the attention away from technical the discussion, but I think we are heaping up a lot of future legal hassle at the moment:
IANAL, but as far as I know all creative work is automatically copyrighted to the creator. Publishing it (even on something like dropbox) doesn't change that at all. So if we continue like we currently do, in the end we have a design that may contain key components we don't have permission to use! The FOSS community has a lot of experience with this sort of cr*p, so why don't we take a page from them? Our options at the moment are:
My own feeling is that this is too cool to just "throw away" by putting it into the public domain. On the other hand, no offence O_Shovah, but I would not want to assign copyright to you. My personal preference is to use a GPL license: there are some issues with applying that to hardware designs, but they seem to be minor. And it works perfectly for the software and firmware.
I am not saying that I will stop working on the project if one of the first options is chosen or if it is a different license. But I think we need to agree on this quickly, before even more people and more copyright holders enter here.
IANAL, but as far as I know all creative work is automatically copyrighted to the creator. Publishing it (even on something like dropbox) doesn't change that at all. So if we continue like we currently do, in the end we have a design that may contain key components we don't have permission to use! The FOSS community has a lot of experience with this sort of cr*p, so why don't we take a page from them? Our options at the moment are:
- We put everything into the public domain. Everyone with write access to the dropbox folder has to agree to that and it needs to be stated in a prominently visible file on dropbox.
- We transfer copyright to a single entity (say: O_Shovah's real identity). Again: everyone with write access has to agree. Then O_Shovah has to set a license under which we all can use his copyrighted work, preferably stated in a prominently visible file. He can change his mind, later.
- We each explicitly assign copyright to our work (an AUTHORS file seems to work) and we all agree on a license that applies to the work (LICENSE file).
My own feeling is that this is too cool to just "throw away" by putting it into the public domain. On the other hand, no offence O_Shovah, but I would not want to assign copyright to you. My personal preference is to use a GPL license: there are some issues with applying that to hardware designs, but they seem to be minor. And it works perfectly for the software and firmware.
I am not saying that I will stop working on the project if one of the first options is chosen or if it is a different license. But I think we need to agree on this quickly, before even more people and more copyright holders enter here.
You are pointing out an important issue i already had some headake about.
I certainly will not claim ownership for the projects copyright all alone.This would be angainst any principles i had in mind when starting this project.
I did some research on this matter and now strongly consider founding a company with all those of you contributing to this project.All rights for hardware and software would be confered to this entity giving equally shared rights to each participator.I Considered the german legal company form of the "Unternehmergesellschaft(haftungsbeschränkt)". Wich transferes in english to literally "entrepreneur association (Limited private liability)".
It is similar to the british limited but has some advantages in my eyes.
This way of organising our legal issues would offer the following advantges :
- All rights would be gathered under one central entity
- The conferation of the individual copyrights to the company would save us problems
in case someday somebody doesn't want to dedicate his copyright to the project anymore - As each member of the company shares the same amount rights, a democratic deciscion on any matters is possible.
- We may use to a combination of publicating the project as a noncommercial license open for anybody to build for himself and
also offering these minersystem in a commercial way to anybody not willing or abled to produce this board himself. - Nobody would be privat financial liable to any actions of the company and it needs 1€ starting capital
There also would be some downturns :
- As a official company we would have to provide all legal responsebilitys bound to that (guarantee on products,customer support,accounting)
- As such we will also have to pay taxes in case we make some profit
- There is a considerable amount of work needed for founding such a company in germany
I therefore would state that this way is the most secure in a legal way. I asume it is easier to control this as it would be bound to national law.
So please give your comment on that.
I think there is nothing in the dropbox so far that I would have a copyright on, so far I've only played an advisory role.
Once it comes to FPGA design and firmware this might change. I'd prefer a FOSS license (MIT, BSD, GPL, LGPL, ...) but would also agree on public domain, if you go for that for whatever reason. This also applies to the FPGA-related code that I have produced so far, especially the Modular Python Bitcoin Miner, or the changes to fpgaminer's code (available in his github repository).
Please note that releasing something into the public domain allows anyone to relicense it in whatever way he wants, including commercial licenses.
Once it comes to FPGA design and firmware this might change. I'd prefer a FOSS license (MIT, BSD, GPL, LGPL, ...) but would also agree on public domain, if you go for that for whatever reason. This also applies to the FPGA-related code that I have produced so far, especially the Modular Python Bitcoin Miner, or the changes to fpgaminer's code (available in his github repository).
Please note that releasing something into the public domain allows anyone to relicense it in whatever way he wants, including commercial licenses.
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.
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.
Go MIT and stick with the spirit of BitCoin. GPL is demonic.
"MIT" as in "MIT license"? Or "MIT spirit"? And do you have specific concerns with GPL and specific advantages you see for a different license? I must admit not having read the bitcoin manifesto (if any such thing exists).
Go MIT and stick with the spirit of BitCoin. GPL is demonic.
I was trying to figure out who did what to each file and when. I looked at the dropbox events view and was... underwhelmed. This is a hopeless clutter of unfiltered text. My questions:
Also: I saw the previous versions feature. Is it guaranteed that all previous versions are stored indefinitely? This might also be important later, so this must be reliable.
- Is this list guaranteed to remain available in completeness or is there a cutoff (say, everything older than 500 entries gets discarded)?
- Is there a better way to vie this, say contributions by a single person on all directories or everyone who contributed to a given file?
Also: I saw the previous versions feature. Is it guaranteed that all previous versions are stored indefinitely? This might also be important later, so this must be reliable.
I hate to draw the attention away from technical the discussion, but I think we are heaping up a lot of future legal hassle at the moment:
IANAL, but as far as I know all creative work is automatically copyrighted to the creator. Publishing it (even on something like dropbox) doesn't change that at all. So if we continue like we currently do, in the end we have a design that may contain key components we don't have permission to use! The FOSS community has a lot of experience with this sort of cr*p, so why don't we take a page from them? Our options at the moment are:
My own feeling is that this is too cool to just "throw away" by putting it into the public domain. On the other hand, no offence O_Shovah, but I would not want to assign copyright to you. My personal preference is to use a GPL license: there are some issues with applying that to hardware designs, but they seem to be minor. And it works perfectly for the software and firmware.
I am not saying that I will stop working on the project if one of the first options is chosen or if it is a different license. But I think we need to agree on this quickly, before even more people and more copyright holders enter here.
IANAL, but as far as I know all creative work is automatically copyrighted to the creator. Publishing it (even on something like dropbox) doesn't change that at all. So if we continue like we currently do, in the end we have a design that may contain key components we don't have permission to use! The FOSS community has a lot of experience with this sort of cr*p, so why don't we take a page from them? Our options at the moment are:
- We put everything into the public domain. Everyone with write access to the dropbox folder has to agree to that and it needs to be stated in a prominently visible file on dropbox.
- We transfer copyright to a single entity (say: O_Shovah's real identity). Again: everyone with write access has to agree. Then O_Shovah has to set a license under which we all can use his copyrighted work, preferably stated in a prominently visible file. He can change his mind, later.
- We each explicitly assign copyright to our work (an AUTHORS file seems to work) and we all agree on a license that applies to the work (LICENSE file).
My own feeling is that this is too cool to just "throw away" by putting it into the public domain. On the other hand, no offence O_Shovah, but I would not want to assign copyright to you. My personal preference is to use a GPL license: there are some issues with applying that to hardware designs, but they seem to be minor. And it works perfectly for the software and firmware.
I am not saying that I will stop working on the project if one of the first options is chosen or if it is a different license. But I think we need to agree on this quickly, before even more people and more copyright holders enter here.
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,
Really? The current still needs to go to the top layer and the pads. There the trace width is 0.3mm only! Admittedly, the traces are short (for VCCint at least). But wouldn't you want a bit more copper for these traces? And for GND, I had no choice but to use rather long traces around the centre of the FPGA.
VccINT is also on the backside, exposed to free air (instead of say in the middle), that really helps out alot on heat.
I mostly did that because for some manufacturers (not pcbcart, apparently) the outer layers can be thicker than the inner layers.
Ok so as i proposed before. May you do the first standalone version of the power supply ?
You said you had the necessary testing equipment so the performance and stability tests would certainly fit for you.
You said you had the necessary testing equipment so the performance and stability tests would certainly fit for you.
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'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.
Considering the high current on the Vint rail. Wich cooper thikness would you advise to keep losses and heating low ? 70um or more ?
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.
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.
I have just created and uploaded a further Block Diagramm that shows my idea of how work parts mostly autonom could be devided to serveral workgroups if desired.
As there would be:
- Power supply ( design, testing,optimisation,supply for the motherboard) i consider this a job for li_gangyi as he has already started on this and seems to have the nessecary equipment.
- Motherboard (Design, layout) fairly open to anyone maybe best for those not so firm on layouts in Eagle ( like me
)
- Bus System and MSP430 ( Design, Code programming) i my eyes best fit for, bahnfire, mamok and all of you with experience in programming an BUS systems
- FPGA I/O ( Design, prerouting) maybe for Olaf.Mandel and others interested in the FPGA
And after that step we start putting these single blocks together and in the end finalise a protoype PCB.
The names i gave a just suggestion originated from my impression who has wich expertise. Of course everyboda is free to choose the subject he or she likes.
Please give your comment.
So in the end again. We are still just 4 people in the Dropbox . So i ask everybody else interested in the Files to notify me their email adress so i may add them.
As there would be:
- Power supply ( design, testing,optimisation,supply for the motherboard) i consider this a job for li_gangyi as he has already started on this and seems to have the nessecary equipment.
- Motherboard (Design, layout) fairly open to anyone maybe best for those not so firm on layouts in Eagle ( like me
)- Bus System and MSP430 ( Design, Code programming) i my eyes best fit for, bahnfire, mamok and all of you with experience in programming an BUS systems
- FPGA I/O ( Design, prerouting) maybe for Olaf.Mandel and others interested in the FPGA
And after that step we start putting these single blocks together and in the end finalise a protoype PCB.
The names i gave a just suggestion originated from my impression who has wich expertise. Of course everyboda is free to choose the subject he or she likes.
Please give your comment.
So in the end again. We are still just 4 people in the Dropbox . So i ask everybody else interested in the Files to notify me their email adress so i may add them.
Just replaced the *.png and *.brd file: there were some unrouted signals left... If you already got the old version: get the new one.
Uploaded new FPGA section of board to dropbox.
Changes compared to last time:
Still to do:
Changes compared to last time:
- Changed all unused pins to GND, pull HSWAPEN high for floating pins during configuration
- Use 4 layers
- Added *.dru file for pcbcart service
- Assign one layer each for the different signals:
- 1: GND
- 2: VCCIO
- 15: VCCAUX
- 16: VCCINT
- Placed smallest caps on the backside
- Compactified the board: 83x28mm2
Still to do:
- Get rid of separate VCCAUX and VCCIO as suggested by li_gangyi?
- Are the buses ok like that (all wires on top of each other)?
- Check everything.
- Write a summary of the *.dru.
- Further compactify the resistors (are all needed?) and largest caps..
I just made a little Block Diagramm for the motherboard and stored it in the Box.
Jump to: