myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] 0.6dev1

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

Hi:

I'll be taking a few day off, and before that I wanted to
release the current development status of MyHDL's assault
on VHDL. Hence, 0.6dev1. See:

http://myhdl.jandecaluwe.com/doku.php/snapshots#snapshots
http://myhdl.jandecaluwe.com/doku.php/whatsnew:0.6
http://myhdl.jandecaluwe.com/doku.php/todo:0.6

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Visual Timing Specification for unit testing - complete example

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

neat idea!

On 10/2/06, George Pantazopoulos <ge...@ga...> wrote:
>
> All,
>    I've come up with a solution that made writing unit tests massively
> more fun and less tedious and error-prone for me.
>
> I've found a way to make an easily human-readable ascii timing diagram.
> However, this timing diagram is special because the very same diagram
> can be parsed and used to drive a MyHDL unit test.
>
> I've pasted a complete working example using an up_counter hardware
> module. This example also demonstrates the use of Python dicts for
> signal grouping. In fact, the test code relies on this functionality.
>
> I have some improvements planned (such as support for negedges).
> Feedback welcome.
>
> Enjoy,
> George
>
>
> # - Begin code
> ---------------------------------------------------------------
>
> # myhdl_vts.py
> # George Pantazopoulos http://www.gammaburst.net
>
> from myhdl import *
>
> #
>
> ----------------------------------------------------------------------------
>
> def visual_timing_spec_parse(vts, print_cts=False):
>    """
>    Visual Timing Specification parser for MyHDL
>
>    Parses a Visual Timing Specification into a condensed
>    format suitable for driving or checking signals
>
>    A Visual Timing Specification (VTS) is an ascii-based
>    format for conveying signal timing information.
>
>    The same timing spec is both human- and machine-readable.
>
>    A VTS object can be used for driving signals as well
>    as checking signal outputs.
>
>    Example VTS objects:
>
>        signals_to_drive = dict(
>        edges =   "|0....|1....|2....|3....|4....|5....|6....",
>        rst   =   "------____________________________________",
>        we    =   "______------------________________________",
>        re    =   "____________------------__________________",
>        dwr   =   "0x00  0b110 0xBB  0xCC  0xDD  ...   0xEE  ")
>
>        correct_outputs = dict(
>        edges =   "|0....|1....|2....|3....|4....|5....|6....",
>        drd   =   "X     0     X     0b110 0xBB  X     X     ",
>        empty =   "X     ------____________------------------",
>        full  =   "X     ____________________________________")
>
>    - A VTS is a Python dictionary.
>
>    - Each dictionary key is the name of a signal in the design.
>
>    - Each key's value is an ASCII string describing that signals behavior
>
>    - In addition to the signal keys, a special key named 'edges'
>      is required.
>
>      Its string value contains edge markers and padding. The edge markers
>      are denoted by '|' for positive edges.
>      Other characters are currently ignored.
>
>    How a VTS is parsed:
>    --------------------
>
>    - Only characters "under" the edge markers are looked at.
>
>    - '-' = signal is high at this clock edge
>
>    - '_' = signal is low  at this clock edge
>
>    - '.' = no change    (used when driving signals)
>
>    - 'X' = "don't care" (used when checking signals)
>
>    - integer data values are supported.
>      Their first character needs to be under the edge marker.
>
>      Hex values must be preceded by "0x"
>      Binary values must be preceded by "0b"
>
>      Padding may be added to the 'edges' string to accomodate
>      data values of any length. One whitespace character must follow
>      the data item and come before the next edge marker.
>
>
>    Timing:
>    -------
>
>    When driving signals with the VTS, assume that the signal
>    will be valid at the clock edge.
>
>    When checking signals with the VTS, the signal value checked for
>    must be valid by the time the corresponding edge arrives.
>
>
>    Condensed Timing Spec
>    ---------------------
>
>    The result of parsing a Visual Timing Spec is a Condensed Timing Spec.
>    Its format is similar to the VTS, except that it's not restricted to
>    ASCII and contains only the data for each clock edge, with no padding.
>
>    The CTS is to be passed as input to the actual driver and monitor
>    functions.
>
>    TODO:
>    -----
>
>    TODO: Make it possible to optionally specify negedges too. Eg:
>    edges  =   "|0....v.....|1....v.....|2....v...."
>    Where 'v' denotes a negedge
>
>    TODO: Make it possible to concatenate multiple VTS's into a list,
>    so long timing specs remain easily readable.
>
>    """
>
>    __author__   = "George Pantazopoulos http://www.gammaburst.net"
>    __revision__ = ""
>    __date__     = "2 Oct 2006"
>    __version__  = "0.1.0"
>    __requires__ = ('myhdl', '>= 0.5.1')
>
>    # Create an empty Condensed Timing Specification
>    cts = dict()
>
>    for sig in vts:
>        cts[sig] = []
>
>    # There should be dictionary item called "edges"
>    # We'll use this to figure out when to sample
>
>    edgenum = 0
>    # For each character in the 'edges' specifier string
>    for i in range(len(vts['edges'])):
>
>        # Grab the character value
>        c = vts['edges'][i]
>
>        if c == '|':
>            # We sample here.
>
>            # For each signal specifier string in vts
>            for sig in vts:
>
>                if sig == 'edges':
>                    data = edgenum
>                    edgenum += 1
>
>                elif sig != 'edges':
>
>                    # Get the character at the edge sampling index
>                    d = vts[sig][i]
>
>                    if   d == '_':
>                        data = False
>
>                    elif d == '-':
>                        data = True
>
>                    # This is a "don't-care".
>                    # Intended for use when checking signals,
>                    # not driving them.
>                    elif d == 'X':
>                        data = ' '
>
>                    # "dont update this signal" when used for driving
>                    elif (d == '.'):
>                        data = ' '
>
>                    # A space under an edge marker is illegal, because it
>                    # could mean a formatting error was made by the user.
>                    #
>                    # This type of error can be hard to spot.
>                    # If we don't trap this, it could lead to wasted time
>                    # and misleading test results.
>                    elif d == ' ':
>
>                        diag = "signal: " + sig + ", offset=" + str(i)
>                        raise Exception, \
>                        "Spaces are not allowed under edge markers " + diag
>
>                    else:
>                        # Treat this char that's under the edge marker
>                        # as the start of a data value string
>                        #
>                        # We need to parse the data string until we reach
>                        # whitespace or the next edge marker.
>                        #
>                        # grab the next chars until we hit whitespace or
> the
>                        # next edge marker.
>                        #
>                        # Start at the char 'under' the current edge
> marker.
>
>                        # TODO: Stop if we hit the next edge marker
>
>                        n = 0
>                        dstr = ""
>                        while d != ' ':
>                            d = vts[sig][i+n]
>                            dstr += d
>                            n += 1
>
>                        # convert to an int.
>                        # The (required) trailing whitespace is ok.
>
>                        # Hex
>                        if   dstr[:2] == "0x":
>                            data = int(dstr[2:],16)
>
>                        # Binary
>                        elif dstr[:2] == "0b":
>                            data = int(dstr[2:], 2)
>
>                        # Decimal
>                        else:
>                            data = int(dstr)
>
>                # Add the data item to the appropriate signal's
> list.
>                cts[sig].append(data)
>
>
>    if print_cts:
>
>        print "cts: "
>
>        import pprint
>        print pprint.pprint(cts)
>
>
>    return cts
>
> #
>
> ----------------------------------------------------------------------------
>
> def drive_signals_from_cts(sigs, cts):
>    """
>    drive_signals_from_cts() - unit test tool for MyHDL
>
>    Given a Condensed Timing Spec object, drive the signals according to
>    that specification. See the Visual Timing Spec parser doc.
>
>    The signal dictionary must contain a 'clk' signal
>    """
>
>    __author__   = "George Pantazopoulos http://www.gammaburst.net"
>    __revision__ = ""
>    __date__     = "2 Oct 2006"
>    __version__  = "0.1.0"
>    __requires__ = ('myhdl', '>= 0.5.1')
>
>    if 'clk' not in sigs:
>        raise Exception, \
>        "signal dictionary 'sigs' must contain a 'clk' signal"
>
>    clk = sigs['clk']
>
>    for i in range(len(cts['edges'])):
>
>        # Setup for positive edge i
>
>        # Drive each signal with the correct value for
>        # the upcoming positive edge i
>        for sig in cts:
>
>            value = cts[sig][i]
>
>            if sig != 'edges':
>
>                if value != ' ':
>                    sigs[sig].next = value
>
>        # positive edge i
>        yield clk.posedge
>
>        # negative edge i
>        yield clk.negedge
>
> #
>
> ----------------------------------------------------------------------------
>
> def check_signals_against_cts(sigs, cts):
>    """
>    check_signals_against_cts() - unit test tool for MyHDL
>
>    Given a Condensed Timing Spec object, ensure the signals match
>    that specification. See the Visual Timing Spec parser doc.
>
>    The signal dictionary must contain a 'clk' signal
>    """
>
>    __author__   = "George Pantazopoulos http://www.gammaburst.net"
>    __revision__ = ""
>    __date__     = "2 Oct 2006"
>    __version__  = "0.1.0"
>    __requires__ = ('myhdl', '>= 0.5.1')
>
>    if 'clk' not in sigs:
>        raise Exception, \
>        "signal dictionary 'sigs' must contain a 'clk' signal"
>
>    clk = sigs['clk']
>
>
>    for i in range(len(cts['edges'])):
>
>        # Setup for edge i
>
>        # Edge i
>        yield clk.posedge
>
>        # Check the outputs that should have been valid by
>        # the time this edge comes around
>        for sig in cts:
>
>            value = cts[sig][i]
>
>            if sig != 'edges':
>
>                # Skip this for 'don't-care' values
>                if value != ' ':
>
>                    # If the signal is not the value it should have been
>                    if sigs[sig] != value:
>
>                        # Raise an exception and show some helpful info.
>                        info = "Edge #" + str(i) + \
>                               " Signal \'" + sig + "\'" + \
>                               " = "  + str(sigs[sig]) + \
>                               ". Correct value = " + str(value)
>                        raise Exception, info
>
>        yield clk.negedge
>
>
>    raise StopSimulation()
>
> #
>
> ----------------------------------------------------------------------------
>
> def up_counter(sigs):
>
>    # Unbundle needed signals. Name them from the perspective of this
> module.
>    clk_i    = sigs['clk']
>    rst_i    = sigs['rst']
>
>    count_o  = sigs['count']
>    enable_i = sigs['count_en']
>
>    @always(clk_i.posedge)
>    def count_proc():
>
>        if rst_i:
>            count_o.next = 0
>
>        else:
>            if enable_i:
>                count_o.next = (count_o + 1) % 2**len(count_o)
>
>    return instances()
>
> #
>
> ----------------------------------------------------------------------------
>
> def up_counter_bench():
>
>    # Embedded function definition for clock generator
>    def clkgen(clk):
>
>        while True:
>            yield delay(10)
>            clk.next = not clk
>
>    # Shared clk signal
>    clk = Signal(bool(0))
>
>    # Create the signal group for the counter
>    counter_sigs=dict(clk      = clk,
>                      rst      = Signal(bool(0)),
>                      count    = Signal(intbv(0)[4:]),
>                      count_en = Signal(bool(0)))
>
>    # Instantiate a clock generator and connect to the shared clock
>    clkgen_inst = clkgen(clk)
>
>    dut = up_counter(counter_sigs)
>
>    # Visual Timing Specification
>    # ---------------------------
>
>    signals_to_drive = dict(
>    edges      = "|0....|1....|2....|3....|4....|5....|6....",
>    rst        = "-------------_____________________________",
>    count_en   = "__________________------------------------")
>
>    correct_outputs = dict(
>    edges      = "|0....|1....|2....|3....|4....|5....|6....",
>    count      = "X     0     0     0     1     2     3     ")
>
>    # Signal driver
>    driver = drive_signals_from_cts(
>
>            sigs = counter_sigs,
>            cts  = visual_timing_spec_parse(signals_to_drive)
>            )
>
>    # Signal monitor
>    monitor = check_signals_against_cts(
>
>            sigs = counter_sigs,
>            cts  = visual_timing_spec_parse(correct_outputs)
>            )
>
>    return instances()
>
> #
>
> ----------------------------------------------------------------------------
>
> def test_up_counter():
>    tb = up_counter_bench()
>    sim = Simulation(tb)
>    sim.run()
>
> test_up_counter()
>
> # - End code
> -----------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Visual Timing Specification for unit testing - complete example

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

