ghdl / ghdl-yosys-plugin

VHDL synthesis (based on ghdl)
GNU General Public License v3.0
296 stars 32 forks source link

[WIP] Implement a VHDL backend #122

Open rlee287 opened 4 years ago

rlee287 commented 4 years ago

This will be a VHDL backend from #112, and I will be using this PR to track what has been finished and what still needs work.

On extended identifiers: #112 suggests always using these, but user-provided names (e.g. port names) should be preserved when possible, and IEEE-1076-2008 15.4.3 states that "Moreover, every extended identifier is distinct from any basic identifier."

Functions that need to be changed to output VHDL syntax (note that this checklist only deals with syntax generation in that function and not any other things that may need adjustment):

rlee287 commented 4 years ago

Documentation of major design decisions I am making (feel free to contest these in followup comments):

rlee287 commented 4 years ago

Technical debt to cleanup before finishing:

Xiretza commented 4 years ago

FYI, VlogHammer might come in useful for testing this. The patch below is an attempt at adapting it for ghdl (to be run with make YOSYS_MODE=ghdl GHDL_MODULE=/path/to/ghdl.so syn_yosys), but there's not enough functionality to properly test it yet:

diff --git a/scripts/syn_yosys.sh b/scripts/syn_yosys.sh
index cb2244f..5276c8d 100644
--- a/scripts/syn_yosys.sh
+++ b/scripts/syn_yosys.sh
@@ -55,6 +55,9 @@ case "$YOSYS_MODE" in
        7|minimal)
                yosys -q -l synth.log -b 'verilog -noattr' -o synth.v \
                      -p 'hierarchy; proc' ../../rtl/$job.v ;;
+       8|ghdl)
+               yosys -m "${GHDL_MODULE:-ghdl}" -q -l synth.log -b 'verilog -noattr' -o synth.v \
+                     -p 'write_vhdl -noattr synth.vhd; design -reset; ghdl synth.vhd -e' ../../rtl/$job.v ;;
        *)
                echo "Unsupported mode: $YOSYS_MODE" >&2
                exit 1 ;;
rlee287 commented 4 years ago

It turns out that more of the id related functions need updating, as the autogenerated ids need to be changed to be valid identifiers (without underscores at the beginning or end). I will need to decide if I want to imitate ghdl --synth and also append _o or _q to internal signal names. (The checklist at the top will be updated momentarily.)

rlee287 commented 3 years ago

Finally getting around to resuming development and copying over the Mem refactoring, but the requirement for placing signal declarations at the beginning for VHDL means that the actual memory dumping is going to be more complicated.

JimLewis commented 3 years ago

Not quite. "=" is a string operation. "?=" is a hardware operation. "=" like character matches like character "?=" 0 matches L, 1 matches H, '-' matches anything. U results in U (except with -), everything else is X.
For more see the LRM.

JimLewis commented 3 years ago

Had a long discussion with a Verilog person about what value to assign in the default assignment within a case statement. It actually helped me understand why I should keep doing what I had always been doing. Which is when assigning to a signal, use 'X" as don't care. For example:

   case slv2 is 
     when "00" => ...
     when "01" => ...
     when "10" => ...
     when "11" => ...
     when others => Y <= "XXXX" ;
  end case ; 

If instead, Y were assigned to "----", then the expression, Y ?= "0000" would be true when the don't care happened. OTOH, interesting things would happen anyway if the condition "11" were not covered and it actually happened in the real hardware.

kammoh commented 2 years ago

Hi! Great initiative @rlee287! I saw there was no activity on this PR so I went a little further with it:

https://github.com/kammoh/ghdl-yosys-plugin/tree/vhdl_backend

I'm now able to run post-synthesis simulation using Yosys synth/synth_xilinx netlist synthesis and GHDL simulation. I've only tested a couple of rather small designs and it passes verification. I merged in master and made sure works with the latest yosys.

Please let me know your thoughts about those changes.

Would you still be interested in working on this feature @rlee287? I'd love to provide any help, as this is a feature I direly need at the moment. Otherwise please let me know if I should make a new PR.

Thank you!

rlee287 commented 2 years ago

Unfortunately, I haven't had time to continue working on this, so I appreciate you stepping up to continue where I left off. I hope you'll be able to see this through and merely ask that you continue documenting design choices and similar things (e.g. the last commit of Yosys that this part of the plugin was based on, in order to track whether it accounts for updates to any of the Yosys cell libs, etc.), similar to how I documented such things when I was working on this earlier.

If you do complete this and get a PR of yours merged with this functionality, I'll be happy to close this PR. Thanks again for picking up where I left off.