Atmel applications journal.Spring 2004

A T M E L A P P L I C A T I O N S J O U R N A L

Figure 1 Simulation Model

Figure 2

Figure 3

load is engaged, the circuit adjusts the PWM duty cycle to produce the required current. Had the circuit been allowed to rise to the 48 volt rail there would be a large surge of current through the new load when it was engaged. A PWM switching frequency of 50 kHz was initially chosen to balance inductor size against heat dissipation in the P-channel MOSFET due to switching losses. Higher switching frequencies result in smaller magnetic component sizes thus allowing us to use a smaller less expensive inductor. Unfortunately, higher switching frequencies also result in greater switching losses in the MOSFET and the associated higher heat dissipation. From the PSPICE simulation results this initial set of gains and switching frequency seemed a good starting place for the design of the actual circuit.

IV. Algorithm Implementation in the Atmel ATtiny15L:

Implementation of the control algorithm in a digital processor requires translation of the system differential equations from their S

domain Laplace form into the Z domain where they can be coded as constant coefficient difference equations. Constant coefficient difference equations are based on past and present values of the inputs and outputs of the system and the system sample rate. In this case load current error and applied PWM duty cycle to the P channel MOSFET transistor. Coefficients are constants based on the selected gain values and the rate at which the feedback parameter is sensed also called the sample rate of the system. First we start with the block diagram of the control loop shown in figure #4 (see nexy page). Only the feed forward proportional plus integral gain block H(s) is mapped to the Z domain. One of the most popular methods for converting from the S domain into the Z domain is by use of the bilinear transformation. The bilinear transformation successfully maps the S domain transfer function into the Z domain with the right half S plane mapping into the unit circuit in the Z domain. In fact, the bilinear transformation maps the entire imaginary axis of the S plane onto the unit circle in the Z plane thus avoiding the problem of aliasing found with the use of impulse invariance.

H(S) = Y(s)/C(s) = Ki/S + Kp

	C(s)				Y9s)
			Ki/s + Kp

H(S) is converted to H(Z) by the following substitution: S = 2/T[ (1-Z-1)/(1+Z-1)]

Where T = sample rate of the system.

The price paid for this is distortion in the frequency axis. Proper smoothing of the current into the load is dependent on the frequency response of the circuit thus we are better off to avoid use of the bilinear transformation and instead base the transformation on the numerical solution to the differential equation. Mapping to the Z domain is again done by a substitution of variables but the substitutionary value for S is a little different:

S = (1 – Z-1)/T

H(S) = Y(S)/C(S) = [0.5S + 500]/ S

www.atmel.com

page 19

A T M E L A P P L I C A T I O N S J O U R N A L

Figure 4

SY(S) = 0.5SC(S) + 500 C(S)

(1 – Z-1)Y(Z)/T = 500 C(Z) + 0.5 C(Z) (1 – Z-1)/T Y(Z) - Z-1Y(Z) = 500T C(Z) + 0.5 C(Z) – 0.5 Z-1 C(Z)

The term Z-1 represents the value of the associated parameter at the previous sample point. We can denote this by the notation Y(k) and Y(k-1) where Y(k) is current value of the output and Y(k-1) is the value of the output generated by the previous sample. Replacing the above equation with this new notation yields:

Y(k) = 500 T C(k) + 0.5 C(k) – 0.5 C(k-1) + Y(k-1)

Y(k) = A * C(k) – B * C(k-1) + D * Y(k-1)

Where	A = 500 * T + 0.5
	B = 0.5
	D = 1

Let T = .001 seconds, the rate at which the charge current will be sensed and the algorithm recalculated and adjustment to the duty cycle of the PWM made.

A = 1.0

B = 0.5

D = 1

Y(k) = C(k) – 0.5 * C(k-1) + Y(k-1)

This is now the starting point for implementation into the ATtiny15L microcontroller. In terms of how the ATtiny15L AVR processor will implement this algorithm, the following definitions apply:

Y(k) = New duty cycle to be applied to the PWM output. Y(k-1) = Duty cycle applied at last sample.

C(k) = Current error (Ierr) between required current and actual current. C(k-1) = Current error (Ierr)at last sample.

Code for the ATtiny15L was written in C so the compiler was left to assign the data variables to registers in the general purpose register file. Other then simple addition and subtraction there is one divide by 2 associated with the variable C(k-1). This can be accomplished by a simple bit shift one place to the right since 0.5 is equivalent to 1/2n where n = 1.

V. Performance of Circuit and Algorithm:

Initial testing of the circuit determined that power dissipation in the P-channel MOSFET was too great to reach the required 8 Amp limit. Reducing the switching frequency to 25 kHz did not provide sufficient improvement. As a result the circuit had to be redesigned to use an N-channel MOSFET with a high side gate drive circuit.

Final circuit schematic is shown in figure #5 (see next page). Even with the N-channel MOSFET, switching frequency had to be reduced to 25 kHz to keep down the power dissipation. This was primarily due to the requirement to operate in a sealed enclosure with no external heat sinking or air flow. Additional problems were encountered with the control algorithm at load resistances down near the required 1_ limit with the minimum current level

of 3 Amps. This requires an output voltage across the load of only 3 volts. Switching of loads at this low resistance caused instability in the control loop. As a result the forward loop gain had to be reduced to stabilize the system. This posed an interesting challenge, to find a set of gains that no only resulted in a stable overdamped system over the full range of loads from 1_ to 16_ but also could be implemented in the ATtiney15L requiring only bit shifts. Fortunately a simple reduction in the proportional gain by a factor of 0.5 combined with a change in the sample rate to 0.5 msec was sufficient to stabilize the system.

This new set of gains and sample rate yields the following constant coefficient difference equation. This final equation is easily implemented with only bit shits, 0.5 being a single bit shift to the right for divide by 2 and 0.25 requiring two bit shifts to the right for a divide by 4.

Y(k) = 0.5 * C(k) – 0.25 * C(k-1) + Y(k-1)

The C code listing for the algorithm is as follows:

for (;;)/* loop forever */

{

if(TIFR & 0x02) // if timer overflow (every .500 millisecond )

{

TIFR |= 0x02; // clear overflow flag

TCNT0=56; // reset counter for 200 counts to overflow (1 ms period)

PORTB|=0x10;
Ck=0;
ADMUX=0x61;	// select channel 2, current setting
ADCSR=0xC2;	// start single conversion, with
CK/4,
while(ADCSR & 0x40);
	// wait for conversion complete
Ck+=ADCH;
ADMUX=0x62;	// select channel 1, current feedback
ADCSR=0xC2;	// start single conversion, with CK/4,
while(ADCSR & 0x40);
	// wait for conversion complete
Ck-=ADCH;	// Ck=setting - feedback (error)
if(Ck1==-1) Ck1=0;
Ck1=Ck1/2;		// divide previous error by 2
Yk=(Ck/2-Ck1/2)+Yk1;		// +/- 7FFF
if(Yk<0) Yk=0;		// no negitive output
if(Yk>0x00FE) Yk=0x00FE ;		// Maximum output is 0xFF
Ck1=Ck;	// save error for next iteration
Yk1=Yk;	// save result for next iteration
OCR1A=(char)Yk;
PORTB&=0xEF;
}

}

Actual performance of the supply at the worst case condition with a 1_ load is shown in figures 6 and 7. In figure #6 we look at the system at initial power up with a 1.0_ load. Here we see that we do not have the classical overdamped transient response characteristics. With a 1.0_ load a 3 Amp current requires only 3.0 volts across the load. A very small duty cycle from the 48 volt source is required to achieve this 3.0 volts. Small changes in such a low duty cycle result in significant swings in the output voltage and current. This is what makes the 1.0_ load case the most difficult. Figure #7 shows not only the transient case when changing direction of current flow but also the steady state current ripple. Although we are below the 10% limit at 3 Amps of 300 mAmps, we have significantly more ripple in the 1.0_ case then we have in the 15.0_ case shown in figure #8. At 1.0_ we see about 250 mAmps of ripple current while we have no measurable ripple in the same scale for the 15.0_ case under identical switching conditions. We also see much more of the desired overdamped characteristic in the 15.0_ load case.

www.atmel.com

page 20

A T M E L A P P L I C A T I O N S J O U R N A L

Figure 5

VI. Conclusions:

Although initial PSPICE simulation provided a good starting point for algorithm development, as well as inductor sizing and PWM frequency, there is still nothing quite like prototype testing. Computer simulation with PSPICE as with all simulation programs is only as good as the models and assumptions used. Care must always be taken with computer simulation to do a sanity check on the results and circuit breadboards and prototypes are still required to flush out all the issues. Minor tweaking of the algorithm was required to achieve stable operation over the required load range. The minimum 1.0_ load requirement proved to be the biggest hurdle as achieving stability at very low PWM duty cycles required a significant reduction in the proportional gain and increase in the sample rate. Heat dissipation on the main pass transistor was also a major challenge in this design. A P-channel MOSFET based design would have been simpler and less expensive but the larger die area and correspondingly higher parasitic capacitance of the P-channel devices results in slower switching times and greater heat dissipation. Higher switching frequencies have more turn on and turn off transient states generating greater heat dissipation in the pass transistor. We were able to overcome these obstacles in the final design and meet all the requirements in large part due to flexibility of the system architecture. Today’s low cost microcontrollers such as the Atmel’s AVR family make it feasible to do digital sampled data controllers where purely analog designs would have previously been used.

