some guideline for starting Simulink HDL coder?

[rockybc]

Hey guys , has anybody used the Simulink HDL coder for DSP on FPGA or sth.? It's said that the tool could change the simulink model to HDL coder, so i wanna study and start.Would you give some guideline about starting the tool?I found there are few data or books on how to use the tool , plz. help!

 

[TrickyDicky]

My advice - dont use it for anything more complicated that a few adders or multipliers. Add in some control logic and HDL coder is a waste of time. You'd be better off hand coding in VHDL or Verilog.

HDL coder is only meant as a speed up tool - to get your algorithm running on an FPGA faster than it would run in simulink. These are often bloated and no where near an optimal design.

 

[rockybc]

TrickyDicky, do you mean the code simulink HDL coder generates isn't the optimal HDL code and would cost more resource than the one off hand coding in VHDL or Verilog? I used to think it would be convenient to generate HDL code while developing complicated DSP algorithm on FPGA ,since the algorithm code isn't easy to develop off hand in VHDL or Verilog.

 

[TrickyDicky]

It really depends what your goals are.

If you have already selected which FPGA you want to use, and you think it will take a significant % (like 50%+) of your chip to implement, then HDL coder will not give you an optimal solution. You will have to hand code the design to get it to fit. It also is not very good at defining interfaces and multiple clock domains (and basically impossible when you have asynchronous clocks). it is also not very easy to produce scalable designs.

But if your goal is to produce a rapid prototype to help speed up simulation time, this is what HDL coder is good for. It may be convenient to use, but a hand coded solution will be needed to fit in tight spaces.

Personally, I think Simulink can act as an excellent Architectural tool, and it will allow you to bring hand coded VHDL into higher level simulink testbenches via co-simulation, and verify your hand coded block act the same as the simulink blocks using black box testing methodology.

So, decide what your goal is. It will also depend what experience you have you existing FPGA design. Because Im a hardware engineer, having done plenty of previous HDL using modelsim for design and verification, I find simulink lacking when it comes to debugging control signals conpared to modelsim.

But your milage may vary.

 

[sirnails]

It really depends what your goals are.

If you have already selected which FPGA you want to use, and you think it will take a significant % (like 50%+) of your chip to implement, then HDL coder will not give you an optimal solution. You will have to hand code the design to get it to fit. It also is not very good at defining interfaces and multiple clock domains (and basically impossible when you have asynchronous clocks). it is also not very easy to produce scalable designs.

But if your goal is to produce a rapid prototype to help speed up simulation time, this is what HDL coder is good for. It may be convenient to use, but a hand coded solution will be needed to fit in tight spaces.

Personally, I think Simulink can act as an excellent Architectural tool, and it will allow you to bring hand coded VHDL into higher level simulink testbenches via co-simulation, and verify your hand coded block act the same as the simulink blocks using black box testing methodology.

So, decide what your goal is. It will also depend what experience you have you existing FPGA design. Because Im a hardware engineer, having done plenty of previous HDL using modelsim for design and verification, I find simulink lacking when it comes to debugging control signals conpared to modelsim.

But your milage may vary.

I completely disagree - sorry.

If your design is a simple rapid prototype then I agree, I would think that knocking something up in VHDL would be slightly easier and quicker.
However if you have a very large and complex system that a single person would not be able to understand (such as an aircraft, or complex motorised plant) then simulinks strengths come to play in that it can simulate the real world far more accurately and easier than hand coding and modelsim alone (also look at co-simulation - you can use modelsim in conjunction with hdl coder).

My second point would be garbage in garbage out - if you don't know how to use matlab/simulink hdl coder then it will generate trash, however I can sit and hand code trash too...
As you become more aware of the idiosyncrasies of hdl coder (embedded matlab code) then you will learn what generates good code and what pitfalls can be found. Again this is due to engineer maturity - the need to understand how to hand code "good" vhld is essential and is a basis for starting to use hdl coder and the first year of using HDL coder you will be disgusted at the mechanical nature of the VHDL code that is generated but if you stick with it and change how you code embedded matlab code to get the resulting VHDL you want then hdl coder will bring many strengths that you won't be able to live without.

My summary would be, for a simple design like a communication bus, glue logic or simple state machine with adders multipliers then hand code, but for complex stuff, it's worth understanding how to use matlab / simulink properly. its like painting the hallway through the letterbox at times but you will find in the long run that there is more power to simulink and that there are more advantages to using matlab/simulink than hand coding VHDL.

Thats just my two cents.

Regards,

 

[TrickyDicky]

This was posted 3 years ago - and I still stand by what I said.
Simulink is a good system modelling tool, and can easily produce VHDL if you have a nice steady pipeline with simple interfaces. But start to throw in more complex interfaces with multiple clock domains, packet buffers etc etc, you get a bit stuck.

I also still havent seen any employers around here put Simulink as a requirement on Jobs, and I havent seen anyone using it as much as my old employer. The big push is now towards modelling in system verilog and verification with UVM.