# VHDL Error 10481 : no primary unit

I'm designing a circuit using Simulink to VHDL generator to be burned into a FPGA. Simulink model works fine on Simulink, however, when I try to compile the VHDL code using Quartus II I get the following error:

Error (10481): VHDL Use Clause error at dsc_escalado.vhd: design library "mylib" does not contain primary unit "sen"

My top level code is dsc_escalado.vhd which uses library "mylib" generated by Simulink, which contains a file named sen.vhd where CORDIC algorithm is used to generate sine waves.

All files where generated by Simulink, I haven't modify any line of code. It works on Simulink, but wont compile on Quartus.

Update I have included all files in the project, However I get the same error. Here is the log generated by Quartus:

• Warning (20028): Parallel compilation is not licensed and has been disabled
• Info (12021): Found 0 design units, including 0 entities, in source file sen.vhd
• Info (12021): Found 0 design units, including 0 entities, in source file sen_120_not_ascii.vhd
• Info (12021): Found 0 design units, including 0 entities, in source file sen_240_not_ascii.vhd
• Info (12021): Found 2 design units, including 1 entities, in source file dsc_escalado.vhd
• Info (12022): Found design unit 1: DSC_escalado-rtl
• Info (12023): Found entity 1: DSC_escalado
• Error (10481): VHDL Use Clause error at DSC_escalado.vhd(90): design library "mylib" does not contain primary unit "sen"
• Error: Quartus II 64-Bit Analysis & Synthesis was unsuccessful. 1 error, 1 warning

Editor's Note: The source file comment line in question shows

while in the original the last three characters consisting of a space (x"20), a SUB (x"1A") and a LF (x"0A")in the original file. There isn't a way of demonstrating the illegal character without resorting to another tool due to the originally being iso8859-1 character mapping and the StackExchange network using UTF-8.)

-- -------------------------------------------------------------
--
-- File Name: hdl_prj\hdlsrc\DPWMfinal\sen.vhd
-- Created: 2018-06-27 14:40:51
--
-- Generated by MATLAB 9.0 and HDL Coder 3.8
--
-- -------------------------------------------------------------

-- -------------------------------------------------------------
--
-- Module: sen
-- Hierarchy Level: 1
--
-- -------------------------------------------------------------
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
USE IEEE.numeric_std.ALL;

LIBRARY WORK;
USE WORK.ALL;

ENTITY sen IS
PORT( clk                               :   IN    std_logic;
reset                             :   IN    std_logic;
enb                               :   IN    std_logic;
angle                             :   IN    std_logic_vector(31 DOWNTO 0);  -- sfix32_En28
sin                               :   OUT   std_logic_vector(31 DOWNTO 0)  -- sfix32_En30
);
END sen;


This is how Quartus II shows the illegal character.

• Can you post the code of the sen.vhd file? – DonFusili Jul 17 '18 at 14:45
• Yes, here is the sen.vhd file link – DanielG Jul 17 '18 at 14:51
• Does "mylib" actually exist? If you want the files to be placed in a non-default library this has to be specified in Quartus. I'm not sure how to do it exactly since I've mostly been working with Xilinx recently, but I'm guessing that's your problem. Maybe this would help? alteraforum.com/forum/showthread.php?t=57264 – ks0ze Jul 17 '18 at 17:30

There are VHDL tools that won't accept non-graphic character or non-format effector character values in comments.

The comment line:

-- Source Path: DSC_escalado/sen


has three trailing characters comprised of character values x"20, x"1A" and X"0a", respective space, sub and new line ASCII characters. Unfortunately x"1A" is neither a graphic character nor a format effector.

See IEEE Std 1075-1993 13.1 Character set

The only characters allowed in the text of a VHDL description are the graphic characters and format effectors. ...

While in -2002 or later (-2008 shown):

15.2 Character set

The only characters allowed in the text of a VHDL description (except within comments—see 15.9, and within text treated specially due to the effect of tool directives—see 15.11) are the graphic characters and format effectors. ...

The presence of non-graphic characters or non-format effector characters in comments is non-compliant with VHDL standards prior to revision -2002.

You'd expect QuartusII would be -1993 compliant and you'd expect an error message(s) (the architecture requires the primary unit be previously analyzed) as well visible status indicating the entity is not analyzed.

After substituting " ^Z" for the portion of the comment consisting of x"20, x"1A" byte values your design unit analyzes with a -1993 compliant VHDL tool. (My editors shows the tail of the comment that way, the character can be deleted as well).

Consider providing your primary design unit in your question unchanged with the comment intact allowing the readers to duplicate the problem. External links aren't guaranteed to persist for the lifetime of the question.

Simulink is doing something that would be harmless (while not being particularly useful) in later revisions of the VHDL standard.

VHDL -1993 and later use the iso8859-1 character set where graphics characters and format effectors can be shown as 8 bit character values belonging to ranges:

#define is_graphic_char(x)      (((x <= 0x7e) && (x >= 0x20)) || \
((x >= 0xa0)) )

#define is_format_effector(x)   ((x <= 0x0d) && (x >= 0x09))


(These are from an include file providing character classifiers similar to ctype.h in a VHDL analyzer implementation).

The problem was originally discovered by using ghdl:

ghdl -a sen.vhd
sen.vhd:14:34:error: invalid character, even in a comment
ghdl:error: compilation error


This provides a :line:character: location.

Fixing the problem either requires an editor that will display the iso8859-1 character set sufficiently to show where the illegal character is found, using an editor that tracks the pointer to line and character position, or a hex editor. (We could also brute force and replace anything close at hand.)

The 0A character is a LF end of line which normally wouldn't be removed.

• Thanks, that really worked!. I would have never guessed the error was a non-graphic character in a comment. – DanielG Jul 18 '18 at 17:38