myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Reusability and encapsulation

[Juan P. C. <jp...@gm...>]

I think I installed it from the Ubuntu 12.04 repository. Is there a
variable containing the version number or should I look in the code?

Thanks,
JP

On Mon, May 4, 2015 at 11:08 AM, Christopher Felton <chr...@gm...>
wrote:

> On 5/3/2015 11:11 AM, Juan Pablo Caram wrote:
> > You will at least get the error:
> >
> > TraceSignalsError: Cannot trace multiple instances simultaneously
> >
> >
> > if you try to run the line:
> >
> > Simulation(traceSignals(_test)).run()
> >
> >
> > a second time without restarting the kernel.
>
> The fourth code cell can be run multiple times
> without restarting the kernel.  You are saying, if
> the line where Simulation(...) occurs is repeated
> twice it fails?
>
>      print("call simulation first time ...")
>      Simulation(traceSignals(_test)).run()
>      print("call simulation second time ...")
>      Simulation(traceSignals(_test)).run()
>
> It does not fail with the version I have?  The above
> works fine.
>
>      call simulation first time ...
>      The note has a tone at 1200.000 and 4000.000
>      call simulation second time ...
>      The note has a tone at 1200.000 and 4000.000
>
> I am not following what fails and how?
>
> Regards,
> Chris
>
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] Interfaces in Interfaces

[Ben R. <be...@re...>]

Hi all,

Is it possible to use interface definitions in interfaces?  For example I
might have an interface for a complex number, and then an interface for a
back-pressured stream of complex numbers that uses the complex number
interface as a component.

e.g.

class Complex(object):

    def __init__(self, width):
        maxval = pow(2, width-1)-1
minval = -pow(2, width-1)
self.real = Signal(intbv(min=minval, max=maxval))
        self.imag = Signal(intbv(min=minval, max=maxval))
self.width = width

class ComplexStream(object):

    def __init__(self, width):
self.data = Signal(Complex(width=width))
        self.valid = Signal(bool(0))
self.last = Signal(bool(0))
        self.ready = Signal(bool(0))
self.width = width

Cheers,
Ben

Re: [myhdl-list] IP core library

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

2015-05-04 12:52 GMT-03:00 Christopher Felton <chr...@gm...>:

> On 5/4/2015 10:37 AM, Euripedes Rocha Filho wrote:
> > 2015-05-04 12:14 GMT-03:00 Christopher Felton <chr...@gm...>:
> >
> >> On 5/3/2015 6:39 AM, Euripedes Rocha Filho wrote:
> >>> Henry,
> >>> good articles.
> >>>
> >>> @Christopher,
> >>> I will follow this approach:
> >>>
> >>> module.py
> >>> parameters - named tuple with the parameters/generics for the design
> >>> interface - class with necessary signals
> >>> module(parameters, interface) - hdl implementation
> >>>
> >>
> >> For each module I don't think you should force
> >> everything into one interface for the module.
> >> In my opinion have logically grouped interfaces:
> >>
> >>       module(interface1, interface2, ..., parameters)
> >>
> >>
> > The idea is to have some regularity across all modules and in the higher
> > level you just need:
> >
> > import module
> >
> > module_interface = module.interface() - An instance of the signals to
> > interconect
> > parameters  = module.parameters('Parameter')
> > module_instance = module.module(parameters, interface)
>
> But then the regularity doesn't go far?  Because
> each interface will be different?
>
>  > module_interface = module.interface()
>
> This breaks modularity?  Don't you want to support
> different port configurations?
>

No, each module has only one port configuration. Instantiating the
interface class to module_interface(a typo in previous email) creates all
necessary signals in the upper module.
I'll try a few example cores and come beck to ask for improvements :)


>
>
> Is `module` a class you want to create or just
> a generic for the example, i.e. import module_xyz?
> If it is a class shouldn't it be called `Module`? [1]
>

'module' is just a generic for the example.

>
> Something I have experimented with is having a
> default (most commonly used) portmap tied to the
> module.  A default doesn't remove or prevent the
> modularity based on port types:
>
>      def somemodule(memmap, streaming, done):
>          # ...
>
>      somemodule.portmap = {'memmap': Avalon(data_width=64,
>                                             address_width=32),
>                            'streaming': Streaming(),
>                            'done': Signal(bool(0))}
>
>
> This is a shortcut to the common ports but doesn't
> prevent:
>
>       g = somemodule(Avalon(data_width=16, address_width=8),
>                      Streamin(), Signal(bool(0)) )
>
> Regards,
> Chris
>
> [1] PEP8 naming suggestions
>      https://www.python.org/dev/peps/pep-0008/#class-names
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] IP core library

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

