Cairnsmore1 - Quad XC6SLX150 Board

[yohan]

If an ASIC is the answer we will consider it. However I have my doubts about the economic viabilty of an ASIC approach. As has been discussed elsewhere I would consider if the Bitcoin market will remain stable. Hardware costs are actually part of Bitcoin stability and if you get an ASIC at low cost I suspect instability and maybe collapse might be the result.

A lot of this depends whether there really is a proper ASIC, what technology it uses, and what BFL sell it at. I won't add to the debate about how they fund that. They may of course be going for a last big bang, make big money quick, approach where Bitcoin ends up being the casuality.

I would also not rule out that we could put together a serious challenge using FPGAs. Cairnsmore1 is our initial product and we have played very safe with the technology so that we could deliver on schedule. That was an engineering and management decision. It also doesn't mean we have showed our best techology yet. That's not to in any way suggest Cairnsmore1 isn't a good product. I am very happy with what we have done now on at 6 weeks into the project and it will be a good for the customers that use it.

I think for the moment we wait to see what BFL actual releases. There is definate an element of trying to spoil the market with lots of bluster about what they are bringing. Enterpoint won't enter into silly games like that and we will concentrate on actual designing and producing good products. When we are ready we will talk about what is coming. For the moment our main concentration is getting Cairnsmore1 to customers as the best solution today and the team are working hard to achieve that.

Yohan

[Lethos]

I think it is wise not to jump too quickly into ASIC. There is a lot on the horizon that could effect the market for it.
Also ASIC are notoriously expensive and a big investment, for both the end-user and manufacter, can't blame them for not wanting to jump into it without seeing the success of their first product. Which is quickly looking like one of the best FPGA boards on the market at the moment.

Btw Yohan, I'm tempted to jump into learning a HDL to create a bitsteam, or improve one, any recommendation on where to start?
Most of my programming experience is in C, C++, C#, PHP, etc. Is the Spartan-6 partial to a specific HDL?
I like the look of Verilog, seems a bit better imho than VHDL (Both popular choices apparently).
Also with it's appearance being "C-like" I think I'll pick it up quickly.

[pieppiep]

I think it is wise not to jump too quickly into ASIC. There is a lot on the horizon that could effect the market for it.
Also ASIC are notoriously expensive and a big investment, for both the end-user and manufacter, can't blame them for not wanting to jump into it without seeing the success of their first product. Which is quickly looking like one of the best FPGA boards on the market at the moment.

Btw Yohan, I'm tempted to jump into learning a HDL to create a bitsteam, or improve one, any recommendation on where to start?
Most of my programming experience is in C, C++, C#, PHP, etc. Is the Spartan-6 partial to a specific HDL?
I like the look of Verilog, seems a bit better imho than VHDL (Both popular choices apparently).
Also with it's appearance being "C-like" I think I'll pick it up quickly.

I've done part of this http://hackaday.com/2011/12/30/so-you-wanna-learn-fpgas/
Must make more time free to do more, but at the moment diablo 3 is so much fun

[Lethos]

I think it is wise not to jump too quickly into ASIC. There is a lot on the horizon that could effect the market for it.
Also ASIC are notoriously expensive and a big investment, for both the end-user and manufacter, can't blame them for not wanting to jump into it without seeing the success of their first product. Which is quickly looking like one of the best FPGA boards on the market at the moment.

Btw Yohan, I'm tempted to jump into learning a HDL to create a bitsteam, or improve one, any recommendation on where to start?
Most of my programming experience is in C, C++, C#, PHP, etc. Is the Spartan-6 partial to a specific HDL?
I like the look of Verilog, seems a bit better imho than VHDL (Both popular choices apparently).
Also with it's appearance being "C-like" I think I'll pick it up quickly.

I've done part of this http://hackaday.com/2011/12/30/so-you-wanna-learn-fpgas/
Must make more time free to do more, but at the moment diablo 3 is so much fun

Thanks so he prefers VHDL. Interesting, guess I'll keep reading to find out why.

[norulezapply]

Yohan,

Any thoughts on using the newly released http://www.tricone-mining.com bitstream in the future?

