Topic: Bounty[PAID OUT] : a bitstream for better utilizing the Cairnsmore1 157-294.5btc - page 4. (Read 21992 times)

Hi gyverlb,

totally agree with you, the information on what SPIProg.exe should be disclosed. If you are a Linux kernel developer you for sure know that programming an SPI device is no rocket science, and one would basically just need to know how the Spartan3 is wired to the FTDI port to access it. There are several SPI programming tools available as open source (like this SPIProg) that can be easily extended to use the related channel over libftdi.

But in the end it is not worth the effort. I found a Xilinx Parallel Cable IV that does the job well. It is fairly outdated and slower than the USB variant (plus you might have troubles finding a parallel port at your host meanwhile), but as recovery tool for sure good enough. You can find it at Ebay for less than 10$, while the USB Platform Cable is available for around 35$.

The cable is fully supported by xc3sprog, and since it comes with the 14pin 2mm pitch cable it is plug-and-play ready (in contrast to other cable I tried first and failed).

Programming the controller is done like ebereon described: use the left-hand JTAG port (the one directly at the Phoenix connector) and run

Good Luck!

Because I had no idea that there still were hardware manufacturers that wouldn't support Linux by default today. Especially in this very case: addressing the Bitcoin mining community: many (most?) of us have Linux rigs some even use the RasperryPi or home routers to connect to their FPGAs. Bitcoin is open-sourced at its roots.
The only question that I asked myself is if the board could be updated via USB (this is why I didn't purchase a JTAG cable). Even the documentation of the controller programming interface would be enough. In fact no Linux support isn't the problem, having to rely on an obscure utility that only runs on some OS versions without the safety net of documentation of the interfaces it uses is a recipe for transforming anything in a paper weight mid or longterm.
This is not the first time I purchase hardware for which I have to code the driver or some tools myself: you can still grep my name in the Linux kernel for the support of some long forgotten IDE controllers. So usually I'm not especially worried, but reading that there is some IP in there that can't be disclosed to build the tools I need is worrying me.


We knew very little of the details when we pre-ordered. Everyone took a risk, myself included.
But having the thing closed to me because I can't have access to the information I need to make it work the way I want is exasperating. I'm a tinkerer : if I can't hack it I won't like it and it better make itself forgotten (which it doesn't do well currently). It's already too bad that Xilinx won't sell you the right to hack the Spartan6 with it but separately. I already had difficulties wrapping my mind around this fact, seems the FPGA world is not for me.


That's a good alternative thanks for the heads up.

There is another possibility and that is to acquire a programming cable that will work with Xilinx ISE tools. Webpack versions of ISE are free, will run under Linux, and whilst they won't build for a LX150 Spartan they I believe will allow programming on these devices and certainly will for the XC3S50AN used for the controller. Some details http://www.xilinx.com/support/download/index.htm. There are several options for cables that will work with this software including our Prog2 (cheap parallel port cable) and Prog3 (dearer). Digilent, Xliinx and various Chinese clones are available as well. Don't ask me if the Chinese ones work. I have never tried them. 

gyverlb, sorry that things are not working out for you. but why did you purchase a hardware when you don't know how to do updates etc.

This is not the way I would buy hardware. When I know I have limited opportunities to work with hardware like this (dev board, no informations, not know software to update, forced to use only Linux etc.), I would better go for something that is better supported and documented. It's just my point of few.

But to give you also an other hint to update from the controller from Linux. Buy an simple JTAG cable, then use the xc3sprog with the -Ixc3s50an.bit option. This way Zefir managed to flash the controller from Linux successfull. Just ask him about the used cable. I think it will not cost the world (~10-20$) and it would make you also happy with your boards =o)

eb

There are 2 problems that make this impractical:

• I've not installed Windows since XP (and even then it was a one-shot because I had to for work) I'd probably spend several days on this in my free time. Last time I saw a Windows system I didn't even know where to begin, its UI is now a total stranger to me.
• I don't have any system on which to install Windows 7. The only available system I have is a test system without a harddrive, booting from an USB key. I'd have to buy a drive or install Win7 on an USB key (is it possible yet?). I thought of using virtualisation on my laptop, but I'm afraid I don't have the disk space on my SSD (I've ~15GB left and that would stretch it).

My best bet if Enterpoint doesn't release a Linux version is to find someone with a Windows install (can't think of any friend with that) and pray that I won't trash his/her system. I could sell the boards too... Ironically I wanted to buy some more, but there's no way I'd knowingly buy something that requires me to spend time on something I don't want to. Especially if it's related to mining: time is money.

I would just try and download a copy of Windows 7 install it without a key, you get 30 Days trial, or borrow someones Win7 Cd and load it from that. That way you could at least get to 1.3, or 1.4 now. You don’t actually need to own the copy just get it installed and use it for 30 days.

My boards (62-0110 and 62-0111) aren't happy yet :

This is with the 190 version in the same batch after 1 hour on cgminer 2.6.4 with --icarus short:

ICA 1 and ICA 3 are linked to the third ttyUSB interfaces of each cairnsmore 1 board on my systems (the latest udev rules published on the forum are quite nice) :
ICA1: /dev/cm-62-0111-if02
ICA3: /dev/cm-62-0110-if02

From what I can tell (orange LED often on), these are the interfaces linked to the 1st and 2nd FPGA on each board. The #62-111 board has indeed both FPGA 1 and 2 orange leds on most of the time. I can see the FPGA 2 orange LED on #62-111 quite often too.

I had a run with 190 on all FPGAs except FPGA 1 where i put the 160 bitstream from the same batch on each board.
Here is the result after 6 hours :
60-110-if02: 3,84
60-110-if03: 5,03
60-111-if02: 3,44
60-111-if03: 5,05

My main problem is that results are quite inconsistent and most of the time hard to get: the tty interfaces vanish often and unpredictably. Some days I have to reset boards by removing power/USB half a dozen times.

My problem might be that I can't update the controller and still use the 1.1 firmware on it but I don't have any solution for it (no Windows license here).

As far as my boards are concerned the latest 200Mhs bitstream takes the bounty. I have been hearing about issues with pre #50 boards,but Im fairly sore most or all of us can agree that that has got to be a hardware issue.

I should note that whilst I have released the source corresponding to those bitstreams, there are no instructions to build similar bitstreams from the source because you can't do so trivially. That source is actually back-modified to match several direct edits I made to the compiled .ncd in FPGA Editor - you can download that from http://www.makomk.com/~aidan/shortfin_dcmwd4c_ed_ncd.7z if you want to poke about yourself. You should be able to get fairly close by pointing Smart Guide to that ncd (unzip it, right-click fpgaminer_top in the Hierarchy pane in ISE, choose Smart Guide and point it at the NCD, then click the green Implement arrow in the toolbar) but that dents performance by several tens of MHz. You'll also need to run mkrelease.sh which executes some FPGA Editor scripts that are needed to get the bitstreams to run.

(Honestly, if you want to do development the halffin-dev branch in my git repository is much nicer to work with, it just doesn't quite have the same performance yet. Or there's Glasswalker's stuff, which is quite nice too.)

I'm running it now on 9 boards. will tell you in 24 hours how it looks.

update:
after 2 hours cgminer shows 6942 total, 771 per , pool shows 6761, 751 per , 99.9% accepted on both.

22 hour update: cgminer shows 6839 total, 759.8 per, pool shows almost exactly the same, 99.98% accepted on both.

I will start testing the 200 MH/s bitstream on my SN 26 board tomorrow.

The 200Mhs bitstream in this pack seems like a winner. I need more ppl testing it, input on wether or not the documentation is as required.
http://www.makomk.com/~aidan/shortfin-dcmwd4c-20120811.7z

Im seeing an average speed of 800Mhs reported at poolside, one troublesome core-pair is pooping out an invalid rate of 3,15%. but it seems like we have a winner, I dont have a long enough test-run yet, but there should be no uptime-issues to be expected.

If you want your word in on wether or not this qualify's for the bounty: the time to act is now, test it, call out about missing or insufficient documentation, do something.

Well I closed timing (175Mhz target, with about 1us to spare) this morning. Unfortunately the build was missing termination on the LVDS clock lines. So that will hurt overall performance. When I get home I'll run that through fpgaeditor and see if I can correct it and do a bitgen from that. Then I'll test that out.

Also I'll try to get the controller fixed so USB programming isn't broken. Then we can get the .bit for the current source code released so everyone can try it out.

If we can get this thing up to 200Mhash, and reliable on all the boards, then I'll shift my focus back to the HashVoodoo core, to replace the ztex/icarus core I'm using now. Which will shift us to a "sea of hashers" style approach.

Anyway I got super busy this past week roughly, so haven't been able to spend as much time on it. Luckily I had a like 5 day long smartxplorer build going, so I wasn't wasting time completely.

Also FYI: the current source code on github is what I've done the current build based on.

If this works (even marginally) then the next step is to backport any of makomk's tweaks into this bitstream, and a few other fixes/adjustments I've thought up. Then provided we can get roughly 200Mhash out of this one, I'll leave it there.

Right now I'm mostly waiting to hear how Glasswalker's latest bitstream will turn out. It sounds really promising, touch wood.

the escrow held by Zefir is now up to 185 btc. lets go glasswalker/makomk/mystery genius, we need more MH/s!

Glasswalker...thank you for that great update!

To be exact, the LED meanings in the "standard icarus" bitstreams (such as makomk's current 190oc release for example) are:
0 - Found a Share (flashes, then fades out)
1 - RX (FPGA received data on the serial port)
2 - TX (FPGA sending data on serial port)
3 - Idle (this lights when the FPGA has no current work to do)

The colors in order are:
0 - Green
1 - Red
2 - Blue
3 - Amber

Those functions are static (ie: they don't change depending on what "mode" the fpga is in).

For the HashVoodoo bitstream (Still not working right as of yet) the LED meanings are:
0 - Found a Share (flashes, then fades out)
1 - Clock Heartbeat (flashes on a heavily divided clock signal to indicate the FPGA is getting a good clock signal and hasn't locked up)
2 - Serial Activity (blinks on transmit or receive on the serial port)
3 - Idle (lights when the FPGA has no current work to do.

It should be noted that on both bitstreams currently the serial rx/tx LEDs light so fast typically you hardly notice them (if at all). I intend to add a (faster) version of the "fader" code from the share found LED code to the serial activity LED, to stretch out the blink duration some, to allow it to be more obvious when the FPGA is communicating.

To answer your question about multiple bitstreams:

In theory that should work fine. The comm clock, and hashing clock are different clock domains, so the communications code should keep on working just fine, while the hash clock can be at different rates. It may end up resulting in the entire nonce range being missed sometimes though (ie the 190 is in "front" and 180 in "back" the 190 starts the job, and forwards half it's nonce range to the 180 bitstream, but the 190 will finish before the 180 has finished, resulting in a small percentage of the second half of the nonce range being "skipped"). I don't think that will hurt overall hashrate, but it might skew some of the other stats slightly. Ultimately the impact should be nearly nothing.

Hope that helps

Also a quick status update on HashVoodoo development:

The first test bitstream using LVDS clock signalling was completed, but we're still having communications issues. So I'm now doing some debugging of the comms stuff.

The good news is that the LVDS clocks seem to be stable in all 4 slots, even on my 0001 serial number board! So I think if we can solve the comms issues, we're really onto something with this one!

Please note, I don't reccomend installing this bitstream just yet, (the .bit isn't released) because it's not quite working right. Once I get it hashing on my end, I'll release the full binary bitstream for you all to test out. I don't want to cause more headaches by releasing a malfunctioning bitstream (and I've encountered some wierdness on the jtag lines now, so I want to rule out the bitstream as a cause. The last thing I want to do is release an update that breaks your usb updating ability).

I'll post more when I have it.

ny1 know if I can run different bitstreams in each FPGA..eg p0,p2,p3 = 190MHs bitstream whilst p1=180MHs

thinking of this as p1 is unstable and keeps shitting itself. NOTE: "Shitting itself" is a professional engineers term for fucking up or crashing

ok..so I have finally deduced what functions the cm1 board lights represent and no, I didn't find it in any enterpoint instruction manual.

FPGA on standby or idle (not mining)
Orange, constant - standby

FPGA mining
Green, flash - found a successful result
Orange, flash - normally with green flash, mining
Orange, constant - FPGA not responding  ---shit itself or controller not communicating with it

I have p1 on 62- 0433 presenting a constant orange during mining so I assume it is playing up...will reflash 190MHs bitstream tonight and report back