Synthelectro

 
Back to basics...

Over a decade ago, I invested time in learning FPGAs. At the time, I thought it was a good idea—and I was probably right. Back then, microcontrollers didn’t have the performance they do today, and replacing all or part of legacy hardware could really only be done this way.

I had bought an Altera DE2-70 development board. FPGAs were all the rage, and although prices had become affordable, they started rising again. Even that wasn’t enough for Altera to survive on its own, as it was acquired by Intel a few years ago. Now, Intel itself isn’t in great shape either. The swan song of American tech?
I considered using FPGAs until 2019...

when I discovered GoWin FPGAs, which were much more affordable than Intel's. But then came 2020 and COVID—and boom, GoWin FPGA prices skyrocketed as well. Once again, I was stuck.

Then came Efinix chips. However, while I found GoWin’s development software somewhat clunky, Efinix’s tools are, in my opinion, a complete disaster—unintuitive, slow, and prone to crashing. Whether it's GoWin’s IDE or Efinix’s, neither is a good tool for development. But then again, that’s just my opinion, and I’m not a professional in the field.

My Big Mistake:

Whether using GoWin or Efinix software, I stubbornly tried to develop entirely within their ecosystems. And, true to my habit of persisting in error, I spent months wrestling with these tools. While I managed to get decent results with GoWin’s IDE—though with far more effort than I’d have liked—my attempts with Efinix’s IDE ended in outright failure.

My approach was simply foolish, and here’s why. The learning curve and overall usability of Quartus (Altera/Intel’s development software) had been, by far, the smoothest for me. I’d built solid experience with it and gained a strong command of VHDL. And here’s the kicker: VHDL works flawlessly with both GoWin and Efinix FPGAs. See where I’m going with this?

Yep—the much less stupid strategy would have been to develop on Altera’s platform first, validate the project there, and then port it to GoWin or Efinix. At worst, I’d only have needed minor adjustments for the target platform’s IP blocks.

Better Late Than Never

That’s exactly what I’ve decided to do: go back to an "easy" development environment to build my projects, then port them to my final platform of choice.

Luckily, Intel still provides the necessary software for the DE2-70 board—version 13SP1—so I’ve reinstalled it on my PC. And compared to my decade-old machine, my current computer should compile much faster, making this "old" board even more practical to use.

Tackling Video Signal Generation Again

This time, I’m revisiting video signal generation. While the DE2-70 has multiple types of RAM, it unfortunately lacks SRAM. And since I want my FPGA projects to be as portable as possible, I need to avoid platform-specific IP blocks—especially those handling dynamic RAM (DRAM).

Luck Is on My Side

Because over the past ten years, static RAM (SRAM) has improved significantly in capacity, price, and access time, interfacing SRAM with an FPGA is straightforward—aside from the high number of electrical connections, but that’s manageable.

Since I only need a modest video interface (limited pixel depth and color range), I can now get by with just a few SRAM chips while still achieving good resolution and enough colors.

And here's the small expansion board I plan to build to provide the DE2-70 with enough SRAM for video interface purposes. I've attempted similar expansions before, but the results weren't satisfactory in terms of access time. I believe I now understand why - this time, I'm taking a different approach. 

Here's what the physical implementation should look like:

The GPIO connectors obviously won't be implemented on this side since the board needs to be plugged into the DE2-70's connectors. I've also added a small connector to enable SRAM loading from an external processor board - I remember not including this feature last time and struggling immensely when trying to use a Z80 processor embedded in the FPGA itself.

That approach made real-time debugging impossible, preventing me from running code step-by-step to verify the VHDL video interface behavior. Essentially, I had two potentially buggy systems in the same FPGA code - how could I possibly determine which one was causing issues? This time, I'm not repeating that mistake.