myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] [PATCH 0 of 2 RFC] Add support for negative indexes

[Angel E. <ang...@gm...>]

On Mon, Sep 9, 2013 at 10:11 AM, Jan Decaluwe <ja...@ja...> wrote:
> On 10/13/2012 02:12 AM, Angel Ezquerra wrote:
>> Python lists have a natural way to access list itemps from the end of
>> the list, which is to use negative indexes. These patches add this
>> functionality to MyHDL.
>>
>> The first patch adds negative index and slice limit support to the
>> intbv class. I think this first patch is probably right and not very
>> controversial
>
> intbv's are dual in nature - bit sequence but also integer interpretation.
>
> indexing is at the intersection of the two. An index corresponds
> to a bit position, but also to the power of the bit when
> expanding the integer in a sum of powers of 2. To match
> the natural way of writing numbers, intbv slicing is already
> totally different from any standard python sequence: the direction
> is reversed.
>
> Personally, I haven't seen much need to enhance intbv bit indexing
> to match what you can do with sequences like lists. However, there
> is a very good reason to stress the power of two interpretation:
> when we add a fixbv type, it would be natural to use the same
> interpretation. Negative indices would represent fractional bits.
> It also seems natural that the intbv would like a subtype of
> a general fixbv type.
>
> Therefore, I propose to keep intbv indexing like it is.

Jan,

sorry it took me a while to get the time to respond.

I understand your point that it would be useful to use negative
indexes to indicate fractional bits on a fixbv. However in my
experience I am as likely to need to access bits from the LSB than
from the MSB. I often see VHDL code that needs to do an explicit
mathematical operation to access the 2nd leftmost bit in a
std_logic_vector, for example. I find it silly that you have to care
about such a thing, when the synthesizer can do that calculation for
you. To me this is a very clear example of a way in which a python
based HDL can extend the capabilities of regular HDL syntax, making
what is unnecessarily hard on VHDL or Verilog easy and concise.

Thus I still believe that it would be very useful to be able to refer
to bits from the MSB. The fixbv class will be useful, no doubt, but
there is a lot of code that will keep using regular intbv. I don't
think the capabilities of the intbv class should be limited because
they could interfere with a derived class which is not even finished
yet.

That being said perhaps there is a way to keep negative index bit
access while retaining the capability of accessing fractional fixbv
bits. The trick is to think of the negative index access as a modulo
operation on the length of the bit vector. That is:

    actual_index = index % vector_length

In the case of a fixbv this could be extended by taking into account
the position of the fractional "dot" on the vector as follows:

    actual_index = (index + dot_position) % vector_length

Of course we could just disallow going beyond the limit in the fixbv
case, but the definition would be the same in both classes.

Cheers,

Angel

Re: [myhdl-list] PYTHON WITHIN OPENCL Versus MyHDL

[David B. <dav...@ya...>]

Here is a link !!!
 
http://mathema.tician.de/software/pyopencl
 
David Blubaugh
 
 
 


________________________________
From: Keerthan jai.c <jck...@gm...>
To: David Blubaugh <dav...@ya...>; General discussions on MyHDL <myh...@li...> 
Sent: Tuesday, September 24, 2013 2:33 PM
Subject: Re: [myhdl-list] PYTHON WITHIN OPENCL Versus MyHDL



OpenCL is not a HDL, so you can't really compare Altera's OpenCL implementation to MyHDL.

Also, I can't seem to find any information regarding Altera OpenCL SDK supporting Python. Could you link us to the docs?




On Tue, Sep 24, 2013 at 1:41 PM, David Blubaugh <dav...@ya...> wrote:

I was wondering if anyone has used the altera opencl starter kit with python support and compared it to the impressive capabilities within MyHDL???
>
>Which one is more superior???? 
>
>David Blubaugh
>
>
> 
>------------------------------------------------------------------------------
>October Webinars: Code for Performance
>Free Intel webinars can help you accelerate application performance.
>Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>the latest Intel processors and coprocessors. See abstracts and register >
>http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
>_______________________________________________
>myhdl-list mailing list
>myh...@li...
>https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>


-- 
have a nice day
-jck 

Re: [myhdl-list] PYTHON WITHIN OPENCL Versus MyHDL

[Keerthan jai.c <jck...@gm...>]

OpenCL is not a HDL, so you can't really compare Altera's OpenCL
implementation to MyHDL.

Also, I can't seem to find any information regarding Altera OpenCL SDK
supporting Python. Could you link us to the docs?


On Tue, Sep 24, 2013 at 1:41 PM, David Blubaugh <dav...@ya...
> wrote:

> I was wondering if anyone has used the altera opencl starter kit with
> python support and compared it to the impressive capabilities within
> MyHDL???
>
> Which one is more superior????
>
> David Blubaugh
>
>
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>


-- 
have a nice day
-jck

[myhdl-list] PYTHON WITHIN OPENCL Versus MyHDL

[David B. <dav...@ya...>]

I was wondering if anyone has used the altera opencl starter kit with python support and compared it to the impressive capabilities within MyHDL???
 
Which one is more superior???? 
 
David Blubaugh

Re: [myhdl-list] Bitbucket fork syncing issue.

[Keerthan jai.c <jck...@gm...>]

That fixed it. Thanks!


On Sun, Sep 22, 2013 at 8:31 AM, Christopher Felton
<chr...@gm...>wrote:

