myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] List Of Constants

[Henry G. <he...@ca...>]

Hi Josy,

Would you mind creating a gist ( https://gist.github.com/ ) of this? I'm 
struggling to extract the lines from the email (it gets munged at 
various points)

Forgive me if I've missed something, are you trying to do something more 
involved that a LUT? I'm using lists of bools and ints with an index 
referencing into them, which convert just fine, though it might not be 
quite your problem.

Cheers,

Henry

On 15/03/15 17:48, Josy Boelen wrote:
> In VHDL we can pass constants in the generic section.
> I mimic that in MyHDL by passing constants as the first arguments in the
> function call. Until now I have always used singular constants to do
> this, but now had the case where a List Of Constants looked more
> appealing than writing each one apart.
> So I threw in a list an passed that to the function.
> The simulation works fine. But the conversion fails depending on the
> contents of the list:
> * plain ints, intbvs: raise an exception
> ```text
> myhdl.ConversionError: in file
> C:\qdesigns\MyHDL\Source\issues\ListOfConstants\ListOfConstants.py, line
> 32:
>      Object type is not supported in this context: Coeff, <type 'list'>
> ```
> * Signals,: the conversion finishes, but the converted code generates
> uninitialized signals (wires in Verilog)
> ```VHDL
> 	type t_array_components_1_Coeff is array (0 to 2 - 1) of
> unsigned(3 downto 0);
> 	signal components_1_Coeff : t_array_components_1_Coeff;
> 	type t_array_components_0_Coeff is array (0 to 2 - 1) of
> unsigned(3 downto 0);
> 	signal components_0_Coeff : t_array_components_0_Coeff;
> ```
> The workaround was returning to spelling out every constant in the call.
>
> I distilled a (self-contained this time) example program showing my
> intent:
> ```python
> '''
> Created on 14 Mar 2015
>
> @author: Josy
> '''
>
>
> from __future__ import print_function
> import os, random
> from myhdl import *
>
>
> def flattenlov(D, Q):
>      ''' a simple utility to turn a list of vectors into a flattened
> vector '''
>      # in theory, ConcatSignal() would be usable too,
>      # but that constructs a new Signal, so we would still need
>      # an @always_comb to assign that newly created Signal to the output
> Signal
>      LNBR_VECTORS = len(D)
>      LWIDTH_D = len(D[0])
>      @always_comb
>      def flattenlov():
>          for i in range(LNBR_VECTORS):
>              Q.next[(i+1) * LWIDTH_D : i * LWIDTH_D ] = D[i]
>      return flattenlov
>
>
> def simplefunc( Coeff, Clk, DA, DB, Q):
>      ''' a simple operation, just for the effect ... '''
>
>      @always_seq( Clk.posedge, reset = None)
>      def calc():
>          Q.next = Coeff[0] * DA + Coeff[1] * DB
>
>      return calc
>
>
> def loc( NBR_VECTORS, Clk, DA, DB, Q ):
>      """
>          List Of Constants
>          DA, DB and Q are flattened Lists Of Vectors
>      """
>
>      # derive a few constants
>      LWIDTH_D = len(DA) / NBR_VECTORS
>      LWIDTH_Q = len(Q) / NBR_VECTORS
>      LWIDTH_C = LWIDTH_Q - LWIDTH_D
>
>      # must split input data into list Of Vectors
>      lova = [ DA((i+1) * LWIDTH_D, i * LWIDTH_D) for i in
> range(NBR_VECTORS)]
>      lovb = [ DB((i+1) * LWIDTH_D, i * LWIDTH_D) for i in
> range(NBR_VECTORS)]
>      # we use a List Of Vectors to collect the results too
>      result = [ Signal( intbv(0)[LWIDTH_Q:]) for _ in range(NBR_VECTORS)]
>
>      # for testing our 'options', we use a local variable for the
> coefficients
>      if USE_COEFF_INT:
>          # this simulates, but doesn't convert
>          LCOEFF = COEFF
>      elif USE_COEFF_INTBV:
>          # this simulates as well, but doesn't convert either
>          LCOEFF = [ [intbv(COEFF[i][0])[LWIDTH_C:], intbv(COEFF[i][1])
> [LWIDTH_C:]] for i in range(NBR_VECTORS)]
>      elif USE_COEFF_SIGNAL:
>          # this simulates _and_ converts, but the conversion doesn't work
> ...
>          LCOEFF = [ [Signal(intbv(COEFF[i][0])[LWIDTH_C:]),
> Signal(intbv(COEFF[i][1])[LWIDTH_C:])] for i in range(NBR_VECTORS)]
>
>      # instantiate as many 'simple functions' as vectors in the input
>      components = []
>      for i in range( NBR_VECTORS ):
>          components.append( simplefunc(LCOEFF[i], Clk, lova[i], lovb[i],
> result[i]))
>
>      # must flatten collected results into the output vector
>      components.append( flattenlov( result, Q ))
>
>      return  components
>
>
> def tb_loc():
>      ''' testing '''
>
>      # helper routines to build/disassemble the flattened in- and out-put
> vectors
>      def flatten( v , w):
>          ''' flattens a list of integer values
>                  v: list
>                  w: width of element in bits
>              assume that the values fit in the given bit-width 'w'
>           '''
>          r = 0
>          # start with Most Significant Value (or at end of list)
>          for i in range(len(v)-1,-1,-1):
>              if v[i] >= 0:
>                  t = v[i]
>              else:
>                  # negative so use 2's complement number
>                  t =  (2**w + v[i])
>              # shift previous result 'w' bits left and insert the new set
>              r = (r << w) + t
>          return r
>
>      def cut( v, w, n, signed = False):
>          ''' cut a flattened value up into a list of integers
>                  v: value
>                  w: width of element in bits
>                  n: number of elements
>                  signed: if True: interpret the 'cut w' bits as a 2's
> complement representation
>          '''
>          r = [ 0 for _ in range(n)]
>          for i in range(n):
>              # mask out the 'w' lowest bits
>              t = v & (2**w - 1)
>              if signed:
>                  # test highest bit
>                  if t & 2**(w-1):
>                      #negative, convert 2's complement number
>                      r[i] = t - 2**w
>                  else:
>                      r[i] = t
>              else:
>                  r[i] = t
>              # shift input value right by 'w' bits
>              v >>= w
>          return r
>
>
>      # construct the test data
>      if not USE_RANDOM:
>          # use a regular pattern?
>          tda = [[j + i for i in range(NBR_VECTORS)] for j in
> range(NBR_OPS)]
>          tdb = [[j + i for i in range(NBR_VECTORS-1,-1,-1)] for j in
> range(NBR_OPS-1,-1,-1)]
>      else:
>          # perhaps random is better ...
>          random.seed('This gives us repeatable randomness')
>          tda = [[random.randrange(2**WIDTH_D) for _ in
> range(NBR_VECTORS)] for __ in range(NBR_OPS)]
>          tdb = [[random.randrange(2**WIDTH_D) for _ in range(NBR_VECTORS-
> 1,-1,-1)] for __ in range(NBR_OPS-1,-1,-1)]
>
>      print( 'tda: {}'.format( tda))
>      print( 'tdb: {}'.format( tdb))
>
>      # calculate the expected result
>      print ('expected result:', end = " ")
>      r  = [ [0 for i in range(NBR_VECTORS)] for j in range(NBR_OPS)]
>      for j in range(NBR_OPS):
>          for i in range(NBR_VECTORS):
>              r[j][i] = (tda[j][i] * COEFF[i][0] + tdb[j][i] * COEFF[i]
> [1])
>      print( r )
>
>      print('received Q:     ', end = ' ')
>      rq =[None for _ in range(NBR_OPS)]
>
>      dut = loc( NBR_VECTORS, Clk, DA, DB, Q )
>
>      tCK = 10
>      @instance
>      def clkgen():
>          while True:
>              Clk.next = 1
>              yield delay( int( tCK / 2 ))
>              Clk.next = 0
>              yield delay( int( tCK / 2 ))
>
>      @instance
>      def stimulus():
>          DA.next = 0
>          DB.next = 0
>          yield Clk.posedge
>          yield delay(int( tCK / 4 ))
>          for j in range(NBR_OPS):
>              DA.next = flatten( tda[j], WIDTH_D)
>              DB.next = flatten( tdb[j], WIDTH_D)
>              yield Clk.posedge
>              yield delay(0)
>              #check the result
>              rq[j] = cut(int(Q), WIDTH_Q, NBR_VECTORS)
> #             print( cut(int(Q), WIDTH_Q, NBR_VECTORS), end = ' ' ) #
> this doesn't work?
>              for i in range(NBR_VECTORS):
>                  if rq[j][i] != r[j][i]:
>                      print( 'Failure: j {}, i {} -> received {} !=
> expected {}'.format( j, i, rq[j][i], r[j][i]))
>              yield delay(int( tCK / 4 ))
>          print( rq )
>          yield Clk.posedge
>          raise StopSimulation
>
>      return dut, clkgen, stimulus
>
>
> def convert():
>      toVHDL(loc, NBR_VECTORS, Clk, DA, DB, Q )
>      toVerilog(loc, NBR_VECTORS, Clk, DA, DB, Q )
>
>
> if __name__ == '__main__':
>      def simulate(timesteps, mainclass):
>          """Runs simulation for MyHDL Class"""
>          # Remove old .vcd file, otherwise we get a list of renamed .vcd
> files lingering about
>          filename = (mainclass.__name__ +".vcd")
>          if os.access(filename,  os.F_OK):
>              os.unlink(filename)
>
>          # Run Simulation
>          tb = traceSignals(mainclass)
>          sim = Simulation(tb)
>          sim.run(timesteps)
>
>      NBR_OPS = 8
>      NBR_VECTORS = 2
>      USE_RANDOM = True
>      COEFF = [ [i+1,i+2] for i in range(NBR_VECTORS)]
>      # select how to describe the coefficients
>      USE_COEFF_INT , USE_COEFF_INTBV , USE_COEFF_SIGNAL = [ False, False,
> True]
>
>      WIDTH_D = 8
>      WIDTH_C = 4 # >= log2(NBR_VECTORS+2), but keep to multiples of 4,
> this makes viewing hex-values in the waveform a lot easier
>      WIDTH_Q = WIDTH_D + WIDTH_C
>
>      Clk = Signal(bool(0))
>      # flattened vectors as input
>      DA  = Signal( intbv()[WIDTH_D * NBR_VECTORS :])
>      DB  = Signal( intbv()[WIDTH_D * NBR_VECTORS :])
>      # and as output
>      Q   = Signal( intbv()[WIDTH_Q * NBR_VECTORS :])
>
>      simulate( 3000 , tb_loc)
>      convert()
> ```
> I understand that using _ints_ or _intbvs_ doesn't work, as it is not
> (yet) supported. But in the case of the _Signals_ am I wrong to expect
> _initialised_ signals in the converted code?
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] List Of Constants

