Support2023, Year in review
It should come as no surprise that a blog with no advertisements has never paid my bills–at least not directly. I blog for fun, and to some extent for rubber duck debugging. As I learn new concepts, I enjoy sharing them here. Going through the rigor to write about a topic also helps to make sure I understand the topic as well.
Why are there no advertisements? For two reasons. First, because I’m not doing this to make money. Second, because because I want more control over any advertising from this site than most advertisers want to provide. Perhaps some day the site will be supported by advertising. Until then, the web site works fine without advertisements.
So how then does the blog fit into my business model? Simply because the blog helps me find customers via those who read articles here and write to me.
Business Projects
So, if the blog doesn’t pay my bills, then what does?
 |
Well, six projects have paid the bills this year. Three of these have been ASIC projects, to include the PSRAM/NOR flash controller, and an ONFI NAND flash controller. Three other projects this year have been FPGA projects, to include an open source 10Gb Ethernet switch and a SONAR front end based upon my VideoZip design–after including several very significant upgrades, such as handling ARP and ICMP requests in hardware. That’s four of the six projects from this year. Once the other two projects become a bit more marketable, I may mention them here as well.
Since I’ve already discussed the 10Gb Ethernet design, let me take a moment and discuss the I2C controller within it. The I2C controller was originally designed to support the SONAR project. Perhaps you may remember the initial article, outlining the design goals for this controller. Thankfully, it’s met all of these goals and more–but we’ll get to that in a moment. As part of the SONAR project, its purpose was to sample various non-acoustic telemetry data: temperature, power supply voltage, current usage, humidity within the enclosure, and more. All of these needed to be sampled at regular intervals. At first glance, this sounds like a software task–that is until you start adding real-time requirements to it such as the need to shut down the SONAR transmitter if it starts overheating, or using so much power that the FPGA itself will brown out shortly. So, the I2C controller was designed to generate (AXI stream) data packets automatically, without CPU intervention, which could then be forwarded … somewhere.
 |
This design was then incorporated into the 10Gb Ethernet design. There it provided the team the ability to 1) read the DDR3 memory stick configuration–useful for making sure the DDR3 controller was properly configured, 2) read the SFP+ configuration–and discover that we were using 1GbE SFP+ connectors initially instead of 10GbE connectors (Oops!), 3) read the Extended Display Identification Data (EDID) from the downstream HDMI monitor, 4) configure and verify the Si5324’s register settings, 5) draw a logo onto a small OLED display, all in addition to 6) actively monitoring hardware temperature.
Supporting these additional tasks required two fundamental changes to the initial vision for this I2C controller. First, I needed an I2C DMA, to quietly transfer results read from the device to memory. Only once I had this DMA could the CPU then inspect and/or report on the results. (It was probably one of the easiest DMA’s I’ve written, since I2C is a rather slow protocol.) Second, each packet needed a designated destination channel, so the design could know where to forward the results. This was useful for knowing if the I2C information should be forwarded to the DMA, for storing in memory, or the HDMI slave controller, for forwarding the downstream monitor’s EDID to the upstream monitor. The fact that this controller, designed for completely separate project, in a completely different domain (i.e. SONAR), ended up working so well in an 10Gb Ethernet design project is a basic testament to a well designed interface.
The year has also included some internally funded projects. These include a new SDIO/eMMC controller, a (to-be-posted) upgrade to my standard debugging bus, and a ZipCPU upgrade. Allow me to take a moment to discuss these three (unfunded) projects in a bit more detail.
The SDIO/eMMC controller is new. By using all four data lanes and a higher clock rate, this upgrade offers a minimum 8x transfer rate performance improvement over my prior SPI-only version. That’s kind of exciting. Even better, the IP has been tested on both an SD card as well as an eMMC chip as part of the KlusterLab (i.e. 10Gb Ethernet board) design. The IP, plus software, is so awesome I’m likely to add it to any future designs I have with SD cards or eMMC chips in the future.
 |
That’s just the beginning, too. Just because this new SDIO controller works on hardware, doesn’t mean it works in all modes. Since its original posting, I’ve added verification to support all the modes our hardware doesn’t (yet) support. I’ve also started adding eMMC BOOT mode support, and I expect I’ll be (eventually) adding DMA support to this IP as well. My goal is also to make sure I can support multiple sector read or write commands–something the SPI only version couldn’t support, and something that’s supposed to be supported in this new version but isn’t tested (yet). (Remember, if it’s not tested it doesn’t work.) In other words, despite declaring this IP as “working”, it remains under very active development.
 |
