myhdl-list

[myhdl-list] Clump'n and Lump'n

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

Hmmm, browsing the internet (instead of being focused and disciplined) I 
ran across this article

http://www1.cse.wustl.edu/~jain/cse567-08/ftp/fpgaprog/index.html#_Toc215239805 
.

The interesting point that caught my attention, was that MyHDL was 
clumped together with the C-based tools.  The author categorized MyHDL 
with ImpulseC, HandelC, SystemC, and JHDL.  The author dubbed these 
languages "Adapted Sequential HDL Programming Languages" (ASPL).  The 
goal of the study was to measure ASPLs against THDL (traditional HDLs 
i.e. Verilog/VHDL).  But I don't see any results for the proposed 
experiments.

Then the author proposes a method to measure the languages effectiveness 
based on :
   1. Language Acquisition [LA](time to learn the language, given??)
   2. Programming Efficiency [PE] (time to implement and debug design)
   3. Operational Efficiency [OE] (resources used)
(see the link for more information on the metrics)

These are tricky and somewhat subjective metrics (as the author states).

Anyone else have experience with the C/java based HDL languages?  How 
was the experience vs. MyHDL?

On a scale 1-3, 1 being highest/best how would you rate the metrics 
outlined in the paper? (The metrics are mainly time and resources, a 
lower value in time and resources are better, hence 1 being highest, 
lowest score wins!).

          MyHDL | JHDL | Verilog | VHDL | ImpC | HanC | SystemC | SV
1. LA
2. PE
3. OE


.chris

Re: [myhdl-list] Clump'n and Lump'n

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

<snip>
>
> On a scale 1-3, 1 being highest/best how would you rate the metrics
> outlined in the paper? (The metrics are mainly time and resources, a
> lower value in time and resources are better, hence 1 being best).
>

            MyHDL | JHDL | Verilog | VHDL | ImpC | HanC | SystemC | SV
1. LA        1      n/a      2        3     n/a    n/a     7        3
2. PE        1      n/a      2        2     n/a    n/a     3        3
3. OE        2      n/a      2        2     n/a    n/a     3        2


Note : I can't declare the same level of competence in SystemC and SV as 
the others.

.chris

Re: [myhdl-list] Clump'n and Lump'n

[Uri N. <ur...@gm...>]

Hi,

In my experience SystemC+Boost is functionally equivalent to MyHDL for
system modelling, although the LA and PE for Python is an order of magnitude
easier.
Another significant advantage of Python is its cross platform portability
(Windows, Unix, Linux, etc), which saves the hassle of deployment and
managing different build chains.

Cheers,
Uri

On 31 May 2011 19:54, Christopher Felton <chr...@gm...> wrote:

> <snip>
> >
> > On a scale 1-3, 1 being highest/best how would you rate the metrics
> > outlined in the paper? (The metrics are mainly time and resources, a
> > lower value in time and resources are better, hence 1 being best).
> >
>
>            MyHDL | JHDL | Verilog | VHDL | ImpC | HanC | SystemC | SV
> 1. LA        1      n/a      2        3     n/a    n/a     7        3
> 2. PE        1      n/a      2        2     n/a    n/a     3        3
> 3. OE        2      n/a      2        2     n/a    n/a     3        2
>
>
> Note : I can't declare the same level of competence in SystemC and SV as
> the others.
>
> .chris
>
>
>
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Clump'n and Lump'n

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

On 6/2/2011 1:41 PM, Uri Nix wrote:
> Hi,
>
> In my experience SystemC+Boost is functionally equivalent to MyHDL for
> system modelling, although the LA and PE for Python is an order of magnitude
> easier.
> Another significant advantage of Python is its cross platform portability
> (Windows, Unix, Linux, etc), which saves the hassle of deployment and
> managing different build chains.
>
> Cheers,
> Uri

Yes, I agree!  Using the numerical packages in Python is much easier. 
To your point I can open a Python shell and do the following:
 >> from numpy import *
 >> X = random.rand(3,3)
 >> matrix(X) * matrix(X[1,:]).transpose()
 >>
matrix([[ 0.53398746],
         [ 0.96773496],
         [ 1.01327792]])

#... expand to myhdl ...
 >> sX = Signal(matrix(X))
 >> sY = Signal(matrix(X[1,:].transpose())
 >> sX.next = sX * sY
#...

And easily incorporate into my design without much issue (the above is 
way too simple of an example).  I can quite easily do complicated system 
modeling; mixing cycle and bit-accurate if needed.

It has been awhile since I used SystemC (over 5 years?).  I remember it 
being difficult (relative) and I am a pretty proficient C/C++ 
programmer.  But it could have been that I gave up on SystemC when I 
started using MyHDL more :)

Then I can create all my plots for analysis right in my simulation, I 
don't have to post-process simulation results.

The only argument might be simulation speed.  But I am usually done with 
my development and simulations and onto the next item, before I would 
have completed a C* implementation, making the simulation speeds a moot 
point.

I have also found interface MyHDL with simulators to be easier than 
SystemC.  I guess it is the Python *batteries-included*!

Chris

Re: [myhdl-list] Clump'n and Lump'n

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

>
> Yes, I agree!  Using the numerical packages in Python is much easier.
> To your point I can open a Python shell and do the following:
>   >>  from numpy import *
>   >>  X = random.rand(3,3)
>   >>  matrix(X) * matrix(X[1,:]).transpose()
>   >>
> matrix([[ 0.53398746],
>           [ 0.96773496],
>           [ 1.01327792]])
>
> #... expand to myhdl ...
>   >>  sX = Signal(matrix(X))
>   >>  sY = Signal(matrix(X[1,:].transpose())
>   >>  sX.next = sX * sY
> #...
>

Doh,  awhile ago I posted the above incorrect example.  I had done 
something similar to the above in the past and forgot I added a small 
wrapper to work with numpy arrays.  The above does not function out of 
the box, when the update function is called it will fail when trying to 
determine if the current != next for numpy arrays.

Below is the wrapper I used.

#-------------------------------------------------------------------------------
# BlockSignal :
#-------------------------------------------------------------------------------
class BlockSignal(SignalType):

     __slots__ = ("parent",) + SignalType.__slots__

     def __init__(self, val=None):

         # @todo check type, always should be an ndarray type!
         self.parent = None

         # Call the myhdl.Signal constructor
         SignalType.__init__(self, val)

         # For the DSP simulations / executions going to make a copy
         # of the numpy.ndarray.  The update functions will just swap
         # buffers instead of copying (copy was actually done in the next
         # assign).
         self._next = copy(self._val)

     def _update(self):
         # @todo check no waiters (self._eventWaiters) should be
         #       no waiters on these signals.  Too expensive to check
         #       the arrays for value changes.
         waiters = self._eventWaiters[:]

         # Swap the buffers (numpy.ndarray) so that the consumers have
         # the latest samples and the producers have a new buffer to
         # fill.
         tmp        = self._val
         self._val  = self._next
         self._next = self._val

         return []

     def _update_type(self, val):
         self._val  = val
         self._next = copy(self._val)


Regards,
Chris Felton