[Fwd: [whygee@f-cpu.org: Re: [f-cpu] binary streams]]

[Yann Guidon <whygee@f-cpu.org>]

hello,

it seems that these mails did not go to the list.
sorry for the delay.

----- Forwarded message from Yann Guidon <whygee@f-cpu.org> -----
From: Yann Guidon <whygee@f-cpu.org>
To: f-cpu@seul.org, "Haneef D. Mohammed" <haneef@symphonyeda.com>
Subject: Re: [f-cpu] binary streams

hi !

Michael Riepe wrote:
> 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 :)

yes, i tried it (i think i reported it yesterday).

> [...]
> > 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++, ...
you know already : i'm really a "low level guy" :-) before Java and
VHDL, i never used overloading. Who needs it after all ?... :-)

> [...]
> > 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? ;)
hell, i don't want to use SPICE as back-end :-P

> > 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:
grrrr, i don't have the FAQ on my laptop, what a shame :-P

>                 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.
it should be something like that, sure. thanks :-)

however, the fact that the file is initialised at initialisation
is very practical : it is like a "shared variable" and consecutive
reads yield different results, whether we read a normal file
or a link to /dev/random.
I don't know how to solve this problem ... let's think tonight.

> [...]
> > 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").
who cares ? :-)
but thanks about the tip for urandom : it seems to work on my debian laptop :-)

> > 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...
it's only for the simulation.
and if you don't like it, just use the "dumb" version that
makes no randomness at all. it's very easy.
look at my latest snapshot : there is a file named "random_clear.vhdl"
which "implements" the package but it just puts 0 all over the place.

> 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 :)
nice idea but a bit heavy...
btw, it must be a function (not a procedure) so that we can write
  signal a : std_ulogic_vector(whatever range) := random(a);

--> btw, there is a problem with Vanilla/simili differences :
with Simili you can write the above line,
but with vanilla you must write something like

subtype suv : std_ulogic_vector(whatever range);
signal a : suv := random(suv'(others=>'0'));

Vanilla doesn't seem to recognize the element that is being declared.

--> enf of aparte

If you add an external record, it must be stored somewhere.
preferably in the toplevel, but then we have to include a "port"
to transmit this value to all the subcircuits. ugly !
The other way is to add a variable/signal in every entity that
uses random but it's still rather heavy. Maybe we can try with the
generics ?

I definitely don't like to use 'local' records. it must be kept
in the package for simplicity and clarity.

BTW i have found a configurable LFSR package in one of Graham's books.
it will be used for the BIST unit. look in eu_bist.


in another mail, Michael Riepe wrote:
> On Thu, Sep 13, 2001 at 07:57:02PM +0200, Yann Guidon wrote:
> [...]
> > Simili gave me a surprise : first, it deals with bytes.
> > at least, this is what the old version i use does.
> > I think that it gives a little insight in how simili
> > works internally. I tried to raw-"write" some structures
> > and a std_ulogic_vector(N downto 0) outputs N bytes (not N-1).
> That should better be N+1...
oops.
well, for N bits it outputs N+1 bytes.

> One byte per (std_ulogic) bit is ok, since std_ulogic can have 9 values.
> A packed (2 std_ulogic bits per byte) format would save some space but
> is harder to handle.
certainly. But as Haneef told us, there were improvements in the
latest versions. I am going to install 15b17 in the laptop and see what
happens...

> > Second, given a binary input, it stops after N bytes.
> > I compared the hexdump of the input and the output :
> > input  : 68 FF 7E
> > output : 68 68
> > (that is : where the output stopped). I fear that it can be
> > worse that i thought. Well i SHOULD update my local copy of
> > simili. Maybe it was fixed long ago. But stopping on a 0xFF
> > is not a good sign for a C program. I know : Simili is written
> > in C++ and i don't know a damn about it. So i will let
> > the experts discuss about it.
> 
> C/C++ programs stopping at 0xff usually suffer from the `getc() return
> type' problem (some programmers use C stdio in C++).  But it could also
> be the C runtime library (getc() returning negative values if the char
> value goes beyond 127, which makes EOF and (char)255 indistinguishable).
> But I'm not a Windoze Quirks Expert (tm)...
i feared something like what you said. i'll try the newer version.

ok, good night. i'll have to wake up early and go to the tax office etc...

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE, professional VHDL newbie
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

----- End forwarded message -----
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/