> I believe you need to go to your repo settings
> and set the active branch to 0-9dev not default.
>
> Regards,
> Chris
>
>
> On Sat, Sep 21, 2013 at 5:20 PM, Keerthan jai.c <jck...@gm...>wrote:
>
>>  I've forked jandecaluwe/myhdl to jck2/myhdl. After Jan makes updates to
>> the repo, bitbucket gives me the option to sync my fork.
>> However, whenever I do this, bitbucket syncs only the 'default' branch,
>> The changes which Jan made to the 0.9-dev branch don't show up in my fork.
>> How do I fix this? Am I doing something wrong, or is it a bitbucket issue?
>>
>> --
>> have a nice day
>> -jck
>>
>>
>> ------------------------------------------------------------------------------
>> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
>> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
>> SharePoint
>> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
>> includes
>> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>>
>
>
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>


-- 
have a nice day
-jck

Re: [myhdl-list] Bitbucket fork syncing issue.

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

I believe you need to go to your repo settings
and set the active branch to 0-9dev not default.

Regards,
Chris


On Sat, Sep 21, 2013 at 5:20 PM, Keerthan jai.c <jck...@gm...>wrote:

> I've forked jandecaluwe/myhdl to jck2/myhdl. After Jan makes updates to
> the repo, bitbucket gives me the option to sync my fork.
> However, whenever I do this, bitbucket syncs only the 'default' branch,
> The changes which Jan made to the 0.9-dev branch don't show up in my fork.
> How do I fix this? Am I doing something wrong, or is it a bitbucket issue?
>
> --
> have a nice day
> -jck
>
>
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>

[myhdl-list] Bitbucket fork syncing issue.

[Keerthan jai.c <jck...@gm...>]

I've forked jandecaluwe/myhdl to jck2/myhdl. After Jan makes updates to the
repo, bitbucket gives me the option to sync my fork.
However, whenever I do this, bitbucket syncs only the 'default' branch, The
changes which Jan made to the 0.9-dev branch don't show up in my fork. How
do I fix this? Am I doing something wrong, or is it a bitbucket issue?

-- 
have a nice day
-jck

Re: [myhdl-list] attribute enum_encoding: string;

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

These issues have been fixed in development.

