Arty100T board + TSI-over-UART

[jerryz123]

Thanks @tianrui-wei for the help on bringing up the Arty DDR,

This PR adds support for the Arty100T board through FPGA-shells. The existing arty sub-project behaves as before.

This PR also adds a new UART-based bringup mechanism for FPGA prototypes or test chips. A special FESVR implementation running on the host PC can connect to a TTY for the serial-adapter interface. A special UART device on the FPGA board converts the UART back to TSI commands, driving the FPGA serial-adapter. This bypasses the need for a soft-core-on-FPGA for bringing up chips. Existing FESVR functionality is all preserved, since the PC-fesvr just extends testchip_tsi_t.

Notably, this also enables more accurate simulated bringup of RTL-simulations or FPGA-emulated systems. As long as the target implements the UART-to-TSI converter, and the SimUART can open a pty on the host PC, uart_tsi can connect to it and interact with it like a normal UART.

After generating and programming a arty100t board with cd fpga && make SUB_PROJECT=arty100t bitstream, the target can be manipulated like:

Running a program

>  ./uart_tsi +tty=/dev/ttyUSB1 dhrystone.riscv
Attempting to open TTY at /dev/ttyUSB1
Constructed uart_tsi_t
Checking connection status with /dev/ttyUSB1
Connection succeeded
Microseconds for one run through Dhrystone: 452
Dhrystones per Second:                      2211
mcycle = 226186
minstret = 187526
Done, shutting down, flushing UART

Probing some address

> ./uart_tsi +tty=/dev/ttyUSB1 +init_read=0x10040 none
Attempting to open TTY at /dev/ttyUSB1
Checking connection status with /dev/ttyUSB1
Connection succeeded
Reading 10040 ... got 517

Writing some address before running a program

> ./uart_tsi +tty=/dev/ttyUSB1 +init_write=0x88000000:0xdeadbeef test.riscv
Attempting to open TTY at /dev/ttyUSB1
Checking connection status with /dev/ttyUSB1
Connection succeeded
Writing 88000000 with deadbeef
Done writing 88000000 with deadbeef
Hello world
Target reading from 0x88000000 - got deadbeef
Done, shutting down, flushing UART

Self-check (check that serial-adapter can read the program that was written):

> ./uart_tsi +tty=/dev/ttyUSB1 +selfcheck dhrystone.riscv
Attempting to open TTY at /dev/ttyUSB1
Checking connection status with /dev/ttyUSB1
Connection succeeded
Performing self check
Self check success
Microseconds for one run through Dhrystone: 452
Dhrystones per Second:                      2207
mcycle = 226534
minstret = 187526
Done, shutting down, flushing UART

Running designs with higher baudrate on the TSI-UART (UART921600RocketArty100TConfig)

> ./uart_tsi +tty=/dev/ttyUSB1 +baudrate=921600 dhrystone.riscv
Attempting to open TTY at /dev/ttyUSB1
Checking connection status with /dev/ttyUSB1
Connection succeeded
Microseconds for one run through Dhrystone: 452
Dhrystones per Second:                      2207
mcycle = 226534
minstret = 187526
Done, shutting down, flushing UART

Related PRs / Issues:

Type of change:

• Bug fix
• New feature
• Other enhancement

Impact:

• RTL change
• Software change (RISC-V software)
• Build system change
• Other

Contributor Checklist:

• Did you set main as the base branch?
• Is this PR's title suitable for inclusion in the changelog and have you added a changelog:<topic> label?
• Did you state the type-of-change/impact?
• Did you delete any extraneous prints/debugging code?
• Did you mark the PR with a changelog: label?
• (If applicable) Did you update the conda .conda-lock.yml file if you updated the conda requirements file?
• (If applicable) Did you add documentation for the feature?
• (If applicable) Did you add a test demonstrating the PR?

• (If applicable) Did you mark the PR as Please Backport?

[harrisonliew]

This is awesome!

One point of remaining confusion for me - for chip bringup specifically, would you use the NoCoresArty100TConfig instead of one of the Rocket ones?

[jerryz123]

One point of remaining confusion for me - for chip bringup specifically, would you use the NoCoresArty100TConfig instead of one of the Rocket ones?

Yes the intention is that you would use a NoCoresConfig, and use a TLSerdesser to cross between the FPGA and the test chip's serialized TL port.

It would be a nice project to demonstrate this with 2 Artys.

[jerryz123]

Failures seem to be transient. Commit-on-master fail for FPGA-shells has been resolved. Merging to unblock other PRs.

[Dai-dirk]

Yes the intention is that you would use a NoCoresConfig, and use a TLSerdesser to cross between the FPGA and the test chip's serialized TL port.

It would be a nice project to demonstrate this with 2 Artys.

One point of remaining confusion for me - for chip bringup specifically, would you use the NoCoresArty100TConfig instead of one of the Rocket ones?

Yes the intention is that you would use a NoCoresConfig, and use a TLSerdesser to cross between the FPGA and the test chip's serialized TL port.

It would be a nice project to demonstrate this with 2 Artys.

Hi, does it means I need to connect the serialized TL signals to the top of the FPGA design for the Arty with NoCoresConfig? Then, these serialized TL signals can be connected to another Arty with RocketCore via some physical wires and making this Arty with RocketCore can be bring up?

[jerryz123]

Hi, does it means I need to connect the serialized TL signals to the top of the FPGA design for the Arty with NoCoresConfig? Then, these serialized TL signals can be connected to another Arty with RocketCore via some physical wires and making this Arty with RocketCore can be bring up?

Yes