Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Why use DSP builder over HDL?

Reply
Thread Tools

Why use DSP builder over HDL?

 
 
Tricky
Guest
Posts: n/a
 
      10-02-2009
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?
 
Reply With Quote
 
 
 
 
backhus
Guest
Posts: n/a
 
      10-02-2009
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
 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      10-02-2009
Tricky wrote:
> 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
 
Reply With Quote
 
Kenn Heinrich
Guest
Posts: n/a
 
      10-03-2009
Tricky <(E-Mail Removed)> writes:

> 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



 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      10-04-2009
Tricky wrote:

> 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
 
Reply With Quote
 
Tricky
Guest
Posts: n/a
 
      10-05-2009
On 4 Oct, 21:09, Mike Treseler <(E-Mail Removed)> wrote:
> Tricky wrote:
> > 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


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.
 
Reply With Quote
 
Tricky
Guest
Posts: n/a
 
      10-05-2009
On 3 Oct, 05:44, Kenn Heinrich <(E-Mail Removed)> wrote:
>


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


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.

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


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?
 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      10-05-2009
Tricky wrote:

> 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
 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      10-06-2009
On Oct 5, 3:06*am, Tricky <(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
WTS APX-SL-DSP-3 288 port Voice/Data DSP cards isptrader VOIP 0 08-29-2005 04:32 PM
WTS APX-SL-DSP-3 288 port Voice/Data DSP cards isptrader VOIP 0 08-15-2005 05:40 PM
WTS APX-SL-DSP-3 288 port Voice/Data DSP cards isptrader VOIP 0 08-15-2005 05:32 PM
WTS: APX-SL-DSP-3 288 port Voice/Data DSP cards isptrader VOIP 0 08-03-2005 04:20 PM



Advertisments