Automated Documentation of Space-Borne FPGA Designs

Over the past three years, I’ve spoken frequently with Cristian Amitroaie, CEO and co-founder of AMIQ EDA, to understand how the company is helping engineers cope with the challenges of chip design and verification. With their broad customer base and many years of experience in the EDA business, the folks at AMIQ really seem to understand what their users need and how they can help.

As I was thinking that it was about time to touch base with them again, it occurred to me that I had never had the chance to interview one of their users. As soon as I asked, Cristian introduced me to three engineers from Kepler Communications Inc. Alexander Smith is an FPGA designer, Eric Murphy Zaremba is a member of the software team, and Francisco Morales is a project manager. They kindly agreed to spend some time with me to talk about the challenges they face in their chip projects and how AMIQ EDA has been able to help. Here’s a summary of our discussion.

Q: Let’s start with the company. I see from your website URL Kepler.space that you appear to be developing space-based applications. Is this accurate?

A: Very much so. Our mission is to build the Internet in space. We design and build satellites that are launched into low-earth orbit.

Q: It seems that a bunch of companies are providing satellite-based Internet connectivity; what makes Kepler unique?

A: Good question. We are very different. All those other companies are trying to use satellites to provide Internet access to Earth-based users. Our goal is to provide Internet access to space-borne asserts, including satellites, space stations, launch vehicles, and habitats.

Q: But those applications already talk to Earth and can access the Internet that way. Where does Kepler come in?

A: Satellite communication requires line of sight, so there are many times when space-borne assets are out of contact with the ground. A typical customer of ours has only a few ground stations, so connectivity is highly intermittent. It is expensive and logistically difficult to license ground stations all around the world. With our full constellation of satellites, we will always be in contact with the ground and able to connect any space-borne asset with the Internet 24×7. Our Internet in space provides universal access with speed and reliability comparable to what’s available on Earth.

Q: Doesn’t that require a lot of satellites?

A: Yes, it does. When fully built out, we will have 100-200 satellites in our constellation. We have 19 in operation already, so at this point we can provide space-based store-and-forward data services. With every additional group of satellites deployed, we move closer to universal real-time Internet connectivity in space.

Q: That is fascinating. Do you develop the satellites yourselves?

A: Yes, we design and assemble the payloads in house. We use FPGAs to implement what is essentially a software-defined radio to provide the connectivity both to other space assets and to ground stations on Earth.

Q: Can you give me a sense of the complexity of your designs and your design flow?

A: We use a Xilinx FPGA that has around 270K look-up tables (LUTs), so it’s significant in size. We have more than 450 Kepler-written RTL modules and almost 300 additional modules from other library and IP sources. The design includes an Arm processor, so software plays a key role in system operation. Our design flow is fairly standard: we write SystemVerilog RTL code and feed it into Xilinx logic synthesis and place-and-route tools. The design itself is quite complex and challenging, but we haven’t had any major issues in design implementation.

Q: What issues did you have in your development process?

A: Well, documentation turned out to be a big challenge. Given that we’re developing a whole new type of application, our design is quite novel, and it evolved a lot over the course of the project as we learned new things and added more functionality. Every time this happened, it was vital that the design documentation be updated correctly to match the design changes. Of course, when a module changes, designers of the adjoining modules need to know. Many hardware changes also require updates to the embedded software running on the Arm processor, and the documentation is the official way to communicate between the two teams.

Q: How did you address this issue?

A: Several members of the team had experience with Python’s built-in documentation capabilities and with Doxygen, which automatically generates documentation from annotated C/C++ code. We thought that there might be a similar open-source solution for SystemVerilog, but we uncovered none that supported all the constructs we used. When we investigated commercial solutions, we quickly found that only Specador Documentation Generator from AMIQ EDA had the features we needed.

Q: How do you use Specador to generate your documentation?

A: Because it’s built on the same technology that AMIQ uses for all its tools, it fully comprehends the SystemVerilog design. It automatically documents the design hierarchy by reading the modules and ports from the RTL code. It generates usage lists for submodules, including the conditions from generate statements. We were particularly impressed by this; it’s a good example of how Specador really “understands” the code.

The generation includes the contents of comment blocks, so we can add text to be incorporated in the documentation. We can create tables more easily than with other methods we’ve used in the past. Specador also generates nice diagrams for finite state machines (FSMs) and timing diagrams as specified with the popular Wavedrom format.

Q: That sounds like a lot of functionality. Is there more?

A: We should also mention the generation of register maps, since the application programming interface (API) for the registers is the main point of interaction between the software and the hardware. We write up register maps in code comments, which Specador includes in the documentation. The automatic regeneration of documents whenever registers change ensures that the software and hardware stay in sync. In fact, the programmers include permalinks to the relevant documentation pages right in their embedded source code.

Q: Who uses the generated documentation? Internal teams only, or customers as well?

A: As mentioned earlier, the documentation is critical for hardware and software engineers to stay in sync. We use our boards only for our own systems, so there’s no need for end customer documentation. However, we have used subcontractors to help with our projects, and we used to have to update their documentation by hand. We can now keep them in sync as well.

Q: How is Specador run in your development flow?

A: We use a continuous integration (CI) methodology, in which builds and tests are automatically triggered whenever RTL or software is checked in. Specador is run at least once a day on the whole design automatically as part of the nightly build process, and sometimes more frequently by individual users.

Q: Is there anything you don’t like about Specador?

A: The generated documentation is sparse, but it serves our needs for internal communication. Specador can be a bit “overzealous” in doing certain types of formatting. We just go back and tweak our code, but perhaps a bit more control would be nice. We’ve also requested a more intuitive way to specify register maps since the hardware/software API is so important to us. AMIQ has been responsive to our suggestions, and we haven’t found any serious problems with the tool.

Q: Can you quantify the benefits of using Specador for your FPGA designs?

A: Clearly, we save minutes or hours manually editing the documentation whenever something changes in the design, and that adds up over time. Since the documentation remains in sync, it serves as the communication mechanism it should be. This saves multiple email messages and voice calls among team members each day as the design evolves. This has been even more valuable during the pandemic, with many engineers working from home on varying schedules. We can’t just stick our heads into nearby cubicles to ask quick questions.

Perhaps the biggest saving comes from not having to debug tricky problems that occur when the hardware and software get out of sync. It’s hard to quantify, but surely that saves weeks of effort throughout the course of the project.

Q: Do you have any changes planned for the future?

A: We have every intention of continuing to use Specador on all our designs. It’s been a real benefit for us.

Q: Thank you for sharing all this great information!

A: It was a pleasure.

Also read:

Continuous Integration of RISC-V Testbenches

Continuous Integration of UVM Testbenches

What’s New with UVM and UVM Checking?