A Free and Open Source Verilog-to-Bitstream Flow for iCE40 FPGAs

[HAL-42b]

[kc8apf]

Yosys can also do synthesis for xilinx 7 series parts now.  You still need a copy of vivado to generate a bitstream though.

Sent from my Nexus 5X using Tapatalk

[JoeN]

So this created a free toolset for very small FPGAs.  But every vendor of these sort of small devices (<100K LUTs) already has free tools.  What is the practical benefit?  If he opened up larger devices with non-free toolchains (e.g. Virtex, Stratix) then I could see the benefit.  Here, what is the benefit?

[HAL-42b]

So this created a free toolset for very small FPGAs.  But every vendor of these sort of small devices (<100K LUTs) already has free tools.  What is the practical benefit?  If he opened up larger devices with non-free toolchains (e.g. Virtex, Stratix) then I could see the benefit.  Here, what is the benefit?

Suppose that effort would require 100.000 man-hours. He is investing the initial 10k hours and is hoping others would contribute as well. If you want to see a benefit you should contribute.

[kc8apf]

He's also shown comparisons of yosys against other synthesis tools.  Yosys tends to do a better job at inferring memories and ends up with fewer resources used for the same design.

Sent from my Nexus 5X using Tapatalk

[artag]

A lot of people are uncomfortable about relying on closed-source tools, even if they're currently free. We remember when those manufacturers wanted thousands of $ for their tools and wouldn't talk to you unless you were a large corporation.

Those days seem to be fading but FPGAs haven't yet reached the state of processors where good open-source tools are available and only dinosaurs sell or loan closed-source. When the same state is reached in FPGA tools it will be much harder to keep people in a single ecosystem, competition will be stronger and prices will fall further. And we'll have the option of debugging or optimising the tools ourselves instead of being beholden to the vendors.

[hamster_nz]

Yosys tends to do a better job at inferring memories and ends up with fewer resources used for the same design.

I'll have to try out Yosys, however it is always possible do a better job at inferring memories with a tool you are intimately familiar with, so I wouldn't expect it to be any other way. 

A bit like how optimizing compilers work, unless you use the primitives that correspond with the physical on-chip resources (a bit like coding in assembler), the FPGA tools are looking for patterns in the intermediate representation and then mapping them to the on-chip resources.  If the RTL code you write happens to fall in line with the patterns that the tool looks for then you win. If it doesn't then you loose.

For example, say you want to infer a dual ported RAM with 18-bit wide interface on one port, and a 36-bit interface on the other side, with byte enables on both sides, and you also want WRITE_FIRST behavior, then if you don't follow the vendor's recommended pattern then all bets are off - it will work, but you will most likely chew through a few thousand LUTs for no reason. Likewise if you want to use all of the tricky resources inside the DSP blocks (like pre-adders and pipeline registers) then knowing the pattern is pretty important if you want to get good results.

So I'm not surprised if somebody says "I put my code through my tool and vendor Y tool's, and my tool is much better for metric Z".  If they say "I compiled the 10 largest projects off of OpenCores and it is better for most metrics" then I would be really impressed.

Apparently that is what the FPGA vendors do - they have a large database of real-world customer designs that they use to evaluate tool performance. One problem is that these 'benchmark' projects differ between vendors and academia, so everybody can get accurate but conflicting results for performance tests of their tools.

For Xilinx Vivado, a lot of the design patterns are detailed in http://www.xilinx.com/support/documentation/sw_manuals/xilinx2014_1/ug901-vivado-synthesis.pdf - DSP blocks, shift registers, RAMs and so on.  If you write RTL for Xilinx 7-series and haven't looked through it you don't know what you have been missing. It is great to not require IP for DSPs and memories and still get optimal results.

[kc8apf]

The whole point of optimizing compilers is that the user should not need to know the intimate details of the processor and code should be written for the user's understanding rather than the processor's.  Good optimizing compilers look not only for an exact pattern but also any equivalents.  This is why compilers are typically composed of multiple optimization passes including the same optimization at different points in the process.

I'm not terribly familiar with the current state of the art in synthesis.  I would hope that they do better than just looking for exact matches to the on-chip resources.  The output from both Vivado and yosys implies that they do quite a bit more.  If nothing else, yosys should provide some advancement in the area of optimization.  It provides an open platform for academic researchers to test out new algorithms and see the results on many designs.

[hamster_nz]

The whole point of optimizing compilers is that the user should not need to know the intimate details of the processor and code should be written for the user's understanding rather than the processor's.  Good optimizing compilers look not only for an exact pattern but also any equivalents.  This is why compilers are typically composed of multiple optimization passes including the same optimization at different points in the process.

I'm not terribly familiar with the current state of the art in synthesis.  I would hope that they do better than just looking for exact matches to the on-chip resources.  The output from both Vivado and yosys implies that they do quite a bit more.

They do a lot of optimization, but they can not make major make structural changes to the design, even if they are functionally equivalent (driven by the requirement that you formally verify that you actually get what you ask for). In a poorly constructed coding analogy, you are asking for the equivalent of coding a bubble sort and expect the compiler to detect this and replace it with a quick sort.

Take for example a really simple example.... a 10001 stage shift register, with a reset that sets all the elements to 0. The reset signal has a single stage of synchronization on it.

