Create read/write UART user interface on Arty for manipulating RTL registers

[Mighty Joe]

I have an Arty and I want to be able to change RTL register parameters on-the-fly via the UART interface. I would prefer to write the user interface in c as I assume that provides more flexibility for an elegant user interface. In addition, I prefer that most (if not all) sources are text based, for source control.

How can this be implemented? I have seen RTL-only examples and microblaze-only examples. In my case, the design is primarily RTL, but with a user interface for register manipulation. Also, can this be implemented without creating a block design?

[zygot]

30 minutes ago, Mighty Joe said:

I have an Arty and I want to be able to change RTL register parameters on-the-fly via the UART interface.

The UART is a great way to control HDL designs from a PC as well as read the contents of status registers. I've posted many projects in the Project Vault that do just that. I believe that you can use the CmodA35T_test.dcp netlist for your board even though it was created for the CMOD-A7. The CmodA735TDemo is in the Project Vault. There's code and documentation on how to use it. You won't have access to all of the registers but enough of them to see how one implementation might work. Of course you can design and code your own interface. This would be the best way to go about it but will involve a lot more work, potentially.

I highly encourage you to wean yourself off of the MicroBlaze design approach and into an all HDL design approach. There's nothing that MicroBlaze can do that you can't do yourself. I never use the block design approach except for ZYNQ based projects where it is unavoidable; and then I do as little in the block design as possible.

The block design approach is easy ( at least on one level ) but doesn't give you freedom to do anything that you want. The all HDL design approach gives you the freedom to do anything that you want but isn't easy; it does get easier with increased competence and experience. No matter how long you use the block design approach you will never learn how to leave its walled garden and be free.

 

[xc6lx45]

>> UART

One hint: check your future plans whether you can live without flow control. That is, the FPGA as data sink will always be able to handle incoming data, as fast as it comes in

It is a small thing, until it becomes "the small thing that sank the ship".

The FTDI chip does support RTS / CTS handshaking but those lines aren't necessarily available to the FPGA for the on-board USB interface.

[zygot]

46 minutes ago, xc6lx45 said:

One hint: check your future plans whether you can live without flow control. That is, the FPGA as data sink will always be able to handle incoming data, as fast as it comes in

A good point, and this applies to your HDL UART as both data sink and data source. You can address such problems with a FIFO, flow control, or both. It really depends on what kind of application your UART is used for. For writing registers a FIFO isn't generally very large as you usually only have to worry about 1 or two Rx characters unless you are doing something odd. For reading registers the application can usually wait until the current information is obtained before requesting another one. When you are spitting out lines of ascii characters at a high rate, such as might happen when your HDL UART is sending text based on events in the HDL, you should anticipate that the receiving UART can't always keep up. Generally you can scale the Tx FIFO size accordingly with a bit of calculation. In this case the FIFO is better situated between the code that creates text and the UART rather than in the UART.

It's always a good idea to put some effort into system level analysis. Otherwise you can end up over designing your HDL modules. A good rule of thumb is to keep averything as simple as they need to be for your current application. The thing about writing your own IP is that you can always create variations to fit different use cases. If you do HDL design properly, that is by writing testbenches, when you revisit a module that you've written years ago, running the simulation will help you remember how your constructed your first version. Always keep good notes. Always document your code. It's not always easy to figure out important details of a design by simply reading source code. 

I use a lot of FIFOs in my designs. I can't remember any cases where I used flow control. I certainly can think of a few that uses a FIFO. While we're talking about flow control there are two types:

1. hardware e.g. CTS RTS
2. embedded characters like XON, XOFF

[xc6lx45]

10 hours ago, zygot said:

...

2. embedded characters like XON, XOFF

Very good point, and for an ASCII-based protocol this could be the "get-out-of-jail" card.

Just keep in mind, "high baudrate" is usually motivated by "need more performance", and this goes hand-in-hand with "binary data" (rule-of-thumb: hex formatting uses 4 bits out of 8 => roughly equivalent to half the binary baudrate). Which is not directly compatible with control-character handshaking when the whole character set is used.

[zygot]

It's very easy to get sucked into trying to make what you are working on be optimal for all applications in every aspect. Generally, this ends in defeat and frustration. For most of my published demo projects I just want to be able to interact with 'remote' hardware in a flexible, easy to view, manner. This has meant using either typing commands into a terminal application like Putty or using a scripted interpreter like Python or OCTAVE in which serial communication is relatively simple. The nature of how this is done naturally implies that flow control isn't going to be a big problem, and if it is then I can handle it easily on a system level. I can only type commands into a terminal so fast. If I'm using a script to send and receive ascii text then I can modify the script as needed to avoid dropping characters. That's what I mean by spending time thinking about the system level parts of a design. You can often simplify the requirements and complexity of a low level design considerably by understanding system level interactions.

If you are trying to transfer very large amounts of data quickly over a UART then the old RS-232 concept of a UART isn't what you want and mapping 12 or 24 bit data into 16 ascii chars is a bad plan. Of course you can always re-imagine the old 8 or 9 bit RS-232 UART in a way that is much more suitable to your needs. But all serialized forms of data transfer has their limits and penalties.  The designer just has to do his homework carefully to avoid wasting his time on impossible missions.

921600 is plenty fast and easy for controlling the functionality of FPGA designs... provided that you aren't trying to make the data channel do something that is isn't capable of doing.

[Mighty Joe]

Thank you, @xc6lx45 and @zygot. All great advice. The register access capabilities that I need are single register write and monitoring (no streaming). Technically, basic ChipScope capability but without end user requirement of installing an IDE (hence UART). So no concern with flow control and the referenced project in Project vault is directly applicable. The user will read/write in physical units (voltage, time, angle) and the code will perform the necessary translation to register values in the background. So divisions and rounding will be involved, which is why I considered c as an alternative. However as @zygot suggests this is all still doable in HDL and I am keen to make this an HDL-only design.

[zygot]

So, did you at least check out this project? https://forum.digilentinc.com/topic/2866-cmod-a7-35t-demo-project/

If nothing else you can see one way to do what you want to do and if you don't like it have a basis for designing a better user interface.

[PhDev]

Hi,

I think you should have a look at Instant SoC. It is a very simple way to solve what you want to do.

It compiles C/C++ to vhdl and have classes for UARTs etc. You can do division, truncation and so on. It is free to download and use.