Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 69. (Read 286370 times)

speaking of ROI, DHL just called me and they said customs wants 400$ some dollars before they can release the shipment. Maybe I should have looked this up but I guess import tax is applied to more expensive shipments in the US?

Ok possibly the return on return characteristics may have changed in the last weeks by *** but of course they may not deliver as promised and then ROI actually doesn't change. Do remember 10 weeks ago we offer a product at 33% discount because it was a development and that was explicitly explained at that point. Even only running at the 50% notional performance that we are today we are not far removed in ROI of other FPGA boards.

The core of the team are already running 100hr+ weeks and have done so since the start of the project. That's part of how we have achieved the timescales. We can't ask more of them than that. Anything that we do that isn't on the plan is a very direct hit on producing the bitsream and other support work for the bulk of our customers. A further point is adding another variable to support i.e. the ET bitstream will further impact progress by virtue of more support calls. If I read it right ET just said he has taken 1 week to get his own very known setup to work again. What's that going to be like for a customer that doesn't have the technical knowledge he has or we have on the products. It's a nightmare basically. We might end up having our team work a week on one customer installation as is and still not have a solution. That's why we are not jumping into the unknown just yet. I'm not in any way saying ET can't do his stuff and sort it out but what I don't what to see is our own progress complete stopped to support a third party. It's not even good for ET to introduce another variable to try and support. As far as I am aware he doesn't even have a Cairnsmore1 to replicate problems on and allow debug of his IP.

The Rev 1.2 is already coming out of beta and is now frozen. We did a before and after test on approximately 50 boards yesterday and it looked good on every one. That taken with a few reports in from customers gives us every reason to make it the default build for now and that switch on the line is already in place. Rev 1.1 is fine as far as we know for 3rd parties but there is no work to support that. Rev 1.2 we know is better and deosn't make any difference to the interface for 3rd party developers.

After reading last posts , I have a doubt :

I 've understood that v1.2 controller  is not needed if you are going to use EP bitstreams ( present and future versions) .

or it will be a must in future quad version bitstream (or thirdparty one) , when it (controller) becomes a non beta version?  


Thank you.

ET says he can always add more servers on demand. Because of the commission (or "fee") he should have quite an interest that his service is operating smoothly and every CM user using his service is one of the best things that could happen to him, I think.

No one is saying it's easy.

How much resources can it really demand, asfar as I understand all he needs is the driver code.
[edit]
"But if they submit a driver for their proprietary USB interface (i.e. a Java class implementing MiningChip) I will certainly include it.  Until then carinsmore supported via JTAG like all other boards.
"
https://bitcointalksearch.org/topic/m.1009527

While I have every faith in you being able to provide a nice bitstream eventually, the sad truth is that the boards I bought are less likeley to ever see a full return of investment every passing day and if infact all eldentyrell needs from you is the driver source and your not providing it to him I feel like you owe us an explanation as to why. Were all grownups here and even if we dont like the explanation Im sure we can deal with it.

Yohan,

I'd really like to provide you with valuable error reports to help your team sorting out the problems, but after the last incident I need to start from the beginning

As I reported, I had a setup with 26 almost stable working CM1 boards in dual Icarus mode. Over the weekend I disassembled the setup to stack the boards and after re-assembling it I found the non deterministic behavior I already saw with the defunct units I sorted out. Some boards failed the golden nonce test, others caused Linux to hang while trying to set COM parameters, or others that start mining with a very low hashrate.

Being aware that the units worked before, I started again monkey testing: varying USB cables, hubs, ports, etc. in a fully random manner. For me it turned out that some boards work with a very specific setup, like: only with one specific USB cable connected to a passive hub that is connected to a powered hub at a given port As soon as I change cable or plug into a different USB port, the golden nonce test fails or other errors occur.

If I had a clue on HW design I would check whether the FTDI chip is correctly assembled, but since I don't I can only speculate that there is some systematic problem with this component. It is hard to believe that you did not encounter this issue during your testing, when from my batch every second board is fragile.

I spent so much time now getting my boards to work, but since it turned out to be such fragile and non deterministic, I lost motivation to dig deeper. Hope this will be solved once the up/down functionality is supported.


Have a nice day.

No doubts. The only problem we had was 100MHz clocking and we didn't need that. It's now fixed with the Rev 1.2 controller.

Just wanted an update, you got really quiet on the bitstream front after keeping us so up to date.
Seems likely you would have developed something inhouse by now to ensure that all 4 chips are actually functional.

I wasnt complaining, just pointing out it seems suspicious how quiet you have gone about the bitstream.
I take it from your outburst that I have hit a nerve, hopefully its not indicative of some underlying issue that you have not been to resolve.

kind regards

I DON'T THINK YOU ARE NOT EVEN A CUSTOMER SO WHY ARE YOU COMPLAINING. YOU WERE ONE OF THE TINY FEW THAT JUMPED SHIP ON ***S ANNOUNCEMENT.