George Pantazopoulos wrote:
> All,
>     I've come up with a solution that made writing unit tests massively 
> more fun and less tedious and error-prone for me.
> 
> I've found a way to make an easily human-readable ascii timing diagram. 
> However, this timing diagram is special because the very same diagram 
> can be parsed and used to drive a MyHDL unit test.

Hi George,

That is a good idea. I briefly looked over the code and saw that you are
doing the parsing yourself.

I wonder whether in the long run using a parser package would help for
the code not to get too complex. I found this PyParsing package a while
ago http://pyparsing.wikispaces.com/ that can be used very flexible for
all kinds of parsing.

 > I have some improvements planned (such as support for negedges).
> Feedback welcome.
> 

I ran over such a tool a while ago -- though not for MyHDL :) --. It did
parse the timing data from an ASCII file. I googled for it, but have not
found it yet. I just wonder whether there exists already some common
character set to specify signal data. Maybe that would allow to use it
to use output from other tools in MyHDL? Just a thought.

Cheers,

Guenter

[myhdl-list] Visual Timing Specification for unit testing - complete example

[George P. <ge...@ga...>]

All,
    I've come up with a solution that made writing unit tests massively 
more fun and less tedious and error-prone for me.

I've found a way to make an easily human-readable ascii timing diagram. 
However, this timing diagram is special because the very same diagram 
can be parsed and used to drive a MyHDL unit test.