Version 1 - not architecture aware:
Artix-7 resources used : 1668 slices of 8150
Maximum clock rate  : approx 322 MHz.

Version 2, which is written in an architecture aware manor, but 100% functionally equivalent:
Resources used : 84 slices of 8150
Performance      : approx 354 MHz.

So in this case architecture aware coding saves 95% of the FPGA resources (and power), and runs about 10% faster. Would it also give better results on Altera Cyclone parts? I don't know - I've not read the device's architecture manual.

If nothing else, yosys should provide some advancement in the area of optimization.  It provides an open platform for academic researchers to test out new algorithms and see the results on many designs.

There is already that sort of work out there - eg the Verilog-to-Routing project ( https://vtr.readthedocs.org ). In general academic research tools are well behind the performance of commercial tools. From https://hes.elis.ugent.be/publications/analyzing-divide-between-fpga-academic-and-commercial-results :

In this work we compare the latest Xilinx commercial tools and products with these well-known academic tools to identify the gap in the major figures of merit. Our results show that there is a significant 2.2X gap in speed-performance for similar process technology

In case you are interested, Version 1 of the shift register:

Code: [Select]

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity connect_switch_to_led_a is
    Port ( clk    : in  STD_LOGIC;
           reset  : in  STD_LOGIC;
           switch : in  STD_LOGIC;
           led    : out STD_LOGIC);
end connect_switch_to_led_a;

architecture Behavioral of connect_switch_to_led_a is
   signal shift_reg  : std_logic_vector(10000 downto 0) := (others => '0');
   signal reset_last : std_logic := '0';
begin
   
process(clk)
    begin
        if rising_edge(clk) then
            if reset_last = '1' then
               led       <= '0';
               shift_reg <= (others => '0');   
            else
               led       <= shift_reg(shift_reg'high);
               shift_reg <= shift_reg(shift_reg'high-1 downto 0) & switch;
            end if;
            reset_last <= reset;
        end if;
    end process;
end Behavioral;


Version 2 of the shift register, which uses a counter to implement the reset, allowing the shift register to be packed into the LUTs:

Code: [Select]

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity connect_switch_to_led_b is
    Port ( clk    : in  STD_LOGIC;
           reset  : in  STD_LOGIC;
           switch : in  STD_LOGIC;
           led    : out STD_LOGIC);
end connect_switch_to_led_b;

architecture Behavioral of connect_switch_to_led_b is
   signal shift_reg : std_logic_vector(10000 downto 0) := (others => '0');
   signal count     : unsigned(13 downto 0) := (others => '0');
   signal reset_last : std_logic := '0';
begin
   
process(clk)
    begin
        if rising_edge(clk) then
            if reset_last = '1' then
               led       <= '0';
               count     <= to_unsigned(10000+1, 14);
            else
               if count > 0 then
                    led   <= '0';
                    count <= count-1;
               else
                    led  <= shift_reg(shift_reg'high);
               end if;
               shift_reg <= shift_reg(shift_reg'high-1 downto 0) & switch;
            end if;
            reset_last <= reset;
        end if;
    end process;
end Behavioral;


[Cerebus]

The whole point of optimizing compilers is that the user should not need to know the intimate details of the processor and code should be written for the user's understanding rather than the processor's.  Good optimizing compilers look not only for an exact pattern but also any equivalents.  This is why compilers are typically composed of multiple optimization passes including the same optimization at different points in the process.

I'm not terribly familiar with the current state of the art in synthesis.  I would hope that they do better than just looking for exact matches to the on-chip resources.  The output from both Vivado and yosys implies that they do quite a bit more.

They do a lot of optimization, but they can not make major make structural changes to the design, even if they are functionally equivalent (driven by the requirement that you formally verify that you actually get what you ask for). In a poorly constructed coding analogy, you are asking for the equivalent of coding a bubble sort and expect the compiler to detect this and replace it with a quick sort.

Not quite at the level of changing *algorithms* but you'd be surprised quite what transformations some compilers can and will make to code. Many, many years ago I was involved with the writing of a FORTRAN compiler that actually spotted parallelism in architecture unaware source code and spat out machine code to kick those parts off to a separate array processor.

In case you are interested, Version 1 of the shift register:

Code: [Select]

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;


Oh, and there you go and spoil it all by using VHDL which should be shunned, as should all the bastard children of ADA and the ironman project. 

What interests me most about Yosys and friends is access to a reasonably lightweight synthesis tool. Often the only meaningful test of whether code will synthesize cleanly is to try and synthesize it. Spinning up a vendor's tool and hacking in all the 'project' overhead with them is time consuming when you're at the early stage of fleshing out some code and all you want is an answer to the "will it synthesize or have I got it wrong" question.

[Someone]

What interests me most about Yosys and friends is access to a reasonably lightweight synthesis tool. Often the only meaningful test of whether code will synthesize cleanly is to try and synthesize it. Spinning up a vendor's tool and hacking in all the 'project' overhead with them is time consuming when you're at the early stage of fleshing out some code and all you want is an answer to the "will it synthesize or have I got it wrong" question.

Great answer, it is exciting to watch (and use) some of the modern interactive software environments, HDL has been progressing but is still a long way behind with its tools.