How can I passthrough data from FPGA to PC with USB UART on the PS?

[lowena]

I followed this tutorial and I understand how to connect physical pins to the PS, but I can't figure out how to pass data from the FPGA to the PS. For example, for a Hello World application, sending the text "hello world" from the FPGA to the PS then to my computer so I can get the output with a serial terminal. I know this is easily possible with C on the PS, but I want to learn FPGA hardware design; eventually work my way up to things like implementing a 6502 on the FPGA in Verilog using UART to for input and output.

So essentially, how can I make a transparent UART passthrough to exchange data between the PS and PL? I assume it'd be connecting a Verilog wire to the AXI bus somehow, but I don't know how to do that.

Thank you!

[BogdanVanca]

Hello,

First, As you may think you have to write your own UART vhdl/verilog module,  with an RS323 interface. After you make sure that it works correctly, you have to add to your code and axi lite interface.  There are two ways for doing that:

1. You add it by your own, and keep your code as a module. 

2. Package your module as an custom ip and use the template given by Xilinx. 

Personally, I will probably go with the second option. And that is because, the template is clearly written and commented. Inside this template there is a state machine that gives you access to a couple of registers.Trough these registers you can pass data from PL to PS side. After you have your own IP, you can add it into a block design and connect it trough the AXI Interconnect. On this stage your IP will have it's own address into the address editor. With that, you can access trough the lite interface each individual register.  

 

Best Regards,

Bogdan Vanca 

 

[zygot]

It is possible to mux PL pins to ZYNQ PS peripherals. You can, for instance use one PS UART connected to the MIO pins as normal and connect a second PS UART to PL IO pins. For a two pin UART interface this pretty easy to do. For an Ethernet interface not so easy.

It sounds to me as if what you want to do is leverage your ZYNQ platform into something that let's you experiment with Verilog designs. You can certainly start with the board design flow to experiment with exchanging data between the PS and PL Verilog code. Simply adding GPIO ports that connect to PMODs would be a place to start. Later you can experiment with using BRAM or you own IP. Personally, I find that having Vivado create a toplevel HDL source that I control works best; but I'm pretty comfortable with HDL design. In my case I create my own HDL toplevel design source and instantiate the board design HDL code. This make connecting HDL code to open ports and pins straight-forward.

If you can afford it I strongly urge you to consider buying a cheap non-ARM based FPGA development board to learn Verilog development. It's just a lot less complicated. There are a number of options for nice <$100 FPGA boards, though the best one's for the money might not be Xilinx based. Once you figure out how to implement something in HDL that you can interact with using , say a UART, then try an integrate your HDL into the ZYNQ platform. There is HDL code projects on other areas of the Digilent forums to play with to help get started. A UART is the easiest interface for debugging or connecting an HDL design to PC applications. For <$10 a good 3.3V TTL USB UART breakout module or cable is indespensibe.

It is also possible to tie off the PS and just use your board as an FPGA platform; this is not something that I'd recommend.

In the end you should choose the best strategy for you. Just don't be afraid to ditch a processor based design because it seems daunting. Before you are ready to implement a 6502 soft processor with peripherals in logic you should be comfortable implementing, simulating, and debugging "peripherals" in the HDL of your choice. At least that's the view from where I sit. 

[lowena]

I knew the board had an ARM processor when I got it, but did not realize that it's not possible to use USB from the FPGA directly, unfortunately. It is too complicated for me with my current knowledge. I'm going to get a TinyFPGA BX, cheap and much simpler. Thanks for your input!

[zygot]

2 hours ago, lowena said:

but did not realize that it's not possible to use USB from the FPGA directly

I'm not sure that I understand this statement. You can't implement a UART in the PL and connect it's RxD and TxD signals to the PS MIO pins that are connected to a USB UART device on your board.

2 hours ago, lowena said:

I'm going to get a TinyFPGA BX, cheap and much simpler

I will caution you to consider how you are going to configure your FPGA device. Development boards made by Digilent or Terasic include the hardware for configuring the device as well as using debugging IP from the tools. Before making a selection understand how the configuration works and if it works with the FPGA vendor's tools. Ideally, an FPGA development board will have a standard JTAG header as an alternative means for these functions. I would suggest that beginners avoid boards that restrict configuration to a custom and or closed format. Some of the low end so called FPGA development boards are too cheap and or too difficult to use. As a beginner you want all the help and options for development that you can get so choose wisely. Some choices require more effort in figuring out what you are going to get.

[xc6lx45]

Hint, you can use a Zynq like an Artix, just disregard the ARM processor and integrate a UART on the FPGA fabric.
As the board's built-in serial-to-USB connection is most likely hard-wired to the PS, you'll need an external serial-to-USB (e.g. "FTDI") board.

Zynq is a difficult platform for a start from square one. the above-mentioned UART wiring being one of the first snags to run into. The regular FPGA e.g. on the CMOD A7 module is more friendly.

Note that the simplicity of the Lattice board you mentioned comes from a heavy layer of code on both PC and FPGA side (bootloader). It's not necessarily a bad thing but be aware that it just postpones hitting the learning curve to the time when you need to leave the well-trodden paths. And then, things get messy (as compared to plain ol' "industry standard" JTAG connectivity).