EmbDev.net

Forum: FPGA, VHDL & Verilog synthesizable 2-dimentional array with generic variables


Author: Meli (Guest)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Hello,
Not so long from last appearance!
I've got a problem, Lothar, synthesizing the generic mux code with 
Design Compiler. As I know, it is not possible to synthesize a 
2-dimentinal array with generic parameters in DC. So, I thought of 
defining a new type like "wire" which is an array of std_logic_vector. 
Some colleagues told me this type might be synthesizable. But I have 
problem defining the new type with constant variables.
I attach the *.VHD file. Is it not really possible to define an aray 
type with variable?

Author: Lothar Miller (lkmiller) (Moderator)
Posted on:

Rate this post
0 useful
not useful
Meli wrote:
> Is it not really possible to define an aray type with variable?
What has to be "variable"?

In general in VHDL you have 2 ways to define an array. Have a look at 
this:
http://www.lothar-miller.de/s9y/archives/39-Mehrdi...
(maybe Google translateor can help...  ;-)
The major difference is in the acces to array elements:
  output0 <= FeldA(cnthi)(cntlo);
  output1 <= FeldB(cnthi, cntlo);
And of course you can use generics or constants to define the size of an 
array.

Author: Meli (Guest)
Posted on:

Rate this post
0 useful
not useful
Thanks Lothar. I know about the arrays and the way I can use the 
generics to describe the size of the arrays, but the point is that,to 
the best of my knowledge, this type of array declaration is not 
synthesizable by Design Compiler, using a generic for denoting the size.
As I posted before, someone told me that one solution for this problem 
is to define a type of a 2D array in a package, and I did so. But to 
define such an array I still need the generics, hence, I used constants 
to describe the size of the array. But it seems like those constants are 
not recognized in the package, and the error says "The identifier % is 
not defined".
Would u please take a look at the code and guide me through this 
problem?
Thanks in advance

Author: Lothar Miller (lkmiller) (Moderator)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Meli wrote:
> this type of array declaration is not synthesizable by Design Compiler,
> using a generic for denoting the size.
May be it wasn't in the last millennium, but now of course it is...

> But it seems like those constants are not recognized in the package
>  constant s is integer range 1 to 5 := 1;
A constant is defined in a different way (and also it has no range, 
because it is constant)...

> "The identifier % is not defined".
Have a look how a package is defined. And you will see that a package 
starts with the keyword library, and you will also see, thet each 
entity starts with the keyword library. And you will also see, that 
your VHDL code doesn't...

Author: Meli (Guest)
Posted on:

Rate this post
0 useful
not useful
Thanks Lothar. I will apply the changes and will report the result.
U r a real help, thank u for your time and comments. ;-)

Author: Meli (Guest)
Posted on:

Rate this post
0 useful
not useful
Deat Lothar,
As you mentioned, the line for using the work library was missing.
Also, there were some synthax errors like defining the constant is done 
with ":" not "is".
So, with applied changes the code worked.
Thanks again
:-)

Author: Meli (Guest)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Lothar Miller wrote:
> Meli wrote:
>> this type of array declaration is not synthesizable by Design Compiler,
>> using a generic for denoting the size.
> May be it wasn't in the last millennium, but now of course it is...
>
>> But it seems like those constants are not recognized in the package
>>  constant s is integer range 1 to 5 := 1;
> A constant is defined in a different way (and also it has no range,
> because it is constant)...
>
>> "The identifier % is not defined".
> Have a look how a package is defined. And you will see that a package
> starts with the keyword library, and you will also see, thet each
> entity starts with the keyword library. And you will also see, that
> your VHDL code doesn't...

Dear Lothar,
Regarding your last helpful comments, I finally got to design the 
generic mux and it was synthesized successfully in DC. Now I'm gonna 
test it with a testbench. I wrote the testbench and it has no errors and 
is simulated, but the waveforms show "U" for input and output ports. Can 
you please help me solve the problem?

I attach the *.vhd code of my testbench, which also contains the mux 
block.

Best Regards and thank you in advance

Author: Lothar Miller (lkmiller) (Moderator)
Posted on:

Rate this post
0 useful
not useful
Meli wrote:
> but the waveforms show "U" for input and output ports.
Are you simulating the wrong module?


BTW:
  TDinput(2**s -1 downto 0)(line_width-1 downto 0) <= temp2(2**s -1 downto 0)(line_width-1 downto 0);
TDinput is the same type and size like tem2. Therefore you can write it 
shorter:
  TDinput <= temp2;

BTW2:
Instead of writing a bunch of vectors like this:
    Tsel <= "00000"; wait for 10 ns;    
    Tsel <= "00001"; wait for 10 ns;        
    Tsel <= "00010"; wait for 10 ns;    
    Tsel <= "00011"; wait for 10 ns;        
    :
    :
    Tsel <= "11101"; wait for 10 ns;    
    Tsel <= "11110"; wait for 10 ns;    
    Tsel <= "11111"; wait for 10 ns;    
You could do it this way:
   for i in 0 to 2**s-1 loop
      Tsel <= std_logic_vector(to_unsigned(i,s));
      wait for 10 ns;    
   end loop;

And also this here:
  temp2(0)(line_width-1 downto 0) <= temp1(0);
  temp2(1)(line_width-1 downto 0) <= temp1(1);
  :
  :
  temp2(29)(line_width-1 downto 0) <= temp1(29);
  temp2(30)(line_width-1 downto 0) <= temp1(30);
  temp2(31)(line_width-1 downto 0) <= temp1(31);
Taken a similar loop it will look like:
   for i in 0 to 2**s-1 loop
     temp2(i)(line_width-1 downto 0) <= temp1(i);
   end loop;

Author: Lothar Miller (lkmiller) (Moderator)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Meli wrote:
> I wrote the testbench and it has no errors and is simulated, but the
> waveforms show "U" for input and output ports.
Yes, i also see them.

And now the question is: WHY?

And thats what a testbench is made for: to find design errors.

Now answer the question: why does the whole input look like rubbish?

And further on: why do the assignments to Tem2 and temp1 occur very 
delayed (320ns too late)?

Its because you wrote all of the assignments in ONE monster process. 
This process is stepped through and the values are saaigned to signals 
at the end of the process or at the very next wait statement. Just 
have a look in your VHDL book about the behaviour of signals inside a 
process. It is very essential to understand this behaviour!

Try the attached files and start thinking on your own. I urge you 
to...

Author: Meli (Guest)
Posted on:

Rate this post
0 useful
not useful
Thanks dear Lothar.
I know the better way of coding for the assignments, but since I'm 
frustrated with confiusing errors, I decide to code elementarily and 
then, after a successful compilation, I optimize my code.
OK, I'll look in my book again. You are right, the delayed signals are 
due to huge processes, but the "U" value for the ports doesn't seem to 
relate to the size of the process, does it?

Author: Meli (Guest)
Posted on:

Rate this post
0 useful
not useful
OMG!
It worked!
I took the assignment of TDinput out of the process and made the 
assignments as you mentioned, Lothar, and it worked!
begin
  UUT: Generic_Mux
  port map ( Dinput => TDinput, sel => Tsel, output => Toutput);
 
  temp1(0)<= std_logic_vector(to_signed (1,line_width));
  temp1(1)<= std_logic_vector(to_signed (0,line_width));
  temp1(2)<= std_logic_vector(to_signed (1,line_width));
  temp1(3)<= std_logic_vector(to_signed (1,line_width));
  temp1(4)<= std_logic_vector(to_signed (0,line_width));
  temp1(5)<= std_logic_vector(to_signed (0,line_width));
  temp1(6)<= std_logic_vector(to_signed (1,line_width));
  temp1(7)<= std_logic_vector(to_signed (0,line_width));
  
  temp1(8)<= std_logic_vector(to_signed (0,line_width));
  temp1(9)<= std_logic_vector(to_signed (0,line_width));
  temp1(10)<= std_logic_vector(to_signed (0,line_width));
  temp1(11)<= std_logic_vector(to_signed (0,line_width));
  temp1(12)<= std_logic_vector(to_signed (1,line_width));
  temp1(13)<= std_logic_vector(to_signed (1,line_width));
  temp1(14)<= std_logic_vector(to_signed (1,line_width));
  temp1(15)<= std_logic_vector(to_signed (0,line_width));
    
  temp1(16)<= std_logic_vector(to_signed (1,line_width));
  temp1(17)<= std_logic_vector(to_signed (1,line_width));
  temp1(18)<= std_logic_vector(to_signed (0,line_width));
  temp1(19)<= std_logic_vector(to_signed (0,line_width));
  temp1(20)<= std_logic_vector(to_signed (1,line_width));
  temp1(21)<= std_logic_vector(to_signed (0,line_width));
  temp1(22)<= std_logic_vector(to_signed (0,line_width));
  temp1(23)<= std_logic_vector(to_signed (1,line_width));
    
  temp1(24)<= std_logic_vector(to_signed (1,line_width));
  temp1(25)<= std_logic_vector(to_signed (1,line_width));
  temp1(26)<= std_logic_vector(to_signed (1,line_width));
  temp1(27)<= std_logic_vector(to_signed (0,line_width));
  temp1(28)<= std_logic_vector(to_signed (1,line_width));
  temp1(29)<= std_logic_vector(to_signed (1,line_width));
  temp1(30)<= std_logic_vector(to_signed (0,line_width));
  temp1(31)<= std_logic_vector(to_signed (1,line_width));
  
G:for i in 0 to 2**s-1 generate
     temp2(i)(line_width-1 downto 0) <= temp1(i);
  end generate;

    TDinput <= temp2;
    
P:process
 begin
   
 for i in 0 to 2**s-1 loop
      Tsel <= std_logic_vector(to_unsigned(i,s));
      wait for 10 ns;    
 end loop;
        
 end process;

So, it really matters that assignments are applied through a generate 
loop or one by one?! Why is that? It wasn't mentioned on the book!
Thanks again Lothar. You would be a great teacher (if you aren't one!).

kind regards

Author: Lothar Miller (lkmiller) (Moderator)
Posted on:

Rate this post
0 useful
not useful
>So, it really matters that assignments are applied through a generate loop or one 
by one?!
No. The "loop vs. one by one" isn't the solution of this particular 
problem! But it's very different (!) whether you assign values to a 
signal in a process or as a concurrent description.

> Whyis that? Itwasn't mentioned on the book!
A book has one major flaw: everything has the same priority. You cannot 
use bold for the important things and more bold for the more important 
ones. So everything has same important...
But be sure: this behavior will be described in every VHDL book...

> Thanks again Lothar.
You're welcome.

> You would be a great teacher (if you aren't one!).
I'm not... ;-)

Author: Meli (Guest)
Posted on:

Rate this post
0 useful
not useful
Oh, yeah! The point is in the difference of concurrent assignment vs. 
one-by-one in a process. But I still can't get why it didn't work when I 
assigned the values to the TDinput in a process. It definitely delayed 
the values but why it showed "U" eternally?!
By the way, could you please take another look to the post of :

http://embdev.net/topic/303196#new

I wanna express my highly gratitude in advance for your helpful 
comments.

Author: Lothar Miller (lkmiller) (Moderator)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Meli wrote:
> But I still can't get why it didn't work when I assigned the values to
> the TDinput in a process. It definitely delayed the values but why it
> showed "U" eternally?!
The assignment
    TDinput(2**s -1 downto 0)(line_width-1 downto 0) <= temp2(2**s -1 downto 0)(line_width-1 downto 0);
didn't work as expected. Only the rightmost element was changed. I 
didn't dig too deep into this problem and replaced that line by
TDinput <= temp2;
After that I saw a double delay on the temp signals (screenshot): the 
process obviously had to "run" twice to finally get the values assigned. 
So I put their assignment outside the process --> work done...

Author: Meli (Guest)
Posted on:

Rate this post
0 useful
not useful
Yes Lothar, you are right, the waveforms explain every thing and I'm 
justified with the reasoning. Thanks for your time. >:D<

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [vhdl]VHDL code[/vhdl]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.