[Josy B. <jos...@gm...>]

In VHDL we can pass constants in the generic section.
I mimic that in MyHDL by passing constants as the first arguments in the 
function call. Until now I have always used singular constants to do 
this, but now had the case where a List Of Constants looked more 
appealing than writing each one apart.
So I threw in a list an passed that to the function. 
The simulation works fine. But the conversion fails depending on the 
contents of the list: 
* plain ints, intbvs: raise an exception 
```text
myhdl.ConversionError: in file 
C:\qdesigns\MyHDL\Source\issues\ListOfConstants\ListOfConstants.py, line 
32:
    Object type is not supported in this context: Coeff, <type 'list'>
```
* Signals,: the conversion finishes, but the converted code generates 
uninitialized signals (wires in Verilog)
```VHDL
	type t_array_components_1_Coeff is array (0 to 2 - 1) of 
unsigned(3 downto 0);
	signal components_1_Coeff : t_array_components_1_Coeff;
	type t_array_components_0_Coeff is array (0 to 2 - 1) of 
unsigned(3 downto 0);
	signal components_0_Coeff : t_array_components_0_Coeff;
```
The workaround was returning to spelling out every constant in the call.

I distilled a (self-contained this time) example program showing my 
intent:
```python
'''
Created on 14 Mar 2015

@author: Josy
'''


from __future__ import print_function
import os, random
from myhdl import *


def flattenlov(D, Q):
    ''' a simple utility to turn a list of vectors into a flattened 
vector '''
    # in theory, ConcatSignal() would be usable too,
    # but that constructs a new Signal, so we would still need
    # an @always_comb to assign that newly created Signal to the output 
Signal
    LNBR_VECTORS = len(D)
    LWIDTH_D = len(D[0])
    @always_comb
    def flattenlov():
        for i in range(LNBR_VECTORS):
            Q.next[(i+1) * LWIDTH_D : i * LWIDTH_D ] = D[i]
    return flattenlov


def simplefunc( Coeff, Clk, DA, DB, Q):
    ''' a simple operation, just for the effect ... '''

    @always_seq( Clk.posedge, reset = None)
    def calc():
        Q.next = Coeff[0] * DA + Coeff[1] * DB

    return calc


def loc( NBR_VECTORS, Clk, DA, DB, Q ):
    """
        List Of Constants
        DA, DB and Q are flattened Lists Of Vectors
    """

    # derive a few constants
    LWIDTH_D = len(DA) / NBR_VECTORS
    LWIDTH_Q = len(Q) / NBR_VECTORS
    LWIDTH_C = LWIDTH_Q - LWIDTH_D

    # must split input data into list Of Vectors
    lova = [ DA((i+1) * LWIDTH_D, i * LWIDTH_D) for i in 
range(NBR_VECTORS)]
    lovb = [ DB((i+1) * LWIDTH_D, i * LWIDTH_D) for i in 
range(NBR_VECTORS)]
    # we use a List Of Vectors to collect the results too
    result = [ Signal( intbv(0)[LWIDTH_Q:]) for _ in range(NBR_VECTORS)]

    # for testing our 'options', we use a local variable for the 
coefficients
    if USE_COEFF_INT:
        # this simulates, but doesn't convert
        LCOEFF = COEFF
    elif USE_COEFF_INTBV:
        # this simulates as well, but doesn't convert either
        LCOEFF = [ [intbv(COEFF[i][0])[LWIDTH_C:], intbv(COEFF[i][1])
[LWIDTH_C:]] for i in range(NBR_VECTORS)]
    elif USE_COEFF_SIGNAL:
        # this simulates _and_ converts, but the conversion doesn't work 
...
        LCOEFF = [ [Signal(intbv(COEFF[i][0])[LWIDTH_C:]), 
Signal(intbv(COEFF[i][1])[LWIDTH_C:])] for i in range(NBR_VECTORS)]

    # instantiate as many 'simple functions' as vectors in the input
    components = []
    for i in range( NBR_VECTORS ):
        components.append( simplefunc(LCOEFF[i], Clk, lova[i], lovb[i], 
result[i]))

    # must flatten collected results into the output vector
    components.append( flattenlov( result, Q ))

    return  components


def tb_loc():
    ''' testing '''

    # helper routines to build/disassemble the flattened in- and out-put 
vectors
    def flatten( v , w):
        ''' flattens a list of integer values
                v: list
                w: width of element in bits
            assume that the values fit in the given bit-width 'w'
         '''
        r = 0
        # start with Most Significant Value (or at end of list)
        for i in range(len(v)-1,-1,-1):
            if v[i] >= 0:
                t = v[i]
            else:
                # negative so use 2's complement number
                t =  (2**w + v[i])
            # shift previous result 'w' bits left and insert the new set
            r = (r << w) + t
        return r

    def cut( v, w, n, signed = False):
        ''' cut a flattened value up into a list of integers
                v: value
                w: width of element in bits
                n: number of elements
                signed: if True: interpret the 'cut w' bits as a 2's 
complement representation
        '''
        r = [ 0 for _ in range(n)]
        for i in range(n):
            # mask out the 'w' lowest bits
            t = v & (2**w - 1)
            if signed:
                # test highest bit
                if t & 2**(w-1):
                    #negative, convert 2's complement number
                    r[i] = t - 2**w
                else:
                    r[i] = t
            else:
                r[i] = t
            # shift input value right by 'w' bits
            v >>= w
        return r


    # construct the test data
    if not USE_RANDOM:
        # use a regular pattern?
        tda = [[j + i for i in range(NBR_VECTORS)] for j in 
range(NBR_OPS)]
        tdb = [[j + i for i in range(NBR_VECTORS-1,-1,-1)] for j in 
range(NBR_OPS-1,-1,-1)]
    else:
        # perhaps random is better ...
        random.seed('This gives us repeatable randomness')
        tda = [[random.randrange(2**WIDTH_D) for _ in 
range(NBR_VECTORS)] for __ in range(NBR_OPS)]
        tdb = [[random.randrange(2**WIDTH_D) for _ in range(NBR_VECTORS-
1,-1,-1)] for __ in range(NBR_OPS-1,-1,-1)]

    print( 'tda: {}'.format( tda))
    print( 'tdb: {}'.format( tdb))

    # calculate the expected result
    print ('expected result:', end = " ")
    r  = [ [0 for i in range(NBR_VECTORS)] for j in range(NBR_OPS)]
    for j in range(NBR_OPS):
        for i in range(NBR_VECTORS):
            r[j][i] = (tda[j][i] * COEFF[i][0] + tdb[j][i] * COEFF[i]
[1])
    print( r )

    print('received Q:     ', end = ' ')
    rq =[None for _ in range(NBR_OPS)]

    dut = loc( NBR_VECTORS, Clk, DA, DB, Q )

    tCK = 10
    @instance
    def clkgen():
        while True:
            Clk.next = 1
            yield delay( int( tCK / 2 ))
            Clk.next = 0
            yield delay( int( tCK / 2 ))

    @instance
    def stimulus():
        DA.next = 0
        DB.next = 0
        yield Clk.posedge
        yield delay(int( tCK / 4 ))
        for j in range(NBR_OPS):
            DA.next = flatten( tda[j], WIDTH_D)
            DB.next = flatten( tdb[j], WIDTH_D)
            yield Clk.posedge
            yield delay(0)
            #check the result
            rq[j] = cut(int(Q), WIDTH_Q, NBR_VECTORS)
#             print( cut(int(Q), WIDTH_Q, NBR_VECTORS), end = ' ' ) # 
this doesn't work?
            for i in range(NBR_VECTORS):
                if rq[j][i] != r[j][i]:
                    print( 'Failure: j {}, i {} -> received {} != 
expected {}'.format( j, i, rq[j][i], r[j][i]))
            yield delay(int( tCK / 4 ))
        print( rq )
        yield Clk.posedge
        raise StopSimulation

    return dut, clkgen, stimulus


def convert():
    toVHDL(loc, NBR_VECTORS, Clk, DA, DB, Q )
    toVerilog(loc, NBR_VECTORS, Clk, DA, DB, Q )


if __name__ == '__main__':
    def simulate(timesteps, mainclass):
        """Runs simulation for MyHDL Class"""
        # Remove old .vcd file, otherwise we get a list of renamed .vcd 
files lingering about
        filename = (mainclass.__name__ +".vcd")
        if os.access(filename,  os.F_OK):
            os.unlink(filename)

        # Run Simulation
        tb = traceSignals(mainclass)
        sim = Simulation(tb)
        sim.run(timesteps)

    NBR_OPS = 8
    NBR_VECTORS = 2
    USE_RANDOM = True
    COEFF = [ [i+1,i+2] for i in range(NBR_VECTORS)]
    # select how to describe the coefficients
    USE_COEFF_INT , USE_COEFF_INTBV , USE_COEFF_SIGNAL = [ False, False, 
True]

    WIDTH_D = 8
    WIDTH_C = 4 # >= log2(NBR_VECTORS+2), but keep to multiples of 4, 
this makes viewing hex-values in the waveform a lot easier
    WIDTH_Q = WIDTH_D + WIDTH_C

    Clk = Signal(bool(0))
    # flattened vectors as input
    DA  = Signal( intbv()[WIDTH_D * NBR_VECTORS :])
    DB  = Signal( intbv()[WIDTH_D * NBR_VECTORS :])
    # and as output
    Q   = Signal( intbv()[WIDTH_Q * NBR_VECTORS :])

    simulate( 3000 , tb_loc)
    convert()
```
I understand that using _ints_ or _intbvs_ doesn't work, as it is not 
(yet) supported. But in the case of the _Signals_ am I wrong to expect 
_initialised_ signals in the converted code?

