myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] MEP guidelines

[Günter D. <dan...@we...>]

On 10.05.2011 09:59, Jan Decaluwe wrote:
> On 05/06/2011 05:03 PM, Günter Dannoritzer wrote:
>> Hi,
>>
>> I would like to suggest, adding some guidelines about the MEP process.
>> Seeing that the text of an already implemented MEP got changed, I think
>> it would be helpfull to have some guidelines how the MEP process is
>> intended.
> 
> Good idea. Looking at your draft however: without BDFL powers (for me)
> it's a no-go as for as I'm concerned, and also unworkable in practice
> I believe.

Yes, I have been thinking about that. Referring to your other post, I
also agree, not to make this process too complicated.

My suggestion would be, that a MEP can only achieve the final state by
approval of you. That keeps the process simple and not add additional
states like 'Rejected'.

I updated the draft and added your case in point to it. So the updated
version of the guidelines would be like this:

---------
MEP stands for MyHDL Enhancement Proposal. A MEP is a design document
providing information to the MyHDL community, or describing a new
feature for MyHDL. The MEP should provide a concise technical
specification of the feature and a rationale for the feature.

We intend MEPs to be the primary mechanisms for proposing new features,
for collecting community input on an issue, and for documenting the
design decisions that have gone into MyHDL. The MEP author is
responsible for building consensus within the community and documenting
dissenting opinions.

MEPs are maintained on the MyHDL wiki page. The page history resembles
the development history of the document.

Main responsibility of a MEP lies with its author. Before opening a new
MEP, its idea should be discussed on the MyHDL mailing list.

In the development phase, the MEP gets the status "Draft" assigned.
Fully developed and provided with a functional implementation, the MEP
can get the status "Final", documenting that the content of the MEP is
ready to be implemented into MyHDL.

The right to change the status of a MEP from "Draft" to "Final" belongs
exclusively to Jan Decaluwe.

Once the MEP has the status "Final" and its content got added to the
source code, the MyHDL version will be added to the MEP document. From
this time on, the text of the document will be frozen. A "Final" MEP
should not be changed, except for spelling mistakes or language
corrections from a neutral proofreader. It is intended to document the
MyHDL development history for experts. The MyHDL language documentation
for users is in the manuals.

In case the functionality described in a MEP needs to be altered or
extended, a new MEP shall be created, describing the new desired
implementation. The new MEP will live through the same steps as the MEP
process describes. The new MEP should cross reference the MEP its
implementation is based on.

In case the new MEP will replace an implementation of an existing MEP,
the old MEP will achieve the status "Deprecated" as soon as the new MEP
achieves the status "Final". Both MEPs should cross reference each other.

------------

Hope this did not become too complicated :)

If there are no objections to these guidelines, I will put them on the
wiki page.

Cheers, Guenter

Re: [myhdl-list] intbv wrap

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

I made a couple of minor adjustments to this patch.

   1. Made the wrap function private (_wrap) and moved _wrap to __wrap. 
  The wrap function should not be used directly because it will not 
covert correctly.  I think for a future (todo) enhancement the wrap 
function can be made public and handled by the converter.  This is an 
involved modification.  For now I think it is good to advertise the wrap 
function was private.

   2. Added myrange to a slot, _range.

   3. Modified a couple comments.

wrap4.patch is the text version.

Thanks
Chris Felton