On 5/4/2015 10:37 AM, Euripedes Rocha Filho wrote:
> 2015-05-04 12:14 GMT-03:00 Christopher Felton <chr...@gm...>:
>
>> On 5/3/2015 6:39 AM, Euripedes Rocha Filho wrote:
>>> Henry,
>>> good articles.
>>>
>>> @Christopher,
>>> I will follow this approach:
>>>
>>> module.py
>>> parameters - named tuple with the parameters/generics for the design
>>> interface - class with necessary signals
>>> module(parameters, interface) - hdl implementation
>>>
>>
>> For each module I don't think you should force
>> everything into one interface for the module.
>> In my opinion have logically grouped interfaces:
>>
>>       module(interface1, interface2, ..., parameters)
>>
>>
> The idea is to have some regularity across all modules and in the higher
> level you just need:
>
> import module
>
> module_interface = module.interface() - An instance of the signals to
> interconect
> parameters  = module.parameters('Parameter')
> module_instance = module.module(parameters, interface)

But then the regularity doesn't go far?  Because
each interface will be different?

 > module_interface = module.interface()

This breaks modularity?  Don't you want to support
different port configurations?


Is `module` a class you want to create or just
a generic for the example, i.e. import module_xyz?
If it is a class shouldn't it be called `Module`? [1]

Something I have experimented with is having a
default (most commonly used) portmap tied to the
module.  A default doesn't remove or prevent the
modularity based on port types:

     def somemodule(memmap, streaming, done):
         # ...

     somemodule.portmap = {'memmap': Avalon(data_width=64,
                                            address_width=32),
                           'streaming': Streaming(),
                           'done': Signal(bool(0))}


This is a shortcut to the common ports but doesn't
prevent:

      g = somemodule(Avalon(data_width=16, address_width=8),
                     Streamin(), Signal(bool(0)) )

Regards,
Chris

[1] PEP8 naming suggestions
     https://www.python.org/dev/peps/pep-0008/#class-names

Re: [myhdl-list] IP core library

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

2015-05-04 12:14 GMT-03:00 Christopher Felton <chr...@gm...>:

> On 5/3/2015 6:39 AM, Euripedes Rocha Filho wrote:
> > Henry,
> > good articles.
> >
> > @Christopher,
> > I will follow this approach:
> >
> > module.py
> > parameters - named tuple with the parameters/generics for the design
> > interface - class with necessary signals
> > module(parameters, interface) - hdl implementation
> >
>
> For each module I don't think you should force
> everything into one interface for the module.
> In my opinion have logically grouped interfaces:
>
>      module(interface1, interface2, ..., parameters)
>
>
The idea is to have some regularity across all modules and in the higher
level you just need:

import module

module_interface = module.interface() - An instance of the signals to
interconect
parameters  = module.parameters('Parameter')
module_instance = module.module(parameters, interface)


> What is the benefit of using namedtuples over
> dictionary or your own Parameters class?
>

Named tuples seems to fit better the purpouse of a parameters list and it
will force the definition of all parameters, it will also force the concept
that the parameters should not change in run time.

Regards

Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] IP core library

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

On 5/3/2015 6:39 AM, Euripedes Rocha Filho wrote:
> Henry,
> good articles.
>
> @Christopher,
> I will follow this approach:
>
> module.py
> parameters - named tuple with the parameters/generics for the design
> interface - class with necessary signals
> module(parameters, interface) - hdl implementation
>

For each module I don't think you should force
everything into one interface for the module.
In my opinion have logically grouped interfaces:

     module(interface1, interface2, ..., parameters)


What is the benefit of using namedtuples over
dictionary or your own Parameters class?

Regards,
Chris

Re: [myhdl-list] Reusability and encapsulation

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

On 5/3/2015 11:11 AM, Juan Pablo Caram wrote:
> You will at least get the error:
>
> TraceSignalsError: Cannot trace multiple instances simultaneously
>
>
> if you try to run the line:
>
> Simulation(traceSignals(_test)).run()
>
>
> a second time without restarting the kernel.

