Why use DSP builder over HDL?

T

Tricky

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.

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). But even that doesnt fully ring
true, as simulink allows co-simulation of HDL via modelsim.

So guys (and any girls?) what advantages does simulink/DSP builder
offer me over well written, well structered HDL?
 
B

backhus

Hi,
with Matlab/Simulink and it's associated tools you have a common
design platform for all the peple that work together in your design
group.
Of course you have to work out a flow how to handle all the data
between different workgroups. This can be a lot of work before you
actually become productive.
(Simulink is a beast that needs taming, like all graphical entry
software.)

But then:
The system designers with barely no knowledge of FPGAs, HDLs etc. can
provide you hardware guys with behavioral/mathematical models and
sophisticated system wide testbenches. (including physical behavior,
like noise signals on sensors etc.)
You can then redefine these models and optimize them for a certain
hardware architecture (including testsruns for hardware/software
balancing), and do a fully automated compare test with the original
(behavioral) model.
And even if you have to do some handcrafted HDL, you still have a HDL
testbench generated by matlab, that you can use to maintain identical
behavior.

So, you get better specs and test cases, easier communication between
working groups and much more. (I'm sure I missed to mention lots of
benefits).

Have a nice synthesis
Eilert
 
M

Mike Treseler

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.

It has come to a point where management are insisting all
implementation is done in Simulink/DSP builder, rather than hand coded
HDL.

That might make sense for a DSP module like a filter,
if I couldn't figure out how to convert a freq domain
spec to Z domain to gates and regs.

Otherwise, it makes no logical sense, as
dsp builder makes ugly code.

-- Mike Treseler
 
K

Kenn Heinrich

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
 
M

Mike Treseler

Tricky said:
I've 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.

One passive-aggressive response would be to code the
module in a single box full of matlab code ;)

-- Mike Treseler
 
T

Tricky

One passive-aggressive response would be to code the
module in a single box full of matlab code ;)

  -- Mike Treseler

Well thats what we used to do - have a matlab model - then architech a
hardware approach, code it, then compare the output of both and voila
- 2 black boxes running the same inputs giving the same outputs.

My worry is that people above me think that this can now be done with
a few simple clicks, which it really isnt.
 
T

Tricky

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....

I dont think they're planning on having the algorithm guys or software
guys touch the hardware implementation. But again I think managers
think that my hardware implementation and the algorithm specification
are going to be one of the same thing when Ive finished, so minor
changes can be made by algorithms guys. Im just scared they dont see
the picture clearly. Past work has often been a mess, and only
recently have things been cleared up, version control introduced. Im
worried they still remember the "good old days" when it comes to code
management, so this is now the saviour of the company.
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.

Simulink can interface directly to modelsim that calls up a top level
and connect the ports accordingly. Afaik, this will then allow ANY
VHDL to be called up in modelsim with a view that its a black box from
the pov of simulink. This, imo, is the best compromise - I just need
to covince people that it is.

The argument that simulink offers more flexibility appears to be
untrue. I have a large diagram in simulink that Ive managed to write
in VHDL in about 300 lines of well commented code. With the new fixed
point library, it allows the user to keep track very easily of
fractional components, but obviously you cannot auto align them. But
from using DSP builer, keeping track of fractional components seems to
be trickier, because it only allows positive indexing. Also, Im having
to place components manually (like muxes/counters/reset conditions
etc) that I can explain explicitly with abstract, behavioural (but
still synthesizable VHDL). And then it doesnt take long before you
have wires crossing wires to get all over the screen - who likes to
follow all that?
 
M

Mike Treseler

Tricky said:
Well thats what we used to do - have a matlab model - then architect a
hardware approach, code it, then compare the output of both and voila
- 2 black boxes running the same inputs giving the same outputs.

My worry is that people above me think that this can now be done with
a few simple clicks, which it really isnt.

I expect that if they really believed that,
they would try it themselves.

I just say, "Great idea boss!"
and go about my business.

-- Mike Treseler
 
A

Andy

With the new fixed
point library, it allows the user to keep track very easily of
fractional components, but obviously you cannot auto align them.

Depends on what you mean by "auto align"...

Sure, I wish we could override the assignment operator in VHDL for
this and many other reasons, but judicious use of of the resize
function is an effective work-around.

I just wish they had the foresight to define ufixed - ufixed = sfixed,
since we're using "mathematically correct" operator implementations.
For simple decrementers, a to_ufixed function call could replace the
obligatory resize anyway (or simply overload resize() to cover sfixed-
ufixed too).

That's one of the things I like about integer types in vhdl. All the
operators get effectively expanded to signed 32 bits anyway, then the
assignment limits it back to the storage size indicated by the
recipient's subtype (like an implied resize and/or signed/unsigned
conversion). Synthesis then goes back and gets rid of any logic that
was not really needed.

Andy
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top