dabo
New ContributorUser Profile
New Contributor
User Widgets
Contributions
Re: Reuse programming file for multiple MAX 10 devices
Thank you Fakhrul. Can you please also answer my question from my previous post: Is it completely safe to program a 10M04SCU169A7G programming file to a 10M04SAU169A7G device? Or a 10M08SCU169I7G programming file to a 10M08SAU169I7G device?1.8KViews0likes0CommentsRe: Reuse programming file for multiple MAX 10 devices
Thank you for the reply. We intend to always use speed grade 7. Are you running at maximum clock frequency? Our design is running only at 20MHz outputted from the built-in PLL. At your clock frequency does your design timing report show close to zero margin on some logic paths? The timing report says everything is ok at 125C for the Automotive range, does that not also imply that running the same programming file on an Industrial ranged device up to 100C will also be ok? We are aware that there could be problems running an Industrial device above 100C no matter if the programming file is built for Industrial or Automotive range. Are you using the full operating temperature range, specifically at the high end where timing performance degrades? We have ran temperature tests for an extreme case and determined that an Industrial device at 100C should suffice. But the temperature margin was not as big as we would have liked so to have some extra margin we elected to go with the Automotive version. Since we have a lot of trouble acquring Automotive ranged devices we decided Industrial will have to do now too. As long as speed grade and temperature grade are the same then it is completely safe to reuse a programming file for the devices I listed in the previous post? For example, program a 10M04SCU169A7G programming file to a 10M04SAU169A7G device or a 10M08SCU169I7G programming file to a 10M08SAU169I7G device?1.8KViews0likes0CommentsReuse programming file for multiple MAX 10 devices
Hello, We are looking for clarification when it is necessary to rebuild the project in Quartus when using different MAX 10 devices. As with many others we are having problems acquiring the MAX 10 device our board was designed for (10M04SCU169A7G) and now when looking for alternatives we want to cover as many options as possible while keeping the different Quartus builds of our application to a minimum. If we build a project in Quartus targeting operating temperature Automotive will the programming file work as intended on both an Industrial and Automotive device? Or could there be timing related issues on the Industrial device? I see the generated .pof-file is very different between different operating temperatures even thougth the application is the same. More specifically would for example the following work? Build a Quartus project targeting 10M04SCU169A7G and use the programming file on the following devices: 10M04SCU169I7G 10M04SCU169A7G 10M04SAU169I7G 10M04SAU169A7G Build a Quartus project targeting 10M08SCU169A7G and use the programming file on the following devices: 10M08SCU169I7G 10M08SCU169A7G 10M08SAU169I7G 10M08SAU169A7G Or do we need to rebuild the Quartus project for each target device?1.9KViews0likes8CommentsRe: MAX 10 JAM player programming failure
Your setup is very similar to ours only we use a 10M04SCU169A7G. Two differences I noticed: 1. In Programmer when we convert pof to jam, we don't check any Program/Configure or Verify checkboxes. We do check the Enable real-time ISP checkbox. 2. What is jbc.exe? I cannot find it in my installation of Quartus. We use quartus_jbcc -n xxx.jam xxx.jbc to convert jam to jbc. Then we convert the jbc to a byte array and embed it into our MCU firmware. When calling jbi_execute in the MCU we use action PROGRAM together with optional procedure DO_VERIFY=1. Not sure if it helps you but this works for us.1.8KViews1like0CommentsMAX10 start-up problem
Hello, We are using a MAX 10 (10M04SCU169A7G) on a custom board and are experiencing start-up problems on 2 out of 40 boards. The MAX 10 is programmed by an MCU on the same board using the embedded version of Jam STAPL Byte-Code Player. The jbc-file is embedded into the MCU firmware. All communication over JTAG between the MCU and MAX 10 always succeed. We have tried to program, verify, erase and blank check and all results are as expected. In Quartus Prime 20.1.0, configuration mode is set to Single Uncompressed Image (128Kbits UFM). All other settings are default set by Quartus. Real-time ISP is not used. Auto-restart configuration after error is activated. tRAMP during POR is ~1.25 ms which is ok according to the Configuration User Guide. CONFIG_SEL, nSTATUS, nCONFIG and CONF_DONE are all pulled up to 3.3V using one 10Kohm resistor each. We have observed nCONFIG, nSTATUS and CONF_DONE on an oscilloscope during start-up and after reprogramming of the MAX 10 and have noticed differences between a working board and one that does not. As expected the configuration pins on the working board follow the configuration sequence in the Configuration User Guide. Attached picture (startup-not-ok.PNG) shows the pins during start-up on a board that does not work. The MAX 10 is already programmed and nSTATUS go high for a short while (~0.8us) before going back low. CONF_DONE is low all the time. Attached picture (startup-ok.PNG) is the corresponding picture for a working board. Here we can see nSTATUS go high followed by CONF_DONE a while later as expected. Attached picture (after-programming-not-ok.PNG) shows the pins after reprogramming a board that does not work. Here nSTATUS and CONF_DONE go high while programming the MAX 10. When programming is completed both go low and then nSTATUS go high for a short while (~0.8us) before it goes low again. CONF_DONE remains low. Same behavior as during start-up. Attached picture (after-programming-ok.PNG) is the corresponding picture for a working board. Both nSTATUS and CONF_DONE go low once reprogramming is completed. Then nSTATUS go high followed by CONF_DONE just like during start-up on a working board. Judging by the behavior of nSTATUS something seems to go wrong during configuration. We have used the Jam STAPL player to verify the data written to FLASH and the check succeeds. Do you have any idea what could go wrong? 95% of the boards work. The same JBC-file is programmed to all boards. Since we have activated Auto-restart configuration after error we expect nSTATUS to go high again after a timeout but we cannot see that. We have managed to get one of the problematic boards to start-up correctly by doing a fullchip erase and program the MAX 10 again. This might fix the other board as well but in order to do more troubleshooting we have elected not to try it yet. In our prototype series of 10 boards 3 of them experienced this phenomenon of which 2 ”self-healed” by reprogramming the MAX 10 enough times. On one board the problem still remains. We assumed the cause of the problem was that we did not connect nCONFIG to a 10Kohm pull-up resistor but that is fixed now on the current boards. We cannot say with certainty that we have the same problem now but the symptoms are the same. Translation for legend in attached pictures: Grön = Green Blå = Blue Gul = Yellow Röd = Red Spik = Spike2.1KViews0likes1CommentUnable to generate uncompressed jbc-file
Hello, I am trying to follow the instructions below to generate an uncompressed jbc-file but quartus_jbcc doesn't seem to do anything. quartus_jbcc never exits at all. It doesn't matter what parameters I provide. https://www.intel.com/content/www/us/en/programmable/support/support-resources/knowledge-base/solutions/rd03192009_674.html Any idea what could be wrong?782Views0likes2Comments