The fourth code cell can be run multiple times
without restarting the kernel.  You are saying, if
the line where Simulation(...) occurs is repeated
twice it fails?

     print("call simulation first time ...")
     Simulation(traceSignals(_test)).run()
     print("call simulation second time ...")
     Simulation(traceSignals(_test)).run()

It does not fail with the version I have?  The above
works fine.

     call simulation first time ...
     The note has a tone at 1200.000 and 4000.000
     call simulation second time ...
     The note has a tone at 1200.000 and 4000.000

I am not following what fails and how?

Regards,
Chris

Re: [myhdl-list] Reusability and encapsulation

[Juan P. C. <jp...@gm...>]

You will at least get the error:

TraceSignalsError: Cannot trace multiple instances simultaneously


if you try to run the line:

Simulation(traceSignals(_test)).run()


a second time without restarting the kernel.

Cheers,
JP

On Sun, May 3, 2015 at 12:02 PM, Christopher Felton <chr...@gm...>
wrote:

> <snip>
> >
> > For those that didn't happen to be watching IRC at that moment, it is
> > discussed a bit in the PR:
> > https://github.com/jandecaluwe/myhdl/pull/67
>
> There are logs for the IRC channel
> https://botbot.me/freenode/myhdl/
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Reusability and encapsulation

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

<snip>
>
> For those that didn't happen to be watching IRC at that moment, it is
> discussed a bit in the PR:
> https://github.com/jandecaluwe/myhdl/pull/67

There are logs for the IRC channel
https://botbot.me/freenode/myhdl/

Regards,
Chris

Re: [myhdl-list] fixbv to current version of myhdl

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

On 03/05/15 14:49, Jose M. Gomez Cama wrote:
> Being short, resize usually implies just an increment and some checks. So in most cases no pipelining is needed.

Ah yes, I realise I've been misinterpreting what is needed by a resize...

Essentially I need the more general case to be implemented in hardware, 
similar to floating point.

Actually, it really is floating point I need :) (but a distinctly 
restricted type of floating point) - the normalize and count operation. 
That's a count leading zeros, left shift, and then a round to even (or 
whatever rounding scheme).

>
> Or being a bad guy, if we do not parametrise the pipeline for multiply or divide which usually will require pipelining, why shall be done for resize;)

I agree. Any real convertible implementation would have to handle 
multiply and divide as explicit operations. To some extent, the multiply 
can be inferred and can be done in a single clock cycle when DSP slices 
are available, so might still be useful.

You make an important point though.

Cheers,

Henry

Re: [myhdl-list] fixbv to current version of myhdl

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

On 5/3/15 9:05 AM, Christopher Felton wrote:
> On 5/2/15 1:47 PM, Jose M. Gomez Cama wrote:
>> Dear Christopher,
>>
>> I have given a quick glance to resize. Have you though on the possibility to use Decimal? It provides similar functionality for rounding, and allows to have a larger number of bits than float.
>>
>
> I don't think Decimal can be used for the `resize`
> function but it should be leverage for the real
> representation, simply because a `fixbv` can have
> more precision than a float.


I should clarify, Decimal would not be useful for
the convertible version of `resize` but it would
be useful in the current model where float is
being used.

Regards,
Chris

Re: [myhdl-list] fixbv to current version of myhdl

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

On 5/2/15 1:47 PM, Jose M. Gomez Cama wrote:
> Dear Christopher,
>
> I have given a quick glance to resize. Have you though on the possibility to use Decimal? It provides similar functionality for rounding, and allows to have a larger number of bits than float.
>

I don't think Decimal can be used for the `resize`
function but it should be leverage for the real
representation, simply because a `fixbv` can have
more precision than a float.

Regards,
Chris

Re: [myhdl-list] fixbv to current version of myhdl

[Jose M. G. C. <ch...@gm...>]

Dear Henry,

Being short, resize usually implies just an increment and some checks. So in most cases no pipelining is needed.

Or being a bad guy, if we do not parametrise the pipeline for multiply or divide which usually will require pipelining, why shall be done for resize;)

On the other hand, there are pathological cases where a resize is done just after a large operation. In this case, just adding an intermediate register to store the result of the large operation, and doing the resize in the following clock tick, should suffice. At least, this is my experience.

I do not if I have answered your question. If not, please do not hesitate to ask.

Best,

Jose M.

