Bitcoin Forum
December 04, 2016, 10:38:22 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [16] 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 »
  Print  
Author Topic: ZTEX USB-FPGA Modules 1.15x and 1.15y: 215 and 860 MH/s FPGA Boards  (Read 174085 times)
ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
February 27, 2012, 08:53:57 AM
 #301

Compilation of the SDK for MacOS is known to work. Several customers did it. But don't ask me about the MacOS version or names of development packages or so.

For compiling the Java bindings of libusb you need to use the "Makefile.macosx" in the libusbJava-src directory. Dependencies are libusb, the java development kit (jdk) and certain OS headers (for type  definitions.)

Compilation of bmp works without modifications. It is tested at least it at with Freepascal versions 1.0, 2.0 and 2.2. There are no other requirements.

As written earlier (https://bitcointalk.org/index.php?topic=49180.msg752052#msg752052)  you just need to copy the library to the working directory of your BTCMiner, i.e. compilation of bmp is not required.

AFAIR one customer created some MacOS packages of the SDK and published them somewhere (ask google).


...
One polite request Stefan - could you list the actual versions of the APIs / SDKs / libraries that your SDK depends on?
...

Creating a Bitcoin client that fully implements the network protocol is extremely difficult. Bitcoin-Qt is the only known safe implementation of a full node. Some other projects attempt to compete, but it is not recommended to use such software for anything serious. (Lightweight clients like Electrum and MultiBit are OK.)
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480891102
Hero Member
*
Offline Offline

Posts: 1480891102

View Profile Personal Message (Offline)

Ignore
1480891102
Reply with quote  #2

1480891102
Report to moderator
1480891102
Hero Member
*
Offline Offline

Posts: 1480891102

View Profile Personal Message (Offline)

Ignore
1480891102
Reply with quote  #2

1480891102
Report to moderator
1480891102
Hero Member
*
Offline Offline

Posts: 1480891102

View Profile Personal Message (Offline)

Ignore
1480891102
Reply with quote  #2

1480891102
Report to moderator
catfish
Sr. Member
****
Offline Offline

Activity: 270


teh giant catfesh


View Profile
February 27, 2012, 09:24:26 AM
 #302

Any object pascal experts in the house? I've managed to bulldoze my way through all the roadblocks getting the SDK compiled cleanly on Mac OS X ice kitteh (aka 10.6) - it's taken bloody ages because of conflicts between USB library bitness, Java library bitness, and having to literally compile every dependency, none of which are versioned clearly, from scratch.

Part of the blame goes to Apple for having a schizophrenic Java implementation that 'cleverly' decides whether to run 32-bit or 64-bit depending on what you're trying to run. And having re-written Stefan's usblibJava Makefile to actually run on Snow in proper 64 bit mode, at last I had all the Java components compiled and working.

Most of the blame goes to me for not being as good as I think I am Smiley

I'm down to the last problem. I can't - for the life of me - get my head round BMP. The problem is simple - an include directive in the macro processor instantiates (recursively) a Macro buffer object which is added to the list of buffers in the object itself. The Macro buffer class is derived from the Text buffer class, and the latest incarnation of the Free Pascal Compiler won't allow a derived class to be passed as parameter to a method expecting the parent class, which is exactly what the code is trying to do.

So we've got object pascal, and an inherited class recursively calling its parent to include its contents.  Angry OK, this isn't a simple problem at all...

I've rewritten the code to take the macro off the derived class, typecast the derived class as its parent and send *that* in the inherited constructor call, adding the macro stuff to the returned instance. Hey presto, it compiles.

However... it only builds a small proportion of the IHXs in the examples section.


What frustrates the hell out of me is that the basic code - UCEcho - compiles and builds a nice Jar file which actually *executes* and runs on my Mac and my FPGA. The USB libraries work, UCEcho tells me the device ID of my nice test board, etc. Hence *most* of the code is OK.

But many of the examples will not build, and neither will the BTCMiner firmware. All of them bomb out leaving a blah.tmp.c file of 64000 bytes (this is Snow Leopard, so may be exactly 64k - Apple confused us all with kilo / kibi and all that BS a while back) and an error of 'failure writing to blah.tmp.c'. No more verbosity can be obtained from the BMP macro processor, and there are virtually NO comments in the code.

Now I haven't been a professional coder for a LONG LONG time but this fucking infuriates me. It's a meta-meta-self-referential fucking parsing machine written in non-type-safe old Pascal and there's no commentary or verbose error messages. I'm trying my hardest here but I have the feeling that the code originally worked only because of some unintentional feature in a specific version of the free pascal compiler... and hence why binaries are included for Linux and Windows. That could be unfair, but anything recursive really needs proper commenting IMO, otherwise it's impossible to follow. The human brain has a stack of 7 items and you're doing well if you can use them all (top coders can, few others train their short term memories to that level)...

I've obviously tried to compile the SDK on Linux and it works immediately using the BMP binary included. Equally I've built the entire SDK from scratch using Ubuntu 11.04 - and it all works. Ubuntu Natty installs FPC 2.4.0... Sad

So that's my final sticking point. It seems to be 100% due to the 'include' issue... which I've had to change. Equally, the entire functioning of the Pascal app may have been scrambled due to the latest version of FPC... comparing the actual bytecode IHX files produced by the Linux version and the OS X versions on the simple UCEcho code (which *does* work on both platforms), there are a bunch of differences and a few extra lines on the OS X side. This could be due to a newer / different version of the SDCC which could lead to faster / slower / non-functional code.

I'm hoping that the SDCC is backward compatible and produces functional code. Equally, now I've nailed Java down so it works properly (unsurprisingly enough, Java and Pascal are not on my CV but C, C++, unix and new scripting languages should suffice to pick anything up), I'm hoping that it's only a question of getting BMP working *properly*. I'm trying to compare output but the Linux builds don't leave the temp files.

I'm going to keep hammering away at this but would appreciate any assistance... for the time being, I'll see if I can remove FPC 2.6.0 from my Mac and install 2.4.0 instead... if this solves the problem then at least I'm up and running, but it's unsatisfactory as it means my main development box becomes instantly fragile - one 'port upgrade all' and everything's fecked...


ETA - Stefan - you beat me to it. The reason I asked about versions is because I thought you'd know and it'd speed up the process. I've solved the Java bindings of libusb for Snow Leopard and it requires a totally different Makefile than the one you supply. Yours assumes that Fink (an old package management system for earlier versions of Mac OS X, superseded largely by MacPorts these days) is installed, hence the references to /sw/lib etc. which give it away. Equally, there are two libusb implementations and the obsolete 'legacy' one is what is required (0.1.3 works - the current 1.0.8 does not).

The SDCC works without problems. BMP does not compile on 2.6.0, the latest version of Free Pascal. Try it. However it works on 2.4.0 as per my latest test on Linux, so I'm going with that for the time being. Apologies for the frustration but life moves pretty fast, as Ferris Bueller said, and FPC 2.2 is ancient, and Mac OS X moves *very* quickly and is perfectly happy to dump backward compatibility...

No offence intended for any of the ranting above, BTW. I don't want to 'just' run the miner pre-packaged... I want to have an SDK that I can compile from scratch whenever I want, and try out some of the examples in your SDK. I'm not your typical Mac user...

...so I give in to the rhythm, the click click clack
I'm too wasted to fight back...


BTC: 1A7HvdGGDie3P5nDpiskG8JxXT33Yu6Gct
catfish
Sr. Member
****
Offline Offline

Activity: 270


teh giant catfesh


View Profile
February 27, 2012, 09:44:11 AM
 #303

UPDATE: Snow Leopard complete from-scratch SDK compile works with FPC 2.4.0.

Will be mining shortly Smiley

...so I give in to the rhythm, the click click clack
I'm too wasted to fight back...


BTC: 1A7HvdGGDie3P5nDpiskG8JxXT33Yu6Gct
rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
February 27, 2012, 10:38:33 AM
 #304

Quick cluster tutorial:

java -cp ZtexBTCMiner-120221.jar BTCMiner -f ztex_ufm1_15d3a.ihx -m p
java -cp ZtexBTCMiner-120221.jar BTCMiner -host XXXX -u XXXX -p XXXX -m c

Done!

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
catfish
Sr. Member
****
Offline Offline

Activity: 270


teh giant catfesh


View Profile
February 27, 2012, 10:42:26 AM
 #305

Still a few niggles - similar to the 'USB issues' thread someone on the Ztex forums running Windows 7 64-bit is having - but I'm mining now Smiley

First error rate over 0.00% was when it hit 212 MHz - area around heatsink being around 41˚C according to IR thermometer. It's back to 208 MHz now and zero error rate.

As the picture shows, this is a test board with hardly optimal cooling so I'd be interested to see how my next boards perform with proper airflow.

Incidentally, I'm using the 64 bit Java USB libraries, still can't build the BTCMiner jar from scratch (missing symbol in the code), and my initial programming efforts (using the 15d3a.ihx firmware) seemed to fail - the process started, then claimed 'no ZTEX devices present' and further programming efforts resulted in 'no device found'.

Then, when disconnecting the USB, and reconnecting, my Mac tells me a 'Ztex FPGA device for Bitcoin mining' unit has been connected to the USB bus (I've got Growl set up to notify me of all hardware changes). Nice touch, so the programming may have worked after all...

So I kicked off a miner job using the pre-packaged Jar and it's merrily mining away. Looks like 208 MHz is the limit on the bodged cooling system I'm using, but subsequent boards will have much superior cooling - not just with the 'tunnel' concept but also with thermal contact between the heatsink (whatever I choose to use) and the FPGA.

Less than 10 W power consumption. W00t. Cheesy

...so I give in to the rhythm, the click click clack
I'm too wasted to fight back...


BTC: 1A7HvdGGDie3P5nDpiskG8JxXT33Yu6Gct
irobindotse
Newbie
*
Offline Offline

Activity: 17


View Profile
February 27, 2012, 10:47:10 AM
 #306

Maybe not the right thread to post in, but is anyone know if ztex(stefan) is working/planning to release on a new board with higher hashspeed? And maybe an eventual date?

Regards
Robin
bulanula
Hero Member
*****
Offline Offline

Activity: 518



View Profile
February 27, 2012, 10:58:50 AM
 #307

Maybe not the right thread to post in, but is anyone know if ztex(stefan) is working/planning to release on a new board with higher hashspeed? And maybe an eventual date?

Regards
Robin

I suggest going to look at the BFL product.

I think people using Spartan 6 will not get any higher hashrate from now and it looks like 180 - 200 MHash/s is the cap.

rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
February 27, 2012, 11:26:42 AM
 #308


BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
irobindotse
Newbie
*
Offline Offline

Activity: 17


View Profile
February 27, 2012, 11:29:58 AM
 #309

Im aware of BFL, forgot to mention that I live in Europe.

Reasons,

1.Insane prices to ship from US and pay toll and taxes.
2. And Ztex offers better guarantees and discounts.

Thats why im asking Smiley

Regards
Robin
bulanula
Hero Member
*****
Offline Offline

Activity: 518



View Profile
February 27, 2012, 11:32:39 AM
 #310

Im aware of BFL, forgot to mention that I live in Europe.

Reasons,

1.Insane prices to ship from US and pay toll and taxes.
2. And Ztex offers better guarantees and discounts.

Thats why im asking Smiley

Regards
Robin
Well I think somebody will end up being a EU reseller with manageable prices and no import duty etc.

But ZTEX offers 2 year warranty while BFL only 6 months Huh
rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
February 27, 2012, 12:11:18 PM
 #311

ztex is more expensive but the MH/w is higher and thus the chips can be completely silent like my solution above!

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
antirack
Hero Member
*****
Offline Offline

Activity: 491


Immersionist


View Profile
February 27, 2012, 12:25:33 PM
 #312

ztex is more expensive but the MH/w is higher and thus the chips can be completely silent like my solution above!

rupy how long are those hex spacers between the boards?
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 27, 2012, 12:54:03 PM
 #313

ztex is more expensive but the MH/w is higher and thus the chips can be completely silent like my solution above!

rupy how long are those hex spacers between the boards?


And where did you get them?
marked
Full Member
***
Offline Offline

Activity: 168



View Profile
February 27, 2012, 01:29:46 PM
 #314

I think people using Spartan 6 will not get any higher hashrate from now and it looks like 180 - 200 MHash/s is the cap.

Doesn't eldentyrell three ring structure improve the performance or at least it will when the clock rate improves?
https://bitcointalk.org/index.php?topic=49971.0;all


marked
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 27, 2012, 01:38:42 PM
 #315

I think people using Spartan 6 will not get any higher hashrate from now and it looks like 180 - 200 MHash/s is the cap.

Doesn't eldentyrell three ring structure improve the performance or at least it will when the clock rate improves?
https://bitcointalk.org/index.php?topic=49971.0;all


marked

Yeah the prior person likely mispoke.  Some higher performance is possible.  ztex has boards running at 212 MH/s.  Still nobody is going to get 400 MH/s out of a Spartan so there will be no massive performance boost where a board costing roughly the same gets 25% or 33% or 50% higher performance.  The Spartan-6 is pretty well analyzed how so it is in the fine tuning.  A couple MH/s here and there.  Maybe someone gets a board going @ 220 MH/s which would be a nice 10% "free" compared to existing bitstreams but significantly higher performance is going to require a new class of chips.

There is no other 45nm chip which delivers the LUTs/$ that Spartan-6 does (without special "sweetheart" pricing) so that means waiting for the Artix-7 28nm chips to become available and at reasonable cost.  The largest Artix-7 chips likely can (eventually with a lot of bitstream analysis) achieve 500MH/s+ so a pair could provide the first GH/s board.  Still who know how long it will be (Q1-2013 ?) before Artix-7 provides better MH/$ than Spartan-6 does.
bulanula
Hero Member
*****
Offline Offline

Activity: 518



View Profile
February 27, 2012, 01:41:38 PM
 #316

I think people using Spartan 6 will not get any higher hashrate from now and it looks like 180 - 200 MHash/s is the cap.

Doesn't eldentyrell three ring structure improve the performance or at least it will when the clock rate improves?
https://bitcointalk.org/index.php?topic=49971.0;all


marked

Yeah the prior person likely mispoke.  Some higher performance is possible.  ztex has boards running at 212 MH/s.  Still nobody is going to get 400 MH/s out of a Spartan so there will be no massive performance boost where a board costing roughly the same gets 25% or 33% or 50% higher performance.  The Spartan-6 is pretty well analyzed how so it is in the fine tuning.  A couple MH/s here and there.  Maybe someone gets a board going @ 220 MH/s which would be a nice 10% "free" compared to existing bitstreams but significantly higher performance is going to require a new class of chips.

There is no other 45nm chip which delivers the LUTs/$ that Spartan-6 does (without special "sweetheart" pricing) so that means waiting for the Artix-7 28nm chips to become available and at reasonable cost.  The largest Artix-7 chips likely can (eventually with a lot of bitstream analysis) achieve 500MH/s+ so a pair could provide the first GH/s board.  Still who know how long it will be (Q1-2013 ?) before Artix-7 provides better MH/$ than Spartan-6 does.


My point was exactly this. There is no way people using expensive 45nm parts will match BFL power hungry but cheap 65nm high performance parts like BFL.
antirack
Hero Member
*****
Offline Offline

Activity: 491


Immersionist


View Profile
February 27, 2012, 01:52:08 PM
 #317

ztex is more expensive but the MH/w is higher and thus the chips can be completely silent like my solution above!

rupy how long are those hex spacers between the boards?


And where did you get them?

At least here in Hong Kong you get this stuff in electronic stores, somewhere near screws and nuts.

http://www.ebay.com/itm/50mm-PCB-Spacer-Hex-Stand-Off-Pillar-Male-Female-x25-/130626750145?_trksid=p5197.m7&_trkparms=algo%3DLVI%26itu%3DUCI%26otn%3D2%26po%3DLVI%26ps%3D63%26clkid%3D6625141050556940213
ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
February 27, 2012, 02:37:00 PM
 #318

and my initial programming efforts (using the 15d3a.ihx firmware) seemed to fail - the process started, then claimed 'no ZTEX devices present' and further programming efforts resulted in 'no device found'.

Then, when disconnecting the USB, and reconnecting, my Mac tells me a 'Ztex FPGA device for Bitcoin mining' unit has been connected to the USB bus (I've got Growl set up to notify me of all hardware changes). Nice touch, so the programming may have worked after all...

This looks like your MacOS is having a problem wit the re-numeration of the FX2 devices. If you would send the output I could say more.


BTC-engineer
Sr. Member
****
Offline Offline

Activity: 338



View Profile
February 27, 2012, 03:24:56 PM
 #319

I think people using Spartan 6 will not get any higher hashrate from now and it looks like 180 - 200 MHash/s is the cap.

Doesn't eldentyrell three ring structure improve the performance or at least it will when the clock rate improves?
https://bitcointalk.org/index.php?topic=49971.0;all


marked

Yeah the prior person likely mispoke.  Some higher performance is possible.  ztex has boards running at 212 MH/s.  Still nobody is going to get 400 MH/s out of a Spartan so there will be no massive performance boost where a board costing roughly the same gets 25% or 33% or 50% higher performance.  The Spartan-6 is pretty well analyzed how so it is in the fine tuning.  A couple MH/s here and there.  Maybe someone gets a board going @ 220 MH/s which would be a nice 10% "free" compared to existing bitstreams but significantly higher performance is going to require a new class of chips.

There is no other 45nm chip which delivers the LUTs/$ that Spartan-6 does (without special "sweetheart" pricing) so that means waiting for the Artix-7 28nm chips to become available and at reasonable cost.  The largest Artix-7 chips likely can (eventually with a lot of bitstream analysis) achieve 500MH/s+ so a pair could provide the first GH/s board.  Still who know how long it will be (Q1-2013 ?) before Artix-7 provides better MH/$ than Spartan-6 does.


The new Artix-7 28nm chip from Xilinx is for sure one of the most interesting new FPGA for mining. Unfortunatley this chip is not yet available, and what is even more worse there is no official announcement when it will get available. When the production of this chip starts it could also take a longer time until the chips are really available on the market for attractive costs, because large companies with high volume are already waiting for this type of chip to assemble their boards.

This week is the Embedded World tradeshow 2012. Maybe I can get some more information about the availability at the trade-show, but I guess we have to wait at least 6 month until a 28nm FPGA miner will be available. Spartan-6 is already available now and you can use the time (with a 50BTC blockreward) until the end of this year to compensate your investment in FPGA. I guess 28nm FPGA miner will start in the time area of 25BTC blockreward. So it will take much longer until you have your return of investment. Beside all of this the 'risk' grows that someday, someone announce a SASIC or even an ASIC.   
 
CA Coins
Donator
Sr. Member
*
Offline Offline

Activity: 306


View Profile
February 27, 2012, 04:01:14 PM
 #320



Nice setup rupy.  What kind of temp/Mhz are you getting with the passive heatsink?
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [16] 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!