P stands for parser and not python which was the original idea and the reason for the name. Other suggested names are:

• Differential fuzzing of verilog simulators and synthesizers
  • Currently verilator, yosys, yosys-slang, icarus/iverilog, sv2v
• Creates complex verilog code from simple inital verilog modules called "snippets"
• Supports the fact that all simulators and synthesizers do not support the same features (cf comparison)
• Guarantees nevertheless that the created verilog code has an expected simulation chance of at least 75% (value that can be changed)

• improving the snippets
• adding more snippets
• adding more simulators and synthesizers

• Verilator
  • Incorrect handling of x in if blocks (if (x) else )
  • Fix static variable initialization in procedural blocks
  • Incorrect streaming_concatenation
  • Initialisation treated as continuous assignement
  • possible scheduling semantics violation or <= / = confusion
• Yosys
  • Incorrect handling of post-decrement operation in always_comb
  • read_verilog: inout parameters not copied out of tasks
  • Incorrect handling of x in if blocks (if (x) else )
  • Interface and modport support bug ?
  • Interface synthesis bug: Logic missing from main evaluation path ?
  • SystemVerilog unsized literal '1 incorrectly evaluated as 1-bit value instead of filling all bits
  • proc_prune / scheduling semantics bug
• yosys-slang
  • Incorrect handling of post-decrement operation in always_comb
  • Incorrect handling of wor
  • Initializers ignored
• Xcelium
  • Scheduling semantics violation
  • Power operator IEEE violation
• cxxrtl
  • cxxrtl: -O1 optimisation unbuffers wires too permissively
  • cxxrtl: timing bug in flip-flop evaluation

• known design defect
  • CXXRTL - indirect clock handling
• already found but never corrected
  • Yosys - multiple drivers on a variable in a module change values of input ports when using prep
• Convention on initialisation
  • Simulation error in always @* block ? This bug is interesting because icarus verilog is the only one of the free simulators to correctly handle this initialisation, but did not want to bother the other repos for the moment (if I am desperate for opening issues then so be it)
  • Is it a posedge if there is no transition from 0 to 1 but an intialisation value already at one, same for negedge (cxxrtl does not agree with the other simulators about this)
• Previously known
  • Internal module wires are not accessible using dot notation
  • The out-of-bounds part-select write behavior is inconsistent with IEEE
  • opt_muxtree broken optimisation
• Non exploitable and duplicate
  • yosys-slang: weird assignement to int error

make build-fuzzer

# Check a file for validity
./pfuzz check-file -file isolated/V3SchedTiming/mod_automatic_task.sv 

# Score snippets for better fuzzing (optional but recommended)
./scripts/score_snippets.sh

# Fuzz a file by injecting snippets into its modules
./pfuzz fuzz -n 160 -strategy smart -file testfiles/sv/ok/sequential_logic.sv -vv

For detailed information about the scoring system, see docs/SCORING.md.

For more details on how we decide how many modules to use and which one we pick to ensure that we have simulatable code then check the docs/INJECTING.md

• verilator
• cxxrtl (in yosys)
• icarus iverilog (>= 13.0)
• xcelium

• yosys
• sv2v (it is not a synthesizer but I tidied it there as it has a similar behaviour)
• vivado

The objective is to inject the snippet IN the original module not to write another module. It might be usefull to have a slice / list of all the lines of the original modules to do this, to be able to modfy lines / inject lines.

What we are interested are mostly the values of the variables that are modified IN the original module. If we find one which corresponds then we inject our module the line after the input variable has been identified. If they are many different candidates for this choose one at random.

If no variable in the module is interesting then we can see if any of the inputs or outputs of the module is of any interest, if possible select clock and reset rarely (using a random decision maker once all the interesting things have been identified)

then see if the output variables of the module we are injecting have the same type as any variable higher up in the code and if they do have the same type then assign the output to this variable. Do not rename many to the same one. If you don't find any then add it to the global outputs of the module