[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] binary streams



On Thu, Sep 13, 2001 at 10:46:14PM +0200, Yann Guidon wrote:
[...]
> > There's a fundamental difference between the declarations
> > 
> >         type octet is range 0 to 255;   -- i forgot the `range'...
> >         subtype other_octet is integer range 0 to 255;
> > 
> > `other_octet' is a subtype of `integer', and must use the same (4-byte)
> > encoding, IIRC, while `octet' is a new type that may use a single-byte
> > representation (vanilla doesn't, unfortunately).
> 
> i think that Vanilla trapped me with that...

On the other hand, Vanilla groks this:

	-- same `entity blah' as in randex.vhdl
	architecture blah of blah is
		type cstream is file of character;
		file x : cstream open read_mode is "random";
	begin
		process
			variable c : character;
			variable lout : line;
		begin
			while not endfile(x) loop
				read(x, c);
				write(lout, character'pos(c));
				writeline(output, lout);
			end loop;
			wait;
		end process;
	end blah;

And it doesn't stop at 0xff :)

[...]
> operator overloading in VHDL is nice but it can become misleading...

IMHO, operator overloading is *always* misleading.  Not only in VHDL,
but also in Ada, C++, ...

[...]
> well this is plain simple. my newest idea is far ... better :-)
> i'll code it before i shout victory :-)
> however i still need some really random bytes for the "seed".

1-transistor noise generator + ADC? ;)

> There is another problem though : When i reach the end of a file,
> i would like to wrap around. i tried to explicitely calling file_close
> and then file_open but the simulators complain :-/ the re-opening
> is not possible because the file name is still associated, or something
> like that. I don't know how to cheat/work around that.

According to the comp.lang.vhdl FAQ, it works like this:

	        file x : some_file_type;
	        -- ...
	        file_open(x, "a_file_name", read_mode);
	        -- ...
			file_close(x);

I guess the trick is not to open the file in the declaration, but
explicitly.

[...]
> I think that i will use a LFSR for the next parts.
> It still requires the possibility to input some bytes
> but the pressure is much reduced : /dev/random is very slow
> and not a continuous stream. This will also spread the randomness
> if text files were used in the input.

/dev/urandom is faster (but "less random").

> However, if the LSFR idea is used, some variables must be saved
> between two function calls : i have to create "shared variables"
> but Vanilla doesn't accept them.

I really try hard not to use shared variables, impure functions and
the like...

What about this:  define a record type that holds the LSFR's internal
state, and an `update' procedure with the state (inout) and the random
value (out) as parameters.  You can export both the `lsfr state' type
and the update procedure from a package, and you'll only have to declare
a state variable in every architecture (or process) that uses an LSFR.
*And* you can use multiple independent LSFRs, with different seeds :)

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/