X
What I want to achive is that there is no consistency in interpreting the synthezis code. It should be onesided what the synthezis shows.The alu design is comprised of arithmetic expressions and a mux4 (case construct). Synthesis decomposes it in elementary AND, OR, XOR and NOT operations. The choice of logic primitives is somehow arbitrary, XOR could be further decomposed. It's effectively impossible to read the original logic function from the decomposed gate level presentation or to easily check the correctness.
I wonder what you want to achieve? As mentioned before, synthesis is usually targeting to a specific hardware. It decides about availability of primitives, e.g. simple logic gates versus look-up-tables.
Yosys is a framework for Verilog RTL synthesis. It currently has extensive Verilog-2005 support and provides a basic set of synthesis algorithms for various application domains. Selected features and typical applications:
Process almost any synthesizable Verilog-2005 design
Converting Verilog to BLIF / EDIF/ BTOR / SMT-LIB / simple RTL Verilog/ etc.
Built-in formal methods for checking properties and equivalence
Mapping to ASIC standard cell libraries (in Liberty File Format)
Mapping to Xilinx 7-Series and Lattice iCE40 and ECP5 FPGAs
Foundation and/or front-end for custom flows
Are you refering to post #1? I believe it corresponds to DFF template, it's no latch. As stated, left and right side are functionally equivalent.Thats not an always_ff block, its an always block using i_c and i_r as enable signals. Hence you are creating transparent latches.
Oh so that's how it works.Based on this (from yosys website):
You aren't having Yosys convert the input code to a structural netlist in a specific technology, but are instead just converting to a simplified RTL Verilog netlist.
Hence you aren't going to see "gates" just simple RTL structures that pretty much match the original code with different names.
They are equivelant, but I am trying to understand how to recreate the whole circuit using logic gates. From always_ff I don't know but from always_comb I know because it has every gates + every connections. In other hand from always_ff I don't have anything but "if" statements, even the input i_e which is in always_comb was written in RTL as "if" statement which was something like multiplexer but the output was already o_y and there wasn't any "inside" connection between multiplexer and D flipflop, I don't know why RTL ignored it.Are you refering to post #1? I believe it corresponds to DFF template, it's no latch. As stated, left and right side are functionally equivalent.
You have NEVER had output that is a gate level netlist from Yosys. The "gate" file you mention from post #1 is an HDL file full of assign statements with Verilog statements representing logic operations on various signals. That is not a gate level representation of the design. A gate level RTL file will have no Verilog assigns, no always blocks, it will be made up entirely of instantiated modules from a technology library.Oh so that's how it works.
But sometimes I did get a specific "gates" to recreate a multiplexer like in my post #1. That was a great example of how yosys gave me a specific convertion from a code to => specific gates with specific connections. And I was really shocked when I saw the RTL/Yosys convertion of always_ff block, in which didn't give me a specific gates with specific connections like with always_comb RTL/Yosys but instead I got "if" statements that was something like multiplexer but weren't them + there were no connections of this multiplexer to other stuff. There was only connection from input, the output of the multiplexer connected to D flipflop was completelly ignored by the RTL, I don't know why, because there are two different gates multiplexer output to input D flipflop but there is no connection in the RTL.
@ads-eeYou have NEVER had output that is a gate level netlist from Yosys. The "gate" file you mention from post #1 is an HDL file full of assign statements with Verilog statements representing logic operations on various signals. That is not a gate level representation of the design. A gate level RTL file will have no Verilog assigns, no always blocks, it will be made up entirely of instantiated modules from a technology library.
@ads-eeYour first picture, right side, is not a gate level netlist, it is a Verilog HDL file that has assign statements that represent the gate level logic that could be used to translate into a gate level netlist.
# Utworzenie kopi modulu z inna nazwa
copy top_module top_module_rtl
# Ustawienie hierarchii projektu na nowy modul
hierarchy -top top_module_rtl
# Synteza logiczna
synth
# Mapowanie na bramki
abc -g AND,OR,XOR
# Optymalizacja po mapowaniu
opt_clean
# Zapis wyniku symulacji
write_verilog -noattr top_module_rtl.sv
# Wypisanie statystyki uzytych bramek
stat -tech cmos
I wonder what you want to achieve? As mentioned before, synthesis is usually targeting to a specific hardware. It decides about availability of primitives, e.g. simple logic gates versus look-up-tables.
I believe the question has been already discussed.
I expect that you have different tool settings for both codes. Picture 1 is simply translating System Verilog to plain Verilog. Picture 2 is translating to logic primitives (and, or, not). It's not actually synthesis because no hardware target is defined, the point has been extensively explained by ads-ee.
# Wczytanie pliku modelu
read_verilog -sv comparation.sv
# Utworzenie kopi modulu z inna nazwa
copy comparation comparation_rtl
# Ustawienie hierarchii projektu na nowy modul
hierarchy -top comparation_rtl
# Synteza logiczna
synth
# Mapowanie na bramki
abc -g AND,OR,XOR
# Optymalizacja po mapowaniu
opt_clean
# Zapis wyniku symulacji
write_verilog -noattr comparation_rtl.sv
# Wypisanie statystyki uzytych bramek
stat -tech cmos
EXAMPLE = comparation
rtl:
# Uruchomienie syntezy yosys
yosys -s run.ys | tee synth.log
sim: compile
# Wykonanie skompilowanego programu symulacji
./${EXAMPLE}.iveri.run
compile: clear
# Kompilacja modulow verilog do programu wykonywalnego
iverilog -g2005-sv \
*.sv \
-o ${EXAMPLE}.iveri.run \
| tee ${EXAMPLE}.iveri.log
waves:
# Uruchomienie przegladarki przebiegow GTKWave
gtkwave signals.vcd &
clear:
# Usuwanie wyniku kompilacji Icarus Verilog
if [ -f ${EXAMPLE}.iveri.run ] ; \
then rm ${EXAMPLE}.iveri.run ; fi
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?