myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] signals in $to_myhdl can't exceed 64?

[Arnold <chu...@ho...>]

Jan,

I got the error message said that signals in $to_myhdl can't exceed 64 when
using MyHDL as HVL in my project. Could you give me a clue how to solve this
issue if my project had to have more than 64 signals monitored by MyHDL?

Thanks

-ChunLin

[myhdl-list] Re: MyHDL / ModelSim cosim

[Jan D. <ja...@ja...>]

David Brochart wrote:
> Jan,
> 
> I tried using one of the PLI C code you published for Icarus and running it with
> ModelSim. It works fine except that VSIM application gets bigger and bigger in

The fact that it works is good news. If the code works unchanged,
I could potentially continue to develop with Icarus (assuming its PLI
support is better by now) and just ask others (like you ;-)) to run
a regression check with Modelsim.

> the system, as if there was a memory leakage. I didn't notice it at the
> beginning but for very long simulations, which contain a lot of I/F signals
> between MyHDL and ModelSim (around 300), ModelSim just crashes.
> Have you noticed it with Icarus or CVER too? Any clue about the cause of it?

I haven't noticed this, but this doesn't mean a lot as I have never done
very long simulations to check this.

My guess is that it is a memory leak caused by the myhdl PLI code, not
by the simulator. This means that I should be able to reproduce it with
Icarus.

I have briefly looked at the code and I can see potential memory leaks:

- apparently call back handles should be explicitly freed with a special
vpi call after registering;
- at a certain point the code malloc's memory in a callback which is
never freed.

As callbacks are created all the time during simulation, this could
explain it. I will run a check with Icarus to see if I can
reproduce/resolve the issue.

> Also, you said some time ago that you were able to use a ModelSim license. Have
> you made some progress? 

To be honest not - during the past months I have been able to spend
much less development time than anticipated. The time I had was spent
on improving the "infrastructure". I want to make it much easier
for others to participate in the project (especially website and
documentation) so that it depends less on me (and my delays :-)).
Nothing released yet, but it will become much better.

 > Do you plan to release a VHDL PLI for using MyHDL with
> ModelSim in the near future?

I want it definitely. After releasing the new website, this will
be my first goal. I'm not sure wether I'll still have access,
if it is really true that the code from Icarus works unchanged,
there may be other possibilities as suggested earlier.

Jan

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

[myhdl-list] MyHDL / ModelSim cosim

[David B. <dav...@fr...>]

Jan,

I tried using one of the PLI C code you published for Icarus and running =
it with
ModelSim. It works fine except that VSIM application gets bigger and bigg=
er in
the system, as if there was a memory leakage. I didn't notice it at the
beginning but for very long simulations, which contain a lot of I/F signa=
ls
between MyHDL and ModelSim (around 300), ModelSim just crashes.
Have you noticed it with Icarus or CVER too? Any clue about the cause of =
it?
Also, you said some time ago that you were able to use a ModelSim license=
. Have
you made some progress? Do you plan to release a VHDL PLI for using MyHDL=
 with
ModelSim in the near future?

Regards,

David.

[myhdl-list] Re: MyHDL Enhancement/Evolution Proposals

[Jean D. <jea...@un...>]

Jan Decaluwe a écrit :
> Jean Demartini wrote:
> 
>> Hi all,
>>
>> I suggest to open a thread dedicated to proposals to enhanced or 
>> modify the semantics of MyHDL. This thread can function following the 
>> model of the internet RFC or the Python PEPs.
>>
>> JDem
> 
> 
> Fine with me - provided I get the role of the
> Benevolent Dicator For Life (BDFL) :-)
> 
> Jan
> 
Personally, I agree.

Jean

[myhdl-list] Re: MyHDL Enhancement/Evolution Proposals

[Jan D. <ja...@ja...>]

Jean Demartini wrote:
> Hi all,
> 
> I suggest to open a thread dedicated to proposals to enhanced or modify 
> the semantics of MyHDL. This thread can function following the model of 
> the internet RFC or the Python PEPs.
> 
> JDem

Fine with me - provided I get the role of the
Benevolent Dicator For Life (BDFL) :-)

Jan

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

[myhdl-list] MyHDL Enhancement/Evolution Proposals

[Jean D. <jea...@un...>]

Hi all,

I suggest to open a thread dedicated to proposals to enhanced or modify 
the semantics of MyHDL. This thread can function following the model of 
the internet RFC or the Python PEPs.

JDem

[myhdl-list] Re: A question of philosophy?

[Jan D. <ja...@ja...>]

Haitao Zhang wrote:
> It seems to me there are three different demands put on HDLs: hardware
> description itself is mostly declarative (in the sense they describe
> structural relationship that can not directly execute on a sequential
> program semantics); but it also has a time axis to it (even though
> hardware can only be structural some times it is more convenient to be
> able to pretend that we can specify it by defining what we want along
> the time axis); AND at times we want to add a imperative component to
> it: think of parameter evaluation, conditional generation, or even
> like myhdl that natively supports simulation. There is tension in
> language design if one wants to do all three well. The "normal" HDLs
> lack a strong support for the last aspect, while Python is a
> inherently sequential language and makes the first (structural) aspect
> harder to carry out (?) without some contortion along the way (the
> tension between declaration, partial eval, and evaluation). I don't
> know if there is a good solution, but I wonder if Jan or anyone else
> has given this question some thoughts.

Yes, I have given these matters lots of thought, but as you raised
an large amount of issues at the same time, I found it hard to
formulate an answer with a size suited for posting :-)

Let me only say this. I don't think there is an essential semantic
difference in the sense you refer to, between traditional HDLs
and MyHDL. The essential need is massive light-weight parallelism.
For this purpose, Python generators are just fine. Structure is
simply what you build on top of that, with more or less syntactic sugar.

The essential contribution of MyHDL as I see it, is that is a HDL
with "scripting power". In better words, it is a very high-level,
dynamically typed language. Whether this is actually relevant for
hardware design remains to be proven, but I think so. In other
computing domains it is; if not, we wouldn't be using any Perl,
Python, Ruby, tcl, or php, but we would use C++ or Java for
everything.

My final remark is about "sequential" statements. It seems to
me that you fall into the classic HDL trap of mixing two
completely different meanings of the word. In hardware,
"sequential" means "clocked" or "along the time axis".
The opposite is "combinatorial". However, in a computer program,
it refers to the relevance of the order of the statements.
Here, a synonym is "procedural" (preferred) and the opposite
is "declarative".

My point is that these two meanings of the same word
have little to do with each other. For example: in HDL design,
the easiest way to describe a combinatorial (= non-sequential)
function, is often a procedural (= sequential) description.
It is no coincidence that all HDLs that really became popular
(such as Verilog and VHDL) have strong support for procedural
descriptions.

Regards, Jan

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

[myhdl-list] Re: VCD viewer ?

[Jan D. <ja...@ja...>]

Jean Demartini wrote:

>>
> Thanks for all this information.
> I will modify _Signal.py and _traceSignals.py accordingly trying to 
> maintain compatibility between GTKwave and WaveVCD.
> 
> I will then inform the forum of the progress.
> 
> Jean

Great. For the case of integer and float, I think we agree
that we should use "native" VCD support, but that it should
be done through a type check. For the integer case, I would
add a value check (< 2**32, and raise an error otherwise).

Jan

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

[myhdl-list] Re: VCD viewer ?

[Jean D. <jea...@un...>]

