Implement AES50

[schulz-alexander]

😍 https://github.com/YetAnotherElectronicsChannel/AES50 😍

[xn--nding-jua]

For those who could support at this issue: at the moment the AES50-IP is synthesizing only using Lattice Diamond. Trying to synthesize in Xilinx ISE14.7 leads to endless loops that we cannot solve.

On the Lattice there are still timing issues and the 100MHz clock has negative slack-values. The timing is safe for up to 95MHz - we seem to be close to a working implementation, but still need more investigation here.

[schulz-alexander]

Progress was made: http://youtube.com/post/Ugkx-JesjZtM3DVfDe7EDrekHg5swMVTfiLb?si=fpo9Iepi_79YPsuA 🎉

[schulz-alexander]

We had the first audio transfer via AES50 these days! 🚀

[aspdigital]

For those who could support at this issue: at the moment the AES50-IP is synthesizing only using Lattice Diamond. Trying to synthesize in Xilinx ISE14.7 leads to endless loops that we cannot solve.

On the Lattice there are still timing issues and the 100MHz clock has negative slack-values. The timing is safe for up to 95MHz - we seem to be close to a working implementation, but still need more investigation here.

Hola -- Have you looked through the timing reports to see what paths are failing, and specifically, how many levels of logic are in those failing paths?

I started poking through your AES50 receiver code (https://github.com/OpenMixerProject/AES50/blob/main/AES50%20IP/SRC/aes50_rx.vhd). The main problem is in how the state machines are described. It is implemented as a nest of priority encoders. That is, priority encoders within priority encoders. The "P2_SubState" comparisons are really hurting you! These all result in very long logic paths.

Also in your state machine you have a bunch of counter comparisons, for example:

                                           elsif (rx_byte_counter >= 30 and rx_byte_counter <= 1437) then
						-- actual data coming
						if (tmp_rx_byte_counter = 0) then
							tmp_rx_word <= tmp_rx_word(31 downto 8) & eth_rx_data_i;
							tmp_rx_byte_counter <= 1;
							
						elsif (tmp_rx_byte_counter = 1) then
							tmp_rx_word <= tmp_rx_word (31 downto 16) & eth_rx_data_i & tmp_rx_word(7 downto 0);
							tmp_rx_byte_counter <= 2;
							
						elsif (tmp_rx_byte_counter = 2) then
							tmp_rx_word <= tmp_rx_word (31 downto 24) & eth_rx_data_i & tmp_rx_word(15 downto 0);
							tmp_rx_byte_counter <= 3;

and these add even more levels of logic. It is really no surprise that you cannot meet timing.

You really need to look at the logic the synthesis tool creates from your code. It will be enlightening.

Consider re-writing your state machines to use the standard case statement implementation. See here, for example. (That article links to a discussion about one-process vs two-process vs three-process state machines. Use only one-process machines. NEVER do two- or three-process machines. They are unmaintainable disasters.)

I also have concerns about your reset synchronization and how you actually reset the machines.

Why are you declaring your integer ranges as downto, such as signal rx_byte_counter : integer range 1500 downto 0;? That's just ... weird. (Also I would make them naturals, not integers, as the numbers are never negative.)

Remember: your coding style absolutely matters.

[xn--nding-jua]

Very good points to improve the current logic-base. My first tests with case-blocks instead of if-else looked good in the Simulation, but did not work. I guess I added other timing-issues here. I will try to migrate the logic to the suggested one-process-machines together with the other points soon.

[aspdigital]

Very good points to improve the current logic-base. My first tests with case-blocks instead of if-else looked good in the Simulation, but did not work. I guess I added other timing-issues here. I will try to migrate the logic to the suggested one-process-machines together with the other points soon.

I'm happy to help. Which repo is the main repo for the AES50 code? I can make a branch, clone it down, do some updates, and then do a PR if you are interested. I created a fork.

I will say up front that I no longer have an ISE install. I may end up implementing it in a Spartan 7 with Vivado. But since the code doesn't use any special device primitives, that shouldn't matter.

[aspdigital]

As an aside, the schematic implementation here makes the code non-portable, and now that ISE is dead and doesn't run on modern OSes, it's a problem to maintain.

[xn--nding-jua]

Hi,
I've forked the original repository of Markus. To keep things clear, please fork the AES50-repo directly from his original repository:
https://github.com/YetAnotherElectronicsChannel/AES50

Please rise Pull-Requests directly to this repository then, so that Markus can test it against his test-bench.

It's great that we can get something going here. Let's see where it leads.

[xn--nding-jua]

As an aside, the schematic implementation here makes the code non-portable, and now that ISE is dead and doesn't run on modern OSes, it's a problem to maintain.

I created a dual-FPGA-project. The general hardeware-independent VHDL-files are located in the first folder, the device-specific parts in the subfolder. The subfolder "lattice" contains the project for Lattice Diamond, the folder "xilinx" for Xilinx ISE14.7. I'm aware that it is "dead", but it is the only tool to create logic for the Spartan 3A that is inside this specific hardware.

Markus uses the Efinex Toolchain, so it should be absolutely fine when you use the Vivado-toolchain for your optimizations. I will lateron check if it is still working for ISE14.7...

If it helps you can use the "main_lattice.vhd" from the first folder to get started for Vivado. I used Intel Quartus Prime to create the main-file, so the names of the signals are kind of obfuscated, but it should run on Vivado.

But to test the logic for AES50 you do not need the whole project. It contains the full logic for the audio-routing-matrix, the UltraNet-sender, the PLLs etc.