is there the same silicon chip used in different housings

[CS72]

Hi, 

if one can buy the same size in different housings, will the chip be the same for the housing with lowest and highest Pin Count?

Would e.g. same silicon chip being housed in 484Pin BGA (i.e. having xyz IO) used in the 240Pin QFP with "just" not connected IO cells due to lower pin count?

[FvM]

Answer is yes.

What is the question behind? What do you want to achieve?

[CS72]

Hi, 

thanks for the quick response. 
The Idea behind is to minimize (to zero?) the changes in the configuration data when switiching the housing (due to availability from the currently used QFP to an BGA) by assigning the matching BGA pin to the signal currently assigned to the 240'er housing pins.

Assignment of the BGA Pin being bonded to the IO cell used for the signal with the QFP should (imho) result in same configuration data, as the silicon is identical and thus the IO cell "does not know" if the signal is connected to QFP PinX or BGA Pin Y...

We have a tested and many years in service proven programming which should be ported to a BGA housing with better availability meanwhile. 

Thus, I think a crossreference would be the way forward, like QFP PinX => BGA PinY, ... 

[CS72]

Hi, 

I used the BSDL files for the different housings to generate a cross-reference, changed the target device and edited the Pin Assigments. I would have expected to get the same configuration file by this, but it's different. 

Is the device ID coded within the POF File? I assume not, if the same chip is used... Would the BGA be programmable with the unchanged QFP configuration file?

[EthanLi]

Hi,

I am not sure if the two chips are pin to pin migration or not. Please check the pin-out file for the details.

https://www.intel.com/content/www/us/en/support/programmable/support-resources/devices/lit-dp.html

For the configuration file, like sof, pof, and jic etc. there is the information of the quartus version and the device id in the header. So I don't think it could be the same between any different OPNs.

Thanks,

Ethan

[CS72]

Hi Ethan, 

the PinOut Files include power, GND, MSEL, JTAG, ... but no cross-ref for the user I/O Pins. Nevertheless, if the sof and pof include the device ID (more than family and size but also package?) they cannot be identical for sure.

As the programmer in JTAG mode and Auto-Detect does not include package information, I would assume these are not coded in HW (if the silicon is same, it cannot be harware coded imho). Thus, the BGA should accept the pof generated for the RQFP, shouldn't it?

Thanks and KR

[EthanLi]

Hi,

As far as I know, the Jtag could get a jtag id while auto detecting, and the jtag id is unique for each package. 

What is the specific OPN for the two devices(QFP and BGA)?

You could check the jtag id in the "pgm_parts.txt" located in Quartus install path.

./quartus/bin64

Via Jtag, you could check the header of the configuration file pof, sof or jic.

I think you could try to configure with rbf or rpd file if the header is the gate.

Thanks,

Ethan

[CS72]

Hi, 

this is the extract from the pgm_parts.txt file from Quartus 9.0 for the device: 

EPF10K100A     88 20 18 15   0 EPF10K100A 0 0 10 0 1 0x001000DD 0xFFFFFFFF 0 155/000 0
EPF10K100AB356 88 20 18  1 356 EPF10K100A 0 0 10 0 1 0x001000DD 0xFFFFFFFF 0 155/000 0
EPF10K100AB600 88 20 18  1 600 EPF10K100A 0 0 10 0 1 0x001000DD 0xFFFFFFFF 0 155/000 0
EPF10K100AF484 88 20 18  4 484 EPF10K100A 0 0 10 0 1 0x001000DD 0xFFFFFFFF 0 155/000 0
EPF10K100AR240 88 20 18 12 240 EPF10K100A 0 0 10 0 1 0x001000DD 0xFFFFFFFF 0 155/000 0

I assume the 0x001000DD is the device ID, i.e. identical for all housings... 

The POF on the other hand includes in the header complete device ID (with housing and speed grade).

The two devices are in detail the (currently used) EPF10K100ARI240-3 and the (intended) EPF10K100AFI484-3.

[WZ2]

Hi there,

