quick question

I have written a VHDL code to generate random numbers using a
"process". I want to implement the same using function/procedure so it
be a part of a package.

I would like to know if this should be done using a function or
procedure. How would a variable maintatin its pervious state in a
function/procedure? eg: if i generated 3 using rand, then next time i
call rand I want to generate the next random number after that

Can this be implemented using impure functions?

FP wrote:

> Can this be implemented using impure functions?

Yes, but if you want to package it, pass a
parameter to a shift function something like this ...
_______
 constant msb : natural := len_char_g -1;
 subtype  char_t is unsigned(msb downto 0); -- generic type, 8 bits
 constant mask_c              : char_t := "111" + zero_c;

 function randomize (arg_byte : char_t)
   return char_t is
   variable result_v : char_t;
 begin
    result_v := arg_byte;                    -- here it is
    result_v := shift_left(result_v, 1);     -- shift it
    if (result_v(result_v'left)) = '1' then  -- maybe invert mask bits
       result_v := result_v xor mask_c;
    end if;
    return result_v;
 end function randomize;
______

... from a synchronous process.

          -- Mike Treseler

FP,

I can't possibly see how you have done what you claim (generate a random
number from VHDL code).

Did you mean to say a quasi-random number? Such as a LFSR?

And a process statement,

http://www.gmvhdl.com/process.htm

creates no hardware, but is a "black box" of the function, and mostly
just used in verification to model something that is not part of what is
being implemented.

The fact that you use the word "call" means you are thinking of VHDL as
a conventional software program, which it is NOT.  VHDL and verilog are
hardware description languages, and all statements are executed in parallel.

So, one the next clock tick, whatever is supposed to change (update)
does so, in parallel, all at once.

Austin

On May 2, 12:56=A0pm, austin <aus...@xilinx.com> wrote:
> FP,
>
> I can't possibly see how you have done what you claim (generate a random
> number from VHDL code).
>
> Did you mean to say a quasi-random number? Such as a LFSR?
>
> And a process statement,
>
> http://www.gmvhdl.com/process.htm
>
> creates no hardware, but is a "black box" of the function, and mostly
> just used in verification to model something that is not part of what is
> being implemented.
>
> The fact that you use the word "call" means you are thinking of VHDL as
> a conventional software program, which it is NOT. =A0VHDL and verilog are
> hardware description languages, and all statements are executed in paralle=
l.
>
> So, one the next clock tick, whatever is supposed to change (update)
> does so, in parallel, all at once.
>
> Austin

Here is is code
procedure rand ( S1,S2 : in positive; min,max : in integer; rand : out
real ) is

  begin
	-- generate random number in real format
	uniform(S1,S2,rand1); -- seed values
	rand :=3D (real(min) + (rand1 * (real(max)-real(min))));
 end procedure rand;

 process
   variable randOut : real;
  begin
	rand(50,10,2,20,randOut);
	wait for 5 ns;
  end process;

The problem with the above is, it just gives me one output. I want it
to give me a new output every 5 ns. If I put the procedure
functionality in the process, I get that but not when I seperate them.
I need something to hold the pervious state.

On May 2, 12:56=A0pm, austin <aus...@xilinx.com> wrote:
> FP,
>
> I can't possibly see how you have done what you claim (generate a random
> number from VHDL code).
>
> Did you mean to say a quasi-random number? Such as a LFSR?
>
> And a process statement,
>
> http://www.gmvhdl.com/process.htm
>
> creates no hardware, but is a "black box" of the function, and mostly
> just used in verification to model something that is not part of what is
> being implemented.
>
> The fact that you use the word "call" means you are thinking of VHDL as
> a conventional software program, which it is NOT. =A0VHDL and verilog are
> hardware description languages, and all statements are executed in paralle=
l.
>
> So, one the next clock tick, whatever is supposed to change (update)
> does so, in parallel, all at once.
>
> Austin

This is just for siumlation.

More,

