Pages:
Author

Topic: FPGA development board "Icarus" - DisContinued/ important announcement - page 3. (Read 207285 times)

hero member
Activity: 592
Merit: 501
We will stand and fight.
will have a final bitsteam update next week

please make some mcs files and not just .bit files so that i can perminently flash the fpgas.

if possible could you also make msc files of the .bit files in the wiki so that at least v3 v4 and beta200 are perm flashable?

kind regards

certainly, will release both .bit and .mcs files.

i will release .mcs files for all bitsteams, unless it's a UNrecommended test bitsteam (like 200m beta).
member
Activity: 112
Merit: 10
BTW:
if there some picture about your '1.7kW solar array' and your mining farm ?

The farm is a bit boring, just a pc and 4 icarus cards.  I will be building an enclosure for the icarus before summer to improve the 4x120mm fan airflow.

But I do have an old pic of my panels http://img713.imageshack.us/img713/4863/2011121318opt.jpg and batteries/inverters http://img828.imageshack.us/img828/1208/2011121318opt1.jpg
I have 2 additional 125w panels and 2 additional 60w panels now.

kind regards
full member
Activity: 120
Merit: 100
+1

BTW:
if there some picture about your '1.7kW solar array' and your mining farm ?
  4 x Icarus 1 x 5850  all powered by a 1.7kW solar array and 3G wireless in outback Australia.

will have a final bitsteam update next week

please make some mcs files and not just .bit files so that i can perminently flash the fpgas.

if possible could you also make msc files of the .bit files in the wiki so that at least v3 v4 and beta200 are perm flashable?

kind regards
member
Activity: 112
Merit: 10
will have a final bitsteam update next week

please make some mcs files and not just .bit files so that i can perminently flash the fpgas.

if possible could you also make msc files of the .bit files in the wiki so that at least v3 v4 and beta200 are perm flashable?

kind regards
hero member
Activity: 592
Merit: 501
We will stand and fight.
 Embarrassed

V4 ..

will have a final bitsteam update next week(i hope). and completely change the architecture.
please wait for that before do any optimization effort.
member
Activity: 112
Merit: 10
The 190mhz v2 and v3 default shipping bitstreams result in results of approximately 1490-1530MH/s for the 4 boards.

The 200mhz bitstream showed results of approximately 1520-1650MH/s for the 4 boards.
BUT large swings in speed at times significantly reduced hashing speeds due to overheating im guessing (only have the v2 40mm fan and 3xv3 50mm fans installed for cooling)

Now testing the 190mhz v4 bitstream with some interesting results.  Seems fast so far sitting pretty solidly on 1620MH/s. U=22 or about U=5.5 per board.
Im pretty sure there are some efficiency improvements in the v4 bitstream that the 200mhz beta doesnt have.  
From size comparisons it seems the 200mhz bitstream is based on the v3 bitstream (perhaps ngzhang can confirm)

If I knew how I would like to synthesize a v4 bitstream at higher speed, but i suspect this is not an easy process.

kind regards
member
Activity: 112
Merit: 10
Hrm, varying results from the 200mhz beta bitstream.  Seems faster, but then its erratic like the cores are having errors sometimes.  CGMiner does not report any HW errors tho.
I think the 200mhz stream might be an older bitstream @ high speed.  Next up ill give the v4 bitstream a go and see what the results are.

4x120mm fans on the way and ill get some better temps on the cores and try again at high speed.

I will also try and get the Tricone mining bitstream going over jtag when i get better cooling and report back here with that too.

kind regards
member
Activity: 112
Merit: 10
No, I have 1xv2 and 3xv3