On 09/12/2013 08:19 AM, David Holl wrote:
> On Tue, Sep 10, 2013 at 12:28:25PM +0200, Jan Decaluwe wrote:
>> Mm, I suspect there will still be a bug iff an
>> enum type is used at the top-level.
>>
>> If someone provides a failing test case, I'll
>> fix it :-)
>
> Wish granted.  :)  I've attached a test that fails on MyHDL 0.8.  Pardon the
> contrived example; I lobotomized a perfectly functioning state machine to
> achieve using a top-level enum.  (reduced to 2 states, removed PCIe junk...)
>
> It passes toVerilog and conversion.analyze (with .simulator='icarus').
>
> But it will fail during toVHDL, or if you comment out the toVHDL test, it will
> also fail during conversion.analyze (.simulator='GHDL') with this error:
>
>
> subspace(ttys003):~> python test_enum_toVHDL.py
> Analysis succeeded  <-- This message is after passing toVerilog & icarus
> Traceback (most recent call last):
>    File "test_enum_toVHDL.py", line 48, in <module>
>      toVHDL(pcie_legacyint_next_state_logic, state, next_state, next_state_en, interrupt_pending, interrupt_assert)
>    File "/Users/dholl/Library/Python/2.7/lib/python/site-packages/myhdl/conversion/_toVHDL.py", line 173, in __call__
>      assert obj in _enumTypeSet
> AssertionError  <-- This is upon trying either toVHDL or ghdl analysis.
>
>
> - David
>
>
>>
>> On 09/09/2013 02:43 PM, David Holl wrote:
>>> ugh!  My asinine filesystem lockdowns had prevented any recent updates to myhdl, and I had been stuck on an old 0.8dev from Nov 9, 2012.  Updating to the latest 0.8 fixed the problem.
>>>
>>> The vhdl output from the Nov 9th 0.8dev did indeed have a top-level package declared before any other statements such as "use work.pck_myhdl_08.all;"
>>>
>>>      package pck_pcie_drx is
>>>           type t_enum_t_state_1 is (
>>>           SM_RESET,
>>>      ...
>>>
>>> (but my design does not use any enum's in the ports)
>>>
>>> However in the vhdl from the latest 0.8, there is no top-level package, and the code opens with
>>>
>>>      library IEEE;
>>>      use IEEE.std_logic_1164.all;
>>>      use IEEE.numeric_std.all;
>>>      use std.textio.all;
>>>      use work.pck_myhdl_08.all;
>>>      entity pcie_drx is
>>>           port (
>>>               user_clk: in std_logic;
>>>      ...
>>>
>>>
>>> Thank you Chris and Jan for looking into this!
>>> - David
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> How ServiceNow helps IT people transform IT departments:
>>> 1. Consolidate legacy IT systems to a single system of record for IT
>>> 2. Standardize and globalize service processes across IT
>>> 3. Implement zero-touch automation to replace manual, redundant tasks
>>> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
>>>
>>>
>>> _______________________________________________
>>> myhdl-list mailing list
>>> myh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/myhdl-list


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

[myhdl-list] Classes in MyHDL

[Benjamin B. <ben...@si...>]

Hello,

when I first started looking into MyHDL, I really wanted to use classes
to encapsulate different parts of the design. As it turned out this was
rather impossible (I did try to hack it, but the ast parser failed).

Now, the enhancement proposals that exist seem to fix some of the issues
that prevent classes from being used in MyHDL. However, I think that
MyHDL could be enhanced a lot more if one figures out a good overall
concept of using classes to model hardware and hierarchy.

Using classes in MyHDL would mean directly building on top of the python
classes, so it seems sane to map some of the software concepts into
hardware.
With python, we have three different pieces in the puzzle:
 1. The object or instance. This is a live instance of a class.
 2. The class. It defines the behaviour of instances.
 3. The metaclass. It can dynamically create new classes.

Now, the instance and classes can simply be mapped to exactly the
equivalent constructs in VDHL/Verilog.
Feature wise this means:
 * The hierarchy can be correctly modelled (Instances).
 * Classes should be synthesizable and can be converted to VHDL/Verilog.
   -> They need port definitions!
   -> Configuration needs to be static!

Metaclasses could be used to create highly configurable HW designs;
which is very powerful as the whole of python can used during the
parameterization (eg. to create LUTs).

I think that these design decisions would make a lot of sense. They do
already cause some interesting problems (I am not going to go into the
details in this e-mail[1]).

And there are a lot more issues that need to be considered[2]. For
example, one direct consequence of the statement that a class should be
synthesizeable is, that the input/output ports need to be correctly
defined.
Because of this, I was thinking about introducing a "Port" class, which
would usually be a proxy to access the underlying signal.

Here is a very simple example (without instances inside a class, etc.)
of how I would expect that it could look like:

----
import myhdl

class Adder(myhdl.Object):
    in1 = myhdl.Port(myhdl.modbv(0)[32:])
    in2 = myhdl.Port(myhdl.modbv(0)[32:])
    out = myhdl.Port(myhdl.modbv(0)[32:], output=True)

    @myhdl.always_comb
    def add(self):
        self.out.next = self.in1 + self.in2

# The class can be converted
myhdl.toVHDL(Adder)

output = myhdl.Signal(myhdl.intbv(0)[32:])

# Signals can be connected in the constructor
a = Adder(out=output)

# or even later on
in1 = myhdl.Signal(a.in1)
in2 = myhdl.Signal(a.in2)

in1.next = 4
in2.next = 5

myhdl.Simulation(a).run()
print(output.val)

----

Now, this might just be a pipe dream, and a lot of things need to be
properly thought through so that one would get a consistent design. But
it seems to me that it could be pretty nice.
Unfortunately I am not sure whether I will be able to put much time into
this myself.

Regads,
Benjamin

[1] One consequence for example is that a class already owns instances,
so instantiating the class requires to deep copy or to recreate the
instances. And then the ports/signals need to be connected correctly. I
am convinced though that these kind of issues can be hidden from the
user; it might require metaclasses though :-)

[2] children; subclasses; mixins; how interfaces could be defined;
metaclass API for configurable classes; ...

Re: [myhdl-list] MEP 107 Initial support

[Keerthan jai.c <jck...@gm...>]

I've pushed a fix for the list of signals naming issue. However, I think
the dynamic attribute issue is a part of a bigger design flaw. I'll look
over it sometime next week.


On Sat, Sep 14, 2013 at 6:58 AM, Jan Decaluwe <ja...@ja...> wrote:

> On 09/14/2013 12:08 PM, Keerthan jai.c wrote:
> > Jan, could you elaborate on the dynamically set attributes case?
> > None of the tests in conversion/toVerilog seem to be failing for me.
>
> jand@gamay:~/dev/myhdl/myhdl/test/conversion/toVerilog$ py.test
> test_newcustom.py
> ==========================================================================
> test session starts
> ==========================================================================
> platform linux2 -- Python 2.6.5 -- pytest-2.0.1
> collected 7 items
>
> test_newcustom.py .F.....
>
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>      Python as a HDL: http://www.myhdl.org
>      VHDL development, the modern way: http://www.sigasi.com
>      World-class digital design: http://www.easics.com
>
>
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
have a nice day
-jck

[myhdl-list] myhdl and benchmarking pypy versions

[Matti P. <mat...@gm...>]

Hi. Could you update the performance page
http://www.myhdl.org/doku.php/performance#historical_data
with one of the latest versions of PyPy?
Thanks,
Matti

Re: [myhdl-list] 0.8.1 bug fix release scheduled

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

<snip>
> Consequently, I plan a bug fix release 0.8.1 soon. If
> there are any other *critical* bugs, we can address
> them also - but no new features or major changes.
>

There is a bug (I believe) in the tri-state
conversion for Verilog, it appears to work in
VHDL.  It has been awhile since I looked at this,
I believe the issue is simply the port definition
is not /inout/ in the Verilog conversion.

I can write a test for this but it will probably
be a week before I can get to it.  Example code
here.

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

Regards,
Chris

Re: [myhdl-list] MEP 107 Initial support

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

On 09/14/2013 12:08 PM, Keerthan jai.c wrote:
> Jan, could you elaborate on the dynamically set attributes case?
> None of the tests in conversion/toVerilog seem to be failing for me.

jand@gamay:~/dev/myhdl/myhdl/test/conversion/toVerilog$ py.test test_newcustom.py
========================================================================== test session starts ==========================================================================
platform linux2 -- Python 2.6.5 -- pytest-2.0.1
collected 7 items

test_newcustom.py .F.....


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

Re: [myhdl-list] MEP 107 Initial support

[Keerthan jai.c <jck...@gm...>]

Jan, could you elaborate on the dynamically set attributes case?
None of the tests in conversion/toVerilog seem to be failing for me.




On Fri, Sep 13, 2013 at 5:37 PM, Jan Decaluwe <ja...@ja...> wrote:

> I have merged this in now on bitbucket.
>
> Development is now on branch 0.9-dev, bug fixes for 0.8 on
> branch default.
>
> The merged-in new functionality is major - I encourage all to
> test further. If it all works as advertised, this is exciting
> because it is a fantastic example of how we can support advanced
> features (interfaces) in conversion even when the target languages
> don't support them. Let's test this thoroughly, and then create
> a lot of buzz about it :-)
>
> NOTE: There are 2 known issues to be resolved, one with list of Signals
> naming (discovered by jck), another with dynamically set
> attributes (discovered by me, see failing unit test in
> conversion/toVerilog and conversion/toVHDL.
>
> I also propose that MEP 107 is adapted to the current
> implementation if necessary - (iff there are features not yet supported
> I suggest to factor them out for a future MEP).
>
> Thanks Chris for already starting with the documentation.
>
> Jan
>
>
> On 09/11/2013 09:47 PM, Jan Decaluwe wrote:
> > Hi Keerthan,
> >
> > Thanks for the efforts, I think this is going to be a great enhancement.
> >
> > Before proceeding, I have posted some comments/questions to the
> > pull request. (I propose to keep the detail discussion there, right
> > with the pull request.)
> >
> > Jan
> >
> >
> > On 08/07/2013 11:59 PM, Keerthan jai.c wrote:
> >> I just created a 0.9-dev branch, merged the mep107 branch into it and
> >> sent a pull request to jandecaluwe/myhdl.
> >>
> >>
> >> If you would like to improve upon this implementation, you can fork
> >> the mep107 branch at https://bitbucket.org/jck2/myhdl/**and send me a
> >> pull request.
> >>
> >> The full changeset can be viewed here:
> >> https://bitbucket.org/jandecaluwe/myhdl/pull-request/3/
> >>
> >>
> >> On Wed, Aug 7, 2013 at 5:33 PM, Keerthan jai.c <jck...@gm...
> >> <mailto:jck...@gm...>> wrote:
> >>
> >> Oops, the first line in __init__ of Operand should be: concat(opcode,
> >> a, b)
> >>
> >>
> >> On Wed, Aug 7, 2013 at 5:30 PM, Keerthan jai.c <jck...@gm...
> >> <mailto:jck...@gm...>> wrote:
> >>
> >> I just pushed better support for dealing with signal attributes.
> >>
> >> This enables us to do cool things such as subclassing Signal to
> >> define a bitfield. Among other things, I beleive this feature will be
> >> helpful to describe things like instruction opcodes, which are
> >> actually a single signal(in memory), rather than a collection of
> >> discrete signals. For example:
> >>
> >> class Operand(Signal): def __init__(opcode=intbv(0)[4:],
> >> a=intbv(0)[8:], b=intbv(0)[8:]): val = concat(fielda, fieldb)
> >> super(Operand, self).__init__(val) self.opcode = self(20, 16) self.a
> >> = self(16, 8) self.b = self(8, 0)
> >>
> >> def decoder(operand, ...): @always_comb def logic(): if
> >> operand.opcode == ... ...
> >>
> >> and in the generated HDL, operand.opcode would refer to bits 20:16.
> >>
> >>
> >>
> >> On Mon, Aug 5, 2013 at 10:11 PM, Christopher Felton
> >> <chr...@gm... <mailto:chr...@gm...>> wrote:
> >>
> >> On 7/29/13 5:23 PM, Keerthan jai.c wrote:
> >>> Thanks a lot Chris!
> >>>
> >>> Jan, Did you get a chance to take a look at the implementation? I
> >>> would love to hear some feedback on whether you think this
> >>> implementation can be merged into myhdl.
> >>>
> >>>
> >>
> >> @jck,
> >>
> >> I just submitted a pull-request with some mods to the tests and a
> >> start on some documentation.  At this point I would suggest we create
> >> a 0.9-dev branch, merge the mep-107 to the 0.9-dev, and create a
> >> pull-request to Jan's repo.
> >>
> >> It will be easier to comment on the changes etc. in the
> >> pull-request.
> >>
> >> Regards, Chris
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >>
> > Get your SQL database under version control now!
> >> Version control is standard for application code, but databases
> >> havent caught up. So what steps can you take to put your SQL
> >> databases under version control? Why should you start doing it? Read
> >> more to find out.
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> >>
> >>
> > _______________________________________________
> >> myhdl-list mailing list myh...@li...
> >> <mailto:myh...@li...>
> >> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >>
> >>
> >>
> >>
> >> -- have a nice day -jck
> >>
> >>
> >>
> >>
> >> -- have a nice day -jck
> >>
> >>
> >>
> >>
> >> -- have a nice day -jck
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >>
> > Get 100% visibility into Java/.NET code with AppDynamics Lite!
> >> It's a free troubleshooting tool designed for production. Get down to
> >> code-level detail for bottlenecks, with <2% overhead. Download for
> >> free and get started troubleshooting in minutes.
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> >>
> >>
> >>
> >>
> >> _______________________________________________ myhdl-list mailing
> >> list myh...@li...
> >> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >>
> >
> >
>
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>      Python as a HDL: http://www.myhdl.org
>      VHDL development, the modern way: http://www.sigasi.com
>      World-class digital design: http://www.easics.com
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. Consolidate legacy IT systems to a single system of record for IT
> 2. Standardize and globalize service processes across IT
> 3. Implement zero-touch automation to replace manual, redundant tasks
> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
have a nice day
-jck

[myhdl-list] 0.8.1 bug fix release scheduled

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

David Holl has found a critical bug on the behavior of
modbv.

There is a fix in development now.

Consequently, I plan a bug fix release 0.8.1 soon. If
there are any other *critical* bugs, we can address
them also - but no new features or major changes.

Jan

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

Re: [myhdl-list] attribute enum_encoding: string;

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

Mm, this fails on toVHDL() already, regardless of the
encoding ... something else is wrong here.


On 09/12/2013 08:19 AM, David Holl wrote:
> On Tue, Sep 10, 2013 at 12:28:25PM +0200, Jan Decaluwe wrote:
>> Mm, I suspect there will still be a bug iff an
>> enum type is used at the top-level.
>>
>> If someone provides a failing test case, I'll
>> fix it :-)
>
> Wish granted.  :)  I've attached a test that fails on MyHDL 0.8.  Pardon the
> contrived example; I lobotomized a perfectly functioning state machine to
> achieve using a top-level enum.  (reduced to 2 states, removed PCIe junk...)
>
> It passes toVerilog and conversion.analyze (with .simulator='icarus').
>
> But it will fail during toVHDL, or if you comment out the toVHDL test, it will
> also fail during conversion.analyze (.simulator='GHDL') with this error:
>
>
> subspace(ttys003):~> python test_enum_toVHDL.py
> Analysis succeeded  <-- This message is after passing toVerilog & icarus
> Traceback (most recent call last):
>    File "test_enum_toVHDL.py", line 48, in <module>
>      toVHDL(pcie_legacyint_next_state_logic, state, next_state, next_state_en, interrupt_pending, interrupt_assert)
>    File "/Users/dholl/Library/Python/2.7/lib/python/site-packages/myhdl/conversion/_toVHDL.py", line 173, in __call__
>      assert obj in _enumTypeSet
> AssertionError  <-- This is upon trying either toVHDL or ghdl analysis.
>
>
> - David
>
>
>>
>> On 09/09/2013 02:43 PM, David Holl wrote:
>>> ugh!  My asinine filesystem lockdowns had prevented any recent updates to myhdl, and I had been stuck on an old 0.8dev from Nov 9, 2012.  Updating to the latest 0.8 fixed the problem.
>>>
>>> The vhdl output from the Nov 9th 0.8dev did indeed have a top-level package declared before any other statements such as "use work.pck_myhdl_08.all;"
>>>
>>>      package pck_pcie_drx is
>>>           type t_enum_t_state_1 is (
>>>           SM_RESET,
>>>      ...
>>>
>>> (but my design does not use any enum's in the ports)
>>>
>>> However in the vhdl from the latest 0.8, there is no top-level package, and the code opens with
>>>
>>>      library IEEE;
>>>      use IEEE.std_logic_1164.all;
>>>      use IEEE.numeric_std.all;
>>>      use std.textio.all;
>>>      use work.pck_myhdl_08.all;
>>>      entity pcie_drx is
>>>           port (
>>>               user_clk: in std_logic;
>>>      ...
>>>
>>>
>>> Thank you Chris and Jan for looking into this!
>>> - David
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> How ServiceNow helps IT people transform IT departments:
>>> 1. Consolidate legacy IT systems to a single system of record for IT
>>> 2. Standardize and globalize service processes across IT
>>> 3. Implement zero-touch automation to replace manual, redundant tasks
>>> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
>>>
>>>
>>> _______________________________________________
>>> myhdl-list mailing list
>>> myh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/myhdl-list


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

Re: [myhdl-list] MEP 107 Initial support

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

I have merged this in now on bitbucket.

Development is now on branch 0.9-dev, bug fixes for 0.8 on
branch default.

The merged-in new functionality is major - I encourage all to
test further. If it all works as advertised, this is exciting
because it is a fantastic example of how we can support advanced
features (interfaces) in conversion even when the target languages
don't support them. Let's test this thoroughly, and then create
a lot of buzz about it :-)

NOTE: There are 2 known issues to be resolved, one with list of Signals
naming (discovered by jck), another with dynamically set
attributes (discovered by me, see failing unit test in
conversion/toVerilog and conversion/toVHDL.

I also propose that MEP 107 is adapted to the current
implementation if necessary - (iff there are features not yet supported
I suggest to factor them out for a future MEP).

Thanks Chris for already starting with the documentation.

Jan


On 09/11/2013 09:47 PM, Jan Decaluwe wrote:
> Hi Keerthan,
>
> Thanks for the efforts, I think this is going to be a great enhancement.
>
> Before proceeding, I have posted some comments/questions to the
> pull request. (I propose to keep the detail discussion there, right
> with the pull request.)
>
> Jan
>
>
> On 08/07/2013 11:59 PM, Keerthan jai.c wrote:
>> I just created a 0.9-dev branch, merged the mep107 branch into it and
>> sent a pull request to jandecaluwe/myhdl.
>>
>>
>> If you would like to improve upon this implementation, you can fork
>> the mep107 branch at https://bitbucket.org/jck2/myhdl/**and send me a
>> pull request.
>>
>> The full changeset can be viewed here:
>> https://bitbucket.org/jandecaluwe/myhdl/pull-request/3/
>>
>>
>> On Wed, Aug 7, 2013 at 5:33 PM, Keerthan jai.c <jck...@gm...
>> <mailto:jck...@gm...>> wrote:
>>
>> Oops, the first line in __init__ of Operand should be: concat(opcode,
>> a, b)
>>
>>
>> On Wed, Aug 7, 2013 at 5:30 PM, Keerthan jai.c <jck...@gm...
>> <mailto:jck...@gm...>> wrote:
>>
>> I just pushed better support for dealing with signal attributes.
>>
>> This enables us to do cool things such as subclassing Signal to
>> define a bitfield. Among other things, I beleive this feature will be
>> helpful to describe things like instruction opcodes, which are
>> actually a single signal(in memory), rather than a collection of
>> discrete signals. For example:
>>
>> class Operand(Signal): def __init__(opcode=intbv(0)[4:],
>> a=intbv(0)[8:], b=intbv(0)[8:]): val = concat(fielda, fieldb)
>> super(Operand, self).__init__(val) self.opcode = self(20, 16) self.a
>> = self(16, 8) self.b = self(8, 0)
>>
>> def decoder(operand, ...): @always_comb def logic(): if
>> operand.opcode == ... ...
>>
>> and in the generated HDL, operand.opcode would refer to bits 20:16.
>>
>>
>>
>> On Mon, Aug 5, 2013 at 10:11 PM, Christopher Felton
>> <chr...@gm... <mailto:chr...@gm...>> wrote:
>>
>> On 7/29/13 5:23 PM, Keerthan jai.c wrote:
>>> Thanks a lot Chris!
>>>
>>> Jan, Did you get a chance to take a look at the implementation? I
>>> would love to hear some feedback on whether you think this
>>> implementation can be merged into myhdl.
>>>
>>>
>>
>> @jck,
>>
>> I just submitted a pull-request with some mods to the tests and a
>> start on some documentation.  At this point I would suggest we create
>> a 0.9-dev branch, merge the mep-107 to the 0.9-dev, and create a
>> pull-request to Jan's repo.
>>
>> It will be easier to comment on the changes etc. in the
>> pull-request.
>>
>> Regards, Chris
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
> Get your SQL database under version control now!
>> Version control is standard for application code, but databases
>> havent caught up. So what steps can you take to put your SQL
>> databases under version control? Why should you start doing it? Read
>> more to find out.
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>
>>
> _______________________________________________
>> myhdl-list mailing list myh...@li...
>> <mailto:myh...@li...>
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>>
>>
>>
>> -- have a nice day -jck
>>
>>
>>
>>
>> -- have a nice day -jck
>>
>>
>>
>>
>> -- have a nice day -jck
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production. Get down to
>> code-level detail for bottlenecks, with <2% overhead. Download for
>> free and get started troubleshooting in minutes.
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>
>>
>>
>>
>> _______________________________________________ myhdl-list mailing
>> list myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>
>


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

Re: [myhdl-list] fixed-point thoughts : part two

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

On 9/11/13 3:11 PM, Jan Decaluwe wrote:
> On 09/05/2013 05:28 AM, Christopher Felton wrote:
>
>> It is assumed the /fixbv/ operations will actually return an
>> /int/ same as /intbv/ operations
>>
>>        >>> x1 = fixbv(2.5,min=-8,max=8,res=1/16.)
>>        >>> x2 = fixbv(1.25,min=-8,max=8,res=1/16.)
>>        >>> x1 + x2
>>        15
>>
>> When assigned to another /fixbv/ the value will fit in the
>> format of the accepting object.
>
> No, I don't think that can be right. The equivalent for
> fixbv would be to return a "fix" :-)
>

Yes, I agree.  Ben pointed out the same issue. I changed
the proposed to return a /fixbv/ (since Python doesn't
have a /fix/ :)

Regards,
Chris

> Like intbv, fixbv would be a "number with bit-level features",
> but the actual value of that number should always be as expected.
>

Re: [myhdl-list] fixed-point thoughts : part two

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

<snip>
>>> The same turned, what about:
>>>    >>> fixedbv(1.25,min=-8,max=8,res=1/16.) + 1
>>> To be consistent with the suggestion, this would result in 1.3125. Not
>>> something I would expect.
>>
>> Currently, it would throw an error.
>
> Ah. It seems to me like this could be interesting when adding a
> constant; but it needs careful thought on what the effect on the min/max
> values of a returned fixedbv is (assuming a fixedbv is returned).
> Throwing an error would not block adding such a feature later on.
>

In my head, a constant has an implied format, and the
resolution is /res = 1/, the constant format would be
(assuming only integer constants for now):

     cc = fixbv(1, min=1, max=1+1, res=1)

When doing the operation above

     siii.iiii
   +        si
   -----------

The constant and the /fixbv/ are not aligned, so it needs
to throw an error.  To add a constant to an existing /fixbv/
the /resize/ function would need to be used or added to
a /fixbv/ with a /res = 1/

     >>> x = fixbv(1.25, min=-8, max=8, res=1/16)
     >>> x = x + resize(1,x)  # <-- resize to "x" format

For a complicated expression this gets a little unwieldy.

> Thanks for looking into this,
> Benjamin

Thanks for keeping me honest :)

Re: [myhdl-list] fixed-point thoughts : part two

[Benjamin B. <ben...@si...>]

On Do, 2013-09-12 at 06:07 -0500, Christopher Felton wrote:
> On 9/10/13 5:20 PM, Benjamin Berg wrote:
> > I think there are some serious issues with the behaviour that you are
> > suggest. The fact that two fixedbv added together should return an
> > integer (instead of a floating point value) alone opens a *huge* can of
> > worms.
> 
> I agree, an oversights on my part. I disagree that a
> floating-point value can be used.  The operations need
> to return a /fixbv/.

Yeah, returning a /fixbv/ is the best solution.

> > On Mi, 2013-09-04 at 22:28 -0500, Christopher Felton wrote:
> >>       >>> x = fixbv(0,min=-8,max=8,res=1/16.)
> >>       >>> y = fixbv(0,min=-1,max=1,res=1/128.)
> >>       >>> x + y
> >>       AssertionError: Add: points not aligned
> >>              fixbv(0.00, format=(8,3,4), ) and fixbv(0.00, format=(8,0,7), )
> >
> > A nice assertion error, but now, if I did:
> >        >>> x + x + y
> > Then the result:
> >   1. is not quite defined (either it is wrong, or results in really
> > surprising behaviour, see below)
> >   2. doesn't throw any error!
> 
> Concur, for the operations a /fixbv/ object should
> be returned.  The "book-keeping" needs to occur through-out
> a complex operation.  As you note, if /x+x/ returns an /int/
> the trailing /int + y/ will encounter incorrect behavior.
> 
> Updating the operation to return a /fixbv/, an error will be
> thrown for the example provided

Yup, that solves the issue.

>     >>> x = fixbv(0,min=-8,max=8,res=1/16.)
>     >>> y = fixbv(0,min=-1,max=1,res=1/128.)
>     >>> x + x + y
>     AssertionError: Add: points not aligned
>        fixbv(0.00, format=(9,4,4), ) and fixbv(0.00, format=(8,0,7), )
> 
> Note the intermediate format changed, it has to accommodate
> the intermediate range.

Hm, yes. So the x which originally was (8,3,4) now becomes (9,4,4)
because of the addition. This does make a lot of sense.

> > The same issue occurs when assigning the result of an operation to a new
> > fixedbv type. You do not get *any* error checking whether the point is
> > still at the same spot. The only way around this would be to either
> > return a fixedbv for any operation that happens[1], or a floating point
> > number.
> >
> > Note that as a direct consequence the following code:
> >   >>> int(fixedbv(1.25,min=-8,max=8,res=1/16.)
> > would need to return 20. I personally would expect 1 to be returned.
> 
> This example, 1 is returned and not 20.

I agree that this is the sanest solution :-)

> > The same turned, what about:
> >   >>> fixedbv(1.25,min=-8,max=8,res=1/16.) + 1
> > To be consistent with the suggestion, this would result in 1.3125. Not
> > something I would expect.
> 
> Currently, it would throw an error.

Ah. It seems to me like this could be interesting when adding a
constant; but it needs careful thought on what the effect on the min/max
values of a returned fixedbv is (assuming a fixedbv is returned).
Throwing an error would not block adding such a feature later on.

Thanks for looking into this,
Benjamin

Re: [myhdl-list] fixed-point thoughts : part two

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

On 9/10/13 5:20 PM, Benjamin Berg wrote:
> Hello,
>
> I think there are some serious issues with the behaviour that you are
> suggest. The fact that two fixedbv added together should return an
> integer (instead of a floating point value) alone opens a *huge* can of
> worms.

I agree, an oversights on my part. I disagree that a
floating-point value can be used.  The operations need
to return a /fixbv/.

>
> Lets take your example:
>
> On Mi, 2013-09-04 at 22:28 -0500, Christopher Felton wrote:
>>       >>> x = fixbv(0,min=-8,max=8,res=1/16.)
>>       >>> y = fixbv(0,min=-1,max=1,res=1/128.)
>>       >>> x + y
>>       AssertionError: Add: points not aligned
>>              fixbv(0.00, format=(8,3,4), ) and fixbv(0.00, format=(8,0,7), )
>
> A nice assertion error, but now, if I did:
>        >>> x + x + y
> Then the result:
>   1. is not quite defined (either it is wrong, or results in really
> surprising behaviour, see below)
>   2. doesn't throw any error!

Concur, for the operations a /fixbv/ object should
be returned.  The "book-keeping" needs to occur through-out
a complex operation.  As you note, if /x+x/ returns an /int/
the trailing /int + y/ will encounter incorrect behavior.

Updating the operation to return a /fixbv/, an error will be
thrown for the example provided

    >>> x = fixbv(0,min=-8,max=8,res=1/16.)
    >>> y = fixbv(0,min=-1,max=1,res=1/128.)
    >>> x + x + y
    AssertionError: Add: points not aligned
       fixbv(0.00, format=(9,4,4), ) and fixbv(0.00, format=(8,0,7), )

Note the intermediate format changed, it has to accommodate
the intermediate range.

>
> The same issue occurs when assigning the result of an operation to a new
> fixedbv type. You do not get *any* error checking whether the point is
> still at the same spot. The only way around this would be to either
> return a fixedbv for any operation that happens[1], or a floating point
> number.
>
> Note that as a direct consequence the following code:
>   >>> int(fixedbv(1.25,min=-8,max=8,res=1/16.)
> would need to return 20. I personally would expect 1 to be returned.

This example, 1 is returned and not 20.

>
> The same turned, what about:
>   >>> fixedbv(1.25,min=-8,max=8,res=1/16.) + 1
> To be consistent with the suggestion, this would result in 1.3125. Not
> something I would expect.

Currently, it would throw an error.


Thanks for the comments, I will update part II with this
correction.

Regards,
Chris Felton

Re: [myhdl-list] attribute enum_encoding: string;

[David H. <da...@ad...>]

On Tue, Sep 10, 2013 at 12:28:25PM +0200, Jan Decaluwe wrote:
> Mm, I suspect there will still be a bug iff an
> enum type is used at the top-level.
> 
> If someone provides a failing test case, I'll
> fix it :-)

Wish granted.  :)  I've attached a test that fails on MyHDL 0.8.  Pardon the
contrived example; I lobotomized a perfectly functioning state machine to
achieve using a top-level enum.  (reduced to 2 states, removed PCIe junk...)

