Skip to content

Bad VHDL code generated for primitive #124

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
polygonhell opened this issue Feb 7, 2016 · 3 comments
Closed

Bad VHDL code generated for primitive #124

polygonhell opened this issue Feb 7, 2016 · 3 comments

Comments

@polygonhell
Copy link

I just pulled 0.6.9 and it generates bad VHDL code for the dual ported RAM in this project.
https://github.com/polygonhell/J1LikeCPU
Simulation appears to be correct, but the interface to the primitive seems to generate a bunch of incorrectly typed intermediates

architecture structural of Main_dpRamFilezm_3 is
signal repANF_0 : signed(63 downto 0);
signal wild_1 : signed(63 downto 0);
signal bodyVar_2 : signed(63 downto 0);
signal repANF_3 : signed(63 downto 0);
signal wild_4 : signed(63 downto 0);
signal bodyVar_5 : signed(63 downto 0);
signal tmp_12 : product6;
begin

None of there values should be signed or bigger than 32 bits and this results in type errors in the VHDL as seen below. It's quite possible I'm missing something and the error is in my code, but this worked with 0.6.7.

Parsing VHDL file "Z:\git\Clash\examples\Alu\vhdl\Main\Main_dpRamFilezm_3.vhdl" into library work
Parsing entity <Main_dpRamFilezm_3>.
Parsing architecture of entity <main_dpramfilezm_3>.
ERROR:HDLCompiler:1728 - "Z:\git\Clash\examples\Alu\vhdl\Main\Main_dpRamFilezm_3.vhdl" Line 64: Type error near bodyvar_2 ; current type signed; expected type integer
ERROR:HDLCompiler:1728 - "Z:\git\Clash\examples\Alu\vhdl\Main\Main_dpRamFilezm_3.vhdl" Line 70: Type error near bodyvar_5 ; current type signed; expected type integer
ERROR:HDLCompiler:432 - "Z:\git\Clash\examples\Alu\vhdl\Main\Main_dpRamFilezm_3.vhdl" Line 80: Formal has no actual or default value.
INFO:HDLCompiler:1408 - "N:/P.20131013/rtf/vhdl/xst/src/numeric_std.vhd" Line 701. arg is declared here
INFO:HDLCompiler:1408 - "N:/P.20131013/rtf/vhdl/xst/src/numeric_std.vhd" Line 701. arg is declared here
ERROR:HDLCompiler:541 - "Z:\git\Clash\examples\Alu\vhdl\Main\Main_dpRamFilezm_3.vhdl" Line 80: Type integer is not an array type and cannot be indexed.
ERROR:HDLCompiler:432 - "Z:\git\Clash\examples\Alu\vhdl\Main\Main_dpRamFilezm_3.vhdl" Line 90: Formal has no actual or default value.
INFO:HDLCompiler:1408 - "N:/P.20131013/rtf/vhdl/xst/src/numeric_std.vhd" Line 701. arg is declared here
INFO:HDLCompiler:1408 - "N:/P.20131013/rtf/vhdl/xst/src/numeric_std.vhd" Line 701. arg is declared here
ERROR:HDLCompiler:541 - "Z:\git\Clash\examples\Alu\vhdl\Main\Main_dpRamFilezm_3.vhdl" Line 90: Type integer is not an array type and cannot be indexed.
ERROR:HDLCompiler:854 - "Z:\git\Clash\examples\Alu\vhdl\Main\Main_dpRamFilezm_3.vhdl" Line 20: Unit ignored due to previous errors.
VHDL file Z:\git\Clash\examples\Alu\vhdl\Main\Main_dpRamFilezm_3.vhdl ignored due to errors

@christiaanb
Copy link
Member

Ah, I see what's going on here. In version 0.6.8 I tried to actually fix the translation of Haskell's Int. Before version 0.6.8, I translated Haskell's Int to VHDL's integer, but this is wrong. The problem is, is that Int has a bit-width equal to the native machine word width, which on most machines is 64-bit these days. However, integer in VHDL is almost always 32-bit in most VHDL simulation and synthesis tools (even though the VHDL standard only specifies a minimum representation of 1-complements 32-bit). So there was a potential simulation/synthesis mismatch which I fixed in 0.6.8: Int is now translated to either signed 32 or signed 64 depending on the machine on which it is synthesized.

This means you'll have to update your BlackBox definition to work with CLaSH 0.6.8 and higher:

  addrA <= to_integer(~ARG[5])
  -- pragma translate_off
        mod ~LIT[2]
  -- pragma translate_on
        ;
  addrB <= to_integer(~ARG[8])
  -- pragma translate_off
        mod ~LIT[2]
  -- pragma translate_on
        ;

You can see find some more information about changing the representation for Int over here: #108

@polygonhell
Copy link
Author

OK, that makes sense.

It probably means though that Int should be avoided in library code, since it potentially behaves differently and certainly generates different VHDL on different machines.

Given how "young" Haskell is it's hard to fathom how the fell into the same trap of machine sized Int's as C.

Thanks again.

@christiaanb
Copy link
Member

I wish I could avoid Int, but some usefull Haskell type classes such as Enum and Bits use Int.

christiaanb pushed a commit that referenced this issue Sep 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants