What does "no design unit detected in this file" mean?
Note this is the very same case which you've encountered here.

The answer given in 2008 also gives another solution: use an extended identifier, where most graphic characters are allowed.

VHDL No design units detected in file.


  davidgkoontz
  Visitor
  davidgkoontz
  Posts: 4
  Registered: ‎02-12-2008 0
  Re: VHDL No design units detected in file.
  ‎04-07-2008 05:12 PM  


If you wish to use a graphic_character in an entity simple name, it needs to be an extended identifier.   (IEEE-1076-1993 Standard Clause 13.3, Lexical elements, Identifiers)

 identifier ::=  basic_identifier | extended_identifier


A basic identifier consists only of letters, digits, and underlines.

 basic_identifier ::=
     letter  { [ underline ] letter_or_digit }

 letter_or_digit ::=  letter | digit

 letter ::=  upper_case_letter | lower_case_letter


Extended identifiers may contain any graphic character.

 extended_identifier ::=
    \ graphic_character { graphic_character } \


Suffice to say the apostrophe isn't part of a basic identifier, but is a graphic_character. 

So every occurance of "BARBAD'D" should be "\BARBAD'D\".  Likewise you could eliminated the apostrophe which is used for indicating attributes.
The cryptic nature of any error messages is due to the architecture of the lexer and parser.     This error arises from the definition of lexical elements, wherein an apostrophe is a delimiter used to separate prefix from the attribute designator in an attribute name (Clause 6.6, Attribute names).  The lexical analyzer sees the tokens:
BARBAD'D
IDENTIFIER_TOKEN          BARBAD
DELIM_APOSTROPHE       '
IDENTIFIER_TOKEN          D

Leaving the error-message-poor parser to muddle through.   It would be proper for a VHDL analyzer to stop when finding an error and complain, pointing to a line and character:


  ghdl -a barbad.vhdl
  barbad.vhdl:4:13: missing "is" after identifier
  barbad.vhdl:4:13: (found: ')
  ghdl: compilation error              (And it stopped)


In your case someone has made a software architecture decision to push error reporting to the calling software by returning information on design units analyzed.   Unfortunately it doesn't tell you what is wrong with your VHDL source code.  Note that the ghdl example doesn't provide a clear clue as to how to fix it either, other than fixing things before the "is".

The extended identifier works because the lexer sees it as one token:

\BARBAD'D\
IDENTIFIER_TOKEN           \BARBAD'D\

I can only recall one lexical and syntactical aware VHDL editor, and it failed in the marketplace, because early VHDL adopters tended to be sophisticated and thoroughly conversant with the LRM.  It was also a bit slow (1990 - 1991).     VHDL is also dependent on previously analyzed elements, in particular declarations, which implies a lot of complexity.

David


  (And I have copyrights over my own work of authorship).


The good news is I learn from your (representational) mistakes.  The bad news is Xilinx doesn't (albeit we can't tell the version of the tools from your images).

Also note the questioner on the Xilinx forum actually tried the solution.