myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] MEP 107 need for portmap

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

What i meant was,

def toVerilogNewName(toplevel):

    ret = toVerilog(toplevel, **toplevel.portmap)

    toplevel.vportmap = toVerilog.portmap

    return ret


On Mar 13, 2014 2:29 PM, "Christopher Felton" <chr...@gm...>
wrote:

> On 3/12/2014 3:43 PM, Keerthan jai.c wrote:
> > What do you think about leaving toV* to behave in their current way,
> > storing the portmap in toV*.portmap; and creating new functions which
> wrap
> > these functions and explicitly do what you proposed?
>
> I am not opposed to the wrapper method.  To restate,
> you are suggesting a wrapper, something like:
>
>      toVerilogWithPortmap(m_toplevel, portmap=portmap)
>      pprint(m_toplevel.portmap)   # this will be all the
>                                   # converted ports.
>
> This could be used for a dynamic portmap configuration.
> Sounds fine to me.
>
> Regards,
> Chris
>
> > On Mar 4, 2014 2:26 PM, "Christopher Felton" <chr...@gm...>
> wrote:
> >
> >> On 2/23/2014 6:03 PM, Keerthan jai.c wrote:
> >>> Are you proposing that toV* can now be called in two ways, the usual
> way
> >>> which is overriden if a function has  a portmap attribute?
> >>>
> >>
> >> Yes,
> >>
> >>       # no portmap (current usage)
> >>       toV*(m_top_level, <explicit list of ports>)
> >>
> >>       # using portmat
> >>       m_top_level.portmap = portmap
> >>       toV*(m_top_level)
> >>
> >> Both cases, after the call to toV* vportmap will
> >> be filled in.
> >>
> >>       pprint(m_top_level.vportmap)
> >>
> >> Regards,
> >> Chris
> >>
> >>>
> >>> On Thu, Feb 20, 2014 at 12:02 PM, Christopher Felton <
> >> chr...@gm...
> >>>> wrote:
> >>>
> >>>> On 2/15/2014 3:43 PM, Keerthan jai.c wrote:
> >>>>> I'm not sure which approach is more pythonic in this scenario.
> However,
> >>>>> currently the only interface to the conversion functions are through
> >> toV*
> >>>>> attributes. I think it is more 'consistent' to use toVerilog.portmap,
> >>>>> unless we make the other parameters(such as toVerilog.name) exposed
> >>>> through
> >>>>> top level function attributes too.
> >>>>>
> >>>>
> >>>> I appreciate that the /portmap/ tied to the toV*
> >>>> functions matches (closer) to the current approach
> >>>> to configure the conversions process.
> >>>>
> >>>> But given some of the other conversations I think
> >>>> having a /portmap/ and /vportmap/ tied to the module
> >>>> (top-level function) is useful and worth discussion.
> >>>>
> >>>> If we tie it to the top-level function it gives us
> >>>> two ways - not two ways to do the same thing but two
> >>>> ways to solve different problems.
> >>>>
> >>>> Per the other discussion - if you want conversion
> >>>> time top-level port modifications that are parameterizable
> >>>> for the system you are building.  The ability to do the
> >>>> following, could be useful:
> >>>>
> >>>>        portmap = dict(<list of ports>)
> >>>>        dut = m_top(**portmap)
> >>>>        m_top.portmap = portmap
> >>>>        toV*(m_top)
> >>>>        #  the function portmap attribut is used to
> >>>>        #  define the top-level ports and what they are
> >>>>        #  instead of the compile time args to the func
> >>>>        #  and the passed signals.
> >>>>
> >>>> I think the above is a use case worth considering.
> >>>>
> >>>> I also like the /portmap/ on the top-level function
> >>>> because as designer I can create a default portmap,
> >>>> often a top-level is for a specific hardware, as
> >>>> the module designer I can define the default portmap
> >>>> (shortcut for any user).  I like this because if I
> >>>> have multiple tests, conversion scripts, etc I don't
> >>>> have to recreate the port definitions in each or
> >>>> define the port signals somewhere else (detached).
> >>>>
> >>>> Regards,
> >>>> Chris
> >>>>
> >>>>
> >>>>>
> >>>>> On Fri, Feb 14, 2014 at 8:50 AM, Christopher Felton
> >>>>> <chr...@gm...>wrote:
> >>>>>
> >>>>>> Previously, we had a short discussion that the MEP107
> >>>>>> interface conversion for top-levels (e.g modules being
> >>>>>> converted) introduced a need for a generated /portmap/ [1].
> >>>>>>
> >>>>>> The main uses case, given a module:
> >>>>>>
> >>>>>>         def m_some_mod(ifc1, ifc2):
> >>>>>>             # ...
> >>>>>>
> >>>>>> If I am verifying the above module via co-simulation,
> >>>>>> without a /portmap/ I would need to manually write a
> >>>>>> wrapper or manually breakout all the interface /Signals/
> >>>>>> when building the /Cosimulation/, example:
> >>>>>>
> >>>>>>         Cosimualation(simcmd, ifc1_di=ifc1.di, ifc1_do=ifc1.do ...
> >>>>>>
> >>>>>> In this case it defeats the purpose of the interfaces.
> >>>>>> To address this complication Keerthan proposed a /portmap/
> >>>>>> be generated in the conversion functions, the above would
> >>>>>> then become:
> >>>>>>
> >>>>>>         Cosimulation(simcmd, **portmap)
> >>>>>>
> >>>>>> Ahhh, much better :)
> >>>>>>
> >>>>>> The /toV*/ functions already return a list generators in
> >>>>>> the module.  The /portmap/ can't be returned from the
> >>>>>> /toV*/ functions without breaking backwards compatibility.
> >>>>>>
> >>>>>> The current proposal is to attach a function attribute to the
> >>>>>> /toV*/ functions, e.g:
> >>>>>>
> >>>>>>         toVerilog.portmap
> >>>>>>
> >>>>>> The /toV*.portmap/ would be the dictionary of the converted
> >>>>>> portmap (interface expanded names).
> >>>>>>
> >>>>>> I would like to propose and discuss attaching the /portmap/
> >>>>>> attribute to the function being converted and not the
> >>>>>> conversion functions.  To me this is a more natural (I don't
> >>>>>> know if this is generally pythonic (accepted) to have other
> >>>>>> functions modify and/or add attributes to other functions).
> >>>>>>
> >>>>>> In addition, I would propose that generated portmap saved
> >>>>>> in the /vportmap/ attribute and the /portmap/ attribute
> >>>>>> to be used as a user defined default port definition.
> >>>>>>
> >>>>>> Keerthan has done an amazing job implementing MEP-107, many
> >>>>>> thanks!  He has also created a pull-request for the
> >>>>>> /toVerilog.portmap/, I wanted to have a short discussion
> >>>>>> and make sure this is the most flexible path moving forward.
> >>>>>> Once we finalize the portmap I can update the MEP.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Chris
> >>>>>>
> >>>>>> [1] http://thread.gmane.org/gmane.comp.python.myhdl/3223/focus=3318
> >>>>>>
> >>>>>>
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Subversion Kills Productivity. Get off Subversion & Make the Move to
> >> Perforce.
> >> With Perforce, you get hassle-free workflows. Merge that actually works.
> >> Faster operations. Version large binaries.  Built-in WAN optimization
> and
> >> the
> >> freedom to use Git, Perforce or both. Make the move to Perforce.
> >>
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> myhdl-list mailing list
> >> myh...@li...
> >> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >>
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Learn Graph Databases - Download FREE O'Reilly Book
> > "Graph Databases" is the definitive new guide to graph databases and
> their
> > applications. Written by three acclaimed leaders in the field,
> > this first edition is now available. Download your free book today!
> > http://p.sf.net/sfu/13534_NeoTech
> >
> >
> >
> > _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] myhdl.org new website

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

Hello:

I would like to switch to the new website shortly.

I have migrated all "my" info and worked further on the
sites, so that I think everything is in place.
See http://new.myhdl.org and http://dev.myhdl.org.

To reiterate: no information will be lost. The old content
is in the repository of the new site under _ori.
Not everything has been migrated, but that can continue
later at any pace.

Moreover, the old site will be available "forever" under
http://old.myhdl.org. This link is functional already.

Some specific info:

http://new.myhdl.org
--------------------
1) No user info has been migrated yet. No problem if this
is because of lack of time or motivation. But if people
find the process too "heavy", let's discuss to see if
something can be done about it.

If someone would like help with migration, let me know
also. I can help to get the process started.

2) Should I start a blog on the site? This would be
for short contributions/announcements/testimonials by
any contributor, through direct access or pull requests.
It could perhaps enhance the visibility of the site.
Only if some people are motivated to write something
from time to time.

http://dev.myhdl.org
--------------------
1) Unless Chris F does so, I still want to migrate
the "VHDL cosimulation with GHDL" document and the
"Initial Value Support" document to the Ideas section.
As with all documents, I would migrate first, and bring
the content up to date after we go live.

2) During migration I noticed a MEP that I hadn't noticed
before, because it was not in the sidebar:

http://myhdl.org/doku.php/meps:mep-104

@Thomas Traber: could you elaborate on this? I haven't
read it in detail, but "Getting rid of the Signal" seems
a strange idea to me: Signals are the fundamental objects
of determinism in a HDL like MyHDL.

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 need for portmap

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

On 3/12/2014 3:43 PM, Keerthan jai.c wrote:
> What do you think about leaving toV* to behave in their current way,
> storing the portmap in toV*.portmap; and creating new functions which wrap
> these functions and explicitly do what you proposed?

I am not opposed to the wrapper method.  To restate,
you are suggesting a wrapper, something like:

     toVerilogWithPortmap(m_toplevel, portmap=portmap)
     pprint(m_toplevel.portmap)   # this will be all the
                                  # converted ports.

This could be used for a dynamic portmap configuration.
Sounds fine to me.

Regards,
Chris

> On Mar 4, 2014 2:26 PM, "Christopher Felton" <chr...@gm...> wrote:
>
>> On 2/23/2014 6:03 PM, Keerthan jai.c wrote:
>>> Are you proposing that toV* can now be called in two ways, the usual way
>>> which is overriden if a function has  a portmap attribute?
>>>
>>
>> Yes,
>>
>>       # no portmap (current usage)
>>       toV*(m_top_level, <explicit list of ports>)
>>
>>       # using portmat
>>       m_top_level.portmap = portmap
>>       toV*(m_top_level)
>>
>> Both cases, after the call to toV* vportmap will
>> be filled in.
>>
>>       pprint(m_top_level.vportmap)
>>
>> Regards,
>> Chris
>>
>>>
>>> On Thu, Feb 20, 2014 at 12:02 PM, Christopher Felton <
>> chr...@gm...
>>>> wrote:
>>>
>>>> On 2/15/2014 3:43 PM, Keerthan jai.c wrote:
>>>>> I'm not sure which approach is more pythonic in this scenario. However,
>>>>> currently the only interface to the conversion functions are through
>> toV*
>>>>> attributes. I think it is more 'consistent' to use toVerilog.portmap,
>>>>> unless we make the other parameters(such as toVerilog.name) exposed
>>>> through
>>>>> top level function attributes too.
>>>>>
>>>>
>>>> I appreciate that the /portmap/ tied to the toV*
>>>> functions matches (closer) to the current approach
>>>> to configure the conversions process.
>>>>
>>>> But given some of the other conversations I think
>>>> having a /portmap/ and /vportmap/ tied to the module
>>>> (top-level function) is useful and worth discussion.
>>>>
>>>> If we tie it to the top-level function it gives us
>>>> two ways - not two ways to do the same thing but two
>>>> ways to solve different problems.
>>>>
>>>> Per the other discussion - if you want conversion
>>>> time top-level port modifications that are parameterizable
>>>> for the system you are building.  The ability to do the
>>>> following, could be useful:
>>>>
>>>>        portmap = dict(<list of ports>)
>>>>        dut = m_top(**portmap)
>>>>        m_top.portmap = portmap
>>>>        toV*(m_top)
>>>>        #  the function portmap attribut is used to
>>>>        #  define the top-level ports and what they are
>>>>        #  instead of the compile time args to the func
>>>>        #  and the passed signals.
>>>>
>>>> I think the above is a use case worth considering.
>>>>
>>>> I also like the /portmap/ on the top-level function
>>>> because as designer I can create a default portmap,
>>>> often a top-level is for a specific hardware, as
>>>> the module designer I can define the default portmap
>>>> (shortcut for any user).  I like this because if I
>>>> have multiple tests, conversion scripts, etc I don't
>>>> have to recreate the port definitions in each or
>>>> define the port signals somewhere else (detached).
>>>>
>>>> Regards,
>>>> Chris
>>>>
>>>>
>>>>>
>>>>> On Fri, Feb 14, 2014 at 8:50 AM, Christopher Felton
>>>>> <chr...@gm...>wrote:
>>>>>
>>>>>> Previously, we had a short discussion that the MEP107
>>>>>> interface conversion for top-levels (e.g modules being
>>>>>> converted) introduced a need for a generated /portmap/ [1].
>>>>>>
>>>>>> The main uses case, given a module:
>>>>>>
>>>>>>         def m_some_mod(ifc1, ifc2):
>>>>>>             # ...
>>>>>>
>>>>>> If I am verifying the above module via co-simulation,
>>>>>> without a /portmap/ I would need to manually write a
>>>>>> wrapper or manually breakout all the interface /Signals/
>>>>>> when building the /Cosimulation/, example:
>>>>>>
>>>>>>         Cosimualation(simcmd, ifc1_di=ifc1.di, ifc1_do=ifc1.do ...
>>>>>>
>>>>>> In this case it defeats the purpose of the interfaces.
>>>>>> To address this complication Keerthan proposed a /portmap/
>>>>>> be generated in the conversion functions, the above would
>>>>>> then become:
>>>>>>
>>>>>>         Cosimulation(simcmd, **portmap)
>>>>>>
>>>>>> Ahhh, much better :)
>>>>>>
>>>>>> The /toV*/ functions already return a list generators in
>>>>>> the module.  The /portmap/ can't be returned from the
>>>>>> /toV*/ functions without breaking backwards compatibility.
>>>>>>
>>>>>> The current proposal is to attach a function attribute to the
>>>>>> /toV*/ functions, e.g:
>>>>>>
>>>>>>         toVerilog.portmap
>>>>>>
>>>>>> The /toV*.portmap/ would be the dictionary of the converted
>>>>>> portmap (interface expanded names).
>>>>>>
>>>>>> I would like to propose and discuss attaching the /portmap/
>>>>>> attribute to the function being converted and not the
>>>>>> conversion functions.  To me this is a more natural (I don't
>>>>>> know if this is generally pythonic (accepted) to have other
>>>>>> functions modify and/or add attributes to other functions).
>>>>>>
>>>>>> In addition, I would propose that generated portmap saved
>>>>>> in the /vportmap/ attribute and the /portmap/ attribute
>>>>>> to be used as a user defined default port definition.
>>>>>>
>>>>>> Keerthan has done an amazing job implementing MEP-107, many
>>>>>> thanks!  He has also created a pull-request for the
>>>>>> /toVerilog.portmap/, I wanted to have a short discussion
>>>>>> and make sure this is the most flexible path moving forward.
>>>>>> Once we finalize the portmap I can update the MEP.
>>>>>>
>>>>>> Regards,
>>>>>> Chris
>>>>>>
>>>>>> [1] http://thread.gmane.org/gmane.comp.python.myhdl/3223/focus=3318
>>>>>>
>>>>>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Subversion Kills Productivity. Get off Subversion & Make the Move to
>> Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries.  Built-in WAN optimization and
>> the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] simulation coding vs conversion coding

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

On 3/12/14 4:25 PM, Keerthan jai.c wrote:
> Chris, can you confirm whether this works for you?
> This does not work for me with 0.8 or 0.9dev upstream.
>
> The code I tried is here:
> https://gist.github.com/9516513
>
> I ran into this problem a few months ago, and implemented a fix for
> verilog in this commit:
> https://bitbucket.org/jck2/myhdl/commits/68d86530af4e8a7cd9fb9ca0102a97ebbb93bbb9?at=sf-hotfixes
> I have not sent a PR yet since I didn't investigate this properly.
>

Yes, I observe the error with 0.8.1 and 0.9dev.

I don't recall if this is a known limitation or error?

This is a valid work around though:

     def ab(in1,out1):
         one=[Signal(intbv(0)[2:]) for k in range(2)]
         item = Signal(in1.val)

         @always_comb
         def comb1():
             item = one[0]
             item.next[0] = in1

         always_comb
         def comb2():
             one[0].next = item

         @always_comb
         def comb3():
             out1.next=one[0][0]

         return instances()

Regards,
Chris

Re: [myhdl-list] simulation coding vs conversion coding

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

Chris, can you confirm whether this works for you?
This does not work for me with 0.8 or 0.9dev upstream.

The code I tried is here:
https://gist.github.com/9516513

I ran into this problem a few months ago, and implemented a fix for verilog
in this commit:
https://bitbucket.org/jck2/myhdl/commits/68d86530af4e8a7cd9fb9ca0102a97ebbb93bbb9?at=sf-hotfixes
I have not sent a PR yet since I didn't investigate this properly.

Lars, you could try making this change to _toVHDL.py and see if it works.



On Tue, Mar 11, 2014 at 7:13 AM, Christopher Felton
<chr...@gm...>wrote:

> On 3/11/14 1:59 AM, Marcel Hellwig wrote:
> > Hi Lars,
> >> one=[Signal(intbv(0)[2:]) for k in range(2)]
> > do this instead:
> >
> >> one, two = [Signal(intbv(0)[2:]) for k in range(2)]
> >
> > it should avoid your problem.
> >
>
> I believe Lars is trying to use a list of signals, the
> above won't work.  You can use list of signals to model
> memory or other logical structures.
>
>
> http://www.myhdl.org/doc/current/manual/conversion_examples.html?highlight=list%20signals#ram-inference
>
> What was posted is the correct approach to bit slice
> into the individual intbv in the list.
>
>      one[n].next[b] = in
>          |       |
>          |       +- intbv bit index
>          +--------- list index
>
> Regards,
> Chris
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
have a nice day
-jck

Re: [myhdl-list] MEP 107 need for portmap

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

What do you think about leaving toV* to behave in their current way,
storing the portmap in toV*.portmap; and creating new functions which wrap
these functions and explicitly do what you proposed?
On Mar 4, 2014 2:26 PM, "Christopher Felton" <chr...@gm...> wrote:

> On 2/23/2014 6:03 PM, Keerthan jai.c wrote:
> > Are you proposing that toV* can now be called in two ways, the usual way
> > which is overriden if a function has  a portmap attribute?
> >
>
> Yes,
>
>      # no portmap (current usage)
>      toV*(m_top_level, <explicit list of ports>)
>
>      # using portmat
>      m_top_level.portmap = portmap
>      toV*(m_top_level)
>
> Both cases, after the call to toV* vportmap will
> be filled in.
>
>      pprint(m_top_level.vportmap)
>
> Regards,
> Chris
>
> >
> > On Thu, Feb 20, 2014 at 12:02 PM, Christopher Felton <
> chr...@gm...
> >> wrote:
> >
> >> On 2/15/2014 3:43 PM, Keerthan jai.c wrote:
> >>> I'm not sure which approach is more pythonic in this scenario. However,
> >>> currently the only interface to the conversion functions are through
> toV*
> >>> attributes. I think it is more 'consistent' to use toVerilog.portmap,
> >>> unless we make the other parameters(such as toVerilog.name) exposed
> >> through
> >>> top level function attributes too.
> >>>
> >>
> >> I appreciate that the /portmap/ tied to the toV*
> >> functions matches (closer) to the current approach
> >> to configure the conversions process.
> >>
> >> But given some of the other conversations I think
> >> having a /portmap/ and /vportmap/ tied to the module
> >> (top-level function) is useful and worth discussion.
> >>
> >> If we tie it to the top-level function it gives us
> >> two ways - not two ways to do the same thing but two
> >> ways to solve different problems.
> >>
> >> Per the other discussion - if you want conversion
> >> time top-level port modifications that are parameterizable
> >> for the system you are building.  The ability to do the
> >> following, could be useful:
> >>
> >>       portmap = dict(<list of ports>)
> >>       dut = m_top(**portmap)
> >>       m_top.portmap = portmap
> >>       toV*(m_top)
> >>       #  the function portmap attribut is used to
> >>       #  define the top-level ports and what they are
> >>       #  instead of the compile time args to the func
> >>       #  and the passed signals.
> >>
> >> I think the above is a use case worth considering.
> >>
> >> I also like the /portmap/ on the top-level function
> >> because as designer I can create a default portmap,
> >> often a top-level is for a specific hardware, as
> >> the module designer I can define the default portmap
> >> (shortcut for any user).  I like this because if I
> >> have multiple tests, conversion scripts, etc I don't
> >> have to recreate the port definitions in each or
> >> define the port signals somewhere else (detached).
> >>
> >> Regards,
> >> Chris
> >>
> >>
> >>>
> >>> On Fri, Feb 14, 2014 at 8:50 AM, Christopher Felton
> >>> <chr...@gm...>wrote:
> >>>
> >>>> Previously, we had a short discussion that the MEP107
> >>>> interface conversion for top-levels (e.g modules being
> >>>> converted) introduced a need for a generated /portmap/ [1].
> >>>>
> >>>> The main uses case, given a module:
> >>>>
> >>>>        def m_some_mod(ifc1, ifc2):
> >>>>            # ...
> >>>>
> >>>> If I am verifying the above module via co-simulation,
> >>>> without a /portmap/ I would need to manually write a
> >>>> wrapper or manually breakout all the interface /Signals/
> >>>> when building the /Cosimulation/, example:
> >>>>
> >>>>        Cosimualation(simcmd, ifc1_di=ifc1.di, ifc1_do=ifc1.do ...
> >>>>
> >>>> In this case it defeats the purpose of the interfaces.
> >>>> To address this complication Keerthan proposed a /portmap/
> >>>> be generated in the conversion functions, the above would
> >>>> then become:
> >>>>
> >>>>        Cosimulation(simcmd, **portmap)
> >>>>
> >>>> Ahhh, much better :)
> >>>>
> >>>> The /toV*/ functions already return a list generators in
> >>>> the module.  The /portmap/ can't be returned from the
> >>>> /toV*/ functions without breaking backwards compatibility.
> >>>>
> >>>> The current proposal is to attach a function attribute to the
> >>>> /toV*/ functions, e.g:
> >>>>
> >>>>        toVerilog.portmap
> >>>>
> >>>> The /toV*.portmap/ would be the dictionary of the converted
> >>>> portmap (interface expanded names).
> >>>>
> >>>> I would like to propose and discuss attaching the /portmap/
> >>>> attribute to the function being converted and not the
> >>>> conversion functions.  To me this is a more natural (I don't
> >>>> know if this is generally pythonic (accepted) to have other
> >>>> functions modify and/or add attributes to other functions).
> >>>>
> >>>> In addition, I would propose that generated portmap saved
> >>>> in the /vportmap/ attribute and the /portmap/ attribute
> >>>> to be used as a user defined default port definition.
> >>>>
> >>>> Keerthan has done an amazing job implementing MEP-107, many
> >>>> thanks!  He has also created a pull-request for the
> >>>> /toVerilog.portmap/, I wanted to have a short discussion
> >>>> and make sure this is the most flexible path moving forward.
> >>>> Once we finalize the portmap I can update the MEP.
> >>>>
> >>>> Regards,
> >>>> Chris
> >>>>
> >>>> [1] http://thread.gmane.org/gmane.comp.python.myhdl/3223/focus=3318
> >>>>
> >>>>
>
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] simulation coding vs conversion coding

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

On 3/11/14 1:59 AM, Marcel Hellwig wrote:
> Hi Lars,
>> one=[Signal(intbv(0)[2:]) for k in range(2)]
> do this instead:
>
>> one, two = [Signal(intbv(0)[2:]) for k in range(2)]
>
> it should avoid your problem.
>

I believe Lars is trying to use a list of signals, the
above won't work.  You can use list of signals to model
memory or other logical structures.

http://www.myhdl.org/doc/current/manual/conversion_examples.html?highlight=list%20signals#ram-inference

What was posted is the correct approach to bit slice
into the individual intbv in the list.

     one[n].next[b] = in
         |       |
         |       +- intbv bit index
         +--------- list index

Regards,
Chris

Re: [myhdl-list] simulation coding vs conversion coding

[Marcel H. <1he...@in...>]

Hi Lars,
> one=[Signal(intbv(0)[2:]) for k in range(2)]
do this instead:

> one, two = [Signal(intbv(0)[2:]) for k in range(2)]

it should avoid your problem.

Greetings

Re: [myhdl-list] simulation coding vs conversion coding

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

On 3/8/14 3:58 AM, L...@rs... wrote:
> Hi,
>
> when using list of signals with signal slicing, I need to change
> coding between simulation and conversion.
> Please see the comment in def ab(in1,out1). Has this already been
> discussed somewhere?

Which version of MyHDL are you using?  I have not run
into this but I don't think I have used the same as
you outlined.

Regards,
Chris

[myhdl-list] simulation coding vs conversion coding

[<L...@rs...>]

Hi,

when using list of signals with signal slicing, I need to change  
coding between simulation and conversion.
Please see the comment in def ab(in1,out1). Has this already been  
discussed somewhere?

Regards
Lars

from myhdl import *
def ab(in1,out1):
     one=[Signal(intbv(0)[2:]) for k in range(2)]
     @always_comb
     def comb1():
         one[0].next[0]=in1 #conv_run requires: one[0][0].next=in1
     @always_comb
     def comb2():
         out1.next=one[0][0]
     return instances()