Re: [myhdl-list] GSOC 2015

[Christopher F. <chr...@gm...>]

Ravi,

Hello and welcome to MyHDL.  For the GSoC this year
we have two groups of projects:

    1. Contributions to MyHDL
    2. Implementing "cores" with MyHDL

Our idea page is available here:
http://dev.myhdl.org/gsoc/gsoc_2015.html

I also see you posted to IRC, I will try and catch
you and IRC and we can discuss further.

Regards,
Chris

On 3/14/15 5:33 PM, Ravi Jain wrote:
> Hello,
> I am Ravi Jain, a student from India pursuing electronics engineering
> from National Institute of Technology, Surat. I am looking to
> participate in GSOC 2015 and i came across this project and got interested.
> I am a quick learner and have a good experience of working on a big
> project in Java language. Recently i have started using python and feel
> pretty comfortable with it. I also have a experience of working on
> hardware and have done projects using AVR and TIVA if that helps.
> Currently i have setup myhdl and have been going through the manual. It
> would be great if you point me to a small bug/enhancement to get started
> and settle in.
>
> Thanks,
> Ravi Jain
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
>

[myhdl-list] GSOC 2015

[Ravi J. <rav...@gm...>]

Hello,
I am Ravi Jain, a student from India pursuing electronics engineering 
from National Institute of Technology, Surat. I am looking to 
participate in GSOC 2015 and i came across this project and got interested.
I am a quick learner and have a good experience of working on a big 
project in Java language. Recently i have started using python and feel 
pretty comfortable with it. I also have a experience of working on 
hardware and have done projects using AVR and TIVA if that helps.
Currently i have setup myhdl and have been going through the manual. It 
would be great if you point me to a small bug/enhancement to get started 
and settle in.

