Tag Archives: DAC



Pretty much every embedded system / FPGA design has to interface to the real world through sensors or external interfaces. Some systems require large volumes of data to be moved around very quickly, in which case high-speed communications interfaces like PCI-X, Giga Bit Ethernet, USB, Fire/ SpaceWire, or those featuring multi-gigabit transceivers may be employed.

However, many embedded systems also need to interface to slower interfaces for sensors, memories and other peripherals these systems can employ one or more of the simpler communications protocols. The four simplest, and therefore most commonly used, protocols are as follows.

  • UART (Universal Asynchronous Receiver Transmitter): This comprises a number of standards defined by the Electronic Industry Association (EIA), the most popular being the RS-232, RS-422, and RS-485 interfaces. These standards are often used for inter-module communication (that is, the transfer of data and supervisory control between different modules forming the system) as opposed to between the FPGA and peripherals on the same board, although I am sure there are plenty of applications that do this also. These standards defined are a mixture of point-to-point and multi-drop buses.
  • SPI (Serial Peripheral Interface): This is a full-duplex, serial, four-wire interface that was originally developed by Motorola, but which has developed into a de facto standard. This standard is commonly used for intra-module communication (that is, transferring data between peripherals and the FPGA within the same system module). Often used for memory devices, analog-to-digital converters (ADCs), CODECs, and MultiMediaCard (MMC) and Secure Digital (SD) memory cards, the system architecture of this interface consists of a single master device and multiple slave devices.
  • I2C (Inter-Integrated Circuit): This is a multi-master, two-wire serial bus that was developed by Phillips in the early 1980s with a similar purpose as SPI. Due to the two-wire nature of this interface, communications are only possible in half-duplex mode.
  • Parallel: Perhaps the simplest method of transferring data between an FPGA and an on-board peripheral, this supports half-duplex communications between the master and the slave. Depending upon the width of data to be transferred, coupled with the addressable range, a parallel interface may be small and simple or large and complex.

The arty board provides four PMOD outputs (JA through JD) along with the Arduino / ChipKit shield connector through which we can interface with peripherals using these interfaces. Over the next few weeks I am going to interface the PModDA4 (SPI) and the PModAD2 (I2C) to the MicroBlaze System that we have created.

The first step is to generate the hardware build within Vivado such that we can interface to the PMODs. We can add in a AXI SPI controller from the IP library and configure it to be a standard SPI driver and not a dual or quad (more on those in future blogs). We can also add in the AXI IIC (remember to search for iic not i2c) controller module and connect it up to the AXI bus, do not forget to add both interrupts to the interrupt controller.



Once both controllers are within the design the next step is to customise for application at hand, with these complete we can assign the i2c and SPI pins to the correct external ports for the PMOD desired.

All that remains then is to build the hardware and write the software, it sounds so easy when we say it quickly.


More things to consider for your prototype


Three things to consider for your prototyping

One of the most exciting stages of an engineering project is when the hardware arrives in the lab for the first time ready for commissioning before integration testing. This typically can mean long hours for all the engineers on the project so how can we try and reduce this time and minimize the issues which may arise.

  1. Think how you will test it from day one – All engineers know the cost of implementing fixes increases as the development progresses. It is more expensive to fix a pin out error once the design has been fixed and manufactured than during an early design review for example. This is the same for testing, thinking of how you will test it from day one and what test equipment you might need.
  2. Think about what to include in the design – During the design of the hardware several design features and functions may need to be included to allow testing of the board with greater ease. The most simple and often implemented test provision is placing test points on all voltage rails Being able to monitor the outputs of clocks and resets is also important, for this reason it is good practice to place test points on the reset line and correctly terminate an unused clock buffer and add test points allowing the clock to be probed with ease. Many modern high performance devices also have on die temperature diodes which can be used during your testing to determine the junction temperature of the die is acceptable, provided you can access these points.
  3. Simple RTL – If you have a complicated design at both the hardware and FPGA level it can be best to develop a more simplified cut down version of the RTL to aid in the testing of the board and the interface between the FPGA and the peripheral. This is especially the case if you are designing high speed interfaces. This cut down RTL could be used in conjunction with chip scope to capture data and block rams which have been pre loaded with data patterns to act as stimulus. This can especially be the case when using ADCs and DACs connected to a FPGA the reprogrammable nature of the FPGA should be utilized to the maximum to develop designs which will allow parametric testing of the ADC and DAC for instance Noise Power Ratio, Spurious Free Dynamic Range and effective number of bit calculations. You should also aim to capitalize on the resources provided by the FPGA  especially system monitor and XADC which can be very useful for monitoring the voltage rails on die and hence helping verify the power integrity analysis

What if it does not go to plan? The first thing to do is not panic, for many issues you will probably not be the first person to face this issue(s) though it may feel like it. Revisit the design schematics, layout and read the data sheets and any errata’s again also have a look on some of the very helpful websites like All Programmable Planet or the Xilinx Forums there are plenty of helpful ones out there.


Things to consider for your prototype


One the most exciting, fun and terrifying stages of engineering is when the first prototypes or engineering models arrive in the lab and are ready for testing. You will have been planning for this day for a long time (hopefully) as the cost of identifying and correcting errors later on in the production run only increases.

Planning for this day will have started right back at the concept of the design as you considered how you would test the functionality being designed into the hardware, FPGA and processors etc. Ensuring you have provided sufficient test points and protected them appropriately (you would hate to short out a rail as you tried to measure the voltage). One thing you also need to consider is accessibility of these test points and debug headers to ensure you can actually access them. Another aspect to consider is how you can test the board on its own will you need any special to type test equipment to enable you to test it, when will it be available.

You will also need to compile a test plan to detail everything you intend to test and the expected results otherwise how else can you be expected to know if performs as required or not.

Once you get the hardware in the lab the testing is generally split into two sections the section is checking the hardware integrity i.e. can it be powered on safely and is it suitable for further testing. During this stage you will check the board has been manufactured and populated correctly, that the voltage rails are safe to turn on and then will come the moment of truth when you have to apply power to the board for the first time. This is always a nerve wracking moment…

Once you have applied power you will be looking at the current drawn against your projections, are the clocks at the correct frequency, does the protection circuitry (over voltage / under voltage) resets and sequencing function as desired. This is the basic engineering tests that will be your first priority however; you will soon progress to wanting to test the more complex interfaces and then the performance.

Some of these may be able to be tested via JTAG / Boundary scan however it is only really testing at speed that you can relax a little (you can never truly relax even after all the qualification testing) It is therefore a great idea to have developed some simple test code for your FPGA or microprocessor to prevent you having to debug both the FPGA/Microprocessor design and the board design. I am sure we have all spent many hours looking into is the issue with the board, FPGA, processor or even worse the ASIC.

Once you have completed the integrity checks you can then proceed to testing the functionality and working out what changes you need to make to the next iteration if any.

Of course at some point I am sure you will encounter problems the most important thing to remember at that point is to not panic and attempt to determine the root cause of the issue even if there is nothing you can do about it on the prototype.


Hardware Considerations – Power Architectures Part One


One of the more interesting aspects to start looking at is the power architecture of a design, and how we go about powering FPGA’s (and other devices) on the board. Normally the system will have an intermediate voltage which comes from an AC/DC convertor or other DC supply which powers the system. The first stage of the design is to correctly specify this interface in terms of voltage and current required by the design. Determining this intermediate voltage is the easier task of the two, as the current required will have to take into account the downstream convertor efficiencies.

The first stage in defining power architecture is the determination of all the voltage rails and currents drawn by each of these rails. For example when considering a FPGA based imaging system as shown below you may have a number of voltage rails


For this example all of the power supplies have a requirement to be within +/-5%.


As can be seen from the table above the highest voltage required is 3.465V which is the 3.3V at its maximum acceptable tolerance. Knowing this value allows us to determine the voltage supplied by the AC/DC or other DC supply within the system, the sensible thing to do here is to select a convertor which has an output compatible with the 3.3V required and save a conversion stage (increasing the overall efficiency).

The next stage is to determine the power required by each of the rails. The requires that you use power estimation tools such as Xilinx XPE and read the datasheets for other devices to ensure you can determine the power required, I tend to collate all of this in a spread sheet as this comes in useful later on once we are determining the conversion architectures.


As you can see above when I have calculated the power required by the board I have performed two calculations the nominal and the maximum power, this is because at this point in time I have not calculated the maximum rail voltages provided in the worse case by the convertors therefore I have assumed they will be at maximum voltage. This is important as it is needed to determine the power required in the worse case by the AC/DC convertor (You should always design to address worse case requirements) while the difference above 146.5 mW is not large it could be in a larger system.

However having determined the load power we need to determine the overall power required including loses in the power convertors before we can specify the power required from the AC/DC convertor or DC Supply.

Having determined the power required by each device the next step is to determine the power required by each rail, this can then be used to determine the conversion architecture, although of course other requirements also come into play to determine this.

Regarding power architecture there are two main types of convertors

Switching regulators, generate the regulated output voltage by switching storage inductors into and out of the circuit to maintain a regulated output voltage when this switching is controlled via either an analogue or digital control loop. With a switching regulator theoretically 100% efficiency is achievable, however sadly the real world intervenes as components are not ideal however efficiencies greater than 90% can be achieved and GAN FET’s promise even better performance.

Linear Regulators generate the regulated voltage by dissipating the excess power across the pass transistor. This is dissipation is controlled via a control loop to adjust for fluctuations, as there is no switching involved the LR is often used where quieter power supplies are required however that does not mean all ripple on the voltage rail is rejected. As can be seen in the image below as the frequency increases the ripple rejection decreases.



Six Aspects to consider designing your PCB


pcbDesigning a PCB for current devices is a very complex and often over looked area instead focus falls upon the more interesting FPGA or Processors. However, the fact remains that without getting the board correct in the first place you may find you have issues either sooner or later so what are the main aspects of a modern PCB should we be concerned about.

  • PCB Stack up – the keystone of the entire PCB this defines the number of layers within the PCB (More layers can increase the cost) along with allowing the engineering team to establish the characteristic impedance on the required layers. This like many things in engineering becomes a trade-off between fabrication processes and layer count to achieve the reliability, yield and cost targets.
  • Via Types – Via’s enable interconnection between the layers and components however, there are many different types Through, Buried, Blind, and Micro (are these single layer, multi-layer or stacked). The best designs minimise the different types of via, close discussion with your selected PCB supplier is also important to ensure you’re via types are within their capabilities. You will also need to ensure the current carrying capacity of the different via types to ensure for high current paths you can parallel up.
  • Design Rules – These will address both rules for the design i.e. component placement, crosstalk budgets, layer allocation, length matching / time of flight analysis and so on. It will also include design for manufacture rules which ensure the finished design can actually be manufactured for instance are the via aspect rations correct.
  • Breakout strategy – before you can begin to verify your signal and power integrity you must first ensure you can break out and route all of the signals on high pin count devices. This will also affect the stack up of the PCB board for instance should you use micro via break out (most probably yes), how deep should these be is stacked micro via required. Once you have a defined stack for the PCB you can think of your routing strategy will it be the traditional North South East West, a layer based breakout or a hybrid style.
  • Signal Integrity – the most commonly considered aspects of designing a good PCB typically an engineer will consider aspect such as signal rise and fall times, track length and characteristic impedance, drive strength and slew rate of the driver and termination. To ensure the best performance SI simulations will be performed pre layout and post layout of the PCB, you will also need to consider the Cross talk budget.
  • Power Integrity – high performance devices especially modern FPGA and ASICs can require large currents at low voltages. Ensuring both the DC and AC performance of the power distribution network is of vital importance

Of course the list above is by no means complete however, it provides a good starting point


The Engineers Guide to using ADCs and DACs issue 80



Once it’s performed the task it
was designed to do, an FPGAbased
system next has to interface
with the real world, and as every
engineer knows, the real world tends
to function around analog as opposed
to digital signals. That means conversion
is going to be required to and from
the digital domain from the analog
realm. Just as you face a plethora of
choices in selecting the correct FPGA
for the job at hand, so too will you find
an abundance of riches when choosing
the correct ADC or DAC for a system.

Link here