On 5/5/11 4:25 PM, Christopher Felton wrote:
> On 5/5/2011 9:21 AM, Ben wrote:
>> Hi Christopher,
>>
>> I took the liberty to review and edit your patch.
>>
>> As you can see, I added some tests, and removed the inclusion of the
>> val property. It became quite smaller ! I left your name in it as the
>> idea and the logic is from you.
>>
>> I also moved the check from the wrap function to the constructor (no
>> need to check every time.).
>
> Perfect!  Thanks for the contributions and for the additional test
> cases, very nice.  Also, good catch on the range checking!
>
> Is there an opinion if 'myrange' should be a class member so that it
> doesn't need to be recalculated on each check?  I don't know if there is
> a down side to having too many slots (_range)?
>
> In the future we will need to address if wrap() can be converted or
> changed to a private function?  As discussed in previous threads.
>
> Thanks again Benoît.
>
> Chris
>
>>
>> Here is a text version, enclosed a bundle. All tests pass fine.
>>
>> # HG changeset patch
>> # User cfelton
>> # Date 1303212809 18000
>> # Node ID 145d558e234f363c3e43e9a79ab48ad7e20d7b9b
>> # Parent  f77cf2c4a5894013ceb2f5c184d84136ea4f04a3
>> Add a wrap parameter to intbv. When set, no overflow will occur.
>>
>> diff -r f77cf2c4a589 -r 145d558e234f myhdl/_intbv.py
>> --- a/myhdl/_intbv.py	Wed May 04 21:33:14 2011 +0200
>> +++ b/myhdl/_intbv.py	Tue Apr 19 06:33:29 2011 -0500
>> @@ -31,37 +31,46 @@
>>    from __builtin__ import max as maxfunc
>>
>>    class intbv(object):
>> -    __slots__ = ('_val', '_min', '_max', '_nrbits')
>> +    __slots__ = ('_min', '_max', '_nrbits', '_wrap', '__val')
>>
>> -    def __init__(self, val=0, min=None, max=None, _nrbits=0):
>> +    def __init__(self, val=0, min=None, max=None, wrap=False, _nrbits=0):
>>            if _nrbits:
>>                self._min = 0
>>                self._max = 2**_nrbits
>> +            self._nrbits = _nrbits
>>            else:
>>                self._min = min
>>                self._max = max
>>                if max is not None and min is not None:
>>                    if min>= 0:
>> -                    _nrbits = len(bin(max-1))
>> +                    self._nrbits = len(bin(max-1))
>>                    elif max<= 1:
>> -                    _nrbits = len(bin(min))
>> +                    self._nrbits = len(bin(min))
>>                    else:
>>                        # make sure there is a leading zero bit in positive numbers
>> -                    _nrbits = maxfunc(len(bin(max-1))+1, len(bin(min)))
>> +                    self._nrbits = maxfunc(len(bin(max-1))+1, len(bin(min)))
>> +            else:
>> +                self._nrbits = 0
>> +
>> +        if wrap:
>> +            myrange = self._nrbits**2
>> +            if (abs(self.min) != self.max) or ((abs(self.min) +
>> self.max) != myrange):
>> +                raise ValueError, "Cannot use wrapping if -min != max
>> (%d != %d)" % (-self.min, self.max)
>> +        self._wrap  = wrap
>>            if isinstance(val, (int, long)):
>>                self._val = val
>>            elif isinstance(val, StringType):
>>                mval = val.replace('_', '')
>> +            self._nrbits = len(mval)
>>                self._val = long(mval, 2)
>> -            _nrbits = len(val)
>>            elif isinstance(val, intbv):
>>                self._val = val._val
>>                self._min = val._min
>>                self._max = val._max
>> -            _nrbits = val._nrbits
>> +            self._wrap = val._wrap
>> +            self._nrbits = val._nrbits
>>            else:
>>                raise TypeError("intbv constructor arg should be int or string")
>> -        self._nrbits = _nrbits
>>            self._checkBounds()
>>
>>        # support for the 'min' and 'max' attribute
>> @@ -82,6 +91,20 @@
>>                    raise ValueError("intbv value %s<   minimum %s" %
>>                                     (self._val, self._min))
>>
>> +    # val property
>> +    def _get_val(self):
>> +        return self.__val
>> +
>> +    def _set_val(self, pval):
>> +
>> +        if self._wrap:
>> +            self.__val = self.wrap(pval)
>> +        else:
>> +            self.__val = pval
>> +
>> +        self._checkBounds()
>> +
>> +    _val = property(_get_val, _set_val)
>>
>>        # hash
>>        def __hash__(self):
>> @@ -433,6 +456,21 @@
>>            return "intbv(" + repr(self._val) + ")"
>>
>>
>> +    def wrap(self, val):
>> +        """ Wrap the value back to the range of the inbv
>> +
>> +        The following will check that the defined min-max is the full
>> +        range of the binary word.  If the full range is specified if
>> +        the value is outside the bounds of the range it will be adjusted
>> +        to the proper value in bounds.
>> +        """
>> +        myrange = 2**self._nrbits
>> +
>> +        rval = self.min + ((val +self.max) % myrange)
>> +
>> +        return rval
>> +
>> +
>>        def signed(self):
>>          ''' return integer with the signed value of the intbv instance
>>
>> diff -r f77cf2c4a589 -r 145d558e234f myhdl/test/core/test_intbv.py
>> --- a/myhdl/test/core/test_intbv.py	Wed May 04 21:33:14 2011 +0200
>> +++ b/myhdl/test/core/test_intbv.py	Tue Apr 19 06:33:29 2011 -0500
>> @@ -576,8 +576,50 @@
>>                    self.assertEqual(n.max, m.max)
>>                    self.assertEqual(len(n), len(m))
>>
>> +class TestIntbvWrap(TestCase):
>> +
>> +    def testWrap(self):
>> +        x = intbv(0, min=-8, max=8, wrap=True)
>> +        x[:] = x + 1
>> +        self.assertEqual(1, x)
>> +        x[:] = x + 2
>> +        self.assertEqual(3, x)
>> +        x[:] = x + 5
>> +        self.assertEqual(-8, x)
>> +        x[:] = x + 1
>> +        self.assertEqual(-7, x)
>> +        x[:] = x - 5
>> +        self.assertEqual(4, x)
>> +        x[:] = x - 4
>> +        self.assertEqual(0, x)
>> +        x[:] += 15
>> +        x[:] = x - 1
>> +        self.assertEqual(-2, x)
>> +
>> +    def testInit(self):
>> +        self.assertRaises(ValueError, intbv, 15, min=-8, max=8)
>> +        x = intbv(15, min=-8, max=8, wrap=True)
>> +        self.assertEqual(-1, x)
>> +
>> +        self.assertRaises(ValueError, intbv, 5, min=-3, max=8, wrap=True)
>> +        intbv(5, min=-3, max=8)
>>
>>
>> +    def testNoWrap(self):
>> +        x = intbv(0, min=-8, max=8, wrap=False)
>> +        try:
>> +            x[:] += 15
>> +            self.fail()
>> +        except ValueError:
>> +            pass
>> +
>> +        x = intbv(0, min=-8, max=8)
>> +        try:
>> +            x[:] += 15
>> +            self.fail()
>> +        except ValueError:
>> +            pass
>> +
>>    if __name__ == "__main__":
>>        unittest.main()
>>
>>
>>
>> ------------------------------------------------------------------------------
>> WhatsUp Gold - Download Free Network Management Software
>> The most intuitive, comprehensive, and cost-effective network
>> management toolset available today.  Delivers lowest initial
>> acquisition cost and overall TCO of any competing solution.
>> http://p.sf.net/sfu/whatsupgold-sd
>>
>>
>>
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd

Re: [myhdl-list] MEP guidelines

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

On 05/06/2011 05:03 PM, Günter Dannoritzer wrote:
> Hi,
>
> I would like to suggest, adding some guidelines about the MEP process.
> Seeing that the text of an already implemented MEP got changed, I think
> it would be helpfull to have some guidelines how the MEP process is
> intended.

Good idea. Looking at your draft however: without BDFL powers (for me)
it's a no-go as for as I'm concerned, and also unworkable in practice
I believe.

> I think, that especially an already implemented MEP should be kept for
> reference as is and not changed later in time. There is the chance, that
> the original notion of the implementation gets altered by editing the
> MEP it originated from.

That is indeed the idea.

> My suggestion is to add the text to the MEP introduction page:
>
> http://myhdl.org/doku.php/meps:intro
>
> The text could be based on the Python Enhancement Proposal, found here:
>
> http://www.python.org/dev/peps/pep-0001/
>
> Here is a first draft for a text. The first paragraphs are a copy of the
> PEP text, changed according to MyHDL:
>
> ---------
>
>
> MEP stands for MyHDL Enhancement Proposal. A MEP is a design document
> providing information to the MyHDL community, or describing a new
> feature for MyHDL. The MEP should provide a concise technical
> specification of the feature and a rationale for the feature.
>
> We intend MEPs to be the primary mechanisms for proposing new features,
> for collecting community input on an issue, and for documenting the
> design decisions that have gone into MyHDL. The MEP author is
> responsible for building consensus within the community and documenting
> dissenting opinions.
>
> MEPs are maintained on the MyHDL wiki page. The page history resembles
> the development history of the document.
>
> Main responsibility of a MEP lies with its author. Before opening a new
> MEP, its idea should be discussed on the MyHDL mailing list.
>
> In the development phase the MEP gets the status "Draft" assigned. Fully
> developed and provided with a functional implementation, the MEP can get
> the status "Final", documenting that the content of the MEP is ready to
> be implemented into MyHDL.
>
> Once the MEP has the status "Final" and its content got added to the
> source code, the MyHDL version will be added to the MEP document. From
> this time, the text of the document will be frozen.
>
> ------------
>
>
> Cheers, Guenter
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd


-- 
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
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] MEP guidelines

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

On 05/06/2011 11:07 PM, Christopher Felton wrote:
> Sounds good.  But what is the process for ammending a MEP?  In the
> example you provided, how would the MEP documentation be kept upto date
> with the implementation?  Assuming the implementation diversion had
> reasons to change the MEP.

I have not stated it explicitly, but, as Guenter inferred, the idea
of MEPs was indeed to be for MyHDL what PEPs are for Python,
and to reuse the PEP methodology.

The PEP infrastructure has all we will ever need, and much more probably.
Given our resources, it is too heavy to just copy it as is, but we
can use the bits that we need and let it grow as our needs evolve.

Case in point:
A 'Final' MEP should not be changed (except typo's and language
corrections from a neutral proofreader). It is intended to document
the language history for experts. The lanugage documentation is
in the manuals.

> Would a new MEP be created for the changes?

New MEP's can be created and existing ones superseded.

> There should be a method to add this information and the process should
> be added to the text.
>
> Regards,
> Chris
>
> On 5/6/11 10:03 AM, Günter Dannoritzer wrote:
>> Hi,
>>
>> I would like to suggest, adding some guidelines about the MEP process.
>> Seeing that the text of an already implemented MEP got changed, I think
>> it would be helpfull to have some guidelines how the MEP process is
>> intended.
>>
>> I think, that especially an already implemented MEP should be kept for
>> reference as is and not changed later in time. There is the chance, that
>> the original notion of the implementation gets altered by editing the
>> MEP it originated from.
>>
>> My suggestion is to add the text to the MEP introduction page:
>>
>> http://myhdl.org/doku.php/meps:intro
>>
>> The text could be based on the Python Enhancement Proposal, found here:
>>
>> http://www.python.org/dev/peps/pep-0001/
>>
>> Here is a first draft for a text. The first paragraphs are a copy of the
>> PEP text, changed according to MyHDL:
>>
>> ---------
>>
>>
>> MEP stands for MyHDL Enhancement Proposal. A MEP is a design document
>> providing information to the MyHDL community, or describing a new
>> feature for MyHDL. The MEP should provide a concise technical
>> specification of the feature and a rationale for the feature.
>>
>> We intend MEPs to be the primary mechanisms for proposing new features,
>> for collecting community input on an issue, and for documenting the
>> design decisions that have gone into MyHDL. The MEP author is
>> responsible for building consensus within the community and documenting
>> dissenting opinions.
>>
>> MEPs are maintained on the MyHDL wiki page. The page history resembles
>> the development history of the document.
>>
>> Main responsibility of a MEP lies with its author. Before opening a new
>> MEP, its idea should be discussed on the MyHDL mailing list.
>>
>> In the development phase the MEP gets the status "Draft" assigned. Fully
>> developed and provided with a functional implementation, the MEP can get
>> the status "Final", documenting that the content of the MEP is ready to
>> be implemented into MyHDL.
>>
>> Once the MEP has the status "Final" and its content got added to the
>> source code, the MyHDL version will be added to the MEP document. From
>> this time, the text of the document will be frozen.
>>
>> ------------
>>
>>
>> Cheers, Guenter
>>
>> ------------------------------------------------------------------------------
>> WhatsUp Gold - Download Free Network Management Software
>> The most intuitive, comprehensive, and cost-effective network
>> management toolset available today.  Delivers lowest initial
>> acquisition cost and overall TCO of any competing solution.
>> http://p.sf.net/sfu/whatsupgold-sd
>
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd


-- 
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
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] rosettacode submission

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

On 5/9/2011 6:57 AM, Jan Coombs wrote:
> On 09/05/11 12:34, Christopher Felton wrote:
>> On 5/9/2011 6:24 AM, Jan Coombs wrote:
>>> On 02/04/11 18:49, Jan Decaluwe wrote:
>>>>       . . .
>>>> I read that he doesn't agree to give MyHDL it own category.
>>>
>>> Does this look like a good compromise?
>>>
>>>       http://rosettacode.org/wiki/Four_bit_adder#MyHDL
>>>
>>> Any other comments?
>>>
>>> Jan Coombs
>>
>> I thought a separate section for MyHDL would not be provided/added?
>>
>> I still do not prefer the structural approach.  I think the inverter,
>> and2, or2, xor2 should be removed and the operators simply used.
>
> Well, compromises are difficult!:) Because I agree with you I
> posted both my solution and Jan D's.
>
> The proposer of the problem spec said that the verbose version met
> his goals best, so I put mine first.
>
> He also said that MyHDL did not warrant a separate language
> section, which Jan&  I believe is incorrect, so I created a new
> language section.
>
> I hope that more hardware teaching problems are proposed on
> rosettacode, and that further suitable dual style solutions are posted.
>
> Jan Coombs

Thanks for the explanation.  I did not notice the second version.

Chris

Re: [myhdl-list] rosettacode submission

[Jan C. <jan...@mu...>]

On 09/05/11 12:34, Christopher Felton wrote:
> On 5/9/2011 6:24 AM, Jan Coombs wrote:
>> On 02/04/11 18:49, Jan Decaluwe wrote:
>>>      . . .
>>> I read that he doesn't agree to give MyHDL it own category.
>>
>> Does this look like a good compromise?
>>
>>      http://rosettacode.org/wiki/Four_bit_adder#MyHDL
>>
>> Any other comments?
>>
>> Jan Coombs
>
> I thought a separate section for MyHDL would not be provided/added?
>
> I still do not prefer the structural approach.  I think the inverter,
> and2, or2, xor2 should be removed and the operators simply used.

Well, compromises are difficult!:) Because I agree with you I 
posted both my solution and Jan D's.

The proposer of the problem spec said that the verbose version met 
his goals best, so I put mine first.

He also said that MyHDL did not warrant a separate language 
section, which Jan & I believe is incorrect, so I created a new 
language section.

I hope that more hardware teaching problems are proposed on 
rosettacode, and that further suitable dual style solutions are posted.

Jan Coombs

Re: [myhdl-list] rosettacode submission

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

On 5/9/2011 6:24 AM, Jan Coombs wrote:
> On 02/04/11 18:49, Jan Decaluwe wrote:
>>     . . .
>> I read that he doesn't agree to give MyHDL it own category.
>
> Does this look like a good compromise?
>
>     http://rosettacode.org/wiki/Four_bit_adder#MyHDL
>
> Any other comments?
>
> Jan Coombs

I thought a separate section for MyHDL would not be provided/added?

I still do not prefer the structural approach.  I think the inverter, 
and2, or2, xor2 should be removed and the operators simply used.

Chris

Re: [myhdl-list] rosettacode submission

[Jan C. <jan...@mu...>]

On 02/04/11 18:49, Jan Decaluwe wrote:
>    . . .
> I read that he doesn't agree to give MyHDL it own category.

Does this look like a good compromise?

   http://rosettacode.org/wiki/Four_bit_adder#MyHDL

Any other comments?

Jan Coombs

Re: [myhdl-list] MEP guidelines

[Günter D. <dan...@we...>]

On 06.05.2011 23:07, Christopher Felton wrote:
> Sounds good.  But what is the process for ammending a MEP?  In the 
> example you provided, how would the MEP documentation be kept upto date 
> with the implementation?  Assuming the implementation diversion had 
> reasons to change the MEP.
> 
> Would a new MEP be created for the changes?

Looking at the PEP flow again, that is what they do. They create a new
PEP, that runs through the stages 'Draft' and 'Final', with the remark
that it is created to replace another PEP. If the PEP achieves the
'Final' state, the originating PEP will get its status changed from
'Final' to 'Replaced'

In think this process could be used for the MEPs as well. Then adding a
cross reference. So the old MEP gets the MEP number added by which it
got replaced and the new MEP gets the number added which it replaces.

That way the history of MyHDL implementation is documented by the MEP
documents that achieved the status 'Final' or in the process got
'Replaced'. Where as the wiki-history of the individual document shows
the development process of the MEPs.

Cheers, Guenter

Re: [myhdl-list] MEP guidelines

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

Sounds good.  But what is the process for ammending a MEP?  In the 
example you provided, how would the MEP documentation be kept upto date 
with the implementation?  Assuming the implementation diversion had 
reasons to change the MEP.

Would a new MEP be created for the changes?

There should be a method to add this information and the process should 
be added to the text.

Regards,
Chris

On 5/6/11 10:03 AM, Günter Dannoritzer wrote:
> Hi,
>
> I would like to suggest, adding some guidelines about the MEP process.
> Seeing that the text of an already implemented MEP got changed, I think
> it would be helpfull to have some guidelines how the MEP process is
> intended.
>
> I think, that especially an already implemented MEP should be kept for
> reference as is and not changed later in time. There is the chance, that
> the original notion of the implementation gets altered by editing the
> MEP it originated from.
>
> My suggestion is to add the text to the MEP introduction page:
>
> http://myhdl.org/doku.php/meps:intro
>
> The text could be based on the Python Enhancement Proposal, found here:
>
> http://www.python.org/dev/peps/pep-0001/
>
> Here is a first draft for a text. The first paragraphs are a copy of the
> PEP text, changed according to MyHDL:
>
> ---------
>
>
> MEP stands for MyHDL Enhancement Proposal. A MEP is a design document
> providing information to the MyHDL community, or describing a new
> feature for MyHDL. The MEP should provide a concise technical
> specification of the feature and a rationale for the feature.
>
> We intend MEPs to be the primary mechanisms for proposing new features,
> for collecting community input on an issue, and for documenting the
> design decisions that have gone into MyHDL. The MEP author is
> responsible for building consensus within the community and documenting
> dissenting opinions.
>
> MEPs are maintained on the MyHDL wiki page. The page history resembles
> the development history of the document.
>
> Main responsibility of a MEP lies with its author. Before opening a new
> MEP, its idea should be discussed on the MyHDL mailing list.
>
> In the development phase the MEP gets the status "Draft" assigned. Fully
> developed and provided with a functional implementation, the MEP can get
> the status "Final", documenting that the content of the MEP is ready to
> be implemented into MyHDL.
>
> Once the MEP has the status "Final" and its content got added to the
> source code, the MyHDL version will be added to the MEP document. From
> this time, the text of the document will be frozen.
>
> ------------
>
>
> Cheers, Guenter
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd

Re: [myhdl-list] MyHDL / ModelSim cosim

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

On 05/05/2011 02:48 PM, Christopher Felton wrote:
> There was an old thread (last post 31 May 2005, same subject line) that
> addressed a memory leak in Modelsim which also occurred in cver and
> Icarus.  I don't know if this was resolved but the issue still exists in
> the current releases with Modelsim.
>
> In a cosimulations that I was running a simulation would exceed 10GB of
> resident memory usage.  And the simulation would crawl along when this
> occurred.
>
> The fix was to release the handles created by vpi_scan, example
>
> ~~~~~~~~~~~ Code Snip ~~~~~~~~~~~~~~~~~~
> // ~line 416 of myhdl_vpi.c
> while ((value_s.value.str = strtok(NULL, " ")) != NULL) {
>       reg_handle = vpi_scan(reg_iter);
>       vpi_put_value(reg_handle,&value_s, NULL, vpiNoDelay);
>       vpi_free_object(reg_handle);  // **<-- Added line
> }
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> This had to be added in four spots (~line 125, 198, 301, 416).  The
> reg_handle and net_handle in the reg and net iterator loops had to be
> released for each object retrieved (at least for modelsim).  After this
> change my memory usage top out at 222MB (no more leak).
>
> I did not create a patch because I didn't have time to regression test
> cver and Icarus.
>
> I can provide a patch if desired.  Should a separate directory and
> myhdl_vpi.c and Makefile be created for mti in the Cosimulation directory?

Yes, that's the right way, and thanks for debugging this.



-- 
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
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

[myhdl-list] MEP guidelines

[Günter D. <dan...@we...>]

Hi,

I would like to suggest, adding some guidelines about the MEP process.
Seeing that the text of an already implemented MEP got changed, I think
it would be helpfull to have some guidelines how the MEP process is
intended.

I think, that especially an already implemented MEP should be kept for
reference as is and not changed later in time. There is the chance, that
the original notion of the implementation gets altered by editing the
MEP it originated from.

My suggestion is to add the text to the MEP introduction page:

http://myhdl.org/doku.php/meps:intro

The text could be based on the Python Enhancement Proposal, found here:

http://www.python.org/dev/peps/pep-0001/

Here is a first draft for a text. The first paragraphs are a copy of the
PEP text, changed according to MyHDL:

---------


MEP stands for MyHDL Enhancement Proposal. A MEP is a design document
providing information to the MyHDL community, or describing a new
feature for MyHDL. The MEP should provide a concise technical
specification of the feature and a rationale for the feature.

We intend MEPs to be the primary mechanisms for proposing new features,
for collecting community input on an issue, and for documenting the
design decisions that have gone into MyHDL. The MEP author is
responsible for building consensus within the community and documenting
dissenting opinions.

MEPs are maintained on the MyHDL wiki page. The page history resembles
the development history of the document.

Main responsibility of a MEP lies with its author. Before opening a new
MEP, its idea should be discussed on the MyHDL mailing list.

In the development phase the MEP gets the status "Draft" assigned. Fully
developed and provided with a functional implementation, the MEP can get
the status "Final", documenting that the content of the MEP is ready to
be implemented into MyHDL.

Once the MEP has the status "Final" and its content got added to the
source code, the MyHDL version will be added to the MEP document. From
this time, the text of the document will be frozen.

------------


Cheers, Guenter

Re: [myhdl-list] intbv wrap

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

On 5/5/2011 9:21 AM, Ben wrote:
> Hi Christopher,
>
> I took the liberty to review and edit your patch.
>
> As you can see, I added some tests, and removed the inclusion of the
> val property. It became quite smaller ! I left your name in it as the
> idea and the logic is from you.
>
> I also moved the check from the wrap function to the constructor (no
> need to check every time.).

Perfect!  Thanks for the contributions and for the additional test 
cases, very nice.  Also, good catch on the range checking!

Is there an opinion if 'myrange' should be a class member so that it 
doesn't need to be recalculated on each check?  I don't know if there is 
a down side to having too many slots (_range)?

In the future we will need to address if wrap() can be converted or 
changed to a private function?  As discussed in previous threads.

Thanks again Benoît.

Chris

>
> Here is a text version, enclosed a bundle. All tests pass fine.
>
> # HG changeset patch
> # User cfelton
> # Date 1303212809 18000
> # Node ID 145d558e234f363c3e43e9a79ab48ad7e20d7b9b
> # Parent  f77cf2c4a5894013ceb2f5c184d84136ea4f04a3
> Add a wrap parameter to intbv. When set, no overflow will occur.
>
> diff -r f77cf2c4a589 -r 145d558e234f myhdl/_intbv.py
> --- a/myhdl/_intbv.py	Wed May 04 21:33:14 2011 +0200
> +++ b/myhdl/_intbv.py	Tue Apr 19 06:33:29 2011 -0500
> @@ -31,37 +31,46 @@
>   from __builtin__ import max as maxfunc
>
>   class intbv(object):
> -    __slots__ = ('_val', '_min', '_max', '_nrbits')
> +    __slots__ = ('_min', '_max', '_nrbits', '_wrap', '__val')
>
> -    def __init__(self, val=0, min=None, max=None, _nrbits=0):
> +    def __init__(self, val=0, min=None, max=None, wrap=False, _nrbits=0):
>           if _nrbits:
>               self._min = 0
>               self._max = 2**_nrbits
> +            self._nrbits = _nrbits
>           else:
>               self._min = min
>               self._max = max
>               if max is not None and min is not None:
>                   if min>= 0:
> -                    _nrbits = len(bin(max-1))
> +                    self._nrbits = len(bin(max-1))
>                   elif max<= 1:
> -                    _nrbits = len(bin(min))
> +                    self._nrbits = len(bin(min))
>                   else:
>                       # make sure there is a leading zero bit in positive numbers
> -                    _nrbits = maxfunc(len(bin(max-1))+1, len(bin(min)))
> +                    self._nrbits = maxfunc(len(bin(max-1))+1, len(bin(min)))
> +            else:
> +                self._nrbits = 0
> +
> +        if wrap:
> +            myrange = self._nrbits**2
> +            if (abs(self.min) != self.max) or ((abs(self.min) +
> self.max) != myrange):
> +                raise ValueError, "Cannot use wrapping if -min != max
> (%d != %d)" % (-self.min, self.max)
> +        self._wrap  = wrap
>           if isinstance(val, (int, long)):
>               self._val = val
>           elif isinstance(val, StringType):
>               mval = val.replace('_', '')
> +            self._nrbits = len(mval)
>               self._val = long(mval, 2)
> -            _nrbits = len(val)
>           elif isinstance(val, intbv):
>               self._val = val._val
>               self._min = val._min
>               self._max = val._max
> -            _nrbits = val._nrbits
> +            self._wrap = val._wrap
> +            self._nrbits = val._nrbits
>           else:
>               raise TypeError("intbv constructor arg should be int or string")
> -        self._nrbits = _nrbits
>           self._checkBounds()
>
>       # support for the 'min' and 'max' attribute
> @@ -82,6 +91,20 @@
>                   raise ValueError("intbv value %s<  minimum %s" %
>                                    (self._val, self._min))
>
> +    # val property
> +    def _get_val(self):
> +        return self.__val
> +
> +    def _set_val(self, pval):
> +
> +        if self._wrap:
> +            self.__val = self.wrap(pval)
> +        else:
> +            self.__val = pval
> +
> +        self._checkBounds()
> +
> +    _val = property(_get_val, _set_val)
>
>       # hash
>       def __hash__(self):
> @@ -433,6 +456,21 @@
>           return "intbv(" + repr(self._val) + ")"
>
>
> +    def wrap(self, val):
> +        """ Wrap the value back to the range of the inbv
> +
> +        The following will check that the defined min-max is the full
> +        range of the binary word.  If the full range is specified if
> +        the value is outside the bounds of the range it will be adjusted
> +        to the proper value in bounds.
> +        """
> +        myrange = 2**self._nrbits
> +
> +        rval = self.min + ((val +self.max) % myrange)
> +
> +        return rval
> +
> +
>       def signed(self):
>         ''' return integer with the signed value of the intbv instance
>
> diff -r f77cf2c4a589 -r 145d558e234f myhdl/test/core/test_intbv.py
> --- a/myhdl/test/core/test_intbv.py	Wed May 04 21:33:14 2011 +0200
> +++ b/myhdl/test/core/test_intbv.py	Tue Apr 19 06:33:29 2011 -0500
> @@ -576,8 +576,50 @@
>                   self.assertEqual(n.max, m.max)
>                   self.assertEqual(len(n), len(m))
>
> +class TestIntbvWrap(TestCase):
> +
> +    def testWrap(self):
> +        x = intbv(0, min=-8, max=8, wrap=True)
> +        x[:] = x + 1
> +        self.assertEqual(1, x)
> +        x[:] = x + 2
> +        self.assertEqual(3, x)
> +        x[:] = x + 5
> +        self.assertEqual(-8, x)
> +        x[:] = x + 1
> +        self.assertEqual(-7, x)
> +        x[:] = x - 5
> +        self.assertEqual(4, x)
> +        x[:] = x - 4
> +        self.assertEqual(0, x)
> +        x[:] += 15
> +        x[:] = x - 1
> +        self.assertEqual(-2, x)
> +
> +    def testInit(self):
> +        self.assertRaises(ValueError, intbv, 15, min=-8, max=8)
> +        x = intbv(15, min=-8, max=8, wrap=True)
> +        self.assertEqual(-1, x)
> +
> +        self.assertRaises(ValueError, intbv, 5, min=-3, max=8, wrap=True)
> +        intbv(5, min=-3, max=8)
>
>
> +    def testNoWrap(self):
> +        x = intbv(0, min=-8, max=8, wrap=False)
> +        try:
> +            x[:] += 15
> +            self.fail()
> +        except ValueError:
> +            pass
> +
> +        x = intbv(0, min=-8, max=8)
> +        try:
> +            x[:] += 15
> +            self.fail()
> +        except ValueError:
> +            pass
> +
>   if __name__ == "__main__":
>       unittest.main()
>
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Modules interface information

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