def sim_dut():
     in1,out1=[Signal(intbv(0)[2:]) for k in range(2)]
     dut=ab(in1,out1)
     @instance
     def stimulus():
         for k in range(2):
             in1.next=k
             yield delay(5)
             print out1
         raise StopSimulation
     return instances()
def sim_run():
     tb_inst=sim_dut()
     sim=Simulation(tb_inst)
     sim.run()
def conv_run():
     in1,out1=[Signal(intbv(0)[2:]) for k in range(2)]
     dd=toVHDL(ab,in1,out1)

Re: [myhdl-list] MEP 107 need for portmap

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

On 2/23/2014 6:03 PM, Keerthan jai.c wrote:
> Are you proposing that toV* can now be called in two ways, the usual way
> which is overriden if a function has  a portmap attribute?
>

Yes,

     # no portmap (current usage)
     toV*(m_top_level, <explicit list of ports>)

     # using portmat
     m_top_level.portmap = portmap
     toV*(m_top_level)

Both cases, after the call to toV* vportmap will
be filled in.

     pprint(m_top_level.vportmap)

Regards,
Chris

>
> On Thu, Feb 20, 2014 at 12:02 PM, Christopher Felton <chr...@gm...
>> wrote:
>
>> On 2/15/2014 3:43 PM, Keerthan jai.c wrote:
>>> I'm not sure which approach is more pythonic in this scenario. However,
>>> currently the only interface to the conversion functions are through toV*
>>> attributes. I think it is more 'consistent' to use toVerilog.portmap,
>>> unless we make the other parameters(such as toVerilog.name) exposed
>> through
>>> top level function attributes too.
>>>
>>
>> I appreciate that the /portmap/ tied to the toV*
>> functions matches (closer) to the current approach
>> to configure the conversions process.
>>
>> But given some of the other conversations I think
>> having a /portmap/ and /vportmap/ tied to the module
>> (top-level function) is useful and worth discussion.
>>
>> If we tie it to the top-level function it gives us
>> two ways - not two ways to do the same thing but two
>> ways to solve different problems.
>>
>> Per the other discussion - if you want conversion
>> time top-level port modifications that are parameterizable
>> for the system you are building.  The ability to do the
>> following, could be useful:
>>
>>       portmap = dict(<list of ports>)
>>       dut = m_top(**portmap)
>>       m_top.portmap = portmap
>>       toV*(m_top)
>>       #  the function portmap attribut is used to
>>       #  define the top-level ports and what they are
>>       #  instead of the compile time args to the func
>>       #  and the passed signals.
>>
>> I think the above is a use case worth considering.
>>
>> I also like the /portmap/ on the top-level function
>> because as designer I can create a default portmap,
>> often a top-level is for a specific hardware, as
>> the module designer I can define the default portmap
>> (shortcut for any user).  I like this because if I
>> have multiple tests, conversion scripts, etc I don't
>> have to recreate the port definitions in each or
>> define the port signals somewhere else (detached).
>>
>> Regards,
>> Chris
>>
>>
>>>
>>> On Fri, Feb 14, 2014 at 8:50 AM, Christopher Felton
>>> <chr...@gm...>wrote:
>>>
>>>> Previously, we had a short discussion that the MEP107
>>>> interface conversion for top-levels (e.g modules being
>>>> converted) introduced a need for a generated /portmap/ [1].
>>>>
>>>> The main uses case, given a module:
>>>>
>>>>        def m_some_mod(ifc1, ifc2):
>>>>            # ...
>>>>
>>>> If I am verifying the above module via co-simulation,
>>>> without a /portmap/ I would need to manually write a
>>>> wrapper or manually breakout all the interface /Signals/
>>>> when building the /Cosimulation/, example:
>>>>
>>>>        Cosimualation(simcmd, ifc1_di=ifc1.di, ifc1_do=ifc1.do ...
>>>>
>>>> In this case it defeats the purpose of the interfaces.
>>>> To address this complication Keerthan proposed a /portmap/
>>>> be generated in the conversion functions, the above would
>>>> then become:
>>>>
>>>>        Cosimulation(simcmd, **portmap)
>>>>
>>>> Ahhh, much better :)
>>>>
>>>> The /toV*/ functions already return a list generators in
>>>> the module.  The /portmap/ can't be returned from the
>>>> /toV*/ functions without breaking backwards compatibility.
>>>>
>>>> The current proposal is to attach a function attribute to the
>>>> /toV*/ functions, e.g:
>>>>
>>>>        toVerilog.portmap
>>>>
>>>> The /toV*.portmap/ would be the dictionary of the converted
>>>> portmap (interface expanded names).
>>>>
>>>> I would like to propose and discuss attaching the /portmap/
>>>> attribute to the function being converted and not the
>>>> conversion functions.  To me this is a more natural (I don't
>>>> know if this is generally pythonic (accepted) to have other
>>>> functions modify and/or add attributes to other functions).
>>>>
>>>> In addition, I would propose that generated portmap saved
>>>> in the /vportmap/ attribute and the /portmap/ attribute
>>>> to be used as a user defined default port definition.
>>>>
>>>> Keerthan has done an amazing job implementing MEP-107, many
>>>> thanks!  He has also created a pull-request for the
>>>> /toVerilog.portmap/, I wanted to have a short discussion
>>>> and make sure this is the most flexible path moving forward.
>>>> Once we finalize the portmap I can update the MEP.
>>>>
>>>> Regards,
>>>> Chris
>>>>
>>>> [1] http://thread.gmane.org/gmane.comp.python.myhdl/3223/focus=3318
>>>>
>>>>

Re: [myhdl-list] MEP 107 need for portmap

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

Are you proposing that toV* can now be called in two ways, the usual way
which is overriden if a function has  a portmap attribute?


On Thu, Feb 20, 2014 at 12:02 PM, Christopher Felton <chr...@gm...
> wrote:

> On 2/15/2014 3:43 PM, Keerthan jai.c wrote:
> > I'm not sure which approach is more pythonic in this scenario. However,
> > currently the only interface to the conversion functions are through toV*
> > attributes. I think it is more 'consistent' to use toVerilog.portmap,
> > unless we make the other parameters(such as toVerilog.name) exposed
> through
> > top level function attributes too.
> >
>
> I appreciate that the /portmap/ tied to the toV*
> functions matches (closer) to the current approach
> to configure the conversions process.
>
> But given some of the other conversations I think
> having a /portmap/ and /vportmap/ tied to the module
> (top-level function) is useful and worth discussion.
>
> If we tie it to the top-level function it gives us
> two ways - not two ways to do the same thing but two
> ways to solve different problems.
>
> Per the other discussion - if you want conversion
> time top-level port modifications that are parameterizable
> for the system you are building.  The ability to do the
> following, could be useful:
>
>      portmap = dict(<list of ports>)
>      dut = m_top(**portmap)
>      m_top.portmap = portmap
>      toV*(m_top)
>      #  the function portmap attribut is used to
>      #  define the top-level ports and what they are
>      #  instead of the compile time args to the func
>      #  and the passed signals.
>
> I think the above is a use case worth considering.
>
> I also like the /portmap/ on the top-level function
> because as designer I can create a default portmap,
> often a top-level is for a specific hardware, as
> the module designer I can define the default portmap
> (shortcut for any user).  I like this because if I
> have multiple tests, conversion scripts, etc I don't
> have to recreate the port definitions in each or
> define the port signals somewhere else (detached).
>
> Regards,
> Chris
>
>
> >
> > On Fri, Feb 14, 2014 at 8:50 AM, Christopher Felton
> > <chr...@gm...>wrote:
> >
> >> Previously, we had a short discussion that the MEP107
> >> interface conversion for top-levels (e.g modules being
> >> converted) introduced a need for a generated /portmap/ [1].
> >>
> >> The main uses case, given a module:
> >>
> >>       def m_some_mod(ifc1, ifc2):
> >>           # ...
> >>
> >> If I am verifying the above module via co-simulation,
> >> without a /portmap/ I would need to manually write a
> >> wrapper or manually breakout all the interface /Signals/
> >> when building the /Cosimulation/, example:
> >>
> >>       Cosimualation(simcmd, ifc1_di=ifc1.di, ifc1_do=ifc1.do ...
> >>
> >> In this case it defeats the purpose of the interfaces.
> >> To address this complication Keerthan proposed a /portmap/
> >> be generated in the conversion functions, the above would
> >> then become:
> >>
> >>       Cosimulation(simcmd, **portmap)
> >>
> >> Ahhh, much better :)
> >>
> >> The /toV*/ functions already return a list generators in
> >> the module.  The /portmap/ can't be returned from the
> >> /toV*/ functions without breaking backwards compatibility.
> >>
> >> The current proposal is to attach a function attribute to the
> >> /toV*/ functions, e.g:
> >>
> >>       toVerilog.portmap
> >>
> >> The /toV*.portmap/ would be the dictionary of the converted
> >> portmap (interface expanded names).
> >>
> >> I would like to propose and discuss attaching the /portmap/
> >> attribute to the function being converted and not the
> >> conversion functions.  To me this is a more natural (I don't
> >> know if this is generally pythonic (accepted) to have other
> >> functions modify and/or add attributes to other functions).
> >>
> >> In addition, I would propose that generated portmap saved
> >> in the /vportmap/ attribute and the /portmap/ attribute
> >> to be used as a user defined default port definition.
> >>
> >> Keerthan has done an amazing job implementing MEP-107, many
> >> thanks!  He has also created a pull-request for the
> >> /toVerilog.portmap/, I wanted to have a short discussion
> >> and make sure this is the most flexible path moving forward.
> >> Once we finalize the portmap I can update the MEP.
> >>
> >> Regards,
> >> Chris
> >>
> >> [1] http://thread.gmane.org/gmane.comp.python.myhdl/3223/focus=3318
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Android apps run on BlackBerry 10
> >> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> >> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> >> Get your Android app in front of a whole new audience.  Start now.
> >>
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> myhdl-list mailing list
> >> myh...@li...
> >> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >>
> >
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Android apps run on BlackBerry 10
> > Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> > Now with support for Jelly Bean, Bluetooth, Mapview and more.
> > Get your Android app in front of a whole new audience.  Start now.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&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] MEP 107 need for portmap

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

On 2/15/2014 3:43 PM, Keerthan jai.c wrote:
> I'm not sure which approach is more pythonic in this scenario. However,
> currently the only interface to the conversion functions are through toV*
> attributes. I think it is more 'consistent' to use toVerilog.portmap,
> unless we make the other parameters(such as toVerilog.name) exposed through
> top level function attributes too.
>

I appreciate that the /portmap/ tied to the toV*
functions matches (closer) to the current approach
to configure the conversions process.

But given some of the other conversations I think
having a /portmap/ and /vportmap/ tied to the module
(top-level function) is useful and worth discussion.

If we tie it to the top-level function it gives us
two ways - not two ways to do the same thing but two
ways to solve different problems.

Per the other discussion - if you want conversion
time top-level port modifications that are parameterizable
for the system you are building.  The ability to do the
following, could be useful:

     portmap = dict(<list of ports>)
     dut = m_top(**portmap)
     m_top.portmap = portmap
     toV*(m_top)
     #  the function portmap attribut is used to
     #  define the top-level ports and what they are
     #  instead of the compile time args to the func
     #  and the passed signals.

I think the above is a use case worth considering.

I also like the /portmap/ on the top-level function
because as designer I can create a default portmap,
often a top-level is for a specific hardware, as
the module designer I can define the default portmap
(shortcut for any user).  I like this because if I
have multiple tests, conversion scripts, etc I don't
have to recreate the port definitions in each or
define the port signals somewhere else (detached).

Regards,
Chris


>
> On Fri, Feb 14, 2014 at 8:50 AM, Christopher Felton
> <chr...@gm...>wrote:
>
>> Previously, we had a short discussion that the MEP107
>> interface conversion for top-levels (e.g modules being
>> converted) introduced a need for a generated /portmap/ [1].
>>
>> The main uses case, given a module:
>>
>>       def m_some_mod(ifc1, ifc2):
>>           # ...
>>
>> If I am verifying the above module via co-simulation,
>> without a /portmap/ I would need to manually write a
>> wrapper or manually breakout all the interface /Signals/
>> when building the /Cosimulation/, example:
>>
>>       Cosimualation(simcmd, ifc1_di=ifc1.di, ifc1_do=ifc1.do ...
>>
>> In this case it defeats the purpose of the interfaces.
>> To address this complication Keerthan proposed a /portmap/
>> be generated in the conversion functions, the above would
>> then become:
>>
>>       Cosimulation(simcmd, **portmap)
>>
>> Ahhh, much better :)
>>
>> The /toV*/ functions already return a list generators in
>> the module.  The /portmap/ can't be returned from the
>> /toV*/ functions without breaking backwards compatibility.
>>
>> The current proposal is to attach a function attribute to the
>> /toV*/ functions, e.g:
>>
>>       toVerilog.portmap
>>
>> The /toV*.portmap/ would be the dictionary of the converted
>> portmap (interface expanded names).
>>
>> I would like to propose and discuss attaching the /portmap/
>> attribute to the function being converted and not the
>> conversion functions.  To me this is a more natural (I don't
>> know if this is generally pythonic (accepted) to have other
>> functions modify and/or add attributes to other functions).
>>
>> In addition, I would propose that generated portmap saved
>> in the /vportmap/ attribute and the /portmap/ attribute
>> to be used as a user defined default port definition.
>>
>> Keerthan has done an amazing job implementing MEP-107, many
>> thanks!  He has also created a pull-request for the
>> /toVerilog.portmap/, I wanted to have a short discussion
>> and make sure this is the most flexible path moving forward.
>> Once we finalize the portmap I can update the MEP.
>>
>> Regards,
>> Chris
>>
>> [1] http://thread.gmane.org/gmane.comp.python.myhdl/3223/focus=3318
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience.  Start now.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] HDL essays

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

