zermelo
Junior Member level 3
- Joined
- May 24, 2013
- Messages
- 25
- Helped
- 0
- Reputation
- 0
- Reaction score
- 0
- Trophy points
- 1,281
- Activity points
- 1,543
Hi all,
I am working with a transceiver board to implement a Hamming windowed Chirp (linear frequency modulation) transmitter into a Cyclone II. Due to economic issues, instead of loading values into a DAC, we are using a dual MOSFET driven by complementary TTL signals to control the transformer stage (2 KVolts) that will drive a transducer.
I have done the VHDL coding , defined some I/O constraints and done the behavioral simulation. Everything works as specified in behavioral simulation : the two TTL have the correct timing, and are enabled a time which is proportional to the product of the window samples and the instantaneous frequency.
Long story short:
When I configure the board, and plug a TX trigger, both TTL signals remain stuck at zero. The Quartus Technology viewer says that the logic to generate them is in place.
Here is the VHDL related with the TTL signal generation:
What I am afraid is that the logic for the comparison of the timer and the threshold value is implemented incorrectly. Those signals , s_ttl_cnt_n, s_ttl_cnt_p, s_ttl_high are defined as:
The s_ttl_high signal is generated as:
And s_ttl_high_sfx is a signed fixed defined as:
I have done some debugging (unluckily I do not have direct JTAG acces to the FPGA, therefore I have no way to use signal tap for this) using testpoints, and observed that the zero crossing signals (s_tx_cr_p_zc and s_tx_cr_n_zc) and s_ttl_data_hi_rdy are generated generated correctly.
Do you see any problem in the conversion of P_TTL_HIGH_CONV? Could the comparison be failing due to that or any other reason? Any advice to debug this?
In the meantime I am trying to get a Cyclone development board so I can have acces to more signals and use Signal Tap.
Thanks in advance
Jose
I am working with a transceiver board to implement a Hamming windowed Chirp (linear frequency modulation) transmitter into a Cyclone II. Due to economic issues, instead of loading values into a DAC, we are using a dual MOSFET driven by complementary TTL signals to control the transformer stage (2 KVolts) that will drive a transducer.
I have done the VHDL coding , defined some I/O constraints and done the behavioral simulation. Everything works as specified in behavioral simulation : the two TTL have the correct timing, and are enabled a time which is proportional to the product of the window samples and the instantaneous frequency.
Long story short:
When I configure the board, and plug a TX trigger, both TTL signals remain stuck at zero. The Quartus Technology viewer says that the logic to generate them is in place.
Here is the VHDL related with the TTL signal generation:
Code:
-- P_TTL_GEN: TTL signals are gated with the result of the time interpolated unit
-- and the Hamming window readings.
P_TTL_GEN: process(i_clk)
begin
if (i_clk'event and i_clk = '1') then
if (i_rst = '1') then
s_ttl_cnt_p <= (others => '0');
s_ttl_cnt_n <= (others => '0');
s_tx_n <= '1';
s_tx_p <= '0';
s_p_cnt_set <= '0';
s_n_cnt_set <= '0';
else
-- tx_p generation
if (s_tx_cr_p_zc = '1') then -- Chirp sine rising edge
s_ttl_cnt_p <= (others => '0');
s_tx_p <= '0';
s_p_cnt_set <= '1';
elsif (s_p_cnt_set = '1') then
if (s_ttl_cnt_p < s_ttl_high) then
s_ttl_cnt_p <= s_ttl_cnt_p + 1;
s_tx_p <= '1';
else
s_p_cnt_set <= '0';
s_tx_p <= '0';
end if;
end if;
-- tx_n generation
if (s_tx_cr_n_zc = '1') then -- Chirp sine falling edge
s_ttl_cnt_n <= (others => '0');
s_tx_n <= '0';
s_n_cnt_set <= '1';
elsif (s_n_cnt_set = '1') then
if (s_ttl_cnt_n < s_ttl_high) then
s_ttl_cnt_n <= s_ttl_cnt_n + 1;
s_tx_n <= '1';
else
s_n_cnt_set <= '0';
s_tx_n <= '0';
end if;
end if;
end if;
end if;
end process P_TTL_GEN;
What I am afraid is that the logic for the comparison of the timer and the threshold value is implemented incorrectly. Those signals , s_ttl_cnt_n, s_ttl_cnt_p, s_ttl_high are defined as:
Code:
signal s_ttl_high : unsigned(14 downto 0);
signal s_ttl_cnt_n : unsigned(s_ttl_high'range);
signal s_ttl_cnt_p : unsigned(s_ttl_high'range);
The s_ttl_high signal is generated as:
Code:
-- P_TTL_HIGH: This product determines the % of TTL pulses within one
-- period or the time that the PWM is high within one period.
P_TTL_HIGH: process(i_clk)
begin
if (i_clk'event and i_clk = '1') then
if (i_rst = '1') then
s_ttl_high_sfx <= (others => '0');
elsif (s_ttl_data_hi_rdy = '1') then
s_ttl_high_sfx <= s_wdw_high_sfx*s_ttl_tunit_high_sfx ;
end if;
end if;
end process P_TTL_HIGH;
P_TTL_HIGH_CONV: PROCESS(i_clk)
begin
if (i_clk'event and i_clk = '1') then
s_ttl_high <= to_unsigned(to_integer(s_ttl_high_sfx(s_ttl_high_sfx'left downto 0)),s_ttl_high'length);
end if;
end process P_TTL_HIGH_CONV;
And s_ttl_high_sfx is a signed fixed defined as:
Code:
signal s_ttl_high_sfx : sfixed(13 downto -2);
I have done some debugging (unluckily I do not have direct JTAG acces to the FPGA, therefore I have no way to use signal tap for this) using testpoints, and observed that the zero crossing signals (s_tx_cr_p_zc and s_tx_cr_n_zc) and s_ttl_data_hi_rdy are generated generated correctly.
Do you see any problem in the conversion of P_TTL_HIGH_CONV? Could the comparison be failing due to that or any other reason? Any advice to debug this?
In the meantime I am trying to get a Cyclone development board so I can have acces to more signals and use Signal Tap.
Thanks in advance
Jose