David Ashley said:
KJ,
Lots of interesting points. I think the "assert" can certainly be useful
as you describe. One thing to note is that it would be very very much
easier to code expected behaviour in 'c' or 'c++' than in vhdl.
Not necessarily any easier in c/c++. Inside a non-synthesizable model
you're only interested in modelling the behaviour somewhat and in that
context you generally have the freedom to code everything in a single
process (or a handful at best) and make it look very 'c-like'. If you want
to code in c/c++ than probably you want SystemC and then of course a mixed
language simulation environment.
If we're
talking about non-synthesizable code being used to verify the
synthesizable code, then VHDL wouldn't be my first choice. I think I
heard there is movement towards embedding 'c' code within VHDL or
some hybrid approach or something, just for this issue.
I think you may be talking about mixing SystemC and VHDL or Verilog or
SystemVerilog. Every language has it's proponents, plusses and minuses and
such. I wouldn't call it a movement just that one needs to cope with
integrating code written in various languages. Since each language 'seems'
to all be evolving and have some users it suggests that each has a niche and
over time the ebb and flow of which language fits best under certain design
conditions will vary.
Another issue of simulation vs actual use -- I have in mind an application
for an FPGA where the FPGA is the main brain of a multimedia system,
including audio, video, networking, etc. The chips I want to use to
connect to the fpga are from various suppliers. How can I hope to
simulate this whole system? Some of the chips are made in Taiwan --
sketchy to no documentation and I'd be very surprised if they
provided any simulation models.
Ideally the supplier would supply a model, but if they don't you can do it
yourself. But you don't need to code up a model for general use by anyone,
just something good enough for your use. I'm in a similar situation in that
I use ASICs with no sim model from the vendor but I do know what the I/O
pins are supposed to be doing and can model some form of behaviour that
validates that information is properly flowing around the system. As an
example, one of the part I use is a Philips processor. I don't have a
'real' model for the processor and I don't run the 'real' code, instead what
my VHDL model does is emulate the two together. From the standpoint of an
external viewer of the signal pins (which is what your FPGA is) it doesn't
know or care how that model gets generated.
Having said that though, by modelling the part yourself, you're also putting
yourself in the situation of wanting to validate that the model is at least
accurate enough for your purposes. But I would argue that you are
implicitly doing this anyway with whatever form of stimulus/expected
response set that you come up with. By putting this explicitly in the form
of a simulation model you're just changing the form that you encode that
knowledge and if you try it out you may find that it's roughly the same
level of effort.
The other thing I do is use an accurate board model. Our CAD system, when
you save a schematic also writes out a VHDL model that can be used in
simulation as well. If you're new to trying to "model the entire system" I
wouldn't suggest starting at this point until you've gotten your feet wet by
writing your own VHDL that plops down part X, Y and Z and your FPGA and then
interconnecting them (and of course writing/scrounging sim models for X, Y
and Z). Using the CAD produced VHDL model is the most accurate but requires
the most models and you'll find yourself fighting seemingly 'stupid' things
like resistor models (like what is the logical value of a net with a
pullup/pulldown termination; or what about that resistor that connects two
ends of a differential pair).
The last thing I do is that the board typically is not the entire system
either. It connects to external devices....so I model them as well and
connect them to the CAD produced simulation model.
So the only way to debug this thing is through using actual hardware,
doing things in real time since it will require human interaction.
I agree to a point. But if you go into the debug phase with a solid feel
for what you believe parts X, Y and Z 'should' be doing based on your
simulation model and whatever knowledge of the part you have you can go
about the debug more quickly.
Eventually of course you run across the situation where the real parts are
not behaving as you thought they should and of course it is causing some
actual problem on the board that you have to fix. What this implies then is
that either the simulation model was not quite as complete as you need it to
be or that your testing didn't exercise things in the manner that the real
part does on your board. Sometimes the problem is a relatively simple one
where you can with confidence put in the FPGA design change and fix the
problem.
For the not so easy problems though you should 'fix' the simulation model by
adding the new behaviour that you're actually seeing and then you should
also be able to see the failure that you're seeing on the board (even more
ideally because you added an 'assert' to catch it) and debug in a simulation
environment from there. Simulation time is w--a--y longer than real time
but the simulation environment lets you probe down to every blasted signal
in your design to get at the root cause of a problem. Debug in hardware
either doesn't allow this luxury or when it does (i.e. bringing out internal
nodes to observable pins) is limited because you go through various
iterations bringing out more and more new and interesting signals whereas in
simulation you just drag the new signal over to the wave window and can
immediately see the entire history of that signal.
So I guess the dividing line isn't so much as what is synthesizable as
what am I actually going to be doing with VHDL instead of with a
more familiar (to me) language. All I want VHDL for is to help create
the bit file I'll be downloading into the FPGA to make the device do
what it needs to do...I'm not interested in the intellectual exercise of
implementing ELIZA in VHDL :^).
And if there is no need for design verification prior to build then you're
right you don't need any of this so you could've stopped reading this long
ago
Other stuff moved onto the fpga fabric -- embedded processors,
multipliers, MAC's perhaps. Special output buffers to handle DDR2
memory signals.
Yep, the list goes on and on.
KJ
