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?
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-Mehrdimensionale-Arrays.html
(maybe Google translateor can help... ;-)
The major difference is in the acces to array elements:
1
output0<=FeldA(cnthi)(cntlo);
2
output1<=FeldB(cnthi,cntlo);
And of course you can use generics or constants to define the size of an
array.
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
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...
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
:-)
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
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...
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?
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
>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... ;-)
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.
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
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
1
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...
Watch this topic
Disable multi-page view