myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] tristatesignal

[Günther S. <gue...@gm...>]

thank you very much.
looking forward for the fix.
regards,
guenther


Am 22.03.2015 um 16:46 schrieb SHEN Chen:
>> When i use TristateSignal with the function
>> traceSignals(), then i get this message:
>> ValueError: I2C_SDAT of module foo has no initial value
> This is a result of pull-request 21 (which fixes issue 19) in github.
>
> I encountered similar problem last week, but was too busy travelling
> around
> to commit my fix to it.
>
> Will test and raise PR asap.
>
> regards,
>
> shenchen
>
>
> ------------------------------------------------------------------------------
> 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] tristatesignal

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

> When i use TristateSignal with the function
> traceSignals(), then i get this message:
> ValueError: I2C_SDAT of module foo has no initial value

This is a result of pull-request 21 (which fixes issue 19) in github.

I encountered similar problem last week, but was too busy travelling 
around
to commit my fix to it.

Will test and raise PR asap.

regards,

shenchen

[myhdl-list] thanks

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

Hello All,
I would like to thank, Chris Felton & Josy Boelen, for all the help they have provided me. I would also to like thank all the others that 
have posted on the MyHDL mailing list.  Each of you has provided different insights into VHDL issues.
Dave Vandenbout from Xess for his XulA2 board and his "FpgasNowWhatBook.pdf".
Each of you have helped me in getting me this far in VHDL.
A special thanks to Jan Decaluwe for writing MyHDL.
I started out with no prior Python experience and none in Hardware Definition Language.
I have programmed for many years, in assembly, forth, C, Pearl, TCL/Tk, and Java.
This by far has been the most challenging effort that I have ever undertaken.
Today I think, marks a milestone, for me. My test bench performs 16 parallel Lifting Scheme using the DWT.
The image that I started with was https://github.com/develone/jpeg-2000-test/blob/master/lena_256.png.
This was a 256 x 256 gray scale.  The test bench provided 
https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/sim_pass1_2.png which is the 1st level
Jpeg 2000 using the DWT.  
https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/test_bench_array_jpeg.py

Steps to run test bench

git clone gi...@gi...:develone/jpeg-2000-test.git
cd jpeg-2000-test/jpeg2k/parallel_jpeg/
cp ../../lena_256.png .
python test_bench_array_jpeg.py
Runs for almost 8 minutes on 6 core AMD running Fedora20.

This generates the sim_pass1_2.png
There is still so much todo, to be able to declare sucess. If you have any questions
I will be glad to help.
 Edward Vidal Jr.
e-mail dev...@sb...
915-595-1613

[myhdl-list] tristatesignal

[guenther s. <gue...@gm...>]

When i use TristateSignal with the function 
traceSignals(), then i get this message:
ValueError: I2C_SDAT of module foo has no initial value

Can anybody please help me how i can solve this problem?
Thank you very much.

Re: [myhdl-list] A newbie question about the sequential conversion example

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

On 3/20/2015 6:08 AM, Jeremy Herbert wrote:
> Hi all,
>
> I'm trying to get my head around myhdl, as I am definitely a python fan and
> I'd like to try and use it for verilog generation. But there is a little
> too much magic going on in one of the examples for me, and I was wondering
> if someone could help me out.
>
> I'm looking at the first example on
> http://docs.myhdl.org/en/latest/manual/conversion_examples.html#conv-usage
> under "A small sequential design". The first problem I have is that in the
> docstring of the Inc function it references a variable "n". But n is not
> present as function argument or anywhere in the code. Huh?

Yes, that is an error, we will get it fixed ASAP.

I believe what happened, is that the example originally
did have an "n" and then it was modified.

>
> Next, just below it, there is the following line:
>
> inc_inst = toVerilog(Inc, count, enable, clock, reset, n=n)
>
> The keyword argument 'n' is now set as equal to the variable n, which isn't
> defined and also isn't used in the Inc function. What's going on here?
> Where is this n coming from?

As you suspected, this is an error sorry for any
confusion.  The example should be stated as (remove
the `n`):


     from myhdl import *

     def Inc(count, enable, clock, reset):
         """ Incrementer with enable.
         count -- output
         enable -- control input, increment when 1
         clock -- clock input
         reset -- asynchronous reset input
         """

         @always_seq(clock.posedge, reset=reset)
         def incLogic():
             if enable:
                 count.next = count + 1

         return incLogic


     m = 8

     count = Signal(modbv(0)[m:])
     enable = Signal(bool(0))
     clock  = Signal(bool(0))
     reset = ResetSignal(0, active=0, async=True)

     inc_inst = Inc(count, enable, clock, reset)


     inc_inst = toVerilog(Inc, count, enable, clock, reset)
     ** ToVerilogWarning: Output port is read internally: count