On 2/20/2014 9:28 AM, Jan Decaluwe wrote:
<snip>
>
> I have added social buttons for twitter and reddit
> though, so feel free to use those. I was thinking
> external discussion on reddit would be a good
> alternative. But perhaps not.

I am always torn on reddit - since majority of the
participants are anonymous, they are emboldened to
speak their mind.  This is good and bad :)

The only way to push trolls into the noise is to
have a large crowd participating.  If you don't
have that, a single troll can wreak havoc.

I think in this case the non-reddit conversations
are better.

Regards,
Chris

Re: [myhdl-list] HDL essays

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

On 02/20/2014 12:17 PM, Euripedes Rocha Filho wrote:
> disqus++(or any other way for discussion).

Ok, diqus has been set up.

> What I liked most  about
> the APP site was the discussion after the posts.

I didn't :-)

  And Jan Decaluwe,
> it's always a pleasure to read your essays, thank you.

Thanks.

-- 
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] HDL essays

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

On 02/20/2014 11:52 AM, Keerthan jai.c wrote:
> Resending since I accidentally replied to JanD instead of the group,
> sorry about that.
>
> Wow, it sucks that they ended APP so abruptly. I don't imagine that
> it cost them too much, considering that most of the posts were from
> volunteers.

Clearly Xilinx didn't see the return for them, which I can
understand. But closing down without an archive is
simply not done.

> What do you think about integrating disqus, to have discussions on
> your essays?

I was rather reluctant: on APP my experience was not
good. I often felt that the comment section to my articles
was dominated by plain idiots and even people with doubtful
intentions. My problem is that I take every comment seriously
and I start by assuming intelligence and good intentions.

I also think weak comments can somehow reflect badly
on the content itself.

I have added social buttons for twitter and reddit
though, so feel free to use those. I was thinking
external discussion on reddit would be a good
alternative. But perhaps not.

Having said that all this, on a site like Sigasi my
experience has been different. Probably when a site
is more specific people are more motivated and to
the point and the quality is higher.

So ok, let's give it a try. I have set up disqus comments
for my essays and blog.

-- 
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] HDL essays ...ZPU

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

On 20/02/14 11:57, Christopher Felton wrote:
> A weekend project I never finished (long time ago :)
> http://myhdl.org/doku.php/users:cfelton:projects:zpu
Thanks, now I have something to grade my work by!:-)  Sorry, but 
can't remember if I'd seen your ZPU page before, or not.   I might 
yet regret starting on the ZPU last weekend:

I was thinking of combining the slow and fast models, with small 
stack cache & big external memory interface.  By adding a two stage 
instruction decode pipeline it should be possible to consume the 
serial in-line constants faster.  Then, duplicating this cache 
could reduce/remove stalls caused by branch instructions.

However, adding a stack cache might get it so close to one 
instruction per clock cycle that the instruction pipeline will 
never get a chance to run ahead and do it's work.

(I replying, perhaps switch to private email/start new thread?)
> Regards,
> Chris
>
> p.s. how do I down grade my thunderbird, everything is
> broken!
I just made mine promise to send everything in plain text, but time 
will tell...  If it won't then I might be tempted to switch to 
something very simple.  I like the idea of one file per email, as 
this would significantly reduce my PC incremental backup size, but 
the only email tool I've found that does this is really ancient.

Jan Coombs
--

Re: [myhdl-list] myhdl.org website migration

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

On 2/16/14 11:29 AM, Jan Decaluwe wrote:
> On 02/14/2014 02:47 PM, Christopher Felton wrote:
>
>> Couple (minor) comments on the new site.
>>
>> Is there a way to easily link back to the site from
>> the manual?  I found it a little frustrating jumping
>> to the manual and back to the site.
>
> The manual link is to the manual generated with readthedocs.org,
> which looks like a convenient automatic method for the future.
>
> Anyone knows how include return links in readthedocs
> manuals?
>
>> I realize the menu system has the links to get started,
>> etc.  But I think having some more content on the landing
>> page would be beneficial for new visitors, etc.  I can
>> create a pull-request with some ideas.
>
> I suggest to discuss this first. I want to learn from
> good examples (bootstrap) and keep the landing page
> as "to the point" and short as possible.

I haven't fully caught up on this thread yet but I
like the changes/additions.

>
> Now we have the name and a tagline. I see the value
> of adding a one or two liner description, and perhaps
> the latest "News" item.
>
>> Also, my contribution plan to the new site is adding
>> examples.  In the past I experimented with adding the
>> examples to the manual and using doctest to verify the
>> examples when a new version of the manual was created.
>> I think this would be good as release tests (that is
>> verifying the examples on the site still work).  Now,
>> that the new website is in a repository, I propose we
>> add a little (as little as possible) formality to the
>> examples so we can leverage this code collection for
>> release testing, e.g. all examples should have:
>>
>>        1. description write up
>>        2. .py file with working example
>>        3. test for the example
>>
>> In addition, there are ways to embedded the code from
>> bitbucket in the example write-up, the write-up can
>> always have the latest code (easy to maintain the examples),
>> thoughts?
>
> Mm, I don't think we want to do repo accesses over the
> net on every build. Of course, you could add a script
> to pull the sources automatically on demand.

I guess I was thinking a build would not pull from the
web but rather as part of the release process you run
all the tests in the site-myhdl/examples (a repo you
have locally).

My thought, is that maybe we structure the examples
directory in the repo so that -possibly- it can be used
as a collection of test code.  From my perspective this
allows us to leverage a code base and a process to evaluate
quality of examples.  My thought is the example directory
would be organized as:

     site-myhdl/examples/
        example1/
            example1.md      # the write-up
            example1.py      # the full example in a python
            test_example1.py # a test for the example

If we encourage a structure like this we can simply test all
the examples.  And it would be neat to automatically give each
example a "badge" for each version of myhdl - but that is
neither here nor there.

