Академический Документы
Профессиональный Документы
Культура Документы
This article describes the entire development cycle for a product using an embedded system on an FPGA, from the Engineers perspective.
As every engineer knows, developing an electronics product is a highly detailed and multi-stepped process. From the idea on the back of the envelope through to the working board ready to drop into its housing, there are many tasks to complete and many opportunities to blow the project timeline and budget. On top of this, the engineer must remain up-to-date with technology. It is only by utilizing the most appropriate technology in their designs can they remain competitive and contribute to the success of their company. Altium Designer presents the hardware engineer, the embedded software developer, and the experienced FPGA engineer a genuine opportunity to perform embedded system design in an FPGA, moving it from an inaccessible dream to an achievable reality. This article presents a discussion of how this process might unfold.
Multiple Projects
My controller had three distinct elements the board, the FPGA design containing the processor and most of the hardware, and the embedded application running on that processor. The housing was a given as their project spec included details of overall dimensions and interface locations. Each design you create in Altium Designer gets its own project. What type of project it gets depends upon the implementation. So I created a PCB Project for my layout-bound schematics, an FPGA project for my chip-bound schematic/HDL design and an embedded project for the application software. I then saved them all in the same design workspace, so I could see all of my design documents together and work on different projects at the same time. My first priority was the board since it would take the longest to get prepare. I knew I would have time to finalize the hardware in the FPGA and write the embedded code after I sent my CAM files to the board fab house. If everything went according to plan, I would have the design for the FPGA placed and routed by the time the board was returned for assembly. All of the design documents that would be included in my projects had to be accessed through my companys version control system. Altium Designer made this easy. The Storage Manager panel not only displays each document, but also its status. I could also check documents in and out and using the physical difference tool, even check for changes to the layout of the PCB as I went.
Schematic Capture
On a notepad, I had sketched a block diagram for my board design. The FPGA components (FPGA and config ROM) would connect with a timer, keypad and LCD. If I included a simple JTAG interface, I would be able to hook the production board directly to the NanoBoard and continue development and testing on my real controller definitely worth the cost of a 10-way header I thought. I could use this interface for production programming too. Another block to represent the power supply finished it off. Altium Designer provides an intuitive link between block diagrams and project hierarchy. My top schematic sheet looked just like the diagram I sketched, with each block being a sheet symbol pointing to an individual sheet or a set of sheets. Signals were carried between the sheet symbols along wires or buses, then down through the sheet symbols to ports on the sub-sheets. I could build more detail into the design as I went. Synchronization features would let me easily keep the design hierarchy intact and accurate.
The block diagram becomes the top sheet for the hierarchical design
Component Libraries
I proceeded to populate each sub-sheet with components from my prepared libraries. I have spent a considerable portion of my career developing and maintaining component libraries, and now with Altium Designers integrated libraries, I can package my signal integrity, simulation and footprint models together with the component symbol right from the start. Altiums library development center gave me a head start, providing over sixty thousand components (mostly integrated with models) with my installation. However, that was simply the beginning. Over time, I have developed my libraries to reflect my specific work requirements, matching appropriate symbols to models that I know are available through my suppliers. In fact, I have developed an elaborate system of component control outside of Altium Designer. This has become a massive component database with a separate table for each component family and an array of fields within each table. For example, my table for ceramic capacitors includes part number, manufacturer, capacitance and tolerance values, voltage rating, package and price. Altium Designer allows me to link directly from the components in my integrated libraries to these external database tables and also precisely oversee updates to my libraries or design documents directly. My database information could then be passed into my bill of materials for my prototype shopping list. I searched through Altium Designers libraries for the components I needed but didnt have in my database, then added its findings to the Libraries panel. A handful of components had to be created from scratch. Most were very basic, done in a few moments within Altium Designers Library Editor.
Connectivity
Im not going to describe the details of my pin-to-pin connections, except to say that Altium Designer provides net identifiers and controls that allow me to hook up my design practically any way I can imagine. I like the hierarchy method, which only required that I use appropriate net identifiers at the sheet level and scope instructions at the project level. Other tools helped me arrange and connect my schematics, including snap-grids for placement and connectivity. One thing that happens when you compile your project in Altium Designer is that your connections come alive. The sheet-level hierarchy is displayed in the Navigator panel, as are the components and nets/buses detected in your design, along with all of their associated elements. So no longer do engineers need to scrutinize netlists to review design connectivity. You may jump through each element of each net right at the schematic level. I wasnt finished with these navigation tools though. I would later return, when my board was synchronized with the schematic information and use the cross-probing tools they offer.
Holding down the ALT key as you click in the Navigator panel will highlight corresponding elements in both source schematic and target PCB documents. The current document remains active, so both must be displayed for this to have any visible effect.
Another advantage of using an FPGA was that I could simplify the routing by driving the final pinout from the boards perspective. Being able to manual and auto pin swap in Altium Designers PCB Editor, and then pass pin allocations back to the FPGA design, meant that I could start with any old pin allocation on the board project and resolve this later.
Simulation results may be displayed individually or superimposed upon the same graph.
PCB Preparation
Satisfied (for the time being) with my schematic design, I turned my attention to board layout. Before leaving the Schematic Editor, however, I had to make sure that my schematic design would send all the necessary information to my PCB design. I already mentioned that I had used an integrated library for this project. This means that the schematic parts I used were already associated with the PCB footprints I wanted to use before I even placed them in the schematic design. You get an integrated library when you compile the library package that contains all the source schematic libraries documents as well as the models. Should any mismatches exist between pins and pads, or model names, these will flag as errors in the Messages panel when the integrated library package is compiled. So most of the correlation between PCB and schematic was done before I even created a blank PCB file. If I hadnt made use of integrated libraries, I would have had to take special care that each footprint referenced within my schematic design was available to the synchronizer. Any mismatches between symbol pins and footprint pads would be flagged upon performing the board updates. I generated a PCB file using the template wizard, updated its outline according to my specifications and gave it four signal layers plus two internal planes. Once the bare board was saved and added to my PCB project, I could update it with the components, nets and directives indicated in the schematics.
The Layer Stack Manager shows a cross-section segment of the board. Layers may be added or redefined in this dialog.
Design Rules
I always establish design rules (at least a preliminary set) before even so much as dragging a resistor across my board outline. In fact, many of my rules came from the schematics themselves. For example, I knew when I was wiring up my schematic that I would want certain widths for my power and ground nets, so I placed a PCB directive on each of these nets and defined the width rule right there. When I went to set up the rest of my PCB design rules, I could see that my schematic-driven rules were all included just as I had defined them. They even included unique identifiers in case I made any modifications on the PCB side and wanted to pass the changes back to the schematic. It always makes sense to spend time right up front crafting a complete set of design rules. Not only will the online DRC flag you immediately when violations occur, but Altium Designer will actually prevent you from creating violations in the first place. So specific design rules will serve as reminders and guides as you place and route your board. The autorouter, too, will look to the design rules you have established to know where and how to run tracks. I have developed a set of rules that I keep using in similar projects, such as preferred track widths for signal and power nets, and minimum clearance between components. Instead of starting each set of design rules from scratch, I can import ones Ive already created in similar designs. Another trick I have learned is to save a read-only copy of a blank board with all the design rules set just so, then referencing that board in a template project. Creating new PCB projects from Right-clicking in the such templates not only gives me all my customized project settings, but also the board file with my Design Rule tree allows preset design rules. I spent some time reviewing the design rules, creating a few classes to simplify tasks like specifying clearances around all mounting holes.
you to import and export individual rules.
The design process is highly iterative between the schematic design and the PCB and my set of design rules always continues to develop throughout the whole process. However, I have both seen the benefits of preparing an elaborate set of design rules before layout and suffered the effects of hastily bypassing this step.
Placement
I placed the four buttons (the simple keypad) and the touchscreen toward the bottom of the board. The FPGA went onto the bottom side of the board, leaving me little room to fit the remaining 70 components. This was challenging, to be sure, but nothing out of the ordinary. Place, not space, is the name of the game during board layout. I chose not to use any auto-placement tools for this board, relying instead on the basic ones: snap-grids, connection lines and alignment tools. I dragged the keypad buttons into place, placing them roughly where I wanted them and then used the alignment tools to evenly space them. Then I began arranging components individually, using the connection lines as my primary guide. I watched these lines with the care of a puppeteer as I positioned the remaining footprints, knowing that the quality of route will follow the quality of placement.
Careful attention to the ratsnest of connection lines will yield better placement and therefore easier routing.
This process was simplified by the choice I explained earlier of having a room generated automatically to contain the components of each schematic sheet. I had designed my schematics with the board real estate in mind, trying to keep components that should be placed near to one another on the same sheet. That way they started the board process together and I had less of a jigsaw puzzle to sort out once the footprints were transferred to the board. Instead, I was able to spend most of my time on the fine-tuning.
Pre-route Work
Because this was a medium-cost product and reliability was paramount, I decided on two internal planes one for power and another for ground. Had this been a high-volume consumer product I wouldnt have been able to justify the additional cost of a multilayer board, which would also have affected my choice of FPGA packaging. Without planes, I would have had to do a lot more pre-route work, laying tracks around the board to make power and ground nets more accessible to nodes in crowded areas. As it turned out, my only task prior to routing the board was to place keepout areas where I didnt want any routing to occur. Specifically, I wanted no signal tracks or vias to run beneath the FPGA. I was reserving the area under the FPGA for a polygon fill, which I would later stitch to the ground plane by a grid of vias. This provided an extra ground current return path for the FPGA, reducing RF emissions.
Youll find my thoughts on that part of the process elsewhere in this article but needless to say I am now comfortable designing an embedded system on an FPGA another plus for my engineering consultancy! Since I was developing the PCB and FPGA projects in parallel, and using the in-built features to keep them synchronized, I didnt have to worry about the myriad of detail at the FPGA-to-PCB design interface. The FPGA project was complete enough to pass my comfort threshold, so after doing a final check of the synchronization in the FPGA Workspace map, I ran the auto pin swap feature in the PCB Editor. A few touch-ups with the manual swap tool and I was happy, ready to route the board. Since my FPGA I/O count was relatively low, I was very confident that I could place and route the FPGA design with this pinout.
Autorouting
Instead of autorouting the entire board, I decided to do it in two stages. First, I ran the router with only the fan-out pass enabled. This extended tracks from the active pads on my FPGA. Once the fan-outs looked good, I locked down all my pre-routes and vias, and then ran the router again, this time with all passes turned on. Some clean-up work is always required after running the autorouter, although powerful re-routing tools help by removing loops, straightening connections and cleaning pad entries. Fortunately, Altium Designers push-and-shove capabilities helped me reroute tangled areas while preventing me from violating my own design rules.
CAM Outputs
Once my layout passed all of my design rules, I was ready to generate the artwork for both fabrication and assembly. I required CAM files for the four signal and plane layers, as well as three mechanical layers. A fourth mechanical layer included basic board dimensions, as well as my companys signature logo, so I wanted to merge its contents with all of the other CAM files. I also needed to setup a Bill of Materials report, as well as an assembly drawing and a Pick-and-Place file for board assembly. Instead of configuring each of these outputs separately, I added an output jobs file to my design, which analyzed my design and offered pull-down lists showing the PCBs and schematics in my project. Every output job I needed could be defined here and configured with specific settings and precision. The best thing about the output jobs file is that it offers one-button generation for
Fabrication
Having used the same board house for five years, I knew exactly what four things they would require: the ODB++ fileset with board dimensions around each of the copper layers; a symbol legend alongside a drill map; an NC Drill file and a phone call. In this case, however, my contact at the fab house called me, having discovered some untented vias on the design. My policy is to tent all through-hole vias. My board house uses a liquid photo-imageable soldermask, which actually produces half-tents, meaning that the copper is covered but the hole remains open. This is, in fact, my preferred solution, as it both shields the vias from solder-bridge shorts and avoids the acid pits that can fester under fully tented vias. I was surprised to learn that I had left the tenting option unchecked on a group of vias. My contact made the changes on my approval and I updated my design to keep it in sync with production.
FPGA Design
While the board was being fabricated, I finished the FPGA design. Delaying this until now was a little tricky, since the footprint decal was already being etched across town a bit like pouring a foundation before designing the house to go on top. However, the Xilinx series I had chosen offered a range of FPGAs that would fit on the same footprint. Knowing the approximate number of gates required for this evaluation, I had pre-selected a land pattern that could accommodate parts with up to 1,000,000 gates, far more than I would need. For the soft-core micro, I decided on the TSK52 included in Altium Designer. My 8051 coding skills could be applied and, by selecting the Wishbone variant, I could easily up-scale both the hardware and the software to the 32-bit TSK3000 at a later date, if I needed some serious processing grunt. Also, the Wishbone interconnection architecture made interfacing the processor and its peripherals a breeze. Youve got to love standards when they work for you, dont you! I was almost tripping over myself to get the FPGA design complete. I was so keen to start testing it on the fancy-looking NanoBoard. The NanoBoard is an FPGA development board. Apparently, it is called a NanoBoard because it is effectively a nano-level virtual breadboard. It housed the FPGA (on a removable daughterboard, making it vendor independent), along with a bag full of useful I/O. This one included pretty much everything I needed a touchscreen, some buttons and a CAN interface. All the core-style components that I needed were in the supplied libraries, so I just had to supply the design idea and work through the capture process. And the best bit no verification. From my small amount of previous FPGA design, I had learnt that HDL-based FPGA design took time to master; time that I did not have right now. Once the design was complete, I hooked in the constraint files to map my nets to the FPGA pins and got to work cobbling some simple test code to run on the micro.
The Devices view brings together the FPGA hardware and the embedded application inside the target device.
I walked through the build process with my own design. Sure, it was still missing chunks like the CAN-based comms interface, but that didnt matter for now. After resolving a small naming error between one of my net names and the naming in the constraint file, I was through to the FPGA place and route process. I already had the Xilinx ISE tools installed and was super happy when I realized that Altium Designer completely abstracted away the Xilinx mapping, place and route, and bit file generation stages. I just clicked that big Build button and watched the process in the Outputs panel. As soon as the software finished programming the FPGA on the NanoBoard, I hit the reset button bingo Hello World appeared on the LCD. Talk about rapid hardware development! The only downer was there was no one around to share my excitement with, so I treated myself to a Tim Tam instead. Switching my thoughts back to the embedded code, it was time to build it up to the prototype stage where it could meet the needs of the blood processing machine development team. I needed to dig out that CAN serial comms standard too and brush up on it so I could plug the supplied CAN core into the hardware design with a minimum of fuss. I figured there was one long weeks work ahead, which would put me one month into the project. I picked up the phone and dialed their Project Manager as I had an idea that would make him very happy. They could buy a NanoBoard, I would email him the bit file to program the FPGA and Xilinxs Impact software would program it for them. They would have working hardware one month ahead of schedule.
Pre-Assembly Tests
When my prototype boards arrived, I had to drag myself away from the NanoBoard. My family was complaining about never seeing me, but the promise of doing a cool design that they could play with on the NanoBoard was keeping the kids happy. My board house has a general policy of testing every board it sends out either with a bed-of-nails, which requires a jig to be generated for the board, or with a flying-probe, which is slower but more economical for fewer boards. Having them flying-probe tested for shorts and opens meant that I just needed to go over them visually, looking for any aesthetic issues, like poorly positioned designators.
Assembly
I took the bare boards into my lab, where I have some assembly equipment, nothing really fancy but enough to put my two prototypes together. If I had been mounting a large number of boards, I would have sent them to a proper assembly house with paste-mask dispensers, pick-and-place machines, wave solder apparatus and heat ovens. My two boards, however, were assembled the old-fashioned way, with an iron in one hand and a coil of solder in the other, eyes peering though a pair of 10x magnifying glasses. Some might think it strange that I chose to assemble the first boards by hand, but this was my production engineering phase of the development cycle. Doing this allowed me to determine any component loading order requirements, detect any potential assembly problems and consider how well my thoughts about production testing were standing up. Once the FPGA and all other surface-mount components were fixed to the board, I finished off with the larger, through-hole components, constantly referring to the assembly drawing. Lacking the density of the surface-mount devices, each through-hole component could be soldered without using the glasses. Even at this point, I found I was not done designing. Throughout the process of assembly, I had noted changes and clarifications that I wished to update in my PCB project. For example, I made some minor design modifications on the silkscreen layer where a designator was obscured by overlapping lines. I also wrote a readme file, describing the assembly process I followed for the prototype. Additionally, Altium Designers latest 3D visualization features allow me to create realistic full 3D assembly models of the finished board. This feature can provide that finishing touch for a designer, where you can examine the final, assembled product in almost any amount of detail. Switching from 2D to 3D in the PCB Editor is a piece of cake just use the 3 and 2 shortcut keys to toggle between modes. You will need to have component bodies created in the component footprints to view them. For a quick tutorial on 3D body building and STEP model importing, refer to the Getting Started with PCB Design document.
In Conclusion
Although the controller module for a blood processing machine is a fictitious project, the description of how such a design would be developed by an engineer in Altium Designer is not. To date, embedded system development inside an FPGA has been out of reach for most engineers and an extremely difficult task for those that have done it. Altium Designer goes a long way to changing that. It opens the door for any competent engineer to apply their current skills to the task of developing an FPGA-based embedded system. Not only does it deliver a capture environment, but also coupled with an FPGA development board, it is a complete development environment, where the design can be captured and implemented, then tested and debugged.
Revision History
Date 09-Dec-2003 12-Apr-2005 28-Nov-2005 21-Dec-2007 11-Feb-2008 27-May-2008 Version No. 1.0 1.1 1.2 1.3 1.4 1.5 Revision New product release Reviewed and updated for Altium Designer Reviewed and updated for Altium Designer 6 Added 3D visualisation comment for 6.9. Component body references changed to 3D body. Converted to A4.
Software, documentation and related materials: Copyright 2008 Altium Limited. The material provided with this notice is subject to various forms of national and international intellectual property protection, including but not limited to copyright protection. You have been granted a non-exclusive license to use such material for the purposes stated in the end-user license agreement governing its use. In no event shall you reverse engineer, decompile, duplicate, distribute, create derivative works from or in any way exploit the material licensed to you except as expressly permitted by the governing agreement. Failure to abide by such restrictions may result in severe civil and criminal penalties, including but not limited to fines and imprisonment. Provided, however, that you are permitted to make one archival copy of said materials for back up purposes only, which archival copy may be accessed and used only in the event that the original copy of the materials is inoperable. Altium, Altium Designer, Board Insight, DXP, Innovation Station, LiveDesign, NanoBoard, NanoTalk, OpenBus, P-CAD, SimCode, Situs, TASKING, and Topological Autorouting and their respective logos are trademarks or registered trademarks of Altium Limited or its subsidiaries. All other registered or unregistered trademarks referenced herein are the property of their respective owners and no trademark rights to the same are claimed. v8.0 31/3/08.
10