Selection of the Atmel ATtiny15L AVR microcontroller proved to be a good choice. It’s small footprint and peripheral set made it a good fit for this design. It seems that the ATtiny15L processor would also be a good choice for battery charging circuits which could make use of the same buck regulator topology. A current sense resistor between battery negative and ground allows feedback for constant current charging independent of any time varying load currents beyond the battery which would be supplied by the charger supply. There are sufficient A/D inputs to support battery voltage and temperature monitoring for –_v or _T rapid charge termination allowing multi-chemistry support for NiCd, NiMH or Li-ion type batteries. It is unfortunate that the ATtiny15L is not offered in a grade that provides a laser trimmed voltage reference. At present, the on board voltage reference has insufficient accuracy to be useful in either the constant current supply or battery charging applications. Even though laser trimming of the voltage reference would add some cost to the part, the increase would be less then the addition of an external voltage reference with the required accuracy. PCB real estate would be saved and total parts count would be reduced with its associated parts stocking fees and carrying costs. Because of the lower current levels used in portable battery operated systems many battery charging applications could make use of the internal differential amplifier even with its limited gain choices. Lower currents allow for a broader selection of potential load sense resistor values without being driven to a high wattage part. Perhaps Atmel will consider offering a laser trimmed ver-

sion of the ATtiny15L in the future targeted at battery charging applications.

Figure 6

Figure 7

Figure 8

www.atmel.com

page 21

A T M E L A P P L I C A T I O N S J O U R N A L

Developing embedded applications often require significant and specific knowledge from the involved engineers. Typically, issues like realtime properties, timing bottlenecks, memory constraints, realization of hardware device drivers etc. all demands previous experience within embedded applications development in order to successfully finalize the application or project. The same actually applies for tools. The times where every embedded project could deploy any general tool on the market have passed. Today, tools for embedded projects need to be specific and customized for the problem domain and hardware devices selected.

RTOS vendors have already adapted towards this trend, and now also the graphical design and development tools that automate several processes in building and testing embedded software are becoming tar- get-specific.

High-level Tool Targeted for AVR Controllers

By Henrik Leerberg, IAR Systems

The tool vendor’s challenge

There are many good reasons for using tools and other 3rd party solutions when building a new embedded device. The fact that code generation technology has matured significantly during the recent years as well as emerging technologies for automatically being able to test the embedded applications, have all added to the number of reasons why corporations should seriously consider (re)investing in tools for new projects.

General purpose tools that cover everything from different analysis and design approaches to several flavors of code generation and languages, (here we can call them “case-tools”), as complex to learn, manage and use as a nuclear power plant, and will not meet the future demands of the embedded developers. The embedded developer requires tools developed for him and for the problems he is facing.

The embedded developer has up until now always been the last in line to get new tools to help building products. So far, many tool vendors have focused their energy on tools for mainframe-, PC-, administrative-type application development, and this is the world from where many of the existing tool vendors originate. However, some of them have been trying, and still try, to re-engi- neer their tools into serving the embedded developer’s needs, but this “conversion” will be tough for many – if not impossible. These vendors’ startingpoint is already off-track since their tools once were built for a completely other purpose and target audience. In that world, nobody had to worry about realtime issues, memory constraints and a few different operating systems to support. Thus, it was extremely difficult to try to squeeze all this “freedom” into a well-working tool solution for embedded projects deploying small scale microcontrollers.

UML with reliable, compact and targeted source code

The Unified Modeling Language (UML) with its real-time extensions is becoming a suitable approach for designing embedded real-time applications. However, it is not enough to view the nail from many different angels, if what you really want, is to hit the nail on the head in the best and fastest possible way. In this case, you need your design to be turned into an implementation through a fully automated process.

For this purpose, automatic code generation is the key, but automatic code generation from a UML design is not as trivial and straightforward as it might sound. Lots of details have to be consistent and precise in order to successfully convert a graphical representation to source code.

