View Single Post
  #2 (permalink)  
Old 10-26-2003, 08:38 PM
Tom Hawkins
Posts: n/a
Default Re: Modeling hardware in Matlab/Simulink (delay, etc.)?

moe <[email protected]> wrote in message news:<[email protected]>...
> Hello all,
> I need some guidedance on how to go about modeling an algorithm before I
> design it into an FPGA.
> I'd like to use Matlab to run the simulation. Instead of just sanity
> check, I also need to optimize the size (# of bits) of several
> parameters. It'll be a balance act between # of bits (hence, FPGA
> performance) and precision of the algorithm output. FPGA needs to run
> 150+Mhz, and the parameter sizes may end up being somewhat of an odd
> size (48? 56?), perhaps up to 64. The algorithm is made up of mostly
> adders and delay elements.

You may want to consider Confluence (CF) for modeling your initial
Like Simulink, CF is a structural dataflow language, i.e., you design
with systems and subsystems, wires and ports. But instead of a GUI,
CF is textual language.

The main strength of Confluence is it's extensive use of parameters;
every CF variable is a configuration parameter that controls how a
system is created. Therefore it's easy to add parameters to
experiment with design tradeoffs such as signal precision and system

For simulation, Confluence compiles into cycle and bit accurate C and
Python models. I personally prefer Python as a high-level testbench
language, but compiled C is very fast. Also, it's straightforward to
integrate C models into Matlab via Simulink s-functions.

> So far, it looks like I need to use Simulink with Fixed-point blockset.
> Is that sufficient, or is there a better way to do this? I've been
> reading previous posts in different places, and it sounds like modeling
> delay isn't as easy as it should be. Is that true? I was able to use
> 'Triggered subsystem' to model a FF without much problem, but then it
> was for a very simple single bit data path.

If you're targeting an FPGA, your delays (aka. registers) should be
synchronous, i.e., the output data only changes on the clock edge. If
you only have one clock domain, synchronous registers are modeled in
Simulink as a unit delay block (1/z). I would stay away from
triggered subsystems because their
semantics do not correspond to hardware. If you need a delay with a
reset and enable, you can add a couple switches in front of the 1/z as
shown in the following pseudo code:

UnitDelayInput = Reset ? 0 : (Enable ? Input : UnitDelayOutput)
Output = UnitDelayOutput

In terms of delays, Confluence is a purely synchronous language; all
registers are synchronous. For example, gluing a chain of 7 delays
together is done like this:

{Delay, 7 DataIn, DataOut}

Note that 7 is a configuration parameter. Techincally speaking,
DataIn is too. One nice feature of the language is clocks, resets,
and enables are implicit. This allows you to clock, reset, or enable
entire subsystems, without having to drag these signals down to every
register in a hierarchy.

You can find Confluence at:

If you'd like to see a particular example, let me know.


Tom Hawkins
Launchbird Design Systems, Inc.

> I'd appreciate any input, feedback, insight, suggestion. I'm sending
> this to VHDL/Verilog newsgroups for a wider audience.
> Please replace 'hard' with 'easy' in my email addr, if replying via
> email.
> -moe

Reply With Quote