(I understand that currently the most important priority is just getting the basics working first but thought I'd flag it up for you as something to look at)

It can apparently reach 315Mh/s - typical is around 270Mh/s (which is incredibly impressive). It uses a signcryption commission system, which equates to donating ~5% of the chips hashrate to tricone-mining, but the bitstream itself is free.

Regards

[yohan]

It's an interesting business model and it will suit a lot of people. I don't have a problem with that approach. someone has done some work and they get rewarded for it. We do think these hashing rates can be achieved if not more in a Spartan-6. We will have a look at this although maybe not for next week or two while we are smoothing out the assembly line.

On languages both VHDL and Verilog have similarities and relationships to C. VHDL probably is now the closest although the more advanced System Verilog is in there too. VHDL tends to have a bigger base in Europe and in the FPGA community. Verilog is strong in the US and in ASIC teams. We work with both but strongly biased to VHDL which is 80-90% of what we do. Things like "types" and "overloading" are used in VHDL and a very familiar concept to a C programmer. C programmers tend to have most difficulty dealing with the parallelism. It's a bit different handling 10000 things happening on a clock edge to 1 thing happeing in most CPUs.

[norulezapply]

Any updates on the status of built-in USB programming and the packaging situation yet?

Regards

PS good to see you're looking at possible bitstream enhancements for future

[Lethos]

On languages both VHDL and Verilog have similarities and relationships to C. VHDL probably is now the closest although the more advanced System Verilog is in there too. VHDL tends to have a bigger base in Europe and in the FPGA community. Verilog is strong in the US and in ASIC teams. We work with both but strongly biased to VHDL which is 80-90% of what we do. Things like "types" and "overloading" are used in VHDL and a very familiar concept to a C programmer. C programmers tend to have most difficulty dealing with the parallelism. It's a bit different handling 10000 things happening on a clock edge to 1 thing happeing in most CPUs.

Thanks for your insight into VHDL.
My initial look into VHDL vs Verilog was just a quick over view of example code and it looked quiet simple to pick up, maybe I too quickly judged VHDL.
If over the next few days I feel confident I understand what I'm doing I'll be asking to add a programming cable to my order, since It's my understand it is needed to reprogram these.
I have a background in both game engine development and commercial programming in C based languages. I've done it both as a hobby and for a job.
At least if I learn how to program these, I can have fun with them, rather than just make a bit of money.
You never know, if I get good at it, I can release them for the good of the community.

[Bitinvestor]

Its all part of the plan you people around here have proven your willingness to give them your money months in advance of delivery already, free product development financing every businesses dream not to mention the already locked in profit on them boxes as well doing it that way.

This is what amazes me as well. Just look at the GLBSE: the scammiest "companies" get the most Bitcoins thrown at them.

[dirtycat]

The Cairnsmore1 went from an idea to a unit in the wild..in what...40 or so days?

How long did BFL take to get that first unit out the door after the initial announcement?

If Enterpoint announced plans to bring an ASIC to the game a lot of folks would be pre-ordering/investing with Enterpoint over BFL.  Even with BFL's huge head start Enterpoint would almost certainly make to market first.

ya but these things dont mine... YET.

[2112]

I'm tempted to jump into learning a HDL to create a bitsteam, or improve one, any recommendation on where to start?

The language choice doesn't really matter. This project is so simple conceptually that the normal reasons for chosing the language are immaterial. This project stresses later stages of the design flow. Your experience with classical sequential programming languages is probably even counterproductive. What really helps is understanding the basics of logic design: combinatorial and sequential logic, flip-flops, etc. as well as any previous experience with declarative or parallel programming languages.

Most of the time you will spend researching various ways of transforming your program to convince the toolchain to accept your idea of how the design should be laid out. If you use Xilinx ISE as your toolchain then be aware of the following:

1) dense LX150 design will require more than 4GB of RAM during the later stages of the workflow, make sure that your machine has at least 8GB and the OS is 64-bit.
2) Xilinx changed the toolchain front-ends (both for Verilog & VHDL) with their "-6" FPGA families. When using tutorials prepared around older Xilinx FPGA families you may experience problems related to the corner-case differences in the HDL implementations.
3) even very small designs on a large chip take comparatively long time to compile. By the time the toolchain reads the floorplan and pinout of the LX150 chip the whole workflow on the LX9 chip will be done. Therefore for the beginners I recommend obtaining $98 Avnet Spartan-6 LX9 kit. If you start with a full LX150 design, especially the unrolled one, you will experience annoyingly long workflow iteration times, in the order of hour or two.

FPGA design is like playing tetris, chess and contract bridge all on the same board that is rectangular, not square.

[rjk]