This isn't something that has to happens right away but if
we set the precedence that an example needs a working .py
and a test then the rest can be added as time permits.

Regards,
Chris

Re: [myhdl-list] HDL essays

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

On 2/20/14 4:48 AM, Jan Coombs wrote:

<snip>

> Because, although the MyHDL site is very complete, and
> comprehensive,  I find that it is often too terse, or
> insufficiently repetitive to allow me to grasp and re-use material
> quickly.

We might be able to address this by adding more
examples.  With the "new" site, writing examples
and descriptions for the examples in markdown.

>
> I very much appreciate all the work and creative thinking that has
> generated this excellent tool.  I say this just after having had
> old VHDL memories re-kindled by translating another tiny processor
> design to MyHDL.   (http://opencores.org/project,zpu)

A weekend project I never finished (long time ago :)
http://myhdl.org/doku.php/users:cfelton:projects:zpu

Regards,
Chris

p.s. how do I down grade my thunderbird, everything is
broken!

Re: [myhdl-list] HDL essays

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

disqus++(or any other way for discussion). What I liked most  about the APP
site was the discussion after the posts. And Jan Decaluwe, it's always a
pleasure to read your essays, thank you.

Euripedes


2014-02-20 7:52 GMT-03:00 Keerthan jai.c <jck...@gm...>:

> Resending since I accidentally replied to JanD instead of the group, sorry
> about that.
>
> Wow, it sucks that they ended APP so abruptly. I don't imagine that it
> cost them too much, considering that most of the posts were from volunteers.
>
> What do you think about integrating disqus, to have discussions on your
> essays?
> On Feb 20, 2014 3:36 AM, "Jan Decaluwe" <ja...@ja...> wrote:
>
>> Last year I wrote a number of blog posts for APP
>> (All Programmable Planet).
>>
>> At some point, Xilinx (the sponsor) and UBM (the publisher)
>> decided to pull the plug an APP. Just like that, without
>> an archive. I have blogged about my anger about this here:
>>
>>
>> http://www.jandecaluwe.com/blog/a-wish-for-free-content-and-open-source.html
>>
>> The good part is that I have material to republish,
>> and I have started to do so as essays on my own site.
>>
>> I have just published an essay that I particularly like:
>>
>> http://www.jandecaluwe.com/hdldesign/signal-assignments.html
>>
>> It investigates the real reason for signal assignments,
>> and uses the MyHDL model to illustrate the concepts.
>>
>> --
>> 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
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>

Re: [myhdl-list] HDL essays

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

Resending since I accidentally replied to JanD instead of the group, sorry
about that.

Wow, it sucks that they ended APP so abruptly. I don't imagine that it cost
them too much, considering that most of the posts were from volunteers.

What do you think about integrating disqus, to have discussions on your
essays?
On Feb 20, 2014 3:36 AM, "Jan Decaluwe" <ja...@ja...> wrote:

> Last year I wrote a number of blog posts for APP
> (All Programmable Planet).
>
> At some point, Xilinx (the sponsor) and UBM (the publisher)
> decided to pull the plug an APP. Just like that, without
> an archive. I have blogged about my anger about this here:
>
>
> http://www.jandecaluwe.com/blog/a-wish-for-free-content-and-open-source.html
>
> The good part is that I have material to republish,
> and I have started to do so as essays on my own site.
>
> I have just published an essay that I particularly like:
>
> http://www.jandecaluwe.com/hdldesign/signal-assignments.html
>
> It investigates the real reason for signal assignments,
> and uses the MyHDL model to illustrate the concepts.
>
> --
> 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
>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] HDL essays

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

On 20/02/14 08:36, Jan Decaluwe wrote:

>
> I have just published an essay that I particularly like:
>
> http://www.jandecaluwe.com/hdldesign/signal-assignments.html
Thanks, was well worth re-reading, and looks much better in tidy 
formal surroundings.

But, for me, this seems to be what they call 'a forward-looking 
statement':

" If you would like to get started now, go to the MyHDL website 
<http://www.myhdl.org> where you will find a manual, examples, 
tutorials, and installation instructions that will allow you to 
quickly get up to speed."

Because, although the MyHDL site is very complete, and 
comprehensive,  I find that it is often too terse, or 
insufficiently repetitive to allow me to grasp and re-use material 
quickly.

I very much appreciate all the work and creative thinking that has 
generated this excellent tool.  I say this just after having had 
old VHDL memories re-kindled by translating another tiny processor 
design to MyHDL.   (http://opencores.org/project,zpu)

Jan Coombs

Re: [myhdl-list] HDL essays

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

On 20/02/14 08:36, Jan Decaluwe wrote:

>
> I have just published an essay that I particularly like:
>
> http://www.jandecaluwe.com/hdldesign/signal-assignments.html
Thanks, was well worth re-reading, and looks much better in tidy 
formal surroundings.

But, for me, this seems to be what they call 'a forward-looking 
statement':

" If you would like to get started now, go to the MyHDL website 
<http://www.myhdl.org> where you will find a manual, examples, 
tutorials, and installation instructions that will allow you to 
quickly get up to speed."

Because, although the MyHDL site is very complete, and 
comprehensive,  I find that it is often too terse, or 
insufficiently repetitive to allow me to grasp and re-use material 
quickly.

I very much appreciate all the work and creative thinking that has 
generated this excellent tool.  I say this just after having had 
old VHDL memories re-kindled by translating another tiny processor 
design to MyHDL.   (http://opencores.org/project,zpu)

Jan Coombs

[myhdl-list] HDL essays

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

Last year I wrote a number of blog posts for APP
(All Programmable Planet).

At some point, Xilinx (the sponsor) and UBM (the publisher)
decided to pull the plug an APP. Just like that, without
an archive. I have blogged about my anger about this here:

http://www.jandecaluwe.com/blog/a-wish-for-free-content-and-open-source.html

The good part is that I have material to republish,
and I have started to do so as essays on my own site.

I have just published an essay that I particularly like:

http://www.jandecaluwe.com/hdldesign/signal-assignments.html

It investigates the real reason for signal assignments,
and uses the MyHDL model to illustrate the concepts.

-- 
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] myhdl.org website migration

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

On Tue, Feb 18, 2014 at 12:22 PM, Jan Decaluwe <ja...@ja...> wrote:
> On 02/17/2014 08:37 PM, Angel Ezquerra wrote:
>
>> I think I miss some kind graphical element like in the bootstrap page
>> to give the landing page a bit more "oomph".
>
> Added some icons from font-awesome - idea borrowed from bootswatch.

This looks really nice! :-)

Angel