> El 03/05/2015, a las 10:57, Henry Gomersall <he...@ca...> escribió:
> 
>> On 02/05/15 19:01, Christopher Felton wrote:
>> On 5/2/15 11:27 AM, Henry Gomersall wrote:
>>>> On 02/05/15 16:47, Christopher Felton wrote:
>>>>>> On 5/2/15 8:55 AM, Edward Vidal wrote:
>>>>>>>>>> Chris,
>>>>>>>>>> Athttp://dev.myhdl.org/meps/mep-111.html
>>>>>>>>>> Limitations no resize (function yet).
>>>>>>>>>> Is this still true?
>>>>>> There is a resize function but it is not convertible
>>>>>> at this point.  I can make a convertible version but
>>>>>> I didn't like how it worked out, been experimenting
>>>>>> with other methods.  The existing resize function
>>>>>> can be used for modeling and testing at this point.
>>>> 
>>>> How does it work?
>> Here is the `model` how I thought it should
>> work:
>> https://github.com/cfelton/myhdl/blob/mep111_fixbv/myhdl/_resize.py
> 
> So I was wondering about this. Is there not a problem in that the 
> performance of any converted implementation is so sensitive to e.g. the 
> number of pipeline registers?
> 
> In my mind, it would make perfect sense to have this as a convertible, 
> parametrizable instance.
> 
> It would be lovely to have as a simple function, but it's hard to get 
> away from the fact that there are design decisions intrinsic to a resize 
> that have quite a bearing on the RTL model. If I'm wrong on this, I'm 
> keen to be educated!
> 
> Cheers,
> 
> Henry
> 
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] IP core library

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

Henry,
good articles.

@Christopher,
I will follow this approach:

module.py
parameters - named tuple with the parameters/generics for the design
interface - class with necessary signals
module(parameters, interface) - hdl implementation

Regards



2015-04-26 8:07 GMT-03:00 Henry Gomersall <he...@ca...>:

>  On 26/04/15 11:30, Euripedes Rocha Filho wrote:
>
> 2015-04-26 5:16 GMT-03:00 Henry Gomersall <he...@ca...>:
>
>> On 25/04/15 22:49, Euripedes Rocha Filho wrote:
>> > I'm doing some personal variation of TDD, lots of unit testing but not
>> > "driving" the development. I'm not that religious :)
>>
>> So you're not doing TDD at all then, you're just doing testing. TDD is
>> useful precisely because the tests are written first.
>>
>> Switching to TDD is a total mindset switch (hence your religious
>> comment). It basically becomes psychologically impossible to write
>> untested code.
>>
>>
> Yes, but you will agree that such a mindset take some time to build,
>
>
> I find one just has to do it. I did a project that was half-arsed for a
> while and it never felt complete.
>
> Only when I decided to do it properly did I fully grok the joy.
>
>
>
>> I'm actually an advocate of BDD over TDD, as behaviour is actually what
>> one cares about.
>>
>
>  I did some read about BDD but didn't practice it yet.
>
>
> This is a really interesting and I think pretty misunderstood field. I
> recommend this blog post:
> http://hadihariri.com/2012/04/11/what-bdd-has-taught-me/
>
> I wrote a bit about it myself in light of that post:
>
> https://hgomersall.wordpress.com/2014/10/03/from-test-driven-development-and-specifications/
>
> Great stuff!
>
> hen
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>

Re: [myhdl-list] fixbv to current version of myhdl

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

On 02/05/15 19:01, Christopher Felton wrote:
> On 5/2/15 11:27 AM, Henry Gomersall wrote:
>> >On 02/05/15 16:47, Christopher Felton wrote:
>>> >>On 5/2/15 8:55 AM, Edward Vidal wrote:
>>>>> >>>>Chris,
>>>>> >>>>Athttp://dev.myhdl.org/meps/mep-111.html
>>>>> >>>>Limitations no resize (function yet).
>>>>> >>>>Is this still true?
>>> >>There is a resize function but it is not convertible
>>> >>at this point.  I can make a convertible version but
>>> >>I didn't like how it worked out, been experimenting
>>> >>with other methods.  The existing resize function
>>> >>can be used for modeling and testing at this point.
>>> >>
>> >
>> >How does it work?
> Here is the `model` how I thought it should
> work:
> https://github.com/cfelton/myhdl/blob/mep111_fixbv/myhdl/_resize.py
>

So I was wondering about this. Is there not a problem in that the 
performance of any converted implementation is so sensitive to e.g. the 
number of pipeline registers?

In my mind, it would make perfect sense to have this as a convertible, 
parametrizable instance.

