Pages:
Author

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

sr. member
Activity: 397
Merit: 500
July 24, 2012, 01:33:14 AM
So B21 connects on FPGA1 D1 (RxD) and
B22 connects on FPGA1 B1 (TxD).

But you can also try the other way around Wink

EDIT: corrected some mixing things  Wink

Hmmm. I think RxD should connect to TxD and vice-versa though. Also, apparently I still really detest fpga_editor. Try:
http://www.makomk.com/~aidan/fpgaminer_cm1_160_test_b22_b21.bit
http://www.makomk.com/~aidan/fpgaminer_cm1_160_test_b21_b22.bit


The correct one is the "fpgaminer_cm1_160_test_b21_b22.bit" but it's not working as it should. When I flash it to FPGA0 and 1 then FPGA2 and 3 does not work anymore even if I let twin_test on FPGA3. I tested every comination but I don't get better results as with twin_test bitstream. It could be that the controller needs an update to get it work. Does the timing met with that bitstream?

The behavor is the same as with the shipping bitstream, FPGA2 and 3 have the orange led on to most of time, sometimes it turns off when a new job comes in, but turn on after ~3 seconds.

Anyway, thank you makmok for your effort.
eb
hero member
Activity: 686
Merit: 564
July 23, 2012, 08:27:39 PM
So B21 connects on FPGA1 D1 (RxD) and
B22 connects on FPGA1 B1 (TxD).

But you can also try the other way around Wink

EDIT: corrected some mixing things  Wink

Hmmm. I think RxD should connect to TxD and vice-versa though. Also, apparently I still really detest fpga_editor. Try:
http://www.makomk.com/~aidan/fpgaminer_cm1_160_test_b22_b21.bit
http://www.makomk.com/~aidan/fpgaminer_cm1_160_test_b21_b22.bit
sr. member
Activity: 397
Merit: 500
July 23, 2012, 07:39:54 PM
When I take a look to (with original icarus pinout):
Code:
######################################
# CONNECTIONS THAT HAVE DIFFERENT USES >> CONNECTS TO ON       FPGA0       FPGA1       FPGA2       FPGA3  (CT=CONTROLLER F0 = FPGA0 ETC.)
###################################### ICARUS:        
NET "LINK_1" LOC = "D1";             # NET "RxD" LOC = "D1"    CT"P83"     F0"B21"     F3"B21"     CT"P48"    
NET "LINK_2" LOC = "D2";             #                         CT"P88"     F0"D21"     F3"D21"     CT"P47"    
NET "LINK_3" LOC = "B1";             # NET "TxD" LOC = "B1"    CT"P87"     F0"B22"     F3"B22"     CT"P50"    
NET "LINK_4" LOC = "B2";             #                         CT"P84"     F0"D22"     F3"D22"     CT"P51"    
NET "LINK_5" LOC = "B22"; # NET "extminer_rxd<0>" LOC = "B22"  F1"B1"      CT"P101"    CT"P57"     F3"B1"    
NET "LINK_6" LOC = "D22"; # NET "extminer_txd<0>" LOC = "D22"  F1"B2"      CT"P103"    CT"P59"     F3"B2"    
NET "LINK_7" LOC = "B21";            #                         F1"D1"      CT"P99"     CT"P55"     F3"D1"    
NET "LINK_8" LOC = "D21";            #                         F1"D2"      CT"P105"    CT"P58"     F3"D2"      

But should be this:
Code:
######################################
# CONNECTIONS THAT HAVE DIFFERENT USES >> CONNECTS TO ON       FPGA0       FPGA1       FPGA2       FPGA3  (CT=CONTROLLER F0 = FPGA0 ETC.)
###################################### ICARUS:        
NET "LINK_1" LOC = "D1";             # NET "RxD" LOC = "D1"    CT"P83"     F0"B21"     F3"B21"     CT"P48"    
NET "LINK_2" LOC = "D2";             #                         CT"P88"     F0"D21"     F3"D21"     CT"P47"    
NET "LINK_3" LOC = "B1";             # NET "TxD" LOC = "B1"    CT"P87"     F0"B22"     F3"B22"     CT"P50"    
NET "LINK_4" LOC = "B2";             #                         CT"P84"     F0"D22"     F3"D22"     CT"P51"    
NET "LINK_5" LOC = "B22"; # NET "extminer_txd<0>" LOC = "B22"  F1"B1"      CT"P101"    CT"P57"     F3"B1"    
NET "LINK_6" LOC = "D22";            #                         F1"B2"      CT"P103"    CT"P59"     F3"B2"    
NET "LINK_7" LOC = "B21"; # NET "extminer_rxd<0>" LOC = "B21"  F1"D1"      CT"P99"     CT"P55"     F3"D1"    
NET "LINK_8" LOC = "D21";            #                         F1"D2"      CT"P105"    CT"P58"     F3"D2"      


