Why use DSP builder over HDL?

Discussion in 'VHDL' started by Tricky, Oct 2, 2009.

  1. Tricky

    Tricky Guest

    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?
    Tricky, Oct 2, 2009
    #1
    1. Advertising

  2. Tricky

    backhus Guest

    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
    backhus, Oct 2, 2009
    #2
    1. Advertising

  3. 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
    Mike Treseler, Oct 2, 2009
    #3
  4. Tricky <> 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
    Kenn Heinrich, Oct 3, 2009
    #4
  5. 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
    Mike Treseler, Oct 4, 2009
    #5
  6. Tricky

    Tricky Guest

    On 4 Oct, 21:09, Mike Treseler <> 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.
    Tricky, Oct 5, 2009
    #6
  7. Tricky

    Tricky Guest

    On 3 Oct, 05:44, Kenn Heinrich <> 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?
    Tricky, Oct 5, 2009
    #7
  8. 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
    Mike Treseler, Oct 6, 2009
    #8
  9. Tricky

    Andy Guest

    On Oct 5, 3:06 am, Tricky <> 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
    Andy, Oct 6, 2009
    #9
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bodhi
    Replies:
    0
    Views:
    595
    Bodhi
    Nov 5, 2003
  2. Andres
    Replies:
    0
    Views:
    625
    Andres
    Nov 6, 2003
  3. glen herrmannsfeldt

    Re: ARM7, DSP and mobile phone, how and why?

    glen herrmannsfeldt, Jun 15, 2004, in forum: C Programming
    Replies:
    3
    Views:
    1,072
    Al Grant
    Jun 18, 2004
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,766
    Smokey Grindel
    Dec 2, 2006
  5. Phlip
    Replies:
    5
    Views:
    551
    Stefan Behnel
    Jan 13, 2010
Loading...

Share This Page