Topic: Klondike - 16 chip ASIC Open Source Board - Preliminary - page 78. (Read 435369 times)
PM or follow that thread... I will be sourcing a lot of those parts next week.
That is a sidetrack. Start a new thread about the bitfury.
Bkk brought it up not me
I'm trying to remember what was the reason for delaying the signal? I haven't looked into the communication protocol too much I just glanced over it. Is the plan to use two nor gates on the final design? I haven't looked at any of the updated files I may do that now.
I know.
Damn him still drooling.
I am more interested in what hub I can bundle with a Raspberry Pi and still overclock the K1 Nanos what is possible because I have giant tub of mineral oil, a pretty heat exchanger, cooling tower and some pumps and a beautiful baby blue fiberglass tank I want to dunk them in.
Yeah did you end up posting that complete mineral oil solution you've got there in that other thread? I'm interested in knowing the parts I'd need.
Also, I plan on putting together a guide on turning the RPI into a miner host, with the added bonus of a $20 RGB 128x64px LCD for monitoring, with keypad. Its Gonna be a fun project while I wait for this board to finish
I wonder if there could be a way to get a larger range than just 60Mhz of signal capture other than just replacing the cap depending on your desired frequency?
Most likely I'll add an extra Schmitt trigger on each line and use the smallest cap that will work once the edges are fast. It only needs > 10nS so that shouldn't be too hard. If that works then it will depend more on software handling of result data as to limits. I already have in mind how I'll speed that up so that it can handle UART data but there is a limit. Basically, once a byte is received by the UART there is 5 uS to deal with it and at that point it cannot let go until all 4 bytes are stored. So other functions will need to co-operate by reducing their ISR footprint. I'm trying to remember what was the reason for delaying the signal? I haven't looked into the communication protocol too much I just glanced over it. Is the plan to use two nor gates on the final design? I haven't looked at any of the updated files I may do that now.
It's because there is no clock signal from the ASIC, but the clock is implicit in the data. So to allow a UART to capture it rather than using a CPLD or FPGA I use a single gate to extract the clock. The delay is so the PIC has enough setup time between the clock and data. Ultimately a CPLD would allow capturing at higher rates and then the PIC could clock the data in as slow as it needs. A more complicated capture could be designed in a CPLD but then we also have another device that needs programming, and you get into another programming tool and using the HDL environment etc. So I was trying to keep it simple as there's already enough to do.I am more interested in what hub I can bundle with a Raspberry Pi and still overclock the K1 Nanos what is possible because I have giant tub of mineral oil, a pretty heat exchanger, cooling tower and some pumps and a beautiful baby blue fiberglass tank I want to dunk them in.
Most of the hubs on the market are junky but someone did post a good robust one back up the thread a ways. I can't run both the K and the Erupter on the hub I have even with a decent adapter wattage. It seems to limit use even when the K doesn't draw power because the Erupter is using a full load. On my notebook they can both run together.Yes, I say populate the whole board, use original design component values and let it rip hash 
Hope to add some more pretty quick. I need the hash now I turned off my GPUs (which is good as it frees up the ATX PSU for this). But not tonight as I stayed up all last night and it wiped me out. So going to bed soon.This is great news!
Thanks BkkCoins almost time to place more ASIC's.
^^FTFY;Thanks BkkCoins almost time to place more ASIC's
.Yes, I say populate the whole board, use original design component values and let it
That is a sidetrack. Start a new thread about the bitfury.
Bkk brought it up not me
I'm trying to remember what was the reason for delaying the signal? I haven't looked into the communication protocol too much I just glanced over it. Is the plan to use two nor gates on the final design? I haven't looked at any of the updated files I may do that now.I know.
Damn him still drooling.
I am more interested in what hub I can bundle with a Raspberry Pi and still overclock the K1 Nanos what is possible because I have giant tub of mineral oil, a pretty heat exchanger, cooling tower and some pumps and a beautiful baby blue fiberglass tank I want to dunk them in.
That is a sidetrack. Start a new thread about the bitfury.
Bkk brought it up not me
I'm trying to remember what was the reason for delaying the signal? I haven't looked into the communication protocol too much I just glanced over it. Is the plan to use two nor gates on the final design? I haven't looked at any of the updated files I may do that now.
That is a sidetrack. Start a new thread about the bitfury.
I hope the BitFury chip has a more flexible design. Addressable registers using SPI like flash memory would be ideal. Then you just update the data you need for each work unit. Nonce ranges and operating parameters like clock cfg can be set once and left. Most current micro-controllers have hardware support for that.
Not to sidetrack this thead but has anyone seen any datasheet on the BitFury chips? I seen they were for sale but no real data sheet on them as of yet. Good to see your hashing at full speed. I know a lot of people following this are set on overclocking. I wonder if there could be a way to get a larger range than just 60Mhz of signal capture other than just replacing the cap depending on your desired frequency?
GREAT NEWS!
I've got it running at 300MHz and it's much more reliable than at lower speeds. I now have 2 chips doing 600 MH/s total with fairly long periods with zero HW errors.
I tried several capacitor values for result capture and the 30pF works well up to about 360MHz. At 380MHz it's lost sync. I tried a brief run at 360 MHz and it worked ok. I need to get a fan working before I run extended tests at higher clocks.
I had to fiddle a lot with the work unit cycle timing. Seems I don't know what's going on because calculated times weren't right. By trial and error I adjusted it to get very few duplicates. I've also implemented code to only update clock cfg when it changes, not every work unit. But I haven't altered the result capture code yet - so even with no extra schmitt buffers and slow result code it's actually doing ok. At 300 MHz the result data comes out at 2.35 MHz.
Here's a pic of the result data at 300 MHz:
(removed we saw further up there didn't we?)
I'm just letting it run for a while at 300 to see how it holds up. Chips and heat sink get fairly hot to touch but I have just convection cooling for now. According to IR thermometer the heat sink is about 54C and the chip may be about 63C.
I've got it running at 300MHz and it's much more reliable than at lower speeds. I now have 2 chips doing 600 MH/s total with fairly long periods with zero HW errors.
I tried several capacitor values for result capture and the 30pF works well up to about 360MHz. At 380MHz it's lost sync. I tried a brief run at 360 MHz and it worked ok. I need to get a fan working before I run extended tests at higher clocks.
I had to fiddle a lot with the work unit cycle timing. Seems I don't know what's going on because calculated times weren't right. By trial and error I adjusted it to get very few duplicates. I've also implemented code to only update clock cfg when it changes, not every work unit. But I haven't altered the result capture code yet - so even with no extra schmitt buffers and slow result code it's actually doing ok. At 300 MHz the result data comes out at 2.35 MHz.
Here's a pic of the result data at 300 MHz:
(removed we saw further up there didn't we?)
I'm just letting it run for a while at 300 to see how it holds up. Chips and heat sink get fairly hot to touch but I have just convection cooling for now. According to IR thermometer the heat sink is about 54C and the chip may be about 63C.
YOU ARE MY HERO!!!!!!!!!!!!
This is great news!
Thanks BkkCoins almost time to place more ASIS's.
Thanks BkkCoins almost time to place more ASIS's
.I'm following, but not super closely.. Doing Result capture like this, are you using good capacitors (2, 5, at most 10%) or are you using standard +80%/-20% caps? If you're having to tinker with values that much, then variance between the parts that people buy is going to be a real issue..
Add-On: I just looked.. the 30pF is a 5% part, so that's a plus.. I would still suggest buying a few of the same part number from different vendors (to guarantee you get samples from different manufacturing lots) and make sure the variance doesn't cause issues..
Enigma
The different parts I've tried have been very different values. 30pF was my original design. But then when I had many capture errors I decided to try larger values like 100pF, 220pF and 330pF. At 128 MHz 220pF worked well. But then when I tried boosting to 256 or 300 MHz I couldn't get capture because the delays were too long and one bit ran into another. So I started lowering again and ended up back at 30pF. So if I had just started running at 256MHz with the original cap I would have avoided all this. I think it's silly to make the serial comm data rate dependent on the internal hash clock, especially when there's the input 32 MHz clock available. Maybe they had to pay by the flip flop for design and decided to save 32 of them.Add-On: I just looked.. the 30pF is a 5% part, so that's a plus.. I would still suggest buying a few of the same part number from different vendors (to guarantee you get samples from different manufacturing lots) and make sure the variance doesn't cause issues..
Enigma
I hope the BitFury chip has a more flexible design. Addressable registers using SPI like flash memory would be ideal. Then you just update the data you need for each work unit. Nonce ranges and operating parameters like clock cfg can be set once and left. Most current micro-controllers have hardware support for that.
Bitfury.... drooooooool......
Hope you rest in between sets and work BKKCoins. Keep fresh!
I'm following, but not super closely.. Doing Result capture like this, are you using good capacitors (2, 5, at most 10%) or are you using standard +80%/-20% caps? If you're having to tinker with values that much, then variance between the parts that people buy is going to be a real issue..
Add-On: I just looked.. the 30pF is a 5% part, so that's a plus.. I would still suggest buying a few of the same part number from different vendors (to guarantee you get samples from different manufacturing lots) and make sure the variance doesn't cause issues..
Enigma
The different parts I've tried have been very different values. 30pF was my original design. But then when I had many capture errors I decided to try larger values like 100pF, 220pF and 330pF. At 128 MHz 220pF worked well. But then when I tried boosting to 256 or 300 MHz I couldn't get capture because the delays were too long and one bit ran into another. So I started lowering again and ended up back at 30pF. So if I had just started running at 256MHz with the original cap I would have avoided all this. I think it's silly to make the serial comm data rate dependent on the internal hash clock, especially when there's the input 32 MHz clock available. Maybe they had to pay by the flip flop for design and decided to save 32 of them.Add-On: I just looked.. the 30pF is a 5% part, so that's a plus.. I would still suggest buying a few of the same part number from different vendors (to guarantee you get samples from different manufacturing lots) and make sure the variance doesn't cause issues..
Enigma
I hope the BitFury chip has a more flexible design. Addressable registers using SPI like flash memory would be ideal. Then you just update the data you need for each work unit. Nonce ranges and operating parameters like clock cfg can be set once and left. Most current micro-controllers have hardware support for that.
GREAT NEWS!
I've got it running at 300MHz and it's much more reliable than at lower speeds. I now have 2 chips doing 600 MH/s total with fairly long periods with zero HW errors.
I tried several capacitor values for result capture and the 30pF works well up to about 360MHz. At 380MHz it's lost sync. I tried a brief run at 360 MHz and it worked ok. I need to get a fan working before I run extended tests at higher clocks.
I've got it running at 300MHz and it's much more reliable than at lower speeds. I now have 2 chips doing 600 MH/s total with fairly long periods with zero HW errors.
I tried several capacitor values for result capture and the 30pF works well up to about 360MHz. At 380MHz it's lost sync. I tried a brief run at 360 MHz and it worked ok. I need to get a fan working before I run extended tests at higher clocks.
I'm following, but not super closely.. Doing Result capture like this, are you using good capacitors (2, 5, at most 10%) or are you using standard +80%/-20% caps? If you're having to tinker with values that much, then variance between the parts that people buy is going to be a real issue..
Add-On: I just looked.. the 30pF is a 5% part, so that's a plus.. I would still suggest buying a few of the same part number from different vendors (to guarantee you get samples from different manufacturing lots) and make sure the variance doesn't cause issues..
Enigma
Awesome breakthrough BKKCoins!!!
Awesome stuff, congratulations!
It's so exciting! Thanks a lot for your great work!
I am working on a K16 board with one ASIC at U6. I am using the latest codes on your github.
ktest shows that it works very well. Every time I send a "W", it returns a GOOD nonce.
However, cgminer(3.3.1) doesn't work very well with it. Rarely a valid nonce is returned.
At most time, I cannot see any result("=") reply. It gives "work stale due to stratum job_id mismatch" and runs very slow.
It seems that the cgminer driver doesn't capture some results message from the PIC.
I don't know why but I am thinking maybe this is because cgminer is using a different USB library than the ktest.
If this is a typical issue, I appreciate if you can help when you have time. Otherwise, just ignore it. I will work it out by myself.
I'll push my current changes in a minute. Be sure to use the latest. It should work ok now but also note that a mismatch between firmware and driver could cause problems as I change them both in sync here. Neither are stable that you can use one if the other changes. Not yet.I am working on a K16 board with one ASIC at U6. I am using the latest codes on your github.
ktest shows that it works very well. Every time I send a "W", it returns a GOOD nonce.
However, cgminer(3.3.1) doesn't work very well with it. Rarely a valid nonce is returned.
At most time, I cannot see any result("=") reply. It gives "work stale due to stratum job_id mismatch" and runs very slow.
It seems that the cgminer driver doesn't capture some results message from the PIC.
I don't know why but I am thinking maybe this is because cgminer is using a different USB library than the ktest.
If this is a typical issue, I appreciate if you can help when you have time. Otherwise, just ignore it. I will work it out by myself.
If ktest reports good nonces then usually right now the driver will also get them.
Note that my board has an extra NOR gate if you haven't kept up with my notes then you may need to change the edge it captures on; now rising edge.
It's so exciting! Thanks a lot for your great work!
I am working on a K16 board with one ASIC at U6. I am using the latest codes on your github.
ktest shows that it works very well. Every time I send a "W", it returns a GOOD nonce.
However, cgminer(3.3.1) doesn't work very well with it. Rarely a valid nonce is returned.
At most time, I cannot see any result("=") reply. It gives "work stale due to stratum job_id mismatch" and runs very slow.
It seems that the cgminer driver doesn't capture some results message from the PIC.
I don't know why but I am thinking maybe this is because cgminer is using a different USB library than the ktest.
If this is a typical issue, I appreciate if you can help when you have time. Otherwise, just ignore it. I will work it out by myself.
I am working on a K16 board with one ASIC at U6. I am using the latest codes on your github.
ktest shows that it works very well. Every time I send a "W", it returns a GOOD nonce.
However, cgminer(3.3.1) doesn't work very well with it. Rarely a valid nonce is returned.
At most time, I cannot see any result("=") reply. It gives "work stale due to stratum job_id mismatch" and runs very slow.
It seems that the cgminer driver doesn't capture some results message from the PIC.
I don't know why but I am thinking maybe this is because cgminer is using a different USB library than the ktest.
If this is a typical issue, I appreciate if you can help when you have time. Otherwise, just ignore it. I will work it out by myself.
really great news, nice!
EXCELLENCE! I send you virtual internet high five!!!
GREAT NEWS!
I've got it running at 300MHz and it's much more reliable than at lower speeds. I now have 2 chips doing 600 MH/s total with fairly long periods with zero HW errors.
I've got it running at 300MHz and it's much more reliable than at lower speeds. I now have 2 chips doing 600 MH/s total with fairly long periods with zero HW errors.
http://www.youtube.com/watch?v=2ORCnvGnaAM#t=1m22s
Jump to: