Reading from STDIN for simulation

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);

.
.
.
end loop;

However, the simulation never reads in any input but says the file cannot be
opened for reading. Used named pipes in the file system (again UNIX-specific)
works for a bit but eventually returns the same error.

The previous simulator I used (vhdlsim, from synopsys) did not have trouble
reading from the named pipes but I never tried to pipe in inputs with it. Is
there any way to get one of the two (pipe or named pipe) working with ncsim
(cadence simulator)?

Since reading from these will look like reading from real files (since no seeks
should be attempted for the sequential case), I do not see any fundamental
reason why it should not work, but it isn't. Uncompressing inputs.gz will take
up more space than is available (several sets of inputs.gz) to use it directly
in the readline.

 

Hubble <reiner@huober.de> wrote:

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.

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....

 

[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.

 

[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.