All posts by ataylor

Arty – XADC Alarms & References

Facebooktwittergoogle_plusredditpinterestlinkedinmail

One of the most common uses of the XADC is for health monitoring of the FPGA and the wider system to that mind the XADC has a number of useful features which can be used.

  1. Trigger and Reset Threshold Alarm registers for the Internal voltages and temperature parameters
  2. Over Temp Monitoring – Maximum junction operating temperature allowable for the device – Auto shut down is possible.
  3. Maximum and Minimum values – Registers which contain the lowest and highest sampled values for each of the voltages and device temperature.

These three elements make for a very useful health monitoring system, of course the alarms and the over temperature must be correctly configured and enabled first. This can be achieved in one of two ways, either via the XADC wizard within Vivado or via our software application.

1

There are seven possible alarms we can configure on the XADC, however we cannot use all of them on the Artix Silicon as some alarms as dedicated to the Zynq (Alarm 6 Vccddro, Alarm 5 Vccpaux and Alarm 4 Vccpint). There is also an eighth alarm bit which is the logical OR of the seven alarm bits and acts as an overall alarm.

We can see if an alarm has occurred via either the Alarm Status Output Register or configure an interrupt to occur should an alarm condition occur such that it can be immediately dealt with.

2

These trigger and reset values allow us to define values which align with our worst case analysis of supply voltages and junction temperature, ensuring we can protect the system properly.

Each alarm also has an associated output which can be used in the wider system either to indicate via a LED a issue has occurred or to take further action e.g. graceful system degradation.

The over temperature alarm is slightly different in that it can be configured to trigger an automatic shutdown of the device. To set automatic shut down the four LSB’s of the over temperature register must be set high. Doing this means that 10 ms after the trigger level is reached a shut down occurs. This prevents re -configuration of the device until the reset level is reached.

It is intended that the temperature alarm is used to act as a pre-warning that the temperature has exceed what the design has calculated as its maximum. This way the system can take action to prevent the shut down e.g. turning on fans, reducing processing etc.

3

While the maximum and minimum registers provide the system with a simple methodology of quickly and easily checking the worst case values as currently observed by the system during its period of operation. These registers can also be of good use in system commissioning to record supply voltages and temperatures  across worst case environmental conditions for example.

There is also one last issue which must be addressed when using the XADC on the Arty board and that is we need to correctly set up the board to use the internal VRefp. Failure to do this results in a inaccurate conversions.  The Arty board is configured such that you can use either the internal or external reference.

4

 

5

We can ensure the internal reference is used by grounding the XADCVREF input, as such the internal reference will be used. This can be confirmed by reading the flag register which also helpfully contains information on any alarms as well

6

With the XADC configured to correctly monitor the internal signals with suitable alarm levels we can look at how we can use the XADC to receive analogue signals from the real world

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Arty – XADC SW

Facebooktwittergoogle_plusredditpinterestlinkedinmail

With the hardware all built and the MicroBlaze system configured to support the XADC at the hardware level we need to be able to drive it at the software level.

2

The first thing you will notice is that having built the hardware in Vivado we need to open the implementation and export the design and the bit file to SDK. The next time we open SDK we will see a dialog box which states the Hardware platform we are using has changed and would we like to update import that to SDK and update the BSP, the answer of course is YES.

This will result in the hardware platform being updated and most importantly the BSP being updated to pull in the correct drivers for the XADC. We can see this if we open the BSP MSS file and click on customise the BSP button, this will open a dialog box upon which the drivers tab we can see the XADC and the driver used to control it in this case XSYSSMON.H. Looking around the BSP directory under the includes/libsrc/sysmon folder will show you the source code to drive the XADC.

Within our application SW how we initialise and set up a peripheral is very similar for all devices

  1. Define the peripheral of interest from the xparameters.h file in this case

#define xadc XPAR_SYSMON_0_DEVICE_ID

  1. Define the instance of the peripheral type we are going to be controlling

XSysMon xadc_inst;

  1. Declare a instance pointer to the peripheral type pointing to the address of the previous instance

XSysMon *xadc_inst_ptr =&xadc_inst;

  1. Declare a configuration pointer of the type of peripheral to be initialised in this case it is XSysMon_Config *xadc_config;
  2. Initialise the configuration pointer with the parameters for the peripheral in use in using the function

Xadc_config = XSysMon_LookupConfig(xadc);

  1. Initialise the peripheral using the function

XSysMon_CfgInitialize(xadc_inst_ptr,xadc_config,xadc_config->BaseAddress);

With the initialization complete we can then proceed to configure the XADC as needed for our application To do this we use the drivers within the XSysMon.h these allow us to configure all of the ADC inputs, its sequencing and if it is interrupt driven or polled.

For this simple example I am going to configure the XADC to sample its internal parameters namely its temperature, VCCInt, VCCAux, VRefP, VRefN, VBram  as would be expected on a normal health monitoring system. This is simple to do using the functions below, this also disables all the alarms in the XADC.

XSysMon_SetSequencerMode(xadc_inst_ptr,XSM_SEQ_MODE_SAFE);

                 XSysMon_SetAlarmEnables(xadc_inst_ptr, 0x00000000);

XSysMon_SetSeqChEnables(xadc_inst_ptr, XSM_CH_TEMP|XSM_CH_VCCINT|XSM_CH_VCCAUX|XSM_CH_VREFP|XSM_CH_VREFN|XSM_CH_VBRAM);

                 XSysMon_SetSequencerMode(xadc_inst_ptr,XSM_SEQ_MODE_SAFE);

 

As I Mentioned in the last blog as we need to use the XADC to provide temperature information to the MIG we will also be enabling the temperature cycle update and defining the time duration this is updated at

XSysMon_SetTempWaitCycles(xadc_inst_ptr, 0x00000340);

                 XSysMon_EnableTempUpdate(xadc_inst_ptr);

The 0x340 relates to system clock cycles which are 83.25MHz to the refresh rate is 9.9939 us which is within the maximum refresh period of 10 microseconds.

Reading the XADC for this example is very simple I used a polled approach which checks for then of end of sequence bit before it asks for the XADC value.

                for(Index =0; Index <RX_BUFFER_SIZE; Index++){

                while ((XSysMon_GetStatus(xadc_inst_ptr) & XSM_SR_EOS_MASK) !=XSM_SR_EOS_MASK);

                                XADC_Buf[Index] = XSysMon_GetAdcData(xadc_inst_ptr, sample[Index]);

                }

The final stage of the programme is to output the results into the table format as can be seen below over the RS232 link. IT is worth recording here that XADC returns a 16 bit result therefore to give the 12 bit accurate result the output result is shifted left by 4 places.

1

You can get the complete code here on the git hub

Over the next few blogs we will look at the XADC Interrupts and Alarms now we have a verified working platform.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Arty – XADC Hardware Build

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Like all Seven series device the Artix on the Arty board contains a 1 MSPS 12 bit XADC which is capable of monitoring not only its internal voltages and die temperature but also up to 16 external inputs. This makes the XADC a very useful device within a embedded system, as it allows you to monitor your system health and perform low speed signal processing without the need for a separate ADC.

1

To show the ease with which we can implement and use a XADC we will add one in to the MicroBlaze system we have been using previously. This will provide the fastest way to configure and report output of the XADC. In fact as we have been using the Memory Interface Generator we already been using the XADC without knowledge as it is used within the MIG to compensate for temperature effects to ensure the DQS is kept centred.
As such if we were to add in another XADC to our block diagram in Vivado we will fail implementation as there would be two XADC instantiations called up when there is only one within the device.
Therefore before we can place the XADC and use it as we wish within our design to monitor the Arty temperature and voltage supplies we need to adjust the configuration on the MIG to not call up the XADC as shown in the image below.