Then there’s the upgrade to the debuging
bus. This has been in the works now for
quite a while. My current/best debugging bus implementation
uses six printable characters to transmit a control code (read request, write
data, or new address) plus 32-bits of data. At six data bits per 8-bit
character transmitted, this meant six characters would need to be sent
(minimum) in order to send either a 32-bit address or 32-bit data word,
leading to a 36b internal word. It also required 10*6 baud periods (10 baud
periods times six characters) for every uncompressed 32b of data transferred,
for a best case efficiency of 53%.
 |
Since then, I’ve slowly been working on an upgrade to this protocol that will use five (not necessarily printable) characters to transmit 32-bits of data plus a control code. This upgrade should achieve an overall 64% worst case (i.e. uncompressed) efficiency, for a speed improvement of about 16% over the prior controller in worst case conditions. The upgrade comes with some synchronization challenges, but currently passes all of its simulation checks–so at this point it’s ready for hardware testing. My only problem is … this upgrade isn’t paid for. Inserting it into one of my business projects is likely to increase the cost of that project–both in terms of integration time as well as verification while chasing down any new bugs introduced by this new implementation–at least until the upgraded bus is verified. This has kept this debugging bus upgrade at a lower priority to the other paying projects. Well, that and the fact that I only expect a 16% improvement over the prior implementation. As a result, the upgrade isn’t likely to pay for itself for a long time.
 |
Finally, let’s discuss the ZipCPU’s big upgrades. As with the other upgrades, these were also internally funded. However, the ZipCPU has now formed a backdrop to a majority of my projects. Indeed, it’s helped me verify ASIC IP in both simulation and FPGA contexts. One upgrade in particular will keep on giving, and that is the ZipCPU’s new DMA controller. I’ve already managed to integrate it into a (work in progress) SATA controller, and I’m likely to retarget this DMA engine (plus a small state machine) to meet the DMA needs of my new SDIO/eMMC controller. Indeed, it is so versatile that I’m likely to use this controller across a lot of projects. Better yet, at this rate, I’m likely to build an AXI version of this new DMA supporting all of these features as well. It’s just that good.
 |
As for dollars? Well, let’s put it this way: the year is now over, and I’m still in business. Not only that, but I’ve also managed to keep two kids in college this year. More specifically, I expect my third child to graduate from college this year. (Five to go …) So, I’ve been hanging in there, and I thank my God that my bills have been paid.
Articles
2023 has been a slower year for articles than past years. Much of this is due to the fact that my time has been so well spent on other paying projects. That’s left less time for blogging. (No, it doesn’t help that my family has fallen in love with Football, and that my major blogging times have been spent watching my son’s high school games, Air Force Academy Falcon’s football, the Kansas City Chiefs, Miami Dolphins, Philadelphia Eagles, and my own home team–the disappointing Minnesota Vikings.) Still, I have managed to push out seven new articles this year. Let’s look at each, and see how easy they can be found using DuckDuckGo.
 |
-
This article discusses some of the challenges I went through when debugging modifications I made to a working ECC algorithm. ECC, of course, is one of those “hard” problems to debug since the intermediate data tends to look meaningless when viewed.
DuckDuckGo Ranking: A search for “FPGA ECC Debugging” brings up the ZipCPU home page as return #111.
That’s kind of disappointing. Let’s try a search using Google. Google finds the correct page immediately as its #1 result. At first I thought the difference was because Google knew I was interested in ZipCPU results. Then I asked my daughter to repeat my test on her phone in private mode. (She has no interest in FPGA anything, so this would be a first for her.) Her Google ranking came up identical, so maybe I can trust this Google ranking.
 |
