Hi, I need help with my project bring-up. The design is a 32bit micro-controller with some peripherals. My design uses UART for loading program into memory. For this following are the steps. a. set UART baud rate (as clocks per bit) using lower 16bits of caravel LA. b. set controller into program mode using IO[7]. It works like a push button for my design. c. send program over UART (using IO[5] as rx). following these steps i am unable to get any response from the design. The test files are attached. can anyone look into the IO configuration and help to figure out the issue. am i missing something related to IO config for user area.

Run the checker to make sure that the I/O configuration gets set the way you expect it to. If you don't have "make check" enabled in the Makefile, then just run

gpio_config/gpio_config_checker.py

. Otherwise, what other signs of life can you get from your project that is simpler than using the UART? Do you have any status bits that you can read back from the logic analyzer? When running your C code, can you see the four bits (GPIO 0, 1 and 32, 33) toggling in the infinite "while" loop?

Yes, the four gpio pins are toggling in loop.

How is your user project driving the OEB lines for the two GPIOs that you have as "input no pull" (GPIO 5 and 7)?

For my design these pins are input only so oeb's are tied to 1. is it right?

Having OEB tied to 1 is good; it means that these pins are properly configured from the user project side as inputs, so most of the configuration bits are ignored, which gives a lot more flexibility for setting the configuration word so that it doesn't conflict with neighboring channels. It should be possible to select a set of configuration words that sets the right direction on each pad but also passes the checker.

That's good to hear. would you please guide me why the checker is failing or how it decides the pass/fail status.

Yes, but please bear with the slow responses, as I am simultaneously juggling about five different conversations.

No issue at all. Thanks for your coordination.

The configuration is going off the rails up at GPIO[11] and higher, but GPIO[5] and GPIO[7] should be properly configured as inputs, so I don't see anything obviously wrong with the program and the setup.

I am running a simple program which sets some IOs (IO[8] - IO[15]) to 1 in response which i am not getting atm.

GPIO[8] through [10] seem to be properly configured (GPIO[11] and [12] definitely have a configuration problem which will need to be worked around. GPIO[13] to [15] are probably okay. Your project is expected to drive OEB low on all of these outputs?

Yes, The OEB will be driven low on IOs 8-15

One quick test I can think of is to toggle all of the GPIO, and then check which ones are set as management output to make sure that matches the checker's understanding of the configuration. According to the checker, you should see the following GPIOs toggle on the low side: 0 to 4, 6, 11, 12 (with a weak pull-down), and 18. At least that test checks the checker. If those outputs are toggling, then the checker can be trusted and GPIO[5] and GPIO[7] should be working correctly as user inputs, and GPIO[8] to GPIO[10] should be working correctly as user outputs (we can worry about fixing GPIO[11-15] once it's clear that something in there is basically functional).

@Tim Edwards Even I am facing issues in configuring the GPIO inputs. Have tried setting the input registers as both user input (Make check doesn't pass) and management input(make check passes). Please refer attached screenshots and attached .c and io.py files. @Pranav Lulu

@Ayushman Tripathi: The image suggests that this is an incorrect setup. That is, the result of the checker is showing that GPIO 36 to 19 are all set to management-controlled output. Normally, if something could not be configured correctly, it will show up as the configuration values being offset or corrupted in some way from one of the known configuration patterns (like management-controlled output). That suggests that when running the checker, you have a mismatch between the three files

gpio_config_data.py

(the bitstream),

gpio_config_def.py

(the calibration), and

gpio_config_io.py

(the setup). Probably the bitstream and calibration match, since the checker shows meaningful configuration data in all channels after loading, but the setup file is probably not the one that was used to create the bitstream.

I have tried for two cases. The screenshot error is for the case when 37th pin is set to C_USER_IN. In the attached file case (37th pin set in management mode), the make check was successful but 37th pin was not toggling

Note that there are two serial chains, one going up the left side of the chip starting at GPIO 37, and one going up the right side starting at GPIO 0. The hold violations occur between the GPIO blocks, so the two GPIOs that are at the beginning of each shift register (which are GPIO 0 and GPIO 37), can never have any hold violation. GPIO 37 can never be in error, so the only way I think that this error report from the checker can happen is if the

gpio_config_io.py

file is changed, and then the checker is run without first generating a new bitstream based on the modified configuration.

Okay. I will try again. Do you know why the first test (pin 37 set in management & make check passed) is not able to toggle 37th bit ?

@Ayushman Tripathi: Maybe I'm getting confused by the various different posts, but in the ones I see above, you have GPIO 37 set to be an input, in which case of course it's not going to toggle. Note that the value put in the housekeeping registers in the C code (lines 7 to 46) only matters for the housekeeping to know which direction data is moving on the single data line for the GPIO. The housekeeping only looks at bit 3 (INP_DIS, the input disable bit). The other bits don't matter since the actual configuration programming is being done by bit-banging, not by copying in the values from the registers. As long as the

gpio_config_io.py

file has GPIO 37 set to

C_MGMT_IN

, the output driver on the buffer is disabled, and the channel cannot toggle regardless of any other setting. If you want to see it toggle, you should use

C_MGMT_OUT

on GPIO 37.

Thanks a lot for your reply. This really helps. Is there some way apart from monitoring chip outputs if our inputs are correctly configured.

There's no direct way to know, but the hold violation issue is well established now, so the mechanisms of failure is that if you don't correctly account for the effect of the hold violation, then bits either get shifted or increase/decrease the run-length of series of "1" bits. If the configuration is wrong, it will be wrong from some point in the chain all the way to the end. So if you are not using GPIOs at the top of the chain (18 and down on the right side, 19 and up on the left side), then configure one of those as an output and toggle it. If it's working, then all the GPIOs up to that point should be working. The only big issue that we continue to have after working out the calibration is that there are occasionally chips that have a hold violation right on the edge, which can change randomly. Since hold violation timing is randomly distributed across chips, the best strategy is to find a chip that doesn't have this problem. If the chip cleanly passes calibration several times, it should be good. Often, lowering the core voltage (as low as 1.43V) will move the hold violation time enough to keep it stable. The final thing is to use the "make check" procedure to ensure that what you think you're programming all the GPIOs to is actually achievable. There should be very few cases where you can't achieve a working configuration, but you might need to resort to configurations that aren't obviously the ones you would normally use (such as using a management-controlled input as a user input). User outputs are the worst case, because everywhere there is an independent hold violation, the high bit of the configuration of one channel (part of the output mode) bleeds into the management control bit of the next channel. We have redefined some of the modes so that the "user output" mode is

011

, which can be used as a valid output mode but engages a resistor in the path of the output to ground, so you end up with an output with a weak pull-down on it. But by keeping the high bit zero, it won't accidentally set the next channel to management control.