So B21 connects on FPGA1 D1 (RxD) and
B22 connects on FPGA1 B1 (TxD).

But you can also try the other way around Wink

EDIT: corrected some mixing things  Wink
hero member
Activity: 686
Merit: 564
July 23, 2012, 07:34:02 PM
Whoops. Obviously I wasn't paying enough attention when looking at the UCF file.

can you change that with the fpga editor? i would test it if you have the new bitstream  Wink
In theory, hold on a second... Are you sure it should be that way around and not vice-versa? I reckon B21 as TxD and B22 as RxD from the UCF that Enterpoint have released?
sr. member
Activity: 397
Merit: 500
July 23, 2012, 07:20:24 PM
Whoops. Obviously I wasn't paying enough attention when looking at the UCF file.

can you change that with the fpga editor? i would test it if you have the new bitstream  Wink
hero member
Activity: 686
Merit: 564
July 23, 2012, 07:18:15 PM
makomk,

did you use the correct ucf settings?

as far as I know it should be:
Code:
# TTL level serial port: ja3 = rxd, ja2 = txd
NET "extminer_txd<0>" LOC = "B22";
NET "extminer_rxd<0>" LOC = "B21";

I saw in your git you still have the icarus pinout in you ucf file?
This bitstream is not working.

eb
Whoops. Obviously I wasn't paying enough attention when looking at the UCF file.
sr. member
Activity: 397
Merit: 500
July 23, 2012, 07:08:24 PM
Having followed the thread, I don't think Enterpoint released the information required to actually develop on it until about a week ago.

Unrelatedly, in theory this should be a working 160 MHz Icarus-style bitstream for the Cairnsmore1 board but I don't have an actual board to test it on: http://www.makomk.com/~aidan/fpgaminer_cm1_160_test.bit Since this is a proper Icarus-like bitstream, I think you'd want to set SW1 and SW6 according to the "Twin Build" diagram on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html and SW2-5 according to the "Initial Shipping Build" diagram. Treat as two Icarus boards in your miner. Note that I have no idea if this will work in practice; ngzhang's clock domain crossing logic looks rather hairy...
makomk,

did you use the correct ucf settings?

as far as I know it should be:
Code:
# TTL level serial port: ja3 = rxd, ja2 = txd
NET "extminer_txd<0>" LOC = "B22";
NET "extminer_rxd<0>" LOC = "B21";

I saw in your git you still have the icarus pinout in you ucf file?
This bitstream is not working.

eb
hero member
Activity: 686
Merit: 564
July 23, 2012, 06:44:14 PM
If you think this as an investment, then its terrible. How many ppl have got these board worked at intended speed? and if you did, for how long? I'm not a technical person but spending a month of tinkering is not acceptable. Maybe we should now know why BFL had a long waiting for their production.

As a potential customer, may i know exactly why you sell the boards without a working bitstream?

It was sold as a DEVELOPMENT BOARD.

If you had really been following the thread "very closely", you would know this.

Having followed the thread, I don't think Enterpoint released the information required to actually develop on it until about a week ago.

Unrelatedly, in theory this should be a working 160 MHz Icarus-style bitstream for the Cairnsmore1 board but I don't have an actual board to test it on: http://www.makomk.com/~aidan/fpgaminer_cm1_160_test.bit Since this is a proper Icarus-like bitstream, I think you'd want to set SW1 and SW6 according to the "Twin Build" diagram on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html and SW2-5 according to the "Initial Shipping Build" diagram. Treat as two Icarus boards in your miner. Note that I have no idea if this will work in practice; ngzhang's clock domain crossing logic looks rather hairy...
hero member
Activity: 481
Merit: 502
July 23, 2012, 05:16:05 PM
If you think this as an investment, then its terrible. How many ppl have got these board worked at intended speed? and if you did, for how long? I'm not a technical person but spending a month of tinkering is not acceptable. Maybe we should now know why BFL had a long waiting for their production.

