Anyone who is looking to load Rev 1.4 of the Controller please don't currently. It looks like we have somehow broken the programmer with this version. I will update you all when we know more.
Oh dear...
Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 33. (Read 286370 times)
Oh dear...
Anyone who is looking to load Rev 1.4 of the Controller please don't currently. It looks like we have somehow broken the programmer with this version. I will update you all when we know more.
Something strange with controller Rev 1.4:
- Actually I can't revert back to controller Rev 1.3 from Rev. 1.4 with SPIprog.exe via USB.
- I can't flash array FPGA's with xc3sprog via USB.
Have someone else this problem? As far as I know, I need only SWITCH6 off, all others on. I tested with ribbon cable disconnected also. The board I want to flash is MASTER.
eb
- Actually I can't revert back to controller Rev 1.3 from Rev. 1.4 with SPIprog.exe via USB.
- I can't flash array FPGA's with xc3sprog via USB.
Have someone else this problem? As far as I know, I need only SWITCH6 off, all others on. I tested with ribbon cable disconnected also. The board I want to flash is MASTER.
eb
OK, that was weird. I just had to power down the machine I had the CM1 connected to to upgrade its RAM, and once I powered everything up again it kept failing the MPBM test job in strange ways until I connected the USB connector before the power connector. Power-cycling the entire board several times but connecting them in the opposite order didn't help. Power-cycling just the array FPGAs using switch 1 also didn't help.
Controller rev. 1.4 is working. Nothing changed about stability or other unexpected things. Everything work as it should.
Here is a photo of my rig now with UP/DOWN Ribbon cables hashing away with 8,1Gh/s and only 5 USB cables:
More photos here
Thank you Yohan, that was really needed! =D
eb
Here is a photo of my rig now with UP/DOWN Ribbon cables hashing away with 8,1Gh/s and only 5 USB cables:
More photos here
Thank you Yohan, that was really needed! =D
eb
Is it just me or is some piece of the puzzle missing, I mean ductaping two boards together and tossing out one usb-cable wont be likeley to work.
Well that Ribbon cable as glasswalker just mention is part of it yes, they do need to be connected to each other.
Think of it abit like how multiple hard drives used to configured back in the day of IDE, where you specifically had to setup a master or slave for them, each of the 2 drives on the cable. Auto didn't work all that well for quiet a while.
But with this they are physically connected to your pc, down a single cable to the first one (master), then with another cable between each other (slave).
Personally I didn't opt for this, I figured it was overcomplicating it. I only had 2 CM1's and have way more than 2 usb ports available.
If their is more to it than 1.4, like improved stability, I'll give it an update.
This one is really for bigger rigs at the moment. It's main benefit is a reduction in the number of USB ports used and hence hubs needed to get all of this going. It does not reduce the number of com ports.
The next stage is basically an extension of Icarus pairs and we might look at say having 16 FPGAs work together over 4 boards on a single com. That reduces both the number of com ports and USB leads and will probably make life more simple for rig setup. It's possible that some performance may be gained this way as well but we will have to see on that.
Is it just me or is some piece of the puzzle missing, I mean ductaping two boards together and tossing out one usb-cable wont be likeley to work.
Well that Ribbon cable as glasswalker just mention is part of it yes, they do need to be connected to each other.
Think of it abit like how multiple hard drives used to configured back in the day of IDE, where you specifically had to setup a master or slave for them, each of the 2 drives on the cable. Auto didn't work all that well for quiet a while.
But with this they are physically connected to your pc, down a single cable to the first one (master), then with another cable between each other (slave).
Personally I didn't opt for this, I figured it was overcomplicating it. I only had 2 CM1's and have way more than 2 usb ports available.
If their is more to it than 1.4, like improved stability, I'll give it an update.
you mean the ribbon cable between the UP/DOWN ports on the board? Of course that would be required for this to work.
We should be making Rev 1.4 of the Controller available later today or tomorrow if our testing today goes ok. The main feature of this build is the first usage of the up/down cabling and it is a very simple implementation that we have done to use it. With Rev 1.4 you have the option to pair up boards to use a single USB interface. On the Master board all 4 com ports are used to support 4 pairs of FPGA 2 pairs on the Master and 2 pairs on the Slave. So long and short of it is that you get to use half the USB cables that you needed previously.
If you don't want to use up/down cabling Rev 1.4 will operate pretty much as Rev 1.3. There is 1 dip switch change for Master/Slave selection but otherwise pretty much what you have seen in Rev 1.3.
We are still looking at the implementation of more complicated schemes that will use up/down for either bigger board clusters or even an entire rig and that will come later. Meanwhile the Rev 1,4 will hopefully make it a bit simplier on the USB setup for all of you with multiple boards setups.
We are also experimenting with removing the power feed from USB to the controller to see if it is just better to power the Controller always from the 12V feed. There is a possibility that might cause an ennumeration issue so it's not confirmed we will do this yet but if does look the better configuration we will cut that in to production on boards serial number 0700+.
We are also closing the general pre-order now with the general intention that it will become a stocked item from October onwards. Large orders will possibly still have a lead time and also tend to clean out available stock so it won't always be immediately available.
If you don't want to use up/down cabling Rev 1.4 will operate pretty much as Rev 1.3. There is 1 dip switch change for Master/Slave selection but otherwise pretty much what you have seen in Rev 1.3.
We are still looking at the implementation of more complicated schemes that will use up/down for either bigger board clusters or even an entire rig and that will come later. Meanwhile the Rev 1,4 will hopefully make it a bit simplier on the USB setup for all of you with multiple boards setups.
We are also experimenting with removing the power feed from USB to the controller to see if it is just better to power the Controller always from the 12V feed. There is a possibility that might cause an ennumeration issue so it's not confirmed we will do this yet but if does look the better configuration we will cut that in to production on boards serial number 0700+.
We are also closing the general pre-order now with the general intention that it will become a stocked item from October onwards. Large orders will possibly still have a lead time and also tend to clean out available stock so it won't always be immediately available.
That is what it's good for Isokivi. Mostly it was an update for those with a lot of boards.
We should be making Rev 1.4 of the Controller available later today or tomorrow if our testing today goes ok. The main feature of this build is the first usage of the up/down cabling and it is a very simple implementation that we have done to use it. With Rev 1.4 you have the option to pair up boards to use a single USB interface. On the Master board all 4 com ports are used to support 4 pairs of FPGA 2 pairs on the Master and 2 pairs on the Slave. So long and short of it is that you get to use half the USB cables that you needed previously.
If you don't want to use up/down cabling Rev 1.4 will operate pretty much as Rev 1.3. There is 1 dip switch change for Master/Slave selection but otherwise pretty much what you have seen in Rev 1.3.
We are still looking at the implementation of more complicated schemes that will use up/down for either bigger board clusters or even an entire rig and that will come later. Meanwhile the Rev 1,4 will hopefully make it a bit simplier on the USB setup for all of you with multiple boards setups.
We are also experimenting with removing the power feed from USB to the controller to see if it is just better to power the Controller always from the 12V feed. There is a possibility that might cause an ennumeration issue so it's not confirmed we will do this yet but if does look the better configuration we will cut that in to production on boards serial number 0700+.
We are also closing the general pre-order now with the general intention that it will become a stocked item from October onwards. Large orders will possibly still have a lead time and also tend to clean out available stock so it won't always be immediately available.
If you don't want to use up/down cabling Rev 1.4 will operate pretty much as Rev 1.3. There is 1 dip switch change for Master/Slave selection but otherwise pretty much what you have seen in Rev 1.3.
We are still looking at the implementation of more complicated schemes that will use up/down for either bigger board clusters or even an entire rig and that will come later. Meanwhile the Rev 1,4 will hopefully make it a bit simplier on the USB setup for all of you with multiple boards setups.
We are also experimenting with removing the power feed from USB to the controller to see if it is just better to power the Controller always from the 12V feed. There is a possibility that might cause an ennumeration issue so it's not confirmed we will do this yet but if does look the better configuration we will cut that in to production on boards serial number 0700+.
We are also closing the general pre-order now with the general intention that it will become a stocked item from October onwards. Large orders will possibly still have a lead time and also tend to clean out available stock so it won't always be immediately available.
That is what it's good for Isokivi. Mostly it was an update for those with a lot of boards.
Rev 1.4 of the Controller is now available.
Dip switches as follows:
Dip switches as follows:
And whats this good for ?
One question about the new controller:
When the controller is updated, how would work the flash of the array fpga's of the Slave board? Do we still need to connect the USB cable for flash or is it working with the one USB from the Master board and the xc3sprog option -p4, -p5, -p6, -p7?
eb
When the controller is updated, how would work the flash of the array fpga's of the Slave board? Do we still need to connect the USB cable for flash or is it working with the one USB from the Master board and the xc3sprog option -p4, -p5, -p6, -p7?
eb
Rev 1.4 of the Controller is now available.
Dip switches as follows:
Dip switches as follows:
We are also experimenting with removing the power feed from USB to the controller to see if it is just better to power the Controller always from the 12V feed. There is a possibility that might cause an ennumeration issue so it's not confirmed we will do this yet but if does look the better configuration we will cut that in to production on boards serial number 0700+.
PS. Apropos usb power: I'm using now a powered (but I don't power it) no-name 10 ports usb hub which works very well because it does not take power from its usb cable (I don't know if it has no power wire inside) and/or it does not deliver the power it takes to its own usb ports.
I believe it has to be like this because I cannot attach more than three boards to my host PC if I don't power them (PC freezes) while right now I have all of them connected and hashing happily since at least a couple of weeks.
So, I'd say, cutting the power line should make things easier for new users.
I'm having this usb issues from the beggining and after buying new powered usb hubs D-LINK ,they are unusable if i power them., just like spiccioli.
testconpastas,
what happens if you DON'T plug into your usb hub its power cord?
they work fine but sometimes randomly (maybe one time after 2days or maybe after some hours) usb devices disconnected. and i have to turn off PSU to recover them
Try this with just ONE board plugged into your usb hub and then with two and so on.
in my 7 port usb hub without power cable i have 6 cm1 working almost ok (except some random disconnections)
If your hub works like mine you'll be able to attach all the boards to your hub without problems, otherwise after two or three boards your host PC should start having problems (slows down to a crawl/freezes altogether).
Im working with a powered usb hub ( but with power cable disconnected) from the begining because if I "power" it my usb drivers fails to install and do strange things. my usb hub unpowered works almost fine except some random disconnections.
maybe my motherboard GA P55A ud5 with 1500ma usb instead of 500 is the cause I could use unpowered usb hub ok
Beware, if your usb hub takes power from its usb cable and then gives this power to its usb ports, you could end up damaging the usb port in your host pc and/or your boards.
I know that but thanks . but i dont know where in this thread i've read that cm1 usb isnt used to feed boards and has low energy consuption. what scares me more is some kind of uncontrolled feedback current to my board but what I hope is my usb hub has some kind of filter/ diode to avoid that .
I'm not resposible for any damage arising from this test!!!
spiccioli.
Anyone is using that "disabled" (cut wire 5v ??) cable and fixed their/my problem??
With Rev 1.4 you have the option to pair up boards to use a single USB interface. On the Master board all 4 com ports are used to support 4 pairs of FPGA 2 pairs on the Master and 2 pairs on the Slave. So long and short of it is that you get to use half the USB cables that you needed previously.
Nice and even better you won't have to guess which 2 ports are randomly used by windows and so you won't have to change cgminer -S option
thank you.
We are also experimenting with removing the power feed from USB to the controller to see if it is just better to power the Controller always from the 12V feed. There is a possibility that might cause an ennumeration issue so it's not confirmed we will do this yet but if does look the better configuration we will cut that in to production on boards serial number 0700+.
PS. Apropos usb power: I'm using now a powered (but I don't power it) no-name 10 ports usb hub which works very well because it does not take power from its usb cable (I don't know if it has no power wire inside) and/or it does not deliver the power it takes to its own usb ports.
I believe it has to be like this because I cannot attach more than three boards to my host PC if I don't power them (PC freezes) while right now I have all of them connected and hashing happily since at least a couple of weeks.
So, I'd say, cutting the power line should make things easier for new users.
I'm having this usb issues from the beggining and after buying new powered usb hubs D-LINK ,they are unusable if i power them., just like spiccioli.
testconpastas,
what happens if you DON'T plug into your usb hub its power cord?
Try this with just ONE board plugged into your usb hub and then with two and so on.
If your hub works like mine you'll be able to attach all the boards to your hub without problems, otherwise after two or three boards your host PC should start having problems (slows down to a crawl/freezes altogether).
Beware, if your usb hub takes power from its usb cable and then gives this power to its usb ports, you could end up damaging the usb port in your host pc and/or your boards.
I'm not resposible for any damage arising from this test!!!
spiccioli.
We are also experimenting with removing the power feed from USB to the controller to see if it is just better to power the Controller always from the 12V feed. There is a possibility that might cause an ennumeration issue so it's not confirmed we will do this yet but if does look the better configuration we will cut that in to production on boards serial number 0700+.
PS. Apropos usb power: I'm using now a powered (but I don't power it) no-name 10 ports usb hub which works very well because it does not take power from its usb cable (I don't know if it has no power wire inside) and/or it does not deliver the power it takes to its own usb ports.
I believe it has to be like this because I cannot attach more than three boards to my host PC if I don't power them (PC freezes) while right now I have all of them connected and hashing happily since at least a couple of weeks.
So, I'd say, cutting the power line should make things easier for new users.
I'm having this usb issues from the beggining and after buying new powered usb hubs D-LINK ,they are unusable if i power them., just like spiccioli.
my boards are 62- (~140 ...150) I've read about the usb cable fix but i dont have clear how to make it.
will there in future controllers, a fix for that? or must i think about "cutting" ( i dont know what part ) usb cable??
thank you.
PS:: after adding extra fans now my rig works a lot of better, ( i had a temp problem) but still having some usb disconnections.
We should be making Rev 1.4 of the Controller available later today or tomorrow if our testing today goes ok.
Yohan,
btw, there are a few things I'd like to ask:
- any way to flash the new controller firmware using some linux tool?
- toggling SW1 switch 1 does reset the board, but the host PC does not receive a usb unplug/plug event. Can such an event be "delivered"?
- right now controller rev. 1.3 stops a FPGA when the fan does not work, can you make it stop FPGAs if their temperature rises too much? EDIT: maybe adding some led flashing so that we know what's going on.
spiccioli.
Linux programming for the Controller is a problem in that every solution we have looked at involves a paid license. I'm told there is a problem with the FTDI drivers for Linux in that unlike Windows the VCP and V2XX drivers can't coexist in most cases. However there is a documentation contracdiction and small possibility coexistance because we have a customised PID and this restriction this might not apply. At the moment we don't have much engineering resources available to do anything on this and it's unlikely we will make progress until September.
SW1 is only a reset to the FPGA logic as you say. The USB reset pin is directly related to power so there isn't a path available currently.
On Spartan-6s generally there is no good way to sense temperature. There are temperature sensors in the board next to each FPGA but the way these work is they need a bitstream design that will support them. I don't believe any are in public domain as yet although Glasswalker I believe is looking at that. Even working these sensors will have a large degree of inaccuracy over the die temperature of the Spartan-6 and of limited use. The most important thing in the cooling solution is to know when a fan is not operating and we have that covered already. With the fan running we normally see the heatsink at only 5-10 degrees C above ambient temperature. We expect the S6 die to be at 45 degrees C above the heatsink temperature when running the full 12A core current available and about 35 degress C running something about 10A which is about the maximum of Makomk or Glasswalker bitstreams currently. It's nearly impossible to verify these numbers on a board without major chip surgery and even then you are changing the environment for testing.
I now have shortfin_dcmwd4c_ed_test_200_overclock running on my SN 26 board. U is 11,53 after one hour.
We should be making Rev 1.4 of the Controller available later today or tomorrow if our testing today goes ok.
Yohan,
btw, there are a few things I'd like to ask:
- any way to flash the new controller firmware using some linux tool?
- toggling SW1 switch 1 does reset the board, but the host PC does not receive a usb unplug/plug event. Can such an event be "delivered"?
- right now controller rev. 1.3 stops a FPGA when the fan does not work, can you make it stop FPGAs if their temperature rises too much? EDIT: maybe adding some led flashing so that we know what's going on.
spiccioli.
Jump to: