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

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

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