Tricky said:
I know this group may be biased, given that it's a VHDL forum, but I
thought Id ask for opinions from people who may have been in a similar
situation.
I look at it as another "evolution point" in the battle between
efficiency of people vs efficiency of gates. It's a lot like the old
assembly-language versus higher-level languages debate.
Your post is timely, though -- I've spent the last eight hours bashing
around some digital PLL code in VHDL, fighting with all the usual
suspects: computing bitfield indices, determining where the MSB
overflows under various conditions, enforcing saturation, all the while
keeping in mind whether I can do these in a single clock cycle or if I
need to precompute flags and add yet another stage to the pipeline,
causing me to re-edit my root timing chain code yet one more time.
I consider myself a pretty adept VHDL person, a good hardware designer,
and a resaonable DSP theoretician. The theoretician in me says the code
itself should be a no-brainer. And it is, really. Yet it's frustrating
to be futzing around in such low-level stuff for so long, even when I'm
competent to do it, when I suspect that one of these DSP productivity
enhancement tools could manage the decimal point, pipelining, clock
enables, and so on, all with a few clicks in a GUI.
If I could trade a day of screwing around with numeric_std.signed vector
indices, for an hour of thinking at the same level my algorithm runs at,
I'd be pretty happy.
But on the other hand, as some have pointed out, you can pay for this
friendly, utopian DSP fantasy (it comes with its own unicorn!) in a big
way. There are plenty of practical headaches: version control, inability
to seamlessly integrate manual code hacks, six billion files in the
autogenerated design heirarchy, a learning curve, and (presumably) some
inefficiency in gates and cycle time. And of course, at some point in
the design, somebody somewhere has to make decisions about bit widths
and so on - the root design parameters still need to be managed by a
human.
It has come to a point where management are insisting all
implementation is done in Simulink/DSP builder, rather than hand coded
HDL.
Ive been using DSP builder in simulink a week now, and all I feel is
like its come full circle back to schematic entry that many people
abandoned for HDL input years ago. We lose the ability for auto-
documention of changes via version control, but it appears we gain
commonality inside a single environment accross all departments
(algorithms, hardware, software).
Across all departments... that smells of danger. Keep the software guys
the heck away from hardware design or they'll start doing things so
radically dumb you'll want to bang your head into a wall. That's the
hidden danger of these tools - it's like giving a chainsaw to a six-year
old. She may be a mathematical savant but that doesn't qualify her to
wield a Husqvarna. She may appear to be doing useful work for a while,
but suddenly there will be this horrible scream and then....
But even that doesnt fully ring
true, as simulink allows co-simulation of HDL via modelsim.
I played one of these tools a few years back and thought it was too
immature for my stuff. But I feel that a lot of these high-level
synthesis tools are actually getting close to ready-for-prime-time;
perhaps yours is one of them.
So guys (and any girls?) what advantages does simulink/DSP builder
offer me over well written, well structered HDL?
As much as I'm a pretty hardcore VHDL user, I'll concede some of these
points to high level synthesis tools:
- no need to write as much plumbing (signal decls, port mappings)
- tool is (I believe) suited for keeping track of decimal point and
bit widths, remembering signed vs unsigned, etc
- library code (like FFTs, FIRs,e tc) that "just works" with less time
rooting through vendor "core generator" tech reports, and
intepreting timing diagrams
- easier to share models for simulation and verification
On the other hand, it seems that the problem domain (pure DSP) that
these tools address in a beatiful, focussed, and effective way, may
often comprise only a relatively small fraction of your entire
design. It doesn't do squat to provide you with RAM interfaces, SERDES,
PLLs and clocking, CPU interfaces, and so forth.
Just my 2 cents.
- Kenn