[myhdl-list] Re: myhdl on windows platform?
Brought to you by:
jandecaluwe
Menu
▾
▴
[myhdl-list] Re: myhdl on windows platform?
|
From: Jan D. <ja...@ja...> - 2004-12-31 16:06:06
|
Chun Lin Zhang wrote:
> Jan,
>
> I tried the method you proposed for me. I made some necessary changes of
> file cosimulation/icarus/test/test.py, use the python in cygwin to
> co-sim (python test.py), and got the following kind of errors.
Thanks for your efforts.
> I don't know what is this assertion means. Could you help me out, or if
> these is a definite message that myhdl can't be used with any windows
> version simulator, I can abort my effort in this.
It may mean that we are almost there. I am prepared to debug it further,
but as I will describe below, I will need your help. I will leave it to
you to decide whether you want to continue the debug process.
In the chapter on co-simulation of the manual, you will find the
following section:
"""
\subsubsection{Interrupted system calls \label{cosim-impl-syscalls}}
The PLI module uses \code{read} and \code{write} system calls to
communicate between the co-simulators. The implementation assumes that
these calls are restarted automatically by the operating system when
interrupted. This is apparently what happens on my Linux box and on
other operating systems I have used before.
I know how to handle non-restarted interrupted system calls, but I
cannot test the code! Also, I don't know whether this is still a
relevant issue with modern operating systems. So I left it
at that for the moment, and added assertions that should trigger
when this situation occurs.
Whenever an assertion fires in the PLI module, let me
know. The same holds for Python exceptions that you cannot
easily explain.
"""
This seems to correspond exactly with what you are describing.
Solving it would essentially mean that I need to adapt the C code
and probably also the Python code at the other side, so that
system calls (read and write) are restarted when they have been
interrupted. Again, I know how to do this (I think) but the
problem is that I can not test this because it doesn't happen
on my platform. So here's where I would need your help in
debugging.
Before proceeding, the best would be to verify whether this is
really the problem. In the C code, you can add code like the
following immediately after n has been set by a write or a read
(and before the assert statements) (untested code):
#include <errno.h> /* to access the errno variable */
....
....
n = read(....) /* or n = write(.....) */
....
if (n<0) {
fprintf(stderr, "Error num %d: %s", errno, strerror(errno));
}
This should print detailed error information.
Regards,
Jan
>
> Thank you very much.
>
> Btw: You've done a great job. Till now it works fine on linux platform
> for me as a very good HVL.
>
> -Arnold
>
> # vsim -do sim.do -c -pli {h:\mti\myhdl.dll} tb
> # Loading c:\Modeltech_6.0a\win32/novas.dll
> # Loading h:\mti\myhdl.dll
> # // ModelSim SE 6.0a Sep 24 2004
> # //
> # // Copyright Mentor Graphics Corporation 2004
> # // All Rights Reserved.
> # //
> # // THIS WORK CONTAINS TRADE SECRET AND
> # // PROPRIETARY INFORMATION WHICH IS THE PROPERTY
> # // OF MENTOR GRAPHICS CORPORATION OR ITS LICENSORS
> # // AND IS SUBJECT TO LICENSE TERMS.
> # //
> # Loading work.tb
> # do sim.do
> Assertion failed: n > 0, file myhdl.c, line 216
>
> abnormal program termination
> ** Fatal: Signal 22 caught. Closing vsimk kernel.
> ** Fatal: Signal Caught in kernel.
> ** Fatal: vsimk is exiting with code 222.
> (Exit codes are defined in the ModelSim messages appendix
> of the ModelSim User's Manual.)
> Traceback (most recent call last):
> File "test.py", line 17, in ?
> cosim = Cosimulation("vsim -pli h:\mti\myhdl.dll -c tb -do sim.do",
> a=a, b=b
> , c=c)
> File "/usr/lib/python2.4/site-packages/myhdl/_Cosimulation.py", line
> 91, in __
> init__
> raise CosimulationError(_error.SimulationEnd)
> myhdl.CosimulationError: Premature simulation end
>
>
> "Arnold" <chu...@ho...
> <mailto:chu...@ho...>> wrote in message news:...
> > Jan,
> >
> > Thank you for your quick reply.
> >
> > Another question is about using cygwin to compile python on windows:
> can I
> > use mingw32 to compile python instead of cygwin? If yes how can I achieve
> > that.
> >
> > Thanks
> >
> >
> > "Jan Decaluwe" <ja...@ja... <mailto:ja...@ja...>>
> wrote in message
> > news:41C...@ja......
> > > Chun Lin Zhang wrote:
> > > > Hi, all,
> > > >
> > > > I tried to use myhdl to co-simulate with verilog on windows platform
> > > > today. I got the following error messages.
> > > >
> > > > Traceback (most recent call last):
> > > > File
> > > >
> > "C:\Python23\lib\site-packages\Pythonwin\pywin\framework\scriptutils.py",
> > > > line 310, in RunScript
> > > > exec codeObject in __main__.__dict__
> > > > File "D:\proj\myhdl-0.4\cosimulation\mti\test\test.py", line
> 17, in ?
> > > > def stimulus(a, b):
> > > > File "C:\Python23\Lib\site-packages\myhdl\_Cosimulation.py",
> line 71,
> > > > in __init__
> > > > child_pid = self._child_pid = os.fork()
> > > > AttributeError: 'module' object has no attribute 'fork'
> > > >
> > > > I queried the library reference of python, it DO mentioned that
> os.fork
> > > > is only available in UNIX.
> > > >
> > > > So I guess MyHDL doesn't have the ability to co-sim with Verilog on
> > > > windows currently. However, do you have any plan to support this on
> > > > windows recently?
> > >
> > > Hi:
> > >
> > > In general, I would like MyHDL run on any Python platform.
> > > I try to take advantage of Python's portability.
> > > However, I only use Linux as a development platform myself,
> > > and I don't have the possibility to test/maintain multiple
> > > platforms. This is one area where I have to rely on outside
> > > help.
> > >
> > > The closer one gets to the operating system, the more likely
> > > it is that problems will appear. The way co-simulation is
> > > currently set up, using fork to create new processes, is
> > > one example. Note that "native" MyHDL shouldn't pose any
> > > problem, and if it does, it should be possible to solve
> > > it easily.
> > >
> > > For this concrete problem: I wasn't fully aware of the
> > > fork issue, but I have done some investigations. It seems
> > > indeed that this is not available on Windows, and cannot
> > > even be emulated easily. From what I read it may be
> > > availabe on NT, but even then it's not certain that Python
> > > will support it.
> > >
> > > Your best bet, I think, is to compile Python under Cygwin
> > > on Windows, instead of using the native Python. This should
> > > give you fork as I understand it.
> > >
> > > This may be a reasonable solution, because I wonder what
> > > Verilog simulator you are using? If it is Icarus, I believe
> > > that the way it works on Windows is by using Cygwin anyway.
> > >
> > > Note: I never used Cygwin myself, but it seems to get good
> > > press.
> > >
> > > Another solution, perhaps, would be one for me: using another
> > > approach for co-simulation. It might be possible to use
> > > threads instead of processes, and this should work on all
> > > platforms (using Python's threading module).
> > > I will need to investigate this further, and I have no idea
> > > what problems I will encounter, so don't count on this
> > > one anytime soon.
> > >
> > > Hope this helps,
> > >
> > > Jan
> > >
> > > --
> > > Jan Decaluwe - Resources bvba - http://jandecaluwe.com
> > > Losbergenlaan 16, B-3010 Leuven, Belgium
> > > Python is fun, and now you can design hardware with it:
> > > http://jandecaluwe.com/Tools/MyHDL/Overview.html
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > SF email is sponsored by - The IT Product Guide
> > > Read honest & candid reviews on hundreds of IT Products from real
> users.
> > > Discover which products truly live up to the hype. Start reading now.
> > > http://productguide.itmanagersjournal.com/
> >
> >
--
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
Using Python as a hardware description language:
http://jandecaluwe.com/Tools/MyHDL/Overview.html
|
