Re: [myhdl-list] Cosimulation newbie questions

[Jan D. <ja...@ja...>]

On 09/25/2011 10:38 AM, Bob Cunningham wrote:

>
> I'm mainly trying to get a feel for how flexible my FPGA development
> process should be.  In software, we frequently create multiple
> independent tests for a single piece of code that runs in a single
> environment.  In hardware, it seems we should first do our basic
> testbenches in all available environments (myHDL, cosimulation,
> hardware).

I don' understand what you mean here.

> In software we have many well-known metrics we use to determine when
> testing is thorough:  Static code inspection, modeling, input/output
> corner analysis, random vector analysis (black box testing),
> path/state analysis, coverage analysis, and the list goes on.
> Embedded/real-time software basically gets tested to death.  We also
> need to test that our software responds appropriately in the presence
> of significant hardware failures.
>
> Do equivalent metrics (and their support tools) exist in the hardware
> domain?  The test benches I've seen so far appear to primarily be
> simple I/O stimulus.  Do tools exist that ensure a testbench does
> indeed access all critical internal states (including corner cases)?
> That all gates ha

A core idea of MyHDL is that you should be able to use any
verification methodology or tool that is available for general
Python development.

Personally, I use test-driven design and unit testing systematically
for hardware design now.

> Or do I need to insert instrumentation into my circuit to expose
> internal states for access by a more sophisticated testbench?  And
> couldn't some or all of the results acquired using such added
> instrumentation be invalidated when the circuit is run without the
> instrumentation?  I would imagine the synthesis output could be very
> different, resulting in some changed functionality in the
> implementation.
>
> I suppose much of this may reside in the synthesis toolchain,
> something I have not yet thoroughly explored.  I don't yet understand
> some of the content of the WebPACK ISE synthesis reports.

It seems to me still have to come to terms with one fundamental
difference with software design: modeling/simulation and synthesis
are completely different things.

Modeling with MyHDL can be very high level and general. You can use
full Python power and tools.

However, MyHDL is not going to magically solve the fact that synthesis
is conceptually quite low-level and restrictive.

> For example, one concern for me would be finding the maximum usable
> clock rate for a particular design in a particular FPGA.  I haven't
> yet seen anything in a testbench that would help determine this.  In
> software, we are seldom worried if the CPU is going too fast!  Quite
> the opposite.

Surely in software there are also many metrics that your "test bench"
or verification code itself cannot help you with directly. Take profiling for
example, to see how fast particular functions run. Finding out the
clock rate is similar, with the big advantage that it is a static
check. In both cases, you can use such feedback to go back to the
code and make changes.


>
> I'm wondering how gnarly I can expect my testing to get as my designs
> become more complex.
>
> -BobC
>
>
> ------------------------------------------------------------------------------
>
>
All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com