EP4CE6 and EP4CE10, same device?

I was looking over the handbook, and I made a strange discovery.
The Altera Cyclone IV EP4CE6 and EP4CE10 has the same bitstream size, and the same IDCODE. Even looking at the chip planner, they look identical.

I was wondering if they are in reality the exact same device, labelled under different markings for market segmentation purpose. Has anyone tried loading an EP4CE10 bitstream in an EP4CE6? Would it work? What is there to stop doing it? Is there some factory-set register or laser-etched trace in the chip preventing doing it (ex, looking at the bitstream target device upon loading configuration bitstream)?

The same goes for EP4CE30 and EP4CE40 by the way.

Regards,
Big Boy

Altera has done this before. They sometimes use the same die for multiple devices in a family. I don't know exactly what they do to prevent one from using a smaller device as a bigger device, but I was informed they only test the smaller devices for the logic that is accessible in the smaller device. Since that is the case there could conceivably be defects in the die that are for the larger device.

Beyond that I don't know much else.

Yes, I taught about defects, or binning, as this usually is the case with other devices line multi-core CPU, where they disable some defective cores. The thing is that it's logical with CPU, which have very clear cut boundaries between the core (use the whole core, or disable it if there's a defect in it). But in FPGA there's no such boundaries. The compiler will spread the design across the whole FPGA. If a gate is not functional, then they can nos simply bin it as a lower gate count part, as any design is free to use any of the gates. So, I don't think this is because of yield problem.

You are right, looking at other parts, there are a few others that are similar, like EP2C15/EP2C20, EP3C5/EP3C10, etc!

If you look at Cyclone V E, the A2 and A4 also has the same size, but they differ in IDCODE. Same goes for Cyclone V E A5 and Cyclone V GX C4/C5 (the latter having transceiver, although here, it could be discarded as A5 due to defective transceiver).

Interesting!

Thanks.

Big Boy said:

The thing is that it's logical with CPU, which have very clear cut boundaries between the core (use the whole core, or disable it if there's a defect in it). But in FPGA there's no such boundaries. The compiler will spread the design across the whole FPGA. If a gate is not functional, then they can nos simply bin it as a lower gate count part, as any design is free to use any of the gates. So, I don't think this is because of yield problem.

Click to expand...

You missed my point, the smaller part uses the same die as a larger part but the tools would know the part is the smaller part and won't put logic in certain sectors/regions of the die as they are not "available". If the IDCODE of the smaller part is identical to the larger part you might get away with programming it with a file generated in the tools using a larger part (as long as they share a common package), but as I understand from a offhand comment of an FAE the smaller part won't be tested as a larger part so there could be hidden defects in the die in those untested regions that the smaller part does not use.

Regards