The ZipCPU was originally designed to be a System within a Chip, or a SwiC as I called it. This article discusses what a SwiC is, and tries to answer the question of whether or not a SwiC makes sense, or equivalently whether or not the ZipCPU made for a good SwiC in the first place. In many ways, this article was a review of whether or not the ZipCPU’s design goals were appropriate, and whether or not they’ve been met.
DuckDuckGo Ranking: Searches on SwiC return all kinds of irrelevant results, and searches on “System within a Chip” return all kinds of results for “Systems on a Chip”. If you cheat and search for “ZipCPU SwiC”, you get the ZipCPU web site as the #1 page.
-
What is a Virtual Packet FIFO?
A virtual FIFO is a first-in, first-out data structure built in hardware, but using external memory–such as a DDR3 SDRAM–for its memory. A virtual packet FIFO is a virtual FIFO that guarantees completed packets and packet boundaries, in spite of any back pressure that might otherwise cause the FIFO to fill or overflow.
 |
This article goes over the why’s and how’s of a virtual packet FIFO: why you might need it, how to use it, and how it works.
Since writing this article, I’ve now built and tested a Wishbone based virtual packet FIFO as part of the 10Gb Ethernet project. Conclusion? First, verifying the FIFO is a pain. Second, I might be able to tune its memory usage with some better buffering. But, overall, the FIFO itself works quite nicely in all kinds of environments.
DuckDuckGo ranking: The ZipCPU blog comes up as the #2 ranking on DuckDuckGo following a search for “Virtual Packet FIFO”. The ZipCPU reddit page comes up as the #7 ranking. The page itself? Not listed. However, both of the prior pages point to this article, so I’m going to give this a DuckDuckGo ranking of #2. Sadly, most of DuckDuckGo’s other results are completely irrelevant to a Virtual Packet FIFO. In general, they’re about Virtual FIFOs–not Virtual Packet FIFOs. As before, though, Google gets the right article as it’s number one search result.
-
After years of updates, ZipCPU 3.0 is here! This means that the ZipCPU now has support for multiple bus structures, wide bus widths, clock stopping, and a brand new DMA. The article announces this new release, and discusses the importance of each of these major upgrades.
DuckDuckGo Ranking: A search for “ZipCPU” on DuckDuckGo yields ZipCPU.com as the #1 search result. That’s good enough for me.
-
Using a Verilog task to simulate a packet generator for an SDIO controller
I haven’t written a lot about either Verilog test benches, or how to build them, so this is a bit of a new topic for me. Specifically, the question involved was how to make your test bench generate properly synchronous stimuli. No, the correct answer is NOT to generate your stimulus on the negative edge of the clock.
DuckDuckGo Ranking: A search for “SDIO Verilog Tasks” on DuckDuckGo yields the SDIO repository as the #31 search result. (Google returns the correct article, after searching for “SDIO Verilog” at #3.)
-
SDIO RX: Bugs found with formal methods
If you’ve read my blog often enough, you’ll know that I’m known for formally verifying my designs. In the case of the new SDIO/eMMC controller, I had it “working” on hardware before either the formal verification or the full simulation model were complete. This leaves open the question, how many bugs were missed by my hardware and (partial) simulation testing?
The article spends a lot of time also discussing “why” proper verification, whether formal or simulation, is so important.
DuckDuckGo Ranking: A search for “SDIO formal verification” turns up the ZipCPU blog as result #69. Adding “verilog” to the search terms, returns the blog as number #46. As before, Google returns the right article as the #1 search result after only searching for “SDIO formal”.
-
An Overview of a 10Gb Ethernet Switch
As I mentioned above, one of the big projects of mine this year was a 10Gb Ethernet switch. This article goes over the basics of the switch, and how the various data paths within the design move data around.
DuckDuckGo Ranking: A search for “10Gb Ethernet Switch FPGA” turns up the Ethernet design as the #16 result, and a search on “10Gb Ethernet Switch Verilog” returns the same github result as the #1 result. Curiously, the 10Gb Ethernet test bench model for the same repository comes up as the #2 result.
For all those who like to spam my email account, my conclusions from these numbers are simple: 1) the ZipCPU blog holds its own just fine on a Google ranking, and 2) DuckDuckGo’s search engine needs work. If you want to sell me web-based services and don’t know this, I’ll assume you haven’t done your homework and leave your email in my spam box.
Upcoming Projects
So, what’s next for 2024? Here are some of the things I know of. Some of these are paid for, others still need funding.
 |