One of the hardest jobs is to generate fully functional and executable source code, which must not subsequently be modified by the software developer in order to get the embedded application running. This requirement must be combined with the constraints of small microcontrollers that are often used in embedded projects. Of course many embedded projects use 32-bit processors or higher, but just as many (if not more) realize the application using 8-bit or 16-bit chips. Small chips are typically easier to program and they cost less.

Another important factor is memory. Memory prices are continuously fluctuating so a company producing e.g. 1,000,000 units can save considerable amounts by trying to stay below a 32 Kbytes limit instead of selecting a 64 Kbytes module.

The automatic code generation facility of visualSTATE is built around a principle of having as much production-ready code available as possible to the developer at all times. By the term production-ready code we mean code generated by the tool that is directly capable of fitting into even the smallest controllers on the market, and at the same time having real-time properties. This also means that the code is not made for simulation purposes for example, although it handles this purpose very well too.

The code is very compact, but just as important is that the code size increases linearly compared to manually written code which has a tendency to increase exponentially the more complex it gets (see picture). Of course this also means that applying the automatically generated code for very small and non-complex applications (below 4 Kbytes of code) normally does not offer efficiency gains because the overhead and relative code size will exceed the overhead and size of manually written code.

The automatically generated code produced by visualSTATE carries a digital signature, which can be embedded in the source code. This means that maintaining and bug fixing already released versions becomes easier because it is always possible to track and trace the exact model from which the code was generated.

Embedded tools for embedded engineers

Embedded engineers should be able to purchase and deploy tools that are specified and verified by embedded engineers, and which only require a lerrning curve compared with lerrning a general spreadsheet program.

In today’s tool market there exist some, but few, tools that originate from the embedded world. One of these tools is IAR Systems’ visualSTATE for Atmel AVR controllers.

www.atmel.com

page 22

A T M E L A P P L I C A T I O N S J O U R N A L

This product focuses on providing an embedded tool solution for embedded engineers, who wish to deploy a visual programming approach, while still being able to use even the smallest micro controllers available in their projects.

Picture: IAR visualSTATE for Atmel AVR

IAR visualSTATE for AVR offers a full UML compliant statechart design environment, where control related problems can be described and maintained.

Included with visualSTATE for AVR is also a comprehensive test suite that includes formal, manual and on-target debugging and testing capabilities. Furthermore, visualSTATE provides a unique code generation engine, that is built for embedded devices and supports both C and C++ implementations. Full Microsoft Word or HTML formatted reports can be automatically generated, which again ensures that code documentation is always up-to-date and easy to create and maintain. All-in-all IAR visualSTATE supports the embedded project in its entire life-cycle, from birth to death.

IAR visualSTATE for AVR is developed for corporations, which are project oriented rather than department oriented. This basically means that IAR Systems is able to deliver a low-cost turn-key solution for most projects, eliminating or at least reducing the rather large investments in both time and money, which are normally required when searching for productivityand quality improving tools for the next embedded project.

New Atmel Design Contest!

When you choose an Atmel AVR microcontroller to jumpstart your entry to AVR Design 2004, your finished design becomes a gateway to incredible rewards. Not only will you be a “winner” for choosing one of the fastest, smartest, and the most readily supported microcontrollers in the world, your design will be in the starting lineup to be reviewed by leading industry experts. Our judges will be giving their full attention to your entry as they decide which designs promote the truly innovative spirit of the AVR microcontrollers.

Much like the capabilities of the Atmel AVR family of microcontrollers,

your contest entry options are nearly unlimited. Simply present us with a working design that demonstrates your mastery of microcontroller imagination. Then prepare yourself for one wild ride – winning entries will be posted or published in Circuit

Cellar, and prizes will be awarded in a variety of categories. Enter today.

Start your journey today towards a successful design at: www.atmel.com

Coming in March

R

© 2004 Atmel Corporation. Atmel and the Atmel logo are registered trademarks of Atmel Corporation.

www.atmel.com

page 23

A T M E L A P P L I C A T I O N S J O U R N A L

TheThe semiconductorse iconductor industryindustry isis movingoving towardsto ards nanoscalenanoscale technologytechnology withith ICIC transistortransistor countscounts attainingattaining thethe hundredshundreds ofof millionsillions.. SystemsSyste s--onon--chipchip areare reachingreaching aa levellevel ofof comcom-- plexityplexity atat whichhich itit isis essentialessential toto testtest andand debugdebug thethe hardhard-- wareare andand softwaresoft are ofof thethe entireentire systemsystem atat operationaloperational speedspeed beforebefore incurringincurring thethe maskask costscosts forfor prototypeprototype fab- fabricationrication. The. Theuseuseof ofarchitec- architectureture pla formsplatformsand systemand systemprototypingprototypingbased onbasedFPGA- onbasedFPGAemulation-based emulationpl f rms are platformsthe cornerstonesare the of the pre- cornerstonesfe r d methodologyof the preferredfor methodologyachieving thisfor. Atmel“’sachieving thisM tral. Atmel’smulationMistralboard for emulationARM9-basedboardsystemsfor-on-chip ARM9combines-basedflexibility,systems-onperform-chip - combinesance and easeflexibility,of use to reduce performancedesign cycle andtimeseaseandof useincreaseto reduceconfidesignence incycleobtain- timesing rightand-firstincrease-timeconfidencesilicon.

in obtaining right-first-time silicon.

Atmel®’s Mistral

Emulation Platform for ARM9™ Core-based SoCs

By Peter Bishop, Communications Manager, Atmel Rousset

Atmel’s FPGA-based emulation board code-named Mistral (Figure 1) is targeted principally (but not exclusively) at SoC designs built around ARM9

Outstanding architectural features at board level include the flexible combination of onand off-board memories. Clocking is either via an external input or an on-board crystal giving multiple programmable clock sources. Simple user inputs (push-buttons, DIP switches and rotary selectors) are carried directly to FPGA inputs. User outputs include LEDs and a general-purpose user I/O connection block. The on-board physical interfaces (PHYs), ADCs/DACs, level shifters, amplifiers and line adapters support plug-and-play connections to a range of industry-standard communications channels (Ethernet, USB 1.0, 2.0 and On-the-Go (OTG), CAN, serial, two-wire interface (TWI) and quad-wire interface (QWI) as well as speaker output and microphone/audio line input).

Figure 1: Atmel’s Mistral FPGA-based Emulation Platform for SoC Development

(ARM926EJ-S™ or ARM946E-S™) microcontroller cores together with one or more DSP cores such as the Teak® from ParthusCeva.

Mistral’s objective is to provide a maximum of flexibility in the SoC architecture while preserving rapidity of implementation. This is achieved by mounting the MCU/DSP cores on separate mezzanine boards for single/dual/multiple MCU/DSP architectures. A large number of on-board interfaces and memory blocks cover industry standards such as USB 2.0, Ethernet 10/100, etc. Extension sockets allow these to be complemented by external components. An external man-machine interface (MMI) board copes with most conventional user interfaces such as LCD screens and keypads. A sophisticated onboard clock generator provides for most clocking schemes that may be required.

Extensibility of Mistral Board

The Mistral board is designed to be as flexible as possible for immediate use in a wide variety of SoC design projects. A principal way of achieving this is the range of extension boards that can be connected directly to it.

The extension connectors on the periphery of the board enable mezzanine boards (described below) to be attached. They are also arranged in such a way that two or more Mistral boards can be directly plugged together in order to function as a single unit.

Mistral Architecture

Figure 2 gives further details of the Mistral architecture at board level.

The central FPGA can emulate the equivalent of 500K ASIC gates, sufficient for the application-spe- cific logic of a broad class of SoCs. However, if the resources of a single Mistral board are insufficient, two or more can be connected together by high-

speed connections that result in very little perform-

ance degradation. Figure 2: Mistral Block Diagram

www.atmel.com

page 24

A T M E L A P P L I C A T I O N S J O U R N A L

As shown in Figure 3, the main components of a typical man-machine interface (MMI) (keypad, LCD display, etc.) are mounted on a separate MMI board. If a different MMI is required for the application, a different MMI board can be constructed and substituted. Further customization is possible by connecting an external bread-board.

Figure 3: Mistral Man-Machine Interface (MMI) Board

ARM946E-S Mezzanine Board

In order to give a choice of MCU/DSP cores for the SoC architecture, these are mounted, together with local memory, on separate mezzanine boards. The board for the ARM946E-S 32-bit RISC processor is shown in Figure 4. Its architecture is illustrated in Figure 5.

The ARM9 mezzanine boards feature Trace and JTAG ports for system interrogation and debug. An on-board fast SSRAM is used for shadow ARM9 code and data workspace.

The high-speed connection to the Mistral board (that emulates the ARM peripherals) is rapid enough for MCU-peripheral data transfers to be made at close The JTAG switchbox shown in Figures 5 and 6 is configurable under FPGA control. It gives a high degree of flexibility in the implementation of JTAG schemes, including software-configurable JTAG chaining topologies.

Figure 4: Mistral ARM946E-S Mezzanine Board

