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

 Author: Louis L. (louivans) Posted on: 2014-08-19 12:53

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: 2014-08-19 15:13

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.

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
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 L. (louivans) Posted on: 2014-08-20 11:41

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 L. (louivans) Posted on: 2014-08-20 12:52

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: 2014-08-20 16:54

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: 2014-08-20 18:36

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.

• $formula (LaTeX syntax)$