Home

cover feature

1. wa ea m FPGA band calibration testbench segment REF signal source Figure 1 e Push button reset display PLLIILIIIS Proto pin for viewing on scope d 24 MAY 2010 embedded systems design www embedded com function and gives a fractional resolu tion of REF 24 sigma delta accumu lator bits Frequency synthesizers multiply a fixed frequency crystal oscillator up to the required frequency The PLL acts as a closed loop negative feedback system to implement this exact multiplication The job of the MMD is to divide the frequency of the VCO output by the in teger value N The phase of this signal is com pared with the phase of the reference and the difference in phases is filtered to remove high frequency components The filtered signal is used as the voltage control of the VCO If there is any phase difference between the output of the MMD and the reference the con trol voltage at the VCO will adjust to correct that phase difference For the application at hand the synthesizer needed to create frequencies from 3 000 to 4 000 MHz Continuous tuning of the VCO is accomplished by changing the bias voltage across a var actor which is part of the parallel in ductor capacitor LC resonant circuit The fabrication technology limits the con
2. sgnedness 1c Dc Code Cibecurity repiscement bet needs parentheses Macro parameter not n bracuorts Metro contains unscceptable items 4 kune amp and formal parameters inconsistent MR 4 al a C Ha E lurezgned omer aon without cast Ggned unegnad meso without cast H 2 Type conversion without cast Bp tect conversion to fond parom Use of numen teal im expresion Use of banned function or variable parameters inconsistent E gt Signed unsigned conversion without cast Signed unsigned conversion without cast Signed unsigned conversion without cast W 2 Type conversion without cast Processing File Etltirrkils ssgnedness 1 1 qih Processing File Completed Code Review Started ssgnedness 1 0 lode Sample Cisecurnty with the C CERT standards modelis implemented Code Review Completed Figure 2 www embedded com embedded systems design Mandatory Mandatory Mandatory Mandatory MAY 2010 21 Ae SEGGER Ls TIT ie 11 de E tin it an debugger J Link GDB Server is a remote server for GDB J Li ash Brez EI jnlimi Ue E lt and its OEM deriva Set are happy to inform you software also Tel QAM the JTAG Link Atm IAR J Link KS Secure coding in the iterative lifecycle
3. Learn today Design tomorrow VOLUME 23 NUMBER 4 MAY 2010 EMBEDDED SYS STEMS DE DESIGN The Official Publication of The Em Using an FPGA to test a PLL band calibration algorithm Object code generation fix Ganssle More on test driven development Protect ag malicious SOF 16 MR exi Let oday Design tomorrow re Embedded Systems Conference Chicago Donald E Stevens Convention Center Conference June 7 9 2010 Expo June 8 9 2010 e ie One Size Doesn t Fit All R With HCC you can choose a file system that s e File Systems right for your application HCC products run e USB Stacks with the broadest range of CPUs and memory e Bootloaders devices with or without an operating system Windows Drivers e Embedded Development Services www hcc embedded com info hcc embedded com INTEGRITY RTOS has it No one else does CO National Information Assurance Partnership LL Common Criteria Certificate S This coniaim realis is awarded to kaz kr rire reni EE ae Rwan Inc eid asia 207 Sar r silam ETE Meer The IT produc ig assurance security specifications ze with the provisions of the ing laboratory in the evaluation ndorsement of the IT product esed or implied j International Corpor
4. Requirements traceability Requirements Analysis and design Initial Secure codes standards Planning enforcement quality and testability Implementation Automated testing unit Planning Configuration and change management Test and metrics reporting Evaluation Testing Deployment Test completeness verification Figure 3 all of the solutions It s not surprising that the processes for building security into software echoes the high level processes required for building quality into software described above BUILDING SECURITY It s not surprising that the processes for building secu rity into software CERT C Secure Coding Guidelines and CWE dictionary static analysis tools echoes the high level processes required for building quality into software Adding security considerations into the help make this objective both practical process from the requirements phase and cost effective Combine this with onwards is the best way of ensuring the the improved productivity and accura development of secure code as de cy of requirements traceability unit scribed in Figure 3 High quality code testing and dynamic analysis and the is not necessarily secure code but se elimination of exploitable software cure code is always high quality code weaknesses become inevitable An increased dependence on inter net connectivity is driving the demand Nat Hillary is a field applicati
5. Advertising Coordination and Production 600 Community Drive Manhasset NY 11030 Donna Ambrosino Production Director 516 562 5115 dambrosi ubm us com developed whatever the official process may be The Heretic Software Department Editor s note James Grenning responds at www embedded com 224200702 We welcome your feedback Letters to the editor may be edited Send your comments to Richard Nass at rich nass ubm com or fill out one of our feedback forms online under the article you wish to discuss An interview with James Grenning Part 2 ames Grenning www renaissance software net whose book Test Driv en Development in C will be out in the fall graciously agreed to be inter viewed about TDD test driven devel opment The first part of our talk ran last month at www embedded com 224200702 where you can also see reader comments Jack How do you know if your testing is adequate TDD people heck practically everyone in this indus try don t seem to use MC DC npath or cyclomatic complexity to prove they have run at least the minimum number of tests required to ensure the system has been adequately verified James You are right TDD practi tioners do not generally measure these things There is nothing said in TDD about these metrics It certainly does not prohibit them You know we have not really defined TDD yet so here goes This is the TDD micro cycle e Write a small test
6. bounce cause the algorithm to start over repeatedly when the switch stops bouncing the BCAL operates normally The 8 bit band value was mapped to two 7 segment displays on the FPGA board to display the final band value in hexadecimal The BCAL algorithm finishes in 146 us 7 230 11 MHZ so only the final value appears to a human observ er The readout made it easy to compare against the theoretical value from the Simulink model In this way the BCAL algorithm was pass fail tested for 50 possible frequencies from its minimum to maximum band values POTENTIAL PITFALLS AND TIPS One of the challenges of this particular design was its asynchronous nature The frequency of the NCO clock changes during the band calibration and some logic elements in the BCAL depend on the timing of the edges of that clock Likewise other logic ele ments change synchronously to the ref erence clock edges The FPGA design software is not conducive to asynchronous design It s not impossible to make an asynchro nous design but don t be surprised if you have to look through documenta tion on a collection of warnings to de termine if your code does what you in tend Since the reference frequency never changes the design was modified to make all the data paths synchronous to the reference clock When the data path needed to jump clock domains it was retimed with cascaded registers to minimize metastabili ty Similarly another pitfall was n
7. this can be extremely important The AreIndependent function ignores the volatile attribute of both in structions and thus reports that it s OK to rearrange these instructions Listing 3 void ChangeMOVOrder Instr inst1 Instr inst2 1 Do other processing first E Bug detection code if IsVolatile inst1 IsVolatileCinst2 ReportSourceStatement inst1 ReportSourceStatement Cinst2 return if CArelndependent instl inst2 ChangeOrderHelper instl inst2 As noted the scheduler can of course choose to leave two independent instructions in place For this customer it s easy to see that he has at least one lo cation that is affected by this bug but One remedy a special version of the original compiler can try to identify all code in the user s code base that is affected by the bug does he have more affected locations Finding that out effectively amounts to going through the complete code base looking for accesses to volatile variables and examining the generated code so we re back to the central theme of this article how can the customer s change management be simplified Here is one possible remedy to the situation a special version of the origi nal compiler can try to identify all code in the user s code base that is actually af fected by the bug Here 1s how the compiler can be turned into a bug detector The function in Listing 1 is used in another function Listing 2 that
8. C and write it so that it picks out the specific registers that it needs A call to the function looks like UART put UARTO c 14 MAY 2010 embedded systems design www embedded com For device operations that use more than one regis ter you can pass just the address of the entire register collection rather than individual registers which is just a tad simpler than it was before Plus you can t accidentally mix registers from two UARTS at once Using structures avoid other mistakes as well Each struct is a truly distinct type You can t accidentally convert a pointer to timer registers into a pointer to UART registers You can only do it intentionally using a cast Thus compilers can easily catch accidents such as timer disable UARTO UART put the timer c compile error compile error One of the problems with using structures to model collections of memory mapped registers is that compilers have some freedom to insert unused bytes called padding after structure members You may have to use compile switches or pragma directives to get your struc tures just so You can also use com pile time assertions to verify that the structure members are laid as they should be CLASSES ARE EVEN BETTER In C using a class to model hard ware registers is even better than us ing a struct I ll show you why over the coming months BM ENDNOTES 1 Saks Dan Mapping Memory Embedded Syst
9. also reduces the overall memory footprint required by the system A side by side comparison of a handset that was virtualized by Open Richard Nass rich nass ubm com is the editorial direc tor of Embedded Systems Design maga zine Embedded com and the Embedded Systems Conference Kernel Labs OK Labs for short shows a significant cost savings up to 46 over a similar nonvirtualized de sign The biggest savings comes from being able to eliminate the applica tions processor which could cost as much as 30 depending on the re quired performance functionality and feature set of the handset Eliminating that apps processor reduces the memory footprint there by savings a few dollars The only ad ditional cost to the BOM comes in the way of the hypervisor needed to do the virtualization which is where OK Labs comes in They provide that hy pervisor software One example of a handset that was virtualized using the OK Labs technology is the Motorola Evoke It employs an embedded hypervisor from OK Labs called the OKL4 note that the Motorola Evoke will be the object of an upcoming Tear Down ar ticle where we really get into the nuts and bolts of how the handset was de signed with a particular focus on the virtualization aspect The bottom line is that you shouldn t dismiss virtualization tech nology as just being for high end de vices You could be missing an oppor tunity to reduce your BOM and ultimat
10. changes the order of two instructions when that function has de cided that it is beneficial to do so www embedded com embedded systems design This function can be changed to de tect the bug case in other words when the ChangeMOVOrder function uses the wrong information to make a deci sion The added code in red in Listing 3 looks for the offending situation and when such a situation arise it reports the affected source locations Note how the code in red would also cure the bug because it classifies all MOV instruc tions with the volatile attribute as de pendent But it is crucial to understand that we could not have placed the detec tor code in the buggy function If we would have done so it would report every occurrence of possibly erroneous instructions Even this simplified example showed us one of the pitfalls in creating a pro duction quality bug detector It can be simple to isolate the root cause of the bug but complicated to determine when this bug will actually result in the gener ation of wrong code We could for exam ple have a number of different functions of varying complexity that depend on the AreIndependent function But if it s practically possible to create the bug detector it can now be used to pinpoint the exact locations of any other code that is affected by the original bug In this way we can avoid going through all object code by hand to look for possi ble occurrences of the
11. has a monotonic tuning curve and can pro duce frequencies in the range 10 to 14 MHz which is approximately the PLL s reference frequency I built the BCAL model The BCAL algorithm works by racing two identical 10 bit counters One counter is clocked by the reference the NCO clocks the other Since they both start from 0 the first counter to get to a constant HIT_VALUE is clocked by the greater frequency To determine which count er gets to HIT_VALUE first each count value is continuously compared with the HIT_VALUE and the XOR of the two comparison results is used to clock a 1 into a D flip flop When both count values are less than HIT_VALUE the comparators both output 0 and the XOR result is 0 At the instant one of the values ex ceeds the HIT VALUE the XOR out put transitions to 1 and captures a 1 on the DFF output Sometime there after the other count value will get to HIT_VALUE and the XOR result re turns to 0 Another comparator is used to compare the reference counter to a constant RESET VALUE and when the count exceeds this value both counters are reset to 0 and the race be gins over again If the HIT VALUE is 230 a plausible RESET VALUE is 240 Meanwhile the bit of information about which clock was faster is used as input to a binary search block The binary search block holds the current band output value and deter mines what the next band value will be based on which clock won the race
12. some kind of instruction pipeline to increase performance by di viding complex instructions into 1 cycle pieces that are executed in their own pipeline stage In this way a throughput of one in struction per clock cycle can be achieved under ideal circumstances It is however very easy to break this if subse quent instructions are competing for the same resource An example is if the first instruction writes to a particular register and the directly following in struction reads from the same register On many pipelined architectures this will cause a so called pipeline stall that means that one cycle processing is in terrupted while the second instruction waits for the first instruction to finish writing to the register A good compiler for such a CPU ar chitecture will try to rearrange or sched void ChangeMOVOrder Instr instl Instr inst2 Do other processing first if CArelndependent instl inst2 i ChangeOrderHelper instil inst2 i 30 MAY 2010 embedded systems design www embedded com ule instructions so as to maximize the distance between instructions that use the same CPU resource in a pipeline blocking way To do such rearranging the compiler must build up one or more dependency graphs for the block of instructions it s about to schedule to determine if it is safe to move an instruction backward or for ward in the instruction stream The com piler uses a set of functions to determine if
13. tems often have complex requirements of their own Those requirements need to be captured independently of the code and need system level testing in dependent of any in code specification I think a certain personality type likes to pick apart the waterfall method and there are obvious arguments against it But so far it is the best tool going for managing complexity and risk in real world projects You can use TDD or OOD or whatever you need to use inside your waterfall block but your block has to be correct in relation to the other blocks of the project Larry Martin Owner www GlueLogix com One difference between embedded and other software is that physical systems often have complex requirements of their own TDD is a way to ensure that some analysis and design is being addressed up front but this article didn t cover all my concerns I ve seen a lot of projects run into trouble when integration occurs due to a lack of planning for integration of the units TDD doesn t seem to address this I also believe it s very beneficial to have independence in testing even at the unit test level It is too common for developers to write tests to prove their www embedded com embedded systems design code correct rather than to prove it in correct Under time pressure this be comes a subconscious driver It would be really easy to write soft tests in TDD as well Addressing this would probably result i
14. two instructions are independent which means that they do not use resources in a conflicting way and thus implicates that their order can be exchanged Let s take a look at a function that the compiler might use to determine if two MOV instructions are independent shown in Listing 1 This function looks innocent enough It basically shifts the question of independence to a helper function that determines if the source and desti nation of the MOV instructions are used independently It s perfectly OK for the compiler to leave the instructions together in the same order get the puzzle together with maximum performance as a result it might for example sometimes just cre ate a new pipeline stall by moving two instructions to avoid another stall Let s return to the function in Listing 1 and the compiler that uses this func tion When a customer compiles a cer tain program with this compiler it works flawlessly except that he notes that two memory writes are done in the wrong or der as opposed to how they are specified in the program Usually this is the princi ple that the scheduler is dependent on to perform its magic but in this case it s not OK because the user has specified that both variables that are affected by the instructions are declared as volatile which has implies that the or der of the writes should not change If for example the memory writes are in tended to initialize some external hard ware
15. 530 IP are T AU 18 INSTRUMENTS Debating test driven development ith respect to the guest Jack Ganssle An interview with James Grenning April 2010 p 35 www embedded com 224200702 he is an example of the kind of software person who focuses too much on the software itself and not enough on the whole system Consider The code specifies the behavior of the executable program in all its necessary detail That s a true statement but a mis leading one Only the target processor can read the code to the level of preci sion needed to answer key questions like What is the maximum travel of this actuator or What is the maxi mum RPM of this motor Therefore human reading of source code is no substitute for a concise accurate top level specification which feeds both im plementation and system test activities Here s an example Some years ago I heard about a software related inci dent at an automated sawmill The tar get processor was 16 bits and the soft ware was calibrated in 001 inch units The first log that came through the sys tem with diameter greater than 32 767 inches caused a reversal of some actua tor that broke stuff and injured the op erator So code may equal design but in this case something more explicit was needed I daresay that TDD style unit testing would not have caught that problem either One difference between embedded and other software is that physical sys
16. ARTS serial ports each of which employs a small collection of device registers The timer registers start at location OxFFFF6000 The registers for UARTO and UARTI start at OxFFFFD000 and OxFFFFEO000 respectively For simplicity let s assume that every device register is a four byte word aligned to an address that s a multiple of four so that you can manipulate each device register as unsigned int Many programmers prefer to use an exact width type such as uint32 t Types such as uint32 t are defined in the C99 header stdint h I prefer to use a symbolic type whose name conveys the meaning of the type rather than its physical extent such as www embedded com embedded systems design MAY 2010 9 2010 Actel Corporation All rights reserved Innovative Intelligent Integration St b Qe WW FOR NU 4 MU AN B WW 4 gt eS pe 95 ON 27 1 AXIR iD ji NY N 2 A EENG L ANI IX 38 MAN SMARTFUSION FPGA ARM Cortex M3 Programmable Analog Actel POWER MATTERS typedef uint32 t device register Device registers are actually volatile entities they may change state in ways that compilers can t detect I often in clude the volatile qualifier in the typedef definition as in typedef uint32 t volatile device register I ve often seen C heade
17. ORM WITH THE LEVEL OF PERFORMANCE YOU NEED TO HELP DELIVER CONNECTED DEVICES THAT STAND OUT WHICH WINDOWS EMBEDDED PLATFORM CAN HELP YOU DELIVER STANDOUT DEVICES FIND OUT AT WINDOWSEMBEDDED COM DEVICESTORIES orogrammer s pointers or as constant pointers timer_registers const the_timer timer registers OxFFFF6000 UART registers const UARTO UART registers OxFFFFDOOO In C using a reinterpret cast is even better timer registers const the timer reinterpret cast timer registers gt COxFFFF6000 UART registers const UARTO reinterpret Cast UART registers gt COxFFFFDOOO Whichever way you define the pointers you can use them to access the actual de vice registers For example you can disable the timer using the expression the timer TMOD amp TE Even better you can wrap it in an inline function inline void timer_disable timer_registers t t gt TMOD amp TE or a function like macro Zdefine timer disable t CCt gt TMOD amp TE Whether you use an inline function or a macro you can sim ply call timer disable the timer For device operations that use more than one register you can pass just the address of the entire register collection rather than individual registers Again sending data to a UART uses both the UART status register and the transmit buffer register You can declare the UART put function as void UART put UART registers u int
18. STRUCTURES Structures provide a better way to model memory mapped devices You can use a structure to represent each collection of device registers as a distinct type For example typedef uint32 t volatile device register typedef struct timer registers timer registers struct timer registers i device register TMOD device register TDATA device register TCNT 13 The typedef before the struct definition elevates the tag name timer registers from a mere tag to a full fledged type name It lets you refer to the struct type as just timer registers rather than as struct timer registers You can provide corresponding structures for each device type typedef struct UART registers UART registers struct UART registers device_register ULCON device_register UCON device_register USTAT device_register UTXBUF Using these structures you can define pointers that let you access device registers You can define the pointers as macros Zdefine the timer CCtimer registers OxFFFF6000 define UARTO CCUART registers OxFFFFDOOO Microsoft Vol 5 A MALFUNCTION IN THE SYSTEM COULD COST THE PLANT MILLIONS 95 Windows Embedded E EMBED THE DEVICE HAS 70 WORK PERFECTLY TO THE MICROSECOND AND HAVE THE CONNECTIVITY TO TRACK PERFORMANCE IN REAL TIME TH THEY RE COUNTING ON ME DELIVER WINDOWS EMBEDDED OFFERS A HIGHLY RELIABLE PLATF
19. The acceptance tests describe the definition of done for the story These acceptance tests are also automated If the new and all prior tests pass the story is done That is an important a quality gate Don t get me wrong I am a proponent of reviews but I think that is supe rior to inspections at preventing defects I did a case study on the Zune bug that illustrates my point This bug caused the 30G Zune model to freeze on New Year s Eve 2008 My informal re search on the bug www renaissancesoft ware net blog archives 38 showed that most online code pundits who inspected the faulty function did not correctly identify the whole problem I was in the group that got it almost right a k a wrong Then I wrote a test The test can not be fooled as easy a human So I think we need both inspections and tests Jack Some systems are complex or control processes that respond slowly What happens when it takes hours to run the tests James For TDD to be a productive way to work the micro cycle has to be very short in duration This pretty much rules out going to the target during the micro cycle and also that unit test exe If there is a lengthy con trol process being test driven we need to take control of the clock If we are managing dependen cies this is not hard cution must also be kept short To avoid the target bottleneck I rec ommend that TDD practitioners first run their unit tests in their develop
20. The binary search block either adds or subtracts the appropriate binary weighted value from its current out put For an 8 bit band the initial band value is mid range at 128 and seven consecutive races are conducted to fill in the 8 bits from MSB to LSB An ex ample run of the BCAL algorithm 15 shown in Figure 2 MAY 2010 25 The BCAL algorithm finishes in 146 us so only the final value appears to a human observer The BCAL algorithm was pass fail tested for 50 possible frequencies After building the band calibration algorithm in Simulink from logic gates comparators registers delays and look up tables the design was entered in the Quartus II software To make de bugging easier every wire in the Simulink model was named During the translation process I used the same names for signals in the Verilog code If a signal originated from a register or a delay in a trig gered subsystem in the Simulink model I made it a register in Verilog otherwise the signal was a wire Asa result the design entry from Simulink primitive subsystems to Verilog was straightforward In a manner similar to the testing done in Simulink all the submodules were simulated and verified in Quartus II After functionality was confirmed for the submodules a test schematic for the entire BCAL was made The test schematic includes the NCO which is controlled by the BCAL band output complete the loop the NCO output is
21. Y 2010 35 into a series of demonstratable bits of work that our customer cares about The product owner s team can add things to the backlog but in the end the authority of what goes into a specific it eration is the PO s responsibility For highly technical stories a hardware engi neer might play the role of the customer For manufacturability stories built in test for example a manufacturing engi neer or QA person might play the role of the customer You can see there may be many customers but the final call on what is worked on at what time is up to the product owner You also ask about estimating time and cost There is no silver bullet here but there is a realistic process Agile teams use When an initial backlog is created all the backlog items or stories are written on note cards and spread out on a table A story is not a specification but rather a name of a feature or part of a feature Engineers get together and do an estimation session Each story is given a relative difficulty on a linear scale The easiest stories are given the value of one story point All stories labeled with a one are of about the same difficulty A story with a value of two is about twice as dif ficult to implement than a one A five is about five times as difficult I am sure you get the idea Once all the stories have a relative estimate we attempt to calibrate the plan by choosing the first few iterations and adding up thei
22. a Time to Market Advantage The newest embedded and wireless products and technologies make designing even more fun Experience Mouser s time to market advantage with no minimums and same day shipping of the newest products from more than 400 leading suppliers a tti company mouser com 800 346 6873 Mouser and Mouser Electronics are registered trademarks of Mouser Electronics Inc Other products logos and company names mentioned herein may be trademarks of their respective owners THE OFFICIAL PUBLICATION OF THE EMBEDDED SYSTEMS CONFERENCES AND EMBEDDED COM Learn today Design tomorrow EMBEDDED SYSTEMS DESIGN VOLUME 23 NUMBER 4 MAY 2010 How to use an FPGA to test a PLL band calibration algorithm BY RUSSELL MOHN Prototyping an ASIC design first on an FPGA is not only useful for verification but allows more room for algorithm experimen tation Dealing with misbehaving tools BY ANDERS HOLMBERG When errors in object code are generated by your tools such as the compiler assembler and linker try this novel approach to the update tool or update source dilemma software design Bullet proofin BY NAT aq Applying secure programming standards and methodology can reduce vulnerabilities in software EMBEDDED SYSTEMS DESIGN ISSN 1558 2493 print ISSN 1558 2507 PDF electronic is published 10 times a year as follows Jan Feb March April May June July August Sept O
23. ation Product Name INTEGRITY 178B Separation Kel SAN SS s ment Protection Profile for menis Requiring High System RTOS version IN ICR750 0101 GH01 Re ee PCI version CPN 944 2021 021 w P The NSA has certified the INTEGRITY RTOS technology to EAL6 INTEGRITY is the most secure real time operating system available and the first and only technology to have achieved this level The NSA also certified INTEGRITY to High Robustness an even higher level of security than EAL6 with 133 additional security mandates over and above the 161 required for EAL6 When security is required Green Hills Software s INTEGRITY RTOS technology is the only option Green Hills Copyright 2010 Green Hills Software Inc Green Hills the Green Hills logo and INTEGRITY are SOFTWARE INC trademarks of Green Hills Software Inc in the U S and or internationally All other trademarks are the property of their respective owners WWW g hs com The Newest Products For Your Newest Designs Embed Your Innovation into the Market Place Y XBee and XBee PRO ZB Adapters mouser com digixbeeadapter Multi lech Systems Wincotech SocketModem iCell Cell Embedded ZICM2410P2 MeshConnect Module Wireless Modems mouser com celzicm2410p2 mouser com multitechicell A1084 B GPS receiver module mouser com vincotecha1084b WARNING Designing with Hot New Products May Cause
24. ation for functionality simulation for timing syn thesis fitting configuring the FPGA with the design and debugging When I tested the band calibration in real time I used the signal source and oscilloscope The binary search block holds the current band output value and deter mines what the next band value will be based on which clock won the race DESIGN AND PROTOTYPING PROCEDURE The design and prototyping procedure is the iteration of the following familiar steps 1 Design Entry 2 Test 3 Debug 4 Go To 2 This cycle is repeated as many times as necessary until the de sired functionality is reached First I built the NCO as a Simulink subsystem The NCO Simulink model was reverse engineered from the verilog for an NCO I found on the web at www mindspring com tcoonan nco v The NCO was based on a programma ble modulo counter Its output frequen cy equals Fs BAND STEP MOD where STEP and MOD are fixed values and BAND is the 8 bit band signal The NCO s functionality was veri fied by running transient simulations using Fs 11MHz and sweeping through the BAND values 0 to 255 and calculating the resulting output frequency The resulting output fre quency versus BAND or band tuning curve was monotonic but not perfect ly linear Since it was monotonic it www embedded com embedded systems design was deemed acceptable to use in the closed loop test setup for the BCAL After establishing that the NCO
25. ations In 2001 he received his B E in EE from Cooper Union His interests include FPGA prototyping system modeling and signal processing Low Power 100mA 5V Tiny Form Factor 36 x 41 mm Industrial Operating Temperature Range 4 85 1 Tal BT Tal ET IN Y A9G20 LPVW 15 designed all E aa LEE PEECILITT ETE TOT re im H VV E m n xal m um SMALL SIZE HIGH PER www calao systems LOW DOWE HRIIAINCE LOW POWER www embedded com embedded systems design MAY 2010 Embedded amp Network Computing Technologies 27 Join EE Times Group to learn how distributors DUE E d f lt gt 5 EE Times Live Webinar 2010 Distributor Brand Preference Study OEMs rank distributors based on how well they help them achieve their operating goals and today more than ever it s crucial for distributor partners to understand how they stack up in the face of their vendor partners and end customers how they are measured and where they rate compared to their competitors in order to strengthen revenues and plan for a strong year ahead Tune in on May 14 as EE Times Group unveils the 2010 Distributor Brand Preference Study our annual benchmark research on the 40 billion distribution market where design engineers technical managers supply chain management purchasing and corpo
26. ble vul nerabilities or weaknesses that can cover feature be used to subvert or sabotage the software s dependability 3 Survivability also referred to as Resilience Software that is re silient enough to withstand attack and to recover as quickly as possi ble and with as little damage as possible from those attacks that it can neither resist nor tolerate The sources of software vulnerabil ities are many including coding errors configuration errors and architectural and design flaws However most vul nerabilities result from coding errors In a 2004 review of the National Vul nerabilities Database for their paper Can Source Code Auditing Software Identify Common Vulnerabilities and Be Used to Evaluate Software Security to the 37th International Conference on System Sciences Jon Heffley and Pascal Meunier found that 64 of the vulner abilities resulted from programming er rors Given this it makes sense that the primary objective when writing secure software must be to build security in BUILDING SECURITY IN Most software development focuses on building high quality software but high quality software is not necessarily secure software Consider the office me dia playing or web browsing software that we all use daily a quick review of the Mitre Corporation s Common Vul nerabilities and Exposures CVE dic tionary will reveal that vulnerabilities in Adding a security perspective
27. cally only takes 1096 Eliminating defects via a small increase in the cod ing effort can significantly reduce the burden of verification and this is where static analysis can really help Ensuring that code never exceeds a maximum complexity value helps to enforce the testability of the code In addition static analysis tools identify other issues that affect testability such as having unreachable or infeasible code paths or an excessive number of loops By eliminating security vulnerabili ties identifying latent errors and en suring the testability of the code under development static analysis tools help ensure that the code is of the highest quality and secure against not only cur rent threats but unknown threats as well FITTING TOOLS INTO THE PROCESS Tools that automate the process of stat ic analysis and enforcement of coding standards such as CWE or CERT C Se cure Coding guidelines ensure that a higher percentage of errors are identi fied in less time This rigor is compli mented by additional tools for e Requirements traceability a good requirements traceability tool is in valuable to the build security in process Being able to trace require The most effective and cheapest way of ensuring that the code under development meets its security requirements Is Via unit testing ments from their source through all of the development phases and down to the verification activities and artifacts ensu
28. ct Nov Dec by the EE Times Group 600 Harrison Street 5th floor San Francisco CA 94107 415 947 6000 Please direct advertising and editorial inquiries to this address SUBSCRIPTION RATE for the United States is 55 for 10 issues Canadian Mexican orders must be accompanied by payment in U S funds with addi tional postage of 6 per year All other foreign subscriptions must be prepaid in U S funds with additional postage of 15 per year for surface mail and 40 per year for airmail POSTMASTER Send all changes to EMBEDDED SYSTEMS DESIGN PO Box 3404 Northbrook IL 60065 9468 For customer service telephone toll free 877 676 9745 Please allow four to six weeks for change of address to take effect Periodicals postage paid at San Francisco CA and additional mailing offices EMBEDDED SYSTEMS DESIGN is a registered trademark owned by the parent company EE Times Group All material published in EMBEDDED SYSTEMS DESIGN is copyright O 2010 by EE Times Group All rights reserved Reproduction of material appearing in EMBEDDED SYSTEMS DESIGN is forbidden without permission COLUMNS programming pointers Alternative models for memory mapped devices BY DAN SAKS Traditional techniques for communi cating with hardware devices can be inconvenient and error prone Here are ways to make them simpler and robust break points 33 An interview with James Grenning Part 2 BY JACK G GANSSLE Is test driven development viable for emb
29. d by any combination of the following e A poor requirements specification Did the specification state how thick logs that were allowed If it did was the product tested against that requirment Poor test tools or no test tools at all Insufficient knowledge in embed ded programming A qualified guess is that the program was writ ten by an unskilled programmer who was using the default int type a deadly sin in any embed ded programming But in that case the real culprit was poor coding standards at the company or no coding standards at all Lundin Manager Thermocouples Make Your Own The Hot Spot Welder is a portable capacitive discharge WER evs wire welding unit that allows thermocouple wire to be formed into free standing bead or butt welded junctions or to be directly welded to metal surfaces The HOT SPOT provides a quick simple accurate low cost means of fabricating thermocouples on a when needed where needed basis Brochure and specification sheet provide photos and descriptions of thermocouple construction and use DCC Corp 7300 N Crescent Blvd Pennsauken NJ 08110 PH 856 662 7272 Fax 856 662 7862 Web www dccCorporation com My experience in embedded software supports every word Mr Grenning said First in my 30 years in the field I remember only one brand new first release program that was a total mess and I m sure that was deliberate ob fuscatio
30. ded software and meet business needs To me many the ideas in Agile Development can really help teams But its important to consider it a start not the destination Jack thanks again for the chat It s always good talking to you Jack Thanks James for your in sightful answers I hope the readers will respond with their thoughts and ences using TDD in their workplace AS EMBEDDED TECHNOLOGY ADVANCES WE RE RIGHT THERE WITH YOU 4 0110101 eoo 1 0 1109595505197 i i 23 LE LI LE aw 2c oro ge Se ra 27 TT aam m gm on aw a 3135 44 04 iFa r were scq EH HERES ae LIE TAL LA a 1 0 1 0 1 1 Pn J l 2 10 4 e 3195010 1 0 10 11 0 110 1 0 1 01 0 1 0 4 0 50git g r t 0 1 0 10RD 0101010110101010101010 101 0 61 10 742 1 77 45 57 N DROID E ER BE T m LINUX MENTOR EMBEDDED Innovation is boundless Mastering its possibilities requires a partner with the very latest in embedded software solutions Mentor Embedded delivers solutions that reduce your development risk and shorten project cycles We provide proven software and tools along with services for Linux and Android development that enable our customers to succeed in emerging areas such as Android beyond mobile multi OS multicore and advanced 3D user interfaces As the industry s leading independent vendor Mentor Embedded stands ready for your next innovation To lea
31. ed com that can lead to these vulnerabilities The standards in each of these diction aries can be enforced by the use of stat ic analysis tools that help to eliminate both known and unknown vulnerabili ties while also eliminating latent errors in code For example the screenshot in Figure 2 shows the detection of a buffer overflow vulnerability due to improper data types Static software analysis tools assess the code under analysis without actual ly executing it They are particularly adept at identifying coding standard vi olations In addition they can provide a range of metrics that can be used to as sess and improve the quality of the code under development such as the cyclo matic complexity metric that identifies unnecessarily complex software that s difficult to test When using static analysis tools for building secure software the primary objective is to identify potential vulner abilities in code Example errors that static analysis tools identify include Insecure functions Array overflows Array underflows Incorrectly used signed and unsigned data types Since secure code must by nature be high quality code static analysis tools can be used to bolster the quality of the code under development The objective here is to ensure that the soft ware under development is easy to veri fy The typical validation and verifica tion phase of a project can take up to 6096 of the total effort while coding typi
32. edded systems Ganssle continues to grill Grenning on TDD DEPARTMENTS include 5 Virtualization extends down to mobile devices BY RICHARD NASS The BOM on a virtualized handset can be reduced significantly over a more traditional design parity bit 7 marketplace 32 IN PERSON ESC Chicago June 7 9 2010 esc chicago techinsightsevents com ESC India July 21 23 2010 www esc india com ESC Boston September 20 23 2010 www embedded com esc boston Embedded Live October 20 21 2010 www embedded co uk ESC Silicon Valley May 2 5 2011 www embedded com esc sv ONLINE www embedded com Reliably With Express Logic s award winning BenchX IDE or use tools from over 20 commercial offerings including those from ARM Freescale Green Hills IAR Microchip MIPS Renesas and Wind River Ll With Express Logic s small fast royalty free and industry leading RTOS NetX TCP IP stack FileX9 FAT file system and USBX USB stack Easily With Express Logic s graphical TraceX event analysis tool and new StackX stack usage analysis tool See exactly what is happening in your system which is essential for both debugging and optimization gt Confidently No matter what it is you re developing Express Logic s solutions will help you build it analyze it run it and ship it better and in less time Join the success of over 600 000 000 deployed products usi
33. ely the causes of the blackout were traced to a slew of system procedur al and human errors and not an act of aggression Nevertheless the event brought home the vulnerability of critical infrastructures connect ed to the Internet raising awareness of the need for secure system components that are immune to cyber attack This increasing dependence on In ternet connectivity demonstrates the growing need to build security into software to protect against currently known and future vulnerabilities This article will look specifically at the best practices knowledge and tools avail able for building secure software that s free from vulnerabilities SECURE SOFTWARE In his book The CERT C Secure Coding Standard Robert Seacord points out that there is currently no consensus on a definition for the term software secu rity For the purposes of this article the 16 MAY 2010 embedded systems design www embedded com definition of secure software will follow that provided by the U S Department of Homeland Security DHS Software Assurance initiative in Enhancing the Development Life Cycle to Produce Se cure Software A Reference Guidebook on Software Assurance DHS main tains that software to be considered se cure must exhibit three properties 1 Dependability Software that exe cutes predictably and operates cor rectly under all conditions 2 Trustworthiness Software that contains few if any exploita
34. ely simplify your design espe cially if your product lends itself to multiple versions family members Lak Z A Richarfl Nass rich nass ubm com www embedded com embedded systems design MAY 2010 5 336 Volts of Green Engineering MEASURE IT FIX IT Developing a commercially viable fuel cell vehicle has been a significant challenge because of the considerable expense of designing and testing each new concept With NI LabVIEW graphical programming and NI CompactRIO hardware Ford quickly prototyped fuel cell control unit iterations resulting in the world s first fuel cell plug in hybrid MEASURE IT Acquire Analyze Present Acquire and Analyze and Present data Design Prototype Deploy Design optimized Prototype designs Deploy to the measure data extract information with HMIs Web from any sensor with signal interfaces or signal processing and reports control algorithms on ready to run hardware platform and systems hardware you choose Ford is just one of many customers using the NI graphical system design platform to improve the world around them Engineers and scientists in virtually every industry are creating new ways to measure and fix industrial machines and processes so they can do their jobs better and more efficiently And along the way they are creating innovative solutions to address some of today s most pressing environmental issues Dow tne teci inIiCal case stud V dl ni com 52
35. ems Programming September 2004 p 49 www embedded com 26807176 2 Saks Dan Mapping Memory Efficiently Embedded Systems Pro gramming November 2004 p 47 www embedded com 50900224 3 Saks Dan More ways to map memory Embedded Systems Pro gramming January 2005 p 7 www embedded com 55301821 4 Saks Dan Sizing and Aligning Device Registers Embedded Sys tems Programming May 2005 p 9 www embedded com 55301821 5 Barr Michael Introduction to fixed width integers Embedded com January 2004 www embedded com 17300092 6 Saks Dan Use Volatile Judiciously Embedded Systems Program ming September 2005 p 8 www embedded com 170701302 7 Saks Dan Place Volatile Accurately Embedded Systems Program ming November 2005 p 11 www embedded com 174300478 Meyers Scott The Most Important Design Guideline IEEE Soft ware July August 2004 p 14 www aristeia com Papers IEEE_Soft ware_JulAug_2004_revised htm 9 Saks Dan Tag Names vs Type Names Embedded Systems Programming September 2002 p 7 www embedded com 9900748 10 Saks Dan Padding and rearranging structure members Embedded Systems Design May 2009 p 11 www embedded com 217200828 11 Saks Dan Catching Errors Early with Compile Time Assertions Embedded Systems Programming July 2005 p 7 www embedded com columns 164900888 SEMINAR TOUR Tektronix power2solve Helping engineers solve complex deb
36. en you re putting together a system with thousands of lines of code controlling dozens of devices writing TMOD amp TE is asking for trouble You could easily write instead of amp leave off the or select the wrong mask Even after you get everything right the code is far from self explanatory Rather you should package this operation as a function named timer disable or something like that so that you and your cohorts can disable the timer with a simple func tion call The function body is very short it s only a single assignment so you should probably declare it as an inline function If you re stuck using an older C dialect you can make it a function like macro But what should you pass to that call Most devices have several registers Is it really a good idea to make the caller re sponsible for selecting which of the timer registers to pass to the function as in timer disable TMOD when only one register will do Maybe it s better to just build all the knowledge into the function as in inline void timer disable void TMOD amp TE so that all you have to do is call timer disable O This works for the timer because there s only one timer However my sample machine has two UARTS each with six registers and many UART operations employ more than one register For example to send data out a port you must use both the UART status register and the transmit buffer register The f
37. ency synthesizer is loosely defined as a PLL that generates an out put frequency that s directly proportion al to a reference frequency The constant of proportionality is a specific subset of integer or real numbers depending on the synthesizer implementation One use for a synthesizer in a re ceiver front end is the creation of the local oscillator input to a mixer that downconverts the received radio fre quency RF signal to an intermediate frequency Channel selection is achieved by setting the synthesizer s constant of proportionality In general RF Ndiv REF where RF is the out put frequency Ndiv is the constant of proportionality and REF is the refer ence frequency Ndiv can be a ratio of integers N R where N is an integer divide value for A large VCO gain would make the PLL susceptible to high phase noise For these reasons the tuning range is split up into dis crete bands the output of the VCO and R is anoth er integer divide ratio for dividing the reference oscillator If even finer fre quency resolution is needed the N val ue can be added to a sigma delta mod ulated code that dithers the divider The band calibration testbench implemented on the FPGA is analogous to band calibration used in a frequency synthesizer on an ASIC REF xtal Disabled y aw e o o ce o ae ao o co co co ao ae ae co
38. for code behavior that does not exist e Watch the test fail maybe not even compile e Write the code to make the test pass e Refactor any messes made in the process of getting the code to pass e Continue until you run out of test cases Maybe you can see that TDD would do very well with these metrics Coverage will be very high measured by line or path coverage Jack G Ganssle is a lecturer and consultant on embedded development issues He conducts seminars on embedded systems and helps companies with their embedded challenges Contact him at jack ganssle com Is test driven development viable for embedded sys tems It may be part of the answer Ganssle con tinues to grill James Grenning on TDD One reason these metrics are not the focus is that there are some prob lems with them It is possible to get a lot of code coverage and not know if your code operates properly Imagine a test case that executes fully some hunk of code but never checks the direct or indirect outputs of the highly covered code Sure it was all executed but did it behave correctly The metrics won t tell you Even though code coverage is not the goal of TDD it can be complemen tary New code developed with TDD www embedded com embedded systems design should have very high code coverage along with meaningful checks that con firm the code is behaving correctly Some practitioners do a periodic review of code coverage lookin
39. g for code that slipped through the TDD process I ve found this to be useful especially when a team is learning TDD There has been some research on TDD s impact on cyclomatic complexi ty TDD s emphasis on testability mod ularity and readability leads to shorter functions Generally code produced with TDD shows reduced cyclomatic complexity If you Google for TDD cy clomatic complexity you can find arti cles supporting this conclusion Jack Who tests the tests James In part the production code tests the test code Bob Martin wrote a blog a few years ago describing how TDD is like double entry accounting Every entry is a debit and a credit Ac counts have to end up balanced or something is wrong If there is a test failure it could be due to a mistake in the test or the production code Copy and paste of test cases is the biggest source of wrong test cases that I have seen But it s not a big deal because the feedback is just seconds after the mis take making it easy to find Also the second step in the TDD micro cycle helps get a test case right in the first place In that step we watch the new test case fail prior to implementing the new behavior Only after seeing that the test case can detect the wrong re sult do we make the code behave as specified by the test case So at first a wrong implementation tests the test case After that the production code tests the test case Another safeguard is to ha
40. g the PLL to lock tuning bands is used in a phase locked A straightforward way to calibrate loop PLL the desired band must be the band is by racing two counters one selected before the PLL can proceed to clocked with the reference clock and phase lock This necessary step has the other clocked with the feedback many names band calibration auto clock that is the frequency divided ver band selection band selection and so sion of the VCO output The frequency on but the idea is the same to pick division occurs in a block called a mul the right frequency band before allow ti modulus divider MMD www embedded com embedded systems design MAY 2010 23 The counters are forced to start at the same time and permitted to count up to a predetermined value Whichev er counter gets to the value first is not ed as the winner it follows that that clock was greater in frequency Using the information about which counter was the winner the band con trol of the VCO can be either incre mented or decremented to bring the frequencies closer This algorithm is implemented in a band calibration block BCAL Instead of waiting for an expensive ASIC fabrication run that in cludes the entire PLL and other circuits you can implement a band calibration algorithm and test it on an FPGA This article shows you how VCO BAND CALIBRATION BCAL In communications chips frequency synthesizers are ubiquitous functional blocks A frequ
41. gagement Barbara Couchois Vice President Sales Ops UBM Corporate UBM LLC Marie Myers Senior Vice President Manufacturing Senior Vice President Strategic Development and Business Administration Pat Nohilly Virtualization extends down to mobile devices t wasn t too long ago that you had to explain to designers what the lt term virtualization was all about That s generally not the case anymore In fact the number of systems that are virtualized as part of the design process has increased considerably In most cases the systems that were candidates for virtualization were those of the high performance variety Today you can make an argu ment to go the virtual route for almost any type of embedded system includ ing mobile devices The technology that s been deployed for years in enter prise data centers can be driven down into consumer devices While traditional virtualization of ten concentrates on a high end even multicore processor and chipset mo bile virtualization tends to look at the paradigm a little differently For exam ple it s no surprise to see multiple chips consolidated into a unified processor with dedicated DRAM glue logic and so on At the same time multiple functions can be ported to that single virtualized processor While potentially increasing performance there s a big upside in the reduced number of interconnects required The single virtualized processor
42. he simulation Now the RTL code can be implemented on the ASIC with confidence it will function correctly j REF er F Sioa s 2 B ae p IN REF input PE to FPGA R 22m oe n band value hex 1 hE3 d227 Stratix II FPGA Figure 3 The functionality checked out okay in those simulations Since then the RF receiver ASIC that includes the frequency synthesizer was fabricated and measurements of the chip show the frequency synthesizer phase locks over its range of possible output frequencies This implies that the band cali bration functions correctly As a result the design team can focus on squeezing better performance out of the analog por tions of the ASIC The process of prototyping a design on an FPGA before committing it to an ASIC is useful not only verification pur poses but also for the possibilities it provides for algorithm experimentation If the context of the algorithm can be repli cated on the FPGA as it will appear on the ASIC any number of algorithm implementations may be tried and compared in terms of area efficiency current consumption or speed Hap py prototyping MI Russell Mohn is a senior design engineer at Epoch Microelec tronics an IC design services company specializing in mixed signal analog and RF design At Epoch his focus has been on the design of fractional N frequency synthesizers for com munications applic
43. igure 1 For the synthesizer to have low phase noise a crystal generates the fre quency reference The reference fre quency 15 typically in the tens of MHz which is well below the maximum speed of the logic that can be imple mented on today s FPGAs The BCAL algorithm itself can be described and designed with digital techniques At its simplest its inputs are two clocks the reference and the output of the NCO its output is the band signal for the NCO The combination of the band calibration NCO and an external ly applied reference signal forms a closed loop system with negative feed back that is analogous to the PLL oper ating during its band calibration mode all of which can be coded in RTL and tested on an FPGA before spending money on an ASIC fabrication WHAT YOU NEED 1 An FPGA and its programming software 2 Matlab Simulink for algorithm de velopment and verification 3 Asignal source for generating the reference clock such as 10 to 15 MHz 4 An oscilloscope for debugging I used Matlab Simulink to enter the initial design and testbench The sup port for fixed point numbers that comes with the Fixed Point Toolbox and Simulink Fixed Point is useful for making the model accurately reflect the implementation in RTL The RTL code was written in verilog and run on AI tera s Stratix II DSP Development Kit From within Altera s Quartus II software all things FPGA could be ac complished design entry simul
44. in other words the compiler assembler and linker Consider the following situation A bug you have found 15 the result of the compiler making wrong assumptions about register allocation and stack allo cation of variables that are local to a function The bug is exposed when many variables compete for the avail able CPU registers and some variables have to be temporarily moved to the stack You have found the bug in a large function with a lot of arithmetic com putations but that is no guarantee that the bug will only manifest itself in large functions with a lot of computations So we end up with the question of whether to persuade the compiler ven dor to supply a fix or applying the workaround s throughout the code Listing 2 i base with all the implications for the project outlined above For high integrity projects the build chain and the vendor should be subject to a lot of scrutiny before selection And the typical scenario is that once a partic ular compiler and version is selected you stay with it throughout the project Some high integrity process frameworks even require the tools selection to be subject to a formalized process where the tools are prequalified or validated ac cording to certain criteria We will now take a look at a special technique that can be used if you have a close relationship with your compiler vendor Consider a compiler for a 32 bit architecture Many 32 bit CPU kernels incorporate
45. ith the domain of the software under development This is determined by a security risk assessment a process that ensures the nature and impact of a se curity breach are assessed prior to de ployment in order to identify the secu rity controls necessary to mitigate any identified impact The identified securi ty controls then become a system re quirement Adding a security perspective to software requirements ensures that se curity is included in the definition of system correctness that then permeates the development process A specific se curity requirement might validate all user string inputs to ensure that they do not exceed a maximum string length A more general one might be to with stand a denial of service attack Whichever end of the spectrum is used it is crucial that the evaluation criteria are identified for an implementation When translating requirements into design it is prudent to consider security risk mitigation via architectural design This can be in the choice of implement ing technologies or by inclusion of secu rity oriented features such as handling untrusted user interactions by validating inputs and or the system responses by an independent process before they are passed on to the core processes The most significant impact on building secure code is the adoption of secure coding practices including both static and dynamic assurance measures The biggest bang for the buck stems from the enforce
46. ling with misbehaving tools BY ANDERS HOLMBERG e changes very late in a project is almost never a ide effects e The process view Making changes to the code and rebuilding the applica tion image will force a restart of one or more test and quality assurance QA activities in the project Mini mizing test and QA without com promising safety and integrity in the face of code changes can thus be come critical for time to market The later in the process a prob lem is encountered the further back hough correction of the error might be crucial for safe usage of the end product it has a number in the process you have to go to re visit certain activities In the worst case a full external revalidation or recertification assessment may be required The code view Changing code to correct erratic behavior always car ries the risk of introducing new un wanted behavior This sometimes leads to the decision to leave a prob lem as is in the product and docu www embedded com embedded systems design MAY 2010 29 ment clearly the impact of the code behavior High integrity regulatory frameworks often make things even tougher by requiring extensive im pact analysis of the changes prior to performing them e The goodwill view Frequent or large code changes in the final stages of a project can make stake holders nervous about the end product If the product has already reached the market the situati
47. ly can ask for a change if he s not Customer might re fer to an end user your boss the sales department or any other stakeholder If there s no barrier to changes how does one manage or even estimate the cost of a project James This is more of an Agile re quirements management issue than TDD but that s OK Let me start by say ing that it is a misconception that there is no barrier to requirements changes and feature creep For successful out come requirements have to be carefully managed In Agile projects there is usually a single person that is responsible for driv ing the development to a successful de livery Some refer to this as the customer or the product owner PO The product owner might be from marketing prod uct management or systems engineer ing She usually heads a team of skilled people who know the product domain the market the technology and testing She 15 responsible for making trade offs Team members advise her of course manage development we create and maintain something called the product backlog The backlog is the list of all the features we can think of that should go into the product There is a strong preference to make the work visi ble to the PO over work that only engi neers understand It is mostly feature oriented not engineering task oriented focusing on value delivery We prevent surprises by taking three month engi neering deliverables and splitting them MA
48. ment system If you are practicing the SOLID design principles it is natural to manage the dependencies on the hardware and operating system If there is a lengthy control process being test driven we need to take control of the clock If we are managing depend encies this is not hard A time driven event eventually resolves to a function call The test fixture can call the event processing code as well as some operat ing system or interrupt based event handler If your code needs to ask some time service what the current millisec ond is we can intercept those calls and mimic any time based scenario we like without any of the real delays slowing the test execution time With that said about unit tests you might have the same issue when it comes to a more thorough integration or sys www embedded com embedded systems design tem test If you have automated some of these tests and you rely on using the real clock tests could take a long time to run But that may not be a problem because the cadence of acceptance and systems tests does not need to be as fast as unit tests We d like to run these longer tests automatically as part of a continuous in tegration system Jack Let s move on to my business concerns Through incremental delivery TDD promises to produce a product that closely aligns with the customer s needs That is at each small release the customer can verify that he s happy with the feature and presumab
49. ment of secure coding rules via static analysis tools With the introduction of security concepts into the requirements process dynamic as surance via security focused testing is then used to verify that security features have been implemented correctly CREATING SECURE CODE WITH STATIC ANALYSIS A review of the contents of the CVE dictionary reveals that common soft ware defects are the leading cause of se curity vulnerabilities Fortunately these Extend battery life with the MAXQ610 16 bit microcontroller Up to 12 MIPS in under 4mA industry s highest MIPS mA The MAXQ610 microcontroller is designed for low cost high performance battery powered applications This 16 bit RISC based microcontroller has a wide operating range down to 1 7V for long battery life and ultra low power consumption Its anticloning features and secure MMU enable you to protect your IP Application partitioning Vcc 1 7V to 3 6V and IP protection Microcontroller Peripherals e 16 bit MAXQ RISC core e Two USARTs and one SPI master slave e 64KB flash memory 2KB SRAM communication port e Ultra low supply current e Two 16 bit timers counters Active mode 3 75mA at 12MHz e 8kHz nanoring functions as programmable Stop mode 200nA typ 2 0 max wakeup timer e Wide 1 7V to 3 6V operating voltage range e R timer simplifies support for low e IP protection speed infrared communication Secure MMU supports multiple privilege IR d
50. n Most developers seem to be able to divide a program into reason able modules and implement these modules intelligently no matter the process they follow It is enhancements that destroy the programs This was true when new breath types were added to a medical ventilator new measure ments to optical inspection systems or new protocols to telemetry sys tems These changes are almost always made under time pressure and use as much existing code as possible The result is usually that pretty decent modules grow to be untestable and unmaintainable I have had to take over far too much such legacy sys tems and it s very hard to convince managers that it s costing them more than it s worth If TDD can stop this code rot and force needed refactoring I hope every organization whose code I ever have to maintain will adopt it P S Kent Beck may have taken the write a little code test it and extend it method past any reasonable point but that is how real working programs are 32 MAY 2010 embedded systems design www embedded com on Best Practices for Peer Code Review available at 7 eel Kani Secrets af Peer Kiev MEDIA KIT www embedded com mediakit Learn today Design tomorrow Sales Contacts 600 Harrison St 5th Flr San Francisco CA 94107 David Blaza Publisher 415 947 6929 david blaza ubm com Bob Dumas Associate Publisher 516 562 5742 bob dumas ubm com
51. n developers complain ing about BTUF Big Testing Up Front lwriemen Chief Frog I think we all agree that the product must be tested as whole in its intend ed environment Or The require ments may be flawed or incomplete numerous research have labelled poor requirements as the most common cause for disaster Also no matter how loose cou pling your code has there might be unforseen dependencies arising when the code is put together All modules in your project will also share the same system resources And there will always be the top down dependancy from main thread gt code modules objects functions So the code too needs to be tested in its intended soft ware environment just like the final product needs to be tested in the in tended real world environment None of the this excludes TDD But of course TDD can t be used asa replacement for final verification vali dation that would just be plain stu pid for the above mentioned reasons I really don t hope that s the case I m going to be mean and shoot down Larry Martin s example about the automated sawmill Any decent static analyzer and good compilers as well would have attacked that particu lar bug saying something like implicit conversion between signed and un signed int If you scratch your head for CONTINUED ON PAGE 32 MAY 2010 1 ne j P Aii m 1 AG P 2 miconduct
52. ng Express Logic s ThreadX BEN CH THREAD TRACE STAC K logic For a free evaluation copy visit www rtos com 1 888 THREADX EMBEDDED SYSTEMS DESIGN Editorial Director Richard Nass 201 288 1904 rich nassubm com Managing Editor Susan Rambo susan rambo ubm com Contributing Editors Michael Barr John Canosa Jack W Crenshaw Jack G Ganssle Dan Saks Larry Mittag Art Director Debee Rommel debee rommel ubm com European Correspondent Colin Holland colin holland ubm com Embedded com Site Editor Bernard Cole bccole acm org Production Director Donna Ambrosino dambrosino ubm us com Subscription Customer Service P O Box 2165 Skokie IL 60076 800 577 5356 toll free Fax 847 763 9606 embeddedsystemsdesign halldata com www customerserviceesp com Article Reprints E prints and Permissions Mike O Brien Wright s Reprints 877 652 5295 toll free 281 419 5725 ext 117 Fax 281 419 5712 www wrightsreprints com reprints index cfm magid 2210 Publisher David Blaza 415 947 6929 david blaza ubm com Editorial Review Board Michael Barr Jack W Crenshaw Jack G Ganssle Bill Gatliff Nigel Jones Niall Murphy Dan Saks Miro Samek EE TimesGroup Corporate EE Times Group Paul Miller Chief Executive Officer Felicia Hamerman Group Marketing Director Brent Pearson Chief Information Officer Jean Marie Enjuto Financial Director Amandeep Sandhu Manager Audience En
53. oing test reviews is more impor tant than reviewing production code The tests are a great place to review in terface and behavior two critical aspects of design Jack As has been observed all test ing can do is prove the presence of bugs not the absence A lot of smart people believe we must think in terms of quality gates multiple independent activities that each filter defects So that includes requirements analysis design reviews inspections tests and even formal verifi cation Is this orthogonal to TDD ap proaches and how do TDD practition ers use various quality gates James TDD does not try to prove the presence of bugs it is a defect pre vention technique www renaissancesoft ware net blog archives 16 People make mistakes regularly during development but in the TDD micro cycle the mis takes are immediately brought to the de veloper s attention The mistake is not around long enough to ever make it into a bug tracking system I think TDD is only part of the an swer Reviews inspections and pair pro gramming are orthogonal and comple mentary to TDD There is another form of TDD a more requirements centric activity called Acceptance Test Driven Development ATDD In ATDD the customer repre sentative defines tests that describe the features of the system Each iteration the team works to complete specific stories defined by the customer A story is like a use case or a specific usage scenario
54. on ception again on no real schedule There is a schedule probably a more rig 36 MAY 2010 embedded systems design www embedded com TDD is just part of the picture The team activities should encompass cross functional needs While the product is evolving the team s progress is an open book orous and fact based schedule that most developers are used to working with The Agile approach can be used to man age to a specific date or to specific fea ture content TDD is just part of the picture The team activities should encompass cross functional needs While the product 15 evolving the team s progress is an open book The user documentation market ing materials etc can and should be kept up to date I don t try to get bosses to buy into vague outcomes I get bosses that are not satisfied with vaguely working harder smarter next time I get bosses interested that want pre dictability and visibility into the work I get bosses that want to see early and steady progress through the develop ment cycle ones that are not so interest ed in doing more of the same thing and expecting different results Jack Now for a hardball question Is it spelled agile or Agile James Saving the toughest for last setting me up Someone with greater command of the language better take that one Like any label agile is aging and getting diluted My real interest and I think yours too is advancing how we develop embed
55. on can be a real nightmare So it s not always possible to avoid code changes but methods and tools to avoid or minimize the impact of changes can be extremely helpful Three broad categories cause most of the late code changes e The source code bug This kind of error is either due to mistakes or misunderstandings by the pro grammer in the implementation or an ambiguous or incomplete func tional specification that leaves too much open to interpretation Al though this is a common occur rence I won t be discussing it in this article e The latent non ANSI C C source bug The ANSI C standard has some dark corners where behavior is either implementation defined or undefined If you ve implemented parts of the source code to depend on how a particular compiler be haves for these corner cases of the standard you can expect a problem Listing 1 Bool ArelIndependent Instr 1 511 Instr inst2 if CIndependentSourceAndDest Instil1 Inst2 return true else return false j It s not always possible to avoid code changes but methods and tools to avoid or minimize the impact of changes can be extremely helpful in the future However as this kind of latent bug is mainly a process and knowledge issue it will not be discussed further here e This leaves us with the main focus for this article the object code gen eration tool bug We will restrict the discussion to bugs in the build chain
56. ons engi neer with LDRA Technologies Inc a po sition that he comes to via an extensive background in software engineering sales and marketing He is an experi enced presenter in the use of software analysis solutions for real time safety crit ical software who has been invited to participate in a number of international forums and seminars on the topic for more secure software With the bulk of vulnerabilities being attributa ble to coding errors reducing or elimi nating exploitable software security weaknesses in new products through the adoption of secure development practices should be achievable within our lifetime By leveraging the knowledge and experience encapsulated within the 22 MAY 2010 embedded systems design www embedded com Prototyping an ASIC design first on a more room for alt only useful for verification but allows experimentation How to use an FPGA to test a PLL band calibration algorithm BY RUSSELL MOHN ts a common technique to split the required frequency tuning range of a controlled oscillator into discrete bands The advantage of having many bands is that a wide tuning range can be covered while keeping a relatively low voltage controlled oscillator VCO gain within each band Low VCO gain is good for achieving low VCO phase noise It s required that the frequency bands overlap The tuning bands are changed with a digital band control signal When an oscillator with discrete in
57. opers can benefit from the experience and knowledge encapsulated within the standards The use of coding standards to eliminate ambiguities and weaknesses in the code under development has been proven extremely successful in the creation of high reliability software such as the use of the Motor Industry Software Reliability Association MIS RA Guidelines for the use of the C lan guage in critical systems The same practice can be used to similar effect in the creation of secure software Of the common exploitable soft ware vulnerabilities that appear in the Static software analysis tools assess the code under analysis without executing it and are adept at identifying cod ing standard violations CVE dictionary some occur more than others user input validation buffer overflows improper data types and improper use of error and exception handling The CWE and CERT C dic tionaries identify coding weaknesses Embedded SmxWIFI untethers your designs e 802 11a b g i n e USB WiFi Dongles e PCI WiFi Cards e Device lt gt Access Point 6 fe Micro Digital 35TH ANNIVERSARY e Device lt gt Device e Security WEP WPA1 WPA2 e Ralink RT25xx RT2860 RT2870 RT3070 Support 800 366 2491 sales smxrtos com www smxrtos com Full source code Optimized for SMX e Portable to other RTOSs Small RAM ROM Footprint Royalty free 20 MAY 2010 embedded systems design www embedd
58. ors as well as the rket supplier of ors to realize intelli ana Im pri By Dan Saks Alternative models for memory mapped devices evice drivers typically communi cate with hardware devices through device registers A driver sends commands or data to a device by storing into device registers or retrieves status information or data from a device by reading from device registers Many processors use memory mapped I O which maps device registers to fixed addresses in the conventional memory space To a C or C programmer a memory mapped device register looks very much like an ordinary data object Programs can use built in operators such as assignment to move values to or from memory mapped device registers Some processors use port mapped I O which maps device registers to ad dresses in a separate address space apart from the conventional memory space Port mapped I O usually re quires special machine instructions such as the in and out instructions of the Intel x86 processors to move data to or from device registers To a C or C programmer port mapped de e vice registers don t look like ordinary memory The and standards say nothing about port mappedI O Pro grams that perform port mapped I O must use nonstandard platform specific language or li brary extensions or worse assembly code On the other hand programs can perform memory mapped I O using onl
59. ot registering combinatorial comparator outputs These are both examples of problems that arise in actual hardware but may not show up in the ide alized models in Simulink unless you explicitly add them in your model To ease the migration of the Simulink model to RTL try to use Simulink function blocks that are primitives in the RTL language of your choice For example logic functions such as XOR AND and greater than map directly from Simulink to Verilog A delay or explicit DFF in Simulink is modeled as a register in Verilog I also recommend naming all the signals in the Simulink model and using the same names in the Verilog code It s okay to first build the model using floating point data types in Simulink but if you migrate the floating point design to fixed point it will ease the coding process and lead to a de sign that is easier to debug THE END RESULT After running the RTL code on the FPGA and judging that the design is functional and meets specifications based on measured data it was time to implement the code on an ASIC The logic synthesis and layout was done with Ca dence s Encounter software As a final check I simulated the resulting logic netlist and also the extracted layout netlist with parasitic resistors and capacitors to make sure the func tionality was still okay after Encounter s synthesis and place and route Lab setup for band calibration running on the FPGA showing that measured band value matches t
60. problem Anders Holmberg is software tools prod uct manager at IAR Systems MAY 2010 31 Low Cost Panel PC EMBEDDED SYSTEMS MARKETPLACE on 200 Mhz ARMS processor with the T PPC E7 isa Compact Panel PC based following features Open Frame Design 10 100 BaseT Ethernet Real Time Clock 3 125 Audio Port 3 USB 2 0 Host Ports i Fanless ARMS 200MHz CPU 3 Serial Ports RS232 485 amp SPI i3 SWMMC Flash Card Interface Windows CE Battery Backed Real Time Clock Up to 64 MB Flash amp 128 MB RAM GPIO A D Timers amp PWM Linux with Eclipse IDE or WinCE 6 0 WVGA 800 x 480 7 LCD with Touch Prices start at 495 Since 1985 UVER 25 YEARS CHI SINGLE HOAR SOLUTIONS Phone 678 4 1 1 i 1 1 mm N r 1 C Irre E ra AS i 4 fg P I J A J uu T Val Tan Ma 3 529 4525 Fax 618 457 0110 Web waw emacinc com parity bit from page 7 a moment you will realize that the tool is telling you why are you using a signed int to store a diameter for It doesn t make sense You will then no doubt start digging in that code piece finding numerous other bugs So I daresay that any form of test would have found that bug in a few minutes if it involved a good compiler or static analyzer As I see it the bug was likely cause
61. r story points We re estimating the team s velocity in story gt 7 points per iteration The initial estimate for the project would be the total of all story points divided by the estimated ve locity This will probably tell us that there is no way to make the delivery date But it s just an estimate next we ll measure As we complete an iteration we cal culate the actual velocity simply by adding the point values of the completed stories The measured velocity provides feedback that is used to calibrate the plan We get early warning of schedule problems rather than 11th hour sur prises If the projected date is too late for the business needs managers can use the data to manage the project The PO can carefully choose stories to do and not do to maximize delivered value The busi ness could looks at adding people before it is too late or change the date Jack Engineering is not a stand alone activity While we are designing a product the marketing people make ad vertising commitments tech writers cre ate the user s manual trade shows are arranged accounting makes income and expense projections and a whole host of other activities must come together for the product s launch TDD says the boss must accept the fact that there s no real schedule or at least it s unclear which features will be done at any particular time How do you get bosses to buy into such vague outcomes James Jack there goes that misc
62. rate managers across the OEM market have weighed in on Which distributors are preferred and what criteria matters the most such as ease of doing business customer service pricing and website capabilities How distributor brand preference varies across product categories such as semiconductors connectors amp interconnects passive components and electromechanical devices What factors influence purchasing decisions from the same distributor Presented by EE Times this landmark research is a key measurement tool for OEM s CEM s distributors and suppliers If you are a distributor an OEM or a decision maker in the purchase process of electronic components you need to attend this webinar Register today http tinyurl com 514 eet study stack up in today s market casper CARD Registration information lll Register by 4 30 10 250 00 USD ll Register between 5 1 10 and 5 14 10 299 00 USD The registration fee is payable by American Express Mastercard or Visa All paid registrants will be given a confirmation number and a url which will enable them to view the study at their leisure from May 14 to December 31 2010 Please contact EE Times Webinar Support with any questions at webinar techonline com Presenter Jim McLeod Warrick Founding Partner of Beacon Technology Partners LLC EE Times Group Here s a novel approach to the update tool or update source dilemma Dea
63. res the highest quality secure software e Unit testing the most effective and cheapest way of ensuring that the code under development meets its security requirements is via unit testing Creating and maintaining the test cases required for this however can be an onerous task Unit testing tools that assist in the cover feature test case generation execution and maintenance streamline the unit testing process easing the unit test ing burden and reinforcing unit test accuracy and completeness e Dynamic analysis analyses per formed while the code is executing provide valuable insight into the code under analysis that goes be yond test case execution Structur al coverage analysis one of the more popular dynamic analysis methods has been proven to be in valuable for ensuring that the veri fication test cases execute all of the code under development This helps ensure that there are no hid den vulnerabilities or defects in the code under development While these various capabilities can be pieced together from a number of suppliers some companies offer an in tegrated tool suite that facilitates the building security in process providing LDRA TBvision screenshot showing improper data type sign usage resulting in buffer overflow vulnerability WF LORA Thvicion 8 1 1 2009 LDRA Ltd forma Actual and formal parameters inconsistent rere Correr pon CNET
64. river capable of 25mA levels helps protect code from copying and sink current reverse engineering Part Program Data 0perating Price C Voltage V MAXQ610B 0 to 70 64KB flash 2KBSRAM 171036 40 TQFN MAXQ is a registered trademark of Maxim Integrated Products Inc SPI is a trademark of Motorola Inc 11000 up recommended resale Prices provided are for design guidance and are FOB USA International prices will differ due to local duties taxes and exchange rates Not all packages are offered in 1k increments and some may require minimum order quantities www maxim ic com MAXQ610 info MAKIN s amer MA AA www maxim ic com shop www em avnet com maxim INNOVATION DELIVERED For free samples or technical support visit our website Innovation Delivered is a trademark and Maxim is a registered trademark of Maxim Integrated Products Inc 2010 Maxim Integrated Products Inc All rights reserved cover feature vulnerabilities can be attributed to common weaknesses in code and a number of dictionaries have been creat ed to capture this information such as the Common Weakness Enumeration CWE dictionary from the Mitre Corporation and the CERT C Secure Coding Standard from the Software Engineering Institute at Carnegie Mellon These secure coding stan dards can be enforced by the use of static analysis tools so that even novice secure software devel
65. rn more visit www mentor com embedded 2010 Mentor Graphics Corporation All Rights Reserved Mentor Graphics is a registered trademark of Mentor Graphics Corporation The new standard for pcb assembly
66. rs that define symbols for device register addresses as clusters of related macros For example timer registers define TMOD Cunsigned volatile OxFFFF6000 define CCunsigned volatile OxFFFF6004 define TCNT CCunsigned volatile OxFFFF6008 defines TMOD TDATA and TCNT as the addresses of the timer mode register the timer data register and the timer count register respectively The header might also include useful constants for manipulating the registers such as define TE 0 01 define TICKS PER SEC 50000000 which defines TE as a mask for setting and clearing the timer enable bit in the TMOD register and TICKS PER SEC as the number of times the TCNT register decrements in one second Using these definitions you can disable the timer using an expression such as TMOD amp TE or prepare the timer to count for two seconds using TDATA 2 TCNT 0 TICKS PER EC Other devices require similar clusters of macros such as Listing 1 In this case UARTO and UART have identical sets of registers but at different memory mapped addresses They can share a common set of bit masks define RDR 0x20 define TBE 0x40 SO WHAT S NOT TO LIKE This approach leaves a lot to be desired As Scott Meyers likes to say interfaces should be easy to use correctly and hard to use incorrectly Well this scheme leads to just the opposite By itself disabling a timer isn t a hard thing to do Wh
67. sters typedef uint32 t volatile timer register define TMOD define TDATA f CCtimer register OxFFFF6000 CCtimer register OxFFFF6004 UART 0 registers typedef uint32 t volatile UART register define ULCONO define UCONO f INI register OXxFFFFDOO0 register OXxFFFFD004 then timer register and register are just two dif ferent names for the same type and you can use them inter changeably throughout your code Even if you take pains to declare the UART put function as void UART put UART register s UART register b int you can still pass it a timer register as a UART register By any name an volatile unsigned is still an volatile unsigned Again you could write the UART functions so that they know which registers to use But there are two UARTS so you d have to write pairs of nearly identical functions such as void UARTO put int c void UART1 put int c 12 MAY 2010 embedded systems design www embedded com This gets tedious quickly and becomes prohibitive when the number of UARTs is much bigger than two As an alternative you could pass an integer designating a UART as 1n typedef unsigned UART number void UART put UART number n int To make this work you need a scheme that converts integers into register addresses at run time Plus you have to worry about what happens when you pass an integer that s out of range USING
68. to software requirements ensures that security is included in the definition of system correctness these applications are discovered and re ported on an almost weekly basis The reason 15 that these applications were written to satisfy functional not securi ty requirements Testing is used to verify that the software meets each require ment but security problems can persist even when the functional requirements are satisfied Indeed software weakness es often occur by the unintended func tionality of the system Building secure software requires adding security concepts to the quality focused software development lifecycle so that security is considered a quality attribute of the software under develop ment Building secure code is all about eliminating known weaknesses Fig ure 1 including defects so by necessity secure software is high quality software Security must be addressed at all phases of the software development lifecycle and team members need a common understanding of the security goals for the project and the approach that will be taken to do the work The starting point is an under Building secure code by eliminating known weaknesses v_n_so t cpp 10 int ival nitens d 11 vectorcint v 14 13 cout 14 1 while 16 17 18 push 19 cout cout 21 22 Figure 1 18 MAY 2010 embedded systems design www embedded com standing of the security risks associated w
69. trol voltage to a maximum change of about 1 5 V It s difficult to build a varactor that will change its reactance enough to cause a frequency change of 1 000 MHz with only a control voltage change of 1 5 V Furthermore a large VCO gain of 1 000 MHz 1 5 V would make the PLL susceptible to high phase noise For these reasons the tuning range is split up into discrete bands The discrete bands are implemented by adding bina ry weighted capacitors to the parallel LC tank circuit They are switched on or off depending on the digital band setting The band must be set before the PLL can be allowed to lock and track in a continuous manner The BCAL circuit operates as a sec ond feedback loop controlling the VCO through its band input During band calibration the VCO control voltage 15 fixed at a convenient voltage usually the mid point of its allowable control voltage range The phase detector is also disabled during band calibration My goal was to design and test the band calibration algorithm before inte grating it with the PLL on an RF receiv er ASIC To that end a system analo gous to the PLL when it s being band calibrated was constructed entire ly with circuits that could be imple mented on an FPGA Since the VCO and MMD lumped together act as a programmable oscillator with output frequencies around the reference fre quency their functionality can be mod eled by a numerically controlled oscil lator NCO shown in F
70. ug challenges quickly You re invited Power2Solve is a series of FREE technical seminars for Design Hands on Training Engineers and Educators offering practical how to training on the latest troubleshooting techniques for embedded system design You ll spend a day working side by side with your peers and industry experts from Tektronix finding solutions to your debugging challenges Courses Include dod AU Use Tektronix cutting edge Debugging Digital Designs oscilloscopes to perform e Serial and Parallel Data Debug hands on digital debug and e Characterization amp Jitter Analysis serial data measurements The Power2Solve Seminar is coming to city near you May 18 2010 The Hyatt Regency Richardson IX May 20 2010 The Radisson Hotel Denver Longmont CO May 24 2010 The Hyatt Regency San Diego CA May 26 2010 The Hyatt Regency Santa Clara CA Attend the event and get the opportunity to win the new Apple iPad Ives Instrument Engineers TESTEQUITY Limited Seating Register Now www tektronix com power2solve cover feature Applying secure programming standards and methodology can reduce vulnerabilities in software Bullet proofing you software design BY NAT HILLARY n August 2003 a rolling blackout affected 10 million people in Ontario and 45 million people in the eastern part of the United States raising concern that a cyber attack by a hostile force was underway Ultimat
71. unction call might look like Listing 1 UART O registers define ULCONO CCunsigned define USTATO CCunsigned define UTXBUFO CCunsigned f volatile volatile volatile UART 1 registers define ULCON1 CCunsigned define USTAT1 CCunsigned define UTXBUF1 CCunsigned f volatile volatile volatile www embedded com embedded systems design MAY 2010 OxFFFFD0O0 OxFFFFDOOS8 OxFFFFDOOC JOXxFFFFEO00 OxFFFFEO08 OxFFFFEOOC 11 orogrammer s pointers UART put USTATO UTXBUFO Maybe passing two registers isn t that bad but what about operations that require three or even four registers Beyond the inconvenience calling functions that require multiple registers invites you to make mistakes such as UART put USTATO UTXBUF1 c which passes registers from two different UARTS In fact the function even lets you accidentally pass a timer register to a UART operation as in UART put USTAT TDATA c Ideally compilers should catch these errors but they can t The problem is that although each macro has a differ ent value they all yield expressions of the same type namely pointer to volatile unsigned Consequently compilers can t use type checking to tell them apart Using different typedefs doesn t help A typedef doesn t define a new type it s just an alias for some other type Thus even if you define the registers as timer regi
72. used as one of the clock inputs to the BCAL The BCAL reference input was wired through one of the FPGA pins to an SMA connector on the board so it could be clocked with an external signal source The BCAL testbench was synthe sized and fitted and the timing netlist was simulated Immediately it was ap parent there was a bug in the design be cause some of the band bits were going into undefined states shown as U in Quartus II The bug came from the asynchro nous comparisons of the counter values to the HIT VALUE After registering these comparison results and retiming the asynchronous data paths to the ref example band calibration run with REF 14 3MHz the band settles to 227 260 BCAL 240 220 n 200 ME ca 180 160 140 120 1 1 E E 0 50 100 150 Time pS Figure 2 26 MAY 2010 embedded systems design www embedded com erence clock the design functionality was Okay in simulation The next step was to load the design onto the FPGA and verify through measurement The testing proceeded by changing the reference frequency generated by the signal source from 10 to 14 MHz in increments of approximately 100 kHz The test setup is shown in Figure 3 At each reference frequency the band cali bration was initiated by a reset tied to a push button Switch debouncing would have made a cleaner testbench but was not necessary Multiple resets caused by the switch
73. ve others look at the tests That could be through pair programming or test reviews Ac tually on some teams we ve decided MAY 2010 33 When it comes to creating your next embedded system an important decision awaits you Memory Your design needs speed reliability performance and capacity to store the code and data your design demands No problem Numonyx has the broadest portfolio of parallel and serial NOR NAND and phase change memory And we offer extended temperature support with 0100 certification on many of our products and expanded design versatility with voltage support up to 5V All designed to deliver a right fit solution to help you shorten design cycles reduce development costs and accelerate the roll out of your next big idea Find out how Numonyx memory matters for your next design 2009 Numonyx B V All rights reserved Includes stacked solutions 1 Available on specific densities rOther names and brands may be claimed as the property of others Product Family Density Range Voltage Solution M325P block erase 512 k 128 Mb single I O M25PX AKB block erase 4 Mb 64 Mb multi 1 0 M25PE M45PE page erase 1Mb 16 Mb av Density Range Voltage Solution 4Mb 2Gb Product Family M29W EW command set page ready P3033 Intel based command set sync burst 64 Mb 2 Gb 1 8 3V core 5 numonyx innovative solutions that d
74. y standard language features Fortunately port mapped I O appears to be gradually fading away and few er programmers need to fuss with it Dan Saks is president of Saks amp Associates a C C training and consulting company For more informa tion about Dan Saks visit his website at www dansaks com Dan also welcomes your feed back e mail him at dan amp dansaks com Traditional techniques for communicating with hard ware devices can be incon venient and error prone Here are ways to make them simpler and robust Several years ago I wrote a series of articles on accessing memory mapped device regis ters using C and C At the time I focused on how to set up pointers in C or or references in to enable access to memory mapped reg isters I followed those articles with another discussing some alternatives for choosing the types that represent the regis ters themselves In the years since then I ve had many discussions with readers and conference atten dees who use other techniques for representing device registers I find that many programmers are still using approaches that are inconvenient and error prone This month I ll compare some popular alternatives fo cusing more on the interface de sign issues than on the imple mentation details MAPPING MEMORY THE OLD FASHIONED WAY Let s consider a machine with a variety of devices including a programmable timer and a couple of U

cover feature

Contents

Download Pdf Manuals

Related Search

Related Contents