2

Instead this will create a new port at the top level of the MIG which is supplied the temperature from the XADC we wish to instantiate.
With this complete we can now open the IP library and place and connect the XADC to the AXI bus, we can make the VP/VN signals connected to the external ports (J5 on the Arty board) by right clicking on the VPVN port on the XADC and selecting make external.
With the XADC connected into the system we need to configure it to provide the temperature output bus needed by the MIG such that it can provide temperature compensation.
To do this we need to tick the Temp Bus option within the basic tab of the XADC wizard, there are a few software switches we need to set when we write the software.

3

This should result in a block diagram which looks like below when the XADC and the MIG are connected together as required.

7

We can drive the XADC in either a polled or interrupt fashion depending upon our application needs, to ensure interrupt support we need to make some connections in the Vivado block diagram.
The first thing we need to do is add a third input to the concatenation block which creates the interrupt vector, we need to increase this from two to three inputs. With this completed we can connect the ip2intc_irpt output signal from the XADC to the new input on the concatenation block.
I also decided the block diagram was getting congested and hard to read so I group up a number of blocks and created a hierarchy. This is easy to do select the blocks you wish to group together, right click and select create hierarchy, enter the block name and a new block will be created with that name. other blocks within your design can then be dragged into that hierarchy block if you wish to add them to it or removed by expanding the block (+ sign in top left) and dragged out. This enables us to create very net looking diagrams. Do not forget to click the re draw option once you have implemented your blocks.

8

Next time we will look at how we can drive the XADC using C in SDK.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Arty – Interrupts Part Two – AXI Timer

Facebooktwittergoogle_plusredditpinterestlinkedinmail

In the last blog we had successfully instantiated the interrupt controller and demonstrated it functioning as intended by simulating the timer interrupt.

The next step is to configure the timer and demonstrate that the interrupts can be handled properly from the timer in reality.

What I want to be able to do using the AXI Timer is measure the interrupt latency of the MicroBlaze. Interrupt latency—the time between the interrupt being raised and the interrupt being serviced—plays a large role in performance. A number of issues impact interrupt latency, two of these issues are the presence of an operating system and the complexity of the ISR (Interrupt Service Routine).

However the underlying hardware and processor architecture will also have an impact on the interrupt latency time. We can use the AXI Timer to help us measure this time however, first we need to get the AXI Timer up and running.

The AXI Timer contains two 32 bit timer which can be configured in the following modes

  • Generate – The counter counts up or down as selected from a reset value, once the terminal count is reached the generate output is pulsed and the interrupt if enabled is generated. This mode is used to generate a signal or interrupt at a predefined time interval
  • Capture – The assertion of the external trigger signal stores the value of the counter when the signal is asserted. This can be used to measure the duration of external events.
  • PWM – Uses both timers to create a PWM signal – timer 0 defines the overall period and timer 1 defines the high time of the period.

As you can see the AXI timer is a very useful component to our embedded system, what is important for measuring the interrupt latency is the ability to assert the freeze input which stops the counter.

1

The timer can be configured to operate as either an up or down counter and in our application is clocked from the UI_CLK output from the MIG. This clock frequency is 83.25MHz or ¼ of the DDR Controller rate.
For this example and the interrupt latency we will use the timer in the generate mode such that it generates at a predefined period, we will be using the counter in its default count up mode.

The periodic time is defined by loading in a predefined value

Period = ( 2^32-1 – Reset Value + 2) * Clk Period

We will use a Reset Value of 0xF0000000 with an 83.25 MHz clock results in a period of 3.22 seconds between interrupts.

The interrupt service routine will be configured to print out that the interrupt has occurred and restart the counter. I have added the code example code to the Github repository when I ran the code on my Arty board I got the result below.

2

In the next blog we will look at how we can use the timer in more detail to determine the interrupt latency and the potential methods we can use to do this.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Arty – Interrupts Part One

