@TheSeven: maybe I am wrong, but I am currently not sure if pyfpgaminer is still having some issues.

Currently I have two fpga board, running in different physical locations.
Both boards are running different bitfiles.

If I now compare the outputs of pyfpgaminer, then on both consoles I see around 10% rejected shares.
If I match the consoles timewise, then the rejects happen at the same points in time.

Do you have any idea if that could be related to specific api calls or something within the communication with the pool?


A)

Found share: eligius:dd51c0630a1638ba8e819b38aa18183b7d4e8d98d5260805d82f3ba9b3fdcbf8:bb9e77d84df7598d1a1d932f:7a031f22       
eligius rejected share 7a031f22                                                                                               
Mining: eligius:f219c175c6f49f8ec2cf0b302307f4f439650c7886b7516ff06656ae84831717:dd20a1094df759a91a1d932f                     
Mining: eligius:098e08762b694e86849b98bb5cfb58289fab9647e9ee082973af9c3cc8dfc00f:27be68d44df759c51a1d932f                     
Found share: eligius:098e08762b694e86849b98bb5cfb58289fab9647e9ee082973af9c3cc8dfc00f:27be68d44df759c51a1d932f:6cfa9395       
eligius rejected share 6cfa9395   

B)
Found share: eligius:3f8347933e5369be01edc6f05284cdefce58f727e97ef6c9334bc8da642a4186:c87f6b0f4df759641a1d932f:0bb3d26f       
eligius rejected share 0bb3d26f                                                                                               
Mining: eligius:0c6933c15b68a5a1480f60382eaa95058eb8ddc3abf2629332c2bbbf05571b68:e3ea48fe4df7597f1a1d932f                     
Mining: eligius:956dfec46f309dfe46db73459267fd2ac3a7b30d54b4ea1e6b437c879a2ee739:84ebf8984df7599a1a1d932f                     
Mining: eligius:6a27c65613e41864db70feefdb8db812aecc86a6dedb6104b10f06acb20d7f2b:213e86ab4df759b71a1d932f                     
Mining: eligius:434201cd46a5972605ee6a5f2fa4baa12f68b73871b164b82597f3a817258bb2:2dd2aca84df759d21a1d932f                     
Mining: eligius:73347264657294419b1f2ce908373d775decd40116836091ceddc01b01492d5e:632383ca4df759ee1a1d932f                     
Found share: eligius:73347264657294419b1f2ce908373d775decd40116836091ceddc01b01492d5e:632383ca4df759ee1a1d932f:2b11428c       
eligius rejected share 2b11428c     

@TheSeven: Just interested, but you fitted a complete unit (depth=6) into a v5lx110t?
Gave it a try, but the default strategy already shows 250% LUTs after synthesis...

trying to build a depth:=3 version right now.

slice luts: 54% (53% used as logic)
slice registers: 26%
occupied slices: 66%

estimates after synthesis.
with a targeted 50mhz clock p&r takes forever and finally fails with setup violations.
problem is congestion/routing, not available ressources in terms of FFs or LUTs...

if you have the time, then just give it a try for xc6slx45-2csg324 with 50mhz and depth:=3

increasing the frequency is not an option, with depth:=2 the timing performance design goal reports just 55mhz  after p&r.

another minor isse:
after a share is found (shown in green) it gets uploaded and I get a
"... rejected share ..." while the pool I am using (bitclockers) shows the share a valid.

2.6.5 on openSuse 11.3

Changing it to
delta = (endtime - starttime).seconds - 0.0145
fixes the problem.

Congrats for PyFPGAMiner, it is really nice

ATM my Atlys with 50Mhz and depth:=2 is giving 3.2MH/s and I'm curious what performance I can reach.
I was thinking about using BlockRAM instead of Slice-FFs to squeeze in more logic and maybe ease the congestion problems of spartan 6 fpgas. A first glimpse showed that ISE is complaining about asynchronous reads in the current hw version.
I think it should help a lot to move all pipeline registers to BRAMS.

ok, gave it a try, after measuring the fpga performance it crashes:

miner.py line 385
 delta = (endtime - starttime).total_seconds() - 0.0145
AttributeError: 'datetime.timedelta' object has no attribute 'total_seconds'

great, will have a look once the bitfile finally runs...

communication is working now, but "Measuring FPGA performance..." takes a lot longer than the specified 120 secs until it timeouts...

I calculated around 4200 secs if the hw achieves 1 MH/s ... can that be?

damn, i missed that one...

I now have a  bitfile for the atlys board (spartan 6 - lx45) with depth:=2 and 50mhz

The only problem is, that miner.py refuses to communicate over the serial port.
It detects the core, but when it starts "Measuring FPGA performance..." it produces and timeout: "Timed out waiting for FPGA to accept work"

@TheSeven: any idea how to debug or solve the problem? is the miner.py code working for all depths and frequencies?

@TheSeven: thanks for providing the vhdl sources. i am currently porting it to an atlys board (which is quite trivial) but the completely unrolled version is not fitting. do you already ported the configurable version to vhdl?