Reading from STDIN for simulation

G

gthorpe

Hi,

I would like to pipe (UNIX pipe) inputs into my simulation e.g.:

'gunzip -c inputs.gz | ncsim -batch testbench'

where the testbench reads in lines of input:

while not endfile(input) loop
readline(F=>input, L=>line);
 
H

Hubble

Looks like ncsim does some weird ioctls when it detects that you do not
read from an ordinary file, like FIOASYNC etc. and does not handle the
pipe case correctly. If there is no complete data line, the simulator
stop instead of waiting :-(.

You can try to use trace or strace commands to detect what is going on.
These will print the system calls to stderr.

However, without source there seems to be little chance to correct your
problem.

Hubble.
 
G

gthorpe

Hubble said:
Looks like ncsim does some weird ioctls when it detects that you do not
read from an ordinary file, like FIOASYNC etc. and does not handle the
pipe case correctly. If there is no complete data line, the simulator
stop instead of waiting :-(.
You can try to use trace or strace commands to detect what is going on.
These will print the system calls to stderr.
However, without source there seems to be little chance to correct your
problem.

Hi,

Thanks, I was wondering if I was doing something wrong. It seems that the
simulator is in fact trying to perform seeks on the pipe, which fails. For
standard input, it polls unsuccessfully.

Interestingly, the seeks would not move the file pointer anyway:

lseek(10, 0, SEEK_CUR);

Where 10 is the fd of the pipe. It is trying to set the pointer to the current
location plus a zero offset (which is the same as the current location!).
After it fails, it closes the pipe and reopens it (it does read some of the
data before it tries to seek) which causes the writer to exit since the pipe
was closed. Of course, now when it tries to read again it cannot open the
file for reading because the writer has already closed it's end.

You are right, there isn't much I can do....
 
H

Hubble

Interestingly, the seeks would not move the file pointer anyway:
lseek(10, 0, SEEK_CUR);
...
You are right, there isn't much I can do....

Under some Unices and linux, you can "wrap" system calls if the
programs use libc as shared library (nowadays the standard case). You
can generate a shared library (my.so) containing an lseek function,
which ignores 0,SEEK_CUR and does the approriate lseek-syscall(2) - not
lseek itself - call otherwise. This will (hopefully) not break the
system. Your library can then be loaded by setting an environment
variable (LD_PRELOAD under linux, solaris has a similar system). Iff
you call

LD_PRELOAD=my.so ncsim <args>

ncsim will happily use your own lseek. Don't ask me for details, I
never did that. There are some thread libraries which do just that,
redefining open,close,read,... system calls.

Hubble.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,905
Latest member
Kristy_Poole

Latest Threads

Top