I'm trying to send input from the firmware to the user_project. From the mprj_stimulus testbench, it seems it's possible by first setting the pin as an input, then doing the reg_mprj_xfer, then setting them to management outputs. (note that the mprj_stimulus fw seems wrong because the comment says it will "recast" the channels to allow input, but they original setup for the channels is not input but mgmt output: <https://github.com/efabless/caravel_user_project/blob/d9ddc78b65db1d5f8c2871925cdec26bf95b5d53/verilog/dv/mprj_stimulus/mprj_stimulus.c#L87>. Has anyone managed this? While doing this, I've hit another issue. If I'm doing individual bit sets and clears on reg_mprj_data it seems to wipe the whole reg. My workaround is to do all the bit manipulation on a temp register and then copy that to the reg_mprj_data register.

The trick with doing a transfer and then setting the registers differently afterward only applied to Caravel chips up to MPW-5. For the newer design, it became clear that the distance from the processor to the GPIOs was too long for a single bidirectional wire (because it can't be buffered in both directions), so we switched to two dedicated wires between the management processor and each GPIO (one in, one out). So it's possible to read from and write to each GPIO at the same time.

can you give me a code example of how to drive a user input pin from the managment fw?

How do you have CLR and SET defined?

image.png

Hmmm. . . I think that switching the definition from USER to MGMT after the serial transfer like you did may still be the correct way to do it.

They work as expected on an unsigned int.

I wonder if there is an issue with using expressions like

|=

and

&=

; that implies a memory read followed immediately by a memory write. I will stare at the housekeeping code a bit---the housekeeping GPIO access is a little awkward because it shares the registers between the wishbone and SPI interfaces, and so it does all 32-bit reads and writes as four separate 8-bit reads and writes, which might have something to do with the phenomenon you're seeing. Meanwhile, does it work if you replace the expression with a separated read and write?---

#define SET(PIN,N) (PIN = PIN | (1<<N))

or

#define SET(PIN,N) (temp = PIN; PIN = temp | (1<<N))

?

I can test that easily

Yes, it would actually toggle on the pin of the chip. What I think you want to do differently is to just set

reg_mprj_io_32/34/36

to

GPIO_MODE_MGMT_STD_OUTPUT

to begin with. The user project will be able to read the value regardless.

#define SET(PIN,N) (PIN = PIN | (1<<N))

doesn't work. as soon as the next set happens it clears all other bits

Is that true for

reg_mprj_datah

only, or is it also true for

reg_mprj_datal

?

the other suggestion causes compilation errors

Oh, it would have to be

#define SET(PIN,N) temp = PIN; PIN = temp | (1<<N)

without the outer parentheses around the expression. Or maybe

#define SET(PIN,N) {int temp = PIN; PIN = temp | (1<<N)}

(which may be better as it allows the variable

temp

to be defined within the context of the definition).

nearly - needed one final ; before the }

Right.

still doesn't work though

I'm thinking it might make sense if the wishbone acknowledge signal is being set too early so that it returns control to the processor before the housekeeping state machine has finished processing the data. But that will take some investigation.

actually what I was doing was never reading from register, doing all the manipulations on temp and then just copying it over

But the

|=

expression implies a read followed by a write.

I think you might be right. I have definitely witnessed some weird wishbone stuff when working on the cocotb testbenches. Like, unless you have a delay in between wishbone writes then they can get lost.

Whoops, input buffer has to be turned on. Use

GPIO_MODE_MGMT_STD_BIDIRECTIONAL

(make sure it's defined as

0x1801

).

that works!

Tentatively, the reason that

|=

doesn't work is that the GPIO data read value is not equal to the GPIO data write value. I think that

STD_BIDIRECTIONAL

must be set on all channels for this to work. Because the read value is the value at the pad. If the pad input buffer is turned off (by using

STD_OUTPUT

), then it will read back zero. This should probably be better explained in documentation (also, it might be a good idea to change the implementation so that when the input buffer is off, the register value will be read back instead of the pad value. Or have an additional bit to toggle between reading from the pad vs. reading from the register value).