libraryIEEE;useIEEE.std_logic_1164.all;--use work.std_arith.all;useIEEE.numeric_std.all;entity adc1_sim isport(
adc1_rbc:instd_logic;
data_mux1:innatural;
adc1_data:outstd_logic;
adc1_busy:outstd_logic;
adc1_dclk:outstd_logic);end adc1_sim;architecture Behaviour72 of adc1_sim issignal rbc, busy, ds, clk_d:std_logic;signal digital :std_logic_vector(15downto0):=X"0000";signal V_max, data_An, res :naturalrange0to65535;signal i, j, AD :naturalrange0to65535;begin
clk_d<='0';--I/P port to Signal map
rbc<=adc1_rbc;
data_An<= data_mux1;--O/P port to Signal map
adc1_busy<=busy;
A1:process(rbc)beginif(rbc='0' and rbc'event)then
res<=V_max/65535;
AD<=data_AN/res;
digital<=std_logic_vector(to_unsigned(AD,16));
busy<='1';for i in0to15loopexitwhen i =16;
j<=15-i;
ds<=digital(j)after 78ns;
adc1_data<=ds;
clk_d<='1'after 78ns;
adc1_dclk<=clk_d;
clk_d<='0' after 156ns;
adc1_dclk<=clk_d;endloop;endif;
busy<='1';endprocess;end Behaviour72;
signal V_max, data_An, res : natural range 0 to 65535; -- V_max <= 65535
-- V_max never assigned, takes default value of "natural", which is 0
...
res<=V_max/65535; -- res is 0 unless V_max is 65535.
AD<=data_AN/res; -- divide by 0
-- simulator error shows wrong line number?
That process doesn't do what you think it does. you probably want to use variables.
Code:
clk_d<='0'; -- adds second driver to clk_d
A1: process(rbc)
begin
if(rbc='0' and rbc'event)then
res<=V_max/65535; -- occurs after 1st cycle
AD<=data_AN/res; -- +1 cycle delay (2nd)
digital<= std_logic_vector(to_unsigned(AD,16)); -- +1 cycle delay (3rd)
busy<='1'; -- occurs after 1st cycle
for i in 0 to 15 loop
exit when i = 16 ; -- how do you get here?
j<=15-i; -- occurs after 1st cycle and sub
ds<=digital(j) after 78ns;
adc1_data<=ds;
clk_d<='1'after 78ns;
adc1_dclk<=clk_d;
clk_d<='0' after 156ns; -- reassignment*
adc1_dclk<=clk_d; -- reassignment*
end loop;
end if;
busy<='1'; -- sets busy to '1' and holds it there after 1st cycle**
end process;
* I've never actually used assignement overrides that had delays. I can't see an interpretation that would be useful.
** if you change this to '0', then it will hold it at '0'. The flaw isn't that you set it to '1' in both assignments, it is that you used a non-blocking assignment and expected blocking behavior.
@sharath: You can have multiple nonblocking assignments to the same signal within the same process. The semantics are that the last reached assignment has priority. This can be abused, but also has some nice uses. For example, you can place the reset logic at the bottom of the process. This allows resets to be used on some signals, but not all. This is much more common in FPGA designs. Recall that placing the reset section at the top results in latches if a signal is not reset as the logic becomes an async load. It is also very common to have a "defaults" section at the top of a process -- especially for combinatorial processes. These two cases are nice because they use this feature in a very well defined manner in very well defined parts of the process. You can use assignment overrides within the core of the process, but it becomes more difficult to determine the logic for a signal because you have the unnatural reverse-order priority of the overrides mixed in with the normal priority order for if/else statements. I prefer to avoid overriding except for the default and reset special cases. In some very specific cases it can make the logic easier to understand.
Assuming you're talking about a synchronous process with async reset, it actually stays a register, with the async reset as the clock enable on the register. (at least with quartus - but this makes sense as the logic would never get loaded with a value other than on a clock edge).