Mathworks Simulink

[Tricky]

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?

 

[Mike Treseler]

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

 

[Benjamin Couillard]

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

 

[Sean Durkin]

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

 

[Tricky]

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

 

[Mike Treseler]

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]

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

 

[David Bishop]

Sean Durkin wrote:
.....

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.

I didn't evaluate all of these, but I came basically to the same conclusion.
That's why I put the fixed and floating point packages together.

David Bishop.

 

[Marty Ryba]

"Mike Treseler" <mtreseler@gmail.com> wrote in message
news:49DCE75F.3080409@gmail.com...

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

 

[Tricky]

On 8 Apr, 19:05, Mike Treseler <mtrese...@gmail.com> 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.