It would be lovely to have as a simple function, but it's hard to get 
away from the fact that there are design decisions intrinsic to a resize 
that have quite a bearing on the RTL model. If I'm wrong on this, I'm 
keen to be educated!

Cheers,

Henry

Re: [myhdl-list] Reusability and encapsulation

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

On 03/05/15 01:21, Christopher Felton wrote:
> On 5/2/15 2:40 PM, Juan Pablo Caram wrote:
>> >Hi,
>> >
>> >I use iPython a lot and need to launch multiple simulations of different
>> >models (and signals) within the same interpreter. And MyHDL does not
>> >play nicely with this.
> That is odd, I use IPython console/notebook constantly,
> most my replies here include IPython snips.  I have
> not run into any issues.

I suspect the state-on-the-signal issue we were discussing on IRC would 
show up as a potential problem here.

For those that didn't happen to be watching IRC at that moment, it is 
discussed a bit in the PR:
https://github.com/jandecaluwe/myhdl/pull/67

Cheers,

Henry

Re: [myhdl-list] Reusability and encapsulation

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

On 5/2/15 2:40 PM, Juan Pablo Caram wrote:
> Hi,
>
> I use iPython a lot and need to launch multiple simulations of different
> models (and signals) within the same interpreter. And MyHDL does not
> play nicely with this.

That is odd, I use IPython console/notebook constantly,
most my replies here include IPython snips.  I have
not run into any issues.

http://nbviewer.ipython.org/github/cfelton/musicbox_simple/blob/master/musicbox.ipynb
(my simple (ridiculously simple) vcd viewer needs
some love :)


There was an issue at one point for folks that used UTF8
encoding I can't remember if that is still true or
not (a fix was identified but I can't recall the if
was implemented or not).

Regards,
Chris

Re: [myhdl-list] Reusability and encapsulation

[Juan P. C. <jp...@gm...>]

I found it. It's #68 (https://github.com/jandecaluwe/myhdl/issues/68).

I commented with a short summary of my last post.

Thanks!

JP

On Sat, May 2, 2015 at 5:08 PM, Henry Gomersall <he...@ca...> wrote:

> I just submitted a github issue on this. I suggest adding some to that.
> Please forgive me, I'm sending this from my phone so it's not easy to check
> the issue number.
>
> The basic problem as far as I can tell is the global state stored in
> simulator.py and the state that is stored on the signal itself.
>
> Possibly your ipython problems would be fixed by the patch I just
> submitted to clear the state on a new simulation instance.
>
> Cheers Henry.
>
>
> On 2 May 2015 20:40:19 BST, Juan Pablo Caram <jp...@gm...> wrote:
>
>> Hi,
>>
>> I use iPython a lot and need to launch multiple simulations of different
>> models (and signals) within the same interpreter. And MyHDL does not play
>> nicely with this.
>>
>> I've found a way to clean the environment in order to be able to run a
>> new simulation: I import
>>
>> from myhdl import _simulator
>> from myhdl import _traceSignals
>>
>> in the beginning, and before every simulation (and signal tracing) I do:
>>
>> _simulator._signals = []
>> _simulator._siglist = []
>> _simulator._futureEvents = []
>> _simulator._time = 0
>> _simulator._cosim = 0
>> _simulator._tracing = 0
>> _simulator._tf = None
>>
>> _traceSignals._tracing = 0
>>
>> which is what is done upon importing the mentioned files.
>>
>> I would love if some re-structuring was done to the code providing better
>> encapsulation of variables. It would alleviate a lot of problems that arise
>> when trying to build upon the base myhdl library. As it stands, it's fine
>> for end-user digital designers, but makes it hard to create software that
>> use myhdl as a feature.
>>
>> Specifically, moving the above-mentioned variables to Simulation
>> instances would be great, and in general, to not have any shared states.
>>
>> I would happily contribute towards these changes. I'd rather contribute
>> to the project than be implementing my own ad-hoc fixes.
>>
>> Thanks,
>>
>> JP
>>
>> ------------------------------
>>
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>
>> ------------------------------
>>
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

Re: [myhdl-list] Reusability and encapsulation

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

I just submitted a github issue on this. I suggest adding some to that. Please forgive me, I'm sending this from my phone so it's not easy to check the issue number.

The basic problem as far as I can tell is the global state stored in simulator.py and the state that is stored on the signal itself.

Possibly your ipython problems would be fixed by the patch I just submitted to clear the state on a new simulation instance.

