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

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

On 7/11/11 3:29 AM, Angel Ezquerra Moreu wrote:
> 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

I think my point was missed, it wasn't the fact that downstream / 
in-system debugging is beneficial or not but rather that the need for 
*unexpected* downstream debugging can be adverted.  And how this relates 
to the generated "flat" file.

Again, I am not trying to argue if in-system debugging is useful or not 
but instead arguing that including in-system debugging in the design is 
a better approach.  Which removes the need to add probes to the 
post-P&R.  And such, minimizes the argument that the flat file 
conversion is a negative.


Chris