( ESNUG 428 Item 8 ) -------------------------------------------- [04/28/04]
From: Lawrence Case <lawrence.case=user domain=motorola spot calm>
Subject: Lawrence's Hands-On Detailed Technical User Review Of CoWare N2C
Hi, John,
Our project team consisted of 4 part-time engineers, 1 full-time engineer,
and 3 months of CoWare assistance. The entire project lasted 6 months.
During that time we built a SoC-like platform with an ARM processor, AMBA
bus, RAM, interrupt controller, DMA-based accelerator (our IP), and
timer. We developed a C-based transaction level model (TLM) of our design;
we swapped the TLM model for RTL of our design in the same simulation
platform and showed that the same software could run each version and give
the same result. We ran Linux on the platform and we loaded kernel mode
drivers that controlled our devices.
CoWare provides a C-modeling environment to allow developers to connect
modules, RTL or C-coded, with clocked or unclocked interfaces, at various
abstraction levels, on a microprocessor-based simulation platform. The
platform can have multiple processors and busses.
What we did and what we learned:
CoWare N2C Platform Development
What we did: We downloaded and installed the tool. Out of the box we had
the processor and RAM running with the CoWare OS. We added other
peripherals such as a timer and interrupt controller with guidance from
CoWare and others. Later we developed the stimulus module which represented
our incoming traffic.
Setting up the processor and RAM were easy. CoWare has a tutorial and has
default settings in their tool which allows one to quickly get running.
Adding other peripherals to the platform required knowledge of how to
control the devices. A proprietary interrupt controller was particularly
complex and difficult to set up and a good example why one needs to design
with software in mind (CoWare provides a simpler one). CoWare has a GUI
for connecting modules and busses together. It looked daunting at first
but everyone picked up on the procedure for integrating modules rather
quickly. My favorite feature is their memory map builder. It'll pick a
map out for you. I wish more tools were willing to guess what you want.
What we learned: Instantly we were thrust into the role of "system"
architects. We quickly became aware that we were no longer designing at
the module level but instead building a platform and thinking from a
platform perspective. We needed to reuse other's designs to build an
environment around ours. With each additional peripheral in our system,
we needed more control code which added more complexity. I believe after
our first month we were at the point where we would not think as module
designers again, our SOC perception bubble had expanded.
TLM Modeling
What we did: Bus performance was a metric we wanted because our design had
a DMA, internal buffers, and required linked-list descriptors to program
and control the functions of our accelerator; it spends a lot of time on
the bus. We built a transaction level model that gave exact bus performance
and programmable latency without all the internal details of a RTL level
design.
TLM modeling has concepts that we needed to understand, especially since
our design has a bus master. Once we learned how to manipulate the
schedule of events we had no problems. We found no issues with CoWare's
class of TLM calls. It works well and is very fast, as advertised.
What we learned: From RTL simulations we knew exactly what the bus data
should look like coming in and going out of our module. At a point in the
TLM development it was frustrating trying to build a accurate bus model
that matched the RTL, until we realized that our design not only has FIFOs
for buffering but also has implicit buffers (registers) that store
additional data popped from the FIFO. This small insight reminded us
how models can help us understand what is going on in a real system.
The Tricky Linux OS Port
What we did: We converted an Armulator Linux Port to run in our platform
and used an Armulator simulation to compare results as we progressed
through the stages of the Linux code. We did not need many of the platform
resources to support Linux but we did need to make sure the memory map,
RAM, and timer were all in place. Admittedly, to get through the port,
we bypassed the interrupt controller code and saved that fundamental
addition for a later date.
This turned out to be a difficult task for those of us not practiced in
the art of porting OS's. The cycle-callable model in our platform did
not exactly match the Armulator behavior so any discrepancy in
execution of instructions brought concern that we would have to dig deep
to understand the difference. But slowly and surely we realized that all
the "bugs" we encountered were simply due to our lack of understanding of
what the OS is trying to do, and what it needs. CoWare was a great help
in this. We paid for their consultation and it was here that they earned
every penny of it (they also were a great help in the other areas but this
one had a heavy weight). In the end, CoWare does not limit the port.
Their simulator is capable of running third party operating systems. The
problem arises later when attempting to profile software. The CoWare OS
has monitors built-in but Linux does not. We would like to see CoWare
come delivered with a Linux-like OS that can profile and trace software
execution.
What we learned: We learned debugging techniques for Porting an OS. One
example in particular showed us the advantage of working in a simulation
environment where all the internal functionality is visible. We were
having problems getting our BogoMIPS calculation (Linux users may know
what we are talking about) because the timer was not counting down
properly. The timer owner assured us the model was correct, and from its
reference guide it looked identical in function to the Armulator timer.
After scratching our heads a bit we set up a break points in the OS timer
code and in the timer model (something you do not usually do in RTL).
Stepping through the timer configuration sequence we discovered the OS
was inadvertently resetting our timer setup due to a very slight difference
between the two timers that was not apparent in the documentation.
Connecting RTL
What we did: We used The CoWare bus model of the AHB we used was at the
TLM abstraction level but our design was pure RTL. We were able to
directly connect them because both abstractions interact at the cycle-edge
boundary, unlike netlists which have events beyond clock edges. Our
design has a master interface to the AHB bus and a slave interface through
a non-ARM peripheral bridge. We wrote a gasket that connected our slave
port directly to the AHB bus. It is important to note that in a C-model
of the CoWare environment you can not simply save waveforms of all internal
signals, only module port traces can be viewed. Internal signals are seen
with break points (something a hardware designer has to get used to), or
with print statements.
We ran into difficulty, but as with many of our tasks, it was not the
CoWare tool that gave us grief. In this case we thought it must be an
incompatibility between the TLM AHB bus and our RTL module interface.
CoWare assured us that it should work but they had their own self doubts
since TLM was a new technology at the time. As it turned out, our in-house
interpretation of AHB-Lite was different that what ARM had specified and
our RTL module interface was incorrect.
What we learned: We relearned the value of having an independent source
provide a golden reference. Their certified AHB-Lite bus revealed a
misunderstanding. We have now re-established independent teams for
verification into our design flow.
Hardware Development
What we did: Early in the design of our module, before our project started,
the initial concepts of the our peripheral were fleshed out in a C-model
that connected to the AHB bus. Much of the code used in that prototype
can be seen in the final RTL. I did not use the C-to-Verilog convertor
at that time, but I was able to simply replace the C syntax with the
Verilog for most of the design.
Because CoWare has a bus interface and allows clock sensitive blocks, it
is fairly straightforward to model hardware in the platform. The CoWare
OS and default platform are sufficient to allow you to write basic driver
code, connect the block, and receive interrupts. The diffi cult part is
converting C-code to RTL once an implementation has been worked out.
What we learned: Having the freedom to add clock sensitive blocks is a
strong plus for hardware designers learning to model in C. Later, in
TLM modeling we learned to lose the clock sensitive threads again.
Design Reuse, ARM Limitations, and the OS
An engineer who was not on our team, and not familiar with CoWare, used
our platform to develop IP that is going to silicon in 2004. Fortunately
we saw some fruit before cost-cutting measures took our licenses away.
Not to be so rosy, CoWare's interface does not really guide engineers into
developing library components for reuse, nor to entice them to build
various modeling platforms for exploration and validation. CoWare can do
all these things under the hood but you would not know that by simply click
ing the GUI buttons. It would be nice to see a component library drag and
drop type interface. I believe someone in the company needs to take a good
hard look at how to professionalize the tool for industry. This may be
happening already with the recent partnership with Cadence.
Also, CoWare is essentially limited to ARM processors unless you want to
build your own CPU simulators. SystemC may be the key to having various
vendors provide ISS models for CoWare so that a user can pick and choose
the processors in their platform. Finally, it would be really nice if they
provided an out-of-the-box third party real-time, and/or multitasking OS
that works with the standard CoWare flow (software monitors and all).
Overall
All said, CoWare at the very least, is a great SoC learning tool for
up-and-coming SOC and driver development engineers. In a short time, we
dealt with everything from handling interrupts, compiling code for embedded
processors, porting an OS, connecting and controlling peripherals, and bus
utilization. And everything we learned in this modeling environment is
directly applicable to "real" system development. Their technology is
sound and it works. I wish we still had it. I would definitely use CoWare
if we did.
- Lawrence Case
Motorola Phoenix, AZ
|
|