Cheers Henry.


On 2 May 2015 20:40:19 BST, Juan Pablo Caram <jp...@gm...> wrote:
>Hi,
>
>I use iPython a lot and need to launch multiple simulations of
>different
>models (and signals) within the same interpreter. And MyHDL does not
>play
>nicely with this.
>
>I've found a way to clean the environment in order to be able to run a
>new
>simulation: I import
>
>from myhdl import _simulator
>from myhdl import _traceSignals
>
>in the beginning, and before every simulation (and signal tracing) I
>do:
>
>_simulator._signals = []
>_simulator._siglist = []
>_simulator._futureEvents = []
>_simulator._time = 0
>_simulator._cosim = 0
>_simulator._tracing = 0
>_simulator._tf = None
>
>_traceSignals._tracing = 0
>
>which is what is done upon importing the mentioned files.
>
>I would love if some re-structuring was done to the code providing
>better
>encapsulation of variables. It would alleviate a lot of problems that
>arise
>when trying to build upon the base myhdl library. As it stands, it's
>fine
>for end-user digital designers, but makes it hard to create software
>that
>use myhdl as a feature.
>
>Specifically, moving the above-mentioned variables to Simulation
>instances
>would be great, and in general, to not have any shared states.
>
>I would happily contribute towards these changes. I'd rather contribute
>to
>the project than be implementing my own ad-hoc fixes.
>
>Thanks,
>
>JP
>
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>One dashboard for servers and applications across
>Physical-Virtual-Cloud 
>Widest out-of-the-box monitoring support with 50+ applications
>Performance metrics, stats and reports that give you Actionable
>Insights
>Deep dive visibility with transaction tracing using APM Insight.
>http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>------------------------------------------------------------------------
>
>_______________________________________________
>myhdl-list mailing list
>myh...@li...
>https://lists.sourceforge.net/lists/listinfo/myhdl-list

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[myhdl-list] Reusability and encapsulation

[Juan P. C. <jp...@gm...>]

Hi,

I use iPython a lot and need to launch multiple simulations of different
models (and signals) within the same interpreter. And MyHDL does not play
nicely with this.

I've found a way to clean the environment in order to be able to run a new
simulation: I import

from myhdl import _simulator
from myhdl import _traceSignals

in the beginning, and before every simulation (and signal tracing) I do:

_simulator._signals = []
_simulator._siglist = []
_simulator._futureEvents = []
_simulator._time = 0
_simulator._cosim = 0
_simulator._tracing = 0
_simulator._tf = None

_traceSignals._tracing = 0

which is what is done upon importing the mentioned files.

I would love if some re-structuring was done to the code providing better
encapsulation of variables. It would alleviate a lot of problems that arise
when trying to build upon the base myhdl library. As it stands, it's fine
for end-user digital designers, but makes it hard to create software that
use myhdl as a feature.

Specifically, moving the above-mentioned variables to Simulation instances
would be great, and in general, to not have any shared states.

I would happily contribute towards these changes. I'd rather contribute to
the project than be implementing my own ad-hoc fixes.

Thanks,

JP

Re: [myhdl-list] fixbv to current version of myhdl

[Jose M. G. C. <ch...@gm...>]

Dear Christopher,

I have given a quick glance to resize. Have you though on the possibility to use Decimal? It provides similar functionality for rounding, and allows to have a larger number of bits than float.

Best,

Jose M.

