On Apr 1, 9:47*am, "M. Norton" <remill...@gmail.com> wrote:
> On Wednesday, March 30, 2011 4:20:31 PM UTC-5, KJ wrote:
> > 1. Similar to what Jonathon suggested, but a bit easier (I think) to
> > draw good boundary lines for the testing entity is to model real
> > parts. *FPGAs in real applications do not exist untethered to the rest
> > of the world, they are connected to real parts on a circuit board so
> > your 'FPGA testbench' could (I think 'should') be a model of that PCBA
> > (and surrounding systems)...which means that if you model the parts
> > that go on that PCBA and connect them per the netlist then you're
> > modelling your real system. *In your case, you had mentioned in later
>
> I've actually done this for downstream effects. *If the FPGA is drivinga ADC or DAC or other peripheral, I base the model on the datasheet and implement it to some degree of fidelity (usually loose at first, and then growing complexity over time, with timing checking assertions and the like.) *I've not done this with the stimulus side though, as frequently it seemslike that task is more daunting than time permits. *
KJ: In what way would it be more daunting to put stimulus code within
the entity for the model for a real part then it is to put it in some
freeform testbench? In order to provide stimulus (and check
responses) you have to write 'something', I'm simply saying that
putting that 'something' inside the model of real part(s) would be a
better overall location than just into some otherwise probably non-
reusable testbench.
The only additional work is the creation of the entity for the part(s)
and the creation of a PCBA and/or system model. The PCBA model
creation is simply instantiating the parts and connecting nets.
Tedious perhaps if you have a lot of parts, but not difficult.
However, if you have a lot of parts that need modelling in order to
test the design, it likely indicates that you'd also need a rather
large and cumbersome freeform testbench.
> I rough in some interface basics but it's pretty rough and ready (hence trying to find a better solution.)
>
> I appreciate the thoughts. *I'll consider more involved stimulus modelsif I can get the reuse and maintainability aspects in line.
>
<KJ soapbox on>: I think you'll find that creating part models is a
good enabler for reuse and maintainability. The reason for this is
that entities are the easiest things to reuse, you simply instantiate
the component and connect it up. Entities are also the natural
hierarchy boundary in VHDL. Within a part model you might use
existing designs that you already have. Or, when you're creating a
new part you might realize that if you only partitioned some other
model a bit differently you could now reuse that part. That's when
you go back and re-factor the original design to create a now reusable
entity. Re-factoring is a natural result of design, sometimes you get
it correct right from the git-go, other times you want to break
designs down into even smaller, reusable, maybe more generally useful
pieces.
By using real parts that have real specifications as the basis for
your testbench you also pick up the following advantages that apply to
reuse and maintainability:
- The part model can be validated to the specification independently
of the design that the part model is being used to verify in the
testbench...one spends as much time or more verifying a design as you
do designing the thing, yet what is the objective criteria for
validating that the testbench itself is correct?
- As the part model is refined to be more inclusive of functions that
weren't initially needed, backwards compatibility is maintained.
Since the entity for the part model is not changing (that gets setup
at the begining based on the pinout of the part that you get from the
specification), only the code in the architecture for the part model
is getting tweaked. All this is doing is refining the function to
more closely reflect reality. If that 'breaks' something in a
simulation testbench then it indicates that either the changes to the
part model are not quite correct (refer back to the part specification
to determine) or you've uncovered a hole in the older design that
should probably be fixed. Any result is a 'good thing' resulting in a
higher quality design or higher quality part model or additional
validation that the design really does work as expected.
<KJ soapbox off>
Kevin Jennings
|
Similar Threads