Thanks,
Ravi Jain

Re: [myhdl-list] Generating 160 bit signal

[Christopher F. <chr...@gm...>]

On 3/13/2015 2:56 PM, Edward Vidal wrote:
> Chris,
> I made some changes to flaten.py at https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/flaten.py.  I added a random number for testing.  This needs .signed() to work.   Is this only for Python?  In your example you  started adding  values at the MSB is this the preferred method?

Not sure what you mean, "Only for Python?".  The
example should be convertible.  But you would
need a top-level wrapper, list-of-signals are
not convertible as a top-level port.

Why does it need "signed" to work?  It is weird to
concat signed values.  The result, you might want
it to be signed but the intermediate bits being
concat'd shouldn't need to be signed (am I missing
something?).

The msb or lsb would be application dependent not
a preference, I simply chose one for the example.
you can use `*reverse` to flip the lsb-msb.

Regards,
Chris


>
> On Thursday, March 12, 2015 12:45 PM, Christopher Felton <chr...@gm...> wrote:
>
>
>
>
> On 3/7/2015 4:12 PM, Edward Vidal wrote:
>> Hello All,
>> Trying to take 16 values from an image to generate 160 bit signal
>>
> Here is an example that might help.  Differs from yours
> in that it uses ShadowSignals and elaboration to build
> the "flat" representation.  The example uses an 8x5
> matrix of 8bit signals and creates a 160 bit flat
> version of the 4 lsb from each matrix element.
>
>       def m_flatten(matrix, flat):
>           _flat = ConcatSignal(*[col(4,0) for row in matrix
>                                           for col in row])
>           @always_comb
>           def rtl():
>               flat.next = _flat
>           return rtl
>
>
>       def test_flatten():
>           matrix = [[Signal(intbv(0)[8:]) for col in range(5)]
>                                           for row in range(8)]
>           flat = Signal(intbv(0)[160:])
>           tbdut = m_flatten(matrix, flat)
>           @instance
>           def tbstim():
>               yield delay(1)
>               print(bin(flat, 160))
>               assert flat == 0
>               matrix[0][0].next = 0x8
>               yield delay(1)
>               print(bin(flat, 160))
>               assert flat[160-1] == 1
>           return tbdut, tbstim
>       Simulation(test_flatten()).run()
>
> https://gist.github.com/cfelton/d52fc4abe8d50b73c13c
>
> <snip>
>
>> Most of the time it works
>> working okay generates a signal of 160
> <snip>
>
>> ValueError: intbv value -4 < minimum 0
>
> I believe the error you are seeing can be explained
> with this little example:
>
>       x = intbv(0)[16:]
>       y = intbv(0, min=-128, max=128)
>       z = intbv(0, min=0, max=256)
>
>       # this will work
>       x[:] = (y << 8) | z
>       print(x)
>
>
>       # this will fail
>       y[:] = -8
>       x[:] = (y << 8) | z
>       print(x)
>
>
>       # this will work
>       y[:] = 118
>       x[:] = (y << 8) | z
>       print(x)
>
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Tool to cosimulate VHDL in Vivado

