I have seen the uart and spi are connected with the pins mprj_io[1] till mprj_io[6] in caravel, I also have peripheral uart and spi in my design so should I also use these pins for for my peripheral as they are directly connected to an FTDI chip? https://github.com/efabless/caravel/blob/d6d8f949bcb755839ca12a3871099f3ef672392c/verilog/rtl/caravel.v#L64

These pins will perform said functions when management core is in reset, before it relinquish the control through its firmware. Then you can configure these to connect with your user core.

Thanks @Tayyeb Mahmood Yes, I know this fact, the question is that I have UART and SPI, which pins are preferable to integrate these two peripherals or in other words can I connect my UART on any PIN other than

// ser_rx    = mprj_io[5]		(input)
    // ser_tx    = mprj_io[6]		(output)

You can connect to any, but then you will not be connected to FTDI.

Great got it thank you.

Only these pins are going to be connected with FTDI afaik

yess

In addition board draft is yet to be finalized.

Any idea what is the expected date?

No, checkout #caravel-board for updates. They have asked for recommendations. However, it may not be possible to furnish all various amendments. Here, uet and uit may join forces on a working draft, which may serve a number of projects instead of one or two.

@Zeeshan Rafique: Check the #caravel-board channel for updates on board design, and also to weigh in with your input on what you need the board to do. The more people tell the board designers what their needs are, the better the board design will be.

@Tim Edwards Great! Ok sure

@Zeeshan Rafique: It occurs to me that the IRQ input pin has no anti-chatter filter on it, and is likely to cause issues with the interrupt being called repeatedly. The handler would need to implement some kind of "hold off" time before responding to the next event. I will log this as an issue and put a glitch filter between the pad and the management SoC input, or else implement a digital glitch filter in the SoC, for MPW-three.

@Tim Edwards I spend good amount of time everyday to summarize information on all related issues. I think this info will work as a gold mine for next iteration of MPW. However, some core issues like JTAG and HKSPI need to be frozen asap.

Well in my design there is a input pin (button) which will interrupt my design (azadi_soc) to load instructions into the Instruction memory, So I was thinking to use mpjr_io[7] for that.

@Zeeshan Rafique: Back to the original question: Yes, I think you should be able to connect your UART and SPI to the same pins used by the management. You should be able to confirm that this works with a testbench. The UART should have no issues, since it has to be enabled by the management SoC to be used by the management SoC. The SPI can cause issues with simulation when an unknown value on CSB propagates through the simulation. If that ends up being a problem, there are some testbenches I can point you to that loop the housekeeping SPI back to the SPI master so that all of the housekeeping control pins remain well defined.

Oh thank you.

@Zeeshan Rafique: Be advised that there is a JTAG pin on caravel, but there is no JTAG circuit connected to it. This has been left reserved for now. We tested a version of the caravel management SoC with scan flops on MPW-one. Once we get that back and test it, we will replace the management SoC with a DFT version. My intention is that the JTAG pin would be tms, and that when in JTAG mode, additional pins would be repurposed for the JTAG tck, tdi, and tdo, probably from the SPI pins (SDK, SDI, and SDO, respectively).

Okay got your point, thank you.