Python to HDL: full Amaranth walkthrough to FPGA and ASIC GDS

We get from design to FPGA/ASIC in this complete walk-through of implementation using the Amaranth language in Python. Part 2 of project Neptune, where a digital logic hardware frequency discriminator is used as a guitar tuner.
The previous video actually describes the project and this one shows how I complete a small but non-trivial project in a single day thanks to the power of Python and Amaranth. The built-in simulation is used to validate modules and inspect traces with gtkwave and the whole thing spits out Verilog that is tested on a Lattice FPGA. Finally, I try and squeeze it into the space afforded by a tinytapeout slot, so it can be produced as a real integrated circuit at low cost.
Of interest
Source Code! github.com/psy...
Neptune Part 1: • Python design of a har...
I got introduced to Amaranth (nee nMigen) with Robert Baruch's excellent series on creating a 6800 CPU with it--it's was worth the time
• Building a 6800 CPU on...
Two versions were handred put on TinyTapeout03:
github.com/psy...
github.com/psy...
Amaranth docs: amaranth-lang....
TinyTapeout (for ASIC production): tinytapeout.com/

[@matferro]

I was looking to learn a bit of Amaranth and what a nice surprise when I noticed that the first link youtube recommended was a video by my former boss Pat. Amazing content as usual, thanks for sharing! : D

[@PsychogenicTechnologies]

Matheus! Well that warms my heart, thanks for the comment :-D I think Amaranth really lightens the load and makes creating hardware flexible and easy, hope you get use out of it and that my content helps quickstart the process. Hit me up in person with any questions!

[@AntonMueckl]

Hi Pat, this is really a great project! When I was still active as a musician, we tuned the guitar strings using the beating. These are caused by the frequency differences. The beats modulated in the range of one Hertz and less. As far as I know, these periods correspond to the difference frequency of the vibrations of the strings. Therefore, it could be that the tolerances you provide are too large. To be on the safe side, you could possibly tune the guitar with the frequency generator and do an audition to see whether a tuning with a frequency at the lower and upper limit of the spot-on range still sounds OK. Or you could try to feed real guitar signals to the FPGA....? Just to validate the concept before putting real money into an ASIC.

[@PsychogenicTechnologies]

Anton, thanks for this info! So you're talking about beat frequencies when two tones are mixed, right? I think this is how I can tell how matched they are (you know, when you hold fret 5 and pluck that string and the next)--you can hear the pulsing when they're close and it sounds horrid as they get further apart. Just not sure how to implement... sweeping the targets to find the beats might work (but be slow?) and the mixing would need to happen outside the circuit (unless I really didn't grok). In any case, you're right... I need to breadboard the A2D side and give it a shot. I'm pretty certain the current window is way too wide for the low strings. On the good news front, found that, once all the optimizing is done (there's stuffing where multi-port gates are used from the PDK), it only uses 500-some gates. So there may be room for a good deal of improvement. Oh, and final note: it's literally a hundred bucks to get onto tinytapeout, so that's not a big risk. The real problem is the turn-around time, waiting for the actual ICs, makes the cycle really slow, so better get it right. Thanks again for the feedback (musician pun!1) and I'm happy you liked it :)

[@rutuparnpawar1022]

I completely lost you when you started discussing Amaranth 😅. I know Python and Verilog well and using Python for HLS is wierd but definitely worth the time for very complex projects

[@PsychogenicTechnologies]

Oh, hm. That tells me I didn't do a great job--very possible, 'cause I just dove right in and spent more time on implementation details. My first introduction to this was with Robert Baruch's series (back when it was called nMigen), which I thought was really good kzbin.info/www/bejne/bma9dIermtCdfaM If you're up for it and curious, it's worth a watch

[@rutuparnpawar1022]

@@PsychogenicTechnologies I tried to run before I can walk. Thanks for the playlist reference

[@bennguyen1313]

Does the Eclipse IDE need any special Amaranth/python plugin? Are there certain rules when using Python to make synthesizable HDL.. like it must be Object-Oriented, can't import certain types of modules , etc? And how is timing closure done? Where can you analyze timing and specify maximum path times, etc? Also what parts of this flow can be used on non-lattice FPGAs? For example, can any of the tools like F4PGA/Symbiflow, Yosys , Padring/config , Coriolis (PnR), Tas Yagle (STA), KLayout, Magic (DRC/LVS) be leveraged towards a Microchip Polarfire, or Quicklogic, etc? For example, I would love to simulate open-source HDLs (ValentyUSB, VexRiscV) without using Questa/ModelSim. Creating test-benches is so time consuming, and the only other alternative I've seen people use is Altera's Max Plus II to draw waveforms and simulate that way, but wonder if there's a better way?!

[@PsychogenicTechnologies]

Hello Ben! There may be other options, but I use the PyDev plugin with eclipse for Python, and that's all you need (in addition to having the Amaranth libs installed somewhere in the pythonpath). The main requirements are that your modules derive from Elaboratable and return a Module on elaborate, which is all very OO. Otherwise, you can do things any way you like, use any python you wish. But to be clear, that doesn't mean you can magically import numpy into your hardware. The Python is used at the stage of netlist construction, i.e. when you're building the logic tree that represents your hardware design. Once that's done, python goes away. You spit out verilog, or RTLIL and then move down the chain of tools. A number of FGPAs are already supported (see github.com/amaranth-lang/amaranth-boards/tree/main/amaranth_boards ) and adding support isn't all that hard. However, if you want a flow that goes from Python straight to burning the FPGA, it will have to be something the community's reverse engineered, because FPGA companies are really anal about that and can't see the benefits of giving access. Anyway, if you want to use STA or other such tools, the normal flow would be to go from your design generator in Amaranth/Python -> to your design in Verilog -> hardening with Yosys/OpenLane/OpenRoad or whatever is appropriate, which is also where you'd be doing all the clock tree, timing, etc stuff. So, if you've done this work before from an HDL, you can just think of Amaranth as one step before, a way to generate that HDL. Nothing afterwards needs to change.