> El 02/05/2015, a las 20:01, Christopher Felton <chr...@gm...> escribió:
> 
>> On 5/2/15 11:27 AM, Henry Gomersall wrote:
>>> On 02/05/15 16:47, Christopher Felton wrote:
>>> On 5/2/15 8:55 AM, Edward Vidal wrote:
>>>>> Chris,
>>>>> Athttp://dev.myhdl.org/meps/mep-111.html
>>>>> Limitations no resize (function yet).
>>>>> Is this still true?
>>> There is a resize function but it is not convertible
>>> at this point.  I can make a convertible version but
>>> I didn't like how it worked out, been experimenting
>>> with other methods.  The existing resize function
>>> can be used for modeling and testing at this point.
>> 
>> How does it work?
> 
> Here is the `model` how I thought it should
> work:
> https://github.com/cfelton/myhdl/blob/mep111_fixbv/myhdl/_resize.py
> 
>> 
>> I've been playing with the routines in flopoco
>> (https://gforge.inria.fr/scm/?group_id=1030), which (among other nicely
>> portable tools) has a nice tool for resizing - actually it's a zero
>> counter and a shift left, so the essence of a resize.
> 
> I am not familiar with flopoco but someone else
> mentioned it on IRC as well.  I will look at it
> when I get a chance :)
> 
> Creating the resize for a given set of types isn't
> too difficult.  The difficulty is having a single
> resize function that can accept any type.
> 
>> 
>> It's the next thing I'm going to be implementing so it would be great to
>> combine effort on this. I'm not currently using fixbv, but a kind of
>> meta type of an intbv and a separate exponent.
> 
> The `fixbv` uses `intbv` as the base class.  There
> are multiple mailing-list conversations about the
> `fixbv`:
> 
> http://article.gmane.org/gmane.comp.python.myhdl/3242/match=fixbv
> http://article.gmane.org/gmane.comp.python.myhdl/3265/match=fixbv
> http://article.gmane.org/gmane.comp.python.myhdl/3385/match=fixbv
> http://article.gmane.org/gmane.comp.python.myhdl/3412/match=fixbv
> 
> (I see I didn't follow-up on your previous inquire
> into MEP111 and resize, doh:
> http://thread.gmane.org/gmane.comp.python.myhdl/3773/focus=3775 )
> 
> Regards,
> Chris
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] fixbv to current version of myhdl

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

On 5/2/15 11:27 AM, Henry Gomersall wrote:
> On 02/05/15 16:47, Christopher Felton wrote:
>> On 5/2/15 8:55 AM, Edward Vidal wrote:
>>>> Chris,
>>>> Athttp://dev.myhdl.org/meps/mep-111.html
>>>> Limitations no resize (function yet).
>>>> Is this still true?
>> There is a resize function but it is not convertible
>> at this point.  I can make a convertible version but
>> I didn't like how it worked out, been experimenting
>> with other methods.  The existing resize function
>> can be used for modeling and testing at this point.
>>
>
> How does it work?

Here is the `model` how I thought it should
work:
https://github.com/cfelton/myhdl/blob/mep111_fixbv/myhdl/_resize.py

>
> I've been playing with the routines in flopoco
> (https://gforge.inria.fr/scm/?group_id=1030), which (among other nicely
> portable tools) has a nice tool for resizing - actually it's a zero
> counter and a shift left, so the essence of a resize.

I am not familiar with flopoco but someone else
mentioned it on IRC as well.  I will look at it
when I get a chance :)

Creating the resize for a given set of types isn't
too difficult.  The difficulty is having a single
resize function that can accept any type.

>
> It's the next thing I'm going to be implementing so it would be great to
> combine effort on this. I'm not currently using fixbv, but a kind of
> meta type of an intbv and a separate exponent.

The `fixbv` uses `intbv` as the base class.  There
are multiple mailing-list conversations about the
`fixbv`:

http://article.gmane.org/gmane.comp.python.myhdl/3242/match=fixbv
http://article.gmane.org/gmane.comp.python.myhdl/3265/match=fixbv
http://article.gmane.org/gmane.comp.python.myhdl/3385/match=fixbv
http://article.gmane.org/gmane.comp.python.myhdl/3412/match=fixbv