kind regards
legendary
Activity: 1064
Merit: 1000
As per the FPGA-README, the number you supply would be 108 (not 10.Cool

Apologies, I was using 108 not 10.8

Seriously, if you want it optimised accurate you need to at least run --icarus-timing short (for about an hour) and see the answer it comes up with

I did that, the results turned out to be 2.5000 10.7xx

Thanks for your confirmation.

kind regards

are your ICA from the last batch?
member
Activity: 112
Merit: 10
As per the FPGA-README, the number you supply would be 108 (not 10.Cool

Apologies, I was using 108 not 10.8

Seriously, if you want it optimised accurate you need to at least run --icarus-timing short (for about an hour) and see the answer it comes up with

I did that, the results turned out to be 2.5000 10.7xx

Thanks for your confirmation.

kind regards
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
As per the FPGA-README, the number you supply would be 108 (not 10.8)

However, 108 is too high for a 2.5ns bitstream - as I mentioned before 2.5ns would be less than that (10.6=106)

If 2.5ns is correct (or lower than correct) then it will calculate the 2nd number and that will work fine.

Certainly you could use 80 (8.0s) and that would ensure it's never idle.

Seriously, if you want it optimised accurate you need to at least run --icarus-timing short (for about an hour) and see the answer it comes up with
member
Activity: 112
Merit: 10

However, 11.2s is calculated based on the Icarus mining at 2.6316ns per hash
(which of course means 5.2632ns per pair of hashes)

Once you have a new correct nanosecond value for your faster bitstream (lets say it was 2.2222ns), you simply start cgminer with the option:
--icarus-timing 2.2222

Ok so doing a temp update to the 200mhz bitstream I recalc'd and get these values :

2.500 10.744

so would I be right to set --icarus-timing 2.5000=10.8

or do i leave the second value at the default and just have the 2.5000 without the =10.8 ?

Preliminary results seem to have bumped the U/rate up from 20-21 to about 21-22, so its the expected 5%
Power consumption seems unchanged.

[update]

Setting --icarus-timing 2.5000=10.8 yielded results of about 1200 shares per hour, similar to the default 190mhz bitstream which usually nets about 1260 shares per hour
Setting --icarus-timing 2.5000 is yielding about 1328 shares per hour which is the expected 5% bump going from the 190mhz up to the 200mhz bitstream

kind regards
legendary
Activity: 2576
Merit: 1186
Nonces starting with three nullbytes (0x000000??) are never reported. Nonces starting with three FF (0xFFFFFF??) always get 01 for the fourth byte, which is usually an incorrect result. This had me confused for a while. Error in the bitstream?


Adding Icarus support to my miner. But I can't get it to ever return a nonce starting with three null bytes. I feed it data for which there is such a solution, but it's not working.

Is that normal? Does it start scanning from nonce 0x00000100 ?


yes, it didn't scan the nonce range form 0. approx: 132
Can you give an exact answer?
Since that will slightly affect the timing for when the nonce range is aborted and also how many nonces were actually processed when a nonce is found.
i.e. also details of how it affects both FPGAs
About 253 according to https://github.com/progranism/Open-Source-FPGA-Bitcoin-Miner/blob/master/projects/X6000_ztex_comm4/hdl/fpgaminer_top.v#L155

Note it's probably not the exact same bitstream.
legendary
Activity: 2730
Merit: 1034
Needs more jiggawatts
Currently beta testing Icarus support for the BitMinter client:
https://bitcointalksearch.org/topic/m.1008906
member
Activity: 112
Merit: 10
OK, ive got my xilinx cable to try and update the icarus firmware. BUT, I want to try the .bit file bitstreams before I permanently flash the spi.

Just not sure how to utilise the .bit file to temporarily hash with the icarus unit instead of using the xilinx tools to flash the mcs permanently.

ngzhang outlines in the icarus wiki that you can test the .bit files without writing anything permanently but gives no details.

If anyone can provide more information I would appreciate it, otherwise I only have the v3 bitstream mcs file that works with xilinx tools.

kind regards
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Nonces starting with three nullbytes (0x000000??) are never reported. Nonces starting with three FF (0xFFFFFF??) always get 01 for the fourth byte, which is usually an incorrect result. This had me confused for a while. Error in the bitstream?


Adding Icarus support to my miner. But I can't get it to ever return a nonce starting with three null bytes. I feed it data for which there is such a solution, but it's not working.

Is that normal? Does it start scanning from nonce 0x00000100 ?


yes, it didn't scan the nonce range form 0. approx: 132
Can you give an exact answer?
Since that will slightly affect the timing for when the nonce range is aborted and also how many nonces were actually processed when a nonce is found.
i.e. also details of how it affects both FPGAs
member
Activity: 112
Merit: 10
(SDK is always installed on my machines...)

Same, I have a desktop GPU miner and an e350 with integrated.
When I tried to run an FPGA only setup on a p3 tablet I got the OpenCL issue crop up.

kind regards
sr. member
Activity: 349
Merit: 250
Crazy idea and all, but maybe read the cgminer thread and the cgminer README?

The option you want is "--disable-gpu|-G: Disable GPU mining even if suitable devices exist"

Reading the thread will show you that other ppl cant run without the SDK installed regardless of the --disable-gpu

Recompiling without OpenCL is the only way.

kind regards

I did not know that and now I've learned something, thanks! (SDK is always installed on my machines...)
member
Activity: 112
Merit: 10
Crazy idea and all, but maybe read the cgminer thread and the cgminer README?

The option you want is "--disable-gpu|-G: Disable GPU mining even if suitable devices exist"

Reading the thread will show you that other ppl cant run without the SDK installed regardless of the --disable-gpu

Recompiling without OpenCL is the only way.

kind regards
sr. member
Activity: 349
Merit: 250
i tried to run icarus with cgminer in an ATOM laptop but cgminer said "no opencl.ddl available" something like that.  what can i do?
i tried to load opencl sdk from microsoft but i see the message "no opencl capable GPU, instalation abort"! Sad

Do you GPU mine on that box, too? If not, I'd recommend to compile cgminer from source disabling GPU support.

Crazy idea and all, but maybe read the cgminer thread and the cgminer README?

The option you want is "--disable-gpu|-G: Disable GPU mining even if suitable devices exist"
Pages:
Jump to: