makomk
|
|
July 23, 2012, 11:44:14 PM Last edit: July 24, 2012, 12:19:00 AM by makomk |
|
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...
|
Quad XC6SLX150 Board: 860 MHash/s or so. SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
|
|
|
ebereon
|
|
July 24, 2012, 12:08:24 AM |
|
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: # 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
|
|
|
|
makomk
|
|
July 24, 2012, 12:18:15 AM |
|
makomk, did you use the correct ucf settings? as far as I know it should be: # 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.
|
Quad XC6SLX150 Board: 860 MHash/s or so. SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
|
|
|
ebereon
|
|
July 24, 2012, 12:20:24 AM |
|
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
|
|
|
|
makomk
|
|
July 24, 2012, 12:34:02 AM |
|
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 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?
|
Quad XC6SLX150 Board: 860 MHash/s or so. SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
|
|
|
ebereon
|
|
July 24, 2012, 12:39:54 AM Last edit: July 24, 2012, 01:10:42 AM by ebereon |
|
When I take a look to (with original icarus pinout): ###################################### # 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: ###################################### # 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 EDIT: corrected some mixing things
|
|
|
|
|
ebereon
|
|
July 24, 2012, 06:33:14 AM Last edit: July 24, 2012, 07:44:41 AM by ebereon |
|
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
|
|
|
|
Cranky4u
|
|
July 24, 2012, 09:31:12 AM |
|
2 * C1 boards arrived in regional SE Australia less than a week after posting from UK. Great service from the Everpoint team.
The babies worked out of the box. Took a few hours to get my head around some initial set up issues but happily mining away.
Now I am just hanging out for an improved bitstream to really vamp these boards up. Anyone got any clues on ETAs?
|
|
|
|
makomk
|
|
July 24, 2012, 09:44:33 AM Last edit: July 24, 2012, 10:13:08 AM by makomk |
|
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.
Curious. According to the constraints file I have, FPGA0 and FPGA1 are a pair and FPGA2 and FPGA3 are also a pair, and because this is an Icarus-like bitstream both pairs should be totally independent of each other (you need to run a seperate miner on each). Also, the logic that forwards work from the first FPGA in the pair to the second is a straight wire with really lax timing requirements so I'm not sure how that could break either... Edit: Yeah, I suspect the controller is doing something interesting.
|
Quad XC6SLX150 Board: 860 MHash/s or so. SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
|
|
|
norulezapply
|
|
July 24, 2012, 09:59:47 AM |
|
2 * C1 boards arrived in regional SE Australia less than a week after posting from UK. Great service from the Everpoint team.
The babies worked out of the box. Took a few hours to get my head around some initial set up issues but happily mining away.
Now I am just hanging out for an improved bitstream to really vamp these boards up. Anyone got any clues on ETAs?
I am jealous! Spent ages tweaking my boards trying to get them functioning stable and at stated icarus hashrate and now they're just getting boxed back up to be replaced
|
|
|
|
ebereon
|
|
July 24, 2012, 01:36:13 PM |
|
Curious. According to the constraints file I have, FPGA0 and FPGA1 are a pair and FPGA2 and FPGA3 are also a pair, and because this is an Icarus-like bitstream both pairs should be totally independent of each other (you need to run a seperate miner on each). Also, the logic that forwards work from the first FPGA in the pair to the second is a straight wire with really lax timing requirements so I'm not sure how that could break either...
Edit: Yeah, I suspect the controller is doing something interesting.
I tested again with my best board which is running 200Mh/s bitstream in twin_test setting with 2.81U/m each (running 4 days), but the same here, your bitstream is running at FPGA0 and 1(~4U/m) but 2 and 3 is not working anymore, best is 0.6U/m. I think frequency is instable or problems with noise etc. So if anyone get a Bitstream done like you, it wont run propably. @yohan: Any news about the 175Mh/s bitstream from Glasswalker? Anything we can play with? eb
|
|
|
|
makomk
|
|
July 24, 2012, 03:28:46 PM |
|
I tested again with my best board which is running 200Mh/s bitstream in twin_test setting with 2.81U/m each (running 4 days), but the same here, your bitstream is running at FPGA0 and 1(~4U/m) but 2 and 3 is not working anymore, best is 0.6U/m. I think frequency is instable or problems with noise etc. So if anyone get a Bitstream done like you, it wont run propably. OK, that's really weird because this runs at the same input frequency at twin_test. You can try running http://www.makomk.com/~aidan/fpgaminer_cm1_160_test_ds.bit on FPGA0/3 and http://www.makomk.com/~aidan/fpgaminer_cm1_160_test_nods.bit on FPGA1/2 but it's a long shot - other than that I'm stumped as to what could be going on.
|
Quad XC6SLX150 Board: 860 MHash/s or so. SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
|
|
|
ebereon
|
|
July 24, 2012, 04:17:01 PM |
|
I tested again with my best board which is running 200Mh/s bitstream in twin_test setting with 2.81U/m each (running 4 days), but the same here, your bitstream is running at FPGA0 and 1(~4U/m) but 2 and 3 is not working anymore, best is 0.6U/m. I think frequency is instable or problems with noise etc. So if anyone get a Bitstream done like you, it wont run propably. OK, that's really weird because this runs at the same input frequency at twin_test. You can try running http://www.makomk.com/~aidan/fpgaminer_cm1_160_test_ds.bit on FPGA0/3 and http://www.makomk.com/~aidan/fpgaminer_cm1_160_test_nods.bit on FPGA1/2 but it's a long shot - other than that I'm stumped as to what could be going on. Same behavor, pair 0/1 is working U ~5 (53 shares/10min). Pair 3/2 orange led on 98% of the time, U ~0.1(1 share/10min). eb
|
|
|
|
makomk
|
|
July 24, 2012, 04:22:14 PM |
|
Same behavor, pair 0/1 is working U ~5 (53 shares/10min). Pair 3/2 orange led on 98% of the time, U ~0.1(1 share/10min).
eb
OK, that's just really really weird. I'm guessing 3/2 should work with those bitstreams if you load everything but FPGA1 and leave FPGA1 with no bitstream loaded on it?
|
Quad XC6SLX150 Board: 860 MHash/s or so. SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
|
|
|
ebereon
|
|
July 24, 2012, 04:25:49 PM Last edit: July 24, 2012, 05:14:54 PM by ebereon |
|
Same behavor, pair 0/1 is working U ~5 (53 shares/10min). Pair 3/2 orange led on 98% of the time, U ~0.1(1 share/10min).
eb
OK, that's just really really weird. I'm guessing 3/2 should work with those bitstreams if you load everything but FPGA1 and leave FPGA1 with no bitstream loaded on it? I will test some cominations now. EDIT: 10 minute test: fpga0: twin_test.bit (LED's off, red flashing on work, green flash and fades off on share found) fpga1: none fpga2: fpgaminer_cm1_160_test_nods.bit (orange LED 99% on) fpga3: fpgaminer_cm1_160_test_ds.bit (orange LED 99% on) = 3/2 not working ~0.5 U fpga0: fpgaminer_cm1_160_test_ds.bit (LED's off, red flashing on work, green flash and fades off on share found) fpga1: none fpga2: fpgaminer_cm1_160_test_nods.bit (orange LED 99% on) fpga3: fpgaminer_cm1_160_test_ds.bit (orange LED 99% on) = 3/2 not working ~0.4 U fpga0: fpgaminer_cm1_160_test_ds.bit (LED's off, red flashing on work, green flash and fades off on share found) fpga1: none fpga2: none fpga3: fpgaminer_cm1_160_test_ds.bit (LED's off, red flashing on work, green flash and fades off on share found) = combined U ~4.4, -------------------------------------------------------------------------------- [P]ool management [S]ettings [D]isplay options [Q]uit ICA 0: | 315.3/319.3/183.8Mh/s | A:26 R:0 HW:0 U:2.57/m ICA 1: | 316.3/339.3/127.3Mh/s | A:18 R:0 HW:0 U:1.78/m -------------------------------------------------------------------------------- Remember it's all on only 10 minutes (so U is not accurate), but we can see the difference. Something strange going on with pair 3/2 when the second fpga on each pair (1/2) running a bitstream. eb
|
|
|
|
ebereon
|
|
July 24, 2012, 05:36:13 PM |
|
One more test: fpga0: fpgaminer_cm1_160_test_ds.bit (LED's off, red flashing on work, green flash and fades off on share found) fpga1: fpgaminer_cm1_160_test_nods.bit (LED's off, red flashing on work, green flash and fades off on share found) fpga2: none fpga3: fpgaminer_cm1_160_test_ds.bit (orange LED ~80% on) combined U 5.2 -------------------------------------------------------------------------------- [P]ool management [S]ettings [D]isplay options [Q]uit ICA 0: | 319.2/326.2/306.9Mh/s | A:44 R:0 HW:0 U: 4.29/m ICA 1: | 315.1/332.8/ 69.8Mh/s | A:10 R:0 HW:0 U: 0.97/m -------------------------------------------------------------------------------- eb
|
|
|
|
ebereon
|
|
July 24, 2012, 05:41:16 PM |
|
for comparison: fpga0: 200M_beta.bit fpga1: none fpga2: none fpga3: 200M_beta.bit combined U 5.62 over 4 days. Thats the best performing board i have.
All tests done with this board. SN# 62-413.
eb
|
|
|
|
makomk
|
|
July 24, 2012, 06:00:35 PM |
|
OK, thanks! Think that pretty much covers everything. Something truely bizarre is going on here. Unless running http://www.makomk.com/~aidan/fpgaminer_cm1_160_test_nods_pullup.bit on FPGA1/2 and fpgaminer_cm1_160_test_ds.bit on 0/3 shows immediate improvement - and it's a long enough shot that I'm not sure it's even worth testing to be honest - I'm gonna say screw it, wait for Glasswalker's stuff.
|
Quad XC6SLX150 Board: 860 MHash/s or so. SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
|
|
|
ebereon
|
|
July 24, 2012, 06:19:49 PM |
|
OK, thanks! Think that pretty much covers everything. Something truely bizarre is going on here. Unless running http://www.makomk.com/~aidan/fpgaminer_cm1_160_test_nods_pullup.bit on FPGA1/2 and fpgaminer_cm1_160_test_ds.bit on 0/3 shows immediate improvement - and it's a long enough shot that I'm not sure it's even worth testing to be honest - I'm gonna say screw it, wait for Glasswalker's stuff. I will test it, but the link is not working :-/
|
|
|
|
|