( ESNUG 491 Item 4 ) -------------------------------------------- [04/14/11]
Subject: Second user confirms CatC does SystemC, control, and prototyping
> We did an eval of Mentor's SystemC support. CatapultC does SystemC.
>
> - from http://www.deepchip.com/items/0488-10.html
From: Bernhard Niemann <bernhard.niemann=user domain=iis.fraunhofer.de>
Hi, John,
We evaluated Mentor Catapult C's support for SystemC and were satisfied
with the results. Below are our specifics and findings.
We've been using Catapult C in our designs since 2004, so we already knew
how it handled complexity and QoR (gate count, throughput, latency).
We wanted to assess how it worked with SystemC input, so we did an eval
exclusively on that. Our goal was to mix algorithmic and cycle-accurate
abstraction levels:
- Continue to use C++ to design our key algorithms.
- Integrate those C++ algorithms into our environment
by encapsulating them in a SystemC module, and writing
the interface and I/Os in SystemC.
SystemC lets us specify interface and communication protocols in a flexible
manner. It is also convenient for specifying design hierarchy because it
provides explicit modeling constructs for hierarchy, similar to Verilog
modules.
VERILOG RTL WRAPPERS
We chose a FIR filter connected to a data source and a data sink as our test
design. Our focus was to evaluate SystemC for the communication part.
Catapult maps abstract I/Os to predefined interface components. However,
Catapult didn't always map to the exact interfaces we needed, so we built
the design with Catapult's I/O components, and then provided Verilog RTL
to force Catapult's I/O to our actual interface. We wanted to use SystemC
to get rid of the tedious hand Verilog RTL wrappers.
I should explain that it's different using SystemC for TLM than it is to
use it for design. For example, in SystemC there are defined ways on how
to handle transaction level ports and interfaces, while high level synthesis
tools do not support the notion of an abstract port. This is a slight
annoyance, but is inherent when doing high level synthesis, rather than a
particular tool limitation.
SCHEDULING
We wanted to assess how our cycle-accurate SystemC code impacted how
Catapult scheduled the rest of the algorithm. Catapult handled that to our
satisfaction. We saw the behavior we were looking for:
Catapult allowed the computation to continue while the interface protocols
ran. If there were no data dependencies, the algorithms continued to run.
If there were data dependencies, then the algorithm halted. This gave us
maximum throughput and maximum flexibility in defining our algorithm. When
we had multiple input sources, the interfaces ran independently.
CONTROL LOGIC
There's always been discussion around whether or not HLS tools support
control logic in one or the other way. In my opinion, before talking about
control logic support, we need to make sure to share the same understanding
of the term "control logic."
I think it makes sense here to distinguish between "Algorithmic," "Control-
Dominated," and "Cycle-Accurate."
- Algorithmic: Highly regular compute intensive module like e.g.
FFT, FIR filter and the like. Usually it can be structured in
Input-Computation-Output.
- Control-Dominated: A module containing a lot of if-else statements
but does not have cycle constraints on its I/O behavior. Usually
I/O does not only occur at the beginning or end of the computation.
There are, however, no requirements to have an output asserted an
exact number of clock cycles after an input has been asserted.
- Cycle-Accurate: A module with I/O requirements like "exactly two
clock cycles after an input has been asserted, something must
happen at the output."
If you want to do "Algorithmic" or "Control-Dominated" modules, in my
opinion pure C/C++ is sufficient to get the job done. This is supported
by Catapult C as is. However if you need to go "Cycle-Accurate" then
SystemC is your language (if you do not want to stick with VHDL or
Verilog). The SystemC option inside Catapult C provides let's you do
all three types of modules using one single language.
Here is an example of our SystemC code which we used to describe the cycle-
accurate behavior of the data input protocol for our FIR filter example.
template<class T>
class read_port
{
public:
sc_in<T> data;
sc_in<bool> valid;
sc_out<bool> ack;
read_port(const sc_module_name &name)
{}
#pragma design modulario
T read()
{
do
wait();
while(valid.read() != true);
T value = data.read();
ack.write(true);
do
wait();
while(valid.read() != false);
ack.write(false);
return value;
}
void operator() (rw_channel<T> &channel)
{
data(channel.data);
valid(channel.valid);
ack(channel.ack);
}
};
CONCLUSION
Catapult C's SystemC support was comprehensive - it did what we were
looking for and we did not have to make code changes.
Beyond its SystemC support, we've been using Catapult C on many of our
projects for 7 years now and it consistently meets our performance goals.
We do real-time prototyping of our ASICs using FPGAs. We run our FPGAs
with same clock as on our ASICs - it's the same scripting for both flows.
That's one of the reasons we use Catapult. Usually we field test the
design in an FPGA first, then we target an ASIC using Catapult C without
tweaking our original C++ code. If our design works in an FPGA at given
frequency, Catapult makes getting to an ASIC push button for us.
- Bernhard Niemann
Fraunhofer IIS Erlangen, Germany
P.S. I want to point out that we did our Catapult C eval *ourselves*
onsite, rather than have Mentor do it in taxicab mode. That's
our evaluation policy - since *we* will be the ones running the
tool, *we* need to make sure we are happy with it.
Join
Index
Next->Item
|
|