On 05/05/2011 10:12 AM, Christopher Lozinski wrote:
> On 5/5/11 4:17 AM, Christopher Felton wrote:
>> >  In traditional HDL you have a well-defined interface in the modules:
> In Zope 3, they solve this kind of problem by having both 
> implementation files, and interface files.  MyHDL already has 
> implementation files.   Obviously the interface files define the 
> interfaces.  Then two different classes can share the same interface.  
> For example there may be two different implementations of a floating 
> point multiplier, that share no code, but have the same interface.  Or 
> you may have two different implementations of an adder that have the 
> same interface.

In Python and MyHDL this is easily handled in the module. If you have 
two (or more) different implementations of the same module, you just 
return the appropriate generator based upon either parameters or I/O types.

Re: [myhdl-list] Modules interface information

[Christopher L. <loz...@fr...>]

On 5/5/11 4:17 AM, Christopher Felton wrote:
> >  In traditional HDL you have a well-defined interface in the modules:
In Zope 3, they solve this kind of problem by having both implementation 
files, and interface files.  MyHDL already has implementation files.   
Obviously the interface files define the interfaces.  Then two different 
classes can share the same interface.  For example there may be two 
different implementations of a floating point multiplier, that share no 
code, but have the same interface.  Or you may have two different 
implementations of an adder that have the same interface.