Other Mistral MCU mezzanine boards, notably for the ARM7TDMI® and ARM926EJ-S™, are under consideration. At present the ARM7TDMI is emulated by using Atmel’s previous-generation POD+ emulation board.

	Trace		Address	1M x 32-bit
				Fast
	Connector
			Data	SSRAM
	(ETM)	ARM920T or
		ARM946E-S
		MCU
	JTAG	Switchbox	Control
	Connector
				SSRAM &
				Digital PLL
		Switch		Controller
				(CPLD)
		Digital PLL
		Clocks		User DIP
		High-speed Connections		Switches
		Connection to Mistral Board

Figure 5: Mistral ARM9 Mezzanine Board Block Diagram

	Trace		Address	1M x 32-bit
				Fast
	Connector
			Data	SSRAM
	(ETM)	ARM920T or
		ARM946E-S
		MCU
	JTAG	Switchbox	Control
	Connector
				SSRAM &
				Digital PLL
		Switch		Controller
				(CPLD)
		Digital PLL
		Clocks		User DIP
		High-speed Connections		Switches
		Connection to Mistral Board

Figure 6: Mistral Teak DSP Mezzanine Board Block Diagram

Development Tools for an Emulation Platform

Netlist Partitioning and Synthesis Tools

The SoC design that is to be emulated is developed and integrated using standard CAD tools. The starting point is a netlist of the entire design at register transfer level (RTL) in Verilog or VHDL. Prior to mapping this netlist onto the emulation board, the design must be partitioned into elements that are to be mapped onto the FPGA, and those such as MCU/DSP cores, memories, analog blocks, etc. that are to be mapped onto other ICs on the Mistral board or its mezzanines. The two internal elements of the design that may require special treatment are the clock tree and the memory blocks. These may require modification to map correctly onto the clock buffer architecture and synchronous SRAM resources of the FPGA. Once this partition has been determined, an FPGA top-level wrapper is designed, together with an appropriate pin assignment.

This preparatory netlist partitioning may be done manually, or a tool such as APART™ from Astek may be invoked. APART assists in changing the design topology for parts that are external to the FPGA, and can be used for architecture splitting in cases where the design is too large for a single FPGA.

When these preparatory steps are complete, the netlist is synthesized targeting FPGA gates using a tool such as Synplify® from Synplicity®. FPGA placement and routing is then performed using the Xilinx ISE Logic Design Tools.

Operating System Considerations

A microcontroller-based SoC requires a suitable operating system to deal with such issues as task scheduling and prioritization, efficient memory manage-

www.atmel.com

page 25

A T M E L A P P L I C A T I O N S J O U R N A L

Contact: Peter Bishop, Communications Manager, Atmel Rousset, France,

Tel: (+33) (0)4 42 53 61 50, e-mail: [e-mail]

ment and interrupt handling. It also presents a virtual system interface to application software modules. The choice ranges from open-source operating systems such as Linux® to proprietary, high-performance real time operating systems. The former has the benefit of minimal cost and support from the worldwide Linux community. The latter have been specifically designed to take advantage of the advanced features of modern RISC architectures like the ARM9. Whatever operating system is selected, the emulation phase gives the opportunity to load and test it, and investigate any problems in the hardware/software interface of the system.

IPITEC Janus SoC Design Example

An example of the use of the system prototyping methodology is the emulation of the SoC for advanced signal processing applications code-named Janus, developed by Atmel’s subsidiary IPITEC. As illustrated in Figures 7 and 8, Janus is built around an ARM7TDMI architecture for overall control and peripheral interfacing. It incorporates a Magic DSP core, a highly parallel floating-point digital signal processing unit based on very large instruction word (VLIW) design principles.

Emulation of the Janus SoC requires a Mistral board for the Magic DSP core and a separate POD+ emulation board (Mistral’s predecessor) for the ARM7TDMI core and peripherals. The two are connected by a high-speed VMEstyle connection.

A small number of modifications are required to the Janus RTL code in order to map it onto the FPGAs. These included the transformation of ASB unidirectional buses of the target system onto the ASB bidirectional buses on the emulation board. The multi-port register files (4 read plus 4 write ports) in the Magic DSP are emulated by a dual-port RAM over-clocked by a factor of 4. Similarly the 80-bit external bus interface is emulated using a 36-bit bus over-clocked by a factor of 4. Internal program memory is downsized by a factor of 4.

