Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Mathworks Simulink

Reply
Thread Tools

Mathworks Simulink

 
 
Tricky
Guest
Posts: n/a
 
      04-07-2009
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?
 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      04-07-2009
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
 
Reply With Quote
 
 
 
 
Benjamin Couillard
Guest
Posts: n/a
 
      04-07-2009

>
> 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
 
Reply With Quote
 
Sean Durkin
Guest
Posts: n/a
 
      04-07-2009
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
 
Reply With Quote
 
Tricky
Guest
Posts: n/a
 
      04-08-2009

>
> 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..
 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      04-08-2009
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
 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      04-08-2009
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
 
Reply With Quote
 
Marty Ryba
Guest
Posts: n/a
 
      04-09-2009
"Mike Treseler" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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


 
Reply With Quote
 
Tricky
Guest
Posts: n/a
 
      04-09-2009
On 8 Apr, 19:05, Mike Treseler <(E-Mail Removed)> 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.
 
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
ModelSim + Simulink VHDL Cosimulation Patrick VHDL 3 10-08-2009 10:51 AM
Senior Compiler Engineer, Mathworks, Natick MA sir_fixelot C++ 1 04-22-2006 02:37 PM
wxpython or PyQT to make a simulink clone ? cravephi@hotmail.com Python 5 06-02-2005 01:35 PM
Simulink / Active HDL Cosimulation Patrick VHDL 0 10-29-2004 12:30 PM
Modeling hardware in Matlab/Simulink (delay, etc.)? moe VHDL 1 10-26-2003 08:38 PM



Advertisments