Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

non responsive vhdl code in FPGA board

Status
Not open for further replies.

ananthan95

Junior Member level 3
Joined
Oct 19, 2017
Messages
31
Helped
0
Reputation
0
Reaction score
0
Trophy points
6
Activity points
289
I wrote a VHDL code for synchronous demodulation. I use vivado 2016.4. it works perfectly with a testbench in the software. but when I burnt the code into the FPGA board (Xilinx Artix-35T FPGA (xc7a35ticsg324-1L)) it doesnt work. any suggestions?
I used a software called terra term to read the output from the board. it is serial communication. nothing is wrong with the board. I tested the board with a different code and it worked. since it works fine in the simulation i couldnt find the error in my code.
the baud rate and pin mapping are double checked and verified. plus after implementing the design I ran a post-implementation timing simulation also. the result was positive. it said the user timing constraints are completely met.!! need help!
 

Hi,

Possible issues:

Not correct power supply
No valid clock source
Wrong schematic
Wrong code
Wrong expectation
Wrong test method
....

If you want us to validate your application you need to give all these informations.

Klaus
 
thank you for replying. but as I mentioned, it is working properly with a testbench. so I hope the code is ok. at least there is no error in the synthesis. and from the post-implementation time simulation, it gave a positive reply. it said the user timing constraints are met. and about the power supply, the board is connected to my lap! i mean if thats what you meant by incorrect power supply.
i didn't understand what u mean by wrong expectation and test method!
 

What do you mean by "working properly in a testbench"?
Have you tested it exhaustively?
Have you modelled all the busses?
Did it pass all your asserts?
Have you used appropriate coding styles?
Did the design meet timing?


In your case, the usual issue is poor coding. It is easy to write code that will "work" in a testbench and then fail synthesis because you didnt use correct coding styles. Why no post the code so we can help?
 

no synthesis error and timing constraints are met.
i ll upload the code below:
in this code, the period of CLK is 20ns and demod_clk is 1320ns
TX_DATA and RX_DATA are set of 24 data points which are 32767,40609,47995,54496,59735,63406,65296,63406,59735,54496,47995,40609,32767,24924,17538,11037,5798,2129,238,2129,5798,11037,
17538,24924
TX_DATA is the refference wave and RX_DATA is the incoming wave. i am using same numbers for both for the sake of verification.

Code:
entity scheme_demod is
    Port ( TX_DATA : in signed(16 downto 0);
           RX_DATA : in signed(16 downto 0);
           clk : in std_logic;
           demod_clk : in  STD_LOGIC;
	       --rx_data_compl : in std_logic;
		   tx_data_compl : in std_logic;
		   b_count : out std_logic;
		   start_data : out std_logic;
		   start_data1 : out STD_LOGIC;
		   DATA_OUT : out std_logic_vector (39 downto 0)
           );
end scheme_demod;

architecture Behavioral of scheme_demod is

type bus_type is array(0 to 23) of integer range 0 to 65535;
type bus_type1 is array (0 to 23) of signed (16 downto 0);
signal temp_rx : bus_type1 :=(others =>(others => '0'));
signal temp_tx : bus_type1 :=(others =>(others => '0'));
signal newrx : bus_type1 :=(others =>(others => '0'));
signal i,p : integer :=0;
signal moore_rx : signed (16 downto 0);
signal new_rx : signed (16 downto 0);
signal dif : signed (16 downto 0);

signal temp_sum : signed(39 downto 0) :="0000000000000000000000000000000000000000";
signal a,b : std_logic;
signal zc_clk,demod : std_logic;

signal test,test1 : std_logic := '1';

begin
start_data <= test;
start_data1 <= test1;
process(demod_clk,clk)
begin 
  if rising_edge(demod_clk) then
    test <= '1';
    temp_tx(i) <= TX_DATA - 32767;
    temp_rx(i) <= RX_DATA - 16384;
    moore_rx <= temp_rx(i);
    i <= i + 1;
  end if;  
  if rising_edge(clk) then
   dif <= 0 - moore_rx;
   if (0 - moore_rx > 0) then
        a <= '0';
    else a <= '1'; 
    end if;
    end if;
  if rising_edge (demod_clk) then  
    b <= a;
    end if;
 if i = 24 then i <= 0; end if; 
 end process;  
           
zc_clk <= (not b) and a;              
              
process(zc_clk,demod_clk)
variable k : integer:=0;
begin
if zc_clk' event and zc_clk = '1' then
 demod <= '1';
 k := 1; 
 end if;
  if falling_edge(demod_clk) then
    if demod = '1' then
--        b_count <= '0';
        newrx(k) <= moore_rx;
        new_rx <= newrx(k);
        temp_sum <= temp_sum + newrx(p) * temp_tx (p);
        p <= p + 1; 
        k := k+1;
   end if;      
   end if;
  if k = 24 then 
     k :=0;
  end if;   
  if rising_edge (demod_clk) then
      b_count <= '0';
    if  p = 24 then 
        b_count <= '1';
       DATA_OUT <= std_logic_vector(temp_sum);
       temp_sum <= "0000000000000000000000000000000000000000";
        p <= 0; 
     end if;
 end if;   
 end process;   
end Behavioral;
 

In your case, the usual issue is poor coding. It is easy to write code that will "work" in a testbench and then fail synthesis because you didnt use correct coding styles. Why no post the code so we can help?
No fun to be proved right...

timing constraints are met
About to impossible for various asynchronous constructs like
Code:
if i = 24 then i <= 0; end if;
outside an edge sensitive condition.

My general suggestion is to rewrite the code in a strictly synchronous manner, everything under the control of the 50 MHz clock, external events synchronized to it as far as necessary.
 
I would also suggest using 1 clock 1 process, instead of 2 clocks 1 process.

I guess synthesis tools have gotten better if it didn't barf on that coding style.
 

Too many clocks in a single process.

I would recommend define your process in a way that makes your code synthesizable.
A reference template has been added for your reference.
Code:
process (<clock>,<async_reset>,<en>)
begin  
   if <async_reset> = '0' then
      <statements>;
   elsif (<clock>'event and <clock> = '1') then
      if <en> = '0' then
         <statements>;
      else
         <statements>;
      end if;
   end if;
end process;
 

en in the above code is not required and should not be in the sensitivity list. It will actually cause the simulator to reenter the process when en changes wasting simulation kernel cycles.

clock'event and clock = '1' is depricated over using the function rising_edge(clock), this antiquated style (with actual simulation repercussions) is taught by way too many academic institutions. You would think a institution of higher learning would learn what is new (actually very old) in a language.
 

en in the above code is not required and should not be in the sensitivity list. It will actually cause the simulator to reenter the process when en changes wasting simulation kernel cycles.

I agree that for simulation it will impact but if we look in terms of synthesisability of the code that won't matter.

clock'event and clock = '1' is depricated over using the function rising_edge(clock), this antiquated style (with actual simulation repercussions) is taught by way too many academic institutions. You would think a institution of higher learning would learn what is new (actually very old) in a language.

Yes, then we can replace clock'event and clock = '1' with rising_edge(clock) in the template to ensure '0' to '1' transition.
 

I agree that for simulation it will impact but if we look in terms of synthesisability of the code that won't matter..

No, it wont (and in reality, unlikely to impact simulation much as Im sure the optimisation processes will catch this), but it comes down to good coding practice. Adding extra signals to sensitivity lists can be confusing for other users.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top