VHDL Error 10481 : no primary unit
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. ...


That includes comments.

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 &lt;= 0x7e) &amp;&amp; (x &gt;= 0x20)) || \
                                 ((x &gt;= 0xa0)) )

#define is_format_effector(x)   ((x &lt;= 0x0d) &amp;&amp; (x &gt;= 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.