As a potential customer, may i know exactly why you sell the boards without a working bitstream?

It was sold as a DEVELOPMENT BOARD.

If you had really been following the thread "very closely", you would know this.

BFL is completely different. They have a working bitstream already, and they take money upfront, without shipping anything for months after the quoted delivery time. If you'd rather buy from them, go ahead I say. Enjoy waiting months for your board for no reason whatsoever other than incompetence...
sr. member
Activity: 476
Merit: 250
Keep it Simple. Every Bit Matters.
July 23, 2012, 03:35:35 PM
I've been following this thread very closely as i'm interested in making a bulk order.

So far, it doesnt make any business sense now. If you think this as an investment, then its terrible. How many ppl have got these board worked at intended speed? and if you did, for how long? I'm not a technical person but spending a month of tinkering is not acceptable. Maybe we should now know why BFL had a long waiting for their production.

As a potential customer, may i know exactly why you sell the boards without a working bitstream?

I know it won't be easy to convience you otherwise of your view. How ever I will do my best to try.

Quick turn around, they are using the same chips and a similar design than what is already been done. However the made it a bit bigger, using 4 chips. Enterpoint are veterans in the market of making FPGA's, but relatively new to bitcoins, it was their first board. They made it from scratch quicker than any other manufactor, so I got to give them credit there. They had lots of people interested in seeing this as a development board, even if it meant us making the bitstream, so they went ahead with it.

A fully working bitstream was not the problem it should of been, it was a oops in the complication of combining 4 of these chips. It was a calculated risk and hasn't turned out that bad. If I had made orders with another manufacter, I know it would of cost me more, also I'd paid in advance for most of them (not all) and many of them I'd still be waiting for my product in hand. To me, I've come out better off for it. I don't like waiting 3+ months for an item, I certainly don't like waiting that long for an item I already bought. Enterpoint delivered what I expected.

Enterpoint (Yohan) and his team with the CM1, it allowed us to be mining on a development board, which we knew about in advance when we order at a lower than normal price. We saved money buying hardware and only paid when it was ready to ship.

As a programmer/developer this does not bother me, sure there are a few frustrating moments, that is part of being a programmer, you get little irratiable when debugging a problem. Many in this thread are also very technical people, that is the target whom jumped in early before a bitstream was fully ready. The FPGA market is filled with people just like me, so it does make business sense, it did work, he sold quiet a lot of them.

Average Joe, sure this might not be ideal for you, unless you prepared to start learning all what it takes to get a FPGA to work. It's not plug and play, anything more advance than a GUIminer is not, so it should come to no suprise that these won't be.
hero member
Activity: 648
Merit: 500
July 23, 2012, 03:05:43 PM
I've been following this thread very closely as i'm interested in making a bulk order.

So far, it doesnt make any business sense now. If you think this as an investment, then its terrible. How many ppl have got these board worked at intended speed? and if you did, for how long? I'm not a technical person but spending a month of tinkering is not acceptable. Maybe we should now know why BFL had a long waiting for their production.

As a potential customer, may i know exactly why you sell the boards without a working bitstream?

/troll
sr. member
Activity: 462
Merit: 250
July 23, 2012, 02:25:16 PM
I've been following this thread very closely as i'm interested in making a bulk order.

So far, it doesnt make any business sense now. If you think this as an investment, then its terrible. How many ppl have got these board worked at intended speed? and if you did, for how long? I'm not a technical person but spending a month of tinkering is not acceptable. Maybe we should now know why BFL had a long waiting for their production.

As a potential customer, may i know exactly why you sell the boards without a working bitstream?
hm
member
Activity: 107
Merit: 10
July 23, 2012, 11:30:16 AM
yesterday, I observed a startup issue with controller rev. 1.3:
I connected power, the controller led did blink as usual, but none of the fpga leds did light up.
I thought "there must be something wrong" and just reconnected the ac adapter without further investigation of the situation.
since then, I re-powered the device between five and ten times without any startup problems.

of course, my instable hash rates didn't improve by any re-powering of the device... but now it's time to test a linux box .. it will surely be better than the 20MH/s I'm getting right now using t500/win7 laptop.
legendary
Activity: 1379
Merit: 1003
nec sine labore
July 23, 2012, 07:20:25 AM
Okay now I'm convinced there's something seriously wrong with my two Cairnsmore1 boards.

