I made some changes to your code. The changes will be explained below.
entity dafsm is
x: in std_logic_vector (31 downto 0) := x"0000002A";
y: out std_logic_vector (31 downto 0)
architecture fpga of dafsm is
function to_string(inp: std_logic_vector) return string is
variable image_str: string (1 to inp'length);
alias input_str: std_logic_vector (1 to inp'length) is inp;
for i in input_str'range loop
image_str(i) := character'VALUE(std_ulogic'IMAGE(input_str(i)));
-- report "image_str = " & image_str;
signal r,s : real range 0.0 to 15.0;
r <= to_real(to_float(x));
s <= r * 0.5;
y <= to_slv(to_float(s));
report "y = " & to_string(to_slv(to_float(s)));
end architecture fpga;
This analyzed, elaborated and simulated.
- I modified the context clause, including a library reference for ieee_proposed, removed anything not needed.
- `x` and `y` were too short to use. I increased them to length 32 as a first attempt. I don't recall the minimum length off the top of my head, you can find that out by reading the documentation on the above web site or reading the package source code. It can be shorter, I knew 32 would work.
- I added a default value for `x` (the hex equivalent of 42 decimal). This is so I could your design without writing a testbench.
- I added a function to_string[std_logic_vector return string], this was done on ghdl, which isn't IEEE Std 1076-2008 compliant, and the function wasn't available. I wrote the function to comply with the standard, section 5.7 String representations (I had this lying around). It's only needed here to verify that the input 42 times 0.5 is 21.
- The package float_pkg is obtained from the VHDL-2008 Support Library web page, a careful reading provides a download link for the -1993 compatible version.
- There are modifications to your concurrent signal assignments. There are no real to/from std_logic_vector conversion routines. everything is piped through the new type float.
- I added a monitor to tell us what the result is.
You carefully scrubbed any vendor identifying information from your error messages and I don't have their implementations any way, I used ghdl.
I first compiled the sources in a directory named ieee_proposed to create a library ieee_proposed:
ghdl -a --work=IEEE_PROPOSED standard_additions_c.vhdl
ghdl -a --work=IEEE_PROPOSED standard_textio_additions_c.vhdl
ghdl -a --work=IEEE_PROPOSED std_logic_1164_additions.vhdl
ghdl -a --work=IEEE_PROPOSED numeric_std_additions.vhdl
ghdl -a --work=IEEE_PROPOSED numeric_std_unsigned_c.vhdl
ghdl -a --work=IEEE_PROPOSED fixed_float_types_c.vhdl
ghdl -a --work=IEEE_PROPOSED fixed_pkg_c.vhdl
ghdl -a --work=IEEE_PROPOSED float_pkg_c.vhdl
We don't need all these to demonstrate your code, but there your are.
Then analyzed, elaborated and simulated your code:
ghdl -a -P./ieee_proposed dafsm.vhdl
ghdl -e -P./ieee_proposed dafsm
ghdl -r dafsm
dafsm.vhdl:33:9:@0ms:(report note): y = 00000000000000000000000000000000
dafsm.vhdl:33:9:@0ms:(report note): y = 00000000000000000000000000010101
There are two outputs because there is an initialization event on
s is assigned
r * 0.5. Note I made the monitor process sensitive to
s because y is an output and can't appear in a process sensitivity list. I recreated the the value
y will have assigned.
The second is the result, 15 in hex is 21 decimal.
The -P./ieee_proposed tells ghdl to look in the current directory for a subdirectory library ieee_proposed (the name of the directory is the same as the library). I could have placed it in ghdl's library search path, it seemed unnecessary for this demonstration.
Other tools usage may vary.
David Bishop assures us this should be synthesis eligible. I haven't tried myself.
Please avail yourself of the documentation on the above web page.