Author

Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 102. (Read 286370 times)

legendary
Activity: 1274
Merit: 1004
June 11, 2012, 12:39:58 PM
I really have no idea how i get the icarus bitstream (only 2 of 4 cores) to work with that piece of hardware.

Is there any step by step howto to get this baby hashing at the moment?

Thanks to yohan and his team, this board looks really professional!

Some more photos -> http://www.wuala.com/ebereon/Shared/bitcoin/

regards,
eb

I'd really like to know this also.

I'm getting 4 orange lights on the FPGAs and 1 red flashing light.

I assume I need to wait for a bitstream update or drivers?

When I tried it on Windows it just said no driver found and cgminer wouldn't detect it.

Tried it on my Raspberry Pi too, didn't detect it either.

Any help would be great!

Did you guys request the early dev boards? Also, do you have a jtag cable?
hero member
Activity: 481
Merit: 502
June 11, 2012, 12:35:18 PM
I really have no idea how i get the icarus bitstream (only 2 of 4 cores) to work with that piece of hardware.

Is there any step by step howto to get this baby hashing at the moment?

Thanks to yohan and his team, this board looks really professional!

Some more photos -> http://www.wuala.com/ebereon/Shared/bitcoin/

regards,
eb

I'd really like to know this also.

I'm getting 4 orange lights on the FPGAs and 1 red flashing light.

I assume I need to wait for a bitstream update or drivers?

When I tried it on Windows it just said no driver found and cgminer wouldn't detect it.

Tried it on my Raspberry Pi too, didn't detect it either.

Any help would be great!
hero member
Activity: 504
Merit: 500
June 11, 2012, 12:13:32 PM
Just to clarify we are currently working with an Icarus style design that we have rebuilt to accomodate the pinout mistake on the downstream port. We are currently playing with several versions to try and get performance improved. We are migrating to a version of this where the link actually goes through the controller allowing many different variations of what we might do.

We are looking at other possibilities as well,

Not sure if I have asked this here before but have you submited you pinout and specs to eldentyrell yet to see if he can get his bitstream running on these?

Just paid for my first one yesterday and it shipped out first thing this morning via express DHL. rock on!

cheers,
 Derek
sr. member
Activity: 462
Merit: 251
June 11, 2012, 11:49:44 AM
Just to clarify we are currently working with an Icarus style design that we have rebuilt to accomodate the pinout mistake on the downstream port. We are currently playing with several versions to try and get performance improved. We are migrating to a version of this where the link actually goes through the controller allowing many different variations of what we might do.

We are looking at other possibilities as well,
fpf
newbie
Activity: 20
Merit: 0
June 11, 2012, 09:15:22 AM
As I know there is no official bitstream available for that board.
But there are a few things you & others should know:

This board is arranged as a "double icarus"

What you need to know about icarus:

Over the USB uart the work will be sent to the primary uart of chip1 (B1 and D1) and than be forwarded over the secondary uart of chip1 (B22 and D22) to the primary uart of chip2  (B1 and D1)

Each Spartan chip does half of the range which is set over the dip switch connected to the chip
(by default all are "off" - you will have to switch position 2 of the dip switch to on - for one of the 2 chips, so that each of them got their own range)

The clock input for the icarus bitstream is 100 MHZ. (You will have to set that over some dip switches on the enterpoint board as I know, should be the one near to the CPLD)

Right now - the forwarding to the second FPGA of each pair does not work with the out of the box bitstream because they made a mistake so that the 2 inputs and the 2 outputs are connected together. The only fix for that would be a modified bitstream.

They use a FTDI quad uart chip - as I know the schematic for that board is not public. I assume 2 of those uarts are correctly connected to the first FPGA of each pair. Where the other 2 uarts are connected to is unknown right now. (Most likely all of those pins are forwarded over the CPLD... in this case there is another solution, you could connect each FPGA directly to an uart and use the original icarus bitstream) That they do only half the range - does not matter in terms of performance.

Phil
hero member
Activity: 686
Merit: 500
June 11, 2012, 08:35:22 AM
my one will arrive today (also germany). @ yohan can you give a feadback how we get icarus stream working or your basic one?
hero member
Activity: 896
Merit: 1000
June 11, 2012, 06:59:55 AM
Want !

