According to the WICED™ Smart Hardware Interfaces (note that this was written for the SoC, but can also be used for the SIP module with limitations such as the WP pin that is bonded internally to P1), you should be able to use P2 (RXD), P0 (TXD), P3 (CTS) and P1 (RTS).
I think these would first need to be configured by the high level API (example configuration for the low level API is available in the document referenced above) from within the application.
Note that Hardware flow control is optional (and has never been tested on the TAG board, which uses the SoC), in which case, CTS and RTS signals will not be configured by the driver API.
There is more information on GPIO configuration/pin mappings here near the bottom: BCM2073XS GPIO Basics
Also note that with an SoC design, you and the regulatory house you choose to work with will be responsible to take the device through full regulatory with little support through the forum as we are only setup internally to support the leveraging of our Limited Modular Approval for the SIP.
Hello mwf_mmfae, thanks for your answer
I just realize that I was going to a bad direction: we don't need the rts/cts anymore and so we don't need to make a SoC design
I thought I needed the hardware flow control because I could not achieve a puart speed greater than 19200 without problem of fifo overrun
This was because in my interrupt function I sent some debug info with ble_trace function which took too much time, by removing these traces, I can communicate at 115200 and it uses only 1/3 of the 16 bytes fifo capacity !!!