[Henry G. <he...@ca...>]

On 13/03/15 20:34, Henry Gomersall wrote:
> On 11/03/15 17:27, Henry Gomersall wrote:
> Enum signals are not currently supported.

To be clear, they're only not supported with the Vivado cosim bit. They 
work in the rest of the code, including the myhdl cosimulation.

Cheers,

Henry

Re: [myhdl-list] Tool to cosimulate VHDL in Vivado

[Henry G. <he...@ca...>]

On 11/03/15 17:27, Henry Gomersall wrote:
> I've written a tool to do behavioural cosimulation of synchronous VHDL
> code using the Vivado simulator.

This is now published at:

https://github.com/hgomersall/Veriutils

It took a while longer than expected to get Interfaces working (and even 
then, only to one level) - there is a bug in the conversion whereby 
signals are missed if they're only used in a vhdl_code block.

Enum signals are not currently supported.

Please liberally submit pull requests! (with tests :)

It's not currently packaged as I need to go and eat my dinner. Hopefully 
I'll get around to it soon.

Cheers,

Henry

Re: [myhdl-list] Generating 160 bit signal

[Edward V. <dev...@sb...>]

Chris,
I made some changes to flaten.py at https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/flaten.py.  I added a random number for testing.  This needs .signed() to work.   Is this only for Python?  In your example you  started adding  values at the MSB is this the preferred method?
Regards 

  


 
Edward Vidal Jr.
e-mail dev...@sb...
915-595-1613


On Thursday, March 12, 2015 12:45 PM, Christopher Felton <chr...@gm...> wrote:
 



On 3/7/2015 4:12 PM, Edward Vidal wrote:
> Hello All,
> Trying to take 16 values from an image to generate 160 bit signal
>
Here is an example that might help.  Differs from yours
in that it uses ShadowSignals and elaboration to build
the "flat" representation.  The example uses an 8x5
matrix of 8bit signals and creates a 160 bit flat
version of the 4 lsb from each matrix element.

     def m_flatten(matrix, flat):
         _flat = ConcatSignal(*[col(4,0) for row in matrix
                                         for col in row])
         @always_comb
         def rtl():
             flat.next = _flat
         return rtl


     def test_flatten():
         matrix = [[Signal(intbv(0)[8:]) for col in range(5)]
                                         for row in range(8)]
         flat = Signal(intbv(0)[160:])
         tbdut = m_flatten(matrix, flat)
         @instance
         def tbstim():
             yield delay(1)
             print(bin(flat, 160))
             assert flat == 0
             matrix[0][0].next = 0x8
             yield delay(1)
             print(bin(flat, 160))
             assert flat[160-1] == 1
         return tbdut, tbstim
     Simulation(test_flatten()).run()

https://gist.github.com/cfelton/d52fc4abe8d50b73c13c

<snip>

> Most of the time it works
> working okay generates a signal of 160
<snip>

> ValueError: intbv value -4 < minimum 0

I believe the error you are seeing can be explained
with this little example:

     x = intbv(0)[16:]
     y = intbv(0, min=-128, max=128)
     z = intbv(0, min=0, max=256)

     # this will work
     x[:] = (y << 8) | z
     print(x)


     # this will fail
     y[:] = -8
     x[:] = (y << 8) | z
     print(x)


     # this will work
     y[:] = 118
     x[:] = (y << 8) | z
     print(x)


Regards,
Chris



------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Generating 160 bit signal

[Christopher F. <chr...@gm...>]

On 3/7/2015 4:12 PM, Edward Vidal wrote:
> Hello All,
> Trying to take 16 values from an image to generate 160 bit signal
>
Here is an example that might help.  Differs from yours
in that it uses ShadowSignals and elaboration to build
the "flat" representation.  The example uses an 8x5
matrix of 8bit signals and creates a 160 bit flat
version of the 4 lsb from each matrix element.

     def m_flatten(matrix, flat):
         _flat = ConcatSignal(*[col(4,0) for row in matrix
                                         for col in row])
         @always_comb
         def rtl():
             flat.next = _flat
         return rtl


     def test_flatten():
         matrix = [[Signal(intbv(0)[8:]) for col in range(5)]
                                         for row in range(8)]
         flat = Signal(intbv(0)[160:])
         tbdut = m_flatten(matrix, flat)
         @instance
         def tbstim():
             yield delay(1)
             print(bin(flat, 160))
             assert flat == 0
             matrix[0][0].next = 0x8
             yield delay(1)
             print(bin(flat, 160))
             assert flat[160-1] == 1
         return tbdut, tbstim
     Simulation(test_flatten()).run()

https://gist.github.com/cfelton/d52fc4abe8d50b73c13c

<snip>

> Most of the time it works
> working okay generates a signal of 160
<snip>
> ValueError: intbv value -4 < minimum 0

I believe the error you are seeing can be explained
with this little example:

     x = intbv(0)[16:]
     y = intbv(0, min=-128, max=128)
     z = intbv(0, min=0, max=256)

     # this will work
     x[:] = (y << 8) | z
     print(x)


     # this will fail
     y[:] = -8
     x[:] = (y << 8) | z
     print(x)


     # this will work
     y[:] = 118
     x[:] = (y << 8) | z
     print(x)


Regards,
Chris

Re: [myhdl-list] Tool to cosimulate VHDL in Vivado

[Henry G. <he...@ca...>]

