Mathworks Simulink

Discussion in 'VHDL' started by Tricky, Apr 7, 2009.

  1. Tricky

    Tricky Guest

    Does anyone have much experience with this and Auto-VHDL generation of
    algorithms? It seems some people have the idea that once they have the
    algorithm specified in sumulink, they can just press the "to VHDL"
    button and out pops some working code that will go straight into our
    hardware, solving all of our problems (these are not hardware
    engineers, who have so far been a little sceptical to say the least).

    Am I going to be out of a job writing algorithm based VHDL in the next
    5 years?
     
    Tricky, Apr 7, 2009
    #1
    1. Advertising

  2. Tricky wrote:
    > Does anyone have much experience with this and Auto-VHDL generation of
    > algorithms? It seems some people have the idea that once they have the
    > algorithm specified in simulink, they can just press the "to VHDL"
    > button and out pops some working code that will go straight into our
    > hardware, solving all of our problems (these are not hardware
    > engineers, who have so far been a little skeptical to say the least).


    Simulink is a good tutorial on how to code dsp modules,
    and can generate usable rtl code,
    but everything else is better covered directly by vhdl or verilog.

    All code generators make ugly code.
    Once I understand what the generator is doing,
    I will capture and parametrize the functions,
    and take the odd tool out of the design loop.

    > Am I going to be out of a job writing algorithm based VHDL in the next
    > 5 years?


    Not because of code generators.

    The pressure on FPGA designers comes from
    cheap servers and open source software.
    Luckily servers are big and noisy so far.
    Also note that algorithms work in any environment.

    -- Mike
     
    Mike Treseler, Apr 7, 2009
    #2
    1. Advertising


  3. >
    > The pressure on FPGA designers comes from
    > cheap servers and open source software.
    > Luckily servers are big and noisy so far.
    > Also note that algorithms work in any environment.
    >
    >         -- Mike



    Care to elaborate? I'm interested in your views.

    Best regards
     
    Benjamin Couillard, Apr 7, 2009
    #3
  4. Tricky

    Sean Durkin Guest

    Tricky wrote:
    > Does anyone have much experience with this and Auto-VHDL generation of
    > algorithms? It seems some people have the idea that once they have the
    > algorithm specified in sumulink, they can just press the "to VHDL"
    > button and out pops some working code that will go straight into our
    > hardware, solving all of our problems (these are not hardware
    > engineers, who have so far been a little sceptical to say the least).
    >
    > Am I going to be out of a job writing algorithm based VHDL in the next
    > 5 years?


    I doubt it. A while back, we evaluated several tools that claim to save
    gazillions of man months when porting algorithms to FPGAs, but then
    decided to stick to hand-coding for the time being.

    1. Matlab -> RTL (the solution offered by mathworks): The downside is
    that the blocks that are supported are very limited in number and
    function. They have things like adders, subtractors, delay elements and
    the like, all stuff that you can basically just write on-the-fly in VHDL
    anyway. At that time, no really interesting things were available, like
    FFTs or ready-to-use filters or so. To me it seemed like you would then
    just use Simulink as a kind of "schematic editor" to connect very simple
    primitives and have it spit out a HDL description. This could save you
    some time and you get free "documentation" (meaning the block diagram)
    as well, but to me it seemed it's not really worth the money (the
    license is quite expensive). Besides, the algorithm people still have to
    adapt to the limitations, i.e. the Matlab designer has to know exactly
    which functions he can use and how the functions map to hardware when
    writing the algorithm, or the HDL designer needs to adapt it afterwards.
    So, in the end, I didn't really see how this would be a big time-saver,
    except maybe for people new to HDL design.

    2. Mentor Catapult C: To me this seemed the most "advanced", judging by
    what it claims to be able to do, like loop unrolling and taking care of
    BRAM at the input or outputs of your algorithm module. But it crashed
    twice during one 2-hour presentation, running the examples supplied with
    the program, and the price for a single license is higher than many a
    project's entire budget, so this was out of the race quite fast.
    Besides, it needs C code for the algorithm, whereas our people do their
    stuff with Matlab. Plus, it also needs Precision Synthesis to work, so
    that makes it even more expensive.

    3. Xilinx AccelDSP: very cheap, works well, lots of available cores
    (sometimes they require additional licenses), but only for Xilinx
    devices. You can always try that out with a free 30-day test license. We
    didn't get very far in testing this, since it was then decided not to
    use a tool that only works with one manufacturer's devices.

    So, in the end we decided not to follow this any further, at least for
    the meantime.

    cu,
    Sean
     
    Sean Durkin, Apr 7, 2009
    #4
  5. Tricky

    Tricky Guest


    >
    > 1. Matlab -> RTL (the solution offered by mathworks): The downside is
    > that the blocks that are supported are very limited in number and
    > function. They have things like adders, subtractors, delay elements and
    > the like, all stuff that you can basically just write on-the-fly in VHDL
    > anyway. At that time, no really interesting things were available, like
    > FFTs or ready-to-use filters or so. To me it seemed like you would then
    > just use Simulink as a kind of "schematic editor" to connect very simple
    > primitives and have it spit out a HDL description. This could save you
    > some time and you get free "documentation" (meaning the block diagram)
    > as well, but to me it seemed it's not really worth the money (the
    > license is quite expensive). Besides, the algorithm people still have to
    > adapt to the limitations, i.e. the Matlab designer has to know exactly
    > which functions he can use and how the functions map to hardware when
    > writing the algorithm, or the HDL designer needs to adapt it afterwards.
    > So, in the end, I didn't really see how this would be a big time-saver,
    > except maybe for people new to HDL design.


    From what Ive seen recently, they do now have things like "filter
    wizards" where you can modify the parameters and taps and whatever,
    and it will allow you to output RTL. Plus there is the altera DSP
    Builder which I think adds altera versions of FFT and other
    interesting image processing and DSP elements. (I think there is a
    Xilinx Equivalent)

    But, of course it will never cope with the specifics of boards -
    memory controllers, UARTS etc. Or if they do, it will never be as
    effecient as a hand crafted job. I see it like making something like a
    Vase out of lego. Yes it can be done, but making it out of clay would
    be much better.

    My worry is the management get sucked into the mathworks presentation
    - see that anyone can now generate firmware (from the coughed up RTL
    code) and then all I get to do is the memory controllers and UARTs,
    and stitch it together with the terrible auto-generated VHDL.

    What I do like about simulink though is the way it help encapsulate
    specs and tie a project together. Now if only they would leave the
    firmware generation out of it..
     
    Tricky, Apr 8, 2009
    #5
  6. Tricky wrote:

    > My worry is the management get sucked into the mathworks presentation
    > - see that anyone can now generate firmware (from the coughed up RTL
    > code) and then all I get to do is the memory controllers and UARTs,
    > and stitch it together with the terrible auto-generated VHDL.


    Managers of the Profit/Loss/Schedule type,
    spend about as much time thinking about engineering tools
    as janitorial supplies.

    It's hardware engineers, looking at covering DSP functions
    in a hurry who evaluate such tools.

    > What I do like about simulink though is the way it help encapsulate
    > specs and tie a project together.


    It's a passable system level simulator,
    but I don't think it will replace any
    fpga designers.

    -- Mike Treseler
     
    Mike Treseler, Apr 8, 2009
    #6
  7. Benjamin Couillard wrote:

    > Care to elaborate? I'm interested in your views.


    The cost of a generic multi-core rack-mount server
    is nearing the price of a high-end fpga
    on a circuit board in a custom box.

    If the project uses standard interfaces,
    and requires web access,
    with heavy math or database functions,
    the server solution is becoming competitive
    for some applications.

    -- Mike Treseler
     
    Mike Treseler, Apr 8, 2009
    #7
  8. Tricky

    Marty Ryba Guest

    "Mike Treseler" <> wrote in message
    news:...
    > The cost of a generic multi-core rack-mount server
    > is nearing the price of a high-end fpga
    > on a circuit board in a custom box.
    >
    > If the project uses standard interfaces,
    > and requires web access,
    > with heavy math or database functions,
    > the server solution is becoming competitive
    > for some applications.


    Actually, for DSP-intensive applications, the current rage is GPUs- the
    NVIDIA chips ganged together several to a board, with several of these
    boards installed into rackmount servers. Our company is using these in
    several applications on both R&D and "real" projects. Our technology
    managers recently ran a little "summit" to compare notes on these efforts
    scattered across the company. I've looked at some of their results and it's
    pretty impressive how many FLOPS/Watt they can get. As far as FLOPS/$, the
    GPUs may be pretty competitive as well. Of course these beasts have their
    own learning curve if you want to do something real.

    My DSP processing is straightforward enough that I can (and have) done it in
    VHDL already so there is less incentive to port it to something else now,
    plus I need realtime behaviors that are hard to get in standard computers,
    and my project has to eventually target a single custom ASIC so it's better
    to work in FPGAs now.

    -Marty Ryba
     
    Marty Ryba, Apr 9, 2009
    #8
  9. Tricky

    Tricky Guest

    On 8 Apr, 19:05, Mike Treseler <> wrote:
    > Benjamin Couillard wrote:
    > > Care to elaborate? I'm interested in your views.

    >
    > The cost of a generic multi-core rack-mount server
    > is nearing the price of a high-end fpga
    > on a circuit board in a custom box.
    >
    > If the project uses standard interfaces,
    > and requires web access,
    > with heavy math or database functions,
    > the server solution is becoming competitive
    > for some applications.
    >
    >         -- Mike Treseler


    Unfortunately, This wont fit in a PC104 standard and run somewhere
    around 25-50W, so I guess Im safe for a while.
     
    Tricky, Apr 9, 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. moe
    Replies:
    1
    Views:
    2,332
    Tom Hawkins
    Oct 26, 2003
  2. Patrick
    Replies:
    3
    Views:
    7,269
    mubarak.mohmed
    Oct 8, 2009
  3. Patrick
    Replies:
    0
    Views:
    658
    Patrick
    Oct 29, 2004
  4. Replies:
    5
    Views:
    2,676
  5. sir_fixelot
    Replies:
    1
    Views:
    348
    Victor Bazarov
    Apr 22, 2006
Loading...

Share This Page