3) even very small designs on a large chip take comparatively long time to compile. By the time the toolchain reads the floorplan and pinout of the LX150 chip the whole workflow on the LX9 chip will be done. Therefore for the beginners I recommend obtaining $98 Avnet Spartan-6 LX9 kit. If you start with a full LX150 design, especially unrolled one, you will experience annoyingly long workflow iteration times, in the order of hour or two.

FPGA design is like playing tetris, chess and contract bridge all on the same board that is rectangular, not square.

I find this interesting, because there is always a way to speed anything up, depending on where the bottleneck is. I've heard that it is strictly RAM dependent, so does this mean that with a low end processor and a low end hard drive, but 1TB of RAM it would be fast? If not, what combination of components relate to the speed loss? It seems to me that they way to speed it up would be to use a very fast processor, very fast RAM, and lots of RAM - more than 64GB to start with.

[2112]

If not, what combination of components relate to the speed loss? It seems to me that they way to speed it up would be to use a very fast processor, very fast RAM, and lots of RAM - more than 64GB to start with.

I'm sorry I probably wasn't clear enough.

The classic programming language compiler has the CPU architecture stored in the back end and it is always the same no matter whether you compile short or long program: in the end the RAM is linear.

The HDL programming language compiler also has to have the FPGA architecture stored in the back end. But unlike RAM the FPGA is not linear, it isn't even rectangular. Remember reading the complaints of eldentyrell and bitfury that the LX-150 has some things missing in the middle of the chip where it has the global clock buffer? Well the back-end of the design compiler (place and route) has to read in the detailed chip resource layout: SLICEs, BRAMs, DSPs (all those are explicitly documented) as well as undocumented switches and routing resources. Not only it has to read in all that data, in the place and route stage it has to explicitly fit the design into the floorplan. Even if the toolchain is all running from SSD disk it will still have to do those tasks. And those tasks aren't linear, the slowdown from LX9 to LX150 will not be 150/9, it will be noticeably more.

[Lethos]

I'm tempted to jump into learning a HDL to create a bitsteam, or improve one, any recommendation on where to start?

The language choice doesn't really matter. This project is so simple conceptually that the normal reasons for chosing the language are immaterial. This project stresses later stages of the design flow. Your experience with classical sequential programming languages is probably even counterproductive. What really helps is understanding the basics of logic design: combinatorial and sequential logic, flip-flops, etc. as well as any previous experience with declarative or parallel programming languages.

Most of the time you will spend researching various ways of transforming your program to convince the toolchain to accept your idea of how the design should be laid out. If you use Xilinx ISE as your toolchain then be aware of the following:

1) dense LX150 design will require more than 4GB of RAM during the later stages of the workflow, make sure that your machine has at least 8GB and the OS is 64-bit.
2) Xilinx changed the toolchain front-ends (both for Verilog & VHDL) with their "-6" FPGA families. When using tutorials prepared around older Xilinx FPGA families you may experience problems related to the corner-case differences in the HDL implementations.
3) even very small designs on a large chip take comparatively long time to compile. By the time the toolchain reads the floorplan and pinout of the LX150 chip the whole workflow on the LX9 chip will be done. Therefore for the beginners I recommend obtaining $98 Avnet Spartan-6 LX9 kit. If you start with a full LX150 design, especially unrolled one, you will experience annoyingly long workflow iteration times, in the order of hour or two.

FPGA design is like playing tetris, chess and contract bridge all on the same board that is rectangular, not square.

Picking a language was just a way of peaking interest amongst those more experienced than myself It worked.
Optimisation is something I'm known for in my software, so tweaking code to run a fraction of a ns faster per clock is something I will be petty enough to do to improve the bitstream.

1) Not a problem, I have that.
2) Noted.
3) Something to consider. I am patient, so if it takes a while to compile that doesn't bother me. Not like I don't have other projects. I will however see if I can find a uk seller doing something like that.

[rjk]

If not, what combination of components relate to the speed loss? It seems to me that they way to speed it up would be to use a very fast processor, very fast RAM, and lots of RAM - more than 64GB to start with.

I'm sorry I probably wasn't clear enough.

The classic programming language compiler has the CPU architecture stored in the back end and it is always the same no matter whether you compile short or long program: in the end the RAM is linear.