Still, this is a good list to start from:
-
One of my ASIC projects is in the middle of a massive speed upgrade. This is not a clock upgrade, or a fastest supported frequency upgrade, but rather an upgrade to adjust the internal state machine. I’m anticipating an additional speed up of between 8x and 256x as a result of this upgrade.
Status? Funded.
-
My brand new SDIO/eMMC controller has neither eMMC boot support, nor DMA support. Boot support might allow me to boot the ZipCPU directly from an eMMC card, whereas DMA support would allow the ZipCPU to read lots of data from the card without CPU interaction. Both may be on the near-term horizon, although neither upgrade is funded.
 |
Status? Not funded. On the other hand, this project fits quite nicely on my laptop for those days when I have the opportunity to take my son to his basketball practice … (He’s a 6’4” high school freshman, who is new to the sport as of this year …)
-
AutoFPGA is now, and has for some time, been a backbone of any of my designs. I use it for everything. It makes adding and removing IP components easy. One of its key capabilities is address assignment (and adjustment). Sadly, it’s worked so well that it now needs some maintenance. Specifically, I’d like to upgrade it so that it can handle partially fixed addressing, such as when some addresses are given and fixed while others are allowed to change from one design to the next. This is only a precursor, though, to supporting 2GB memories where the memory address range overlaps one of the ZipSystem’s fixed address ranges.
Status? A funded (SONAR) project requires these upgrades. Unlike my current SONAR project, built around Digilent’s Nexys Video board, this one will be built around Enclustra’s Mercury KX2, and so either AutoFPGA gets upgraded or I can’t use the full memory range.
-
The ZipCPU’s GCC backend urgently needs a fix. Specifically, it has a problem with tail (sibling) calls that jump to register addresses. This problem was revealed when testing the SDIO/eMMC software drivers, and needs a proper fix before I can make any more progress on upgrading the ZipOS.
Did I mention working on the ZipOS? Indeed. realistically, further work on the SDIO/eMMC software really wants a proper OS of some type, so … this may be a future and upcoming task.
Status? This project isn’t likely to get any funding, but other projects are likely to require this fix.
-
As another potential project, an old friend is looking into building a “see-in-the-dark” capability–kind of like a “better” version of night-vision goggles. He’s currently arranging for funding, and after all of my video work I might finally find a customer for it. Yes, his work will require some secret sauce processing–but it’s all quite doable, and could easily fit nicely into this years upcoming work.
Status? If this moves forward, it will be funded.
-
I’d also like to continue my work on a Wishbone controlled SATA controller this year. I started working on this controller under the assumption that it would be required by my SONAR project, and so funded. Now it no longer looks like it will be funded under this vehicle. Still, the controller is now written, even though the verification work is far from complete. Specifically, I’ll need to work on my SATA (Verilog) Verification IP, until it’s sufficient enough to get me past knowing if I have the Xilinx GTX transceivers modeled correctly or not. Once I get that far, I can both start testing against actual hardware (on my desk), as well as against Verilator models.
Status? Funding has been applied for. Sadly, it’s not likely to be enough to pay for my hours, but perhaps I can have a junior engineer work on this. Still, whether or not the funding comes through remains to be determined.
-
Did I mention that the new debugging bus upgrades are on my list to be tested? Who knows, I may test their AXI counterparts first, or I may test the UDP version first, or … Only the Good Lord knows how this task will move forward.
Status? Not funded at all.
-
I am looking into getting some funding for a second version of an Ethernet based Memory controller. The SONAR project required a first version of this controller, and it smokes my serial port based debugging controller. A second version of this controller, designed for resource constrained FPGAs, designed for speed, designed for throughput from the ground up … could easily become a highly desired product.
We’ll see.
Status? Sounds fun, but not (yet) funded.
-
Finally, I have an outstanding task to test an open source memory controller, using an open source synthesis, and place and route tool, for both Artix-7 and Kintex-7 devices. I’ll let you know how that works out.
Since these are business predictions about the future, I am required by the Good Lord to add that these are subject to whether or not I live and the Lord wills. (See James 4:13-15 for an explanation.)
As always, let me know if you are interested in any of these projects, and especially let me know if you are interested in funding one or more of them. Either way, the upcoming year looks like it will be quite busy and it’s only January.
“My cup runneth over (Ps 23:5)”, and so I shall also pray that God grants you the many blessings He has given me.
Let every thing that hath breath praise the LORD. Praise ye the LORD. (Ps 150:6)