Quote from: Wipeout2097 on January 24, 2014, 07:07:39 AM

Quote from: rezilient on January 23, 2014, 10:08:14 PM

Does anyone know why they'd be able to release a BTC+LTC asic a lot easier than an exclusive LTC asic? There is a huge arms race right now in the LTC world for the first ASIC so I don't understand why these guys wouldn't go "all in" on a LTC asic. They would be the first, and reap huge rewards for that.

Because scrypt requires SHA2 circuitry anyway. SHA2 related transistors would be in the chip, idling 90% of the time. Why not use that part of the chip to mine BTC during those idle cycles?

What they can fine tune is how many SHA2 units they choose to put in a chip, to control die area and costs. That has to do with it's size vs the rest of the required logic. If they are small, why not?

I'm doubtful that any of the SHA256-dual hashers are shared between the BTC and LTC cores. The spec shows 160 BTC units and 4 LTC units. Each of the LTC units will contain perhaps one or two SHA256-single non-midstate hashers and these need not be fully unrolled pipelines either as the time required to compute the PBKDF2 hash is very short compared to the salsa hash. It would be just too much trouble to share the SHA256 hashers between the BTC and LTC cores (time is money in ASIC design, it would not be cost effective to do it this way).

I agree that the LTC cores are prototypes. My guess is that GridSeed had a foundry slot available for the BTC ASIC, so decided to add a prototype LTC hash design to the die. This would have been quite expensive in area as the embedded RAM would take up significant space, but its a sensible decision as it gives them a huge advantage in being first to market. I'll be interested to see what their next-generation pure LTC ASIC will do (I think we can assume one is in the pipeline).