Jan Decaluwe a écrit :
> Jean Demartini wrote:
> 
>> I'm a little newbie in Python and some Python idiom's are a little 
>> puzzling. Then my question:
>>
>> Why an enum variable is not a true class testable by 
>> isinstance(..,Enum) ? this will simplify the catching of enum 
>> variables in _Signal.py.
>>
>> Jean
> 
> 
> I see your point, and I agree.
> 
> Probably the "idiom" that puzzles you is the usage of the "nested"
> classes EnumItem and Enum in function enum in module _enum.py.
> This looks rather strange: my intention was to make sure these
> auxiliary classes are not directly usable by a user. But there
> are other ways to achieve that, such as giving them a "private"
> name, starting with underscore.
> 
> You are correct in stating that these objects should be
> indentifiable by an instance check. This can be achieved easily
> by using a "dummy" parent class, whose sole purpose is to be
> subclassable by the actual (private) Enum class. This can be
> done as follows (untested):
> 
> In _enum.py, create a new EnumType class at the module level:
> 
>     class EnumType(object):
>         pass
> 
> Subclass the private Enum class from EnumType instead of object:
> 
>     class Enum(EnumType):
>         ....
> 
> Make the EnumType class visible in __init__.py:
> 
>     from _enum import EnumType
> 
> Now you can use it with:
> 
>    from myhdl import EnumType
> 
> and things like isinstance(obj, EnumType) should work.
> 
> Regards,
> 
> Jan
> 
Thanks for all this information.
I will modify _Signal.py and _traceSignals.py accordingly trying to 
maintain compatibility between GTKwave and WaveVCD.

I will then inform the forum of the progress.

Jean

[myhdl-list] Re: VCD viewer ?

[Jan D. <ja...@ja...>]

Jean Demartini wrote:

> I'm a little newbie in Python and some Python idiom's are a little 
> puzzling. Then my question:
> 
> Why an enum variable is not a true class testable by isinstance(..,Enum) 
> ? this will simplify the catching of enum variables in _Signal.py.
> 
> Jean

I see your point, and I agree.

Probably the "idiom" that puzzles you is the usage of the "nested"
classes EnumItem and Enum in function enum in module _enum.py.
This looks rather strange: my intention was to make sure these
auxiliary classes are not directly usable by a user. But there
are other ways to achieve that, such as giving them a "private"
name, starting with underscore.

You are correct in stating that these objects should be
indentifiable by an instance check. This can be achieved easily
by using a "dummy" parent class, whose sole purpose is to be
subclassable by the actual (private) Enum class. This can be
done as follows (untested):

In _enum.py, create a new EnumType class at the module level:

     class EnumType(object):
         pass

Subclass the private Enum class from EnumType instead of object:

     class Enum(EnumType):
         ....

Make the EnumType class visible in __init__.py:

     from _enum import EnumType

Now you can use it with:

    from myhdl import EnumType

and things like isinstance(obj, EnumType) should work.

Regards,

Jan

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

[myhdl-list] Re: VCD viewer ?

[Jean D. <jea...@un...>]