On 12/03/15 15:46, Christopher Felton wrote:
> <snip>
>> >
>> >This email is really to see if there is interest in me packaging this up
>> >and releasing it. The code is written to be solid and it has a complete
>> >test bench.
> Yes, I think you should github it and package it
> up.
>
>> >I suspect that it can be easily modified to support Verilog, and I
>> >daresay much of the effort would be applicable to other simulators that
>> >are not VPI/VHPI compliant.
> If I understand correctly, shouldn't this package
> be language agnotstic (whatever is simulated
> externally?).  Isn't the input to the external
> simulated a collection of VCD(?) stimulus and
> capture?

Not currently, though having found out properly about VCD files today, 
perhaps that would have been a better idea*.

The implementation is a generator from a LUT with a VHDL file writer 
(essentially implementing my own synchronous signal output file). This 
makes it VHDL specific, but it would be simple to write the equivalent 
for Verilog. It's not complicated, but it does work.

I'll stick it on github so you can critique it properly. Give me an hour 
or so...

Cheers,

Henry

*It's really frustrating to find this, which I did by stumbling across 
the relevant tcl commands for Vivado - it's not like I didn't make a 
concerted effort to work out the standard way of reading/writing signals 
from a simulator. That said, I still can't work out whether there is any 
way to read from a VCD file in the simulation. The FPGA world is very 
hard to penetrate.

Re: [myhdl-list] Tool to cosimulate VHDL in Vivado

[Christopher F. <chr...@gm...>]

<snip>
>
> This email is really to see if there is interest in me packaging this up
> and releasing it. The code is written to be solid and it has a complete
> test bench.

Yes, I think you should github it and package it
up.

> I suspect that it can be easily modified to support Verilog, and I
> daresay much of the effort would be applicable to other simulators that
> are not VPI/VHPI compliant.

If I understand correctly, shouldn't this package
be language agnotstic (whatever is simulated
externally?).  Isn't the input to the external
simulated a collection of VCD(?) stimulus and
capture?


Regards,
Chris

Re: [myhdl-list] Tool to cosimulate VHDL in Vivado

[Tim B. <tim...@so...>]

Hi Henry,

> I've written a tool to do behavioural cosimulation of synchronous VHDL
> code using the Vivado simulator.
That grabbed my attention!
>
> It's probably more accurately quasi-cosimulation as what it actually
> does is runs a MyHDL reference design and records all the inputs and the
> outputs at each clock cycle, then runs a device under test inside Vivado
> through the tcl interface, playing back to it the recorded inputs. The
> tool then returns the resultant set of outputs from both simulations for
> comparison.
>
> There is an equivalent tool for cosimulating myhdl models with other
> myhdl models, so in principle it should be a simple case of writing the
> test suite for myhdl development, then trivially switching the test
> function to use Vivado.
>
> The real win of this approach is it opens up the facility of a free
> simulator in order to do behavioural verification of MyHDL models of
> encrypted IP (most of the IP that is now shipped with Vivado). It's
> still necessary to have the MyHDL model, but at least the loop is now
> closed.
>
> I've also written a set of support functions for common things like
> clock generation and random input generation for use in this framework.
>
> This email is really to see if there is interest in me packaging this up
> and releasing it. The code is written to be solid and it has a complete
> test bench.
I don't have access to a supported VPI/VHPI simulator, and that was one 
of the main stumbling blocks for me having a real go with MyHDL. I'd be 
very interested in this.
>
> I suspect that it can be easily modified to support Verilog, and I
> daresay much of the effort would be applicable to other simulators that
> are not VPI/VHPI compliant.
>
> Cheers,
>
> Henry
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

-- 

Senior Design Engineer
Somerdata Ltd
1 Riverside Business Park
St Annes Road
Bristol
BS4 4ED

Tel: +44 (0)117 9634050
Fax: +44 (0)117 3302929

E-mail: tim...@so...
Website: www.somerdata.com

Re: [myhdl-list] Tool to cosimulate VHDL in Vivado

[Euripedes R. F. <roc...@gm...>]

Hi Henry,
even not working to much in Vivado in this moment, I would like to see and
test this approach some time in future.

regards

2015-03-11 14:27 GMT-03:00 Henry Gomersall <he...@ca...>:

> I've written a tool to do behavioural cosimulation of synchronous VHDL
> code using the Vivado simulator.
>
> It's probably more accurately quasi-cosimulation as what it actually
> does is runs a MyHDL reference design and records all the inputs and the
> outputs at each clock cycle, then runs a device under test inside Vivado
> through the tcl interface, playing back to it the recorded inputs. The
> tool then returns the resultant set of outputs from both simulations for
> comparison.
>
> There is an equivalent tool for cosimulating myhdl models with other
> myhdl models, so in principle it should be a simple case of writing the
> test suite for myhdl development, then trivially switching the test
> function to use Vivado.
>
> The real win of this approach is it opens up the facility of a free
> simulator in order to do behavioural verification of MyHDL models of
> encrypted IP (most of the IP that is now shipped with Vivado). It's
> still necessary to have the MyHDL model, but at least the loop is now
> closed.
>
> I've also written a set of support functions for common things like
> clock generation and random input generation for use in this framework.
>
> This email is really to see if there is interest in me packaging this up
> and releasing it. The code is written to be solid and it has a complete
> test bench.
>
> I suspect that it can be easily modified to support Verilog, and I
> daresay much of the effort would be applicable to other simulators that
> are not VPI/VHPI compliant.
>
> Cheers,
>
> Henry
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] Tool to cosimulate VHDL in Vivado

[Henry G. <he...@ca...>]

I've written a tool to do behavioural cosimulation of synchronous VHDL 
code using the Vivado simulator.

It's probably more accurately quasi-cosimulation as what it actually 
does is runs a MyHDL reference design and records all the inputs and the 
outputs at each clock cycle, then runs a device under test inside Vivado 
through the tcl interface, playing back to it the recorded inputs. The 
tool then returns the resultant set of outputs from both simulations for 
comparison.

There is an equivalent tool for cosimulating myhdl models with other 
myhdl models, so in principle it should be a simple case of writing the 
test suite for myhdl development, then trivially switching the test 
function to use Vivado.

The real win of this approach is it opens up the facility of a free 
simulator in order to do behavioural verification of MyHDL models of 
encrypted IP (most of the IP that is now shipped with Vivado). It's 
still necessary to have the MyHDL model, but at least the loop is now 
closed.

I've also written a set of support functions for common things like 
clock generation and random input generation for use in this framework.