(I see I didn't follow-up on your previous inquire
into MEP111 and resize, doh:
http://thread.gmane.org/gmane.comp.python.myhdl/3773/focus=3775 )

Regards,
Chris

Re: [myhdl-list] fixbv to current version of myhdl

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

On 5/2/15 11:31 AM, Jose M. Gomez Cama wrote:
> Dear Christopher,
>
> You can find the classes and test under my git user, the fork numerics.

Unfortunately, I don't have time to dig through
and figure it out.  I will gladly provide feedback
and my opinions at the appropriate time.

>
> I have done all this work during the last month, but I have had no time
> to make any docs. Sorry for that. In any case, the way it works is
> equivalent to the fixed package in VHDL, so you can use it as a base.
> http://www.eda-stds.org/fphdl/Fixed_ug.pdf

Yes, familiar with it.

>
> I agree with you that it is going to be tough to make an equivalent in
> Verilog, but I do not see a solution that does not provide a resize to
> be useful, at least this is my experience.

I agree a resize is needed, the fixbv will have a
resize.  I can provide a convertible resize now
but I haven't fully embraced the current approach.
I think there is a better option but it will require
and additional enhancement and this enhancement
needs some thought and consideration (other things
have preempted this effort, move to github, GSoC,
...).

I can update the MEP and make it clear the resize
needs to and will exist (put it on my todo list :).
I can outline the current options I envision.  I
wanted to get the `fixbv` type in first and focus
on the resize once the `fixbv` was merged in.

In my opinion, not having a Verilog version is
a show stopper.  It was my goal to learn from
the VHDL fixed-point but not limit the fixbv
from it.

Regards,
Chris

Re: [myhdl-list] fixbv to current version of myhdl

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

On 5/2/15 11:30 AM, Henry Gomersall wrote:
> On 02/05/15 16:47, Christopher Felton wrote:
>> On 5/2/15 10:19 AM, Jose M. Gomez Cama wrote:
>>>> Dear Edward,
>>>>
>>>> That's the reason for the classes I made, they include the resize an it
>>>> is fully working.
>>>>
>> Jose,
>>
>> If you have some documentation or examples I will
>> gladly look at it and provide feedback, otherwise
>> your comments are odd and not helpful.
>>
>> You can comment on the MEP111 here or review the
>> previous mailing-list conversation and provide
>> reasonable arguments why you think your approach
>> is better than the fixbv approach.  Having to
>> create a Verilog version of the VHDL fixed-point
>> package to support Verilog conversion is going to
>> be a tough sell (IMO).
>
> I think possibly Jose was just saying he'd written some convertible code
> for fixbv (including a resize) that might be useful; I don't think he's
> trying to step on anyone's toes - I interpreted it as a "Here's what I
> have in case anyone is interested".

I appreciate the Jose work and am open to
different options and opinions.  But I don't
think this thread was the appropriate spot
and it did not help the OP at all.

 From the description so far, it sounds like
a completely different approach and not
compatible with the current (which is fine,
but it is his burden to convince us the
alternate approach is a better fit for
the project).

Regards,
Chris

Re: [myhdl-list] fixbv to current version of myhdl

[Jose M. G. C. <ch...@gm...>]

Dear Christopher,

I agree that I have not followed the standard approach. The reason has been that I needed thinks for yesterday, and I needed it to run quickly. I needed to move from a previous platform to an open one, and I saw myhdl as a good approach. I also needed fixed point, but the fixbv approach, which is equivalent to the one provided in opencores did not fulfil my requirements, as I needed a resize.

Basically I needed the VHDL fixed package on myhdl. One thing bring to another, and the small package has become a little monster that has required a lot of changes, including the converter code.

Sincerely, for me it would be perfect to help you with the fixbv, and provide to it the same functionality as the VHDL fixed. But in my opinion, this will need also to modify intbv and create helping functions in Verilog for rounding, saturate or, in other words, resizing, if not the code will become a mess in Verilog. Just look at the code generated by the test in VHDL with the helping functions that have been already added, and it is still a little mess.

But please, check the code and give it a try. I am sure you will find some aspects to improve and others that could be useful, and we can try to find a way to have a powerful fixed point type in myhdl. Moreover, this changes shall allow to add a floating point type afterwards.

Best,

Jose M.



> El 02/05/2015, a las 17:48, Christopher Felton <chr...@gm...> escribió:
> 
>> On 5/1/15 4:16 PM, Jose M. Gomez Cama wrote:
>> Dear all,
>> 
>> I have created a series of new types that allow to work with fixed point
>> and is compatible with the fixed point from VHDL. I am still working on
>> it, but it is presently compatible with GHDL, vcom and symplify.
>> 
>> I have not published it before because it uses a new base class,
>> bitarray. I have also created classes for the signed and unsigned types.
>> It still requires some tunning, because it is slower than intbv, as it
>> is fully object oriented, which adds some overhead.
>> 
>> I do not know how to proceed as the number of changes is quite large.
>> And I wanted to discuss it before hand, but as I saw this mail, I
>> thought it could be useful.
>> 
>> In brief, the package is in git, under the user jmgc, fork numeric.
> 
> This approach sounds like it would be an additional pkg
> bolt on and not part of myhdl?
> 
>> 
>> And Jan, if you think it can be added to myhdl, please, tell me how I
>> shall proceed.
> 
> Typically, for a new feature the best approach is to
> follow the development guidelines, which include creating
> a MEP and discussing on the mailing-list:
> 
> http://dev.myhdl.org/guide/guide.html#contributing-changes
> http://dev.myhdl.org/meps/mep-001.html
> 
> Regards,
> Chris
> 
> 
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list