[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [f-cpu] binary streams
in this mail i will try to sum up the different discussions
so please excuse me for the cross-posting and the length.
Kim Enkovaara wrote:
> On Thu, 13 Sep 2001, Yann Guidon wrote:
> > in the Eurostar, i found the reason why my random
> > routin gave strange behaviour. This can be illutrated
> > by the following code :
> > variable c : character;
> I think this is the problem. Define this as bit_vector or
> std_logic_vector. After that binary mode reading should work. Character is
> defined differently.
i am not sure to understand what you said.
I have already tried (well, with simili) to output std-ulogic_vectors
and it uses one byte per bit (each bytt represents the different possible
states of the corresponding bit). i don't understand what you mean by
"Character is defined differently." I have read two (rather exhaustive) VHDL
books in the subject and they did not address that point.
> Mr. Kim Enkovaara | firstname.lastname@example.org | Microelectronic Riemannian
> Vasamatie 1 C 16 | IRC: embo | curved-space fault in
> 02630 Espoo | | write-only file system
Michael Riepe wrote:
> On Thu, Sep 13, 2001 at 03:38:54AM +0200, Yann Guidon wrote:
> > > but I don't know what to do in VHDL. Perhaps you can do something like
> > > type octet is 0 to 255;
> > > type octet_stream is file of octet;
> > i think i tried this already, however i presume that this "subset"
> > for the "integer" type keeps the 4-byte encoding (the range is only restricted)
> > so if i read a "byte" i will increment the file counter by four.
> > i'll try anyway because i better prove it, but it's a gut feeling.
> 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...
> > > If it still stops at a ^Z, I would consider that a bug in Simili.
> > simili and vanilla definitely differ !
> As well as the underlying OSes.
sure. Fortunately, i see that simili is evolving in the good sense :-)))
i'll try to download a newer version if it is available.
the latest i got was VHDLSimili15b17.exe but i have not installed it
on my laptop.
> > > But you'll probably have to write a completely new set of I/O routines
> > > for the `octet' type.
> > not necessarily, but if it's necessary, i'll do it.
> Seems like there are predefined read and write procedures...
yes :-) i read that in one of Graham's books :-)
you can output almost any scalar type except file itself.
the textio interface defines a new type so the textio package itself
is just a bunch of wrappers.
operator overloading in VHDL is nice but it can become misleading...
> > > On the other hand, binary files are evil anyway because they're not
> > > portable (imagine you had to transfer them to a big-endian box, like
> > > SPARC).
> > in this case (random numbers coming from /dev/random or .tgz files)
> > it is irrevelant.
> In that case, you could also try a `file of integer' or something like
> that, and read larger quantities. I've attached an example (works
> with vanilla; please try simili yourself, I can't reboot while I'm
> writing e-mails ;).
i think i have another idea...
> Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
> "All I wanna do is have a little fun before I die"
> randex.vhdlName: randex.vhdl
> Type: Plain Text (text/plain)
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".
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.
Any hint or advice ?
Haneef Mohammed wrote:
> > first good news : Simili (1-year old version) works
> > rather well under wine. the hardest part is to setup
> > wine directories etc.
> > just write :
> Good to hear that.
> > $> wine "vhdlp filename.vhdl" 2> /dev/null
> > because wine output lots of error messages about semaphores
> > or something like that, but simili works anyway and well.
> > problem :
> > i want to make a "true" random function to initialize
> > variables and signals at startup, before /reset is activated.
> > so i use an external file access to /dev/null.
> > but it clashes ! i made a little simili/vanilla
> > comparison with the attached file and vanilla
> > treats characters as bytes while simili hangs
> > on certain characters ('EOF') in a binary stream.
> > what's your advice ?
> About the semaphore/criticalsection messages from wine,
> you can ignore them I believe.
i do and it is harmless.
> Someone said that there
> may even be a way to turn them off in the wine config file.
> I dont know why wine is outputting those messages.
i will try to investigate on that. i saw some parameters
in the wine config file but i don't know what parameter addresses
this special case.
> About reading binary data....
> Not sure what the problem is. I just tested it and I was
> able to read all 8-bit ascii characters in windows. You say
> that you are using an year old version which may be the problem.
> Can you try it out with the latest version? It works fine for
> me with 1.5 and 2.0.
i'll update my files.
> It is possible that in one of the older version,
> the files were being opened for read in text mode (which may explain
> what you are seeing).
certainly. i never open files in text mode in C (it is a good and safe
thing to write 'fopen(filename,"rb").
Later, Haneef Mohammed wrote:
> Please note that if you are writing files from VHDL,
> simili does convert \n ro \r\n (this is the default
> dos behaviour).....
i know and expected that something like that would happen
but it is not a problem because it is more about _reading_
> But, reading should be just fine with the latest 1.5
i'm happy to read that :-)
> A month or two ago, I noticed this on writes (when I
> was doing the Linux port) and 2.0 was changed so that
> both reads and writes happen in binary mode. Do you need
> the output to be pure binary...If so, I have to give you
> a patched version of 1.5 that you and your colleagues
> can use.
no need of a patch (we already do that all the time on our
own files :-P). The problem (currently) is to _read_ binary
stream without being interrupted by a 0xFF.
So here are the remaining questions :
- what is the safest way to write a VHDL code that read binary
inputs in a way that is as much portable as possible ?
- how can one "seek" to the beginning of a file when EOF is reached ?
- Vanilla complains in the "random" package when i want to put
shared variables in the body of the package. how can i
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.
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.
Thank you everybody for your help !
To unsubscribe, send an e-mail to email@example.com with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/