The process statement does execute statements (in this case,
instructions) in order, and is in essence, a convenience to put
conventional software 'instructions' inside the VHDL, but as I noted, it
doesn't create any hardware.

Austin

austin wrote:

> And a process statement,
> http://www.gmvhdl.com/process.htm
> creates no hardware, but is a "black box" of the function, and mostly
> just used in verification to model something that is not part of what is
> being implemented.

If we are talking about VHDL,
a process is always required to make *any* hardware.

> The fact that you use the word "call" means you are thinking of VHDL as
> a conventional software program, which it is NOT.  VHDL and verilog are
> hardware description languages, and all statements are executed in parallel.

That is how most hardware guys write vhdl code.
But I can, if I choose, describe parallel hardware with a
sequential description in a single process like this...
  http://mysite.verizon.net/miketreseler/
...and call all the functions a procedures that I want.

     -- Mike Treseler

On May 2, 1:28=A0pm, FP <FPGA.unkn...@gmail.com> wrote:
> On May 2, 12:56=A0pm, austin <aus...@xilinx.com> wrote:
>
>
> Here is is code
> procedure rand ( S1,S2 : in positive; min,max : in integer; rand : out
> real ) is
>
> =A0 begin
> =A0 =A0 =A0 =A0 -- generate random number in real format
> =A0 =A0 =A0 =A0 uniform(S1,S2,rand1); -- seed values
> =A0 =A0 =A0 =A0 rand :=3D (real(min) + (rand1 * (real(max)-real(min))));
> =A0end procedure rand;
>
> =A0process
> =A0 =A0variable randOut : real;
> =A0 begin
> =A0 =A0 =A0 =A0 rand(50,10,2,20,randOut);
> =A0 =A0 =A0 =A0 wait for 5 ns;
> =A0 end process;
>
> The problem with the above is, it just gives me one output. I want it
> to give me a new output every 5 ns. If I put the procedure
> functionality in the process, I get that but not when I seperate them.
> I need something to hold the pervious state.- Hide quoted text -
>

Your seed values that get passed into 'uniform' (S1, S2) need to be of
type 'inout' and they need to be maintained in whatever process it is
that calls your 'rand' procedure.

KJ

Mike,

OK, I thought I knew something and now I am confused by your answer.

A simulator will "execute" the VHDL and provide you with a verification
(simulation) of whatever it is you are trying to do.

Targeting that VHDL to a synthesis tool will use a library of hardware
elements (in an FPGA: LUTs, CLBs, etc; or in an ASIC: gates, registers,
flip flops, etc) and result in a hardware design that performs the
function you desired.

Some VHDL statements are for testing and test benches (simulation) and
don't create hardware (like a "wait 5ns" statement), right?

The hardware only knows about clock edges, so every single element of
the hardware (statement of VHDL) operates at once, there is no "sequence
of operation" as there is in a c program, for example execute the first
instruction, then the next, and so on -- does not exist in the
synthesized hardware.  In hardware it is on the next rising edge, do
everything everywhere based on the last state of all of the registers,
flip flops, latches, etc.

http://www.sunburst-design.com/papers/CummingsSNUG1999SJ_SynthMismatch.pdf

http://www.martiangeek.com/2008/01/16/how-to-write-hdl-code-that-works/

http://www.people.vcu.edu/~rhklenke/tutorials/vhdl/modules/m12_23/sld004.htm

Austin

Hmmm,

I see something that might confuse.  A VHDL if, case, or loop may seem
to have sequential behavior, but when synthesized into hardware, really
"executes" on a condition (such as a rising clock edge).  Thus on a
clock tick, the entire if-then-else, case, or loop is evaluated, and the
new state is a result of the previous state after the clock tick.  This
is much different than a software program which takes many clock cycles
to rattle though each instruction of the if-then-else, case, or loop;
and after each instruction, you are not really through evaluating all
the conditions, and you haven't updated the entire state until to get to
the end of the if-then-else, case, or loop.

Austin