In the provided LA tests, how are the delays between assignments to the registers set? For instance, when setting a single mprj_io bit high to signal the start of the test and then setting it back to low to finish, only the last write to that register will persist.

//start test
reg_mprj_datal = 0x00000001
// Do stuff
//End test
reg_mprj_datal = 0x00000000

When I look at the waveform for that code, once all the pins are set and the program is loaded, the 0-th bit will be 0, but if I comment out the last line, it will be 1. This seems like the register is being overwritten. If I use two separate pins for start and end, I can see that the timestamp of when it sees each bit after the wait statement is the same. Is there some way to add delays or prevent this overwriting, so that I can write to the reg_la_data registers? I was more or less modifying the two given la tests to send data over the interface

@Tim Edwards you wrote the LA. it's just a memory mapped register, so this has to be a software issue right? These memory locations are declared volatile which means they can't be optimized away

@Matthew Guthaus: Mohamed Shalan wrote the logic analyzer. All I did was to make it full duplex.

@mshalan Can you help with this?

@Amogh Lonkar: I don't really get the gist of your question, though. The mprj_io has nothing to do with the logic analyzer. But yes, those addresses are registered. There is a 38-bit register at reg_mprj_datal (the address is hard-wired; "reg_mprj_datal" is just a definition from defs.h pointing to the hard-wired address), one register bit per GPIO channel. Writing to it is like writing to any other valid memory address.

It's true this isn't an LA issue, but I believe we see the same thing there with the memory mapped registers.

I've never seen that happen ( the optimization into a single assignment) but I'm not sure that's even what the op is describing. @Amogh Lonkar can you post screenshots of the firmware and waveforms to better describe the issue you're having?

@Matt Venn I can confirm that is exactly what were doing with the LA and GPIO... and we expected it to be the delays of the CPU + wishbone bus.

@Matthew Guthaus (and maybe @Amogh Lonkar)? If the issue has to do with the configuration of the GPIO, the setup is that in order to prevent having thousands of wires going from the management SoC to the pads, I implemented a GPIO controller block that sits locally next to the GPIO, under the padframe power buses, and supplies all the DC settings to the pad. The controller block has its own local registers for the GPIO configuration, and is programmed by a serial shift register that wraps around the entire padframe. The GPIO configuration is therefore held in two registers: One in the management SoC, and one in the GPIO controller. Applying the "reg_mprj_xfer" bit is what transfers the configuration from the SoC to the local GPIO controller blocks. The transfer takes some time, which is why my testbench C code always loops on querying the bit that says that the transfer is done. At the end of the serial transfer, all GPIO configuration blocks are updated simultaneously. The GPIO configuration is not directly accessible to the user. The registers such as "reg_mprj_io_31" are the value that is registered within the SoC. So this serial programming is only for the DC signals (there are 11 of them, I think), not the actual signal on the pad. But that reduces the wiring back to the SoC on most of the GPIO pads to a single wire that is the input/output data line. Programming the "reg_mprj_datal" and "reg_mprj_datah" lines set or read those input/output data lines, so those values are instantaneous and not related to the static configuration of the GPIO. Does all that make sense?

This all makes sense. We saw all operations "squashed" together because they were applied after the config was shifted in. I thought that while loop was an end of program wait so that it wouldn't go into undefined memory... (Amogh is a grad student working with me...)

We need an organizational chart of who is related to who and what institutions.

@Matt Venn It was looking like this. It made sense that each line of code correspond to instructions executing one after the other but the timing of the assignments threw me off. I will try now with the proper config for xfer.