I've pasted a complete working example using an up_counter hardware 
module. This example also demonstrates the use of Python dicts for 
signal grouping. In fact, the test code relies on this functionality.

I have some improvements planned (such as support for negedges). 
Feedback welcome.

Enjoy,
George


# - Begin code 
---------------------------------------------------------------

# myhdl_vts.py
# George Pantazopoulos http://www.gammaburst.net

from myhdl import *

# 
----------------------------------------------------------------------------

def visual_timing_spec_parse(vts, print_cts=False):
    """
    Visual Timing Specification parser for MyHDL
   
    Parses a Visual Timing Specification into a condensed
    format suitable for driving or checking signals
   
    A Visual Timing Specification (VTS) is an ascii-based
    format for conveying signal timing information.
   
    The same timing spec is both human- and machine-readable.
   
    A VTS object can be used for driving signals as well
    as checking signal outputs.
   
    Example VTS objects:

        signals_to_drive = dict(
        edges =   "|0....|1....|2....|3....|4....|5....|6....",
        rst   =   "------____________________________________",
        we    =   "______------------________________________",
        re    =   "____________------------__________________",
        dwr   =   "0x00  0b110 0xBB  0xCC  0xDD  ...   0xEE  ")
   
        correct_outputs = dict(
        edges =   "|0....|1....|2....|3....|4....|5....|6....",
        drd   =   "X     0     X     0b110 0xBB  X     X     ",
        empty =   "X     ------____________------------------",
        full  =   "X     ____________________________________")
   
    - A VTS is a Python dictionary.
   
    - Each dictionary key is the name of a signal in the design.
   
    - Each key's value is an ASCII string describing that signals behavior
   
    - In addition to the signal keys, a special key named 'edges'
      is required.
     
      Its string value contains edge markers and padding. The edge markers
      are denoted by '|' for positive edges.
      Other characters are currently ignored.
         
    How a VTS is parsed:
    --------------------
   
    - Only characters "under" the edge markers are looked at.
   
    - '-' = signal is high at this clock edge
   
    - '_' = signal is low  at this clock edge
   
    - '.' = no change    (used when driving signals)
   
    - 'X' = "don't care" (used when checking signals)
   
    - integer data values are supported.
      Their first character needs to be under the edge marker.
     
      Hex values must be preceded by "0x"
      Binary values must be preceded by "0b"
     
      Padding may be added to the 'edges' string to accomodate
      data values of any length. One whitespace character must follow
      the data item and come before the next edge marker.
     
     
    Timing:
    -------
   
    When driving signals with the VTS, assume that the signal
    will be valid at the clock edge.
   
    When checking signals with the VTS, the signal value checked for
    must be valid by the time the corresponding edge arrives.
     
     
    Condensed Timing Spec
    ---------------------
   
    The result of parsing a Visual Timing Spec is a Condensed Timing Spec.
    Its format is similar to the VTS, except that it's not restricted to
    ASCII and contains only the data for each clock edge, with no padding.
   
    The CTS is to be passed as input to the actual driver and monitor
    functions.  

    TODO:
    -----
   
    TODO: Make it possible to optionally specify negedges too. Eg:
    edges  =   "|0....v.....|1....v.....|2....v...."
    Where 'v' denotes a negedge
   
    TODO: Make it possible to concatenate multiple VTS's into a list,
    so long timing specs remain easily readable.
   
    """
   
    __author__   = "George Pantazopoulos http://www.gammaburst.net"
    __revision__ = ""
    __date__     = "2 Oct 2006"
    __version__  = "0.1.0"
    __requires__ = ('myhdl', '>= 0.5.1')
       
    # Create an empty Condensed Timing Specification
    cts = dict()
   
    for sig in vts:
        cts[sig] = []
       
    # There should be dictionary item called "edges"
    # We'll use this to figure out when to sample
   
    edgenum = 0
    # For each character in the 'edges' specifier string
    for i in range(len(vts['edges'])):
       
        # Grab the character value
        c = vts['edges'][i]
       
        if c == '|':
            # We sample here.
           
            # For each signal specifier string in vts
            for sig in vts:
               
                if sig == 'edges':
                    data = edgenum
                    edgenum += 1
                   
                elif sig != 'edges':
                   
                    # Get the character at the edge sampling index
                    d = vts[sig][i]
                   
                    if   d == '_':
                        data = False
                   
                    elif d == '-':
                        data = True
                   
                    # This is a "don't-care".
                    # Intended for use when checking signals,
                    # not driving them.
                    elif d == 'X':
                        data = ' '
                   
                    # "dont update this signal" when used for driving
                    elif (d == '.'):
                        data = ' '
                       
                    # A space under an edge marker is illegal, because it
                    # could mean a formatting error was made by the user.
                    #
                    # This type of error can be hard to spot.
                    # If we don't trap this, it could lead to wasted time
                    # and misleading test results.
                    elif d == ' ':
                       
                        diag = "signal: " + sig + ", offset=" + str(i)
                        raise Exception, \
                        "Spaces are not allowed under edge markers " + diag
                       
                    else:
                        # Treat this char that's under the edge marker
                        # as the start of a data value string
                        #
                        # We need to parse the data string until we reach
                        # whitespace or the next edge marker.
                        #                               
                        # grab the next chars until we hit whitespace or the
                        # next edge marker.
                        #
                        # Start at the char 'under' the current edge marker.
                       
                        # TODO: Stop if we hit the next edge marker        
                                            
                        n = 0
                        dstr = ""
                        while d != ' ':
                            d = vts[sig][i+n]
                            dstr += d
                            n += 1
                       
                        # convert to an int.
                        # The (required) trailing whitespace is ok.
                       
                        # Hex
                        if   dstr[:2] == "0x":
                            data = int(dstr[2:],16)   
                       
                        # Binary
                        elif dstr[:2] == "0b":
                            data = int(dstr[2:], 2)
                       
                        # Decimal
                        else:
                            data = int(dstr)
               
                # Add the data item to the appropriate signal's 
list.       
                cts[sig].append(data)
                   
                   
    if print_cts:
       
        print "cts: "
       
        import pprint
        print pprint.pprint(cts) 
       
          
    return cts   

# 
----------------------------------------------------------------------------

def drive_signals_from_cts(sigs, cts):
    """
    drive_signals_from_cts() - unit test tool for MyHDL
   
    Given a Condensed Timing Spec object, drive the signals according to
    that specification. See the Visual Timing Spec parser doc.
   
    The signal dictionary must contain a 'clk' signal
    """
   
    __author__   = "George Pantazopoulos http://www.gammaburst.net"
    __revision__ = ""
    __date__     = "2 Oct 2006"
    __version__  = "0.1.0"
    __requires__ = ('myhdl', '>= 0.5.1')
       
    if 'clk' not in sigs:
        raise Exception, \
        "signal dictionary 'sigs' must contain a 'clk' signal"
   
    clk = sigs['clk']
       
    for i in range(len(cts['edges'])):
   
        # Setup for positive edge i
   
        # Drive each signal with the correct value for
        # the upcoming positive edge i
        for sig in cts:
           
            value = cts[sig][i]
           
            if sig != 'edges':
               
                if value != ' ':
                    sigs[sig].next = value
           
        # positive edge i
        yield clk.posedge
   
        # negative edge i
        yield clk.negedge
   