You can read more here.

http://wiki.zope.org/zope3/WhatAreInterfaces

I will quote a small part of the page.

    Forget those explanations about patterns. And forget about Python
    classes.

    Interfaces are a Zope 3 /invention/ mainly to:

           1. Allow the exposing of an API (every component has an
              external interface.
           2. Allow the Zope 3 machinery to query the interface.

    Interfaces can set constraints - so when you access a /value/ they
    can throw an error allowing for strict(er) type checking.

    Interfaces can set constraints - so, for example, containers know
    what other interfaces can be contained.

    Key to understanding /interfaces/ is that they can be /queried/ and
    /constraints/ can be added. Quite simple, /really/.

  We should be able to just use their interface system without needing 
the rest of Zope 3.

I think that the Zope 3 interfaces system is brilliant.  My 
understanding is that in general it gets a lot of respect.  Indeed it 
allows for appropriate type checking, in a  dynamically typed language. 
Perfect.  And it supports documentation.  And does lots of other 
wonderful things in a Zope 3 environment.  Presumably we will use it in 
other ways to simplify this application, much like decorators proved so 
useful.

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

Re: [myhdl-list] Modules interface information

[Oscar D. <osc...@gm...>]

2011/5/5 Günter Dannoritzer <dan...@we...>:
> Am 05.05.2011 15:45, schrieb Oscar Diaz:
>
> ...
>
> BTW, I did not follow in that example what I was telling you earlier
> about inferring the bit width from the input signal.

Suppose that I want to implement the adder in a structural way with
1-bit adders:

def add1bit(a, b, carry_in, x, carry_out):
    ...

def adder(a, b, x):
    assert len(a) = len(b)
    carry = [Signal(0) for i in range(len(a))]
    add_1bit_list = [ add1bit( a(i), b(i), carry(i), x(i), carry(i+1)
) for i in range(len(a)) ]
    ...

I don't need an explicit width parameter to know how many instances of
add1bit is needed, and I enforce the restriction of 'a' and 'b' to
have the same width.

Again, I think I should pick another better example :P

>
> Cheers, Guenter
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
Oscar Díaz
Huella de clave = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

Recomiendo usar OpenDocument Format
para uso e intercambio de documentos

http://www.spreadopendocument.org/

Re: [myhdl-list] intbv wrap

[Ben <ben...@gm...>]

Hi Christopher,

I took the liberty to review and edit your patch.

As you can see, I added some tests, and removed the inclusion of the
val property. It became quite smaller ! I left your name in it as the
idea and the logic is from you.

I also moved the check from the wrap function to the constructor (no
need to check every time.).

Here is a text version, enclosed a bundle. All tests pass fine.

# HG changeset patch
# User cfelton
# Date 1303212809 18000
# Node ID 145d558e234f363c3e43e9a79ab48ad7e20d7b9b
# Parent  f77cf2c4a5894013ceb2f5c184d84136ea4f04a3
Add a wrap parameter to intbv. When set, no overflow will occur.

diff -r f77cf2c4a589 -r 145d558e234f myhdl/_intbv.py
--- a/myhdl/_intbv.py	Wed May 04 21:33:14 2011 +0200
+++ b/myhdl/_intbv.py	Tue Apr 19 06:33:29 2011 -0500
@@ -31,37 +31,46 @@
 from __builtin__ import max as maxfunc

 class intbv(object):
-    __slots__ = ('_val', '_min', '_max', '_nrbits')
+    __slots__ = ('_min', '_max', '_nrbits', '_wrap', '__val')

-    def __init__(self, val=0, min=None, max=None, _nrbits=0):
+    def __init__(self, val=0, min=None, max=None, wrap=False, _nrbits=0):
         if _nrbits:
             self._min = 0
             self._max = 2**_nrbits
+            self._nrbits = _nrbits
         else:
             self._min = min
             self._max = max
             if max is not None and min is not None:
                 if min >= 0:
-                    _nrbits = len(bin(max-1))
+                    self._nrbits = len(bin(max-1))
                 elif max <= 1:
-                    _nrbits = len(bin(min))
+                    self._nrbits = len(bin(min))
                 else:
                     # make sure there is a leading zero bit in positive numbers
-                    _nrbits = maxfunc(len(bin(max-1))+1, len(bin(min)))
+                    self._nrbits = maxfunc(len(bin(max-1))+1, len(bin(min)))
+            else:
+                self._nrbits = 0
+
+        if wrap:
+            myrange = self._nrbits**2
+            if (abs(self.min) != self.max) or ((abs(self.min) +
self.max) != myrange):
+                raise ValueError, "Cannot use wrapping if -min != max
(%d != %d)" % (-self.min, self.max)
+        self._wrap  = wrap
         if isinstance(val, (int, long)):
             self._val = val
         elif isinstance(val, StringType):
             mval = val.replace('_', '')
+            self._nrbits = len(mval)
             self._val = long(mval, 2)
-            _nrbits = len(val)
         elif isinstance(val, intbv):
             self._val = val._val
             self._min = val._min
             self._max = val._max
-            _nrbits = val._nrbits
+            self._wrap = val._wrap
+            self._nrbits = val._nrbits
         else:
             raise TypeError("intbv constructor arg should be int or string")
-        self._nrbits = _nrbits
         self._checkBounds()

     # support for the 'min' and 'max' attribute
@@ -82,6 +91,20 @@
                 raise ValueError("intbv value %s < minimum %s" %
                                  (self._val, self._min))

+    # val property
+    def _get_val(self):
+        return self.__val
+
+    def _set_val(self, pval):
+
+        if self._wrap:
+            self.__val = self.wrap(pval)
+        else:
+            self.__val = pval
+
+        self._checkBounds()
+
+    _val = property(_get_val, _set_val)

     # hash
     def __hash__(self):
@@ -433,6 +456,21 @@
         return "intbv(" + repr(self._val) + ")"


+    def wrap(self, val):
+        """ Wrap the value back to the range of the inbv
+
+        The following will check that the defined min-max is the full
+        range of the binary word.  If the full range is specified if
+        the value is outside the bounds of the range it will be adjusted
+        to the proper value in bounds.
+        """
+        myrange = 2**self._nrbits
+
+        rval = self.min + ((val +self.max) % myrange)
+
+        return rval
+
+
     def signed(self):
       ''' return integer with the signed value of the intbv instance

diff -r f77cf2c4a589 -r 145d558e234f myhdl/test/core/test_intbv.py
--- a/myhdl/test/core/test_intbv.py	Wed May 04 21:33:14 2011 +0200
+++ b/myhdl/test/core/test_intbv.py	Tue Apr 19 06:33:29 2011 -0500
@@ -576,8 +576,50 @@
                 self.assertEqual(n.max, m.max)
                 self.assertEqual(len(n), len(m))

+class TestIntbvWrap(TestCase):
+
+    def testWrap(self):
+        x = intbv(0, min=-8, max=8, wrap=True)
+        x[:] = x + 1
+        self.assertEqual(1, x)
+        x[:] = x + 2
+        self.assertEqual(3, x)
+        x[:] = x + 5
+        self.assertEqual(-8, x)
+        x[:] = x + 1
+        self.assertEqual(-7, x)
+        x[:] = x - 5
+        self.assertEqual(4, x)
+        x[:] = x - 4
+        self.assertEqual(0, x)
+        x[:] += 15
+        x[:] = x - 1
+        self.assertEqual(-2, x)
+
+    def testInit(self):
+        self.assertRaises(ValueError, intbv, 15, min=-8, max=8)
+        x = intbv(15, min=-8, max=8, wrap=True)
+        self.assertEqual(-1, x)
+
+        self.assertRaises(ValueError, intbv, 5, min=-3, max=8, wrap=True)
+        intbv(5, min=-3, max=8)


+    def testNoWrap(self):
+        x = intbv(0, min=-8, max=8, wrap=False)
+        try:
+            x[:] += 15
+            self.fail()
+        except ValueError:
+            pass
+
+        x = intbv(0, min=-8, max=8)
+        try:
+            x[:] += 15
+            self.fail()
+        except ValueError:
+            pass
+
 if __name__ == "__main__":
     unittest.main()

Re: [myhdl-list] Modules interface information

[Günter D. <dan...@we...>]

Am 05.05.2011 15:45, schrieb Oscar Diaz:

...
> Another point in favor with my colleagues. However there are some
> cases when you need to pass an explicit parameter, i.e. a constant
> that must be different for each instances of the same module.
> 

Yes, and I think you can do distinguish that with coding style. Have a
look at the following example:

http://myhdl.org/doku.php/projects:rounding#rtl_implementation

You should be able to just determine from the interface what is a signal
and what is a parameter. If not, the doc string will tell you for sure.

BTW, I did not follow in that example what I was telling you earlier
about inferring the bit width from the input signal.

Cheers, Guenter

Re: [myhdl-list] Modules interface information

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

Hi,

I will throw my thoughts in on this subject as I have made some very 
flexible modules in MyHDL.

First I think we are too young at this to set any kind of standard in 
stone as we would end up changing the standard later anyway as more 
usesr made reusable MyHDL modules and had input into the standard.

In my use of MyHDL I have for settled on this "standard".

def adder(x,a,b,clk=None,r=None,pipes=0) :

x being required output. a,b being required inputs. clk is an optional 
input, making it synchronous with pipes number of pipelines. r being an 
optional reset input.

I like the outputs first since there are usually less optional outputs 
that inputs.

I would leave all the other details to the module implementations. You 
could make this adder work for any type of I/O or not. Most problems 
will be worked out during simulation and conversion.

For instance, with this adder, x, a, and b may all be intbvs, or maybe b 
is a constant 1, and x and a are intbvs, then you end up with an 
increment by a constant.







On 05/05/2011 08:40 AM, Oscar Diaz wrote:
> 2011/5/5 Christopher Felton<chr...@gm...>:
>> Different people have done it different ways, some have specific
>> functions to check, built into classes, etc.  I think you are asking if
>> there could be a standard published way to address the issue you
>> encountered.
>>
>> I think having some utility functions like this could be useful to those
>> use to the other HDLs.  But, I think a more Pythonic terminology should
>> be used.  Not assert_generic.
> Well, at first I saw this issue as matter of coding standards and good
> practices: an IP must have proper documentation, so why worrying about
> 'ambiguity' in language, as long as the converters infer signals
> correctly? But then two interesting aspects come to mind: the
> "standard published way" as you said, and error-check capabilities.
> Maybe "assert_generic" was too inspired in VHDL and not enough
> pythonic :) .
>
>> Also, for the above width parameter could be removed.  The adder module
>> becomes generic based on the type of signals provided.  Instead of
>> enforcing that the inputs and outputs are a certain width, you might
>> want to assert they follow some set of rules, for the adder example.
>>
>> assert len(x)>= max(len(a), len(b)) + 1
>>
>> That gives the function a little more modularity (more generic).
> Of course that's better than manual parameters, in fact I argue that
> inferring parameters is a lot easier and powerful because you have
> full python for that. Maybe the adder example wasn't making my point,
> I wanted to show how to distinguish between IO signals and parameters,
> so a dumb error like
>
> inst_adder = adder(a=1, b=2, x=sig_out)
>
> is catched as type mismatch: "a and b must be type Signal of intbv, not int"
>
>> In my mind this is a better way to develop IP.  Any IP is going to need
>> documentation above the "entity" definition.  Defining that your IP can
>> except these types (more than a single type) and then the IP enforcing
>> these rules is really good.  Example for the adder, no we can except
>> different a,b sizes, etc.  Instead of having (in this example) different
>> variants of the adder we can have one that is a little more flexible.
> Again, documentation and parameter checking concerns me, but I think
> it would be nice to have a standard way to use it (and have another
> plus point over traditional HDLs). In fact, I like using "assert"
> sentence for that.
>
>>
>> Chris
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> WhatsUp Gold - Download Free Network Management Software
>> The most intuitive, comprehensive, and cost-effective network
>> management toolset available today.  Delivers lowest initial
>> acquisition cost and overall TCO of any competing solution.
>> http://p.sf.net/sfu/whatsupgold-sd
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
> Best regards
>

Re: [myhdl-list] Modules interface information

[Oscar D. <osc...@gm...>]

2011/5/5 Günter Dannoritzer <dan...@we...>:
> Am 05.05.2011 12:00, schrieb Oscar Diaz:
> ...
>> In traditional HDL you have a well-defined interface in the modules:
>> i.e. VHDL has entity declarations with generics and ports, each with a
>> well-defined type. So, you can easily create an IP core and someone
>> can easily see the entity description and hopefully use it correctly.
>
> I agree that you need some documentation about what is an input, output,
> or parameter. But there is some advantage to not specify the port too
> specific. You can create the code in a generic way and specify by the
> interfacing signals its behavior. No need to specify whether the input
> is 8 bit or 16 bit wide. The internal logic will determine it by the
> specified interface signal. - Though works only for input signals. When
> I tried this the last time for output signals, the convertor got
> confused, because I was using information from the output signal and it
> thought I tried to use it as an input.
>
> One interesting idea is conditional instantiation as shown in the manual
> based on a parameter:
>
> http://www.myhdl.org/doc/current/manual/modeling.html#conditional-instantiation
>
> I haven't tested that, but assume you could do it based on the signal
> type as well. So if the interface signal is of type intbv, use some
> implementation that is e.g. different from the implementation than the
> implementation when the input signal is a bool type. ... or any other
> type you can imagine.

Another point in favor with my colleagues. However there are some
cases when you need to pass an explicit parameter, i.e. a constant
that must be different for each instances of the same module.

>
> Cheers, Guenter
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
Oscar Díaz
Huella de clave = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

Recomiendo usar OpenDocument Format
para uso e intercambio de documentos

http://www.spreadopendocument.org/

Re: [myhdl-list] Modules interface information

[Oscar D. <osc...@gm...>]

2011/5/5 Christopher Felton <chr...@gm...>:
>
> Different people have done it different ways, some have specific
> functions to check, built into classes, etc.  I think you are asking if
> there could be a standard published way to address the issue you
> encountered.
>
> I think having some utility functions like this could be useful to those
> use to the other HDLs.  But, I think a more Pythonic terminology should
> be used.  Not assert_generic.

Well, at first I saw this issue as matter of coding standards and good
practices: an IP must have proper documentation, so why worrying about
'ambiguity' in language, as long as the converters infer signals
correctly? But then two interesting aspects come to mind: the
"standard published way" as you said, and error-check capabilities.
Maybe "assert_generic" was too inspired in VHDL and not enough
pythonic :) .

> Also, for the above width parameter could be removed.  The adder module
> becomes generic based on the type of signals provided.  Instead of
> enforcing that the inputs and outputs are a certain width, you might
> want to assert they follow some set of rules, for the adder example.
>
> assert len(x) >= max(len(a), len(b)) + 1
>
> That gives the function a little more modularity (more generic).

Of course that's better than manual parameters, in fact I argue that
inferring parameters is a lot easier and powerful because you have
full python for that. Maybe the adder example wasn't making my point,
I wanted to show how to distinguish between IO signals and parameters,
so a dumb error like

inst_adder = adder(a=1, b=2, x=sig_out)

is catched as type mismatch: "a and b must be type Signal of intbv, not int"

> In my mind this is a better way to develop IP.  Any IP is going to need
> documentation above the "entity" definition.  Defining that your IP can
> except these types (more than a single type) and then the IP enforcing
> these rules is really good.  Example for the adder, no we can except
> different a,b sizes, etc.  Instead of having (in this example) different
> variants of the adder we can have one that is a little more flexible.

Again, documentation and parameter checking concerns me, but I think
it would be nice to have a standard way to use it (and have another
plus point over traditional HDLs). In fact, I like using "assert"
sentence for that.

>
>
> Chris
>
>
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Best regards

-- 
Oscar Díaz
Huella de clave = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

Recomiendo usar OpenDocument Format
para uso e intercambio de documentos

http://www.spreadopendocument.org/

Re: [myhdl-list] Modules interface information

[Günter D. <dan...@we...>]

Am 05.05.2011 14:19, schrieb Christopher Felton:
...
> This is only true if the information accessed was used inside of a 
> generator?  If the bit-width (len) and such is accessed outside of the 
> generators it should not be a problem.
...

It has been a while when I was trying this and don't remember whether I
used the information inside or outside a generator.

I tried to create a fixed point multiplier that would determine the
right amount of rounding based on the width of input and output signals.

I thought, this would be an interesting example to demonstrate, but
don't have the time at the moment to pursue it.

Cheers, Guenter

[myhdl-list] MyHDL / ModelSim cosim

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

There was an old thread (last post 31 May 2005, same subject line) that 
addressed a memory leak in Modelsim which also occurred in cver and 
Icarus.  I don't know if this was resolved but the issue still exists in 
the current releases with Modelsim.

In a cosimulations that I was running a simulation would exceed 10GB of 
resident memory usage.  And the simulation would crawl along when this 
occurred.

The fix was to release the handles created by vpi_scan, example

~~~~~~~~~~~ Code Snip ~~~~~~~~~~~~~~~~~~
// ~line 416 of myhdl_vpi.c
while ((value_s.value.str = strtok(NULL, " ")) != NULL) {
     reg_handle = vpi_scan(reg_iter);
     vpi_put_value(reg_handle, &value_s, NULL, vpiNoDelay);
     vpi_free_object(reg_handle);  // ** <-- Added line
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This had to be added in four spots (~line 125, 198, 301, 416).  The 
reg_handle and net_handle in the reg and net iterator loops had to be 
released for each object retrieved (at least for modelsim).  After this 
change my memory usage top out at 222MB (no more leak).

I did not create a patch because I didn't have time to regression test 
cver and Icarus.

I can provide a patch if desired.  Should a separate directory and 
myhdl_vpi.c and Makefile be created for mti in the Cosimulation directory?

Chris

Re: [myhdl-list] Modules interface information

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

<snip>
 > The internal logic will determine it by the
> specified interface signal. - Though works only for input signals. When
> I tried this the last time for output signals, the convertor got
> confused, because I was using information from the output signal and it
> thought I tried to use it as an input.
>

This is only true if the information accessed was used inside of a 
generator?  If the bit-width (len) and such is accessed outside of the 
generators it should not be a problem.

Do you have a simple example?  Something like this?

def  ioid(a,b,x):

    @always_comb
    def rtl_something():
        x.next = a[int(len(x)/2)] ^ b[int(len(x)/4)]

Chris

Re: [myhdl-list] Modules interface information

[Günter D. <dan...@we...>]

Am 05.05.2011 12:00, schrieb Oscar Diaz:
...
> In traditional HDL you have a well-defined interface in the modules:
> i.e. VHDL has entity declarations with generics and ports, each with a
> well-defined type. So, you can easily create an IP core and someone
> can easily see the entity description and hopefully use it correctly.

I agree that you need some documentation about what is an input, output,
or parameter. But there is some advantage to not specify the port too
specific. You can create the code in a generic way and specify by the
interfacing signals its behavior. No need to specify whether the input
is 8 bit or 16 bit wide. The internal logic will determine it by the
specified interface signal. - Though works only for input signals. When
I tried this the last time for output signals, the convertor got
confused, because I was using information from the output signal and it
thought I tried to use it as an input.

One interesting idea is conditional instantiation as shown in the manual
based on a parameter:

http://www.myhdl.org/doc/current/manual/modeling.html#conditional-instantiation

I haven't tested that, but assume you could do it based on the signal
type as well. So if the interface signal is of type intbv, use some
implementation that is e.g. different from the implementation than the
implementation when the input signal is a bool type. ... or any other
type you can imagine.

Cheers, Guenter