Regards,
Chris

[myhdl-list] A newbie question about the sequential conversion example

[Jeremy H. <jer...@gm...>]

Hi all,

I'm trying to get my head around myhdl, as I am definitely a python fan and
I'd like to try and use it for verilog generation. But there is a little
too much magic going on in one of the examples for me, and I was wondering
if someone could help me out.

I'm looking at the first example on
http://docs.myhdl.org/en/latest/manual/conversion_examples.html#conv-usage
under "A small sequential design". The first problem I have is that in the
docstring of the Inc function it references a variable "n". But n is not
present as function argument or anywhere in the code. Huh?

Next, just below it, there is the following line:

inc_inst = toVerilog(Inc, count, enable, clock, reset, n=n)

The keyword argument 'n' is now set as equal to the variable n, which isn't
defined and also isn't used in the Inc function. What's going on here?
Where is this n coming from?

Any help would be very much appreciated!

Thanks,
Jeremy

Re: [myhdl-list] bit width questions

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

<snip>
> 2 of the signals in the test bench must be set as follows for the test
> bench to run to completion.
> W0 = 9
> res_out_x = Signal(intbv(0, min= -(2**(W0)) ,max= (2**(W0))))
> x is a temp signal used to create the 144 bit input signals.  Don't
> think this signal will ever go to the FPGA.
> x = Signal(intbv(0, min=-(2**(W0)), max=(2**(W0))))
> If these signals use, (W0-1) instead of (W0), I get overflow errors.

It all depends on the range of the values used, here you
are using [-512,512) (the actual max is 511).  If you use
(W0-1) you get have that range [-256,256), no value outside
that range can be assigned to the signal.

> Is this overflow error, because you need a bit for sign?
> How is the overflow handle when the code is put in the FPGA?

This is a verification operation, the overflow will not be
handled in the FPGA synthesis.  If you have decent coverage
with your testbench you can be reasonably confident it will
not happen in the design.

>
>
> The res_out_x is signed with the inputs being extracted from 3 144 bit
> signals and 1 80 bit signal which comes from rom_flags
> VHDL
> https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/jp_process.vhd
> Verilog
> https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/jp_process.v
>
> VHDL
> https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/m_flatten.vhd
> Verilog
> https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/m_flatten.v
> Currently all of the code is in the tb module.  The process uses large
> code segments that I would like to resuse  without coding in place.  Is
> there restrictions where in the file the code is for simulation?