# 
----------------------------------------------------------------------------

def check_signals_against_cts(sigs, cts):
    """
    check_signals_against_cts() - unit test tool for MyHDL
   
    Given a Condensed Timing Spec object, ensure the signals match
    that specification. See the Visual Timing Spec parser doc.
   
    The signal dictionary must contain a 'clk' signal
    """      
   
    __author__   = "George Pantazopoulos http://www.gammaburst.net"
    __revision__ = ""
    __date__     = "2 Oct 2006"
    __version__  = "0.1.0"
    __requires__ = ('myhdl', '>= 0.5.1')
       
    if 'clk' not in sigs:
        raise Exception, \
        "signal dictionary 'sigs' must contain a 'clk' signal"
   
    clk = sigs['clk']
     
            
    for i in range(len(cts['edges'])):
       
        # Setup for edge i

        # Edge i
        yield clk.posedge
   
        # Check the outputs that should have been valid by
        # the time this edge comes around
        for sig in cts:
           
            value = cts[sig][i]
           
            if sig != 'edges':
           
                # Skip this for 'don't-care' values
                if value != ' ':
                   
                    # If the signal is not the value it should have been
                    if sigs[sig] != value:
                       
                        # Raise an exception and show some helpful info.
                        info = "Edge #" + str(i) + \
                               " Signal \'" + sig + "\'" + \
                               " = "  + str(sigs[sig]) + \
                               ". Correct value = " + str(value)
                        raise Exception, info         
   
        yield clk.negedge
                 
         
    raise StopSimulation()

# 
----------------------------------------------------------------------------

def up_counter(sigs):
   
    # Unbundle needed signals. Name them from the perspective of this 
module.
    clk_i    = sigs['clk']
    rst_i    = sigs['rst']
   
    count_o  = sigs['count']   
    enable_i = sigs['count_en']
   
    @always(clk_i.posedge)
    def count_proc():
       
        if rst_i:
            count_o.next = 0
           
        else:
            if enable_i:
                count_o.next = (count_o + 1) % 2**len(count_o)
          
    return instances()

# 
----------------------------------------------------------------------------

def up_counter_bench():
   
    # Embedded function definition for clock generator
    def clkgen(clk):
       
        while True:
            yield delay(10)
            clk.next = not clk
   
    # Shared clk signal
    clk = Signal(bool(0))
    
    # Create the signal group for the counter
    counter_sigs=dict(clk      = clk,
                      rst      = Signal(bool(0)),
                      count    = Signal(intbv(0)[4:]),
                      count_en = Signal(bool(0)))
   
    # Instantiate a clock generator and connect to the shared clock
    clkgen_inst = clkgen(clk)

    dut = up_counter(counter_sigs)

    # Visual Timing Specification
    # ---------------------------

    signals_to_drive = dict(
    edges      = "|0....|1....|2....|3....|4....|5....|6....",
    rst        = "-------------_____________________________",
    count_en   = "__________________------------------------")
       
    correct_outputs = dict(
    edges      = "|0....|1....|2....|3....|4....|5....|6....",
    count      = "X     0     0     0     1     2     3     ")

    # Signal driver
    driver = drive_signals_from_cts(
                           
            sigs = counter_sigs,
            cts  = visual_timing_spec_parse(signals_to_drive)
            )
   
    # Signal monitor
    monitor = check_signals_against_cts(
           
            sigs = counter_sigs,
            cts  = visual_timing_spec_parse(correct_outputs)
            )   
   
    return instances()

# 
----------------------------------------------------------------------------

def test_up_counter():
    tb = up_counter_bench()
    sim = Simulation(tb)
    sim.run()

test_up_counter()

# - End code 
-----------------------------------------------------------------

Re: [myhdl-list] Dream Mux (still a dream for now)

[George P. <ge...@ga...>]

>
> Discussing about a spec will make it possible to understand
> the issues better, and perhaps even come up with a better
> solution for what you want to achieve.
>

I agree. I've been doing some pathfinding on my own, evaluating different
methods of making the MyHDL code more readable while using (and unit
testing) hardware modules with many signals.

I've also done some experiments using classes for hardware blocks and
theres a synergistic effect with using signal bundles (dicts).

What I do know is that bundling signals using dicts seems to be a good wa=
y
to group related signals and manage complexity. The problem areas with
using  signal bundles as I seem them currently are:

Top-level modules for conversion to synthesizable Verilog:
 - Probably not much of a problem in practice, but I'll have to experimen=
t.

Using toVerilog with cosimulation:
 - Since toVerilog() requires a flat signal list, this is problematic.
   There may be a way to get around this by using some advanced Pythoning=
=20
   (such as the function wrapping features in 2.5). I'll have to
experiment.

Being required to unbundle signals for use in generators, since toVerilog
doesn't currently support directly using dicts in generators:

def module(sigs):

   # 'sigs' may contain more signals than we acutally unbundle and use.

   # This is actually clearer than using the dict directly,
   # since it describes the signal from the perspective of this module.
   # Also, it's easier to type.
   clk_i =3D sigs['clk']
   dat_o =3D sigs['drd']
   dat_i =3D sigs['dwr']

   @always(clk_i.posedge)
   def proc():
      ...

   return instances()


 - This isn't too much of a problem. I've often found that unbundling the
signals enhances readability anyway. Note this works fine in unit tests
without cosimulation. But if cosimulation doesn't support it, then the
unit tests can't really use it in practice.


 - Being able to manipulate all signals in a dict while inside a
generator,       and have the generated Verilog only contain a single
'always' block. This seems to be a strongly desireable feature, but as
you said is a lot harder to implement than the previous item.


I'm not quite sure how to start off a discussion on specs. Could you give
me a hint to get started?

Even with these problem areas, I've had considerable success already in m=
y
experiments, using classes and bundled signals. Python and MyHDL really
give me a lot of freedom to be creative.

I'm working on a ring buffer module that uses classes, signal bundling,
and some more of my 'home grown' ideas. Would it be helpful if I posted
the code and unit test sometime later?

Regards,
George


--=20
George Pantazopoulos
http://www.gammaburst.net

Re: [myhdl-list] Dream Mux (still a dream for now)

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

George Pantazopoulos wrote:

> 
> How difficult would it be to enhance the Verilog converter so it accepts 
> dict lookups in generators?
> 
> I really want to have the ability to do this:
> 
> @always(sigs['clk'].posedge)
> def Proc():
>    
>     sigs['dat'].next = 0
> 

