1 2 Previous Next 23 Replies Latest reply on Apr 21, 2015 3:55 PM by 3flares

    Galileo Shield Update

    mjstanis

      Hi everyone,

       

      After my initial post (Developing a New Galileo Shield), it's been some time since I've updated you on the shield project.  I'm happy to say everything is moving forward and we're just wrapping up the architecture.  Below is a overview of the shield as it currently stands.  It's a bit long, but I hope it covers everything we talked about and I'd love comments/questions about it.

       

      As always, this information is still in development, so none of the design is final yet and shouldn't be considered definite.  Please take the information with a grain of salt. 

       

      Also, I'll be presenting a poster on the shield at the Intel booth at the Maker Faire in the Bay Area on May 17-18, so feel free to stop by and say "Hello"

       

      Okay, on to the nitty-gritty:

       

      ---------------------------------------------------------------------------------------

       

      Shield Overview


      The Galileo shield will provide an interface between common sensors that makers use, such as an ultrasonic microphone, and the Intel Quark processor on the Galileo.  To do this, the shield uses an FPGA and the PCIe interface to communicate between the sensors connected to the shield and the Quark on the Galileo. 

       

      The shield supports many common interfaces that are typically used with sensors and other devices, such as SPI and UART (see ‘Supported Interfaces’ below).  The headers provided on the shield can be reconfigured using RTL in the FPGA to operate different types of interfaces.  This allows a maker to use an unlimited number of sensors and other devices in their projects using this shield.

       

      The shield consists of the following major components:

       

      • Precision time (IEEE 1588) Components
      • FPGA
      • PCIe Switch
      • Analog-to-Digital Converter (ADC)
      • MIPI CSI
      • Sensor Headers

       

      Hardware


      An overall block diagram of the shield is provided below:

       

      1.png

      2.png

       

       

      Precision Time (IEEE 1588)


      The Galileo shield takes advantage of the IEEE 1588 support in the Intel Quark X1000 processor onboard the Galileo.  More information on using precision time functions with the Quark, such as timestamping, can be found in the Intel Quark SoC X1000 Datasheet.

       

      Software on the embedded Linux system of the Quark communicates using a driver over PCIe from the Galileo to the shield to convey timestamp information in addition to data.  A register set implemented in the FPGA will be provided to enable time synchronization support on the shield.

       

      One example of precision time is the use of audio synchronization to implement a wireless speaker system.  The Galileo shield also provides the necessary components to do audio synchronization through the use of a speaker or headphone jack, microphone, audio codec and clock (more info on these components - TBD)

       

      In the case of audio synchronization, samples are stored in DRAM on the Galileo.  For audio output, the FPGA requests samples from DRAM via PCIe using the Xillybus (http://www.xillybus.com) DMA engine.  The FPGA passes the samples from the PCIe interface to the audio codec via I2S, which is then outputted via the speaker or headphone jack.  For audio input, the microphone input is sent to the codec, which passes it to the FPGA via I2S.  The FPGA transfers the I2S data to PCIe and sends it to the DRAM on the Galileo using the DMA.

       

      The above example demonstrates how the FPGA is used as a pass-through device that connects interfaces, not as a processing device.  All processing for audio or other data is performed on the Galileo side using the Quark, allowing for relatively small buffers on the FPGA and thus a small, cheap FPGA to be used on the shield.

       

      FPGA (unconfirmed)


      An Altera Cyclone IV FPGA will be used onboard the Galileo shield.  This component acts as a mapping device between sensor headers and the PCIe interface.  RTL on the FPGA can be modified to support a variety of interfaces (more info on RTL - TBD)

       

      Data is sent from the shield via PCIe to the Intel Quark processor on the Galileo, where it is processed.  Likewise, the Quark sends data over the same PCIe interface to the FPGA, which distributes it to the proper interface.

       

      Vertical Migration


      The Altera Cyclone IV FPGA chosen allows for expansion to a larger device with the same footprint through vertical migration.  Based on the type of device package chosen (F169), the EP4CGX15, EP4CGX22 or EP4CGX30 device can be chosen, allowing makers to choose the right size of device based on their logic element (LE) utilization and cost requirements.

       

      PCIe


      The PCIe connection on the shield is a Gen1 x1 interface.  The Cyclone IV FPGA includes a hardened PCIe IP interface, which allows less LEs to be consumed when implementing PCIe and is implemented using Altera’s Quartus II software.  Xillybus (http://www.xillybus.com) provides a DMA backend for the Altera PCIe IP, allowing users to use a simple FIFO interface to send data between the FPGA on the shield and the Quark on the Galileo.  A free-to-try, full-featured copy of the Xillybus DMA IP can be used for personal use.

       

      MIPI


      The FPGA also includes one MIPI interface.  Please see below for more details.

       

      PCIe Switch


      A 3-port, 3-lane PCIe switch by PLX allows the shield to connect to the Galileo via its mPCIe interface while providing the ability to add an additional mPCIe device (i.e. Wi-Fi card) via a connector on the shield.  The switch takes the upstream x1 port from the Quark on the Galileo and provides two x1 downstream ports, one to the FPGA and the other to an mPCIe connector. 

       

      Cabling


      To connect the PCIe link between the shield and the Galileo, an mPCIe-to-Flat Flexible Cable (FFC) adapter and FFC cable will be used.  The adapter and one end of the FFC will connect to the mPCIe connector on the bottom of the Galileo, while the other end of the FFC will plug into a connector on the shield. 

       

      MIPI (unconfirmed)


      A MIPI Camera Serial Interface (CSI-2) is provided on the Galileo shield to allow the FPGA to receive data from an image sensor of a mobile camera.

      Keeping in line with the Raspberry Pi, a popular maker board similar to the Galileo, the following MIPI CSI configuration has been implemented:

       

      • CSI-2: 2-lane receive (Rx) interface running at up to 800Mbps

       

      The implementation has been taken from the Raspberry Pi schematic (see ‘S5’ on p. 4 of http://www.raspberrypi.org/wp-content/uploads/2012/10/Raspberry-Pi-R2.0-Schematics-Issue2.2_027.pdf) to allow compatibility with the Raspberry Pi camera.

       

      Analog-to-Digital Converter (ADC)


      The Galileo shield provides four (4) additional analog inputs via an onboard ADC in addition to the six (6) provided by the Galileo itself (A0 – A5). 

      The ADS7950 provides an analog interface that can provide a sample rate of 1MSPS with the same 12-bit resolution.  This allows all the analog sensors researched to operate at maximum frequency, which was calculated as 10kHz for sampling.

       

      Sensor Headers


      IO Availability


      Based on current FPGA size estimates, approximately thirty-two (32) IOs will be available via headers for sensor applications.  Two headers will be available for sensors, a low-speed and high-speed IO interface. There will be two (2) low-speed headers and one (1) high-speed header available on the shield.

      Please see the table below for the distribution of IOs:

       

      Function

      Number of IOs

      Comments

      Sensor Header

      32

      2x low-speed, 1x high-speed

      PCIe

      6

      Not including transceivers

      Codec

      8

       

      MIPI CSI

      10

       

      User Input

      9

      4 LEDs, 1 push button, 4-button DIP switch

      Galileo IOs

      7

      4 for SPI; 3 general purpose IOs

      Spare

      0

       

      TOTAL

      72

       

       

      Low-Speed Header


      Two (2) low-speed headers are available on the Galileo shield.  Each 10-pin header provides 3.3V power, ground and eight (8) 5V-tolerant 3.3V IOs.  The header key and pin out are provided below:

       

      Low-speed header key

      3

      3.3V Power

      G

      Ground

      S

      Signal IO

       

      Low-speed header pin out

      3

      G

      S

      S

      S

      S

      S

      S

      S

      S

       

      This layout was chosen by examining interface pin outs of 60 common sensors on popular maker websites, such as SparkFun, Adafruit and Seeed.  Although 3.3V is more common (87% of sensors surveyed), a 5V header is also provided nearby to allow 5V-powered devices to operate properly.

       

      These headers are meant to be used either directly with sensor modules or wired via breadboards to sensors.  As breadboards typically operate correctly up to about 10MHz (BW limit referenced at: http://electronics.stackexchange.com/questions/2103/when-to-avoid-using-a-breadboard, http://en.wikipedia.org/wiki/Breadboard, http://www.ehow.com/list_7653183_breadboard-specifications.html) and most sensors researched do no operate above that frequency, the low-speed headers should work for most devices that makers wish to use.

       

      For a high-speed alternative, please see below.

       

      High-Speed Header


      One (1) high-speed header is available on the Galileo shield.  Each 36-pin header provides 5V and 3.3V power, ground and sixteen (16) 5V-tolerant 3.3V IOs.  The header key and pin out are provided below:

       

      High-speed header key

      5

      5V Power

      3

      3.3V Power

      G

      Ground

      S

      Signal IO

       

      High-speed header pin out

      3

      3

      G

      S

      S

      G

      S

      G

      S

      G

      S

      G

      S

      G

      S

      G

      S

      G

      5

      G

      G

      S

      G

      S

      G

      S

      G

      S

      G

      S

      G

      S

      G

      S

      S

      G

       

      This custom layout was chosen to provide a low-noise, high-speed interface within a compact header pin out.  Two (2) sets of signals are provided side-by-side as a means to allow for differential pairs to be used.  The header is meant to be operated at the theoretical maximum allowed by the FPGA, which is around 200MHz (see the Cyclone IV Device Datasheet).  Both 5V and 3.3V power are provided on this header. A 5V header is also provided nearby if additional 5V power is needed.

       

      A maker must develop their own adapter or add-on card to use this header.   A breadboard should NOT be used with this interface, as they only operate correctly up to about 10MHz (BW limit referenced at: http://electronics.stackexchange.com/questions/2103/when-to-avoid-using-a-breadboard, http://en.wikipedia.org/wiki/Breadboard, http://www.ehow.com/list_7653183_breadboard-specifications.html).

      For most sensors researched for this design, the low-speed headers should be more than adequate and allow for breadboards to be used.

       

      Supported Interfaces


      Using common distributors of maker products, such as SparkFun, Adafruit and Seeed, a list of 60 sensors was generated.  By comparing common interface standards, power requirements and pin layouts, a list of common interfaces used by sensors and other devices was developed for the shield.

       

      The following key and table provides a list of common interface standards, and their support status for the Galileo shield:

       

      Interface key

      Status

      Explanation

      Supported

      Fully compatible with the shield

      Requires Pin Mapping

      User must re-map pins between sensor and shield using breadboard or wires

      Onboard Galileo

      Feature is already available on Galileo and will not be implemented on the shield

      Unsupported

      Not implemented on the shield

       

      Interfaces and shield status

      Interface

      Status

      Comments

      Analog Input (ADC)

      Supported

       

      Arducam

      Requires Pin Mapping

       

      CSI-2

      Supported

       

      CSI-3

      Unsupported

      Not electrically compatible with CSI-2

      Digital IO

      Supported

       

      DSI

      Unsupported

       

      DVP

      Requires Pin Mapping

       

      Grove

      Requires Pin Mapping

       

      HDMI

      Unsupported

       

      I2C

      Supported

       

      PCIe

      Supported

       

      PWM

      Supported

       

      RS232

      Onboard Galileo

       

      SPI

      Supported

       

      UART

      Supported

       

       

      Galileo IOs


      Seven (7) IOs allow for communication between the Galileo and the FPGA directly by utilizing the shield pins.  Four (4) of these IOs connect to the SPI signals (IO10-IO13) on the Galileo: SCK (Clock), MOSI (Master-out, Slave-in), MISO (Master-in, Slave-out) and CS (cable select).  The remaining three (3) IOs connect to general IOs IO2-IO4 on the Galileo.  IO2 and IO3 can be operated at “fast” speeds, which means that they can operate at faster than the advertised 230Hz interface speeds.  More information can be found at this site: https://communities.intel.com/message/207904. IO4 can only be operated at the maximum 230Hz speed.

       

      5V Tolerance


      All IO headers (low-speed and high-speed) onboard the Galileo shield will support up to a 5V input. All IOs on the shield connect to the FPGA, which is programmed to operate the IOs at 3.3V.  As most sensors surveyed (87%) operate at 3.3V, 3.3V was chosen as the primary IO voltage for the shield.  All 3.3V and 5V sensor devices interface with the IO headers normally, without any additional hardware.

       

      Note that while the header IOs can accept 5V inputs, they only operate as 3.3V outputs.  All sensors surveyed didn’t require a 5V output from the shield, and therefore 5V tolerant inputs were implemented on the shield using quick (bus) switches rather than implementing bidirectional level-shifting to reduce cost and complexity.

       

      Software and RTL - TBD


      ---------------------------------------------------------------------------------------

       

      Whew!  Okay, that's it...as I said, let me know what you think, either here or at the Maker Faire .

       

      Thanks!

      Matt

        • 1. Re: Galileo Shield Update
          fpga_brad

          Do you expect typical Makers to be able to develop FPGA code or is your plan to provide a stock .bit file?

          • 2. Re: Galileo Shield Update
            mjstanis

            We plan on providing some FPGA code for some basic modules (SPI, I2S, CSI, etc...) as well as some IP cores for the larger interfaces like PCIe.  The idea being that the modules are there to provide blocks that makers can use to connect interfaces together with glue logic.

             

            As for .bit files, we'll most likely provide an image for the basic sensor demo we plan to do, and maybe for a CSI demo too.

             

            Thanks!

            Matt

            • 3. Re: Galileo Shield Update
              mjstanis

              Hi all,

               

              Happy to say that Eagle work is beginning on the PCB today!  Thank you all for your continued feedback.  Here's a quick 3D shot from SketchUp of the final shield:

               

              shield_3d_print.png

              Hope to have more info soon!

              Matt

              • 4. Re: Galileo Shield Update
                Zigenz

                Matt - this looks like a great fit for a prototype I'm developing at the moment.

                 

                Any news on availability?

                 

                Cheers,

                Z

                • 5. Re: Galileo Shield Update
                  mjstanis

                  Yep, the good news is the board files just went out to have the prototypes build, so I'll have prototypes in my hands soon.  After that, we need to find some product guys to help get them out to the public.  I've been meaning to write a more detailed update for quite some time, so I'll try and get on that soon.

                   

                  But yea, it's soon going to be built, now I'm just working on the distribution end of things.

                   

                  Will keep you posted!

                  Matt

                  • 6. Re: Galileo Shield Update
                    Zigenz

                    Excellent!  If you're looking for testers, feel free to fire one this way!

                     

                    Z

                    • 7. Re: Galileo Shield Update
                      mjstanis

                      Haha, well I'm definitely glad to hear you can use one!  I'd love to hear from anyone who wants a shield, as it'll help us make the case to get them built :-)

                       

                      Working on a quick update post now, hoping I can get that out asap.

                       

                      Thanks!

                      Matt

                      • 8. Re: Galileo Shield Update
                        mjstanis

                        Hi everyone,

                         

                        Well it's been a long time coming, but I'm happy to announce that as of today, the IoT Shield has been released for manufacturing!  We should be getting the first prototypes back in about 3 weeks and then we'll be working on getting this out to you for your own use.  Here’s an Eagle image of the top and bottom of the board for your viewing pleasure :-) :

                         

                        board_output.png

                         

                        board_output_bot.png

                         

                        As for specs, there have been some updates since my first post above:

                         

                        • Both Galileo Gen1 and Galileo Gen2 are supported
                        • FPGA now confirmed to be the Altera Cyclone IV GX30
                        • PCIe switch updated to the Pericom PI7C9X2G303EL
                        • CSI-2 receive (RX) interface is confirmed and will be tested with the Rapsberry Pi camera
                          • Interface speeds will be 500Mbps per lane
                        • Added more IOs all around for accessing a larger number of sensors:
                          • Doubled header IOs from 32 to 64 IOs by adding a third low-speed IO header and a larger high-speed IO header
                          • Connected all Galileo header IOs to the IoT Shield
                          • Added an additional 4 LEDs, 1 push button and 4 DIP switches for more user input choices

                         

                        Below is an updated block diagram:

                         

                        shield_top.png

                         

                        shield_bot.png

                         

                        Looking forward to providing more posts on first boot in a few weeks.  If you have any interest in getting your own IoT shield, please let me know either on the forums or through a private message.  I'm hoping by showing your support, we can get this into your hands as soon as possible.

                         

                        Thanks!

                        Matt

                        • 9. Re: Galileo Shield Update
                          Zigenz

                          Matt - looking good!

                           

                          Re. the IEEE 1588 timestamping function, I had a look in the Quark SoC X1000 datasheet and the timestamping functionality lives in the 802.3 MAC (as I thought it would).  I assume therefore that only software timestamping would be available if using an attached WiFi adapter and a tool such as linuxptp.

                           

                          Z

                          • 10. Re: Galileo Shield Update
                            mjstanis

                            Hi Z,

                             

                            Actually, IEEE 1588 timestamping is theoretically possible in Wi-Fi hardware.  More info can be found in this IEEE tutorial:

                             

                            http://ieee802.org/1/files/public/docs2014/as-kbstanton-8021AS-tutorial-0714-v01.pdf 

                             

                            Thanks!

                            Matt

                            • 11. Re: Galileo Shield Update
                              Zigenz

                              Thanks for the link Matt - very useful.

                               

                              Finally had a chance to digest it; looks like hardware timestamping in 802.11 relies on the timing measurement field of the MAC Layer Management Entity (MLME.TIMINGMSMT) being correctly populated to work correctly.  This would require:

                              - application support in the relevant IEEE 1588 implementation (e.g. in ptp4l),

                              - kernel support to facilitate manipulation of the MLME payload,

                              - driver support to for appropriate MAC framing; and

                              - hardware support.

                               

                              I'm struggling to find any reference configurations of 802.11 hardware timestamping and associated performance figures.  Would appreciate it if you could please advise if there a proven stack for IEEE 1588 hardware timestamping over 802.11; namely:

                              - application/s / daemon/s and version/s,

                              - Linux kernel version,

                              - relevant driver and version; and

                              - adapter model number.

                               

                              Appreciate the help Matt!

                               

                              Cheers,

                              Z

                              • 12. Re: Galileo Shield Update
                                mjstanis

                                Hi Z,

                                 

                                Unfortunately, I don't have any additional info on reference configurations for getting IEEE 1588 up and running on wireless hardware.  At the very least, I would like to refer you to my post Re: Custom kernel patch failing, where I'm working on getting IEEE 1588 up and running on the current Galileo Ethernet MAC, in case that would be useful for you.

                                 

                                Once news on 802.11-based timestamping hardware comes out, I'll be glad to share

                                 

                                Thanks!

                                Matt

                                • 13. Re: Galileo Shield Update
                                  Zigenz

                                  Hi Matt - you must have had a good play with this thing by now...  How is everything looking?

                                   

                                  Cheers,

                                  Z

                                  • 14. Re: Galileo Shield Update
                                    mjstanis

                                    Hey Z,

                                     

                                    The boards should be here any day now!  I'll keep you posted :-)

                                     

                                    Matt

                                    1 2 Previous Next