It passes toVerilog and conversion.analyze (with .simulator='icarus').

But it will fail during toVHDL, or if you comment out the toVHDL test, it will
also fail during conversion.analyze (.simulator='GHDL') with this error:


subspace(ttys003):~> python test_enum_toVHDL.py
Analysis succeeded  <-- This message is after passing toVerilog & icarus
Traceback (most recent call last):
  File "test_enum_toVHDL.py", line 48, in <module>
    toVHDL(pcie_legacyint_next_state_logic, state, next_state, next_state_en, interrupt_pending, interrupt_assert)
  File "/Users/dholl/Library/Python/2.7/lib/python/site-packages/myhdl/conversion/_toVHDL.py", line 173, in __call__
    assert obj in _enumTypeSet
AssertionError  <-- This is upon trying either toVHDL or ghdl analysis.


- David


> 
> On 09/09/2013 02:43 PM, David Holl wrote:
> > ugh!  My asinine filesystem lockdowns had prevented any recent updates to myhdl, and I had been stuck on an old 0.8dev from Nov 9, 2012.  Updating to the latest 0.8 fixed the problem.
> >
> > The vhdl output from the Nov 9th 0.8dev did indeed have a top-level package declared before any other statements such as "use work.pck_myhdl_08.all;"
> >
> >     package pck_pcie_drx is
> >          type t_enum_t_state_1 is (
> >          SM_RESET,
> >     ...
> >
> > (but my design does not use any enum's in the ports)
> >
> > However in the vhdl from the latest 0.8, there is no top-level package, and the code opens with
> >
> >     library IEEE;
> >     use IEEE.std_logic_1164.all;
> >     use IEEE.numeric_std.all;
> >     use std.textio.all;
> >     use work.pck_myhdl_08.all;
> >     entity pcie_drx is
> >          port (
> >              user_clk: in std_logic;
> >     ...
> >
> >
> > Thank you Chris and Jan for looking into this!
> > - David

Re: [myhdl-list] fixed-point thoughts : part two

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

On 09/11/2013 12:20 AM, Benjamin Berg wrote:

> [1] I am actually very surprised that calculations with /intbv/s have an
> integer result and not an intbv result with the min/max values kept up
> to date.

Actually some operations (e.g. bit invert) return intbv types
themselves. These are clearly "bit-oriented" operations.

In case of arithmetic, I think the current design achieves a "natural"
result by using integers while avoiding a whole lot of bookkeeping
and complexities with doubtful value. The typical operation with
such a result is to assign to another intbv's internal value,
which does the bound checks at that point. The integer is simply
an efficient way to transparantly move values around.

I think it could work in much the same way for a fixbv: the
arithmetic returns fixed point numbers that are assigned
to the internal value of a fixbv or fixbv Signal, and this
assignment does bound checks.

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

Re: [myhdl-list] fixed-point thoughts : part two

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

On 09/05/2013 05:28 AM, Christopher Felton wrote:

> It is assumed the /fixbv/ operations will actually return an
> /int/ same as /intbv/ operations
>
>       >>> x1 = fixbv(2.5,min=-8,max=8,res=1/16.)
>       >>> x2 = fixbv(1.25,min=-8,max=8,res=1/16.)
>       >>> x1 + x2
>       15
>
> When assigned to another /fixbv/ the value will fit in the
> format of the accepting object.

No, I don't think that can be right. The equivalent for
fixbv would be to return a "fix" :-)

Like intbv, fixbv would be a "number with bit-level features",
but the actual value of that number should always be as expected.

Jan

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

Re: [myhdl-list] MEP 107 Initial support

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

Hi Keerthan,

Thanks for the efforts, I think this is going to be a great enhancement.

Before proceeding, I have posted some comments/questions to the
pull request. (I propose to keep the detail discussion there, right
with the pull request.)

Jan


On 08/07/2013 11:59 PM, Keerthan jai.c wrote:
> I just created a 0.9-dev branch, merged the mep107 branch into it and
> sent a pull request to jandecaluwe/myhdl.
>
>
> If you would like to improve upon this implementation, you can fork
> the mep107 branch at https://bitbucket.org/jck2/myhdl/**and send me a
> pull request.
>
> The full changeset can be viewed here:
> https://bitbucket.org/jandecaluwe/myhdl/pull-request/3/
>
>
> On Wed, Aug 7, 2013 at 5:33 PM, Keerthan jai.c <jck...@gm...
> <mailto:jck...@gm...>> wrote:
>
> Oops, the first line in __init__ of Operand should be: concat(opcode,
> a, b)
>
>
> On Wed, Aug 7, 2013 at 5:30 PM, Keerthan jai.c <jck...@gm...
> <mailto:jck...@gm...>> wrote:
>
> I just pushed better support for dealing with signal attributes.
>
> This enables us to do cool things such as subclassing Signal to
> define a bitfield. Among other things, I beleive this feature will be
> helpful to describe things like instruction opcodes, which are
> actually a single signal(in memory), rather than a collection of
> discrete signals. For example:
>
> class Operand(Signal): def __init__(opcode=intbv(0)[4:],
> a=intbv(0)[8:], b=intbv(0)[8:]): val = concat(fielda, fieldb)
> super(Operand, self).__init__(val) self.opcode = self(20, 16) self.a
> = self(16, 8) self.b = self(8, 0)
>
> def decoder(operand, ...): @always_comb def logic(): if
> operand.opcode == ... ...
>
> and in the generated HDL, operand.opcode would refer to bits 20:16.
>
>
>
> On Mon, Aug 5, 2013 at 10:11 PM, Christopher Felton
> <chr...@gm... <mailto:chr...@gm...>> wrote:
>
> On 7/29/13 5:23 PM, Keerthan jai.c wrote:
>> Thanks a lot Chris!
>>
>> Jan, Did you get a chance to take a look at the implementation? I
>> would love to hear some feedback on whether you think this
>> implementation can be merged into myhdl.
>>
>>
>
> @jck,
>
> I just submitted a pull-request with some mods to the tests and a
> start on some documentation.  At this point I would suggest we create
> a 0.9-dev branch, merge the mep-107 to the 0.9-dev, and create a
> pull-request to Jan's repo.
>
> It will be easier to comment on the changes etc. in the
> pull-request.
>
> Regards, Chris
>
>
>
> ------------------------------------------------------------------------------
>
>
Get your SQL database under version control now!
> Version control is standard for application code, but databases
> havent caught up. So what steps can you take to put your SQL
> databases under version control? Why should you start doing it? Read
> more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>
>
_______________________________________________
> myhdl-list mailing list myh...@li...
> <mailto:myh...@li...>
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
>
> -- have a nice day -jck
>
>
>
>
> -- have a nice day -jck
>
>
>
>
> -- have a nice day -jck
>
>
> ------------------------------------------------------------------------------
>
>
Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production. Get down to
> code-level detail for bottlenecks, with <2% overhead. Download for
> free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>
>
>
>
> _______________________________________________ myhdl-list mailing
> list myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>


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