Hope the multiple boards purchases will begin soon after these single board deliveries.
sr. member
Activity: 397
Merit: 500
June 11, 2012, 06:45:26 AM
Got my first board! Shipped on friday and arrived today in germany, that's really fast!

Nice packaging:


Running, but no work (no software, bitstream etc.):   Undecided


I really have no idea how i get the icarus bitstream (only 2 of 4 cores) to work with that piece of hardware.

Is there any step by step howto to get this baby hashing at the moment?

Thanks to yohan and his team, this board looks really professional!

Some more photos -> http://www.wuala.com/ebereon/Shared/bitcoin/

regards,
eb
hero member
Activity: 481
Merit: 502
June 11, 2012, 06:35:49 AM
Officially just received my board today Smiley

Can't wait to try it out when I get home!

Thanks to yohan and the rest of the team at Enterpoint!
sr. member
Activity: 462
Merit: 251
June 11, 2012, 05:21:51 AM
Orders will flow out every day unless we have shortage like the expected one for a couple days this week on heatsinks. A very large batch of batch of heatsinks should arrive Friday, fingers are crossed, and then we are back up and running pumping out boards.

We are running real test mining now on a low performance level. There will be some related relevant stuff going on the webpage probably today. It's going to take anything from a few days to a few weeks to get the bitstream up a decent performance level. I am sure there will be some bug clearing to do as well. Remember this is still very much in the development phase and we are now only on 45th calendar day since we started.

Now that the hardware manufacturing side is moving into a more steady state level we will have more tme to look at bitstreams and related items and we will start to fill in the gaps.

Yohan
sr. member
Activity: 466
Merit: 250
June 11, 2012, 12:38:33 AM
Just to clarify, at this time, the boards are not able to do any mining yet correct?

Secondly, when will the second shipment occur for preorders?  Thanks!

There is really no point for me to even answer this because yohan knows better and he's so active here Smiley

But I'll try
Cairnsmore1 can mine with Icarus bitsream using only 2/4 cores. It can also mine with Enterpoint's own bitstream using all the cores. Enterpoint's bitstream is still under development. Right now the hashing speed isn't worth mentioning.
sr. member
Activity: 297
Merit: 250
June 11, 2012, 12:24:03 AM
Just to clarify, at this time, the boards are not able to do any mining yet correct?

Secondly, when will the second shipment occur for preorders?  Thanks!
sr. member
Activity: 462
Merit: 251
June 10, 2012, 10:54:53 AM
Ok not a total answer but we have sorted out pricing for a couple of the stacking items:

Item1 - Pack of 4 x 75mm stacking pillars - GBP £4 / USD $6.40 / 5.20€ + vat (if applies) - order code CAIRNSMORE1-STACK-75MM
Item2 - Up/Down ribbon cable - GBP £4 / USD $6.40 / 5.20€ + vat (if applies) - CAIRNSMORE1-UPDOWN

Item1 is already in stock. Item2 should be available in a couple of days.

Yohan
sr. member
Activity: 462
Merit: 251
June 09, 2012, 12:00:43 PM
At the moment we are roughly on schedule. Maybe a few days behind on the ideal. We have set our shipping schedule at something that we think is realistic. There will always be production issues that cause glitches and we have set the schedule to hopefully account for those. There is some possibility that we might do better that we have promised I won't ever guarantee that. It's our margin for when something unexpected happens as it usually does.
sr. member
Activity: 462
Merit: 251
June 09, 2012, 03:03:40 AM
The Icarus thing was just to give us a fast path to working tools and bitstreams. Unfortunately we made a mistake in the downstream pin numbers so the bitstream part didn't quite work. That's one of the downsides of doing the design in a very fast manner as we have. We could have done a respin of the PCB but that would have cost 2-3 weeks on the schedule and related costs so our engineering solution is to fix it at the bitstream level.

