(These are from IEEE Std 1076-2008). A port signal can be a record, too.
A resolution indication can appear wherever there is a driver. This is valid VHDL code:
library ieee;
use ieee.std_logic_1164.all;
package a_pkg is
function x_res (to_resolve: std_logic_vector) return std_ulogic;
end a_pkg;
package body a_pkg is
function x_res (to_resolve: std_logic_vector) return std_ulogic is
variable r: std_ulogic;
begin
r := 'Z';
for i in to_resolve'range loop
r := r or to_resolve(i);
end loop;
return r;
end function x_res;
end a_pkg;
library ieee;
use ieee.std_logic_1164.all;
use work.a_pkg.all;
entity foo is
port (
signal a: in std_logic;
signal b: in std_logic;
signal c: in std_logic;
signal p: out x_res std_logic
);
end entity;
architecture fum of foo is
begin
p <= a;
p <= b;
p <= c;
end architecture;
As you can see there's a resolution function declared and because it's not an array type or a record type there are no parentheses for an array element resolution function. A record can have a resolution function for each record element, while there's only one for an array type.
I've written schematic symbol generators several times over the years what your program does isn't a surprise, the geometry familiar.
That you discard the subtype indication (index range) limits the use to block diagrams (for documentation). There's at least one PDF based schematic package out there (Kicad). It'd likely require your own PDF code generation to make symbols for it.
A three signal port entity generated a 10KB PDF file, you're own PDF code generation could possibly reduce that should you be able to live with a standard embedded font. The issue here is eventually swamping a word processor by including embedded PDF files accumulating in size. Open Office/Libre Office can slow down with a relatively few large image files, It's the redraw times.
We used to do a lot of PostScript code for this kind of stuff back in the day, PDF can be on par and schematic symbols are about as hard as printing overlays on bank checks. You could do PostScript and rely on conversion to PDF.
.
I noticed your tool doesn't accept the optional keyword signal in an interface signal declaration on the port.
interface_signal_declaration ::= [ signal ] identifier_list : [ mode ] subtype_indication [ bus ] [ := static_expression ]
"Ports of any mode are also signals." As you can see the mode is optional and defaults to mode in.
Also a subtype indication can be more than a name and an index range:
subtype_indication ::= [ resolution_indication ] type_mark [ constraint ]
resolution_indication ::= resolution_function_name | ( element_resolution )
element_resolution ::= array_element_resolution | record_resolution
array_element_resolution ::= resolution_indication
record_resolution ::= record_element_resolution { , record_element_resolution }
record_element_resolution ::= record_element_simple_name resolution_indication
(These are from IEEE Std 1076-2008). A port signal can be a record, too.
A resolution indication can appear wherever there is a driver. This is valid VHDL code:
library ieee; use ieee.std_logic_1164.all;
package a_pkg is
function x_res (to_resolve: std_logic_vector) return std_ulogic;
end a_pkg;
package body a_pkg is
function x_res (to_resolve: std_logic_vector) return std_ulogic is variable r: std_ulogic; begin r := 'Z'; for i in to_resolve'range loop r := r or to_resolve(i); end loop; return r; end function x_res;
end a_pkg;
library ieee; use ieee.std_logic_1164.all; use work.a_pkg.all;
entity foo is port ( signal a: in std_logic; signal b: in std_logic; signal c: in std_logic; signal p: out x_res std_logic ); end entity;
architecture fum of foo is
begin p <= a; p <= b; p <= c; end architecture;
As you can see there's a resolution function declared and because it's not an array type or a record type there are no parentheses for an array element resolution function. A record can have a resolution function for each record element, while there's only one for an array type.
I've written schematic symbol generators several times over the years what your program does isn't a surprise, the geometry familiar.
That you discard the subtype indication (index range) limits the use to block diagrams (for documentation). There's at least one PDF based schematic package out there (Kicad). It'd likely require your own PDF code generation to make symbols for it.
A three signal port entity generated a 10KB PDF file, you're own PDF code generation could possibly reduce that should you be able to live with a standard embedded font. The issue here is eventually swamping a word processor by including embedded PDF files accumulating in size. Open Office/Libre Office can slow down with a relatively few large image files, It's the redraw times.
We used to do a lot of PostScript code for this kind of stuff back in the day, PDF can be on par and schematic symbols are about as hard as printing overlays on bank checks. You could do PostScript and rely on conversion to PDF. .