Facebooktwittergoogle_plusredditpinterestlinkedinmail

When we built the MicroBlaze system we included the ability to handle interrupts by the inclusion of an AXI Interrupt controller. This is connected to the interrupt input on the MicroBlaze controller each AXI interrupt controller is capable of supporting up to 32 interrupts. However, we can cascade the interrupt controllers to support up to 96 interrupts for each MicroBlaze instantiation.

Within the system we created in our first blog  , we had two interrupts one from the AXI UART lite and a second from the AXI Timer.

1

The interrupt signal from both the timer and UART are concatenated into a bus using the concatenate block as can be seen above. The intr input on the AXI interrupt shown above as intr[1:0] will scale automatically depending upon the size of the buss connected to it. To use all 32 interrupts use a 32 input bit concatenate block, when you next click on validate you will see the intr input width on the AXI Interrupt block update automatically to the correct width.

The AXI controller is very simple then containing a number of 32 bit registers such as interrupt status, pending, enable and clear registers along with interrupt vector addresses to manage the 32 interrupts.

Within the AXI interrupt block we can customise its behaviour, most importantly we can select if we want the interrupts to be level triggered and active high or low.

2

Once we have configured the hardware as we desire we can build the hardware and export the hardware to SDK if we have not already done this previously.

Within SDK we can create a simple programme which enable us to configure and initialise the AXI interrupt controller and simulate a timer interrupt occurring. Taking this approach allows us to verify in stages our use of interrupts, this stage allows us to demonstrate that we have correctly configured the interrupt controller. Satisfied that this is working OK we can then configure the timer to function and generate interrupts later on.

The first thing we need to do within our software application is include the correct libraries for this example we will need the following

3

  • stdio.h – Contains the standard input and output functions
  • platform.h – Defines the initialisation and tidy up routines for the MicroBlaze
  • xparameters.h – Contains the address and configurations of need for the system
  • xstatus.h – Contains the status definitions used
  • xintc.h – Contains the API for using the AI interrupt controller
  • xil_exception.h – Contains the API for MicroBlaze exceptions

With the correct libraries included the next stage is to write three functions

  1. Interrupt Example – This one is called from the main() function and controls the demonstration
  2. Interrupt set up – A standalone function which configures the AXI interrupt controller and the microblaze exceptions
  3. Interrupt Service Routine (ISR) – This is the function called when the interrupt occurs

As this is a simulated interrupt the ISR simply terminates the programme after printing a message out over the UART when I ran this I got the following output on my terminal.

4

I have added the software application I wrote to my GIT Hub   repository for download if you want it. The next blog on the ARTY will look at the using the AXI timer and the determining the interrupt latency.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Arty – SDK Hello World

Facebooktwittergoogle_plusredditpinterestlinkedinmail

When we left the hardware build we had just exported the HDF and bit file to SDK, initially this will have exported the required information to a directory local to the Vivado project.

With the project exported we can close down Vivado and open SDK, if this is the first time you have opened SDK you will be asked for the workspace you wish to use. The workspace is the area where your projects and associated software projects like Board Support Packages (BSP) and copies of the hardware definition will be stored.

Within SDK to get this up and running we need to do the following

  • Create a hardware definition project
  • Create a Board Support Package for the hardware definition
  • Create our application – in this case a simple hello world
  • Build the application – this is the simple part
  • Define the debug environment such that we can run the application on the Arty board over the JTAG link.

The first step is to import the hardware definition we just exported from Vivado to do this select file->new-> other from the SDK menu this will open a dialog box, beneath the Xilinx folder as shown below select new Hardware Platform Specification

21On the next dialog box enter your project name, I always prefer to call it project_HW to be clear what it is and browse to the directory within your Vivado project which contains the HDF file. Note this is within the .sdk folder under your Vivado project.

22

This will create the hardware specification which, will appear under the project explorer on the left side of SDK, as shown below (this does show all three of the elements we need to create a project)