George:

To meaningfully the assess the difficulty of this I believe
we should move from examples (which are useful to get the ball
rolling) to a comprehensive spec of what really is required.

For example, the example above would require read lookup
based on a constant key.

The first example you posted would require much more:
- read lookup on a loop variable key
- support for the keys() method of dicts, used in a for-loop
- I understand that because of readibility, you would want to
map the for-loop to a Verilog loop in the output

Of course, there are many more things that can be done
with dicts and that are potentially useful in modeling.
Before we know what should be supported, what not, and how
it should map to Verilog if applicable, little can be said
about implementation difficulty.

Discussing about a spec will make it possible to understand
the issues better, and perhaps even come up with a better
solution for what you want to achieve.

Best regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] suggestion: version number printout

[Tom D. <TD...@di...>]

On Sunday 01 October 2006 14:16, George Pantazopoulos wrote:
> Jan,
>
>     I think it would be useful to have MyHDL print its version number
> every time it runs. It could prevent considerable confusion and
> frustration. For example, I just discovered that I was actually using
> 0.5c1 and not 0.5.1 like I thought! But to find this out I had to
> manually check:

I would not want anything printed out unless I explicitly asked for it. That 
would really get ugly when running batch of unittests.

Tom

Re: [myhdl-list] Dream Mux (still a dream for now)

[Tom D. <TD...@di...>]

>     Thanks for your reply. Unfortunately, even though the above does
> convert, I think it leaves a lot to be desired because it produces
> long-winded, hard to follow Verilog code. I think it's important for the
> Verilog code to stay reaonably readable and MyHDL already does a great
> job in that respect. As far as the top-level interface, having it
> completely flat is inconvenient for me, but I can live with it for now.
> I'm going to try to find my own solution, and I'll let you know if I
> come up with anything. Yeah, Python hacking! :-)
>

Just my 2 cents worth...

I've never been concerned with what the generated Verilog code looks like. As 
a matter of fact, as long as it synthesizes (and simulates) properly, I would 
never look at it.

Tom

[myhdl-list] suggestion: version number printout

[George P. <ge...@ga...>]

Jan,
   
    I think it would be useful to have MyHDL print its version number 
every time it runs. It could prevent considerable confusion and  
frustration. For example, I just discovered that I was actually using 
0.5c1 and not 0.5.1 like I thought! But to find this out I had to 
manually check:

import myhdl
print myhdl.__version__

    Also, as my library of MyHDL modules grows along with MyHDL itself, 
some modules may require a newer version of MyHDL than others. I think 
it would nice to be able to enforce this, and save the user from the 
ensuing flood of hard-to-read Python tracebacks.

I like how PyGTK provides a method to require a particular version of 
gtk be available:

import pygtk
pygtk.require('2.0')
import gtk

Regards,
George

Re: [myhdl-list] Dream Mux (still a dream for now)

[George P. <ge...@ga...>]

> Mm. The code for 4 muxes, as can be expected.
>
> With Python 2.5, we'll be able to write mux behavior with one-liners:
>
>      z.next = b if sel else a
>
> which implies that the convertor will then simply produce 4 assign
> statements (using the Verilog one-liner counterpart).
>
>   
That sounds interesting. For synchronous logic, I'd like that to produce
one 'always' block in Verilog as opposed to N blocks.
>
> In summary, "readability" of the Verilog output is only my 3rd goal.
> The first is correctness, and the second is conversion power. As I
> try to show, the finest conversion results are sometimes obtained
> when no code is converted at all! (Because it has been taken care
> of before, by the elaboration with the Python interpreter.) And when,
> consequently, the Verilog output seems unrelated to the MyHDL input.
>
> Some of these ideas are explored on the following page:
>
>     http://myhdl.jandecaluwe.com/doku.php/cookbook:sinecomp
>
> A very good example of what I'm trying to say is here:
>
>     http://myhdl.jandecaluwe.com/doku.php/cookbook:bitonic
>
> The latter page shows that you can use structural recursion even
> when your target language or synthesis tool don't support recursion
> at all.
>
>   
Indeed! I've been having fun with that lately :-) Your cookbook examples 
are very rich with powerful and practical techniques. The more I re-read 
them the more I learn. Great job!

How difficult would it be to enhance the Verilog converter so it accepts 
dict lookups in generators?

I really want to have the ability to do this:

@always(sigs['clk'].posedge)
def Proc():
   
    sigs['dat'].next = 0

Thanks and keep up the good work,
George

Re: [myhdl-list] Dream Mux (still a dream for now)

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

George:

A couple of points:

> Hi Jan,
> 
>     Thanks for your reply. Unfortunately, even though the above does 
> convert, I think it leaves a lot to be desired because it produces 
> long-winded, hard to follow Verilog code.

Mm. The code for 4 muxes, as can be expected.

With Python 2.5, we'll be able to write mux behavior with one-liners:

     z.next = b if sel else a

which implies that the convertor will then simply produce 4 assign
statements (using the Verilog one-liner counterpart).

> I think it's important for the 
> Verilog code to stay reaonably readable and MyHDL already does a great 
> job in that respect.

For the code that is converted, yes. Even of higher quality than what
many a Verilog coder produces. But - I keep hammering on the same nail -
not all code is/needs to be converted, and that can be used to one's
advantage. In the sense that you can produce synthesizable Verilog
even when your MyHDL code uses features for which there is no Verilog
counterpart or no support in the synthesis tool. Obviously in such
cases the Verilog output will not reflect the MyHDL input code - it
will be at a much "lower level". But it will do the same thing!

In summary, "readability" of the Verilog output is only my 3rd goal.
The first is correctness, and the second is conversion power. As I
try to show, the finest conversion results are sometimes obtained
when no code is converted at all! (Because it has been taken care
of before, by the elaboration with the Python interpreter.) And when,
consequently, the Verilog output seems unrelated to the MyHDL input.

Some of these ideas are explored on the following page:

    http://myhdl.jandecaluwe.com/doku.php/cookbook:sinecomp

A very good example of what I'm trying to say is here:

    http://myhdl.jandecaluwe.com/doku.php/cookbook:bitonic

The latter page shows that you can use structural recursion even
when your target language or synthesis tool don't support recursion
at all.

> I'm going to try to find my own solution, and I'll let you know if I 
> come up with anything. Yeah, Python hacking! :-)

Fine. But note that your original code is most likely not what
you want, because it's only sensitive to the control signal.
For proper combinatorial behavior, it should be sensitive to
the data signals as well.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Dream Mux (still a dream for now)

[George P. <ge...@ga...>]

> George:
>
> Before doing anything else I would like to know whether you find the
> following solution acceptable.
>
> You could use dicts that hold signals to be muxed as follows:
>
> # begin code
> from myhdl import *
>
> def mux(z, a, b, sel):
>      @always_comb
>      def logic():
>          if sel:
>              z.next = b
>          else:
>              z.next = a
>      return logic
>
>
> def DreamMux(sigs0, sigs1, sigs_out, sel):
>
>      muxes = [mux(sigs_out[k], sigs0[k], sigs1[k], sel) for k in sigs_out]
>
>      return muxes
> # end code
>
>   
Hi Jan,

    Thanks for your reply. Unfortunately, even though the above does 
