New to verilog so this may be a dumb question? Are there any concerns I should consider when assigning an 'input' net to an 'output' net or is this not possible? For example:
module TOP( CLK1, CLK2 );
input CLK1;
output CLK2;
assign CLK2 = CLK1;
endmodule
Suppose CLK1 was a 50MHz clock, still valid?
Yes, it's valid. In fact, you are describing the simplest possible module: one that has just a wire connecting CLK1 with CLK2. Something like this:
TOP
+---------------+
| |
CLK1 | |
------->-..... |
| . |
| . |
CLK2 | . |
-------<-..... |
| |
| |
+---------------+
When you synthesize this, you only concern is to keep in mind the delay that the synthesizer has calculated for the propagation of a signal from CLK1 to CLK2. Of course, assuming that the synthesizer actually built this module. If this module is part of a bigger design, the synthesizer may (and surely will) absorb it during the optimization process.
Either it optimized it or not, the path from CLK1 to CLK2 has to exist, and that path will have a delay, which will depend on the location of macrocells / CLBs which signals CLK1 and CLK2 are in, which in turn will decide the physical path that the router builds (using more macrocells, CLBs, BUFG, or whatever resources your device has), the technology of the device you are synthesizing for, etc.
It is still valid you are effectively wiring them together.
If you can use verilog-2001 then you can define as:
module TOP(
input CLK1,
output CLK2
);
assign CLK2 = CLK1;
endmodule
Or defined as a reg type:
module TOP(
input CLK1,
output reg CLK2
);
always @* begin
CLK2 = CLK1;
end
endmodule
The code you've written contains no concept of time or delay. CLK1 could be 50GHz and it would still be valid.
If you are really asking about whether it can be synthesized to functionally correct hardware, that is another matter. If you were synthesizing to a modern FPGA then it is likely that it would work just fine. In fact, even a mediocre synthesizer would just optimize your module into a wire.
If you want to correctly simulate your Verilog then you need to worry about the timespec specifier in the testbench. This command sets the time resolution of the simulation so you want to make sure that the simulator will see the changes in the clock signals. A typical default resolution is 1ns so you would again be fine.
For simulation you might also make sure that any #delay values you add to the code are compatible with the desired clock frequency.
Verilog port directions are essentially advisory (unlike VHDL, where they're enforced). You can even write to an input port. You can do pretty much whatever you want, although a synthesiser will hopefully catch something that doesn't make sense. I don't have the LRM here, but look up port direction coercion.
