我正在通过一些旧的考试来准备考试。其中一个问题是：
在图中编写实现同步 FSM 的可综合行为 VHDL 代码... FSM 有一个输入，称为请求，它是具有值 (r1, r2, r3) 的枚举类型...
这让我想写这段代码：
entity fsm is
port ( clk : in std_logic;
request : in my_enum_type
);
end fsm;
某处有一个：
type my_enum_type is (r1, r2, r3);
某处（我在端口声明之前和架构声明之后都尝试过）。
但我似乎无法让它发挥作用。我可以将自定义类型作为输入或输出吗？
Yes you can, and I regard it as best practice - it means least work, best understanding, easiest maintenance, and cleanest design.
The trick is to declare the types common to your whole design in a package (I usually call it "Common" :-) and add use work.Common.all before the entity declaration AND in every customer of that entity. More specialised components can have appropriate names, of course!
For example:
package Common is -- untested...
type my_enum_type is (r1, r2, r3);
-- (optional) useful tools
function to_slv (e : my_enum_type) return std_logic_vector;
function to_enum (s : std_logic_vector(my_enum'length downto 0))
return my_enum_type;
end Common;
package body Common is
-- subprogram bodies here
end Common;
Now when you add a value to the enumeration, you ONLY modify "Common" and rebuild the design, while those who follow conventional guidelines are still trying to identify every port and signal where they have to increase the range of their "std_logic_vector" by 1.
Works really well for bus interfaces too, where a record in each direction hides all the individual bus and handshaking signals.
You WILL have to fight brain-dead tools like Xilinx "automatic testbench generator" which will helpfully translate ALL your port types - integer or boolean as well as custom - into std_logic(_vector) and then fail to compile. Just translate them back again.
You can still make a case that at the very top level, all the external FPGA pins should still be std_logic based. And if you ever need to simulate a post-synthesis version of your design, then you will either need to live with std_logic_vector ports, or add a simple wrapper to convert from one form to the other.