TL/DR
Whatever the relative performance of this FPGA is to a CPU miner it would be WORSE if the p value was higher. LTC decision to use a low p value makes what otherwise would be a nearly impossible task into one which is merely challenging.
Whatever the relative performance of this FPGA is to a CPU miner it would be WORSE if the p value was higher. LTC decision to use a low p value makes what otherwise would be a nearly impossible task into one which is merely challenging.
I doubt it. You should have a look at Solar Designer's TMTO data with N=2^14, r=2^3, p=1.
As you can see, as memory exponentially decreases integer ops exponentially increase. He was easily able to get the memory usage into the kilobytes and still crank out hashes. I'd guess that exactly the same is true with N=2^10, r=1, p=1 too. It's the same balancing act you run into no matter what value you use for N or r; at higher N you may increase the difficulty by a smaller constant factor, but overall I doubt increasing N or r will make scrypt much more FPGA/ASIC unfriendly when they finally iron out the FPGA implementation.