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

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

On 9/16/2011 11:17 AM, Shakthi Kannan wrote:
> Hi Christopher:
>
> --- On Fri, Sep 16, 2011 at 8:19 PM, Christopher Felton
> <chr...@gm...>  wrote:
> | 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.
> \--
>
> :) There will be quite a few students in the audience, and I don't
> want them to ponder on the logic as to how it works. Hence, the
> explicit walk through. Others can just skip through that part.

Sure, it is ok.  But, my opinion, you only need to show 0+0=0 once, and 
you can jump ahead.  But no foul no harm.

>
> The manual is well documented, so I didn't want to repeat the same in
> the presentation. Moreover, the focus is on how Python and
> python-myhdl is useful for HDL. Hence, just the code examples and
> illustrations.

This feeds an argument against the explicit logic walk through because, 
as you said, the focus is Python and Python-MyHDL, IMO.

>
> ---
> | 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
> \--
>
> For "a = intbv(-12, min=0, max=16)", how can we set value to -12, when
> minimum is 0? Same with "b = intbv(-12, min=16, max=16)". These return
> a ValueError.
>
> Can you elaborate on what you would like to emphasize here?

That is the point, a negative value assigned to an unsigned causes a 
value error (you won't see this in Verilog).  You need the correct 
bounds to represent a number.  Failing examples are as useful as correct 
examples.

>
> ---
> | 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 :) --.
> \--
>
> True :)
>
> ---
> | 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.
> \--
>
> I have now explicitly mentioned "High Level Modelling" for the sparse
> memory and fifo examples at:
>
>    http://www.myhdl.org/doc/current/manual/modeling.html#high-level-modeling

Cool, I think that works, stating the different types of modeling, 
Structural, RTL, and HL.

>
> ---
> | 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
> \--
>
> Yes, I have demos for the examples, and will use them during the presentation.

That isn't what I was thinking.  I was thinking a slide that summarizes 
up to the point (just before the pypy) will be a better transition to 
the pypy information.  Summarizing the design flow is one possibility.

>
> ---
> | Using PyPy
> | -----------
> | Since these tables are directly from Jan's wikipage I would add the
> | reference to this slide.
> \--
>
> Updated.
>
> ---
> | 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.
> |
> | Or you could normalize to pypy and see
> | how the others compare.
> |
> | I guess, normalizing to pypy is the most dramatic and gets the
> | information across the fastest, IMO.
> \--
>
> Updated. Thanks for your feedback!
>
> SK
>

No problem, have fun.

Chris Felton