Open j-marjanovic opened 8 years ago
From what I found out so far, there is a problem in Generating class documentation...
phase. When the offending line is present an assertion fails when the documentation for top_module
is being generated:
Generating class documentation...
Generating docs for compound simple_submodule...
[debug]: virtual void LatexGenerator::startFile(const char*, const char*, const char*), name: enumsimple__submodule
Generating docs for compound top_module...
[debug]: virtual void LatexGenerator::startFile(const char*, const char*, const char*), name: enumtop__module
ASSERT: "m_numDecMembers!=-1" in memberlist.h (134)
Generating namespace index...
Generating graph info page...
Generating directory documentation...
Jan,
Thanks for all the documentation. A couple quick ideas:
Have you tried putting the doxygen comment for the signal after the signal name? Such as:
//% @brief A simple submodule
//% @date August 2016
module simple_submodule (
input clk //% clock input
);
endmodule
Does the same behavior occur if you have two signals? I have found that certain items act odd when acting upon or involving the last item in a port list (in VHDL at least). For example if you have a group:
entity Test is
port (
--! @name External Clock Inputs
--! @{
signal clk_50mhz : in std_logic; --! Main system clock
--! @}
--! @name UARTs and Generic IO
--! @{
signal uat_txd : out std_logic;
signal uar_rxd : in std_logic;
signal fpga_io : inout std_logic_vector(7 downto 0)
);
-- Doxygen needs this group to be after the semicolon, otherwise the last signal in the port list is not picked up.
--! @}
end entity Test;
Sorry, I know that example is in VHDL, but that's what I happen to be writing in at the moment...the same idea should apply to Verilog though, since they use pretty much the same parsing elements.
Unfortunately neither moving the doxygen comment after the signal name neither adding more signals does not resolve this issue.
I did however managed to generate LaTeX output by forcing INLINE_INHERITED_MEMB
configuration option to true in endMemberDeclarations
function:
void ClassDef::endMemberDeclarations(OutputList &ol)
{
//printf("%s: ClassDef::endMemberDeclarations()\n",name().data());
static bool inlineInheritedMembers = Config_getBool("INLINE_INHERITED_MEMB");
inlineInheritedMembers = true;
printf("[debug] %s, inlineInheritedMembers: %s\n", __PRETTY_FUNCTION__, inlineInheritedMembers ? "true" : "false");
if (!inlineInheritedMembers && countAdditionalInheritedMembers()>0)
...
Does it have any sense to have INLINE_INHERITED_MEMB
enabled for VHDL and (non-System) Verilog? I would assume that this option only makes sense for OO languages.
There is a bug which halts generation of LaTeX output when the project is composed of multiple Verilog modules.
Follows a minimal example which enables replication of this bug. When the line
input clk
insimple_submodule.v
is commented out, the LaTeX output is correctly generated and this is the contents of thelatex
directory:When the line
input clk
is present therefman.tex
is missing:Files
top_module.v
simple_submodule.v
verilog.cfg (Doxverilog configuration file)