The HDL programming language compiler also has to have the FPGA architecture stored in the back end. But unlike RAM the FPGA is not linear, it isn't even rectangular. Remember reading the complaints of eldentyrell and bitfury that the LX-150 has some things missing in the middle of the chip where it has the global clock buffer? Well the back-end of the design compiler (place and route) has to read in the detailed chip resource layout: SLICEs, BRAMs, DSPs (all those are explicitly documented) as well as undocumented switches and routing resources. Not only it has to read in all that data, in the place and route stage it has to explicitly fit the design into the floorplan. Even if the toolchain is all running from SSD disk it will still have to do those tasks. And those tasks aren't linear, the slowdown from LX9 to LX150 will not be 150/9, it will be noticeably more.

Right, but I'm still not sure from that description where the bottleneck is - like I said, there are always ways to speed anything up, even if the speed difference isn't a lot. For instance, if the CPU doesn't actually relate to how long such a design placement takes, you could save money there and spend it somewhere else - for instance, on a 24-drive SSD array.

[Lethos]

I think it is wise not to jump too quickly into ASIC. There is a lot on the horizon that could effect the market for it.
Also ASIC are notoriously expensive and a big investment, for both the end-user and manufacter, can't blame them for not wanting to jump into it without seeing the success of their first product. Which is quickly looking like one of the best FPGA boards on the market at the moment.

Btw Yohan, I'm tempted to jump into learning a HDL to create a bitsteam, or improve one, any recommendation on where to start?
Most of my programming experience is in C, C++, C#, PHP, etc. Is the Spartan-6 partial to a specific HDL?
I like the look of Verilog, seems a bit better imho than VHDL (Both popular choices apparently).
Also with it's appearance being "C-like" I think I'll pick it up quickly.

I've done part of this http://hackaday.com/2011/12/30/so-you-wanna-learn-fpgas/
Must make more time free to do more, but at the moment diablo 3 is so much fun

It was a good read, however since the article focused on how it's done on a spartan 3, I'm off to find one on the spartan 6 for see how things changed between the two.

[2112]

Right, but I'm still not sure from that description where the bottleneck is - like I said, there are always ways to speed anything up, even if the speed difference isn't a lot. For instance, if the CPU doesn't actually relate to how long such a design placement takes, you could save money there and spend it somewhere else - for instance, on a 24-drive SSD array.

My best guess for the bottleneck in compiling small designs into large FPGAs is in decrypting the floorplan files. Xilinx ISE has separate files for each chip in each package. All this information is a trade secret and serious effort was spent to encrypt and obfuscate it. So my guess for the best Xilinx FPGA design workstation would be the fastest server-grade CPU with a huge cache and lowest-latency RAM. Number of cores is immaterial as most of the workflow is single-threaded.

[rampone]

One humble question to yohan: are the "spaceships" 1.1 on their way? or will shipping take until wednesday?

What about the "optional" stacking kit. How much does it cost extra?

And forgot to say: Awesome engineering speed so far. TY

[zefir]

Hi yohan,

while eagerly looking forward to get my Quads delivered, I started preparing the setup to prevent any additional delays after receipt - to be able to unpack the boards and start mining immediately 

Assuming each board will consume less than 40W, I prepared two 1.2kW PSUs and need some additional information to prepare power and communication cabling. If it was not already answered somewhere else, could you please respond to the following:

1) Stacking Kit
Does the stacking kit you are going to offer (or at least plan to) include cables to connect the up/down interfaces for daisy chaining? If so, does this include USB chaining and/or power supply?

2) Communication
Does the claimed 'Supports up and down interfaces for data flow within board stacking' imply that interconnected stacked boards need to be attached to only one USB port and will be detected as an array of tty interfaces (this is to know how many USB hubs I need to prepare)?

3) Power Supply
Are all the power connectors directly connected? What I would like to do is: stack 5 boards, connect the middle one via PCIe6 to PSU and connect all Molex connectors. Would this be doable to power all boards?


Thanks in advance (not to mention: kudos for keeping your promise)

[DILLIGAF]

3) Power Supply
Are all the power connectors directly connected? What I would like to do is: stack 5 boards, connect the middle one via PCIe6 to PSU and connect all Molex connectors. Would this be doable to power all boards?

I have been thinking the same idea five per checking into the power supplies it seems you would be better going the other way one on the molex and four on pci-e six pin. The six pin provides I believe it is a dedicated 75w to the cable whereas the molex are shared on a cable that provides under the 75w per cable so there is chance you may overload those cables with a couple of boards on it.