It is possible to drive a signal from two modules.
However, it is not straightforward; the two modules have to cooperate - if one drives '1' and the other '0' at the same time, you have created a short circuit across the power supply, and you can potentially damage the device. In simulation, thankfully, the results are less dramatic!
Two ways to do so; and the reason not to use either of them inside an FPGA.
The first way is the traditional "wired AND" where there is a weak '1' permanently connected to the signal. Traditionally this was a resistor connected to +5V; in VHDL you might say Load_Divider <='H'; in the toplevel design. H and L are weak versions of '1' and '0'.
Now every driver can either pull it low, or turn off
if condition then
Load_Divider <='0';
else
Load_Divider <='Z';
end if;
('Z' means the high-Z or high impedance state, i.e. turn off the driver).
If ALL the modules drive Z, the output is 'H' (equal to '1').
The second way is called a tri-state bus. Here either module may drive 0, 1 or Z onto the bus. However, you the designer MUST make sure that when one module is driving '0' or '1', ALL the other modules are driving 'Z', to prevent the short circuit and damage mentioned above. That requires the cooperation of all the modules in some way:
if my_turn then
Load_Divider <= my_signal; -- 0 or 1
else
Load_Divider <='Z';
end if;
Either of these techniques are valid ways to communicate between separate FPGAs and other chips (memories, CPUs) on your board. But inside an FPGA there are no tri-state signals (only on its I/O pins) so if you use either technique above, the synthesis tools translate it into an equivalent signal without the tri-states.
For example the first technique (wired-AND) might translate to
Load_Divider_1 <= '0'; -- module 1
Load_Divider_2 <= '1'; -- module 2
Load_Divider <= Load_Divider_1 and Load_Divider_2;
where you can see that each signal has only one driver. So why not write that in the first place?
I think you really want an enumerated type. They will show up named in the simulation without the hassle of strings. You will need to check them out to figure out completely how to use them. Here are the basics:
-- declaration
type my_enumerated_type is ( good, bad, ugly);
signal rating, rating2 : my_enumerated_type;
constant ENCODED_TYPE_WIDTH : natural := 2;
-- helpers - use a function like this to convert between enumerated type and std_logic_vector
function encode ( rating : my_enumerated_type ) return std_logic_vector is
begin
return std_logic_vector(to_unsigned(my_enumerated_type'pos(rating), ENCODED_TYPE_WIDTH));
end encode;
function decode ( rating : std_logic_vector ) return my_enumerated_type is
begin
if unsigned(rating) < my_enumerated_type'length then
return my_enumerated_type'val(to_integer(unsigned(rating)));
else
return ugly;
-- TODO: throw an error instead? like so:
-- assert false report "rating out of bounds in conversion to my_enumerated_type" severity ERROR;
end if;
end decode;
-- conversion
output <= encode(rating);
rating2 <= decode(input);
These enums can be fun and powerful in VHDL. Enjoy!
Best Answer
There's a lot of digital design concepts you'll need to know to do this. I guess an outline would be:
Design a finite state machine that shifts out a single 10-bit serial frame (assuming 8-N-1 so one start bit, 8 data bits, 1 stop bit). The module accepts a clock (your baud rate) and some 8-bit data, as well as a "go" (start shifting data) input and "done" (all bits shifted) output indicator.
Design a baud rate generator module that produces your clock of say 9600 baud. This will probably be some kind of counter that you'll compare to a value to know when to toggle the baud clock output and reset the counter. Its input will be whatever clock sources are available on your FPGA board, probably something in the MHz range.
Design a FIFO module for storing data to be transmitted serially. The FIFO has data in, data out, a clock and reset, and status flags for full and empty.
Design another state machine that unloads data from the FIFO and transfers that single byte to the shifting-out module you previously developed. This way when the FIFO is full, it will send out new characters until empty. It will need to examine the FIFO empty flag to know when to start and stop.
Make a top-level module that loads some data into the FIFO. Maybe your development board has buttons or switches to accomplish this, you can load in a binary word at a time to the FIFO and then press a button to make the FSM start outputting data byte by byte.
At every step you need to write a test bench module and validate all aspects of the module you are testing. It's a critical part of development even though some people put it off until the end.
I'd read up on state machine design to get more information. You need to know about Mealy and Moore type state machines, how the control unit (FSM) controls a data path which operates on data, etc.