Atmel’s Mistral emulation platform combines flexibility, performance and ease of use in order to make this step as rapid and effective as possible. It is a major contributing factor to right-first-time silicon delivered in short timescales. It also contributes to the long-term evolution of a product as a platform for in-service debug and development of new versions of the system architecture and software.

		ARM7TDMI	Buffer	Magic
		Processor	Memory	DSP
			ASB
		Advanced
		Interrupt	External Bus Interface
		Controller
		Peripheral	Bridge
		Data
		Controller
			APB
		Serial Peripheral	Timer
		Interface
		Serial Peripheral	Watchdog Timer
		Interface
	PIO	USART	Clock	PIO
			Generator
		USART	ADC/DAC
			Parallel I/O Controller

The target system (on silicon) is designed to run at 100 MHz. This is not							Figure 7: Janus System Architecture
achievable on the emulation system, but the scaled-
down clock speeds are adequate to test and demon-
strate the performance of the system. On the POD+			Data Flow					VLIW Program Memory
board the ARM7TDMI core and peripherals are clocked
at 5 MHz. On the Mistral board, the Floating Point
Unit and internal memories are clocked at 10 MHz.			Instruction/					Modular VLIW Program Word
			Control/
			Address
The two Register Files are clocked at 40 MHz, as is			Flow				Flow	Register File	Multiple Address	Arithmetic
the access to external memories. Even at these							Control	Address	Generation Unit Field	Operators
reduced clock frequencies, the emulation system
achieves a computational throughput of 100 Mflops.								Flow Control and VLIW Decoder Unit

				Instruction	Condition	Status		Program
To give some idea of the complexity of this project,				Decoder	Generation	Register		Counter
the mapping of the Janus architecture occupies more									Memory
than 80% of the FPGA resources of the Mistral board.									Input
									Remote
									Buffer,
							Read Data		FPU
									Buffer,
Emulation is the only way of investigating and testing									Peripherals
					Multiple
the hardware and software performance of a highly				16-port Data
					Address	Left
complex SoC like Janus before fabrication. The emu-				Register File	Generation		Right
					Unit	Read
lation system is used for demonstrations of potential						Addr	Read
							Addr
applications, as well as for developing the hardware					8-port	Left Dual-		Right Dual-	ASB Interface
					Address	port Data		port Data
					Register File	Memory	Right	Memory
and software of subsequent versions of the product.						Write
						Left	Write
						Addr	Addr
				Operator
Conclusion				Block
		increase in	transistor count and
As systems-on-chip									Memory
									Output
complexity,	with	embedded	microcontroller/DSP				Write Data		Remote
									Buffer,
cores and significant software			content, architecture						FPU
									Buffer,
and emulation platforms are becoming essential ele-									Peripherals
ments in the design flow to validate all aspects of the				Figure 8: Magic DSP Core Architecture
hardware and software before prototype fabrication.

www.atmel.com

page 26

A T M E L A P P L I C A T I O N S J O U R N A L

The CryptoMemory familyi utilizesi i Atmel’s’s proven EEPROM technology

for all ninei devices,i , rangingi inin sizei from 1K1K bitit to 256K bitsi ..

Low-cost,

High Security Solution

By Mary Jarboe, Atmel

CryptoMemory® Cryptographic Security ICs from Atmel offer a low cost, high security solution for any embedded application requiring data protection. A proprietary cryptographic algorithm encrypts data, passwords and checksums, providing a secure place for storage of sensitive information within a system. With CryptoMemory’s tamper-protection circuits, this information remains safe even under attack. Atmel’s CryptoMemory offers a secure solution for protecting factory configuration data, user preference data or encryption keys.

The CryptoMemory family utilizes Atmel’s proven EEPROM technology for all nine devices, ranging in size from 1K bit to 256K bits. Memory is divided into zones to help organize data or store different data with different security levels and keys. Security features are user-configurable by memory zone, giving the flexibility needed to bring security to any application.

Atmel developed the CryptoMemory family after many years of designing chips for the smart card marketplace, a market where security is key. The same techniques used to keep information safe from attack in smart cards are now available to the embedded market. The device includes a proprietary algorithm for encrypting data and passwords and providing a MAC for read and write operations. Access to data stored in the device is also protected by an authentication routine. Various security options are available, including four unique key sets for authentication and eight unique password sets. Encryption is performed using a new session key each time the device is accessed.

Atmel is the only manufacturer to offer this level of security in a memory device. To make it convenient and fast, a common 2-wire serial interface running at up to 1.5 MHz is utilized. CryptoMemory is available in popular 8-lead SOIC, PDIP and LAP packages having the same pinout as Atmel’s AT24Cxxx Serial EEPROMs.

CryptoMemory Cryptographic Security ICs

