General Technical Discussion

[adtun]

Hello. I have two processes. 1. Main, 2. Random Number Generator.

------------------------------------------------------------------------------------

signal random : std_logic_vector(0 to 3);

process(clk) --- MAIN PROGRAM
begin
for i in 0 to 7 loop
number(i) <= conv_integer(random(0 to 3));
end loop;

end process;

--------------------------------

process(clk) --- RANDOM NUMBER GENERATOR

begin

- - - - - - 

- - - - - - 

      random <= - - - - -;

end process;

For every clock, Random module can produce a new random number. There is no problem. But, in main process, when I want to take these random numbers(by using random signal), it sends the same random number. What can i do for this problem? Thank you very much.

[joelby]

It's not completely clear what you're doing, but it sounds a bit like you're trying to generate eight random numbers, number(0) to number(7), every clock cycle. You will need eight different random number generators to do this, so replicate your random process.

A 'for' loop in HDL is unrolled at synthesis - it is not equivalent to a microprocessor loop, where you might expect it to take eight cycles to assign all of the numbers.

[eilert]

Hi,

I don't know about your random number generating process, but your main process has no synchronous description in it.

Probably it's just for simulation anyway, so you could write it like this:

process --- MAIN PROGRAM
begin
for i in 0 to 7 loop

wait until rising_edge(clk);

number(i) <= conv_integer(random(0 to 3));
end loop;

wait; -- forever   which stops the process, useful in testbenches

end process;

Does your random number generator have a synchronous description in it?

The sensitivity list alone is not sufficient. It triggers on both clock edges in simulation and in synthesis you would get some combinatorical circuit because it is ignored there.

Besides, why do you convert the number to some integer?

Blowing up 4 bits to 32 is just a waste.

If it's just for waveform viewing purposes, this can be done better with the RADIX setting of the simulator.

Have a nice simulation

  Eilert

[adtun]

Thank you very much for your answers. 

Actually, I will implement all codes on Xilinx XUPV5-LX110T FPGA device. Ithink I can not use "wait". I use Genetic Algorithms. For this I need random numbers. For example; for 40 individuals, I need 320 random numbers. Here, two processes run with "CLK". But in one "CLK" Random Number Generator generates one random number. But I want while Main Process runs, I will take 320 random numbers.

Process(CLK) MAIN PROGRAM

----

----

Genetic Algorihm

----

----

end process;

Process(CLK) RANDOM NUMBER GENERATOR

----

----

end process; 

[chary.vlsi]

u r random number generator(2nd process) generates 1 random no. per 1 clk.

But  for loop updates number(0) to number(7) by randum with in 1 clk event. So same No. was repeated.

number(0) to number(7) should be updated by 8 clks.

Update number under clk rising/falling edge, then problem solved.

-- chary

[eilert]

Hi.

If you are actually going to write code for synthesis you should use sth. like

process(clk) is

begin 

 if rising_edge(clk) then

   -- your algorithm

 end if;

end process;

You should remove the concept of "Programm" from your brain while working with FPGAs and install "Hardware Design" instead. ;-)

Keep away from loops (for the beginning). They have their use for handling some data types elementwise, but with synchronous processes like shown above they do not iterate on each clock cycle.

The whole algorithm is processed once every clock cycle. So you have to controll what really should happen then.

The limitations are only constraint by physical properties. Everything else is up to your engineering skills.

e.g. if you want to use 320 new random numbers in one cycle of the main process you can go two ways.

1) create 320 PRN-Generators.

2) have one PRN-Generatur run with 320 times the clock of the main process. Store the values in buffer registers.

Besides, not everything needs to be done in one clock cycle. If we are talking about 100MHz for example it would mean that your genetic algorithm would have 100 million evolution steps per second. Do you really need that (while it surely would be nice to have it)? What's the speed of the software solutions you want to beat?  

Have a nice synthesis

  Eilert

Of course these approaches can be mixed for a good balance of area and clock frequency.

But sometimes it might be better to rethink the initial goal from a hardware perspective.

Hardware solutions are often very different from their software counterparts and might need a different understanding of the problem.

e.g Software often solves problems by massive storing of data, Hardware solutions avoid this method because memory is rare on a FPGA and external memory can cause bottlenecks for the design efficiency.

[adtun]

Thank you very much for your answers and interest.