convert, I think it leaves a lot to be desired because it produces 
long-winded, hard to follow Verilog code. I think it's important for the 
Verilog code to stay reaonably readable and MyHDL already does a great 
job in that respect. As far as the top-level interface, having it 
completely flat is inconvenient for me, but I can live with it for now. 
I'm going to try to find my own solution, and I'll let you know if I 
come up with anything. Yeah, Python hacking! :-)

Thanks,
George

> Then there's the issue of the top-level interface. There you can't
> use dicts because the ports have to be mapped to Verilog primitives.
> However, this issue is different from your main concern and
> again, it's only an issue at the very top-level.
>
> As an example, this would be a top-level wrapper around the
> DreamMux design:
>
> # begin code
> # top-level with "flat" interface
> def Top(dat0, adr0, cyc0, stb0,
>          dat1, adr1, cyc1, stb1,
>          dat_out, adr_out, cyc_out, stb_out, sel):
>
>      sigs0 = dict(dat=dat0, adr=adr0, cyc=cyc0, stb=stb0)
>      sigs1 = dict(dat=dat1, adr=adr1, cyc=cyc1, stb=stb1)
>      sigs_out = dict(dat=dat_out, adr=adr_out, cyc=cyc_out, stb=stb_out)
>
>      top_inst = DreamMux(sigs0, sigs1, sigs_out, sel)
>
>      return top_inst
> # end code
>
> You can verify that it converts as follows:
>
> # begin code
> # conversion
> sel = Signal(bool(0))
> dat0, dat1, dat_out = [Signal(intbv(0)[8:]) for i in range(3)]
> adr0, adr1, adr_out = [Signal(intbv(0)[16:]) for i in range(3)]
> cyc0, cyc1, cyc_out = [Signal(bool(0)) for i in range(3)]
> stb0, stb1, stb_out = [Signal(bool(0)) for i in range(3)]
>
> toVerilog(Top,
>            dat0, adr0, cyc0, stb0,
>            dat1, adr1, cyc1, stb1,
>            dat_out, adr_out, cyc_out, stb_out, sel)
> # end code
>
> Best regards,
>
> Jan
>
>   

Re: [myhdl-list] Dream Mux (still a dream for now)

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

George Pantazopoulos wrote:
> Hi Jan,
> 
>     I've been experimenting with ways to make my Wishbone bus components 
> more robust and modular (as well as less tedious and error-prone to 
> write, theres quite a few signals). I've had a lot of success using 
> dicts to bundle signals together, but something is preventing me from 
> taking this concept all the way.
> 
> Basically, I want a 2:1 Mux that routes one of the signal bundles to its 
> output.
> 
> I pasted a "dream" Mux block at the end of my email. I want it to assign 
> every named signal in sigs_out, to its named counterpart in either sigs0 
> and sigs1, depending on the state of the select line.

> I'm curious as to why the code below doesn't work (it causes a 
> "Requirement Violation, see below), and if it can be made to work. I 
> really want this functionality.
> 
>     I think I've developed my Python chops enough to try working on your 
> MyHDL sourcecode myself, but I'm still unsure as to how it all works. I 
> just put your code through Doxygen which is going to help a lot, but 
> could you give me some hints and maybe enlighten me a little about what 
> would have to change? This has to be possible! :)

George:

Before doing anything else I would like to know whether you find the
following solution acceptable.

You could use dicts that hold signals to be muxed as follows:

# begin code
from myhdl import *

def mux(z, a, b, sel):
     @always_comb
     def logic():
         if sel:
             z.next = b
         else:
             z.next = a
     return logic


def DreamMux(sigs0, sigs1, sigs_out, sel):

     muxes = [mux(sigs_out[k], sigs0[k], sigs1[k], sel) for k in sigs_out]

     return muxes
# end code

Then there's the issue of the top-level interface. There you can't
use dicts because the ports have to be mapped to Verilog primitives.
However, this issue is different from your main concern and
again, it's only an issue at the very top-level.

As an example, this would be a top-level wrapper around the
DreamMux design:

# begin code
# top-level with "flat" interface
def Top(dat0, adr0, cyc0, stb0,
         dat1, adr1, cyc1, stb1,
         dat_out, adr_out, cyc_out, stb_out, sel):

     sigs0 = dict(dat=dat0, adr=adr0, cyc=cyc0, stb=stb0)
     sigs1 = dict(dat=dat1, adr=adr1, cyc=cyc1, stb=stb1)
     sigs_out = dict(dat=dat_out, adr=adr_out, cyc=cyc_out, stb=stb_out)

     top_inst = DreamMux(sigs0, sigs1, sigs_out, sel)

     return top_inst
# end code

You can verify that it converts as follows:

# begin code
# conversion
sel = Signal(bool(0))
dat0, dat1, dat_out = [Signal(intbv(0)[8:]) for i in range(3)]
adr0, adr1, adr_out = [Signal(intbv(0)[16:]) for i in range(3)]
cyc0, cyc1, cyc_out = [Signal(bool(0)) for i in range(3)]
stb0, stb1, stb_out = [Signal(bool(0)) for i in range(3)]

toVerilog(Top,
           dat0, adr0, cyc0, stb0,
           dat1, adr1, cyc1, stb1,
           dat_out, adr_out, cyc_out, stb_out, sel)
# end code

Best regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Dream Mux (still a dream for now)

[George P. <ge...@ga...>]

Hi Jan,

    I've been experimenting with ways to make my Wishbone bus components 
more robust and modular (as well as less tedious and error-prone to 
write, theres quite a few signals). I've had a lot of success using 
dicts to bundle signals together, but something is preventing me from 
taking this concept all the way.

Basically, I want a 2:1 Mux that routes one of the signal bundles to its 
output.

I pasted a "dream" Mux block at the end of my email. I want it to assign 
every named signal in sigs_out, to its named counterpart in either sigs0 
and sigs1, depending on the state of the select line.

The signal bundles are Python dictionaries and could look something like 
this:

# -- Begin Code Paste --------------------------------------

sel = Signal(bool(0))

# Input Bundle 0
sigs0 = {}
sigs0['dat']    = Signal(intbv(0)[8:])
sigs0['adr']    = Signal(intbv(0)[16:])
sigs0['cyc']    = Signal(bool(0))
sigs0['stb']    = Signal(bool(0))

# Input Bundle 1
sigs1 = {}
sigs1['dat']    = Signal(intbv(0)[8:])
sigs1['adr']    = Signal(intbv(0)[16:])
sigs1['cyc']    = Signal(bool(0))
sigs1['stb']    = Signal(bool(0))

