We use Quartus19.1 to generate a .jbc file for the EPCS128 connected to a EP4CE6F17I7N FPGA via the Active Serial interface..
On our board we use the Jam STAPL Byte-Code Player Version 2.2 software to program the Serial Configuration Device via JTAG.
The programming is working, but propably during the time of access to the Serial Configuration Device via the Serial Flash Loader (SFL) some IOs of the FPGA do not have anymore this Weak Pull-ups as we expect.
(E.g. when I start programming the output (Pin B4) gets first input with weak Pull-up for a while and then just input or input with Weak Pull-down before it gets again ouput at the end.)
Is there any explanation of this behavior?
As I remember, we had similar effects in a old project, but only when we generated the .jbc file with Quartus newer then 13.1. Maybe that helps to find the problem.
Yes all pin are pulled to HIGH Z during configuration mode. When the device is booted successfully, unused pin will remain the same as what is set in Quartus. Meanwhile, used pin will go back to the state which is set in the design.
What you describe is correct. But I was talking about the pin state during programming of the Configuration Memory via JTAG-SFL-ASMI.
It seems that when the SFL is active, some IOs are not anymore with weak pull-ups.
Or do you say, that we can define the IOs of this SFL bridge, which gets loaded first, somehow in Quartus. How do we have to do it?
P.S. sorry for my poor english
The IO state is the same in all programming scenario.
You may change the unused pin state in user mode by following the guide below:
In our design the unused IOs are already set as input tri-stated with weak pull-up. And actually the Pin B4 is used as an output.
What about the IOs after the SFL from the generated .jbc file is loaded via JTAG and active? Can we also define them in this state of the programming?
As I wrote during programming of the Config. Flash via JTAG-SFL(Serial Flash Loader)-ASMI(Actice Serial Memory Interface), this output has not anymore a weak pull-up.
I'm sorry that I confused you. Actually it was always Pin R7 I talked about. We use this user output as Backlight-Enable signal in our design.
The picture I attached, shows that this output R7 (trace C3) is going low (instead high with weak pull-up) in the programming phase when the configuration memory gets accessed via JTAG-SFL-ASMI. Visible because the Chipselect ouput 'CSO' of the FPGA (trace C2) is toggling.
Before this phase of programming you can see that the output is high with weak pull-up. Which is as expected and I assume that this is the phase where the SFL bridge gets loaded to the FPGA via JTAG.
At the beginn and at the end of the picture the output is high, when the FPGA is in user mode.
Trace C1 is the CONF_DONE output of the FPGA.
So, my question. Way gets the user output R7 low during programming?
I think the pin is toggled to low during user mode. The reason is the the CONF_DONE is pulled back to high to indicates that the configuration is done and is in user mode. Probably you might want to check your pin state in your design.
You might be right, but that's not our user mode. It's a kind of user mode when the Serial Flash Loader Bridge from Quartus 19.1 is loaded and active.
How are the IOs defined during this? Do we have to do it somewhere?
In my picture above we can see that the chipselect of the configuration memory ('CSO' Pin D2) is toggling during the time when the FPGA Pin R7 is low.
As the programming basically is working, I assume we see the access to the configuration memory via JTAG and this Enhanced Serial Flash Loader (SFL) during this time.
But somehow the Pin R7 is not pulled high during this time.
Here are the more detailed timing measurements. I added also the JTAG TCK signal.
The CONF_DONE is going 3 times to low during the whole programming process.
After the second time (see Detail B), where in my opinion the SFL is active, we get the problem with the user IO at Pin R7.
It stays low instead of high with weak pull-up.
With the reconfiuration in Detail C, Pin R7 gets again high with weak pull-up and then high driven by our user mode.
Sorry for being late, i was in discussion with internal team about this. From the timing diagram, it seems like the pin is pulled down during image file (JBC File) programming.
Also, you mentioned that the JBC file generated after v13.0, all pin are pulled-up during programming, but now, when generated with v19.1, all pin are pulled-down during programming?
I do not know whether all Pins are low during programming of the Configuration Flash via JTAG and SFL Bridge. At least Pin R7 is it. Why? And can we change that?
We have not tried this project with Quartus v13.1 yet. That was some years ago where we had similar issues. But maybe it was something else. I will ask your designer to try with Quartus v13.1.
Is from your side something different between v13.1 and v19.0 according automatic added SFL Bridge?
Today we build the .jbc file once with Quartus 13.1 and once with 19.1.
During the programming of the 13.1 file the Pin R7 has allways weak pull-up, during the programming of the 19.1 file the Pin R7 goes to low as mentioned before.
So, what is the difference between 13.1 and 19.1 according the automatic added SFL bridge?
Do we have to do something different?