Device	Memory Size	Memory Zone
AT88SC0104C	1K bit (128 bytes)	4
AT88SC0204C	2K bits (256 bytes)	4
AT88SC0404C	4K bits (512 bytes)	4
AT88SC0808C	8K bits (1K byte)	8
AT88SC1616C	16K bits (2K bytes)	16
AT88SC3216C	32K bits (4K bytes)	16
AT88SC6416C	64K bits (8K bytes)	16
AT88SC12816C	128K bits (16K bytes)	16
AT88SC25616C	256K bits (32K bytes)	16

For more information on Atmel’s CryptoMemory family, visit www.atmel.com/products/SecureMem.

Atmels’ CryptoMemory chip

www.atmel.com

page 27

A T M E L A P P L I C A T I O N S J O U R N A L

Atmel'st l's AT76C503A isis a singlei le--chipip USB con-- trollert ll thatt t providesi

allll thet processingi and functionalityf ti lity requiredi forf thet Mediaia Access Controlt l (MAC)( ) protocolt l off wirelessi l LANsL att up toto 1111 Mbps.. ItIt focusesf

on,, butt isis nott limitedli it toto thet IEEEI 802..11b11b (Wi( i--Fi)i) standardt .. The AT76C503A providesi a gluelessl l interfacei t f conformingf i toto thet 1212--Mbps Universali l Seriali l Bus (USB)( ) specificationifi ti and can controlt l a varietyi ty off wirelessi l physicali l interfacesi t f .. ItIt integratesi t t Wiredi Equivalenti l t Privacyi

(WEP)( ) inin hardware,, supportingti bothth 64--bitit and 1281 --bitit encryptionti ..

USB Wireless LAN Media

Access Controller

Local Area Networks Background: Wired and Wireless

A local area network (LAN) is a communications medium for PCs and shared resources such as printers, file servers, communications ports and other computer devices in the same vicinity. Typically, a LAN covers a building or a campus.

Wired Ethernet

The most common architecture for LANs is the Ethernet using coaxial, highquality twisted pair or fiber optic cabling, connected in a branching structure (Figure 1). Most Ethernet-type networks operate at 10 or 100 megabits per second (Mbps), but gigabit Ethernets are coming into operation. The protocols for the network configuration and data transmission/reception over an Ethernet are formally described in the IEEE 802.3 series of standards.

Figure 1: Ethernet Architecture

Devices on an Ethernet communicate using a protocol called Carrier Sense Multiple Access with Collision Detection (CSMA/CD). No central coordination or control is required. Each device has a unique Internet Protocol (IP) address. A device that has data to transmit waits until the communication medium is quiet and then sends a sequence of data packets in a standard format. All other devices on the network receive the packets, but only retain those that are addressed to them. If two devices start transmitting at the same time, they are able to detect a collision on the medium, and wait for a random time interval before re-trying transmission.

This anarchic protocol has numerous benefits, notably the ease of setting up an Ethernet, and the ability to attach and detach devices at any time without having to re-configure the network. The easy implementation, along with the relatively low cost of Ethernet interface cards and cabling, are the major factors in the acceptance of the Ethernet as the worldwide standard for LANs today.

Wireless LAN (WLAN)

Building on the success of the wired Ethernet, as described before, an architecture has been developed for an equivalent network based on wireless connectivity. This has been formalized in the IEEE 802.11 (Wi-Fi) series of standards. A wireless LAN (WLAN) following these standards uses Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA), an access protocol more sophisticated than CSMA/CD. Each of the devices on the network estimates when a collision is likely to occur and avoids transmission during these times. CSMA/CA eliminates the requirement for collision detection hardware, thereby reducing costs.

Figure 2: Wireless LAN Peer-to-peer or Ad-hoc Network

An IEEE 802.11-based wireless LAN has the same advantages of decentralized control and flexibility to introduce/withdraw devices as a wired Ethernet, together with an equivalent data transmission rate. It overcomes the inconvenience and cost of network cabling, and is particularly suited for portable PCs, PDAs and similar hand-held devices.

A simple configuration of a wireless LAN between a small number of devices is a peer-to-peer network (also called ad-hoc network) as shown in Figure 2. A more sophisticated wireless LAN may be connected to a wired LAN through an access point (also called a bridge) that permits the WLAN devices to share the same resources as the wired LAN devices. This is usually called an infrastructure network (Figure 3).

Figure 3: Wireless LAN Infrastructure Network

A wireless LAN that follows the IEEE 802.11 standard can extend over tens of meters indoors and hundreds of meters in open air. It is not confined to a sin-

www.atmel.com

page 28