# Output Bundle
sigs_out = {}
sigs_out['dat'] = Signal(intbv(0)[8:])
sigs_out['adr'] = Signal(intbv(0)[16:])
sigs_out['cyc'] = Signal(bool(0))
sigs_out['cyc'] = Signal(bool(0))

MUX_INST = DreamMux(sigs0, sigs1, sigs_out, sel)

# -- End Code Paste --------------------------------------

I'm curious as to why the code below doesn't work (it causes a 
"Requirement Violation, see below), and if it can be made to work. I 
really want this functionality.

    I think I've developed my Python chops enough to try working on your 
MyHDL sourcecode myself, but I'm still unsure as to how it all works. I 
just put your code through Doxygen which is going to help a lot, but 
could you give me some hints and maybe enlighten me a little about what 
would have to change? This has to be possible! :)

Thanks,
George

# -- Begin Code Paste --------------------------------------

def DreamMux(sigs0, sigs1, sigs_out, sel):
    
    # I'd love to be able to do this,
    # but currently get errors in MyHDL:
    
    # sigs_out, sigs0, and sigs1 are dicts
    
    def Muxer():
        
        while True:
            
            yield sel
        
            if sel:
                                
                # For all signals in sigs_out
                # connect them to their counterparts in sigs1
                for k in sigs_out.keys():
                    sigs_out[k].next = sigs1[k]
            
            else:

                # For all signals in sigs_out
                # connect them to their counterparts in 
sigs0                
                for k in sigs_out.keys():
                    sigs_out[k].next = sigs0[k]
                    
    MUXER = Muxer()
    
    return instances()

# -- End Code Paste --------------------------------------

Traceback (most recent call last):
  File "myhdl_class_wbc_Master_Slave.py", line 282, in ?
    toVerilog(top, clk_i)
  File "/usr/lib/python2.4/site-packages/myhdl/_toVerilog/_convert.py", 
line 118
, in __call__
    _convertGens(genlist, vfile)
  File "/usr/lib/python2.4/site-packages/myhdl/_toVerilog/_convert.py", 
line 271
, in _convertGens
    compiler.walk(ast, v)
  File "/tmp/python.340/usr/lib/python2.4/compiler/visitor.py", line 
106, in wal
k
  File "/tmp/python.340/usr/lib/python2.4/compiler/visitor.py", line 63, 
in preo
rder
  File "/tmp/python.340/usr/lib/python2.4/compiler/visitor.py", line 57, 
in disp
atch
  File "/usr/lib/python2.4/site-packages/myhdl/_toVerilog/_convert.py", 
line 712
, in visitModule
    self.visit(stmt)
  File "/tmp/python.340/usr/lib/python2.4/compiler/visitor.py", line 57, 
in disp
atch
  File "/usr/lib/python2.4/site-packages/myhdl/_toVerilog/_convert.py", 
line 892
, in visitFunction
    self.visit(stmt)
  File "/tmp/python.340/usr/lib/python2.4/compiler/visitor.py", line 57, 
in disp
atch
  File "/usr/lib/python2.4/site-packages/myhdl/_toVerilog/_convert.py", 
line 647
, in visitIf
    self.mapToIf(node, *args)
  File "/usr/lib/python2.4/site-packages/myhdl/_toVerilog/_convert.py", 
line 694
, in mapToIf
    self.visit(suite)
  File "/tmp/python.340/usr/lib/python2.4/compiler/visitor.py", line 57, 
in disp
atch
  File "/usr/lib/python2.4/site-packages/myhdl/_toVerilog/_convert.py", 
line 817
, in visitStmt
    self.visit(stmt)
  File "/tmp/python.340/usr/lib/python2.4/compiler/visitor.py", line 57, 
in disp
atch
  File "/usr/lib/python2.4/site-packages/myhdl/_toVerilog/_convert.py", 
line 567
, in visitFor
    self.require(node, f in (range, downrange), "Expected (down)range call")
  File "/usr/lib/python2.4/site-packages/myhdl/_toVerilog/__init__.py", 
line 113
, in require
    self.raiseError(node, _error.Requirement, msg)
  File "/usr/lib/python2.4/site-packages/myhdl/_toVerilog/__init__.py", 
line 108
, in raiseError
    raise ToVerilogError(kind, msg, info)
myhdl.ToVerilogError: in file myhdl_class_wbc_Master_Slave.py, line 90:
    Requirement violation: Expected (down)range call

Re: [myhdl-list] choice of free Verilog simulator: icarus vs cver

[George P. <ge...@ga...>]

> That did it for me.
>
>   

That worked for me too. Thanks a LOT!

George

Re: [myhdl-list] PhoenixSID 65X81 News page updated

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

Tom Dillon wrote:
> On Tuesday 26 September 2006 18:09, George Pantazopoulos wrote:
> 
>>>>Also, the User-defined Verilog feature won't work because it would
>>>>create
>>>>nested modules that I confirmed do NOT work in Xilinx ISE.
>>>
>>>I don't understand what you are saying won't work in ISE. Could you
>>>provide an
>>>example?
>>
>>The User-defined Verilog works great and just as advertised for inserting
>>module instantiations into the MyHDL-generated Verilog code. I didn't mean
>>to imply it was broken in some way.
>>
>>What I mean is that I can't use that feature to declare additional, needed
>>modules because it is only capable of inserting stuff *inside* existing
>>modules.
> 
> 
> I see what you are saying. I would still let ISE compile the files separately. 
> That is the normal way of doing it and really doesn't cause any trouble.

I agree with that. This thread is really about Verilog project
management and I don't think MyHDL should play a role in that.

Because of the way it works (elaborating and flattening hierarchy),
the convertor generates one single Verilog output file. This makes it
easy to set up simple projects. But that doesn't mean that having
everything in one big file is the proper way to do project management
in larger projects.

As a last resort, you always have the choice of writing your own
convenience function that concatenates files and call it right
after the conversion in your Python file. But personally I would
set up the project properly, tracking dependencies with make or
in whatever way a project environment like ISE does it.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] choice of free Verilog simulator: icarus vs cver

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

George Pantazopoulos wrote:
> 
> Oh, I may want to stick with Icarus, then, as long as the signed
> arithmetic stuff is fixed. Is it ok to use the latest snapshot? If not,
> can you recommend a particular one?
> 

Hi George,

I recently installed the latest snapshot 20060809 under cygwin and had
to do some adjusting to get it to compile.

First there is a bug report:

http://sourceforge.net/tracker/index.php?func=detail&aid=1541452&group_id=149850&atid=775997

with a patch file:

http://sourceforge.net/tracker/download.php?group_id=149850&atid=775997&file_id=194444&aid=1541452

>From all what is said in that bug report the patch file is the one to
apply to the source.


Then there is another change that has to be done:

> Stephen Williams wrote:
> [...]
>> > 
>> > Try adding ivl_lval_width to the ivl.def file in the main source
>> > directory, then rebuild from the top down. It looks like that got
>> > missed in the big fixup.

That did it for me.

