chip migration

[Altera_Forum]

Hello, 

we have a board which use a MAX EPM7032BTC44-3 chip to pass programming data to a FLEX EPF10K30ETC144-1N from a PowerPC. Passive serial connection (nCONFIG, nSTATUS, CON_DONE, and so on...) is used to program FLEX from MAX. For production reasons, we decided to change the EPM7032BTC44-3 with an EPM7064BTC44-3N. Since EPM7032 and EPM7064 have the same pinout, we thought we had only to recompile the FW. We tried to recompile the FW using both QuartusII v.7.0.33 and MAX+Plus II 10.2. The situation is: -using the old EPM7032 chip and the old FW, all works fine. -using the new EPM7064 chip and the recompiledFWs (from both tools), the FLEX EPF10K30ETC144-1N is not programmed (nSTATUS tied low by the FLEX itself).  So, my questions are: - EPM7032 was lead version, EPM7064 is lead-free version. Could it affect? - Is it possible that "-3" and "-3N" versions require different compiler releases (both tools we have look to be able to handle only "-3" version, but "-3N")? - Is there any timing difference between EPM7032BTC44-3 and EPM7064BTC44-3N? I didn't find this info on datasheets. - How many bytes must be sent to EPM7032 and EPM7064 to program them? (Just to understand if .pof files we generated are, more or less, ok or not)  Thanks

[Altera_Forum]

the N simply designates lead-free/RoHS. you can compile using the -3 settings in the tool. 

 i don't think there should be timing differences in the larger device (certainly not from the -N).  i imagine the .pof for the 64 part will be larger.

[Altera_Forum]

Hi thepancake, 

thanks for the answer.   I double-checked the board, and the situation looks to be slightly different respect of what I said yesterday :o. Perhaps I had some trouble with the oscilloscope probe tip. I replaced it with another one (double-checked too).   I attached a report which should explain what I'm seeing. In the attachment you'll find two nCONFIG signals (nCONFIG1 and nCONFIG2) as boards has two EPLD that are programmed by the EPM70xx chip.   So, at today, the situation is: - a board with EPM7032 and old FW works (I have tried that on 3 boards up to now, moving the EPM7032 chip); - the same board(s) with EPM7064 and recompiled FW is not able to release the CONF_DN1, but COND_DN2, after configuration bits are (apparently) sent.   Since FW for EPM7032 looks to be good, I opened that .pof and I have looked at contents with an hex editor. It addresses from 0x0000 up to 0x0850, so 0x851 bytes in hex notation, so 2129 bytes, in decimal notation. I did the same for recompiled FW for EPM7064. Addresses are from 0x0000 up to 0x0FF0, so 0xFF1 bytes in hex notation, so 4081 bytes, in decimal notation. I expected 4258 bytes in EPM7064 .pof, since EPM7032 has 2129 bytes in its .pof and it works that way. Perhaps that difference is a matter of compiler/fitter processes.   As already said, the target devices that should be programmed are both FLEX EPF 10K30ETC144-1N. I found that EPF10K30e requires 473720 bits (59215 Bytes) for SRAM configuration. Is that correct? However, how many bits shall I send to that targets to fill their SRAM completely?   Bye.