Re: [myhdl-list] A Reviewers Thoughts ...

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

On Sun, Jul 10, 2011 at 8:54 PM, Christopher Felton
<chr...@gm...> wrote:
> On 7/8/11 12:41 AM, Angel Ezquerra wrote:
>> On Fri, Jul 8, 2011 at 6:54 AM, Christopher Felton
>> <chr...@gm...>  wrote:
>>> I have stumbled upon this presentation a couple times;
>>>
>>> http://seti.berkeley.edu/sites/default/files/gordon_casper_myhdl_presentation.pdf.
>>>
>>> The last slide is interesting, it is the brief summary of the author's
>>> concluding strengths and weaknesses of MyHDL.
>>>
>>> Strengths
>>> -----------
>>>   * The power of Python
>>>     * Supporting Libraries
>>>     * Flexibility
>>>
>>>   * Fast accurate functional simulations
>>>
>>> Weaknesses
>>> ------------
>>>   * Flat Conversion
>>>
>>>   * Limited Datatypes
>>>
>>>   * Manual Process
>>>
>>>
>>> I am surprised to see the "Flat Conversion" protested frequently.  I
>>> have not found this to be a weakness of any kind.  Have others found
>>> this to be a weakness?
>>
>> Well, I am definitely not a power user of MyHDL, but I recently
>> attended a training course for Xilinx tools and one thing that we
>> learned is that it is possible to tell the synthesizer to "keep the
>> hierarchy" for a given (or all) module(s). Apparently this can lead to
>> more predictable synthesis. Also this makes sure that the module
>> interface signals are not lost during the synthesis/traslate/map
>> process, which makes it easier to add probes (e.g. a ChipScope) that
>> peek on those signals.
>>
>> Angel
>>
>
> Thanks for for the comments!  I am curious because this "item" seems to
> appear from time to time.  The following is my rebuttal to the case you
> mentioned.
>
> At least so far, the main argument is that minimal signal/variable/net
> obfuscation is desired for downstream debugging.  In other-words the
> Designers want to identify "things" from the original design entry in
> the targeted implementation (in a FPGA the synthesized-P&R circuit).  To
> me this is really a bigger question.  What is the most efficient
> verification (debug) method.
>
> I think others would agree, in MyHDL with all the power of Python,
> building a robust verification environment is reasonable.  This would
> minimize the requirement to do in system debugging.  The need to
> identify a net in a post P&R circuit to attach debug probes shouldn't be
> required (chip-scope or signal-tap).  Or at least, the in-circuit
> "probing", avoided because it is a more difficult method to debug.  Not
> because of net obfusction but because less is available at run time:
> less visibility, limited number of probes, can be harder to inject error
> scenarios, etc.
>
> In some cases (in my opinion they are rare) you may want to do in system
> debugging / verification.  In this scenario, it is usually because some
> interface is poorly defined and you need to see how it is acting.  But
> in my mind, this is something that is designed in (DFM approach) and not
> an after-thought.  Meaning that you don't realize you need to attach
> probes until it doesn't work and don't want to re-P&R.
>
> I guess, in my mind this isn't an issue of flat design versus a
> preserved hierarchy design.  But rather the difference between the best
> verification/debug approach
>
> Regards,
> Chris

Chris,

this is certainly a very good point, but even if rare, there are still
occasions in which even with a very robust verification system you may
still need to do "downstream debugging".

For example, we work with systems whose inputs are non deterministic.
It is quite hard to create a reasonable number of test vectors that
cover all scenarios. So sometimes you must peek at the system as it is
running in order to understand why it is not working as expected.

Angel