In general no (I haven't looked over the code) you will import
the modules from the file.  It is common to group design files
(reusable components) if a file(s) and the tests in a separate
file.

Regards,
Chris

[myhdl-list] bit width questions

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

Hello All,

I am running a test bench https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/test_bench_array_jpeg.py
for my jpeg-2000 application.
2 of the signals in the test bench must be set as follows for the test bench to run to completion.
W0 = 9
res_out_x = Signal(intbv(0, min= -(2**(W0)) ,max= (2**(W0))))
x is a temp signal used to create the 144 bit input signals.  Don't think this signal will ever go to the FPGA.
x = Signal(intbv(0, min=-(2**(W0)), max=(2**(W0))))
If these signals use, (W0-1) instead of (W0), I get overflow errors.
Is this overflow error, because you need a bit for sign?
How is the overflow handle when the code is put in the FPGA?
 

The res_out_x is signed with the inputs being extracted from 3 144 bit signals and 1 80 bit signal which comes from rom_flags
VHDL
https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/jp_process.vhd
Verilog
https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/jp_process.v

VHDL
https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/m_flatten.vhd
Verilog
https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/m_flatten.v
Currently all of the code is in the tb module.  The process uses large code segments that I would like to resuse  without coding in place.  Is there restrictions where in the file the code is for simulation?

Steps to run test bench
runs for over 7 minutes on 6 core AMD.
git clone gi...@gi...:develone/jpeg-2000-test.git
cd jpeg-2000-test/jpeg2k/parallel_jpeg/
cp ../../lena_256.png .
python test_bench_array_jpeg.py Any and all help is appreciated. 
Edward Vidal Jr.
e-mail dev...@sb...
915-595-1613

Re: [myhdl-list] List Of Constants

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

<snip>
>
>       def m_initial_values(coef, coef_init):
>           assert isinstance(coef, list)
>           assert isinstance(coef_init, tuple)
>           N = len(coef)
>           @always_comb
>           def assign():
>               for ii in range(N):
>                   ival = coef_init[ii]
>                   coef.next = ival
>           return assign
>

Of course it should be

     coef[ii].next = ival


(should have written a test :)

Regards,
Chris

Re: [myhdl-list] List Of Constants

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

<snip>

Thanks, Chris

learned something today, again

Regards,

Josy

Re: [myhdl-list] List Of Constants

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

On 3/18/15 11:54 AM, Josy Boelen wrote:
>>>         x = [Signal(intbv(...) ...]
>>>         b = tuple(map(int, [round(1/N*xmax) for ...]))
>>>
>>>         def sop(N, x, b ):
>>>         <at> always_seq(clock.posedge, reset=reset)
>>>         def sop():
>>>             ssum = 0
>>>             for ii in range(N):
>>>    	      ssum = ssum + x[ii] * b[ii]
>>>             y.next = ssum
>>>         return sop
>>>
>>
>> No, even with the enhancement request the above would
>> not be converted because the index is not constant.
>> For that to be convertible the loop would need to be
>> unrolled.
>> <snip>
>
> Chris,
>
> did you trick me? :)

Not intentionally.

> I overlooked that fact. Aren't the two codes doing the same in the end?
> Or perhaps the second doesn't convert?
> In my code a loop would, almost always, be unrolled or rather be
> replaced by a, probably pipelined, tree-structure so the indexes would
> become constants.

They are doing the same thing in the end from a code
perspective but not from a hardware perspective.  The
only way to do the second is to unroll the loop with
literals or with initial value support.

You would need an array of signals in the converted
code with an initial (constant) value.  The initial
value support is too inconsistent across tools (best
of our knowledge).

The safe method, is to set the initial values your
self.

     def m_initial_values(coef, coef_init):
         assert isinstance(coef, list)
         assert isinstance(coef_init, tuple)
         N = len(coef)
         @always_comb
         def assign():
             for ii in range(N):
                 ival = coef_init[ii]
                 coef.next = ival
         return assign

Using a generic module like the above will let you
use the second version of code directly and then
you don't have to mess with the synthesis tools
inconsistent support of initial values.

Regards,
Chris

Re: [myhdl-list] List Of Constants

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

> >        x = [Signal(intbv(...) ...]
> >        b = tuple(map(int, [round(1/N*xmax) for ...]))
> >
> >        def sop(N, x, b ):
> >        <at> always_seq(clock.posedge, reset=reset)
> >        def sop():
> >            ssum = 0
> >            for ii in range(N):
> >   	      ssum = ssum + x[ii] * b[ii]
> >            y.next = ssum
> >        return sop
> >
> 
> No, even with the enhancement request the above would
> not be converted because the index is not constant.
> For that to be convertible the loop would need to be
> unrolled.
> <snip>

Chris,

did you trick me? :)
I overlooked that fact. Aren't the two codes doing the same in the end? 
Or perhaps the second doesn't convert? 
In my code a loop would, almost always, be unrolled or rather be 
replaced by a, probably pipelined, tree-structure so the indexes would 
become constants.

Best regards,

Josy

Re: [myhdl-list] List Of Constants

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

On 3/18/15 11:36 AM, Josy Boelen wrote:
>
>>> To me the prettiness of the VHDL or Verilog code is an indication of
> how
>>> 'good' the MyHDL code was drafted/converted.
>>
>> I strongly disagree, you are trading off readability
>> and pythonics in the MyHDL code for "prettier"
>> intermediate code.
>>
>> A similar example to yours is a straightfoward
>> sum-of products
>>
>>       x = [Signal(intbv(...) ...]
>>       b = tuple(map(int, [round(1/N*xmax) for ...]))
>>
>>        <at> always_seq(clock.posedge, reset=reset)
>>    	ssum = 0
>> 	for ii in range(N):
>>               c = b[ii]
>> 	    ssum = ssum + x[ii] * c
>>           y.next = ssum
>>
>> I wouldn't write the above any other way even though
>> the converted code will have the case embedded in the
>> process.
>>
>> <snip>
>
> You're quite right that for N being large the above approach is the only
> way. Imagine spelling out 64 constants all day long ...
> For the moment.
> When your (ours?) MEP_lite gets implemented, it will look like this
>        x = [Signal(intbv(...) ...]
>        b = tuple(map(int, [round(1/N*xmax) for ...]))
>
>        def sop(N, x, b ):
>        <at> always_seq(clock.posedge, reset=reset)
>        def sop():
>            ssum = 0
>            for ii in range(N):
>   	      ssum = ssum + x[ii] * b[ii]
>            y.next = ssum
>        return sop
>

No, even with the enhancement request the above would
not be converted because the index is not constant.
For that to be convertible the loop would need to be
unrolled.

Regards,
Chris

Re: [myhdl-list] List Of Constants

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

> > To me the prettiness of the VHDL or Verilog code is an indication of 
how
> > 'good' the MyHDL code was drafted/converted.
> 
> I strongly disagree, you are trading off readability
> and pythonics in the MyHDL code for "prettier"
> intermediate code.
> 
> A similar example to yours is a straightfoward
> sum-of products
> 
>      x = [Signal(intbv(...) ...]
>      b = tuple(map(int, [round(1/N*xmax) for ...]))
> 
>       <at> always_seq(clock.posedge, reset=reset)
>   	ssum = 0
> 	for ii in range(N):
>              c = b[ii]
> 	    ssum = ssum + x[ii] * c
>          y.next = ssum
> 
> I wouldn't write the above any other way even though
> the converted code will have the case embedded in the
> process.
> 
> <snip>

You're quite right that for N being large the above approach is the only 
way. Imagine spelling out 64 constants all day long ...
For the moment.
When your (ours?) MEP_lite gets implemented, it will look like this
      x = [Signal(intbv(...) ...]
      b = tuple(map(int, [round(1/N*xmax) for ...]))
 
      def sop(N, x, b ):
      <at> always_seq(clock.posedge, reset=reset)
      def sop():
          ssum = 0
          for ii in range(N):
 	      ssum = ssum + x[ii] * b[ii]
          y.next = ssum
      return sop

Which is definitely more pythonic (and the converted V* will be cleaner 
too)
I refrained from making b upper-case :)

Best regards,

Josy

Re: [myhdl-list] List Of Constants

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

> > while you're at it, can you put the 'constants' in upper-case? A 
PEP8
> > recommendation ;)
> >
> 
> I disagree, we have a reference to a `tuple` not a
> module level constant.
> 
>      # module level constant
>      from myhdl import *
>      MAX_LEVELS = 4
> 
>      # reference to a tuple
>      coef = (1,2,3,4)
> 
> Module-level constants are fairly rare.  The python
> documentation [1] does not use cap names for references
> to tuples (can't say I have seen other that does)
> 
> Regards,
> Chris
> 
> [1] 
> https://docs.python.org/2/tutorial/datastructures.html#tuples-and-
sequences

Chris,

I see your point. But I like to stress the fact that some arguments are 
*constant* (and I always use UPPER_CASE names for generic parameters in 
VHDL which is what I mimic in my MyHDL code). I'll let it digest.

Regards,

Josy

Re: [myhdl-list] List Of Constants

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

On 3/17/15 1:51 PM, Josy Boelen wrote:
> Christopher Felton <chris.felton <at> gmail.com> writes:
>
>>
>> <snip>
>>>
>>> I tried that code, and although it functions, the VHDL code doesn't
> get any
>>> prettier.
>>
>> I am typically not too concerned with the "prettiness" of
>> the converted code.  I think reasonable steps should be
>> taken to make it readable but not stand in the way.
>>
>> With that said I created and issue (enhancement request)
>> for this particular item:
>> https://github.com/jandecaluwe/myhdl/issues/34
>>
>> <snip>
>
> Chris,
>
> To me the prettiness of the VHDL or Verilog code is an indication of how
> 'good' the MyHDL code was drafted/converted.

I strongly disagree, you are trading off readability
and pythonics in the MyHDL code for "prettier"
intermediate code.

A similar example to yours is a straightfoward
sum-of products

     x = [Signal(intbv(...) ...]
     b = tuple(map(int, [round(1/N*xmax) for ...]))

     @always_seq(clock.posedge, reset=reset)
  	ssum = 0
	for ii in range(N):
             c = b[ii]
	    ssum = ssum + x[ii] * c
         y.next = ssum


I wouldn't write the above any other way even though
the converted code will have the case embedded in the
process.

Regards,
Chris

Re: [myhdl-list] List Of Constants

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

On 3/18/15 2:36 AM, Josy Boelen wrote:
> Christopher Felton <chris.felton <at> gmail.com> writes:
>
>>
>>
>>> But I welcome your MEP-lite. Just wish you hadn't used the word *rom*,
> I
>>> feel that name is a bit ambiguous to describe what is going on there.
>>>
>>
>> It can be change and probably should.  I agree, in this case
>> we want a constant and not a read-only look-up.  I will change
>> it.
>>
> Chris,
>
> while you're at it, can you put the 'constants' in upper-case? A PEP8
> recommendation ;)
>

I disagree, we have a reference to a `tuple` not a
module level constant.

     # module level constant
     from myhdl import *
     MAX_LEVELS = 4

     # reference to a tuple
     coef = (1,2,3,4)

Module-level constants are fairly rare.  The python
documentation [1] does not use cap names for references
to tuples (can't say I have seen other that does)

Regards,
Chris

[1] 
https://docs.python.org/2/tutorial/datastructures.html#tuples-and-sequences

Re: [myhdl-list] Constant ints in interfaces

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

BTW, the above example converts fine to verilog.

On Tue, Mar 17, 2015 at 3:30 AM, Keerthan JC <jck...@gm...> wrote:

> That is not actually true. The implementation actually flattens everything
> except previously supported attributes like .next, .posedge etc.
>
> The problem now is just a naming bug.
>
> On Tue, Mar 17, 2015 at 12:28 AM, Christopher Felton <
> chr...@gm...> wrote:
>
>> On 3/16/15 7:01 AM, SHEN Chen wrote:
>> > Hi Keerthan,
>> >
>> > I will write more cases as you said. So I hope folks here will post
>> > exotic way of abusing interface, so we could clarifying what are
>> > supported v.s. what are not.
>> >
>> > By doing this, we can have a spec first, before anyone attempting a fix.
>>
>> The spec should be covered in MEP 107:
>> http://dev.myhdl.org/meps/mep-107.html
>>
>> The conversion of constants wasn't in the
>> original MEP but is a good feature to go
>> along with interfaces.  We can add more
>> info on const usage in the "what's new in
>> MyHDL 0.9" documentation.
>>
>> >
>> > For instance, do you think it's a good idea to have a Interface base
>> > class, and requires all interface to derive from the base class?
>>
>> This was discussed when MEP107 was first
>> proposed and it was decided no.
>>
>> >
>> > With this convention, during extractHier/analyze, we can unambiguously
>> > identify interface objects, descend into it and extract its member
>> signals.
>>
>> This is what is currently done, an object is
>> walked and the "Signal" attributes identified.
>>
>> 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
>>
>
>
>
> --
> have a nice day
> -jck
>



-- 
have a nice day
-jck

Re: [myhdl-list] List Of Constants

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

Christopher Felton <chris.felton <at> gmail.com> writes:

> 
> 
> > But I welcome your MEP-lite. Just wish you hadn't used the word *rom*, 
I
> > feel that name is a bit ambiguous to describe what is going on there.
> >
> 
> It can be change and probably should.  I agree, in this case
> we want a constant and not a read-only look-up.  I will change
> it.
> 
Chris,

while you're at it, can you put the 'constants' in upper-case? A PEP8 
recommendation ;)

Regards,

Josy

Re: [myhdl-list] List Of Constants

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

> But I welcome your MEP-lite. Just wish you hadn't used the word *rom*, I
> feel that name is a bit ambiguous to describe what is going on there.
>

It can be change and probably should.  I agree, in this case
we want a constant and not a read-only look-up.  I will change
it.

Regards,
Chris

Re: [myhdl-list] List Of Constants

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

Christopher Felton <chris.felton <at> gmail.com> writes:

> 
> <snip>
> >
> > I tried that code, and although it functions, the VHDL code doesn't 
get any
> > prettier.
> 
> I am typically not too concerned with the "prettiness" of
> the converted code.  I think reasonable steps should be
> taken to make it readable but not stand in the way.
> 
> With that said I created and issue (enhancement request)
> for this particular item:
> https://github.com/jandecaluwe/myhdl/issues/34
> 
><snip>

Chris,

To me the prettiness of the VHDL or Verilog code is an indication of how 
'good' the MyHDL code was drafted/converted. From the workarounds the 
one with the spelled out constants looks best in both representations 
(MyHDL and VHDL) where the others bear the signs of being workarounds.
But I welcome your MEP-lite. Just wish you hadn't used the word *rom*, I 
feel that name is a bit ambiguous to describe what is going on there.

Regards,

Josy

Re: [myhdl-list] List Of Constants

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

<snip>
>
> I tried that code, and although it functions, the VHDL code doesn't get any
> prettier.

I am typically not too concerned with the "prettiness" of
the converted code.  I think reasonable steps should be
taken to make it readable but not stand in the way.

With that said I created and issue (enhancement request)
for this particular item:
https://github.com/jandecaluwe/myhdl/issues/34

Regards,
Chris

Re: [myhdl-list] List Of Constants

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

> I looked at your code a little closer, first
> you want to create a `tuple` of ints or `tuple`
> of `intbv`.  Because we are using a ROM and you
> want to access multiple index at a time you need
> to access first:
> 
>      def simplefunc( Coeff, Clk, DA, DB, Q):
>          ''' a simple operation, just for the effect ... '''
> 
>          Coeff = tuple(Coeff)
>           <at> always_seq( Clk.posedge, reset = None)
>          def calc():
>              c0 = Coeff[0]
>              c1 = Coeff[1]
>              Q.next = c0 * DA + c1 * DB
> 
> The converter doesn't detect the constant/literal
> index value so it doesn't replace the const with
> the explicit value (this could possibly be a MEP).
> 
> To use the ROM structure you need to capture with
> a variable first, the generated code will be kinda
> odd (optimized away) because it is generate for a
> variable index instead of a const.
> 
> You could use a list-of-signals with initial values
> but initial values support has not been enabled because
> support was inconsistent between various synthesis tools:
> http://dev.myhdl.org/ideas/initial-values.html
> 
> At one point someone had a patch that enabled initial
> value support for list-of-signals (i.e. RAM) but we
> never finished verifying support across the major
> synthesis tools.
> 
<snip>

Chris,

I tried that code, and although it functions, the VHDL code doesn't get any 
prettier. Also the method stays cumbersome for large(r) coefficient arrays.
I can live with my workaround (spelling out every coefficient in the call) and 
put my hopes on future improvements on the conversion process. 

You indirectly answer my question: initial values are not supported - so my 
workaround of embedding the constant in a Signal can't work. Close but no cigar 
:)

Regards,

Josy

Re: [myhdl-list] Constant ints in interfaces

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

That is not actually true. The implementation actually flattens everything
except previously supported attributes like .next, .posedge etc.

The problem now is just a naming bug.

On Tue, Mar 17, 2015 at 12:28 AM, Christopher Felton <chr...@gm...
> wrote:

> On 3/16/15 7:01 AM, SHEN Chen wrote:
> > Hi Keerthan,
> >
> > I will write more cases as you said. So I hope folks here will post
> > exotic way of abusing interface, so we could clarifying what are
> > supported v.s. what are not.
> >
> > By doing this, we can have a spec first, before anyone attempting a fix.
>
> The spec should be covered in MEP 107:
> http://dev.myhdl.org/meps/mep-107.html
>
> The conversion of constants wasn't in the
> original MEP but is a good feature to go
> along with interfaces.  We can add more
> info on const usage in the "what's new in
> MyHDL 0.9" documentation.
>
> >
> > For instance, do you think it's a good idea to have a Interface base
> > class, and requires all interface to derive from the base class?
>
> This was discussed when MEP107 was first
> proposed and it was decided no.
>
> >
> > With this convention, during extractHier/analyze, we can unambiguously
> > identify interface objects, descend into it and extract its member
> signals.
>
> This is what is currently done, an object is
> walked and the "Signal" attributes identified.
>
> 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
>



-- 
have a nice day
-jck

Re: [myhdl-list] Constant ints in interfaces

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

On 3/16/15 7:01 AM, SHEN Chen wrote:
> Hi Keerthan,
>
> I will write more cases as you said. So I hope folks here will post
> exotic way of abusing interface, so we could clarifying what are
> supported v.s. what are not.
>
> By doing this, we can have a spec first, before anyone attempting a fix.

The spec should be covered in MEP 107:
http://dev.myhdl.org/meps/mep-107.html

The conversion of constants wasn't in the
original MEP but is a good feature to go
along with interfaces.  We can add more
info on const usage in the "what's new in
MyHDL 0.9" documentation.

>
> For instance, do you think it's a good idea to have a Interface base
> class, and requires all interface to derive from the base class?

This was discussed when MEP107 was first
proposed and it was decided no.

>
> With this convention, during extractHier/analyze, we can unambiguously
> identify interface objects, descend into it and extract its member signals.

This is what is currently done, an object is
walked and the "Signal" attributes identified.

Regards,
Chris