Style of coding complex logic (particularly state machines)

I guess my wording is not very clear. Let me elaborate on the statement. A variable in C is a symbolic memory location in a computer and its function is close to a register in hardware. A statement like

sum =0; for (i=0, i

What is missing is some form of control to say, how many clock cycles it can take to implement the algorithm. Given that additional control on the synthesis the designer can make tradeoffs on how much logic versus how much latency is acceptable and the surrounding circuitry can be designed appropriately. Neither C nor VHDL inherently have this.

I don't think this is equivalent to what is generally meant when synthesis tools do 'register retiming/balancing' either since even after this task they still will meet the overall clock cycle latency of the function. Recognizing that the overall clock cycle latency is really an up front design tradeoff to be made and correctly synthesizing code using that as an input parameter would be a leap forward.

Yep, mine too.

KJ

Hi,

I think that's the intention of mentor's Catapult C synthesis program, though I haven't used it myself.

Cheers,

Andy

Cool, thanks for the tip. Sounds like it's worth investigating.

KJ

Northrop bought the whole shebang and then the Automotive bit spun off as separate entity.

We're not yet at the stage of "chuck any old algorithm at the tools", but I think synthesis tools get less cred for figuring things out than they sometimes should.

Regarding tools - when I write software, I like to know what I'm aiming for in terms of which bits of the processor are going to be used as well. I wouldn't like to not know what my C-compiler is likely to be doing either. However, plenty of people write software without that understanding and in future plenty of people will write hardware similarly. For a lot of applications, it won't matter IMHO.

It's all just a case of getting things done in the end :-)

Cheers, Martin

Well, eventually, it's going to happen. We'll be abstracted far enough away from the hardware to still be productive.

OK, but I notice you've said minimal hardware there - my point was "gets the job done"... maybe I have an enormous FPGA.

Yes. Maybe in 1 process, and maybe in 2, or maybe three :-)

I wasn't suggesting directly mapping C-code to VHDL like this, just that the "describe everything to the synthesizer" approach can be a bit heavy-handed and time consuming.

I don't suggest that the synth *can* make those sort of transformations. It doesn't have the constraints currently to know.

As an aside, I think that FpgaC will do it with one comparator and a memory, (maybe fpga_toys will chip in here).

In the future, we *will* be moving away from low-level stuff like this (personally, I don't think *C* is high enough level, but that's another debate :-)

Cheers, Martin

Hmmm One way to do that is to declare i and/or j as variables rather than loop constants. Then throttle back to fewer loops per tick...

-- Mike Treseler

Take a look at Mentor's Catapult C. It translates untimed C models into synthesizable VHDL or verilog. You must specify the clock period. It assumes loop iterations take one clock, but individual instructions do not. You can tell it to unroll loops to perform their statements in parallel, or partially or fully pipeline the model, with varying clock cycles per pipe state (i.e. the pipeline need not accept new data every clock). The nice thing about it is that it takes care of the control logic to turn the untimed (i.e. one-clock) description into a useable hardware design that could target a variety of space-performance trade-offs.

They have a very good interface synthesis approach. They can access the inputs and outputs in parallel, streaming in order, or pick them out of an external (to their model, not necessarily to the FPGA) single or dual port ram. Internal arrays can also be stored in registers or single or dual port rams. They also assume the whole hardware model operates with one clock input and one reset input (asynchronous or synchronous, per your choice).

The bottom line is that you wouldn't use it to design a whole chip, but you would use it to design a hardware implementation of a software algorithm. Then the chip designer, using verilog or vhdl, would develop the rest of the chip around it.

They also provide the hooks for testing the hardware description from original c code used to test the c model (at the transaction level), using system-c concurrently with the vhdl or verilog model in modelsim.

In addition, they provide cycle-accurate vhdl and verilog models of the hardware design. I chastised them on the fact that if they worked on their synthesizable vhdl, they could use the same code for synthesis and cycle based simulation (using variables and a single clocked processes, etc.).

I took a 3 day training class with it a couple of weeks ago, and I, a die-hard vhdl designer, was impressed!

Andy

Mart>

Thanks - I shall take another look, it's been a while since I looked at that. Sounds a lot like what AccelDSP does for Matlab scripts.

Cheers, Martin