After trying again today to get them working at full speed, I was flashing Rev 1.2 onto both of my boards using SPIProg.exe, I turned the power off to the boards, then turned it back on. I noticed that one of my boards had different LEDs lit to the other board, even though they were using the exact same documented DIP switch settings

norulezapply,

this is a bug of revision 1.2, sometimes when starting up you get blue/red leds light up.

If you flash revision 1.3 this problem is fixed.

spiccioli.


Hmm.

The reason I was trying 1.2 was because I'm not getting stable or full hashrates with 1.3.

If it is just a bug with 1.2, how come the same thing is not happening with my 2nd board when I flash it with 1.2? :S

norulezapply,

I don't know, see this and following messages from yohan https://bitcointalk.org/index.php?topic=78239.msg1023229;topicseen#msg1023229

spiccioli.

hero member
Activity: 810
Merit: 1000
July 23, 2012, 06:36:09 AM
Does it work with multible units to?

Can't wait to test it  Cheesy

Undortunately I'm a one unit owner Smiley

Chris

2 unit owner here...happy to try it if all 4 FPGAs per board get hammering
newbie
Activity: 33
Merit: 0
July 23, 2012, 06:25:20 AM
Does it work with multible units to?

Can't wait to test it  Cheesy

Undortunately I'm a one unit owner Smiley

Chris
sr. member
Activity: 397
Merit: 500
July 23, 2012, 05:36:28 AM
Does it work with multible units to?

Can't wait to test it  Cheesy
newbie
Activity: 33
Merit: 0
July 23, 2012, 05:02:10 AM
Today I was able to get the Enterpoint cairnsmore to work with the tricone mining software without needing an isolated stand-alone cable, just the FTDI link.  The code is still early in function, and still suffers from some JTAG errors likely due to noise / reflections on the lines which will need better error handling.  I only performed several tests, but was easily able to get stable function with three rings at 100Mhz. (150 Mh/s).

I will keep you guys updated, I should have more time to work on it on Tuesday.

Here's some brief logs from submitted shares, it's fairly garbled from the ascii formatting for the colors.

Code:
[cairnsmore:1:0.1   ]   pool accepted share
...

nice one! But only with one fpga? What OS you use? If windows then please can you provide the patched urjtag prog.? The code of tml would be also nice.  Wink

All 4 FPGAs work, just a testing run post.  I'm doing it under linux, but it should work fine under Win32/Mac/Linux.  The code actually doesn't use urjtag, but just the modified tml code and FTDI driver. 

It should be much more useful once the JTAG issues are hammered out.

Chris
hero member
Activity: 481
Merit: 502
July 23, 2012, 04:05:24 AM
Okay now I'm convinced there's something seriously wrong with my two Cairnsmore1 boards.

After trying again today to get them working at full speed, I was flashing Rev 1.2 onto both of my boards using SPIProg.exe, I turned the power off to the boards, then turned it back on. I noticed that one of my boards had different LEDs lit to the other board, even though they were using the exact same documented DIP switch settings

norulezapply,

this is a bug of revision 1.2, sometimes when starting up you get blue/red leds light up.

If you flash revision 1.3 this problem is fixed.

spiccioli.


Hmm.

The reason I was trying 1.2 was because I'm not getting stable or full hashrates with 1.3.

If it is just a bug with 1.2, how come the same thing is not happening with my 2nd board when I flash it with 1.2? :S
sr. member
Activity: 397
Merit: 500
July 23, 2012, 02:52:51 AM
Today I was able to get the Enterpoint cairnsmore to work with the tricone mining software without needing an isolated stand-alone cable, just the FTDI link.  The code is still early in function, and still suffers from some JTAG errors likely due to noise / reflections on the lines which will need better error handling.  I only performed several tests, but was easily able to get stable function with three rings at 100Mhz. (150 Mh/s).

I will keep you guys updated, I should have more time to work on it on Tuesday.

Here's some brief logs from submitted shares, it's fairly garbled from the ascii formatting for the colors.

Code:
[cairnsmore:1:0.1   ]   pool accepted share
...

nice one! But only with one fpga? What OS you use? If windows then please can you provide the patched urjtag prog.? The code of tml would be also nice.  Wink
Pages:
Jump to: