is there the same silicon chip used in different housings
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?
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.
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, ...
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?
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.
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?
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.
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?
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.
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.
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
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.
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?
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.
New Contributor
