Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 55. (Read 286370 times)
I wrote another email to [email protected] . I guess we'll see further with an answer.
@rampone
Hope in the #bitminter on irc and i'll try to see if i can help you get your board working. No idea what issue you got but i'll try to help you if i can
Hope in the #bitminter on irc and i'll try to see if i can help you get your board working. No idea what issue you got but i'll try to help you if i can
only 2*50Mh/s bitstream working on my board so far. nuttin' else.(first cry from me for over a month in this thread
short reply:
fpga0: fpgaminer_cm1_160_test_ds.bit <- working
fpga1: fpgaminer_cm1_160_test_nods_pullup.bit <- working
fpga2: fpgaminer_cm1_160_test_nods_pullup.bit <- not working
fpga3: fpgaminer_cm1_160_test_ds.bit <- not working
fpga0: fpgaminer_cm1_160_test_ds.bit <- working
fpga1: fpgaminer_cm1_160_test_nods_pullup.bit <- working
fpga2: none
fpga3: fpgaminer_cm1_160_test_ds.bit <- not working
fpga0: fpgaminer_cm1_160_test_ds.bit <- working
fpga1: fpgaminer_cm1_160_test_nods_pullup.bit <- working
fpga2: fpgaminer_cm1_160_test_nods_pullup.bit <- not working (get no work -> nods have other pinout?)
fpga3: fpgaminer_cm1_160_test_nods_pullup.bit <- worked one time U ~1.6 LED's ok, next 5 attempts not working...
fpga0: fpgaminer_cm1_160_test_ds.bit <- working
fpga1: fpgaminer_cm1_160_test_nods_pullup.bit <- working
fpga2: none
fpga3: fpgaminer_cm1_160_test_nods_pullup.bit <- not working
eb
EDIT:
See bold
fpga0: fpgaminer_cm1_160_test_ds.bit <- working
fpga1: fpgaminer_cm1_160_test_nods_pullup.bit <- working
fpga2: fpgaminer_cm1_160_test_nods_pullup.bit <- not working
fpga3: fpgaminer_cm1_160_test_ds.bit <- not working
fpga0: fpgaminer_cm1_160_test_ds.bit <- working
fpga1: fpgaminer_cm1_160_test_nods_pullup.bit <- working
fpga2: none
fpga3: fpgaminer_cm1_160_test_ds.bit <- not working
fpga0: fpgaminer_cm1_160_test_ds.bit <- working
fpga1: fpgaminer_cm1_160_test_nods_pullup.bit <- working
fpga2: fpgaminer_cm1_160_test_nods_pullup.bit <- not working (get no work -> nods have other pinout?)
fpga3: fpgaminer_cm1_160_test_nods_pullup.bit <- worked one time U ~1.6 LED's ok, next 5 attempts not working...
fpga0: fpgaminer_cm1_160_test_ds.bit <- working
fpga1: fpgaminer_cm1_160_test_nods_pullup.bit <- working
fpga2: none
fpga3: fpgaminer_cm1_160_test_nods_pullup.bit <- not working
eb
EDIT:
See bold
http://s14.directupload.net/file/d/2961/xvi9i6lb_png.htm
like you see I have no stability issues, but only 1 fpga is running (second board the first I had sn 002 was broken)
cgminer 2.5.0, Win7 x64
like you see I have no stability issues, but only 1 fpga is running (second board the first I had sn 002 was broken)
cgminer 2.5.0, Win7 x64
Are the RX and TX lines on the top or bottom layer or otherwise reasonably accessible where a skilled person could swap them to get the normal Icarus bitstream running?
Makomk have swaped them in the bitstream we are testing at the moment. And to your idea, it's not possible, i think it's a 6 or 8 layer PCB.
Are the RX and TX lines on the top or bottom layer or otherwise reasonably accessible where a skilled person could swap them to get the normal Icarus bitstream running?
I will test it, but the link is not working :-/
Whoops, sorry. Fixed. 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 :-/
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.
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
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
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
eb
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
Code:
--------------------------------------------------------------------------------
[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
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?eb
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,
Code:
--------------------------------------------------------------------------------
[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
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? eb
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. So if anyone get a Bitstream done like you, it wont run propably.
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
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. So if anyone get a Bitstream done like you, it wont run propably.
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.
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
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?
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
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...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.
Edit: Yeah, I suspect the controller is doing something interesting.
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?
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?
Jump to: