An Overview of Electronic Product Development in Altium Designer

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.

One-Stop Electronic Product Design Environment

A medical research firm recently hired me to design a controller module for a blood processing machine. The controller module did not require a lot - a simple keypad and a touchscreen LCD for I/O, a reasonable processor for operator instructions and machine-response processing, and a CAN based comms interface was all the specification called for. The challenge was that they wanted it to support a range of blood processing machines that they had, and for the design to be flexible enough so it would only require a firmware update to cater for new technology they had in their research pipeline.

They had one last requirement - like most of my clients, they needed the controller yesterday! They wanted a working prototype within two months for the blood processing machine development team to keep them on track. I could then polish and finalize the controller in parallel with their development.

These requirements, along with the allowed production costing models, suggested to me that I should consider using an FPGA-based embedded system for the controller. By embedding the processor, touchscreen LCD controller and the CAN communications system inside an FPGA, I could keep the bulk of the design in a mutable or soft form, maximizing the flexibility and lifespan of the physical PCB while still keeping the development timeline tight. Conceptually this sounded great. The only hitch was that I had no experience designing an embedded system inside an FPGA.

Since I was already designing my hardware using Altium's board-level system design offering, and I had heard the Altium Designer system also supported designing an embedded system in an FPGA without requiring a PhD in HDL coding and verification, I visited their website to explore this option some more.

Digging deeper into Altium Designer's FPGA capabilities I discovered that Altium's new FPGA development board, called NanoBoard 2, actually included a touchscreen LCD and a CAN interface on board. That meant that I could probably implement most of my controller module right on the development platform - definitely a major bonus when the development schedule was so tight. This was the clincher. I decided that, all factors considered, this solution offered the lowest overall risk - I would go for it!

Luck was on my side too. There was an opening in an Altium training course that would rapidly ramp up my embedded system in FPGA skills, so I factored that into my project costing and booked a spot. A quick phone call and my credit card extended my Altium Designer license to include embedded FPGA design capabilities and my new NanoBoard was on the way. Time for me to take the system design out of my head and start roughing it out in the Altium Designer environment.

Multiple Projects

Main article: Project Management

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 company's 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

Main article: Schematic Editing Essentials

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.

Component Libraries

Main articles: Component, Model and Library Concepts, Using Components Directly from Your Company Database

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 Designer's integrated libraries, I can package my signal integrity, simulation and footprint models together with the component symbol right from the start.

Altium's 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 Designer's libraries for the components I needed but didn't 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 Designer's Library Editor.

Connectivity

Main article: Connectivity and Multi-Sheet Design

I'm 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 wasn't 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.

Another advantage of using an FPGA was that I could simplify the routing by driving the final pinout from the board's perspective. Being able to manual and auto pin swap in Altium Designer's 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.

Verifying the Design

Main article: Verifying Your Design in Altium Designer

The other result of compiling a project in Altium Designer is an electrical rule check. This is highly configurable, as you may stipulate which scenarios you want to flag and how serious you consider them to be.

Even when time is tight, I am a stickler about producing a clean ERC before sending information over to the PCB. I carefully set No-ERC directives on every unused pin, thus detecting any unintentionally unconnected input pins when I compiled. The messages that appear upon compile are more than just descriptive; they're interactive. Double-clicking on a specific message will list relevant primitives in a floating panel as links, which will let you jump between them in the workspace. This lets you discern and resolve each error quickly. Recompiling the project will show if your previous errors have been fixed, and if any new ones have been created.

After running a clean ERC, I simulated the timer portion of my design. I ran two signals (trigger input and clock output) through a transient analysis to make sure that the required signal would be generated as expected.

Of course, a simulation requires that each contributing component have a valid SPICE model that is appropriately mapped to the symbol's pins. This can be done either at the library level or within the captured schematic. Signal integrity tests are not as stringent (having a formally established protocol) and allow generic models to be substituted where no specific model is indicated.

PCB Preparation

Main article: Preparing the Board for Design Transfer

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 hadn't 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.

Passing the Design to the PCB Editor

My board held no footprints as of yet, so the transfer of the design from the Schematic Editor to the PCB Editor was simple. I selected the Update command to generate a set of ECOs that added all footprints, component classes, nets, net classes and room definitions to the bare board.

Since my library panel contained the same integrated libraries, from which I had populated the schematic, and because each schematic symbol I used had a valid footprint matching pads to pins, I was confident that I could proceed without much to worry about. Still, as a matter of course, I ran a check to validate each of the proposed changes before executing them.

As the board was updated, footprints were arranged alongside the board, each within a "room", as I had retained the default setting of grouping components from each schematic sheet together. While schematic-based rooms don't make sense on every board I design, such cases are becoming rarer, as I have begun designing my schematics with the PCB in mind, grouping symbols in much the same way as they should be arranged on the board.

Each electrical pad in my design is linked to at least one net companion by a connection line. This ratsnest of "From-Tos" will be my primary aid in the big job ahead - component placement.

Design Rules

Main article: 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 I've 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 such templates not only gives me all my customized project settings, but also the board file with my 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.

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.

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 wouldn't 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 didn't 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.

Splitting Power Planes

Main article: Internal Power and Split Planes

Although I had dedicated an entire internal plane for my power nodes, not all of these nets were of equal voltage. The PCB Editor allows internal planes to be sub-divided for different nets sharing the same physical layer.

First, I assigned 5V as the default net for the plane. Then I ran the split-plane option, carving an area around all the 3.3V nodes, then another around all the 2.5V nodes.

Optimizing the FPGA pinout

Main article: Linked FPGA-PCB Project Changes - Pin Swapping in the PCB Document

I am getting ahead of myself now I thought, aren't I. Before I could route the board I needed to ensure my FPGA design was nailed down to the point where all the I/O was finalized, then I could optimize the FPGA pinout for routeability.

After browsing the resource usage files included in the software for the various cores I needed, I decided on a 400K gate Xilinx Spartan-3 in a 256 pin BGA package. It was the mid-sized device in a series of three available in this package, giving me room to downsize or upsize should I need to.

You'll 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 didn't 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.

Routing

Main articles: PCB Routing, Situs Autorouting Essentials

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 Designer's push-and-shove capabilities helped me re-route tangled areas while preventing me from violating my own design rules.

Design Rule Check

Main article: Design Rule Checking

With the online DRC enabled, I had monitored my design for violations from the start. In addition, all of my design rules fell within the auto-router's scope, so I didn't expect to see many errors at this point. I had, however, done some manual placement and post-route clean-up work, so I knew that there had been some room for mistakes to be made. In any case, I have long since learned not to skip the step of checking my design for errors before generating final artwork.

The PCB Editor's panel lists the rules and any errors categorically, for example, unrouted nets were listed as broken and connections between nets were listed as short circuits. Browsing through the list of violations, I could zoom in on each error, discover what caused it and decide what to do about it. Each error disappeared from the list as soon as it was resolved.

CAM Outputs

Main article: Design to Manufacturing

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 company's 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 the whole lot (printed and CAM files alike). On the other hand, you still have the option to create individual or selected output jobs instead.

All CAM outputs were saved on my hard drive, where I could make copies to email to the board house. Before doing so, however, I followed my career-long policy of checking them myself. Altium Designer includes a full CAM editor for viewing and manipulating CAM data, and with it, I scrutinized each layer of information that my board house would see.

Once the files all checked out, I emailed them to the board house.

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

Main articles: Soft Design, Processor-based 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. You've got to love standards when they work for you, don't 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.

Developing the Embedded Software

Main articles: Tutorial - Getting Started with the Software Platform Builder, Introduction to the Software Platform

After skimming through some of the design examples included in the software, it took me no time to organize a shell embedded project. Not particularly innovative mind you, but hey, displaying 'Hello World' on the LCD would do for starters. I jumped back to my FPGA project and hooked a logic analyzer onto the data bus, just in case nothing happened when I flicked the switch.

Who'd Have Thought - LiveDesign

Main article: Testing and Debugging

After downloading a couple of the example designs into the NanoBoard, I started to get a sense of what I was working with and appreciate what Altium meant by 'LiveDesign'. Here, on my desk was a 'live' hands-on engineered development environment where I could run real software, on real hardware, in real time. Phew, this was so much better than my university tutorial days - not only could I single-step through the code in debug mode, I could modify the actual hardware, rebuild the design and download it in the space of a few minutes. People don't always appreciate it, but the biggest part of the product development cycle is not designing and coding, it is testing and debugging, and here in front of me I had everything I needed to do this right now - components to wire up, virtual instruments to test hardware with, and a debugger to iron out the problems in my code.

I walked through the build process with my own design. Sure, it was still missing chunks like the CAN-based comms interface, but that didn't 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 week's 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 Xilinx's 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 Designer's 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.

Basic Hardware Testing

Once the boards were assembled, I ran some basic electrical tests. Using a CRO, I tested each rail for the proper voltage, each oscillator for the proper frequency, and each switch on the keypad for the proper signal. I also ran down my bench supply to ensure that the board would shut off at an appropriate level.

Moving the Design to the Production Board

At the moment, I had a board that was pretty dumb. It included an LCD, some buttons, an oscillator, the power supply, a couple of connectors, and a blank FPGA. It was time to load in the heart of the design, the embedded system inside the FPGA.

I was about to be greeted by yet another pleasant surprise - the ease at which I could move the design from the development board onto my prototype production board. I had copied and pasted the standard JTAG interface from one of the reference designs into my board design, so, according to the Altium Designer documentation, all I had to do was use the supplied 10-way ribbon to connect from the NanoBoard to my board. With some trepidation, I connected the ribbon cable between the boards and pressed F5 to refresh the view in the Altium Designer Devices view (command central for working between hardware design, the embedded project and target device).

And there it was, next to the NanoBoard's FPGA was the FPGA on my board and the config device. Feeling confident, I decided to unplug the FPGA from the NanoBoard so that I would only be working with my target FPGA. Reconfiguring my design to use the simple 'Hello World' test code, I clicked the Program button in the Devices view and watched as the design was re-processed for the product board. The only change was the internal mapping from the nets to the FPGA pins. As soon as I saw the Place and Route light go green, I knew I was on the home straight. 'Hello World' appeared and I looked forward to completing my project, ahead of schedule and under budget.

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.

See Also

• Getting Started with Altium Designer
• Quickstart - the Environment & Projects
• Quickstart - Schematic Capture
• Multi-sheet design
• Quickstart - PCB Layout
• Quickstart - Creating Components
• Quickstart - Soft Design, software
• Quickstart - Soft Design, hardware
• Developing the Application
• Interfacing to Altium Designer from SolidWorks