To put matters straight we did not say we would start our own bitstream development at the beginning of this process and indeed people we talked to privately we told them we would have very little resources for this in May and only a little in June. I think I said quite a lot of this in this forum as well. We have more or less kept to that schedule and we have only really had a reasonable resourcing on this for 2-3 weeks now. Ok we made a small mistake on the wiring to the second chip and the original plan of dropping in an Icarus bitstream initially into all positions didn't quite work and that was our mistake. However it was a reasonable engineering decision to fix this with our own bitstream as the fastest way to sort the issue. The Icarus bitstream was only ever a temporary solution and I think that was made clear.

I have also said that for bitstream development it isn't easy to put a precise time on and yes I might have said a few days and maybe I should have said a few weeks. This isn't a process we can do a percentage complete number on with any accuracy. Unlike a lot of FPGA things we do this function with either work or it won't there is no partial working stage to give a measure on and it will simply be working one morning when I get in the office. Do remember too it is only 10 weeks and 4 days since we announced the concept and we probably have the best FPGA hardware platform designed but have manufactured and delivered hundreds of them to customers in that timeframe. I don't want to hark on about that but most professional engineers in the electronics business would either say that was either impossible or very unlikely that it could be done.

As to ET's bitstream that has barely been working for more than a handful of days on one of Ztex's boards and has had a pile of problems on there over those days. We are watching how this develops and I am sure he will sort out the issues. We could sink our entire resource into supporting that now but it's no guarantee that it will work any quicker and if it did his server might well collapse under the weight of Cairnsmore1s trying to use the server services. That would also bring our own develop to a complete halt which would not be good and we have a pile of customers that simply don't want to be forced down that route. So this is something we have to balance our time on. When the ET solution is slightly more stable will be the time to some work.

Also as far as I understand ETs solution can't support multiple units working together as yet. We don't have any problems with customers using this bitstream as such and we will do our best to support it. We do believe we have the best chance of any of the FPGA boards of being able to support that bitstream given our power and cooling systems but right now it looks like a pile of development work and server hardware to install before it is actually a viable solution. I will have a look at what he needs once I find a utility to open a jar file and see if we can do anything quickly. If it is days of work then it won't happen this week for an unstable solution the time is better spent stabilising our own product and we have made good progress this week already with the new controller update.

Indeed, its becoming a bit suspicious now ...  even a low speed quad stream would be good ...

+3!
This should of have been done forever ago. No matter how much enterpoint considers it a distraction from their own bitstream which has been "a few days away" since god knows when, may 27th ?

Also yohan can you please fill out the TML BDK? http://www.tricone-mining.com/bdk.html as ET will not implement native usb support without one filled out.

Whats the progress on the bitstream yohan ?

kind regards

Round up for today was that we day excellent results with the Rev 1.2 Controller at several different levels including the best utility factor we have see with the twin bitstream. Absolutely no adverse effects have been seen with the new controller either and we will start using this on the line from tomorrow for boards going through the final assembly/test line.

We will continue to look at the other driver/CGminer issues and updates on those as we find out more.

I made a change to my USB port in Windows and disabled any power savings.  Each core is still up and running and has not powered off yet, they have submitted about 4500 shares each.  It used to crap out around 1100 shares each core. 

I programmed mine using the dipswich setting for twin_test stream operating mode, with the exception of turning the dipswiches in the picture, like they are in the picture. Everything appeared to go well, the programming finished without errors and the board is no worse than it was before.

[/quote]

Ok, now I'm even more confused, that's exactly where I got the info from. The problem with the loader PDF document in that zip is it doesn't show you what SW  2, 3, 4, and 5 are supposed to be set to, so I assumed they should all be off. Maybe that's why I never got the last one working.

Can you look at that document and make give me the exact switch settings for the controller update? Id like to try one more time on the broken board. I'm going to drop it off for shipment back to you guys tomorrow as well.

Also I'm using Linux currently and the new board you sent seems to be working great with the FTDI drivers and Cgminer 2.4.3 without any modifications.

Thanks,

Doff
[/quote]

Ok I will try and rework the document to make this clearer. Meanwhile have a look at the pictures on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html. The dip switch numbers have been made bigger and clearer on these.

If anything (and it's propably too early to say) the update made my slow-cored unit worse. As I am typing this in CM0 has 44 shares and CM1 has 2, neither shows rejects. The core used to be able to push out roughly one tenth of the first cores shares. But like I said it's too early to say, I will fill in more credible numbers in some hours.
[edit]
453/16 shares 1/0 rejects, no hardware errors.
1000/35 shares 2/0 rejects, no harware errors.
So in my case this made no difference whatsoever.
[edit2]
2485/77 shares 4/0 rejects, no harware errors.
... and now on to the interesting part, I will now chuck all the boards to work in the same Cgminer instance, to demonstrate how the slow core will start producing more shares, or as I believe it to be CGminer reporting shares to wrong cores.

That WOULD explain a lot of problems.