23

We are now in a position that we can create a BSP for the hardware platform, this contains the drivers necessary for the hardware. We can create the BSP by selecting file->new->board support package this will open a dialog box like below

24

Enter a project name, notice how it has picked up the hardware platform we just created, for this example we will use the standalone operating system.

This will a settings pop up for the BSP there are no changes we need to make here but this is where we can add in additional options if needed e.g. light weight IP stack etc

25

We can also on the standalone page select the stdin and stdout for the compiler make sure this is set to uart lite as below.

26

With this verified you can close the BSP settings and you will see a progress box appear while the software generates the BSP files for your system.

At this point we can then create our application, for this example I am going to use the simple hello world template. We can create the application project by selecting file->new->application project this will open a dialog box where we can select the BSP we previously created the hardware definition and the processor we are targeting (in this case there is only one)

27

 

29

This will create a simple application which will output hello world over the USB-UART, selecting build all will then enable us to build the BSP and the application project such that we get an ELF file which can be downloaded and run on the hardware.  The project is built using the project->build all settings and you will see the ELF file appear under your application project as below

210

The next stage is to run it on the Arty board, this requires that we remove the jumper on J1 on the arty board such that we do not load the design example already loaded within the QSPI flash.

To run the example we need to do the following

  • Programme the FPGA
  • Download the ELF

Before we can download the ELF we need to create a debug environment such that when we click on it we can download the elf. To do this right click on your application project and select Debug As -> Debug Configurations as below

211

This will open a dialog box where we can create a new debug environment, we wish to create a new GBD debug application

212

One you have selected new you will see the dialog box below, you should only need to change the information on page one (most should be auto populated)

213

Provide a name and If not selected select the Rest Processor from the drop down menu close to the bottom, we also need to click on the Debugger applications tab and uncheck the option ”stop at main() when debugging” this ensures the application will run automatically on download finally then click on apply not debug and then close.

214

With this completed it is time to connect the arty board to the USB of your PC, this will auto detect and install any software required when it is completed we can progress and test our application. Note it should only ever need to install once.

The first thing to do is programme the FPGA we do this under the Xilinx Tools -> Programme FPGA which will open the following dialog box (you should not need to change anything)

216

Click on program and you will see the FPGA is programmed, you can confirm this on your Arty board as the done LED will illuminate green.

We are now ready to download our ELF file, click on the bug icon on the top menu and this will use the debug configuration we just created to download the application

217

Once downloaded you will notice the software runs and the message “hello world” will appear in your chosen terminal programme.

You can find part one here

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Arty – Building MicroBlaze in Vivado

Facebooktwittergoogle_plusredditpinterestlinkedinmail

The Arty board is the next generation of the very useful LX9 MicroBoard however, it takes account of advances in devices and interfacing. I ordered mine just before I recently flew to Japan, and it was waiting for me when I returned.

arty

 

The Arty is marketed as the perfect development platform for MicroBlaze applications as such when I opened my Arty the first thing I wanted to do was a new build from scratch of a MicroBlaze system. This way I could really understand the ease (or not) with which it could be developed, in the end it was very easy to create both the hardware application and create the simple software to say hello world.

To get MicroBlaze up and running on my Arty I did the following

  • Download and install the most update version of Vivado (remember to install the Vivado Design Edition)
  • Redeem the license for the Vivado SW which comes with the Arty
  • Download the Arty board definitions
  • Create the hardware definition within a new Vivado project
  • Build the hardware definition and export it to SDK
  • Create out SW application – This needs Hardware Definition, Board Support Package and Application SW.

While it may seem daunting these stages can be achieved quickly, also I am not going to talk you through how to do the first two points as they are very straight forward.

Which brings us to downloading the board definitions, these are available at the following link https://reference.digilentinc.com/vivado:boardfiles Once you have downloaded the board files you need to extract the Arty board definitions and store it within your Vivado installation <VIVADO DIRECTORY>/data/boards/ on my system the path is C:\Xilinx\Vivado\2015.3\data\boards\board_files

