I have been thinking about it, I don't know if my line of thinking is right or not, but I just want to throw it out for your guys to critique and correct me where I'm wrong.
Here we go: These are built for Scrypt mining first right? So in order to maximize efficiency for Scrypt mining, there must be a balance between hashing cores and the amount of memory. Too many cores and not enough memory, you are not utilizing your cores to their potential. Too much memory and too little cores, die space is wasted.
So in the case of Scrypt mining (n=10), one would assume that the amount of memory available to the cores are exactly how much the cores need in order to maximize die space efficiency. You wouldn't want more memory than needed because that takes up precious die space, so we can assume the memory shipped is fixed exactly at how much n=10 mining needs.
Let's assume then that core:memory ratio is 1:1 to maximize die efficiency. When we look at n=11, the amount of memory needed per core is doubled. However, because fixed memory was specifically allocated for cores running at n=10, you now find yourself with "half" the usable memory since each core uses up double the memory. Now at n=11, your core:memory requirement is 1:2, and with a fixed amount of memory it means only half your total number of cores are utilized.
Looking at GPUs we have today, switching to n=11 immediately halves the hashrate and that is considering we have an abundance of memory. That means in the case of these "ASICs", mining at n=11 is probably going to cut the hash rate by 1/4, and another 1/4 for each increase in N Value.
One workaround is of course to provide more memory as overhead, but memory is expensive and die space is limited. As primarily Scrypt ASICs, it wouldn't make sense to increase production costs or by crippling Scrypt hashrates since that's what they are meant to do in the first place.
Of course all this is assuming reprogramming for Scrypt-N ASICs is even possible.
Again, this is what I think. It may or may not be wrong. Criticism is welcomed and I would gladly learn from others who have input on this matter.
Edit: Shitty drawing I made in paint to help visualize.
https://i.imgur.com/EWhWDMI.png[1]
yes, you are right, and it was confirmed by Mark (aka kramble) :
"It depends very much on the architecture that has been chosen for the ASIC. If they are using a massively-multiple core architecture, with a small RAM attached to each core, then the scope for supporting increased N is limited to increasing the interpolation (LOOKUP_GAP) factor, which very rapidly runs out of steam with perhaps 8192 being the practical limit. I was able to test this in my open-source FPGA code quite easily for N=2048, and it gave roughly one quarter of the hash rate of the original N=1024 scrypt" https://litecointalk.org/index.php?topic=17548.msg146942#msg146942I have some early research with two GPU miners developers and there is some hope with not used yet algo - for strong suppressing ASIC
if current scrypt-n solution would fail, we can go back to this
btw: yacoin has N=32768, and it seems is still GPU mineable
http://download.muuttuja.org/yacoin/countdown/