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.

Register Log in

why having error with concatenation?

Status
Not open for further replies.
M

milan.km

Member level 3
Joined
Sep 14, 2015
Messages
55
Helped
0
Reputation
0
Reaction score
0
Trophy points
6
Activity points
435
hi
i want to concatenate the input pixel pi which is signed(7 downto 0) and write it four times in one row of ram. but i have the following error ,can anybody help me why this is happening?
thanks
Code: 
inter(adr) <= pin & pin & pin & pin;
found '2' definitions of operator "&", cannot determine exact overloaded matching definition for "&"
Click to expand...
 

You probably have more than one library loaded that has conflicts for the & overloading.

What libraries do you call out in the use statements.
 
sounds like you included the std_logic_arith library and the numeric_std library together. You should delete the non-standard std_logic_arith from your code.
That is only a guess without the context of the full code.
 

Code: 
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all;
i have these libraries.
 

please show the whole code (especially the declarations) so we can see the context.
 

TrickyDicky said:
please show the whole code (especially the declarations) so we can see the context.
Click to expand...

here :
Code: 
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all;
----------------------------
entity neighbinter is
port( pin : in signed(7 downto 0);
      clk : in std_logic;
      pout: out signed(31 downto 0));		
end neighbinter;
--------------------
architecture neighbinter_arch of neighbinter is
type int_type is array (0 to 63) of signed(31 downto 0);
type int1_type is array (0 to 63) of int_type;
signal inter : int1_type := (others => (others => "00000000000000000000000000000000"));
signal adr : integer range 0 to 4096 := 0 ;
begin
process(clk)
variable i,j : integer range 0 to 64 := 0 ;
variable k : integer range 0 to 4 := 0 ;
begin
if (clk'event and clk='1') then
if (adr < 4096) then 
inter(adr) <= pin & pin & pin & pin;
adr <= adr+1;
end if;
if (adr /= 0) then 
 if (i < 64) then
   if (k < 4) then 
     if (j < 64) then
	    pout <= inter(i)(j);
		 j := j+1;
		 if(j=64)then
		 k := k+1;j:=0;
		 if (k=4) then
		 k := 0; i:= i+1;
		 end if;
		 end if;
    end if;
 end if;
end if;
end if;
end if;
end process;
end neighbinter_arch;
 

Inter is declared as a 64x64 array of 32 bit signed numbers.
So when you assign inter(adr), it is expecting 64 32 bit signed numbers.

pin & pin & pin & pin

is only a single 32 bit signed value. You didnt specify the other 31 values.

- - - Updated - - -

ps, when you run this code, if adr goes larger than 63 you're going to get an array index out of bounds error.
 
i use this code to write each pixel of a image in a row four times and then read each line four times (simple interpolation)
that first extend each pixel of each row to four pixel(i did this by concatenating an 8 bit pixel and write it into a 32 bit ram) and then extend each row to four row,i write this code but its too complicated and have a complex hardware,can anybody help me write it more simple?
thanks
 

Well at the moment there are errors in your code - so try fixing that first.
 
thanks trickydicky
there is no syntax error now,but i dont know how to make it simpler than now.
Code: 
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all;
----------------------------
entity neighbinter is
port( pin : in signed(7 downto 0);
      clk : in std_logic;
      pout: out signed(31 downto 0));		
end neighbinter;
--------------------
architecture neighbinter_arch of neighbinter is
type int_type is array (0 to 63) of signed(31 downto 0);
type int1_type is array (0 to 63) of int_type;
signal inter : int1_type := (others => (others => "00000000000000000000000000000000"));
signal adr : integer range 0 to 4096 := 0 ;
begin
process(clk)
variable i,j,m,n : integer range 0 to 64 := 0 ;
variable k : integer range 0 to 4 := 0 ;
begin
if (clk'event and clk='1') then
if (m<64) then 
if (n<64) then
inter(m)(n) <= pin & pin & pin & pin;
n := n+1;
if(n=64) then 
n := 0; m := m+1;
end if;
end if;
end if;
 if (i < 64) then
   if (k < 4) then 
     if (j < 64) then
	    pout <= inter(i)(j);
		 j := j+1;
		 if(j=64)then
		 k := k+1;j:=0;
		 if (k=4) then
		 k := 0; i:= i+1;
		 end if;
		 end if;
    end if;
 end if;
end if;
end if;
end process;
end neighbinter_arch;
 

There is still an error, because m never gets reset back to 0.

I dont understand why it is so complex. Looking at it pout is just a registered version of the inter signal. I dont see when it would never change, because i/j/k are always incremented.

Why not just have a single addr counter that increaments from 0 to 4095?
 

There is still an error, because m never gets reset back to 0.
Click to expand...
because when m is 63 it means that we write the whole matrix in ram and we want stop writting in RAM.
Why not just have a single addr counter that increaments from 0 to 4095?
Click to expand...
as i said before i write one image 64*64 in ram,i wanted to extend each pixel of each row(doing this by concatenation) and next i want to read each row four times(??this is the problem why i use all these counters and make it so complicated.).
here is one example of this
a b
c d
a a a a b b b b
a a a a b b b b
a a a a b b b b
a a a a b b b b
c c c c d d d d
c c c c d d d d
c c c c d d d d
c c c c d d d d
 

Where is the data for the ram coming from? there is no write enable on the interface so this just expects data from the start. Give this I dont really see the usefulness of this ram.

Also, why doesnt i ever get reset? what is the data playing out to?

Given this - why is this even a ram? the current design simply delays the input by a single clock cycle. Why not just put a register in there?
 
Where is the data for the ram coming from?
Click to expand...
i want to use this component in the main code, data is coming from the testbench i will write for the testbench.
there is no write enable on the interface so this just expects data from the start. Give this I dont really see the usefulness of this ram.
Click to expand...
i didnt put write enable but because of
Code: 
if (m<64) then 
if (n<64) then
when all te input data is written in ram it will stop writiing.
Also, why doesnt i ever get reset? what is the data playing out to?
Click to expand...
it doesnt have a reset because i just want to use it one time and the data is going to the next component (its the next function) i want to do after interpolation.
Given this - why is this even a ram? the current design simply delays the input by a single clock cycle. Why not just put a register in there?
Click to expand...
i want to repeat each of 64 row,can i do this with delay?
actually this design was the only way cross to my mind i would really appreciate if u help me with another ideas.
thanks
 

The problem will be in a real system is that this data will play in and out very quickly.

I think you need to take a step back, and draw out your design ON paper. The code you have looks like you wrote some software and wrapped a synchronous process around it. Although this code will technically work, it's not very functional in a design sense.

What are you trying to acheive from the top level?
 

i am agree with u ,its software.
i am trying to do some image processing on a image.
but the main idea for doing this "concatenating each pixel four times and put a counter in each row and read it four times is a good idea for implementing in fpga??
 
Last edited:

Whatever you're trying to do - its like software, so not a good style for hardware.
You need to draw your design out on paper before writing ANY HDL code.
 
For actual implementation you would want to ensure this maps to efficient resources. This is 32bit * 4096 = 128kbit. This could map to 4 32k BRAMs or 128k registers. (or distributed ram in some amount in between).

The concatenation should be done on the read side of the ram, not the write side -- this cuts the ram size down by a factor of 4. The adr index should be limit to 0 to 4095, not 4096. The addressing may need to be limited to a single dimension (check synthesis tool documentation or results). This gets the ram size down to 1 BRAM, so further optimization is not required.

You would need some reset and read/write trigger/enable for this to be practical.
 

vGoodtimes said:
For actual implementation you would want to ensure this maps to efficient resources. This is 32bit * 4096 = 128kbit. This could map to 4 32k BRAMs or 128k registers. (or distributed ram in some amount in between).

The concatenation should be done on the read side of the ram, not the write side -- this cuts the ram size down by a factor of 4. The adr index should be limit to 0 to 4095, not 4096. The addressing may need to be limited to a single dimension (check synthesis tool documentation or results). This gets the ram size down to 1 BRAM, so further optimization is not required.

You would need some reset and read/write trigger/enable for this to be practical.
Click to expand...

nope by a factor of 16 the op is replicating pixels in 2 dimensions, see post 12.

I'd considered suggesting the read side of the RAM earlier today, along with a counter that counts the entire output data array. The addresses to the reading side are sliced from bits of the counter that match the (a x4, b x4) x4, (c x4, d x4) x4 sequence. Too much work for me to actually figure out the conversion between counter and read address, which is why I didn't reply earlier. I'll leave it up to the OP or someone else to come up with the counter bits to use.
 

it is a factor of four in the ram. The OP re-reads the row from ram four times, and appears to have a 4x wide output bus for the replication.

The read addressing is either a (6+2)+(6+2) bit counter, or a (6+2)+6 bit counter. For a single pixel output per cycle, the former is used, and bits 0,1,8,9 are not used in the indexing. For four pixels at a time, bits 6,7 are not used. However there is no need to concatenate the pixels on the write side -- that can be done on the read side.

--edit: 4x bus width for the replication in the horizontal dimension. re-read four times for the replication in the vertical dimension.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top