Jan Decaluwe a écrit :
> Jean Demartini wrote:
> 
>> Jean DEMARTINI a écrit :
>>
>>> Hi all,
>>>
>>> For many reasons I've to use MyHDL on a Windows platform (XP SP2). 
>>> Python and MyHDL works perfectly. But has anyone knowledge of a 
>>> working free VCD viewer onto Windows. Despite many effort, I've not 
>>> succeded to use GTKwave and Wavevcd from ISS (beta downloadable at 
>>> www.iss-us.com) does not recognize the VCD format generated by MyHDL 
>>> (its is a drawback of the ISS viewer as the VCD format generated by 
>>> MyDHL is quite correct) .
>>>
>>> Jean
>>>
>>>
>>
>> ISS has just release a new version of its free Wave VCD viewer 
>> (http://www.iss-us.com/wavevcd/). This viewer functions quite properly 
>> but is only conformant with IEEE VCD std. To generate such VCD files, 
>> it is necessary to modifie:
>> _Signal.py
>> _traceSignals.py
>>
>> Enclosed are a modified version of these files. Testing is in progress 
>> and these files are given as it.
> 
> 
> In _traceSignal.py, I had expected a type check to differentiate
> between the various types - instead this is done by checking the
> bit width. Doesn't this mean that a reg of width 32 or 64 would
> be declared as an int or a float ??
> 
> Jan

Yes.

It is in memory of the (not so) old ineger size (32 bits) and the IEEE 
float size (64 bits).
It could be now probably better to introduce a "true" type checking. But 
as it was the 1st time I was "intruding" in your code, I prefered not to 
modify its structure. Then the trick.

A more deep modification has been done in _Signal.py code to track enum 
variables. The default _printVcd() method is no more for strings but for 
an integer which is the _index attribute of the val of an (potentially) 
enum variable. It seems that this default case is invocated only in this 
case.

I'm a little newbie in Python and some Python idiom's are a little 
puzzling. Then my question:

Why an enum variable is not a true class testable by isinstance(..,Enum) 
? this will simplify the catching of enum variables in _Signal.py.

Jean

[myhdl-list] Re: VCD viewer ?

[Jan D. <ja...@ja...>]

Jean Demartini wrote:
> Jean DEMARTINI a écrit :
> 
>> Hi all,
>>
>> For many reasons I've to use MyHDL on a Windows platform (XP SP2). 
>> Python and MyHDL works perfectly. But has anyone knowledge of a 
>> working free VCD viewer onto Windows. Despite many effort, I've not 
>> succeded to use GTKwave and Wavevcd from ISS (beta downloadable at 
>> www.iss-us.com) does not recognize the VCD format generated by MyHDL 
>> (its is a drawback of the ISS viewer as the VCD format generated by 
>> MyDHL is quite correct) .
>>
>> Jean
>>
>>
> 
> ISS has just release a new version of its free Wave VCD viewer 
> (http://www.iss-us.com/wavevcd/). This viewer functions quite properly 
> but is only conformant with IEEE VCD std. To generate such VCD files, it 
> is necessary to modifie:
> _Signal.py
> _traceSignals.py
> 
> Enclosed are a modified version of these files. Testing is in progress 
> and these files are given as it.

In _traceSignal.py, I had expected a type check to differentiate
between the various types - instead this is done by checking the
bit width. Doesn't this mean that a reg of width 32 or 64 would
be declared as an int or a float ??

Jan


> 
> vcd-test.py is a modified version of the examle given in the tutorial 
> and tb_fsm.vcd is the generated VCD file.
> 
> Warning: enum type has not been modified. Then states are denoted by 
> integers ans no more by strings.
> 
> Hope this helps.
> JDem
> 
> 
> ------------------------------------------------------------------------
> 
> #  This file is part of the myhdl library, a Python package for using
> #  Python as a Hardware Description Language.
> #
> #  Copyright (C) 2003 Jan Decaluwe
> #
> #  The myhdl library is free software; you can redistribute it and/or
> #  modify it under the terms of the GNU Lesser General Public License as
> #  published by the Free Software Foundation; either version 2.1 of the
> #  License, or (at your option) any later version.
> #
> #  This library is distributed in the hope that it will be useful, but
> #  WITHOUT ANY WARRANTY; without even the implied warranty of
> #  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> #  Lesser General Public License for more details.
> #
> #  You should have received a copy of the GNU Lesser General Public
> #  License along with this library; if not, write to the Free Software
> #  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> #
> ########################
> #
> #   modified by Jean DEMARTINI to generate true std. IEEE VCD files
> #   modified or inserted instruction are shown by a comment like # XXXXX ---- JDM
> #
> #   these modifcations are only partly tested. Their effects on Verilog generation
> #   has not been tested.
> 
> """ myhdl traceSignals module.
> 
> """
> 
> __author__ = "Jan Decaluwe <ja...@ja...>"
> __revision__ = "$Revision: 1.20 $"
> __date__ = "$Date: 2004/09/23 20:38:07 $"
> 
> import sys
> from inspect import currentframe, getouterframes
> import time
> import os
> path = os.path
> import shutil
> from sets import Set
> 
> from myhdl import _simulator, Signal, __version__
> from myhdl._util import _isGenFunc
> from myhdl._isGenSeq import _isGenSeq
> from myhdl._extractHierarchy import _findInstanceName, _HierExtr
> from myhdl import TraceSignalsError
> 
> _tracing = 0
> _profileFunc = None
> 
> class _error:
>     pass
> _error.TopLevelName = "result of traceSignals call should be assigned to a top level name"
> _error.ArgType = "traceSignals first argument should be a classic function"
> _error.MultipleTraces = "Cannot trace multiple instances simultaneously"
> 
> def traceSignals(dut, *args, **kwargs):
>     global _tracing
>     if _tracing:
>         return dut(*args, **kwargs) # skip
>     else:
>         # clean start
>         sys.setprofile(None)
>     from myhdl._toVerilog import _convert
>     if _convert._converting:
>         raise TraceSignalsError("Cannot use traceSignals while converting to Verilog")
>     if not callable(dut):
>         raise TraceSignalsError(_error.ArgType, "got %s" % type(dut))
>     if _simulator._tracing:
>         raise TraceSignalsError(_error.MultipleTraces)
>     
>     _tracing = 1
>     try:
>         outer = getouterframes(currentframe())[1]
>         name = _findInstanceName(outer)
>         if name is None:
>             raise TraceSignalsError(_error.TopLevelName)
>         h = _HierExtr(name, dut, *args, **kwargs)
>         vcdpath = name + ".vcd"
>         if path.exists(vcdpath):
>             backup = vcdpath + '.' + str(path.getmtime(vcdpath))
>             shutil.copyfile(vcdpath, backup)
>             os.remove(vcdpath)
>         vcdfile = open(vcdpath, 'w')
>         _simulator._tracing = 1
>         _simulator._tf = vcdfile
>         _writeVcdHeader(vcdfile)
>         _writeVcdSigs(vcdfile, h.hierarchy)
>     finally:
>         _tracing = 0
>         
>     return h.top
> 
> 
> _codechars = ""
> for i in range(33, 127):
>     _codechars += chr(i)
> _mod = len(_codechars)
> 
> def _genNameCode():
>     n = 0
>     while 1:
>         yield _namecode(n)
>         n += 1
>         
> def _namecode(n):
>     q, r = divmod(n, _mod)
>     code = _codechars[r]
>     while q > 0:
>         q, r = divmod(q, _mod)
>         code = _codechars[r] + code
>     return code
> 
> def _writeVcdHeader(f):
>     print >> f, "$date"
>     print >> f, "    %s" % time.asctime()
>     print >> f, "$end"
>     print >> f, "$version"
>     print >> f, "    MyHDL %s" % __version__
>     print >> f, "$end"
>     print >> f, "$timescale"
>     print >> f, "    1ns"
>     print >> f, "$end"
>     print >> f
> 
> def _writeVcdSigs(f, hierarchy):
>     curlevel = 0
>     namegen = _genNameCode()
>     siglist = []
>     for level, name, sigdict in hierarchy:
>         delta = curlevel - level
>         curlevel = level
>         assert(delta >= -1)
>         if delta >= 0:
>             for i in range(delta + 1):
>                 print >> f, "$upscope $end"
>         print >> f, "$scope module %s $end" % name
>         for n, s in sigdict.items():
>             if not s._tracing:
>                 s._tracing = 1
>                 s._code = namegen.next()
>                 siglist.append(s)
>             w = s._nrbits
>             if w:
>                 if w == 1:
>                     print >> f, "$var reg 1 %s %s $end" % (s._code, n)                      # single bit ------------- JDM
>                 elif w == 32:
>                     print >> f, "$var integer %s %s %s $end" % (w, s._code, n)              # integer    ------------- JDM
>                 elif w == 64:
>                     print >> f, "$var real %s %s %s $end" % (w, s._code, n)                 # float      ------------- JDM
>                 else:
>                     print >> f, "$var reg %s %s %s[%s:0] $end" % (w, s._code, n, w-1)       # register   ------------- JDM
>             else:
>                 raise ValueError("Unexpected type, got %s" % w)                             # error      ------------- JDM
>     for i in range(curlevel):
>         print >> f, "$upscope $end"
>     print >> f
>     print >> f, "$enddefinitions $end"
>     print >> f, "$dumpvars"
>     for s in siglist:
>         s._printVcd() # initial value
>     print >> f, "$end"
>             
>             
>         
>         
> 
> 
>     
>     
> 
>             
>         
>     
>     
> 
> 
> ------------------------------------------------------------------------
> 
> #  This file is part of the myhdl library, a Python package for using
> #  Python as a Hardware Description Language.
> #
> #  Copyright (C) 2003 Jan Decaluwe
> #
> #  The myhdl library is free software; you can redistribute it and/or
> #  modify it under the terms of the GNU Lesser General Public License as
> #  published by the Free Software Foundation; either version 2.1 of the
> #  License, or (at your option) any later version.
> #
> #  This library is distributed in the hope that it will be useful, but
> #  WITHOUT ANY WARRANTY; without even the implied warranty of
> #  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> #  Lesser General Public License for more details.
> 
> #  You should have received a copy of the GNU Lesser General Public
> #  License along with this library; if not, write to the Free Software
> #  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> #
> ########################
> #
> #   modified by Jean DEMARTINI to generate true std. IEEE VCD files
> #   modified or inserted instruction are shown by a comment like # XXXXX ---- JDM
> #
> #   these modifcations are only partly tested. Their effects on Verilog generation
> #   has not been tested.
> 
> """ Module that provides the Signal class and related objects.
> 
> This module provides the following objects:
> 
> Signal -- class to model hardware signals
> posedge -- callable to model a rising edge on a signal in a yield statement
> negedge -- callable to model a falling edge on a signal in a yield statement
> 
> """
> __author__ = "Jan Decaluwe <ja...@ja...>"
> __revision__ = "$Revision: 1.25 $"
> __date__ = "$Date: 2004/12/27 12:31:47 $"
> 
> from inspect import currentframe, getouterframes
> from copy import deepcopy as copy
> 
> from myhdl import _simulator as sim
> from myhdl._simulator import _siglist, _futureEvents, now
> from myhdl._Waiter import _WaiterList
> from myhdl._intbv import intbv
> from myhdl._bin import bin
> 
> _schedule = _futureEvents.append
>         
> 
> def posedge(sig):
>     """ Return a posedge trigger object """
>     return sig.posedge
> 
> def negedge(sig):
>     """ Return a negedge trigger object """
>     return sig.negedge
> 
> class Signal(object):
> 
>     """ Signal class.
> 
>     Properties:
>     val -- current value (read-only)
>     next -- next value (read-write)
> 
>     """
> 
>     __slots__ = ('_next', '_val', '_min', '_max', '_type', 
>                  '_eventWaiters', '_posedgeWaiters', '_negedgeWaiters',
>                  '_code', '_tracing', '_nrbits', '_checkVal', '_setNextVal',
>                  '_printVcd', '_driven' ,'_read', '_name'
>                 )
> 
>     def __new__(cls, val=None, delay=None):
>         """ Return a new Signal (default or delay 0) or DelayedSignal """
>         if delay is not None:
>             if delay < 0:
>                 raise TypeError("Signal: delay should be >= 0")
>             return object.__new__(DelayedSignal)
>         else:
>             return object.__new__(cls)
> 
>     def __init__(self, val=None):
>         """ Construct a signal.
> 
>         val -- initial value
>         
>         """
>         self._next = self._val = val
>         self._min = self._max = None
>         self._name = self._read = self._driven = None
>         self._nrbits = 0
>         self._printVcd = self._printVcdStr
>         if isinstance(val, bool):
>             self._type = bool
>             self._setNextVal = self._setNextBool
>             self._printVcd = self._printVcdBit
>             self._nrbits = 1
>         elif isinstance(val, (int, long)):
>             self._type = (int, long)
>             self._setNextVal = self._setNextInt
>             self._nrbits = 32                       # ------------- JDM
>             self._printVcd = self._printVcdInt      # ------------- JDM
>         elif isinstance(val, float):                # ------------- JDM
>             self._type = float                      # ------------- JDM
>             self._setNextVal = self._setNextReal    # ------------- JDM
>             self._nrbits = 64                       # ------------- JDM
>             self._printVcd = self._printVcdReal     # ------------- JDM
>         elif isinstance(val, intbv):
>             self._type = intbv
>             self._min = val._min
>             self._max = val._max
>             self._nrbits = val._nrbits
>             self._setNextVal = self._setNextIntbv
>             if self._nrbits:
>                 self._printVcd = self._printVcdVec
>             else:
>                 self._printVcd = self._printVcdHex
>         elif val is None:
>             self._type = None
>             self._setNextVal = self._setNext
>         else:
>             self._type = type(val)
>             self._setNextVal = self._setNextType
>             if hasattr(val, '_nrbits'):
>                 self._nrbits = val._nrbits
>         self._eventWaiters = _WaiterList()
>         self._posedgeWaiters = _WaiterList()
>         self._negedgeWaiters = _WaiterList()
>         self._code = ""
>         self._tracing = 0
>         
>     def _update(self):
>         val, next = self._val, self._next
>         if val != next:
>             waiters = self._eventWaiters[:]
>             del self._eventWaiters[:]
>             if not val and next:
>                 waiters.extend(self._posedgeWaiters[:])
>                 del self._posedgeWaiters[:]
>             elif not next and val:
>                 waiters.extend(self._negedgeWaiters[:])
>                 del self._negedgeWaiters[:]
>             self._val = next
>             if self._tracing:
>                 self._printVcd()
>             return waiters
>         else:
>             return []
> 
>     # support for the 'val' attribute
>     def _get_val(self):
>         return self._val
>     val = property(_get_val, None, None, "'val' access methods")
> 
>     # support for the 'next' attribute
>     def _get_next(self):
>         if self._next is self._val:
>             self._next = copy(self._val)
>         _siglist.append(self)
>         return self._next
>     def _set_next(self, val):
>         if isinstance(val, Signal):
>             val = val._val
>         self._setNextVal(val)
>         _siglist.append(self)
>     next = property(_get_next, _set_next, None, "'next' access methods")
> 
>     # support for the 'posedge' attribute
>     def _get_posedge(self):
>         return self._posedgeWaiters
>     posedge = property(_get_posedge, None, None, "'posedge' access methods")
>                        
>     # support for the 'negedge' attribute
>     def _get_negedge(self):
>         return self._negedgeWaiters
>     negedge = property(_get_negedge, None, None, "'negedge' access methods")
>     
>     # support for the 'min' and 'max' attribute
>     def _get_max(self):
>         return self._max
>     max = property(_get_max, None)
>     def _get_min(self):
>         return self._min
>     min = property(_get_min, None)
> 
>     # set next methods
>     def _setNextBool(self, val):
>         if not val in (0, 1):
>             raise ValueError("Expected value 0 or 1, got %s" % val)
>         self._next = val
> 
>     def _setNextInt(self, val):
>         if not isinstance(val, (int, long, intbv)):
>             raise TypeError("Expected int or intbv, got %s" % type(val))
>         self._next = val
> 
>     def _setNextReal(self, val):
>         if not isinstance(val, float):
>             raise TypeError("Expected float, got %s" % type(val))
>         self._next = val
>         
>     def _setNextIntbv(self, val):
>         if isinstance(val, intbv):
>             val = val._val
>         elif not isinstance(val, (int, long)):
>             raise TypeError("Expected int or intbv, got %s" % type(val))
>         if self._next is self._val:
>             self._next = copy(self._val)
>         self._next._val = val
>         self._next._checkBounds()
> 
>     def _setNextType(self, val):
>         if not isinstance(val, self._type):
>             raise TypeError("Expected %s, got %s" % (self._type, type(val)))
>         self._next = val
>         
>     def _setNext(self, val):
>         self._next = val
> 
>     # vcd print methods
>     def _printVcdReal(self):
>         print >> sim._tf, "R%.16g%s" % (self._val, self._code)      # --------------- JDM
>         
>     def _printVcdInt(self):
>         print >> sim._tf, "B%s%s" % (bin(self._val,32), self._code) # --------------- JDM
>         
>     def _printVcdStr(self):
>         print >> sim._tf, "s%s %s" % (str(self._val), self._code)
>         
>     def _printVcdHex(self):
>         print >> sim._tf, "s%s %s" % (hex(self._val), self._code)
> 
>     def _printVcdBit(self):
>         print >> sim._tf, "%d%s" % (self._val, self._code)
> 
>     def _printVcdVec(self):
>         print >> sim._tf, "b%s %s" % (bin(self._val, self._nrbits), self._code)
> 
>     ### operators for which delegation to current value is appropriate ###
>         
>     # hashing (?)
>     def __hash__(self):
>         return hash(self._val)
>         
>     
>     def __nonzero__(self):
>         if self._val:
>             return 1
>         else:
>             return 0
> 
>     # length
>     def __len__(self):
>         return len(self._val)
> 
>     # indexing and slicing methods
> 
>     def __getitem__(self, key):
>         return self._val[key]
>         
>     # integer-like methods
> 
>     def __add__(self, other):
>         if isinstance(other, Signal):
>             return self._val + other._val
>         else:
>             return self._val + other
>     def __radd__(self, other):
>         return other + self._val
>     
>     def __sub__(self, other):
>         if isinstance(other, Signal):
>             return self._val - other._val
>         else:
>             return self._val - other
>     def __rsub__(self, other):
>         return other - self._val
> 
>     def __mul__(self, other):
>         if isinstance(other, Signal):
>             return self._val * other._val
>         else:
>             return self._val * other
>     def __rmul__(self, other):
>         return other * self._val
> 
>     def __div__(self, other):
>         if isinstance(other, Signal):
>             return self._val / other._val
>         else:
>             return self._val / other
>     def __rdiv__(self, other):
>         return other / self._val
>     
>     def __truediv__(self, other):
>         if isinstance(other, Signal):
>             return operator.truediv(self._val, other._val)
>         else:
>             return operator.truediv(self._val, other)
>     def __rtruediv__(self, other):
>         return operator.truediv(other, self._val)
>     
>     def __floordiv__(self, other):
>         if isinstance(other, Signal):
>             return self._val // other._val
>         else:
>             return self._val // other
>     def __rfloordiv__(self, other):
>         return other //  self._val
>     
>     def __mod__(self, other):
>         if isinstance(other, Signal):
>             return self._val % other._val
>         else:
>             return self._val % other
>     def __rmod__(self, other):
>         return other % self._val
> 
>     # XXX divmod
>     
>     def __pow__(self, other):
>         if isinstance(other, Signal):
>             return self._val ** other._val
>         else:
>             return self._val ** other
>     def __rpow__(self, other):
>         return other ** self._val
> 
>     def __lshift__(self, other):
>         if isinstance(other, Signal):
>             return self._val << other._val
>         else:
>             return self._val << other
>     def __rlshift__(self, other):
>         return other << self._val
>             
>     def __rshift__(self, other):
>         if isinstance(other, Signal):
>             return self._val >> other._val
>         else:
>             return self._val >> other
>     def __rrshift__(self, other):
>         return other >> self._val
>            
>     def __and__(self, other):
>         if isinstance(other, Signal):
>             return self._val & other._val
>         else:
>             return self._val & other
>     def __rand__(self, other):
>         return other & self._val
> 
>     def __or__(self, other):
>         if isinstance(other, Signal):
>             return self._val | other._val
>         else:
>             return self._val | other
>     def __ror__(self, other):
>         return other | self._val
>     
>     def __xor__(self, other):
>         if isinstance(other, Signal):
>             return self._val ^ other._val
>         else:
>             return self._val ^ other
>     def __rxor__(self, other):
>         return other ^ self._val
>     
>     def __neg__(self):
>         return -self._val
> 
>     def __pos__(self):
>         return +self._val
> 
>     def __abs__(self):
>         return abs(self._val)
> 
>     def __invert__(self):
>         return ~self._val
>         
>     # conversions
>     
>     def __int__(self):
>         return int(self._val)
>         
>     def __long__(self):
>         return long(self._val)
> 
>     def __float__(self):
>         return float(self._val)
>     
>     def __oct__(self):
>         return oct(self._val)
>     
>     def __hex__(self):
>         return hex(self._val)
> 
> 
>     # comparison
>     def __cmp__(self, other):
>         return cmp(self._val, other)
> 
>     # representation 
>     def __str__(self):
>         return str(self._val)
> 
>     def __repr__(self):
>         return "Signal(" + repr(self._val) + ")"
> 
>     # augmented assignment not supported
>     def _augm(self):
>         raise TypeError, "Signal object doesn't support augmented assignment"
> 
>     __iadd__ = __isub__ = __idiv__ = __imul__ = __ipow__ = __imod__ = _augm
>     __ior__ = __iand__ = __ixor__ = __irshift__ = __ilshift__ = _augm
> 
>     # index and slice assignment not supported
>     def __setitem__(self, key, val):
>         raise TypeError, "Signal object doesn't support item/slice assignment"
> 
> 
> class DelayedSignal(Signal):
>     
>     __slots__ = ('_nextZ', '_delay', '_timeStamp',
>                 )
> 
>     def __init__(self, val=None, delay=1):
>         """ Construct a new DelayedSignal.
> 
>         Automatically invoked through the Signal new method.
>         val -- initial value
>         delay -- non-zero delay value
>         """
>         Signal.__init__(self, val)
>         self._nextZ = val
>         self._delay = delay
>         self._timeStamp = 0
> 
>     def _update(self):
>         if self._next != self._nextZ:
>             self._timeStamp = sim._time
>         self._nextZ = self._next
>         t = sim._time + self._delay
>         _schedule((t, _SignalWrap(self, self._next, self._timeStamp)))
>         return []
> 
>     def _apply(self, next, timeStamp):
>         val = self._val
>         if timeStamp == self._timeStamp and val != next:
>             waiters = self._eventWaiters[:]
>             del self._eventWaiters[:]
>             if not val and next:
>                 waiters.extend(self._posedgeWaiters[:])
>                 del self._posedgeWaiters[:]
>             elif not next and val:
>                 waiters.extend(self._negedgeWaiters[:])
>                 del self._negedgeWaiters[:]
>             self._val = copy(next)
>             if self._tracing:
>                 self._printVcd()
>             return waiters            
>         else:
>             return []
> 
>    # support for the 'delay' attribute
>     def _get_delay(self):
>          return self._delay
>     def _set_delay(self, delay):
>          self._delay = delay
>     delay = property(_get_delay, _set_delay, None, "'delay' access methods")
> 
>         
> class _SignalWrap(object):
>     def __init__(self, sig, next, timeStamp):
>         self.sig = sig
>         self.next = next
>         self.timeStamp = timeStamp
>     def apply(self):
>         return self.sig._apply(self.next, self.timeStamp)
> 
>    
> 
> 
> ------------------------------------------------------------------------
> 
> # essai VCD from example found in tutorial
> # slightly modified to generated a std. IEEE VCD file
> #
> # by: Jean DEMARTINI
> #
> from myhdl import *
> 
> ACTIVE_LOW = 0
> FRAME_SIZE = 8
> #t_State = enum('SEARCH','CONFIRM','SYNC')
> SEARCH = 0
> CONFIRM = 1
> SYNC = 2
> 
> def FrameCtrl(SOF,state,syncFlag,clk,reset_n):
>     index = Signal(0)
>     
>     def FSM():
>         while 1:
>             yield posedge(clk),negedge(reset_n)
>             
>             if reset_n == ACTIVE_LOW:
>                 SOF.next = 0
>                 index.next = 0
>                 state.next = SEARCH #t_State.SEARCH
>             else:
>                 index.next = (index+1)%FRAME_SIZE
>                 SOF.next = 0
>                 
>                 if state == SEARCH: #t_State.SEARCH:
>                     index.next = 1
>                     if syncFlag:
>                         state.next = CONFIRM #t_State.CONFIRM
>                 elif state == CONFIRM: #t_State.CONFIRM:
>                     if index == 0:
>                         if syncFlag:
>                             state.next = SYNC #t_State.SYNC
>                         else:
>                             state.next = SEARCH #t_State.SEARCH
>                 elif state == SYNC: #t_State.SYNC:
>                     if index == 0:
>                         if not syncFlag:
>                             state.next = SEARCH #t_State.SEARCH
>                     SOF.next = (index == FRAME_SIZE-1)
>                 else:
>                     raise ValueError("Undefined state")
>     return FSM()
>         
> def testbench():
>     SOF = Signal(bool(0))
>     syncFlag = Signal(bool(0))
>     clk = Signal(bool(0))
>     reset_n = Signal(bool(1))
>     state = Signal(SEARCH) #Signal(t_State.SEARCH)
>     
>     frameCtrl = FrameCtrl(SOF,state,syncFlag,clk,reset_n)
>     
>     def clkgen():
>         while 1:
>             yield delay(10)
>             clk.next = not clk
>             
>     def stimulus():
>         for i in range(3):
>             yield posedge(clk)
>         for n in (12,8,8,4):
>             syncFlag.next = 1
>             yield posedge(clk)
>             syncFlag.next = 0
>             for i in range(n-1):
>                 yield posedge(clk)
>         raise StopSimulation
>         
>     return frameCtrl,clkgen(),stimulus()
>         
> tb_fsm = traceSignals(testbench)
> 
> sim = Simulation(tb_fsm)
> sim.run()
> 
>     
> 
> 
> ------------------------------------------------------------------------
> 
> $date
>     Wed Apr 20 10:01:48 2005
> $end
> $version
>     MyHDL 0.4.1
> $end
> $timescale
>     1ns
> $end
> 
> $scope module tb_fsm $end
> $var reg 1 ! reset_n $end
> $var integer 32 " state $end
> $var reg 1 # clk $end
> $var reg 1 $ syncFlag $end
> $var reg 1 % SOF $end
> $scope module frameCtrl $end
> $var integer 32 & index $end
> $var reg 1 # clk $end
> $var reg 1 % SOF $end
> $var integer 32 " state $end
> $var reg 1 ! reset_n $end
> $var reg 1 $ syncFlag $end
> $upscope $end
> $upscope $end
> 
> $enddefinitions $end
> $dumpvars
> 1!
> B00000000000000000000000000000000"
> 0#
> 0$
> 0%
> B00000000000000000000000000000000&
> $end
> #10
> 1#
> B00000000000000000000000000000001&
> #20
> 0#
> #30
> 1#
> #40
> 0#
> #50
> 1#
> 1$
> #60
> 0#
> #70
> 1#
> 0$
> B00000000000000000000000000000001"
> #80
> 0#
> #90
> 1#
> B00000000000000000000000000000010&
> #100
> 0#
> #110
> 1#
> B00000000000000000000000000000011&
> #120
> 0#
> #130
> 1#
> B00000000000000000000000000000100&
> #140
> 0#
> #150
> 1#
> B00000000000000000000000000000101&
> #160
> 0#
> #170
> 1#
> B00000000000000000000000000000110&
> #180
> 0#
> #190
> 1#
> B00000000000000000000000000000111&
> #200
> 0#
> #210
> 1#
> B00000000000000000000000000000000&
> #220
> 0#
> #230
> 1#
> B00000000000000000000000000000001&
> B00000000000000000000000000000000"
> #240
> 0#
> #250
> 1#
> #260
> 0#
> #270
> 1#
> #280
> 0#
> #290
> 1#
> 1$
> #300
> 0#
> #310
> 1#
> 0$
> B00000000000000000000000000000001"
> #320
> 0#
> #330
> 1#
> B00000000000000000000000000000010&
> #340
> 0#
> #350
> 1#
> B00000000000000000000000000000011&
> #360
> 0#
> #370
> 1#
> B00000000000000000000000000000100&
> #380
> 0#
> #390
> 1#
> B00000000000000000000000000000101&
> #400
> 0#
> #410
> 1#
> B00000000000000000000000000000110&
> #420
> 0#
> #430
> 1#
> B00000000000000000000000000000111&
> #440
> 0#
> #450
> 1#
> B00000000000000000000000000000000&
> 1$
> #460
> 0#
> #470
> 1#
> 0$
> B00000000000000000000000000000001&
> B00000000000000000000000000000010"
> #480
> 0#
> #490
> 1#
> B00000000000000000000000000000010&
> #500
> 0#
> #510
> 1#
> B00000000000000000000000000000011&
> #520
> 0#
> #530
> 1#
> B00000000000000000000000000000100&
> #540
> 0#
> #550
> 1#
> B00000000000000000000000000000101&
> #560
> 0#
> #570
> 1#
> B00000000000000000000000000000110&
> #580
> 0#
> #590
> 1#
> B00000000000000000000000000000111&
> #600
> 0#
> #610
> 1#
> B00000000000000000000000000000000&
> 1%
> 1$
> #620
> 0#
> #630
> 1#
> 0$
> B00000000000000000000000000000001&
> 0%
> #640
> 0#
> #650
> 1#
> B00000000000000000000000000000010&
> #660
> 0#
> #670
> 1#
> B00000000000000000000000000000011&
> #680
> 0#
> #690
> 1#


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

[myhdl-list] Re: VCD viewer ?

[Jan D. <ja...@ja...>]

Jean Demartini wrote:
> Hi all,
> 
> ISS (www.iss-us.com) has released a new version of its Wave VCD viewer. 
> This version functions quite properly... But the VCD files generated by 
> the traceSignals method are not strictly conformant to the IEEE specs 
> and some tools cannot parse these VCD files.
> 
> Some points:
> 1 - the declaration of a reg with a size > 1 is incorrect It lacks the 
> slice declaration. Ex. "$var reg 2 state[1:0] $end" is the correct 
> declaration instead of "$var reg 2 state $end". This point is easy to 
> solve in _traceSignals.py file.

Yes, looking at the original code it seems that something was
missing (the code makes a difference for the case size = 1 and
size > 1, but then does the same thing).

You mention the "VCD standard", do you have a reference for this? I
remember looking for a "standard" during implementation, but I only
found examples and explanations.

> 2 - the integer variable are declared as real 1 and then translated to 
> strings such as sXX and that is not allowed in VCD format. This point 
> too is not too difficult to solve by addind the adequate _printVcd 
> method in the signal object: file _Signal.py

The difficulty with integer is that the Python integer has an
"indefinite" bit width while the Verilog integer has a bit width
of 32. The current (non-standard) implementation would address that,
and a straight integer mapping won't. I agree though that this may be
more of a theoretical issue. In fact, the same issue exists already
in the Verilog conversion.

> 3 - It is rather easy, as above, to introduce the management of real 
> variables.

Right.

> 4 - but how to manage the enum variables which are valued by strings ?

Here the issue is that VCD doesn't support it, but the extended VCD
that gtkwave supports does. (This is mentioned in the manual). It is
remarkable that VCD became so popular without support for strings
(and therefore, enums). The best solution may be to support another
format that has this. I know that gtkwave also supports GTX (or GXT?)
but I don't know a lot about it. Does your viewer support other
formats that may be a candidate?

Regards, Jan

> 
> Has somebody an idea ?
> 
> JDem
> 
> Jean Demartini a écrit :
> 
>> Thanks a lot Günter for your help. Finallt GTKwave for Windows 
>> functions properly.
>>
>> For the information a the new users of GTKwave: the executable 
>> winwave.exe has to be launch in a DOS console window and is not an 
>> interactive GUI software. Then a user window is opened.
>>
>> Günter Dannoritzer a écrit :
>>
>>> Hi Jean,
>>>
>>> Jean DEMARTINI wrote:
>>>
>>>> Hi all,
>>>>
>>>> For many reasons I've to use MyHDL on a Windows platform (XP SP2). 
>>>> Python and MyHDL works perfectly. But has anyone knowledge of a 
>>>> working free VCD viewer onto Windows. Despite many effort, I've not 
>>>> succeded to use GTKwave and Wavevcd from ISS (beta downloadable at 
>>>> www.iss-us.com) does not recognize the VCD format generated by MyHDL 
>>>> (its is a drawback of the ISS viewer as the VCD format generated by 
>>>> MyDHL is quite correct) .
>>>>
>>>> Jean
>>>>
>>>>
>>>
>>> Have you looked into GTKWave?
>>>
>>>     http://www.cs.man.ac.uk/apt/tools/gtkwave/
>>>
>>> I have not used it with MyHDL, so I cannot commend on that.
>>>
>>> Here is a page that has a windows version available:
>>>
>>> http://www.geocities.com/SiliconValley/Campus/3216/GTKWave/gtkwave-win32.html 
>>>
>>>
>>> The windows version is an older version, but still works fine. 
>>> Actually I had recently a .vcd file that would work with the older 
>>> version and not with one of the new 2.0 pre releases.
>>>
>>> Hope that helps.
>>>
>>> Guenter
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> 
> 
> 
> 
> -------------------------------------------------------
> 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click


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

[myhdl-list] Re: VCD viewer ?

[Jean D. <jea...@un...>]

Hi all,

Posted included a new version of _Signal.py taking account of enum 
variables. When exported in a VCD file, enum variables are denoted by 
their _index attribute.

I know, its is not a perfect method as it needs that only one enum 
variable is used.

JDem

[myhdl-list] Re: VCD viewer ?

[Jean D. <jea...@un...>]

Jean DEMARTINI a écrit :
> Hi all,
> 
> For many reasons I've to use MyHDL on a Windows platform (XP SP2). 
> Python and MyHDL works perfectly. But has anyone knowledge of a working 
> free VCD viewer onto Windows. Despite many effort, I've not succeded to 
> use GTKwave and Wavevcd from ISS (beta downloadable at www.iss-us.com) 
> does not recognize the VCD format generated by MyHDL (its is a drawback 
> of the ISS viewer as the VCD format generated by MyDHL is quite correct) .
> 
> Jean
> 
> 

ISS has just release a new version of its free Wave VCD viewer 
(http://www.iss-us.com/wavevcd/). This viewer functions quite properly 
but is only conformant with IEEE VCD std. To generate such VCD files, it 
is necessary to modifie:
_Signal.py
_traceSignals.py

Enclosed are a modified version of these files. Testing is in progress 
and these files are given as it.

vcd-test.py is a modified version of the examle given in the tutorial 
and tb_fsm.vcd is the generated VCD file.

Warning: enum type has not been modified. Then states are denoted by 
integers ans no more by strings.

Hope this helps.
JDem

[myhdl-list] Re: VCD viewer ?

[Jean D. <jea...@un...>]

Hi all,

ISS (www.iss-us.com) has released a new version of its Wave VCD viewer. 
This version functions quite properly... But the VCD files generated by 
the traceSignals method are not strictly conformant to the IEEE specs 
and some tools cannot parse these VCD files.

Some points:
1 - the declaration of a reg with a size > 1 is incorrect It lacks the 
slice declaration. Ex. "$var reg 2 state[1:0] $end" is the correct 
declaration instead of "$var reg 2 state $end". This point is easy to 
solve in _traceSignals.py file.

2 - the integer variable are declared as real 1 and then translated to 
strings such as sXX and that is not allowed in VCD format. This point 
too is not too difficult to solve by addind the adequate _printVcd 
method in the signal object: file _Signal.py

3 - It is rather easy, as above, to introduce the management of real 
variables.

4 - but how to manage the enum variables which are valued by strings ?

Has somebody an idea ?

JDem

Jean Demartini a écrit :
> Thanks a lot Günter for your help. Finallt GTKwave for Windows functions 
> properly.
> 
> For the information a the new users of GTKwave: the executable 
> winwave.exe has to be launch in a DOS console window and is not an 
> interactive GUI software. Then a user window is opened.
> 
> Günter Dannoritzer a écrit :
> 
>> Hi Jean,
>>
>> Jean DEMARTINI wrote:
>>
>>> Hi all,
>>>
>>> For many reasons I've to use MyHDL on a Windows platform (XP SP2). 
>>> Python and MyHDL works perfectly. But has anyone knowledge of a 
>>> working free VCD viewer onto Windows. Despite many effort, I've not 
>>> succeded to use GTKwave and Wavevcd from ISS (beta downloadable at 
>>> www.iss-us.com) does not recognize the VCD format generated by MyHDL 
>>> (its is a drawback of the ISS viewer as the VCD format generated by 
>>> MyDHL is quite correct) .
>>>
>>> Jean
>>>
>>>
>>
>> Have you looked into GTKWave?
>>
>>     http://www.cs.man.ac.uk/apt/tools/gtkwave/
>>
>> I have not used it with MyHDL, so I cannot commend on that.
>>
>> Here is a page that has a windows version available:
>>
>> http://www.geocities.com/SiliconValley/Campus/3216/GTKWave/gtkwave-win32.html 
>>
>>
>> The windows version is an older version, but still works fine. 
>> Actually I had recently a .vcd file that would work with the older 
>> version and not with one of the new 2.0 pre releases.
>>
>> Hope that helps.
>>
>> Guenter
>>
>>
>>
>> -------------------------------------------------------
>> 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> 
> 
> 
> 
> -------------------------------------------------------
> 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

[myhdl-list] Re: Generators semantics

[Jan D. <ja...@ja...>]

Jean Demartini wrote:
> Generators used in MyDHL (and Python) ressemble strongly to co-routines 
> used to model some real-time systems.
> 
> Is this view true and relevant or is it false and illusory ?

Without having any hands-on experience with coroutines, I believe this
is true, in the sense that both concepts can emulate light-weight
parallellism.

As I understand it, coroutines are things that pass control to each
other, at certain points. Generators pass control to whatever called
them, in Python with the yield statement.

The way MyHDL uses generators is special in the sense that the behavior
of the "caller" (a.k.a. the Simulation object) is "hidden" from the user.
The Simuulation object acts as a predefined scheduler, suited for hardware
simulations (e.g. achieving determinism in cooperation with Signal objects.)
For the purposes of hardware modelling therefore, I believe the functionality
offered by generators is sufficient.

Best regards,

Jan 

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

[myhdl-list] Generators semantics

[Jean D. <jea...@un...>]

Generators used in MyDHL (and Python) ressemble strongly to co-routines 
used to model some real-time systems.

Is this view true and relevant or is it false and illusory ?
Jdem

[myhdl-list] Re: range object

[Beni C. <cb...@us...>]

Haitao Zhang wrote:
> On Thu, 03 Mar 2005 11:49:08 +0100, Jan Decaluwe <ja...@ja...> wrote:
> 
>>Haitao Zhang wrote:
>>
>>> [...] However in Python the native slicing is limited to integer
>>> arguments (?), so one has to define two named constants instead of
>>> passing an indexing object.
>>
Before Python 2.3, builtin sequences didn't support slice objects (which also 
means they didn't support slicing with a step - ``a[start:stop:step]``).   In 
2.3 and later it works.  But behavior of builtin sequence types doesn't say 
anything about the behavior of `intbv`.

>>This is not correct. Consider:
>>
>>>>>from myhdl import intbv
>>>>>a = intbv(0xffff)
>>>>>CTRL_FIELD = slice(4, 2)
>>>>>type(CTRL_FIELD)
>>
>><type 'slice'>
>>
>>>>>a[CTRL_FIELD]
>>
>>intbv(3L)
>>
>>>>>a[CTRL_FIELD] = 0
>>>>>hex(a)
>>
>>'0xFFF3L'
>>
This works in MyHDL 0.4.1 (0.4 used ``__getslice__`` methods).  Incidentally, 
0.4.1 requires Python 2.3 for several reasons.

>>The slice object is not often used explicitly in Python code but
>>probably deserves more attention. (Warning: toVerilog doesn't
>>support his - as always, patches are welcome!).
>>
Also note that before Python 2.3, `slice` was a constuctor function distinct 
from the <type 'slice'> object (accessible as `types.SliceType`) which.  In 
Python 2.3 they were merged so now `slice` is the type and is callable (like 
`int` and other builtin types).

> 
> Thanks for the tip! This is exactly what I want for now. (Matlab
> behaviour is probably an over kill unless one has no-contigous field,
> which for hardware designer only happens under special circumstances).
> I will see what I can do about toVerilog when I get that far.
> 
> Haitao
> 
>>>In Matlab one can index any vector with another vector. I don't see
>>>why this shouldn't be doable in Python as well. Maybe just no need for
>>>it, until the hardware designers come along? Is the simplest way to
>>>overload __getslice__ to accept a tuple (defining range)?
>>
You can have the matlab behavior with Numeric arrays.  `intbv` could easily be 
extended to support it if there is a real use for it.

BTW, `intbv` presently silently ignores the step of the slice.  To prevent 
bugs going unnoticed, it should raise an exception if ``key.step is not None`` 
(or properly support it).

[myhdl-list] Re: VCD viewer ?

[Jean D. <jea...@un...>]

Thanks a lot Günter for your help. Finallt GTKwave for Windows functions 
properly.

For the information a the new users of GTKwave: the executable 
winwave.exe has to be launch in a DOS console window and is not an 
interactive GUI software. Then a user window is opened.

Günter Dannoritzer a écrit :
> Hi Jean,
> 
> Jean DEMARTINI wrote:
> 
>> Hi all,
>>
>> For many reasons I've to use MyHDL on a Windows platform (XP SP2). 
>> Python and MyHDL works perfectly. But has anyone knowledge of a 
>> working free VCD viewer onto Windows. Despite many effort, I've not 
>> succeded to use GTKwave and Wavevcd from ISS (beta downloadable at 
>> www.iss-us.com) does not recognize the VCD format generated by MyHDL 
>> (its is a drawback of the ISS viewer as the VCD format generated by 
>> MyDHL is quite correct) .
>>
>> Jean
>>
>>
> 
> Have you looked into GTKWave?
> 
>     http://www.cs.man.ac.uk/apt/tools/gtkwave/
> 
> I have not used it with MyHDL, so I cannot commend on that.
> 
> Here is a page that has a windows version available:
> 
> http://www.geocities.com/SiliconValley/Campus/3216/GTKWave/gtkwave-win32.html 
> 
> 
> The windows version is an older version, but still works fine. Actually 
> I had recently a .vcd file that would work with the older version and 
> not with one of the new 2.0 pre releases.
> 
> Hope that helps.
> 
> Guenter
> 
> 
> 
> -------------------------------------------------------
> 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

[myhdl-list] Re: Re: VCD viewer ?

[Jean D. <jea...@un...>]

Hi G=FCnter,

Thanks for your help.
The trick is that GTKwave has to be launched from a DOS console window.

Jean


--=20
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 266.6.0 - Release Date: 02/03/2005

Re: [myhdl-list] VCD viewer ?

[<dan...@we...>]

Hi Jean,

Jean DEMARTINI wrote:
> Hi all,
> 
> For many reasons I've to use MyHDL on a Windows platform (XP SP2). 
> Python and MyHDL works perfectly. But has anyone knowledge of a working 
> free VCD viewer onto Windows. Despite many effort, I've not succeded to 
> use GTKwave and Wavevcd from ISS (beta downloadable at www.iss-us.com) 
> does not recognize the VCD format generated by MyHDL (its is a drawback 
> of the ISS viewer as the VCD format generated by MyDHL is quite correct) .
> 
> Jean
> 
> 

Have you looked into GTKWave?

	http://www.cs.man.ac.uk/apt/tools/gtkwave/

I have not used it with MyHDL, so I cannot commend on that.

Here is a page that has a windows version available:

http://www.geocities.com/SiliconValley/Campus/3216/GTKWave/gtkwave-win32.html

The windows version is an older version, but still works fine. Actually 
I had recently a .vcd file that would work with the older version and 
not with one of the new 2.0 pre releases.

Hope that helps.

Guenter

[myhdl-list] VCD viewer ?

[Jean D. <jea...@wa...>]

Hi all,

For many reasons I've to use MyHDL on a Windows platform (XP SP2). 
Python and MyHDL works perfectly. But has anyone knowledge of a working 
free VCD viewer onto Windows. Despite many effort, I've not succeded to 
use GTKwave and Wavevcd from ISS (beta downloadable at www.iss-us.com) 
does not recognize the VCD format generated by MyHDL (its is a drawback 
of the ISS viewer as the VCD format generated by MyDHL is quite correct) .

Jean


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 266.6.0 - Release Date: 02/03/2005

[myhdl-list] Status + holiday

[Jan D. <ja...@ja...>]

Hi all:

A quick note to let you know that you wont' hear from me
until March 14, because I'm on a skiing holiday.

The past weeks I worked on wiki stuff. I'm not satisfied
with the current solution (on python.org) but fascinated
by the idea. As I'm also not satisified with my current
web site, I plan to put everything on a freshly installed
wiki of my own. It cannot be a Python one (my web site
is on yahoo). After some searching, I selected
DokuWiki (in PHP). It's nice, small and clean, and has
some very nice features such as section edits. I did some
customization work, e.g. to support a sidebar.

The new site is not finished yet, but you can get an
idea by viewing the current status at:

    www.jandecaluwe.com/wiki

There may be issues - Feedback welcome. E.g. the
stylesheet works perfectly with Mozilla, but I'm not
sure about IE.

The idea would be that the MyHDL part would be
editable by any registered user.

Jan

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

Re: [myhdl-list] Re: range object

[Haitao Z. <ha...@gm...>]

On Thu, 03 Mar 2005 11:49:08 +0100, Jan Decaluwe <ja...@ja...> wrote:
> Haitao Zhang wrote:
> > Another nice to have :)
> >
> > In VHDL one could define a range type and define a constant with it,
> > so that one can associate a symbolic name say CTRL_FIELD with  7
> > DOWNTO 3, and then one can refer to register(CTRL_FIELD). In Verilog
> > one can probably get by with macro defines. However in Python the
> > native slicing is limited to integer arguments (?), so one has to
> > define two named constants instead of passing an indexing object.
> 
> This is not correct. Consider:
> 
> >>> from myhdl import intbv
> >>> a = intbv(0xffff)
> >>> CTRL_FIELD = slice(4, 2)
> >>> type(CTRL_FIELD)
> <type 'slice'>
> >>> a[CTRL_FIELD]
> intbv(3L)
> >>> a[CTRL_FIELD] = 0
> >>> hex(a)
> '0xFFF3L'
> 
> The slice object is not often used explicitly in Python code but
> probably deserves more attention. (Warning: toVerilog doesn't
> support his - as always, patches are welcome!).
> 

Thanks for the tip! This is exactly what I want for now. (Matlab
behaviour is probably an over kill unless one has no-contigous field,
which for hardware designer only happens under special circumstances).
I will see what I can do about toVerilog when I get that far.

Haitao

> > This feature is handy when one needs to define control register
> > fields. It allows one to define the named constants in one place.
> >
> > In Matlab one can index any vector with another vector. I don't see
> > why this shouldn't be doable in Python as well. Maybe just no need for
> > it, until the hardware designers come along? Is the simplest way to
> > overload __getslice__ to accept a tuple (defining range)?
> 
> (__getslice__ is deprecated, use __getitem__ instead. Look in
> the 0.4.1 code for intbv to see how slicing is implemented.)
> More than you probably need has been done by lots of people doing
> lots of work. Check out the Numeric Python extension for a Python
> with MatLab-like functionality. Also check SciPy. (Warning:
> there is a LOT of material to study.)
> 
> Regards, Jan
> 
> --
> 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
> 
> -------------------------------------------------------
> 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>