Re: [myhdl-list] From Python to Silicon: python-myhdl presentation

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

On 9/15/2011 12:49 PM, Shakthi Kannan wrote:
> Greetings!
>
> I will be presenting python-myhdl at PyCon India 2011 [1]. Thanks to
> Jan Decaluwe for his review, and code examples. The presentation is
> available under CC BY-SA 3.0 [2].
>
> The LaTeX Beamer sources of the presentation are available at gitorious.org [3].
>
> I'd appreciate any feedback/suggestions regarding the presentation.
>
> Thanks!
>
> SK
>
> [1] PyCon India 2011. http://in.pycon.org/
>
> [2] From Python to Silicon: python-myhdl.
> http://shakthimaan.com/downloads/glv/2011/pycon-2011/from-python-to-silicon.pdf
>
> [3] Presentation git sources at gitorious.
> https://gitorious.org/from-python-to-silicon/
>
(Guess I did have some more feedback)

The number of slides dedicated to explaining Gray code is a little 
excessive.  After the truth table slide, you can probably jump to slide 
20 (think it is 20).  And then jump to the last slide of the Gray table. 
  Explicitly walking through XOR of 0s is ... kinda ... yawn.

Unsigned and Signed Representation
-----------------------------------
I would show a signed and unsigned representation before converting 
(extending) an unsigned to a signed.
a = intbv(12, min=0, max=16)   # Unsigned
a = intbv(-12, min=0, max=16)  # What happens if unsigned to set sign
b = intbv(-12, min=16, max=16) # Signed
# Then conversion to signed

Unit Tests
-----------
Emphasize, this is one of the reasons why Python HDL *rules*.  You 
inherit the world of Python and its ecosystem and you don't have to 
reinvent the world -- unless that is what you do and you can convince 
your customers to pay for it :) --.

Conditional Instantiation
--------------------------
This might be a good spot (if not already discussed) the idea of the 
elaboration phase.  And those familiar with HDLs how this replaces the 
generates.

* Modeling
-----------
I think "Modeling" has been used in two different context and it might 
be confusing.  MyHDL can be used for a bunch of different purposes, 
including: (1) Modeling complex event based systems, (2) advanced 
verification/testbenches, and (3) as a convertible (synthesizable) HDL. 
  In these slides "Modeling" refers to items 1 and 3.

You use "RTL Modeling" for the generators that can be converted and 
plain "Modeling" for those that do not convert.  I would make additional 
effort to make sure this is clear when presenting.

I guess this is the same for the "Structural Modeling", in the 
discussion make clear the "structural" and "RTL" are convertible and the 
other "modeling" is not.

Intermediate Summary (So far have learned)
------------------------------------------
Before the PyPy you might want a quick summary to this point.
   * Describe the HDL in Python/MyHDL
   * Simulate
   * Convert to Verilog or VHDL
   * Co-simulate to verify conversion correctness
   * Synthesize to target technology
   * Co-simulate with synthesized netlist

Using PyPy
-----------
Since these tables are directly from Jan's wikipage I would add the 
reference to this slide.  Indicate where the info was taken.  Also, it 
would be nice to see this table in a normalized percentage.  You could 
normalize to MyHDL@pypy or Normalize to one of the others, example.

MPyPy_Compare
Out[364]:
{'findmax': {'ghdl': 2256, 'iver': 56, 'pypy': 86,
              'ver1': 21, 'vhdl1': 37},
  'lfsr24': {'ghdl': 71, 'iver': 79, 'pypy': 66,
             'ver1': 266, 'vhdl1': 240},
  'logdiv': {'ghdl': 224, 'iver': 43, 'pypy': 69,
             'ver1': 96, 'vhdl1': 98},
  'randgen': {'ghdl': 24, 'iver': 197, 'pypy': 62,
              'ver1': 76, 'vhdl1': 67},
  'timer': {'ghdl': 146, 'iver': 106, 'pypy': 62,
            'ver1': 260, 'vhdl1': 219}}

for k,v in MPyPy_Compare.items():
     print("%8s : %1.2f | %1.2f | %1.2f | %1.2f | %1.2f" % (k,
           v['pypy']/float(v['iver']),
           v['iver']/float(v['iver']),
           v['ghdl']/float(v['iver']),
           v['ver1']/float(v['iver']),
           v['vhdl1']/float(v['iver']) )
)

    timer : 0.58 | 1.00 | 1.38  | 2.45 | 2.07
   lfsr24 : 0.84 | 1.00 | 0.90  | 3.37 | 3.04
  randgen : 0.31 | 1.00 | 0.12  | 0.39 | 0.34
   logdiv : 1.60 | 1.00 | 5.21  | 2.23 | 2.28
  findmax : 1.54 | 1.00 | 40.29 | 0.38 | 0.66

The above normalized to Icarus.  Or you could normalize to pypy and see 
how the others compare.

    timer : 1.00 | 1.71 | 2.35  | 4.19 | 3.53
   lfsr24 : 1.00 | 1.20 | 1.08  | 4.03 | 3.64
  randgen : 1.00 | 3.18 | 0.39  | 1.23 | 1.08
   logdiv : 1.00 | 0.62 | 3.25  | 1.39 | 1.42
  findmax : 1.00 | 0.65 | 26.23 | 0.24 | 0.43

I guess, normalizing to pypy is the most dramatic and gets the 
information across the fastest, IMO.

Regards,
Chris Felton