Within the arty directory you will then see the board definition XML and most helpfully a mig.prj this is the settings for the memory interface generator for if we wish to use the DDR on the arty (and we will of course).

This enables us to create a new project and select the Arty board, which is our next step

1

Once we have the project created the next step is to create the MicroBlaze system, to do this we need to create a block diagram within which we can create our system. You can create a block diagram by selecting Create Block Diagram option under the Flow Navigator on the left of Vivado

2

Once the block diagram is open we need to add the following things to it

  • MicroBlaze System – See end of blog for customisation
  • Memory Interface Generator – This uses the arty settings so it is just a case of scrolling through and generating the options
  • AXI UART lite – for communication externally – double click on it to set your RS232 options the default is 9600 no parity one stop bit
  • AXI Timer
  • AXI Interrupt Controller – We need a concatenate block to drive the interrupt from the timer and the AXI UART lite
  • AXI BRAM Controller and BRAM for the AXI Data and Instruction Cache
  • Clocking wizard to output a 166.667 MHz Clock and a 200 MHz Clock
  • MicroBlaze Debug Module
  • AXI Peripheral Interconnect to connect to the timer and UART
  • AXI Memory Interconnect to connect to the MIG (DDR) and the AXI BRAM controller
  • Processor Reset System

The clocking of the MicroBlaze and all AXI peripherals should use the output clock from the MIG (ui_clk) while the MCM reset from the MIG block should be fed back to the processor reset system DCM input, the ui_clk_rst goes to the ext_reset_in on the reset block.

The clock wizard outputs connects as below

3

The rest of the connections are pretty straight forward AXI connections, the only difference is the need to add in a MicroBlaze Local DLMB and ILMB memory we can use the Run Block Automation Option (MicroBlaze) available on top of the block diagram editor.

When it is all complete your diagram will look like the below

Arty_vivado

The one thing we have not done by this point is to connect up the IO on the design to those on the board. We can do this by selecting on the board tab within the block diagram

5

We can then right click on a signal we wish to use and select Connect Board Component as below

6

It is then just a simple case of selecting the existing IP to connect it to

7

Do this for the following

  • Sys_clk – 100 MHz clock on the Arty
  • DDR3_SDRAM – the DDR on the arty
  • USB_UART – How we will say hello world
  • Reset – Reset input

This saves us from having to write a XDC file with the pin locations needed to ensure we use the correct IO with the board.

With this completed we can validate our design and we should not get any warnings – if you have any address issues see he Address Editor tab mine looked like below when it was validated OK

8

Once it has validated OK you are in a position that you can build the hardware, and export the hardware definition to SDK.

I will post another blog tomorrow on how to get the SDK side of things up and running but below is the result

arty_hello

Below are the MicroBlaze customisations

9

10

11
12

13

Facebooktwittergoogle_plusredditpinterestlinkedinmail

SDSoC Step by Step Example

Facebooktwittergoogle_plusredditpinterestlinkedinmail

sdsoc1

Until the release of the Xilinx® SDSoC™ development environment, the standard SoC design methodology involved a mix of disparate engineering skills. Typically, once the system architect had generated a system architecture and subsystem segmentation from the requirement, the solution would be split between functions implemented in hardware (the logic side) and functions implemented in software (the processor side). FPGA and software engineers would separately develop their respective functions and then combine and test them in accordance with the integration test plan. This approach worked well for years, but the advent of more-capable SoCs, such as the Xilinx Zynq®-7000 All Programmable SoC and the upcoming Xilinx Zynq UltraScale™ MPSoC, mandated a new design methodology.

Link here 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

More things to consider for your prototype

Facebooktwittergoogle_plusredditpinterestlinkedinmail

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.

Facebooktwittergoogle_plusredditpinterestlinkedinmail