This email is really to see if there is interest in me packaging this up 
and releasing it. The code is written to be solid and it has a complete 
test bench.

I suspect that it can be easily modified to support Verilog, and I 
daresay much of the effort would be applicable to other simulators that 
are not VPI/VHPI compliant.

Cheers,

Henry

Re: [myhdl-list] Generating 160 bit signal

[Jan <jen...@mu...>]

On Sat, 7 Mar 2015 14:12:06 -0800
Edward Vidal <dev...@sb...> wrote:

> Hello All,
> Trying to take 16 values from an image to generate 160 bit signal

Why?

Jan Coombs. 

[myhdl-list] Generating 160 bit signal

[Edward V. <dev...@sb...>]

Hello All,
Trying to take 16 values from an image to generate 160 bit signal

lft_s_i.next = ((r[row+31][col] << W0*15) | (r[row+29][col] << W0*14) | 
(r[row+27][col] << W0*13) | (r[row+25][col] << W0*12) | 
(r[row+23][col] << W0*11) | (r[row+21][col] << W0*10) | 
(r[row+19][col] << W0*9) | (r[row+17][col] << W0*8) | 
(r[row+15][col] << W0*7) | (r[row+13][col] << W0*6) | 
(r[row+11][col] << W0*5) | (r[row+9][col] << W0*4) | 
(r[row+7][col] << W0*3) | (r[row+5][col] << W0*2) | 
(r[row+3][col] << W0*1) | (r[row-1][col] ))

Also works most of time with + instead | 

Most of the time it works 
working okay generates a signal of 160
1111100001000010000011111000001111100000111110000011111000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
1111100000111110000011111000001110100000111010000011111000001111100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
10000100000111110000100001000001111100000111110000011111000001111100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
This causes the error the signal needs 157 more bits
100
100
100
Traceback (most recent call last):
  File "test_bench_array_jpeg.py", line 482, in <module>
    sim.run()
  File "/usr/lib/python2.7/site-packages/myhdl/_Simulation.py", line 132, in run
    waiter.next(waiters, actives, exc)
  File "/usr/lib/python2.7/site-packages/myhdl/_Waiter.py", line 141, in next
    clause = self.generator.next()
  File "test_bench_array_jpeg.py", line 344, in stimulus
    lft_s_i.next = ((r[row+31][col] << W0*15) | (r[row+29][col] << W0*14) | (r[row+27][col] << W0*13) | (r[row+25][col] << W0*12) | (r[row+23][col] << W0*11) | (r[row+21][col] << W0*10) | (r[row+19][col] << W0*9) | (r[row+17][col] << W0*8) | (r[row+15][col] << W0*7) | (r[row+13][col] << W0*6) | (r[row+11][col] << W0*5) | (r[row+9][col] << W0*4) | (r[row+7][col] << W0*3) | (r[row+5][col] << W0*2) | (r[row+3][col] << W0*1) | (r[row-1][col] ))
  File "/usr/lib/python2.7/site-packages/myhdl/_Signal.py", line 216, in _set_next
    self._setNextVal(val)
  File "/usr/lib/python2.7/site-packages/myhdl/_Signal.py", line 282, in _setNextIntbv
    self._next._handleBounds()
  File "/usr/lib/python2.7/site-packages/myhdl/_intbv.py", line 83, in _handleBounds
    (self._val, self._min))
ValueError: intbv value -4 < minimum 0

 All help is appreciated.


Edward Vidal Jr.
e-mail dev...@sb...
915-595-1613

Re: [myhdl-list] Broken link in FAQ

[Christopher F. <chr...@gm...>]

On 3/7/15 1:04 AM, Guy Eschemann wrote:
> In the FAQ section about "Why is the conversion output
> non-hierarchical?"Â [1], the "here" link seems to be broken.
>
> [1]Â
> http://www.myhdl.org/documentation/faq.html#why-is-the-conversion-output-non-hierarchical
>

Thanks,

The links are updated (might need to refresh browser).

Regards,
Chris

[myhdl-list] Broken link in FAQ

[Guy E. <guy...@gm...>]

In the FAQ section about "Why is the conversion output
non-hierarchical?" [1], the "here" link seems to be broken.

[1]
http://www.myhdl.org/documentation/faq.html#why-is-the-conversion-output-non-hierarchical

Regards,
Guy

Re: [myhdl-list] 0.9 development status

[Christopher F. <chr...@gm...>]

On 3/3/2015 3:49 PM, Jan Decaluwe wrote:
> Hello all:
>
> Development on github is going well :-)

I agree!

>
> I have just pushed commits to master so
> that *all tests pass on my local machine*.
>
> @jck How do we enable VHDL tests for travis?
>
> I would also like to run the tests under bugs/
> as part of the travis CI tests - these are
> specific tests for fixed bugs.

Another change since the move to github is
that the readthedocs/latest is built from the
master branch (seems ok).  The latest docs
include the 0.9 mods.  Should we add a simple
tag in the "What's new" bullets to indicated
released vs. not released?

Something like:

    * [dev] What's new in MyHDL 0.9

    * What's new in MyHDL 0.8

Regards,
Chris

http://docs.myhdl.org/en/latest/

Re: [myhdl-list] register-file with variable register size

[Christopher F. <chr...@gm...>]

On 3/6/2015 11:52 AM, SHEN Chen wrote:
<snip>
>
> Or even better, a reference implementation of register
> file in testcase, cookbook/examples would be helpful.

Possibly on myhdl.org here: http://www.myhdl.org/examples/

But we might have a hard time agreeing which
would be the appropriate example :)

In my case, I wanted "ease of use", so I created a
framework that I can easily define a register file,
example:

     rf = RegiserFile()

     reg = Register('control', 0x00, 'rw', 0x01)
     reg.add_named_bits('enable', slice(1,0), 'enable peripheral')
     rf.add_register(reg)

     reg = Register('status', 0x01, 'ro', 0x00)
     rf.add_register(reg)

And then in the peripheral you simply:

     def m_peripheral(...)
         # "rf" from above
         # get the logic for the regbus interface
         g_regbus = rf.m_per_interface(glbl, regbus,
                                   base_address=0x2000)
        ...
        @always_seq(...)
        def ex():
            if rf.enable:
            ...

