how to write a tesbench with reading input from text and writting output in text?

ads-ee · Sep 17, 2015

Your UUT code isn't synthesizable, a for loop can't be used to do division doesn't matter is it's VHDL or Verilog. To generate hardware the loop is unrolled, which means only the assignment when i and j are both 63 is done, hence it probably never changes. In the previous for loop in your tb I failed to account for your time control wait statement inside the loop, which results in software like behavior.

Now that I've looked at your UUT code, I think you need to rewrite a lot of it to make it synthesizable. For loops are used for replicating logic not for sequencing through an array. As you arent treating the array a memory the tools will try and implement then as FFs, as each array requires 32K+ FFs the dessign is not likely to fit.

K-J · Sep 17, 2015

ads-ee said:
Now that I've looked at your UUT code, I think you need to rewrite a lot of it to make it synthesizable.

Maybe in the end, the OP wants the UUT to be synthesized, but this thread is only about simulating what he has, not synthesis.

Kevin

milan.km · Sep 17, 2015

yes,I just want to simulate.do u think iys because of for loop ,the answer is wrong?

- - - Updated - - -

ads-ee said:
Your UUT code isn't synthesizable, a for loop can't be used to do division doesn't matter is it's VHDL or Verilog. To generate hardware the loop is unrolled, which means on the assignment when i and j are both 63 is done, hence it probably never changes. In the previous for loop in you tb I failed to account for your time control wait statement inside the loop, which results in software like behavior.

Now that I've looked at your UUT code, I think you need to rewrite a lot of it to make it synthesizable. For loops are used for replicating logic not for sequencing through an array. As you arent treating the array a memory the tools will try and implement then as FFs, as each array requires 32K+ FFs the dessign is not likely to fit.

i THINK if its the problem of for loop i should'nt have answer at all,but i have the numbers and there are wrong?

ads-ee · Sep 17, 2015

As you are writing software using an HDL I can't comment much on how the code should behave.

I'm a hardware engineer and I build and design hardware, so my focus has and always will be on synthesizable code, non-synthesizable code is for testbench code only. Division by 9 can't be implement in hardware without resorting to some algorithm (e.g. non-restoring division) and using a clock and registers to store intermediate results. Combinational implementations are both slow and not easily realized in FPGAs.

I also saw you have both clk and wr_ena in the process sensitivity list wr_ena shouldn't be there.

milan.km · Sep 17, 2015

ads-ee said:
Your UUT code isn't synthesizable, a for loop can't be used to do division doesn't matter is it's VHDL or Verilog. To generate hardware the loop is unrolled, which means only the assignment when i and j are both 63 is done, hence it probably never changes. In the previous for loop in your tb I failed to account for your time control wait statement inside the loop, which results in software like behavior.

Now that I've looked at your UUT code, I think you need to rewrite a lot of it to make it synthesizable. For loops are used for replicating logic not for sequencing through an array. As you arent treating the array a memory the tools will try and implement then as FFs, as each array requires 32K+ FFs the dessign is not likely to fit.

thanks for ur answer,I want just to have simulation,do u still think I should change it?
would u help me how should I change it and I should replace for loop with what?
thanks

ads-ee · Sep 17, 2015

milan.km said:
yes,I just want to simulate.do u think iys because of for loop ,the answer is wrong?
i THINK if its the problem of for loop i should'nt have answer at all,but i have the numbers and there are wrong?

Then write the UUT in C++ or something else instead of VHDL. Then your software coding style won't be a problem with the simulation and will run as you desire as a single thread starting at the top of the code until it reaches the end of the code.

milan.km · Sep 17, 2015

do u think it will be ok if i change a to fixed point and replace a/9 by a*(1/9)??

- - - Updated - - -

ads-ee said:
Then write the UUT in C++ or something else instead of VHDL. Then your software coding style won't be a problem with the simulation and will run as you desire as a single thread starting at the top of the code until it reaches the end of the code.

i write it before but i first wanted to write it in silmulation mode in vhdl (which is easier thand hardware design)and have a spectation that how much time will bw saved in vhdl then start to write it as hardware design

ads-ee · Sep 17, 2015

milan.km said:
thanks for ur answer,I want just to have simulation,do u still think I should change it?

Ask yourself are you ever going to implement it in an FPGA or is this just a simulation only exercise to see how to simulate VHDL not write VHDL that is useful in a product.

If you are going to implement it in an FPGA sometime in the future then writing it in synthesizable VHDL will mean you won't have to rewrite it. If you are only exploring different implementation architectures then you should even be using VHDL IMO, you should be coding it in MATLAB, C++ or something else that is more software oriented and figure out the architecture of your implementation first (i.e. design it first). Then translate that design into HDL (i.e describe the hardware).

would u help me how should I change it and I should replace for loop with what?
thanks

lookup non-restoring division in wikipedia (it's basically doing pencil and paper division) it also requires a clock and FFs to store stuff as it calculates the result.

- - - Updated - - -

milan.km said:
do u think it will be ok if i change a to fixed point and replace a/9 by a*(1/9)??

multiplying would work, but still combinational circuits for this calculation is a bad idea, and it seems to me the circuit is unrolled so access to multiple array elements is required simultaneously (i.e. that means can't be implemented as a RAM block but must be implemented a FFs).

RAM becoming FFs seems to be a very typical newbie problem, must be related to the way VHDL/Verilog is taught in schools.

i write it before but i first wanted to write it in simulation mode in vhdl (which is easier thand hardware design)and have a spectation that how much time will bw saved in vhdl then start to write it as hardware design

Not sure what you're saying here about what you are trying to save? I see it as if you write it once using non-synthesizable code then if it works then you still don't have any idea if it will take 1 clock cycle or 100 clock cycles of latency to work when implemented correctly as a pipelined hardware design.

K-J · Sep 17, 2015

milan.km said:
yes,I just want to simulate.do u think iys because of for loop ,the answer is wrong?

You should simply use your simulator to step through the code and see what it is doing rather than just run it, look what pops out (or doesn't pop out) at the end and then ask in a forum what is wrong. Debug it like the software that it is. Put breakpoints in, step through the code, check intermediate results, etc.

Kevin

D.A.(Tony)Stewart · Sep 17, 2015

How will you know the result is correct without a checksum?

milan.km · Sep 17, 2015

why output is not written in textfile?

hi
I posted another question about my code in the previous posts, but as my question is new I posted them again.I hope I didnt make a mistake.
I have a question about the final part of my code for writting the output in textfile :

Code:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all;
use ieee.fixed_float_types.all;
use ieee.fixed_pkg.all;
----
entity x1 is
generic (m,n : Integer := 64);
port(clk : in std_logic;
     p_in : in unsigned(7 downto 0);
     p_out : out unsigned(7 downto 0));
end x1;
-----
architecture x1_arch of x1 is
subtype ufixed7_8 is ufixed (7 downto -8) ;
subtype ufixed11_4 is ufixed (11 downto -4);
type mat is array (0 to 4355) of unsigned(7 downto 0); --size of image with zero padarray
type mat1 is array (0 to 4095) of unsigned(7 downto 0); --size of image without zero padarray
type mat2 is array (0 to 4095) of ufixed7_8;

signal a,memory : mat :=(others => "00000000");
signal wr_ena : std_logic := '1';
signal temp4 : mat1 :=(others => "00000000");
signal temp2 : mat2 :=(others => "0000000000000000");
constant k : integer := (m+2);
-------- ufixed-----
signal b1 : ufixed7_8 := to_ufixed (0.2, 7, -8);
signal b2 : ufixed7_8 := to_ufixed (0.8, 7, -8);
signal ip : ufixed7_8 := to_ufixed (0.003 , 7, -8);
begin
--Read the data in process one to RAM
process(clk,wr_ena)
variable addr : integer range 0 to 4356 := 0;
begin
IF (clk'event AND clk = '1') THEN
  if (wr_ena ='1') then
    memory(addr) <= p_in;
    addr :=addr+1;
    if addr = 4356 then
      wr_ena <= '0';
    end if;
  else 
    a <= memory ;
  end if;
end if;
end process;
-- pause the first process forever, Start the second process doing the actual simulation.
process(a)
  variable temp : unsigned(11 downto 0) := "000000000000";
  variable l : integer := 0;
  variable temp1 : mat2 :=(others => "0000000000000000");
  variable temp5 : ufixed11_4 := "0000000000000000";
  
  
  begin
    l := 0;
  for i in 0 to 63 loop
    for j in 0 to 63 loop
      temp := ("0000"&a(k*i+j))+a(k*i+j+1)+a(k*i+j+2)+
              a(k*(i+1)+j)+a(k*(i+1)+j+1)+a(k*(i+1)+j+2)+
              a(k*(i+2)+j)+a(k*(i+2)+j+1)+a(k*(i+2)+j+2);
              temp5 := to_ufixed(temp, 11, -4);
              temp1(l) := resize(temp5*to_ufixed(0.1111,11,-4),7,-8) ;
              l := l+1;
              
     end loop;
  end loop;
  temp2 <= temp1 ;
end process;
process(temp2)
  variable temp3 : mat2 :=(others => "0000000000000000");   --???fixed
  begin
  for i in temp2'range loop
  --temp3(i) := to_ufixed(temp2(i), 7, -8);
  --temp3(i) := temp3(i) * ip ;
  temp3(i) := resize(temp2(i) * ip,7,-8) ;
     if ( temp3(i) < b1 ) then
     temp3(i) := to_ufixed(0,7,-8);   --??
   elsif (temp3(i) > b2) then
    temp3(i) := to_ufixed(1,7,-8) ;
  else
  temp3(i) := resize(to_ufixed(1.666,7,-8)*temp3(i)-to_ufixed(0.333,7,-8),7,-8);
  --temp3(i) := temp3(i)-to_ufixed(2,7,-8);  
end if;
temp3(i) := resize(temp3(i)* to_ufixed(255,7,-8),7,-8) ; 
[COLOR="#FF0000"]p_out <= unsigned(to_slv(temp3(i)(7 downto 0)));[/COLOR]
   end loop;
   ---debug
  for i in temp3'range loop
[COLOR="#FF0000"]temp4(i) <= unsigned(to_slv(temp3(i)(7 downto 0)));[/COLOR]
end loop;
-----------
    end process;
end x1_arch;

I'M SURE the output is correct according to signal temp4

Code:

temp4(i) <= unsigned(to_slv(temp3(i)(7 downto 0)));

but in the red line I should send the p_out to the textfile,but I do it wrong because the output is still empty,
here is the tesbench :

Code:

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
use ieee.numeric_std.all;
 
use std.textio.all;	
use ieee.std_logic_textio.all;	

 
ENTITY x1_tb IS
END x1_tb;
 
ARCHITECTURE behavior OF med6_tb IS 
 
    -- Component Declaration for the Unit Under Test (UUT)
 
    COMPONENT x1
    PORT(
         clk : in  std_logic;
         p_in : in  unsigned(7 downto 0);
         p_out : out  unsigned(7 downto 0)
        );
    END COMPONENT;
    

   --Inputs
   signal clk : std_logic := '0';
   signal p_in : unsigned(7 downto 0) := (others => '0');

 	--Outputs
  signal p_out : unsigned(7 downto 0):=(others => '0');
  signal Simulation_Complete : std_ulogic := '0';
   -- Clock period definitions
constant clk_period : time := 2 ns;

signal i:integer :=0;
signal p1:integer := 0;
BEGIN
 
	-- Instantiate the Unit Under Test (UUT)
   uut: x1 PORT MAP (
          clk => clk,
          p_in => p_in,
          p_out => p_out
        );

   -- Clock process definitions
   clk_process :process
   begin
		clk <= '0';
		wait for clk_period/2;
		clk <= '1';
		wait for clk_period/2;
		if (Simulation_Complete = '1') then
    wait;
   end if;
   end process;

   -- Stimulus process
   stim_proc: process
	file infile:text ;
	variable fstatus:File_open_status;
	variable in_line:line;
	variable p1:integer;
   begin		
      file_open(infile,"D:\IP1\in1.txt",read_mode);
      --wait for 5 ns; 	

		-- Add stimulus here
       while not endfile( infile ) loop
readline( infile, in_line );
		  read( in_line, p1 );
			 p_in <=to_unsigned(p1,8);
			 --wait until rising_edge(clk);
			 wait for 2 ns;
        end loop;
		file_close(infile);
		wait;
	end process;
stim_proc2: process
file outfile:text;
	variable fstatus:File_open_status;
	variable p2:integer;
	variable out_line:line;
   begin
	i<=0;
	  file_open(fstatus,outfile,"D:\IP1\out1.txt", write_mode);
	wait for 10000 ns;
      [COLOR="#FF0000"] for i in 0 to 4095 loop
             --wait until rising_edge(clk);
             wait for 2 ns;
				 p2:=to_integer(p_out);
	          write(out_line,p2); 
				 writeline( outfile ,out_line ) ;
        end loop;
        file_close(outfile);
        --wait for 3*clk_period;
        Simulation_Complete <= '1';
      wait;
   end process; [/COLOR]

END;

the red part is about writting p_out to the textfile which I think is wrong,but I dont know how to fix this.
I would appreciate if sb give me an idea.
thanks

ads-ee · Sep 17, 2015

The loop is unrolled so only the last p_out (i.e. temp2'range) gets assigned.

Write synthesizable code or at least don't use for loops unless you know how they are interpreted. VHDL is not software, so don't write code that will only run if it's software.

You should read a book on VHDL synthesis and a book on debugging. I also don't see how your code will ever synthesize to a design that runs at 500 MHz, you would be lucky if this piece of spaghetti runs at 50 MHz.

My recommendations are:

Draw a schematic (novice VHDL coder), block diagram minimum (intermediate VHDL coder), some notes on the pipeline design and a drawing or two (advance VHDL coder), nothing (VHDL hacking=buggy spaghetti code).
Don't use variables anywhere in your code for any reason. I never use them. Only when you can be classified as an expert VHDL coder would you introduce them into your repertoire of coding tricks.
Don't use for loops until you know exactly what happens when they are used. Unrolled or not depending on what's in the loop.
Not writing synchronous descriptions, writing code like process(a) and process(temp2) will result in huge combinational circuits that will be very very slow.

K-J · Sep 18, 2015

ads-ee said:
Write synthesizable code or at least don't use for loops unless you know how they are interpreted. VHDL is not software, so don't write code that will only run if it's software.

Actually, for what Milan has stated, his use of VHDL is software. He is simply trying to simulate something, so it is strictly software at this point.

You should read a book on VHDL synthesis and a book on debugging. I also don't see how your code will ever synthesize to a design that runs at 500 MHz, you would be lucky if this piece of spaghetti runs at 50 MHz.

You seem to be hung up on synthesis even though Milan has said a couple of times he is only trying to simulate his code. There is absolutely nothing wrong with describing actual hardware in a non-synthesizable manner, it is quite useful. Your recommendations would be more appropriate in a future thread that may come up along the lines of 'My design won't build with ISE/Quartus', but this thread is clearly about simulation only.

Kevin Jennings

Welcome to EDAboard.com

how to write a tesbench with reading input from text and writting output in text?

ads-ee

Super Moderator

K-J

Advanced Member level 2

milan.km

Member level 3

ads-ee

Super Moderator

milan.km

Member level 3

ads-ee

Super Moderator

milan.km

Member level 3

ads-ee

Super Moderator

K-J

Advanced Member level 2

D.A.(Tony)Stewart

Advanced Member level 7

milan.km

Member level 3

ads-ee

Super Moderator

milan.km

K-J

Advanced Member level 2

milan.km

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Connect with us

Online statistics

Forum statistics