Forum Discussion

2reSolve's avatar
2reSolve
Icon for New Contributor rankNew Contributor
2 years ago

10M08SCE144C8G Temperature Issues

Hi,

We're having some wird temperature issues with some newer 10M08SCE144C8G FPGA chips date marked with "2301A".

The FPGA chips are used in an older MUX design "which have always worked before".

Some of the "2301A" chips, however, does not operate as normal at 25C room temperature. However, if we apply external heating they suddenly start working as normal at arond 35-50C.

Looking at some of our older circuits boards without temperature problems, with FPGA chips date marked "2007A", I cannot help notice the text painted in white color is very easy to read:

Old, working FPGA. Please notice clear, white text.

Compared to examining the newer "2301A" boards, the one with temperature problems, the text is almost impossible to read, like the white paint inside the text is completely missing:

Newer, failed FPGA. Is the more unclear text a sign of soldering heat damage?

What's the most possible explonation:

1. The FPGA has been mounted using the wrong soldering profile with to high temperature

2. Intel has simply removed the white paint from its Altera MAX 10 chips. Nothing to worry about.

3. These are fake, chineese duplicates (and yes, these boards have been assembled in China).

Please advice.

Board Debug

14 Replies

  • matvr's avatar
    matvr
    Icon for New Contributor rankNew Contributor
    2 years ago

    Hi @2reSolve !

    Since you're switching from old "2007A" to recently manufactured "2301A" do you use the same binary for newer device which you have used for the older one? When was it compiled?

    I think you might also want to explain a little bit what you exactly mean by "does not operate as normal at 25C room temperature" since it may raise further thoughts on what might be going wrong in your case.

    BR, Matt

    • 2reSolve's avatar
      2reSolve
      Icon for New Contributor rankNew Contributor
      2 years ago

      Thanks for this input Matt.

      1. We will investigate this Errata carfully.

      2. Yes, same binary was used. The .pof compile date is 2016-06-07. We will look into re-compiling the project.

      3. Sorry. The FPGA does not work at all at 20-25C room temperature. But this only appy to about 1/3 of the 2301 dated FPGA units.

      We don't think the FPGA parts are fake, but we can't know 100% for sure they are not re-purposed/used parts.

      The firmware for these FPGA's was originally designed by an external consultant (as we lack in-house FPGA expertice).

      Sadly, this consultant is no longer available so we are now in contact with some other consultants to solve this.

      • matvr's avatar
        matvr
        Icon for New Contributor rankNew Contributor
        2 years ago

        1. For the Errata - I removed suggestion from previous post since I wrongly decoded the 2007 date code. It is never a bad thing to double check the issues from errata, though.

        2. For the binary I would suggest to try recompile the project since it is possible for adjustments in silicon production to affect timings of the FPGA and thus lead to some issues, for instance. Synthesiser should be able to fix this if it is indeed the case.

        3. Do you test the boards through all the product temperature range? For 33% not working could be some margin effects like capacitance change with temperature and not related to the FPGA at all.

        Still don't understand what do you mean by "FPGA does not work at all at 20-25C room temperature".
        For me it appears as if what you really mean by this is "FPGA doesn't fulfil the function that it is supposed to". But it doesn't mean that it does not work at all - the FPGA itself might be configured (let's call it "firmware running"), PLL generating clocks, input data handling but it could be at some dead end of the algorithm due to wrong timings, for instance.

        BR, Matt.

  • NazrulNaim_Intel's avatar
    NazrulNaim_Intel
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    Hello,

    Good day

    Thank you for reaching out. I'm Nazrul Naim looking into your issue and allow me some time to look into your issue. I shall come back to you with findings.

    Thank you for your patience.

    Best Regards,

    Nazrul Naim


  • 2reSolve's avatar
    2reSolve
    Icon for New Contributor rankNew Contributor
    2 years ago

    Hello Naim,

    Thanks for your attantion on this issue. Any info you may share which would help resolve this issue will be greatly appreciated.

    Meanwhile, as per FvM suggestions, we will have an FPGA expert characterize and observe the function failure in detail, review the original design for possible timing constraint vacancies and other trap doors. Hopefully this will bring a solution to our problems.

    Best, Tore

  • NazrulNaim_Intel's avatar
    NazrulNaim_Intel
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    Hi Tore,


    I'm sorry for the delay. I understand your concern however, sorry to let you know that we do not provide part marking verification in order to avoid the devices from grey market.

    Altera has its authorized distributor to sale devices. If you got the devices from formal distributors, you shouldn’t worry on the device authenticity/validity as the devices must be valid units. Otherwise, we do not ensure the device quality and do not provide the further service. You may find the authorized distributor list from the link below:

    https://www.intel.com/content/www/us/en/programmable/buy.html

    Regards,

    Nazrul Naim


  • NazrulNaim_Intel's avatar
    NazrulNaim_Intel
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    Hello,

    As we do not receive any response from you on the previous question/reply/answer that we have provided. Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

    Best regards,

    Nazrul Naim


  • 2reSolve's avatar
    2reSolve
    Icon for New Contributor rankNew Contributor
    10 months ago

    Buying the FPGA chips from authorized distributor this time did not solve this issue.

    Also, after hiring an FPGA expert for reviewing our FPGA design we are informed the project does not build because of Error (18496): The Output TLK_TX[1] in pin location 28 (pad_1628) is too close to PLL clock input pin (CLK_50M) in pin location 29 (pad_1)

    This errror was not present (even as a warning) when the project was originally build with Quartus II 15.0.2.153 back in 2015.

    So please, is there "a work around" for Error (18496) which allows this project to build with the newer Quartus versions?

    • FvM's avatar
      FvM
      Icon for Super Contributor rankSuper Contributor
      10 months ago
      Yes there's a simple workaround by assigning toggle rate of "0 MHz" to pin 28 in pin planner or assignment editor to suppress distance rule application. It however depends on output signal characteristic if it can be done without causing signal integrity issues.
  • 2reSolve's avatar
    2reSolve
    Icon for New Contributor rankNew Contributor
    10 months ago

    I've already tried setting "Toggle Rate" to "0 MHz" on both adjacent output pins 28 and 30 adjacant of PLL clock input pin (CLK_50M) in pin location 29 with different "Current Strengt" and "Slew Rate" settings without any success so far.

    Also, Quartus does not seem to allow the User to Suppress Error Message (18496).

    It seems like Intel simply do not allow override of their Signal Integrity Design Guidelines for the Clock Input Signal:

    This is just fine, that is until you realize each and every single pin of the 144pins in your hardware design has already been spoken for.

    So maybe my best and only option right now is to have my FPGA designer work on this problem using an older version of Quartus with its "preliminary timing models" even though this is far from optimal.

    If Intel allowed to Suppress Error Message (18496) we could instead work on this problem using the latest Quartus version.