It's important to stress that the Icarus thing was only intended to be a temporary thing and the board can working in number of ways that is not Icarus. There are direct I/O from each FPGA to the controller and a lot of different logical structures can be implemented. That's where Cairnsmore1 gets interesting particularly when paired up with the up/down interface and we can build arrays that operate as one device. Some of this is ideas testing for what we might do in Cairnsmore2 and Cairnsmore3 and we will develop these ideas as we go along.

Equally we could have looked at the Ztex way. The pinout of Ztex was not checked but there is a reasonable chance we can use that with a rebuild and other work as well. That's probably not worth doing as it duplicates up other things we are working on. The main thing about Cairnsmore1 is that I think we have got a design that is capable of competing with any other current offering and maybe also doing a lot better.
hero member
Activity: 697
Merit: 500
June 08, 2012, 05:49:29 PM
What made you decide to go with Icarus bitstream over say, Ztex?

I believe they built this board like a pair of Icarus boards on one PCB. It sounds like 1 FPGA may communicate through another? Not certain.
hero member
Activity: 504
Merit: 500
June 08, 2012, 05:07:58 PM
What made you decide to go with Icarus bitstream over say, Ztex?
legendary
Activity: 3878
Merit: 1193
June 08, 2012, 04:59:58 PM
I think everything that didn't meet courier cutoff time today go keyed into Monday's courier pickup. Apologies to those who's unit didn't escape our cluches today.

The inital bitstream is just just an Icarus build just rebuilt to our pinout.

NET "osc_clk" LOC = "J1";
NET "RxD" LOC = "D1";
NET "TxD" LOC = "B1";
NET "extminer_txd<0>" LOC = "B21";
NET "extminer_rxd<0>" LOC = "B22";
NET "led[0]" LOC = "A17";
NET "led[1]" LOC = "B18";
NET "led[2]" LOC = "A18";
NET "led[3]" LOC = "A16";
NET "dip[0]" LOC = "A4";
NET "dip[1]" LOC = "D6";
NET "dip[2]" LOC = "C6";
NET "dip[3]" LOC = "C8";

The current controller build can supply 50MHz, 100MHz, 150MHz or 200Mhz depending on dip switch setting. Eventually will have something a little more advanced but that is it today. The in-built programmer features can update the controller as well as the main array. That gives us an on-going path to make improvements and for customers to apply them to their units.

The problem we keep having with Icarus builds is the intermittant working of the coms interface and that's assuming a build completes which often it doesn't. This is principally down to the way the coms is designed and can be improved and we might do that at some point depending on how our other approaches work out.


The open communication and honesty are sure a breath of fresh air compared to some other FPGA company. Keep up the good work.
sr. member
Activity: 476
Merit: 250
Keep it Simple. Every Bit Matters.
June 08, 2012, 03:34:31 PM
Thanks Yohan, so that overcomes the issues you spoke of a week back ( i think ) that came with going from dual to quad processors and the communication to the "back" two.
sr. member
Activity: 462
Merit: 251
June 08, 2012, 02:20:14 PM
I think everything that didn't meet courier cutoff time today go keyed into Monday's courier pickup. Apologies to those who's unit didn't escape our cluches today.

The inital bitstream is just just an Icarus build just rebuilt to our pinout.

NET "osc_clk" LOC = "J1";
NET "RxD" LOC = "D1";
NET "TxD" LOC = "B1";
NET "extminer_txd<0>" LOC = "B21";
NET "extminer_rxd<0>" LOC = "B22";
NET "led[0]" LOC = "A17";
NET "led[1]" LOC = "B18";
NET "led[2]" LOC = "A18";
NET "led[3]" LOC = "A16";
NET "dip[0]" LOC = "A4";
NET "dip[1]" LOC = "D6";
NET "dip[2]" LOC = "C6";
NET "dip[3]" LOC = "C8";

The current controller build can supply 50MHz, 100MHz, 150MHz or 200Mhz depending on dip switch setting. Eventually will have something a little more advanced but that is it today. The in-built programmer features can update the controller as well as the main array. That gives us an on-going path to make improvements and for customers to apply them to their units.

The problem we keep having with Icarus builds is the intermittant working of the coms interface and that's assuming a build completes which often it doesn't. This is principally down to the way the coms is designed and can be improved and we might do that at some point depending on how our other approaches work out.
Jump to: