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

Is this the sort of USB blaster cable you have?
http://www.suntekstore.co.uk/goods.php?id=14003019&utm_source=gbuk

Just to confirm.

I'm putting up a 2 btc bounty if anyone can help me program my cm1 controller with a usb blaster cable. I got the drivers for the cable and made a svf file in impact now I'm just trying to get a connection going with urjtag but not getting very far. I have the usb blaster plugged into the up/down port as it uses the same cable (I assume its just a jtag port) but maybe I'm off here.

dcmwd4e_210 is running great on my #0005 board (with 1.3 controller).

Status after running for about 11 hours:

(5s):1014.5 (avg):839.2 Mh/s | Q:900  A:7256  R:36  HW:0  E:806%  U:11.6/m
ICA0                | (5s):419.3 (avg):419.5 Mh/s | A:3663 R:18 HW:0 U:5.9/m
ICA1                | (5s):419.0 (avg):419.8 Mh/s | A:3590 R:18 HW:0 U:5.8/m

Steve, if you having problems flashing just some of them, erasing them in full before you flash does work for me.
I wrote a full up guide on this a few pages back.
https://bitcointalksearch.org/topic/m.1110647

Yes, very much so!

I've managed to get p0 & p1 permaflashed with nodynclock_175, but p2 & p3 fail to verify, but a temp flash seems to succeed. I'm having com port problems so cgminer only sees on usable device, but starts to mine.

I think I'd be better off doing this with Linux...

The flashing red LED is the clock heartbeat. Shows that the clock is actually running (on my bitstreams the red LEDs next to the FPGAs blink too)

Please make sure you're using the right one, as I said there are 2 releases, the newest one (08_20_2012 I believe) is unstable, it includes a 175 up to 210 roughly I think, and all of them are unstable. They mine, but only for anywhere from 1 hour to 1 day before failing randomly.

The older release 08_16_2012 has a 175oc bit file in it, that one is rock solid stable. Make sure you're using the right one I hope to release one with the full stability and fast speeds (up to 210) soon (hopefully).

Anyway, as long as that's right... Using the HashVoodoo bitstreams, it ignores the dip switches at the FPGA. So it doesn't matter. But on the ones based more closely on Icarus (using an Icarus Pair), on the "front" fpga (the ones closest to the connectors on the board) they are all on I believe, and the back pair have 2 on and 2 off. Enterpoint has a diagram up on the cairnsmore support page that shows the exact positions I suggest referencing that to ensure they are in the right spot. It's best to set it to the "original" setup (with the back 2 having 2on 2off in the proper config) so that if you decide to flash any of makomk's bitstreams it should work seamlessly. My HashVoodoo bitstreams ignore the fpga specific dips anyway.

Does that help?

Thanks for the help. I wasn't sure what the purpose of the red flashing light was (it's usually not good  )

I've got it talking to my pc again by plugging it into a different USB port (?) and sucessfully flashed the controller with hashvoodoo_controller_25.bit

I'll start with hashvoodoo_nodynclock_175.bit, following the wipe forward/ program reverse procedure - i've got SW3 and SW6 one question though:

what are the correct running dip switch positions for the the ones near the FPGA's ? all on?

The led on the controller should flash during normal operation. You do not need a JTAG, you can program the controller and bitstream via USB (there are several "mini-howto" in this thread, and the instructions from enterpoint should work fine). It sounds like you flashed it successfully.

You didn't mention which bitstream you have installed? (did you install a bitstream after receiving it?) the shipping bitstream is likely not ideal to use, as MUCH development has happened.

If you're using controller 1.5, I reccomend one of makomk's new dcmwd bitstreams, that seems to currently be getting the best overall performance from the board. If you have any stability problems, you can fall back to my HashVoodoo bitstream from github at https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner/downloads specifically you want the 08_16 release not the 08_20 one. (08_20 is faster but has stability issues). You may want to download both though, as the readme in the 08_20 one has some added tips/tricks for flashing in it. The 08_16 is rock solid, but only performs at 175Mhash per chip. Where makomk's bitstreams reach upwards of 200 or 210 right now (and his newer ones should solve the stability problems). I have yet to release one with his newest fixes.

Hope that helps.

The way it currently works with the newest controllers is:

Previously you had 4 ports per board, but only 2 of them were used for mining (1 port for each Icarus Style Pair of chips).
With the new ribbon cable in place, the second board uses the other 2 ports on the first. So you plug the USB into one board, chain a second board off of it, and use all 4 ports (each port representing 2 chips Icarus style).

Does that help?

Other than following the instructions from Enterpoint (I believe some dip settings) there is nothing else fancy you need to do, just use it like normal, just use all 4 ports instead of just 2.

Hope that helps!

Hi everybody - I'm having some problems with my cm1 board (arrived today)

Here's what I did:

Plugged it all in and installed the drivers (Win7 X64) - all ports, etc. created ok

Tried cgminer to com ports 25-28 - nothing working - I assumed it was because the shipping controller runs at 57600 and cgminer assumes 115200 (i read that on the thread)

Used spiprog.exe to update to controller 1.5 - 0 errors and flashing red controller led,so disconnected usb and psu to cm1 and reconnected with all dip switchs on. led still flashing (?)

The red controller led stops flashing if the board is back in programming mode (sw3 & sw6 off), but isn't responding at all

Do I need a JTAG cable to reprogram the controller?

I would just like to thank all that have been working on the bitstreams and such, ive been away for a month (a weeks holiday and then waiting on my rma return, etc).

Flashed the 2 new boards to controller 1.5 and shortfin_dcmwd4e_ed_test_200_overclock.bit for the hour that both have been running, i have average Utility per pair of 5~5.5, which seems pretty good to me, such a change from my poorly board before

For anyone that has done the up/down cable, is there anything special i need to change in my run commands? I know i have to connect the cable and set the master/slave dip, but is that it, does the dual stack just present as 8 com port as it would do individually?

Hi makomk,

this is board sn #132 with your latest bitstream dcmwd4e 210 MH/s running since yesterday 10 pm CET.


The 220 MH/s one does not work, a pair of FPGAs dies as soon as it starts.

It has a higher invalid count, though, in particular ICA 17

spiccioli.

makomk,
I use "--icarus-timing long".
I remember cgminer complaining about not getting work fast enough, but I didn't see this with the 200mhz bitstreams but with 210 and 220 which have way lower U/m than the dcmwd4c/4e-200 on my board. I can't say for sure though because I don't use cgminer logfile.

Ah, normally that means that the FPGAs aren't being fed new work fast enough. It might help to add "--icarus-timing=2.4" to the cgminer command line. Also, does cgminer complain about not getting work from your pool fast enough?

thank you, makomk, I appreciate your work. the new bitstream will stop my whining for a short time...

dcmwd4e_ed_test_200 @ all four fpga of board #62-0017 running for 16 hours:
still no 5.6 U/m @ ICA1... I'll let it run another day to have a better base for the stats...




sometimes there are simultaneous orange flashes @ fpgas 2+3 (ICA1).

In fact it seems to run fine on the original (1.1?) controller. As my 2 boards were crashed when you posted your new version, I tried it. I'll have to wait 24h to know if its more stable (usually utility goes down within 24h meaning FPGAs are going down one after another).

btw I found 2.71 to be a good upgrade atleast for me (hashvoodoo175oc bitstream).
I swear it's increased my average hash rate by about 5-10%. 1400 -> 1500
Will give it another 12 hours, but it appears to be performing very well.

Yeah, it does require reverting back to the 1.3 or 1.5 controller. No doubt ebereon and others will have some news as to how stable it is in a day or two, might be worth waiting until then. (Glasswalker will probably also be coming out with faster bitstreams at some point but he's really busy right now.)

Awesome news Makomk, would love to try, but just changed over to hashvoodoo. Kinda like now I got it stable, not a single error, also it mean having to revert back to the original controller right?
It is very tempting that higher rate though.

OK. I think I've managed to track down an issue in my previous bitstreams which sometimes caused them to fall over and stop producing shares after a while. You can find the fixed bitstreams at: http://www.makomk.com/~aidan/shortfin-dcmwd4e-20120822.7z They should hopefully reach the same initial hashrates and invalid rates as the dcmwd4c ones did, except without the long-term stability issues that plagued those. Again, this issue affects all my previous bitstreams and for maximum stability I recommend that everyone who's using any of them upgrades to the new ones when it's convenient to do so. Plus, the 210 MHz and 220 MHz bitstreams might actually be usable this time around!

(It appears some - though not all - of the problems I was blaming on the DCM were actually caused by me failing to change a synthesis option that needed changing, meaning a particular finite-state machine was less robust than it needed to be and kept getting wedged in an invalid state. Whoops.)