And that is it, you do not need to code any specific
register access in the module, I think it is simplistic
to use.  The down side is that general solutions are,
often, not optimal, I wanted it to work and was not
concerned with it being optimal or supporting tons of
features. (

Also the above can be adapted for various
memory-mapped spec/protocols: wishbone, avalon,
amba, etc.  The peripheral is memmap bus agnostic:

     regbus = Wishbone()
     gp1 = m_periperal(glbl, regbus)
or
     regbus = Avalon()
     gp1 = m_peripheral(glbl, regbus)

This solution would not be a good reference example
because it does lots of extra "stuff".

Since we are all trying to do something slightly
different (how it is accessed, etc.) the best bet is
for someone to post their example and see :)

Regards,
Chris

Re: [myhdl-list] register-file with variable register size

[SHEN C. <she...@co...>]

 

Hi All, 

Being very new to MyHDL, and HDL in general, I just
realize that register file is a piece of code every one needs. 

MyHDL
seems to promise elegant solutions to code regfile, but no one seems to
have a perfect one yet. 

I was very much inspired by Chris's minnesota
code, but my current solution is similar to Josyb's
(https://github.com/josyb/ControlStatus). 

I got through with it in my
recent project (small FPGA design) but it's far from satisfactory. 

The
common problem we are having is with ShadowSignals. examples: 

 - issue
#2 (https://github.com/jandecaluwe/myhdl/issues/2) 

 - issue #10
(https://github.com/jandecaluwe/myhdl/issues/10) 

 - PR #11
(https://github.com/jandecaluwe/myhdl/pull/11) 

I think this is
something worth sorting out. 

It'd be nice to have a testcase
specifically dedicated to ShadowSignal on list of signals and on
ShadowSignals. 

Or even better, a reference implementation of register
file in testcase, cookbook/examples would be helpful. 

Any thoughts
about this? TIA. 

Regards,
shenchen 

On 2015-03-02 06:47, Christopher
Felton wrote: 

> On 2/13/15 9:09 AM, SHEN Chen wrote:
> 
>> Hi Chris,
In fact, I've read some of minnesota's source code yesterday, and find
it very inspiring. What I was trying to do is somewhat similar, but if I
understand the code correctly, you can not write to the read-only
register as a whole.
> 
> No, you should be able to write the read-only
register
> as a whole or via the "named-bits". But the register
> can
only be one or the other, either it is written by
> the "named-bits" or
the whole register - not both.
> 
>> For example, in test_regfile.py we
defined "status" as an 'ro' register, and declared a few named bits. We
can write to the individual bits, but not the "status" register as a
whole.
> 
> Correct, this is because there would be two processes
>
accessing the register. It would require some kind of
> arbitrator to
determine how the register is being
> modified. There might be an
elegant solution - but I
> have not thought of one?
> 
> In your case
this register-file builder wouldn't be
> useful, sounds like you might
need custom logic for
> each register definition.

-- 

SHEN Chen
General Manager
---------------------------------
Cogenda Co Ltd
SISPARK
II Room C102-1, 1355 Jinjihu Avenue, Suzhou, Jiangsu, China
Phone(Fax):
+86 512 67900636
Homepage: http://www.cogenda.com
 

Links:
------
[1]
http://goparallel.sourceforge.net/
[2]
mailto:myh...@li...
[3]
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] 0.9 development status

[Keerthan JC <jck...@gm...>]

There is still a failing test with GHDL.
https://travis-ci.org/jck/myhdl/jobs/52974694

On Tue, Mar 3, 2015 at 5:33 PM, Keerthan JC <jck...@gm...> wrote:

> I'll send a PR shortly.
>
> On Tue, Mar 3, 2015 at 4:49 PM, Jan Decaluwe <ja...@ja...> wrote:
>
>> Hello all:
>>
>> Development on github is going well :-)
>>
>> I have just pushed commits to master so
>> that *all tests pass on my local machine*.
>>
>> @jck How do we enable VHDL tests for travis?
>>
>> I would also like to run the tests under bugs/
>> as part of the travis CI tests - these are
>> specific tests for fixed bugs.
>>
>> Jan
>>
>> --
>> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>>      Python as a HDL: http://www.myhdl.org
>>      VHDL development, the modern way: http://www.sigasi.com
>>      World-class digital design: http://www.easics.com
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>
>
>
> --
> have a nice day
> -jck
>



-- 
have a nice day
-jck

Re: [myhdl-list] 0.9 development status

[Keerthan JC <jck...@gm...>]

I'll send a PR shortly.

On Tue, Mar 3, 2015 at 4:49 PM, Jan Decaluwe <ja...@ja...> wrote:

> Hello all:
>
> Development on github is going well :-)
>
> I have just pushed commits to master so
> that *all tests pass on my local machine*.
>
> @jck How do we enable VHDL tests for travis?
>
> I would also like to run the tests under bugs/
> as part of the travis CI tests - these are
> specific tests for fixed bugs.
>
> Jan
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>      Python as a HDL: http://www.myhdl.org
>      VHDL development, the modern way: http://www.sigasi.com
>      World-class digital design: http://www.easics.com
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
have a nice day
-jck

Re: [myhdl-list] combining values in signals

[Josy B. <jos...@gm...>]

Edward Vidal <develone <at> sbcglobal.net> writes:

> 
> 
> Josy r is not a Signal it is a sub band of an image it started out as 
list. See github
> develone/jpeg-2000-test/jpeg2k/parellel_jpeg/test_bench_array_jpeg.py 
typing on cell might ha
> have error. Regards thanks
> 

OK, I found the repository. Next time I'll check that first (if there is a 
link),
If you want to combine negative and positive numbers you have to 
explicitly convert negative numbers to their 2's complement first.
I assume that the positive numbers are < 2**(10-1)?
If you later want to extract a 10 bit value you have to explicitly convert 
the 2's complement into a normal integer to get the sign back.

Regards,

Josy

[myhdl-list] 0.9 development status

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

Hello all:

Development on github is going well :-)

I have just pushed commits to master so
that *all tests pass on my local machine*.

@jck How do we enable VHDL tests for travis?

I would also like to run the tests under bugs/
as part of the travis CI tests - these are
specific tests for fixed bugs.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com