Guenter

Re: [myhdl-list] choice of free Verilog simulator: icarus vs cver

[George P. <ge...@ga...>]

> George Pantazopoulos wrote:
>> Hi Jan,
>>
>>    Did cver overthrow icarus Verilog for the title of Officially
>> Sanctioned Verilog Simlator now?
>
> No - I've had issues with both and want to use both for increased
> confidence (in the MyHDL convertor).
>
>> How much does the choice matter?
>
> Depends on what you're doing with which version :-)
>
> To be sure, I filed bug reports, they were acknowledged, and
> have been reported to be fixed by now. At that time I continued
> with cver to make progress.
>

Oh, I may want to stick with Icarus, then, as long as the signed
arithmetic stuff is fixed. Is it ok to use the latest snapshot? If not,
can you recommend a particular one?

>
> Probably it's time for me to upgrade my installations. But
> since I'm doing VHDL these days ... (GHDL seems to work
> very well, by the way.)
>

Yeah, I've been curious as to what you've been up to, since you seem
pretty busy ;-) How is the VHDL and tristate support going?

--=20
George Pantazopoulos
http://www.gammaburst.net

Re: [myhdl-list] Beginners question

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

Thomas Heller wrote:
> Jan Decaluwe schrieb:
> 
>>Thomas Heller wrote:
>>
>>>If I have two or more events in an always decorator:
>>>
>>>@always(a.negedge, b.negedge, delay(10))
>>>def func():
>>>    ...
>>>
>>>how can I determine inside func which event is currently handled?
>>
>>Currently there is no direct way. For edges and signals, it may
>>be possible to support this by making sure that certain
>>attributes (e.g. 'negedge') can be checked in code. But that
>>is not possible currently (that is, it won't work as expected).
>>For other things, such as delays, it's not clear how to do it.
>>
>>However, do we actually need this?
>>For synthesizable code, the classic synthesis templates are such
>>that the relevant checks are done implicitly by the
>>top-level if-then-else structure.
>>
>>For non-synthesizable code, you have the option of using
>>separate always blocks, each triggered by the relevant condition.
>>

> 
> Well, I guess the answer is "don't do this" anyway.

I'm open to being convinced if I understand the application.
If we look at VHDL versus Verilog: VHDL has such attributes,
Verilog doesn't. But on the other hand, you can't specify
"edges" in VHDL sensitivity lists, while you can in Verilog.
In this regard, MyHDL follows the Verilog scheme, which
suggests that we don't need the attributes either.

 > It seems
> I have still to switch from the more software oriented mental model back
> to hardware oriented.

Perhaps we can help (and also understand the original question better)
if you tell us more about your application. E.g. for the coding style
it makes a big difference whether you want to write synthesizable code
or high-level models.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] choice of free Verilog simulator: icarus vs cver

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

George Pantazopoulos wrote:
> Hi Jan,
> 
>    Did cver overthrow icarus Verilog for the title of Officially
> Sanctioned Verilog Simlator now?

No - I've had issues with both and want to use both for increased
confidence (in the MyHDL convertor).

> How much does the choice matter?

Depends on what you're doing with which version :-)

When I introduced support for 'signed' in the Verilog conversion,
I inevitably ended up in some of the darkest corners of the
Verilog language. Not unexpectedly, the simulators behaved
differently and it turned out that Icarus (0.8) had bugs.

To be sure, I filed bug reports, they were acknowledged, and
have been reported to be fixed by now. At that time I continued
with cver to make progress.

Cver may seem more robust, but has its issues also. E.g. the
'RandomScrambler' test takes ages with cver (unacceptably long),
but not with Icarus.

Probably it's time for me to upgrade my installations. But
since I'm doing VHDL these days ... (GHDL seems to work
very well, by the way.)

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] choice of free Verilog simulator: icarus vs cver

[George P. <ge...@ga...>]

Hi Jan,

   Did cver overthrow icarus Verilog for the title of Officially
Sanctioned Verilog Simlator now? How much does the choice matter?

Thanks,
--=20
George Pantazopoulos
http://www.gammaburst.net

Re: [myhdl-list] Python. tabs vs. spaces

[bedros <be...@ya...>]

spaces... old world editors like vi or vim show ugly indentation when opening files edited using other editors and tabs are inserted.

-B

----- Original Message ----
From: George Pantazopoulos <ge...@ga...>
To: General discussions on MyHDL <myh...@li...>
Sent: Wednesday, September 27, 2006 7:59:56 PM
Subject: [myhdl-list] Python. tabs vs. spaces

Hey fellow black wizards,

Just wondering which do you all prefer in your Python code: tabs or spaces?

Does it still matter nowadays when modern IDE's like Eclipse can convert 
files?
Why do you prefer one over the other?

I figure it's safe to ask this in here without sparking off a holy war ;-)

Thanks,
George


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] Python. tabs vs. spaces

[George P. <ge...@ga...>]

Hey fellow black wizards,

Just wondering which do you all prefer in your Python code: tabs or spaces?

Does it still matter nowadays when modern IDE's like Eclipse can convert 
files?
Why do you prefer one over the other?

I figure it's safe to ask this in here without sparking off a holy war ;-)

Thanks,
George

Re: [myhdl-list] Beginners question

[Thomas H. <th...@py...>]

Jan Decaluwe schrieb:
> Thomas Heller wrote:
>> If I have two or more events in an always decorator:
>> 
>> @always(a.negedge, b.negedge, delay(10))
>> def func():
>>     ...
>> 
>> how can I determine inside func which event is currently handled?
> 
> Currently there is no direct way. For edges and signals, it may
> be possible to support this by making sure that certain
> attributes (e.g. 'negedge') can be checked in code. But that
> is not possible currently (that is, it won't work as expected).
> For other things, such as delays, it's not clear how to do it.
> 
> However, do we actually need this?
> For synthesizable code, the classic synthesis templates are such
> that the relevant checks are done implicitly by the
> top-level if-then-else structure.
> 
> For non-synthesizable code, you have the option of using
> separate always blocks, each triggered by the relevant condition.
> 
Well, I guess the answer is "don't do this" anyway.  It seems
I have still to switch from the more software oriented mental model back
to hardware oriented.

Thanks,
Thomas

Re: [myhdl-list] Beginners question

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

Thomas Heller wrote:
> If I have two or more events in an always decorator:
> 
> @always(a.negedge, b.negedge, delay(10))
> def func():
>     ...
> 
> how can I determine inside func which event is currently handled?

Currently there is no direct way. For edges and signals, it may
be possible to support this by making sure that certain
attributes (e.g. 'negedge') can be checked in code. But that
is not possible currently (that is, it won't work as expected).
For other things, such as delays, it's not clear how to do it.

However, do we actually need this?
For synthesizable code, the classic synthesis templates are such
that the relevant checks are done implicitly by the
top-level if-then-else structure.

For non-synthesizable code, you have the option of using
separate always blocks, each triggered by the relevant condition.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com