https://open-source-silicon.dev logo
Join Slack
Powered by
Hi <@U016EM8L91B> &amp; team -  Are we sure that:...
# caravel-board
d
Hi @User & team -  Are we sure that:  (a) The 
slippage
script is always correctly modifying values for configuring IOs 0-18, and (b) IOs 19 and up are devoid of similar problems?  We’re having all sorts of trouble configuring a subset of the user-space IOs. Walking through all of them, I see these discrepancies between the firmware-program and bench measurements:  * MPRJ IOs 3 & 4 - set as INPUT, look like an OUTPUT * MPRJ IOs 12 & 13 - set PULLDOWN, looks like a NOPULL input * MPRJ IOs 14 & 15 - set OUTPUT, looks like an input  * MPRJ IO 22 - set INPUT NOPULL, looks like a pull-down * MPRJ IO 24 - set OUTPUT, looks like an input  When I say “looks like”, I mean I hook up a ~1k decade box to the pin, move the other end between VSS and VDD, and observe whether the chip appears to be driving that pin.  Some of these are more damaging than others. Inclusion or exclusion of the pull-up/downs, for example, isn’t a real problem in our context (although it may be indicative of underlying programming problems). But several of these INPUT vs OUTPUT discrepancies (3 & 4, 24) are on our bring-up/ debug interfaces. They’ve gotta work, or our chip’s DOA.  FWIW the code configuring all this is here:  https://github.com/ucberkeley-ee290c/caravel_board/blob/main/firmware/osci/osci.c And my paired edits to your 
slippage
script live next to it, here:  https://github.com/ucberkeley-ee290c/caravel_board/blob/main/firmware/osci/slippage.py Thanks in advance.
t
I'm looking at this and will have to address all of the issues somehow, but right away I can see one problem (or maybe two): I/O 3 and 4 belong to the housekeeping SPI. The housekeeping SPI pins could not have their "management enable" pin sense-flipped like the other GPIO pins or else the housekeeping SPI would no longer work. So for these four pins, the definition of MGMT and USER is reversed (the low bit is inverted). So you would want "GPIO_MODE_MGMT_STD_INPUT_NOPULL" on I/O 3 and 4 to get them to be under user control (I knew that was going to be totally confusing but I couldn't think of any better way to do it).
FYI, Jeff DiCorpo was reporting problems setting GPIO 19 to 37 which I could not reproduce; I had two boards on my desk and both of them responded to setting all channels. There is no chance of the "bit slippage" problem on channels 19 to 37 because the clock runs in the reverse direction of the data, which eliminates the possibility of hold violations (at the expense of setup margin, but I found that this cut the frequency at which the GPIO loader works from 40MHz down to 30MHz, whereas the actual board clock is 10MHz, so there should be no problem there).
d
Very helpful thanks. We’ll roll that in this afternoon and report back. Perhaps @User can weigh in on the trouble he’s seen, and work-arounds if any have panned out.
Also - which of these two sets of constants should serve as valid inputs to the 
slippage
script: From `defs_mpw-two-mfix.h`:
Copy code
// Useful GPIO mode values
// Important note!  GPIOs 1 to 4 have a reversed bit for
// management disable that requires swapping the values
// for "USER" and "MGMT" for these four pins.  Normally, use
// of these pins for user project purposes is discouraged, so
// it should not be a major issue.

#define GPIO_MODE_USER_STD_INPUT_NOPULL    0x0403
#define GPIO_MODE_USER_STD_INPUT_PULLDOWN  0x0803
#define GPIO_MODE_USER_STD_INPUT_PULLUP	   0x0c03
#define GPIO_MODE_USER_STD_OUTPUT	       0x1809
#define GPIO_MODE_USER_STD_BIDIRECTIONAL   0x1803
#define GPIO_MODE_USER_STD_OUT_MONITORED   0x1803
#define GPIO_MODE_USER_STD_ANALOG   	   0x000b

#define GPIO_MODE_MGMT_STD_INPUT_NOPULL	   0x0402
#define GPIO_MODE_MGMT_STD_INPUT_PULLDOWN  0x0802
#define GPIO_MODE_MGMT_STD_INPUT_PULLUP	   0x0c02
#define GPIO_MODE_MGMT_STD_OUTPUT	       0x1808
#define GPIO_MODE_MGMT_STD_BIDIRECTIONAL   0x1802
#define GPIO_MODE_MGMT_STD_OUT_MONITORED   0x1802
#define GPIO_MODE_MGMT_STD_ANALOG   	   0x000a
Versus the (similar, not identical) ones in `defs.h`:
Copy code
// Useful GPIO mode values
#define GPIO_MODE_MGMT_STD_INPUT_NOPULL    0x0403
#define GPIO_MODE_MGMT_STD_INPUT_PULLDOWN  0x0803
#define GPIO_MODE_MGMT_STD_INPUT_PULLUP	   0x0c03
#define GPIO_MODE_MGMT_STD_OUTPUT	       0x1809
#define GPIO_MODE_MGMT_STD_BIDIRECTIONAL   0x1801
#define GPIO_MODE_MGMT_STD_ANALOG   	   0x000b

#define GPIO_MODE_USER_STD_INPUT_NOPULL	   0x0402
#define GPIO_MODE_USER_STD_INPUT_PULLDOWN  0x0802
#define GPIO_MODE_USER_STD_INPUT_PULLUP	   0x0c02
#define GPIO_MODE_USER_STD_OUTPUT	       0x1808
#define GPIO_MODE_USER_STD_BIDIRECTIONAL   0x1800
#define GPIO_MODE_USER_STD_OUT_MONITORED   0x1802
#define GPIO_MODE_USER_STD_ANALOG   	   0x000a
FWIW we have been using the former.
t
@User: The 
defs_mpw-two-mfix.h
file corresponds to the specific metal mask fix that we made to the ChipIgnite-1 version of Caravel. The difference is that we inverted the sense of bit 0, which was formerly the "management enable" bit but is now, effectively, the "management disable" bit. However, for reasons of keeping the housekeeping SPI active on power-up, GPIO channels 1, 2, 3, and 4 were not modified. As you can see from the list you quoted, the only difference is that "USER" changes to "MGMT" and vice versa. Just make sure that for GPIO channels 1 through 4, if you use 
defs_mpw-two-mfix.h
, then you want to use the "MGMT" string for user control. As I said, it's confusing, but was necessary to do.
j
@User sorry - just saw the thread and catching up now
i’ll see if I can run your code on one of our boards.
w
I was also seeing intermittent issues with the high order GPIO bank on my chip. Not able to reproduce as of late though.
Due to the overlapping bit of the adjacent configuration words, if everything is under user project control the only possible I/O configurations are
Copy code
value 100 = open drain to power
	    value 101 = open drain to ground
	    value 110 = digital output
	    value 111 = digital output (weak)
But that would not make pins set as outputs be set as inputs.
I was seeing some issues with my I/O tests where the behavior of the management side configuration word was conflicting with what was sitting in the registers on the I/O itself.
Tim suggested that the management side I/O configuration registers be loaded with the normal values (and not shifted out by setting reg_mprj_xfer = 1) after doing the full I/O configuration. I dont think that would impact the user project I/O stuff though?
j
I’m not sure it would either, but can’t confirm. @User?? I can confirm it is required for mgmt configured IO.
t
Re-writing the values in the memory-mapped space for the configuration after doing the transfer is only meaningful for management-controlled GPIO. It will have absolutely no effect on user-controlled GPIO.
Open in Slack
PreviousNext
Powered by