Verification of a microcontroller in a SoC

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 3.12, Item 12.0)

From: Raimund Soenning

we are a small subsidiary of Philips in Starnberg, Germany working on
the design of LCD panel controller ICs. We do the IC design itself and
also the design of the low-level driver SW (creating kind of an API
for the application specific SW done in Taiwan). Myself I am leader of
a digital front-end design team that is also responsible for
verification. We do not have a dedicated verification team or
engineers at the moment.

To make a long story short: for the next generation of our ICs we are
supposed to integrate a 80c51 microcontroller core from Philips with
on-board SRAM and ROM and external flash ROM. As none of us has any
experience in doing and particularly verifying this kind of system
I would like to ask you for your advice:

- what is the best way of verifying the uC in and together with the
system?
- is it necessary/complementary/mandatory to use a tool like
'Seamless'?
- at which point in the vericiation process would you test the uC with
the rest of the system (as early as possible or as last step)?
- would it be sufficient to do some basic testing in simulation and do
the rest on the emulator?
- what about FPGA prototyping of the chip with uC?

About our environment: we have the RTL sources of the uC. We use NCSim
as simulator engine - currently with own developed HDL testbench
together with a reference C-model. We also have a Quickturn Mercury+
emulator and will soon have a Quickturn Palladium accelerator/emulator
in-house.

I would really appreciate if you could comment on our situation and
give some hints or directions - or 'best practise' - for our
verification.

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 3.13, Item 6.0)

From: Anonymous

I talk with many customers who have to test similar and more complex
microcontroller based designs. I will try and answer some of your
questions and give you some ideas of my own to aid your verification
task.

> - what is the best way of verifying the uC in and together with the
> system?

The first stage I would suggest is to build a virtual prototype of the
system you intend testing. I am going to assume that your goal if to
first verify that the system itself functions at a basic level. Simple
reads / writes from the microcontroller which interface with the
internal/external memory and other logic. This virtual prototype in
essence is a structural netlist connecting up all the relative
components. It does not have to be all components at this level, just
the set of basic blocks. Once you have this base layer it is easy to
add on top of the system to expand it's functionality.

At this first level you want to use a bus functional model of the
80c51. This will enable you to very quickly build up a set of bus
cycles that generate a large amount of cycles across the
microcontroller busses and activate most sections of the system at a
low level. Remember your goal is to test the system, not the 80c51 in
this case.

A bus functional model for the 80c51 is available from Synopsys as
part of the DesignWare library that you may already own.
http://www.synopsys.com/products/designware/ipdir/ search for 80c51

You also get memory models as part of the DesignWare library that you
can use to model your memory devices.

Now you have a good system starting point to build on top of.

I actually have some examples of systems including an 80c51 BFM. They
were created quite a time ago but still act as good reference design
examples. If you would like to see these please feel free to drop me
an email.

> - is it necessary/complementary/mandatory to use a tool like
> 'Seamless'?

How much software code debug do you want to do verses hardware debug?
That is the question you need to ask yourself. If your goal is to
fully debug the software using the virtual prototype hardware then you
will need to use some sort of HW/SW co verification tool. If your goal
is to thrash out hardware a little more by using the software but
don't really need debug visibility into the software code then a full
functional model of the microcontroller can be used.

You say that you have access to the RTL source, which will be a full
functional model. The virtual prototype you created using the bus
functional model can now be re-used. Remove the BFM and replace it
with the full functional model of the 80c51. Compile your software
into machine code and then into a format like Intel hex. Take this
Intel hex and load it into your boot memory device. As part of the
DesignWare library you get access to a converter that reads Intel hex
and Motorola S-record and converts it into memory image format. This
memory image format can be loaded into the memory models at simulator
startup.

Once you have you code loaded your virtual system will try and boot up
like the real system. As you are only verifying device drivers I do
not expect you to have huge amount of software. You should be easily
be able to verify your hardware against these small parts of code.

> - at which point in the verification process would you test the uC with
> the rest of the system (as early as possible or as last step)?

I think I answered this already. Test system with a bus functional
model first. At the first stage the system is under test, so using a
verified model of the 80c51 will ease the task of getting the system
to work. Then plug in you RTL of the microcontroller. Then in effect
you are using the system to test the integration of the RTL.

I hope that gives you something to start with.

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 3.13, Item 6.1)

From: Dave Chapman

Wow. Where do I begin?

First of all, using the 8051 is a profoundly bad idea. Every project
I have ever seen using that little piece of garbage has ended badly.
The 64k address limit is a problem enough. . .

Assuming that you don't have another job lined up, I would recommend
the following:

1. Use an FPGA to do the simulations. Choose one with lots of extra
pins.

2. Get a software person on board ASAP. You'll want to have the
processor helping debug the design, and not have to guess if it's
correct.

3. You should debug the processor FIRST. See point 2.

4. Sure, set up a simulation environment. It might help to
characterize the bugs you find in FPGA mode.

To not be too boring on this point, however, the 8051 is a 25-year-old
design, and is obsolete. The 64k address limit makes the part not
recommended for new designs. Have you considered a different
instruction set? How about a 68000 subset?