I wanted to check if you have any further questions or concerns. If not, I will go ahead and mark this issue as resolved.

Additionally, we would greatly appreciate it if you could take a moment to fill out our survey. Your feedback is valuable to us and helps us improve our support quality.

Thank you for your time and cooperation.

Best regards,
WZ

[WZ2]

Hi there,

Apologies for the confusion. Due to Ethan's job change, I'm stepping in to address your concerns. First and foremost, let me clarify: are you looking to interchange between different packages of the same device? Are you seeking a pin-to-pin reference?

1. If I understand correctly, unfortunately, we do not have similar documentation or references, as this idea is rather unconventional. It's more common to migrate between devices of the same series but different performances within the same package, and we do have documentation for such cases.

2. Additionally, I'd like to clarify the differences you mentioned between the configuration files you've generated. Could you please specify in which aspects these differences are reflected? If you could provide information and screenshots in this regard, perhaps we can discuss further.

Best regards, WZ

[CS72]

Hi, 

for sure this idea is very strange, as it requires a custom made PCB to interconnect the BGA Pins with the QFP pads on the existing hardware. Something you would not think of in "normal" designs But a redesign of the hardware for direct assembly of the BGA is no option, being high-effort, ... of a proven in use design. 

The "normal an intended" way is using the vertical migration feature, supporting different logic sizes being placed on same PCB, depending on the application's need. 

In this special case, the problem is a combination of obsolescence and need to support old hardware. The original used FLEX10K is a 10K100ARI, i.e., a RQFP240 pin device. Being obsolete for many years now, we are meanwhile also running out of stock at Brookers. 
The 10K100 has been offered in the 484BGA (10K100AFI). To keep credits from the many years proven in use design, we would also like to re-use the programming file as is. 

If the chip "inside" in the different housings (RQFP and BGA) is the same silicon, with just more or less I/O cells being bonded to I/O pins (depending on the housing), the original programming file should configure the BGA packed chip as well, shouldn't it?
(The silicon is not aware of the housing used...)

With the cross-reference between RQFP Pin to BGA Pin, the adapter board should be designed to connect the correct pins and thus, the BGA on the adapter should be identical to the original RQFP housed device w/o any change of the programming file imho...

To prove this idea, I created a reference using the BDSL files, using the Boundary Scan Cell information section. 

RQFP Pin6 = BGA Pin C22

...

Changing the target device and updating the pin-assigments accordingly, the *.pof is different... Using a HexEditor to open the *.pof this is shown in the target device being part of the datastream, originally the ARI240, noe the AFI484. 
If this is not part of the "real" configuration data for the chip ("just" information showing up in the programmer window?), this mismatch when using the original *.pof with the BGA should not prevent configuration and with the correct PCB between the original HW and the BGA housing the "ARI240 targeting" POF should be fine, shouldn't it?

Many thanks taking time to support this strange issue

KR 

[WZ2]

Hi there,

Your explanation helped me understand your point. I have to say it's a bold idea, and I believe it's feasible. However, I must admit it's something that has never been experimented with before.

Regarding your confusion, since I haven't seen your POF, I can only speculate where the differences might lie. It's uncertain if it involves differences in routing information.

Best regards,

WZ

[CS72]

Hi, 

here is a screenshot of a comparison between the both *.pof files - they differ not only in the first lines including the device name, but also all through the imho configuration data... 

While the original file is dated 2007 a recompilation with current machine gives identical file, i.e., the difference seems not to be related to the machine but the fitting algorithm being different? 

KR, Carlhermann 

[WZ2]

Hi there,

Yes, I believe the differences may occur in the instantiation of resource distribution and routing variations. However, these data themselves cannot be reverse-analyzed for resolution. Since such use cases are rare and there are no precedents, nor any forward analysis data or experience available for reference, my suggestion is to experiment to verify.

Of course, before proceeding with a major project burn, you can first select a few I/Os (please confirm if there are test pins on the board) for speculative validation, while ensuring to avoid damage during the process.

Best regards,

WZ