EmbDev.net

Forum: FPGA, VHDL & Verilog simulation to implementation, problems with the real type


Author: Louis Louis (louivans)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Hi,

I realised a VHDL program which works well at the simulation but when I 
want to implement it's said that the real type is not supported . I 
decided to change the real by some std_logic_vector but I have still 
some errors:

** Error: //pstudfsnb/home8/w13046248/My 
Documents/Work/lorenz1000.vhd(67): (vcom-1272) Length of expected is 32; 
length of actual is 96.

** Error: //pstudfsnb/home8/w13046248/My 
Documents/Work/lorenz1000.vhd(68): (vcom-1272) Length of expected is 32; 
length of actual is 96.

** Error: //pstudfsnb/home8/w13046248/My 
Documents/Work/lorenz1000.vhd(69): (vcom-1272) Length of expected is 32; 
length of actual is 96.

** Error: //pstudfsnb/home8/w13046248/My 
Documents/Work/lorenz1000.vhd(71): (vcom-1272) Length of expected is 32; 
length of actual is 64.

** Error: //pstudfsnb/home8/w13046248/My 
Documents/Work/lorenz1000.vhd(72): (vcom-1272) Length of expected is 32; 
length of actual is 64.

** Error: //pstudfsnb/home8/w13046248/My 
Documents/Work/lorenz1000.vhd(73): (vcom-1272) Length of expected is 32; 
length of actual is 64.

** Error: //pstudfsnb/home8/w13046248/My 
Documents/Work/lorenz1000.vhd(75): (vcom-1272) Length of expected is 32; 
length of actual is 64.

there are further, it's always the same, I try to change the lenght of 
the vector but it changed nothing.
I attached the two programs, lorenz which is the one works in simulation 
with real type and lorenz1000 with the vectors.

Author: Achim S. (Guest)
Posted on:

Rate this post
0 useful
not useful
the following line 67 belongs to your first error message:
yt11 := std_logic_vector(signed(y1m) + signed(h2)*signed(f01));
...
ft11 := std_logic_vector(signed(a)*(signed(yt12)-signed(yt11)));

Are you aware, that a multiplication of two signed variables of length 
32 results in a signed variable of length 64? (If you multiply the 
single decimal digit 9 with another 9, you need two digits for the 
result 81). Also adding two numbers of length 32 can give a result with 
a bigger length. This longer result will not fit into yt11.

Besides the length of your standard-logic-vectors your complete 
calculation is set up in a way that would give a terrible synthesis 
result. My most urgent recommendations would be:
a) avoid working with variables unless you really know what you're 
doing. Work with signals instead.
b) work with clocked processes, which lead to clocked registers in the 
synthesis result.
c) work with pipelines: calculate an intermediate result (like yt11) in 
one clock cycle, and use the result in the following clock cycle to 
calculate ft11. Don't try to execute all caclulations "at once".

Author: Louis Louis (louivans)
Posted on:

Rate this post
0 useful
not useful
yes I'm aware for the problem of length, I tried further solutions but 
it didn't worked.
I will try that you said, when you said to work with clocked process, 
you mean that it,s needed to put a wait instruction at each line of 
calculation ?

Author: Louis Louis (louivans)
Posted on:

Rate this post
0 useful
not useful
I change the constant and variable by some signald and I managed the 
problem of length, but my program is a loop so when I arrive at the end 
of the program with the good length for the vectors, it's said that the 
vector I corrected before don't have the good length. How can I managed 
this? maybe the vectors are not a good solution.

Author: Achim S. (Guest)
Posted on:

Rate this post
0 useful
not useful
Louis Louis wrote:
> but my program is a loop

mistake Nr. 1: you do not have a program at all. VHDL-code is a 
description of hardware. If you write VHDL for synthesis you must have 
an idea of the hardware you want to generate. What looks like a program 
is only a textual description of hardware. (For simulation you can 
pretty much ignore that, but not for synthesis).

Louis Louis wrote:
> when I arrive at the end
> of the program with the good length for the vectors, it's said that the
> vector I corrected before don't have the good length.

So the numbers in your repeated calculation grow bigger and bigger til 
they run to infinity? Most probably you have to scale your numbers 
inbetween: if a calculation gives a result of 96 bit length, then maybe 
only the most significant 32 bit carry real information while the 64 
lower significant bits carry only noise. Then you just take the 
uppermost 32 bit for further calculation and ignore the 64 bit of noise.

But you have to be carefull: depending on the calculations you execute 
it could also be, that the uppermost 32 bit are all 0 (or all 1 for 
negative numbers) and the real information is e.g. in the bits 60 downto 
28. Have a close look at your calculations and the numbers you put in, 
and evaluate manually, what extreme-values you may reach.

As an example: in your code you use 32 bits to describe the decimal 
number 3. If you multiply this with any 32 bit number, the result will 
be 64 bit wide, but the uppermost 30 bit will carry no information 
besides the sign of your result. The numeric information will start from 
bit 33 downwards.

Louis Louis wrote:
> I will try that you said, when you said to work with clocked process,
> you mean that it,s needed to put a wait instruction at each line of
> calculation ?

No, I did not mean that for sure.

As I stated above: you need an idea, how your description is converted 
in real hardware, so that you can write reasonable VHDL code. I 
recommend that you work through a book for synthesizable VHDL. In German 
my proposal would be Reichard/Schwartz: VHDL-Synthese, I'm sure there 
are good books in English too.

Author: Lattice User (Guest)
Posted on:

Rate this post
0 useful
not useful
the after will be ignored by the synthesyser, FPGAs don't have a 
generic delay element.
Z <= std_logic_vector(Z_buff) after 1ns;

This means that once you have fixed your vector size problem, the 
synthesyser will bark at you about the missing sensitivity list or 
clock, just like the simulator.

So for implementing it on the FPGA you need to add a clock from some 
external source.
begin
   wait until rising_edge(clk);
   y1m := X_buff;

   ...

Once you have fixed this, and probably some other problems, you will be 
able to build it, but only to find out that it will support only a very 
low clock rate.

Since your requires the output from the previous cycle, and even inside 
each stage requires the result from the previous stage there isn't much 
you can do for speeding it up.
Of course speed may be not your goal, i don't know.

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.