May 26, 2016 – Big Bike Ride for Heart and Stroke Foundation

BigBikeLogo Ride Big. Live Big.Big Bike Tshirt logo

On May 26th, 2016, the Fidus Flyers team set out on a 2km bike ride on the famous 30 seater Big Bike.

Cardiovascular disease is a leading cause of death for Canadian men and women.  And we are very proud of the $2,425.00 Fidus raised for Heart and Stroke Research.

Fidus was one of the top fundraisers in Kanata North contributing to the total $11,479.00 raised in the Kanata North Community.

Fidus dedicated this year’s Big Bike ride to the late Virginie van Ravenswaay.  Our deepest sympathies go out to her family and friends. Her strength, unwavering love and bravery will always remain an inspiration to us all.

DSCN3752cropped        IMG_2108

May 6, 2016 – Fidus Attended the Embedded Systems Conference and BIOMEDevice Expo in Boston

ESCFidus attended the  Embedded Systems Conference and BIOMEDevice Expo on May 6th! The Embedded Systems Conference (ESC) is the industry’s largest, most comprehensive technical conference for embedded systems professionals in the US.

The ESC Boston Technical Conference Program consists of 8 tracks covering all aspects of embedded systems design, from concept development through to prototyping, debugging, and manufacturing decisions. ESC is offering a full program of technical training, post-mortems, teardowns, and hands-on sessions, allowing us all to absorb practical, actionable information to cut time, money, and complexity out of the embedded development process.

Read More

The Demo Hall  showcased vendors with new products one could use or evaluate head-to-head for potential future use.

ESC Conference Tracks:

Connected Devices and the IoT | Embedded Software Design | Hardware:

Design, I/O and Interfacing | Prototyping | Embedded Systems Design | Software: Design, Languages, & Quality | Fantastical Theater | Teardowns |

BIOMEDevice_MTW_NE_4cThe BIOMEDevice Expo will be showcasing the latest industry innovations and emerging technologies, including:

Manufacturing Equipment | Cleanroom & Sterilization | Contract Manufacturing | Design Services | Electronic Components | Medical Grade Materials | Packaging & Labeling | 3D Printing | and Testing & QA/QC |

This event includes a 1 day conference on wireless device technology, a full day on quality control and assurance content, 3D printing presentations on both days of the event, and a 75 minute session on medical device design.

There will be dozens of prominent speakers attending, including representatives from Deloitte Consulting, Intel, Medtronic, Philips Healthcare, Smith & Nephew, Stratasys, Stryker, UL and numerous universities.

Both of these events are occurring at the Boston Convention and Exhibition Center.

April 18-21, 2016 – Fidus will be attending NAB Show

Hi! I’m Scott Turnbull, Director of Technology at Fidus Systems.

I would like to personally invite you to visit Fidus at the NAB Show, in the Las Vegas Convention Center from April 18th to 21st.

Don’t know Fidus yet? Think of us as your high-speed, high-complexity electronic design services partner that gets your products to market faster.

We’ll be showing off some of our 4K and 8K developments, featuring 12G-SDI, HDMI4K, and Xilinx FPGAs. Get a glimpse of our new 12G-SDI Gearbox, or as we call it, the Gearbox “plus”. Find out why when you stop by.

Use the passcode below for free entry into the exhibits and use Fidus to get your products to market faster.

See you at NAB!


Dates: April 18-21, 2016
Location: Las Vegas Convention Center
Booth #: N5520 (North Hall)
Free Exhibits Registration Code: LV4629
Contact: Scott Turnbull (

How to Correct Interleaving Issues With the Althea 5GSPS FMC Card

Do you ever find yourself running into interleaving issues while using a system with multiple analog-to-digital converters? There can often be differences in gain or phase between the two or multiple channels that are involved with the capture. Fidus and ADI have created a 5GSPS FMC card which works on a multiple analog-to-digital converter that can also correct any unwanted interleaving products. The video above is a live demonstration of how the Althea 5GSPS FMC Card has interleaving correction logic that makes unwanted interleaving spurs disappear.

You can watch how the interleaving spurs appear when the interleaving correction is turned off. The unwanted spurs can be difficult to get rid of so the Althea card proves that it is piece of next generation technology that will be useful for all of your multiple analog-to-digital converters.The Althea 5GSPS 12-bit, JESD204B ADC based FMC is a powerful solution for your prototyping and limited production needs. Visit our products page here for more information about this FMC card, as well as our other FMC and A/D Converters that we offer.

DDR4 Address bus Interconnect Optimization – Syed Bokhari

Abstract— This paper presents an investigation of Signal Integrity of the address bus in a DDR4 memory application. The fly-by topology is simulated at the highest DDR4 switching rate of 1.6 Gbps in a configuration comprising 8 memory devices. Interconnect impedance optimization is carried out to maximize eye opening. A new termination scheme that results in a reduced pattern dependent jitter is described. It consists of the use of series end termination resistors. Numerical results of the effect of trace impedance and termination resistor location are presented.

Presented at the EMC & SI conference, 2015.

Keywords— DDR4, Fly-By topology, series termination, Signal Integrity, Eye diagram, Jitter.

DDR4 technology [1] has enabled single ended signaling at data rates as high as 3.2 Gbps. The two main category of buses involved are the data and address, command and control buses. The data bus comprises several byte lanes. Each byte lane includes 8 data bits (termed DQ), a data mask bit (termed DM) at data inversion bit (termed DBI) and a differential strobe (termed DQS). The differential strobe will operate at a frequency of 1.6 GHz. Both the rising and falling edges of the differential DQS bit are used to latch the remaining bits in the byte lane.

The address, command and control bus comprises a differential clock and a number of address, command and control signals. The differential clock operates at a frequency of 1.6 GHz. All address command and control signals are latched only at the rising edge of the clock and consequently their effective rate is 1.6 Gbps.

All signals are connected from a memory controller (Cont.) to each memory device (U1, U2,…). In a single rank memory system, the data bus is a point-to-point bi-directional connection between the memory controller and each memory device. Both the controller and memories have On Die Termination (ODT) and an output impedance that is controllable in discrete steps. Consequently, when a controller is writing data, it can be programmed to use an optimum output impedance and ODT value. This results in a near ideal situation of perfect match enabling extremely high speed data transfer.

Figure 1
Fig 1. Address net topology

The address bus, on the other hand is a multipoint uni-directional connection from a controller to the memory. Therefore, unlike the data bus, the design of this interconnect can be challenging. Signal integrity is ensured by using what is termed a “fly-by” topology with a far end pull-up termination as shown in Fig. 1. The “fly-by” topology is essentially a daisy chain connection with a very short stub. A similar topology is used for the differential clock net as shown in Fig. 2. The eye diagram of the address signal at each memory device must have adequate amplitude and width for an unambiguous detection. It must also be synchronous with respect to the rising edge of the clock signal. The clock signal is required to have an adequate amplitude and a monotonic rising edge. The goal of the interconnect design is to ensure that these requirements are met by a proper choice of interconnect impedance, trace length and termination values.

Figure 2
Figure 2: Clock net topology

First, the case of an interconnect with uniform trace impedance is simulated and is used as the reference. Next, an optimized interconnect impedance case is simulated. In the last two examples, series end-terminators are used to illustrate the benefit. All simulations in this paper use a linear model for the controller with an output impedance of 40 Ohms and a high input impedance model that is typical of memory input pins. PCB thickness is 80 mils and via stub length = 50 mils.


A straightforward implementation consists of routing the entire interconnect with a uniform trace impedance of 50 Ohms. Eye diagrams at all the memories are shown in Fig. 3. It can be seen that the waveform integrity is usually the best at the last device closest to the pull up resistor. The first and intermediate devices are more strongly affected by reflections and will exhibit increased jitter and a reduced amplitude.

Figure 3
Fig.3. Case 1: 1.6 Gbps Eye diagrams at the 8 memories (TL1 = 3500 mils, impedance = 50 Ohms, TL2 = TL3 = 1000 mils, impedance = 50 Ohms, STUBS = via with a long stub and a trace length of 100 mils, 50 Ohms trace.


It is easily possible to optimize by ensuring that stubs and the trace segments TL2-TL3 have high impedance and keeping the impedance of TL1 at a low value. A practical value of low impedance is 25-40 Ohms and high impedance is 50-60 Ohms. Eye diagrams at all the memories are shown in Fig. 4. An improvement in Eye opening, in particular amplitude, is noticeable as compared to Figure 3.

Figure 4
Fig. 4. Case 2: 1.6 Gbps Eye diagrams at the 8 memories (DTL1 = 3500 mils, 40 Ohms impedance, TL2 = TL3 = 1000 mils, 50 Ohms impedance, and , STUBS = via with a long stub and 100 mils of 50 Ohms trace.


A typical interconnect involving 4 memory devices is shown in Fig. 5 for display clarity. Breakout from the controller and at each memory device requires a via. A short trace segment is also invariably required at each memory pin except in situations where blind vias are used. This constitutes a stub as shown in the inset of Fig. 5. Reflections from each memory device degrade waveform integrity.

Figure 5
Fig. 5. Enlarged view of an address interconnect on PCB
Case 3: 40 Ohms resistance placed at R2
Case 4: 40 Ohms resistance placed at R1

Reflections in transmission lines can be reduced or eliminated by using passive termination elements [2]. Commonly used terminations consist of series resistors placed close to the source, and shunt terminations placed close to a receiver. In this work, the use of a series resistance placed close to a receiver is investigated. Basically a resistance of a value equal to the transmission line impedance will combine with input capacitance of the receiver and act as an RC termination reducing high frequency reflections.

Therefore, if a discrete resistance can be placed at the precise location of the stub, namely R1 (hypothetical), one would expect an attenuation of the reflected signal. Alternatively the resistor can also be placed at R2 which is more realistic. Simulated results for both locations for the resistance of a value = 40 Ohms are tabulated in Table I. The waveforms for Case 3 only are shown in Fig. 6. Those for Case 4 cannot be visibly distinguished and are omitted.

It can be seen that the use of resistive end termination is most effective at the position R1. Placement at the position R2 will also yield an improvement in the eye opening although with a slightly reduced performance. Both cases show a substantial reduction in jitter. The value of the termination resistance also plays an important role. If the value is too large, amplitude reduces and affects noise margin adversely although there will be a reduction in jitter. If the value is too small, both jitter and amplitude increase. A value in 40-50 Ohms range is found to be best suited.

It is also of importance to determine the effect of end terminators on the clock waveform. In simulations, the topology of the clock net is identical to that of the address net and trace lengths are also identical, i.e., DTL1 = TL1, DTL2 = TL2, and DTL3 = TL3, and DSTUB = STUB in Figures 1-2. This is required to ensure synchronism between the clock and address net. The differential transmission lines are treated as two single ended uncoupled lines. The differential impedance of DTL1-3 and DSTUB is simply twice that of TL1-3 and STUB. Figures 7 and 8 show one cycle of the differential clock waveform for cases 2 and 3. Other cycles are suppressed for clarity. It can be seen that the waveform amplitude is more attenuated at the last memory device for case 3 although the requirements are still met.

Lastly, the impact of optimization on the relative delay between clock and data nets is analyzed. Figure 9 shows the strep response of both clock and data nets for case 2. It can be seen that the clock is delayed with respect to the address net and the delay increases as one moves away from the controller. In this case the delay difference is 106-12 = 94 pS.

Figure 10 shows the step response of both clock and data nets for case 3. It can be seen that the clock is delayed more due to the resistive loading. In this case the delay difference is 120-32 = 88 pS, which is less than that of case 2.

In both cases, the clock can centered by making DTL1 to be ~50 pS longer than TL1. There is no significant signal integrity benefit in using series end terminations on the clock net although it would certainly help in reducing radiation.




Table 1


Figure 6
Fig. 6. Case 3: 1.6 Gbps Eye diagrams at the 8 memories (TL1 = 3500 mils, 40 Ohms impedance, TL2 = TL3 = 1000 mils, 50 Ohms impedance, and , STUBS = via with a long stub and 100 mils of 50 Ohms trace, 40 Ohms series end termination resistors placed at position R2 at each memory device.

Figure 7
Fig. 7. Differential Clock waveforms for case 2

Figure 8
Fig. 8. Differential Clock waveforms for case 3

Figure 9
Fig. 9 Step response of clock and address net for Case 2. (Address waveform offset by 1 V for clarity)

Figure 10
Fig.10. Step response of clock and address net for Case 3 (Address waveform offset by 1 V for clarity)


In this work, signal integrity of the address bus in a DDR4 memory system is investigated. It is shown that jitter can be reduced by using series end terminators at the memory devices. Implementation of such a scheme using discrete resistors would become impractical due to space constraints. This can be circumvented with the use embedded passive resistors. The termination technique is also useful in other applications involving multi-point buses. In particular, it can ensure monotonic clock edges, and also help in reducing radiation without compromising waveform integrity significantly.

Syed Bokhari of Fidus Systems

[1] DDR4 SDRAM Standard, JEDEC JESD 79-4, September 2012. [2] Brian Young, Digital Signal Integrity, New Jersey: Prentice Hall, 2001, Chapter 2.

January 19-21, 2016 – Fidus attended DesignCon


The DesignCon Technical Conference Program consists of 14 tracks covering all aspects of electronic design, from chips through boards and systems.

Through more than 100 technical paper sessions, panels and tutorials, conference attendees gather the latest theories, methodologies, applications and advanced design tools related to signal integrity, power integrity, jitter, crosstalk, test and measurement, parallel and memory interface design, ICs, semiconductor components and more.

DesignCon 2016 will be host to three insightful, informative and inspirational keynotes from industry luminaries.

Selected through a rigorous review process conducted by the Technical Program Committee, DesignCon speakers constitute an elite group of practicing engineers, offering leading-edge case studies, technology innovations, practical techniques, design tips and application overviews.


September 10-15, 2015 – Fidus attended #IBC2015


IBC unites the technologies and business models powering the creation, management and delivery of all forms of electronic media content to consumers in a world where content is everywhere.

From OTT delivery, mobile TV and Cloud production to the economics of Ultra HD, digital cinema innovation and the rise of social television, IBC sits at the forefront of all the recent major changes in the industry.

IBC sits at the global crossroads of the electronic media and entertainment industry and provides a full and vibrant experience, whether you are a student or CEO, an innovative start-up to media superpower. Held at the world-class venue, the Amsterdam RAI, every September, it is always at the forefront of industry innovation and provides unrivalled networking opportunities. Join 55,000 attendees from more than 170 countries for IBC2015 between 10 – 15 September.

The IBC Exhibition covers fourteen halls across the RAI and hosts over 1,700 exhibitors spanning the creation, management and delivery of electronic and media entertainment. Integral to your IBC Experience are a number of specially curated Feature Areas and events. These are hosted throughout the IBC Exhibition and tie into the IBC Conference to enrich your understanding of technologies and trends that are driving the industry.

The IBC Conference is an unrivalled global destination for discussion and debate about the many different challenges facing the electronic media and entertainment industry, both in its sessions and in the range of networking opportunities it affords. Featuring some of the foremost thought-leaders, innovators and policy makers in their fields and covering a wide breadth of topics, it is the place to explore new strategies, understand business disruptors, chart future technological progress and uncover the future roadmap

August 4, 2015 – Fidus Attends TechTuesday

tech Teusday
The Summer Beat Goes On!

Tech Tuesdays is a networking event held on the first Tuesday of every month for Ottawa’s high-tech community. It is sponsored by the Wesley Clover Foundation.

Tech Teusday has a terrific turnout for their annual BBQ in July! Fidus was able to attend the latest Tech Teusday event on August 4th.

Date: Tuesday, August 4th, 2015
Time: 5:00 p.m. – 8:30 p.m.
Location: The Marshes Golf Club, 320 Terry Fox Drive, Kanata
Cost: No charge

July 19, 2015 – Fidus works with Xilinx® SDSoC™

The Xilinx SDSoC™ development environment is a member of the Xilinx SDx™ family that provides a greatly simplified ASSP-like C/C++ programming experience including an easy to use Eclipse IDE and a comprehensive design environment for heterogeneous Zynq® All Programmable SoC and MPSoC deployment. Complete with the industry’s first C/C++ full-system optimizing compiler, SDSoC delivers system level profiling, automated software acceleration in programmable logic, automated system connectivity generation, and libraries to speed programming.

To access the capabilities of SDSoC, please visit

Fidus Systems is an SDSoC development environment-qualified Xilinx Alliance Member, and a Xilinx Premier Design Services member, offering electronic product development and design services.

Xilinx® SDSoC™ – The First Encounter

As a Xilinx® Premier Design Services member, Fidus is always working with Xilinx’s latest and greatest hardware, tools, and methodologies. This time, we got our hands on an Early Access license for Xilinx’s brand new SDSoC™ development environment and began working with the tool. As Xilinx prepares for general release of the SDSoC development environment, here is a story of our very first SDSoC undertaking.

Below are the candid memoirs of Dessislav Valkov, Fidus Team Leader. Enjoy!

Read More

Use the SDSoC development environment to move an open source AES-256 encryption algorithm from ‘C’ into hardware, to facilitate the comparison of software execution time vs hardware execution time on Xilinx’s Zynq® SoC.

Avnet® Zedboard™ (Note: although Zynq contains dual ARM® Cortex™-A9 cores, I only made use of a single core, running at 667MHz)
OS: Windows 7 (see story)
Software: Xilinx SDSoC 2015.2 development environment

A few years ago we had the chance to work with, what was at the time, a brand new tool from Xilinx called HLS (High Level Synthesis). The goal of HLS was to compile native C/C++ to synthesizable HDL, thus enabling software developers to take advantage of the benefits of FPGAs. Various companies had tried making these types of tools in the past, albeit with mixed success. We concluded that HLS worked well, although it still had a steep learning curve for a software developer, and thus, typically still required some hand holding by the FPGA specialist.
Today, SDSoC has embedded the design flow into an Eclipse based IDE thus allowing software designers to target hardware in a familiar and much more abstracted environment. The tool can also intelligently partition the algorithm into software and hardware, then select the interfaces between the application and the translated HDL functions, and finally, automatically build a Linux or bare metal (just to mention the big two) SD card image. All of this strives to make the whole design process seamless to a SW developer.

“Here’s what I did”
1. Obtained and installed SDSoC 2015.2 from Xilinx

    a. It requires a separate license which had to be installed as well using the standard Xilinx license manager.
    b. Worth mentioning that the tool seemed to have some stability issues on RedHat 6.6 and so with great reluctance I had to install it on Windows 7 where it was performing as expected. It is a brand new tool and that probably makes some sense, although I was expecting it to be the opposite.

2. Configuring the environment is straight forward and similar to the other Eclipse based SDK tools from Xilinx.

      a. First I had to configure the Linux TCF Agent to connect to my Zedboard IP; establishing the debugging communication channel.

b. After that, I had to configure the debug configuration with the TCF Agent, and the local and the remote .elf file location. Interestingly, sometimes the tool found the three settings automatically, but most often I had to do it manually. I also noted that the Zedboard DHCP always picked an IP already in use my some other machine, so I had to assign it manually after each reboot. I didn’t look into this, so it’s probably just me.

3. After experimenting with some of the example projects provided with the tool, I was ready to tackle the mission code. To be fair, it was a really refreshing experience. Everything worked as promised in the three YouTube tutorials (see links below). How often does that happen?

4. It was decided that we should try to optimize the same code we tried back then on Vivado HLS. After downloading the freely available AES-256 from the web, coding a simple top level calling function, and trying to compile it with SDSoC, it became clear that there are some new rules which should be followed. The pure C++ compilation was completing without any errors, but when I assigned the AES-256 function to be implemented in hardware, SDSoC complained about a couple things:

      a. It could not find the body of the AES function, because it was in a separate file from the calling function. Obviously SDSoC wants to have all functions dedicated for implementation in HW in the same file. An easy fix.

b. Next, SDSoC didn’t like the function parameters which were declared like pointer to arrays:
void call_aes_rtl(uint8_t * key, uint8_t * message, uint8_t * cipher);
This is understandable since a function implemented in hardware must have rigidly defined parameters passed back and forth, since hardware cannot accommodate on the fly the pointers to potentially different sized arrays. The C++ compiler didn’t have problems deriving the array sizes from the code, but SDSoC compiler needed something more explicit in the parameters declaration:
void call_aes_rtl(uint8_t key[32], uint8_t message[32], uint8_t cipher[32]);
Although to a software guy this might not be a very common way of passing arrays, this was exactly what was needed. Thanks to the example projects it was easy to find out what the tool was expecting.


Compiling HLS can be quite involved. For example, back in the day, we had to define the function’s parameters as ports using the special HLS #pragma properties. This told the HLS compiler exactly how to implement every parameter as a port – Master/Slave port, AXI-Lite, AXI-FIFO, AXI-ACP, etc. SDSoC can also use the #pragma for fine tuning, but even without additional effort it immediately recognized the ports and picked the best fit. In our case, SDSoC picked AXI-FIFO for each one of three ports, since the three ports had to transfer arrays of 32 elements each. I was relieved how well SDSoC completed this task.


      c. Running SDSoC is quite intuitive, and software like, in the way that it handles debugging, code stepping, and variable updates, on the active platform. In addition to the standard SDDebug and the SDRelease configurations, Xilinx have added a new one called SDEstimate. SDEstimate can offer insight into the speed improvements one could expect by pushing a function into hardware, prior to undertaking the actual HDL compilation, testing, and, benchmarking.

d. To be fair, as an HDL designer I could not stop myself from optimizing the C code just a little. In the original code, the AES function was working with the three arrays directly in the memory, with many reads and writes occurring during the message encryption/decryption cycles. My background told me that when moved to hardware these unnecessary accesses over the AXI interfaces will be very detrimental to the total performance, so I decided to copy the three arrays locally to the AES function, thus limiting the access over the AXI-FIFO interface only to the initial vectors loading and result unloading – three arrays of 32 elements each.

e. Then I had to copy the already prepared SDcard image containing a light Linux distribution, together with the files needed to run my Linux application. Just drag and drop the SDcard folder to the SDcard, insert the SDcard to the Zedboard, power it and see Linux booting on the COM port (configured 115200,8,1,N).


For Linux to boot on a Zedboard in the pre-SDSoC/early HLS times – I had to do quite a few things manually. First, generate the device tree. Then clone Xilinx Linux Git repository, and configure and build the kernel. Then clone the Buildroot/BusyBox Git repository and configure and build the file system with the applications we might want to use. And not to forget packaging our C++ application binary in the file system. Configure and compile u-boot bootloader. Now, with SDSoC, all of this is just copy and paste to the SD card. Compared to all this SDSoC saves a lot of time and typing. Not to mention that the stock SDSoC Linux distribution comes with persistent file system, SSH, and a CGI-Perl web server, which is so handy.


5. With the system now running, I was able to quickly figure out that the SDSoC targeted hardware was running 7x faster, at only 143MHz in the programmable logic fabric, compared to the algorithm in software on the 667MHz processor. Check out the benchmarks below.

AES-256 in SW:
Delta time 3752 us = (new timestamp 555258 us) – (old timestamp 551506 us)
Calculated cipher \„NÔo˜^]jO”Ç×
AES-256 as HDL:
Delta time 550 us = (new timestamp 555840 us) – (old timestamp 555290 us)
Calculated cipher \„NÔo˜^]jO”Ç×

    And frankly, this was purely a software coded AES-256 algorithm compared to the identical code implemented in the programmable logic, with near zero design effort, and definitely no significant attempts at internal algorithm optimization. Pretty powerful stuff. Pretty cool too.


This 7x optimization in speed is significantly better compared to the original HLS-only implementation improvement from a few years back. In both cases the C code interface was handled with as minimal effort as possible and with no further attempts to improve performance with directed HLS #pragma driven optimizations.


SDSoC was really quick and easy: It took me 3 days to implement in hardware an pre-existing AES-256 algorithm written in C++. Really though, most of that time time was spent on learning SDSoC features and configurations, which thankfully were very consistent with the other Eclipse based tools. Not bad for a newbie. SDSoC does seem to be all that!


Other thoughts
1. Looking ahead:

      a. I want to check out if I can get things running even faster! Up the fabric speed, optimize, etc.

b. I want to see if SDSoC supports Partial Reconfiguration (PR) and Isolation Design Flow (IDF) using Xilinx IVT tool ( If so, things should be way easier than before. Before SDSoC we used Vivado HLS to implement different C++ HLS and RTL code in the same reconfigurable partition with the twist of IDF. It was quite doable, but not trivial. Today SDSoC offers the whole Vivado IPI project, another very nice and handy feature which hopefully simplifies PR and IDF flows as well.

2. On the videos above, you can see that there are example projects using the famous OpenCV libraries ( OpenCV basically gives you the power of processing images and video in a standard and rich framework. Really impressive stuff. And in the earlier versions of the tool there were example projects using these libraries, but for some reason they were removed from the standard distribution of SDSoC. This is my Christmas wish – Xilinx, please, put them back in.


About Fidus Systems
Fidus Systems provides Electronic Product Development and Consulting Services to companies across a wide range of industries. Focusing on high-speed, complex designs, Fidus enables your success with multiple design centers, a large full-time staff, and flexible business models.

Fidus provides high-speed, high complexity, electronic product development and consulting services across a wide range of industries. As a Xilinx® Alliance Program Premier Design Services Member, Fidus designs Xilinx solutions to enable customer products. Xilinx highlights: Vivado®, 7-series, Zynq®, Partial Reconfiguration, HLS, SDR, mixed signal, JESD204B, 4k+ video/broadcast, emulation, and FMC development.

By leveraging in-house expert knowledge, and utilizing industry leading tools, Fidus delivers excellence in Hardware, FPGA/DSP, Signal Integrity, Embedded Software, RF/Wireless, and PCB Layout. Fidus is proud to be selected and recognized as Premier Design Services Member for Xilinx North America.

Since 2001, Fidus has delivered over 1000 products/projects for more than 300 customers.

June 16-17, 2015 – Fidus to Exhibit at Devens Robotica 2015


Devens Robotica features live demonstrations of world class robot and unmanned vehicle systems in an outdoor and real world environment. The Event is being held at what may soon be the world’s most technologically advanced community, Devens, MA, just west of Boston in the hub of the Northeast’s robo-innovation corridor.

Read More

Organized by the Devens Inter-Operability Playground for multi-environment and real world testing and commercialization of robotic and unmanned systems, the Devens Robotica events are sponsored by the New England Chapter of the Association of Unmanned Vehicle Systems International (AUVSI), in collaboration with the Robotics Cluster of the Massachusetts Technology Leadership Council (MassTLC).
Join the hundreds of attendees and exhibitors at the inaugural 2015 event. Highlights include (tentative) WPI’s Atlas Robot entry into DARPA’s Robotic Challenge, QinetiQ, Harvest Automation, iRobot and other application demonstrations, plus Maritime, Ground, and Air Pavilions featuring driverless vehicles, tele-presence robots, UV’s and more.
Take in the plenary sessions, workshops, and keynote speakers from Govenment, Industry, and Academia…plus a host of Subject Matter Experts in the fields of Medical, Transportation, Aviation, Maritime, Industrial and Commercial Automation, Personal Robots and Driverless Vehicle Systems.