1 2 Previous Next 19 Replies Latest reply on May 5, 2014 6:15 PM by mjstanis

    Developing a New Galileo Shield


      Hi everyone,


      My name's Matt and I'm a maker over here at Intel in Oregon.  I'm spearheading a new Galileo shield to promote a cool new technology on the Quark that allows for several orders of magnitude improvement in time synchronization over a network. Here's a quick Wiki page covering the basics: Precision Time Protocol - Wikipedia, the free encyclopedia


      With this level of synchronization between devices, there are endless nifty audio, video, location and other projects that can be done.  We've thought of a few so far, but we thought it'd be even better give the maker community the tools to go out and develop their own projects using time synchronization.


      Therefore, I'm in the early planning stages of developing a possible shield for the Galileo that will enable users to take advantage of the time synchronization technology on Quark by providing a bunch of sensors and other devices to help get you going.


      For sensors and I/O devices, here are some of our current ideas:


      - Speaker

      - Microphone

      - Ultrasonic receiver/transmitter

      - Accelerometer

      - Magnetometer

      - Temperature Sensor

      - Pressure Sensor

      - IR Sensor

      - Clock and 1MHz counter (for timestamping)

      - Camera (possibly Motion JPEG)


      Since many of the serial interface speeds (I2C/SPI/etc…) are limited on the Galileo based on the I/O expander (see https://communities.intel.com/message/207619), we thought it’d be cool to hook all the sensors to IOs on a cheap FPGA to give you the fastest possible connection.  We’d also wire up all the remaining IOs to headers for all your future project needs J


      On the other end, the FPGA would talk to the Galileo over the mini-PCIe link on the bottom through a flexible cable.  This allows you to take advantage of the speed of the PCIe interface.  Once you load the code into the FPGA for the PCIe and other sensor interfaces, there would still be plenty of room to code up your own RTL for making use of the space in the FPGA.


      This is merely a concept at this point; there’s no potential order date yet, we’re all here just brainstorming right now. 


      What do you think?  Do you have other suggestions for sensors/IO devices?  Other stuff (LEDs, buttons, etc…) that you’d like to see on this board?

      I’m a maker at heart, and I believe that the best way to make a useful shield for everyone is of course to ask the makers, so give me your input and let’s see what we can come up with!


      Thanks for taking the time to read and chime in!


        • 1. Re: Developing a New Galileo Shield



          The Galileo _needs_ an expansion board like this.

          As it now is, it just shows what happens
          when a tribe that shrinks heads gets hold of a MinnowBoard.


          That _has_ a second PCIe Port.


          The Galileo doesn't though
          the Quark X1000 on it does.
          But it isn't pinned out!


          Since the Gerber files for "Your Old Gal"
          _still_ are not in the public domain,
          I can't tell whether it _might_ be possible
          for a superb tech to expose the now-hidden second PCIe port.


          And so if I were going to scope out what you're thinking of doing,
          I would buy a MinnowBoard with a Break-Out-Board for $189
          and use _them_ to rough things out.


          The one thing that simply _has_ to be on the "BOB"
          is an FPGA that the CPU interacts with via
          its second PCIe port.


          What is behind the FPGA on the "BOB" is TBD.
          But for starters, it could be a "local bus"
          that is 16/32 bits wide and provides access
          to the rest of the "BOB"'s prototyping area.*


          And/Or a CPU of some ilk that would provide a _working_
          "Uno"/"Duo" interface for off-the-shelf "shields". That's
          what is going to be done on the "Tre" , I believe.


          Ideally the FPGA you choose would have a
          hard-coded PCIe interface. But the FPGA's
          that I know about that do aren't inexpensive.


          I've experimented with the Lattice Semi
          ECP3 Versa Board and the free Diamond Software,
          which runs well on my Linux boxes. If I were
          where you are, I'd contact them when the rain stops
          and try to find out what they have now or in the pipeline
          that might meet your needs.


          Though I do not have a Galileo or a Minnow Board
          to test the software I've built, I have been able
          to build systems of various ilks for the MinnowBoard
          (and BeagleBoards) using "poky-dora-10.0.1.tar.gz" and
          "dora-10.0.1.final.tar.gz" Never thought I'd see
          the word "final" at yoctoproject.org.


          BC Bill

          Fifteen plus years ago, Intel had an IC -- the i960VH --
          with a PCI "front door" and a 32-bit "back door"
          that I used on a project for a large firm that
          now prefers to sell sizzle rather than bacon.

          • 2. Re: Developing a New Galileo Shield

            Hi Matt,


            thank you for inviting the community for a discussion!


            I understand your excitement and using a FPGA to get around the limits of the existing IO interface is a really sophisticated way.


            I've another fear (i'm german, we have always fears if it comes to technology): Software and documentation support. Get me straight: As you see here in the forum, a lot of Galileo users have an Arduino background and struggle "already" to transfer there knowledge (and sketches) from Arduino to Galileo. Some popular Arduino sketches, libraries and solutions might be only usable with your proposed shield - but telling these users "just program the FPGA as needed" is not an option. You should not only plan the hardware but also spend a lot of time to provide the neccessary knowledge and software tools for non-professional users.

            • 3. Re: Developing a New Galileo Shield

              Hi Matt. Would you please reach out to us when convenient ? We are working on some expansion ideas for this platform and would like to avoid any potential overlap. Have some ideas that will be worth noting for best support. Thanks and bye for now.

              • 4. Re: Developing a New Galileo Shield

                The time sync and the sensors don't sound all that interesting to me. The I have a lack of knowledge about the time sync advantages so it might be good but I just don't know enough. There are already a ton of sensors for the Arduino -- there isn't really a need for more.


                However, the FPGA connected to pci-e would be outstanding!


                In many ways I have the opposite perspective of AlexanderMerz. Intel has positioned Galileo as an Arduino. This attempt at being beginner friendly has caused it to be far more limited than it otherwise should be. I like the Arduino headers for hardware compatibility but this is a powerful board behind the beginner-friendly facade. There are already plenty of excellent Arduinos that are beginner friendly we don't need another. But a system that is powerful while still fitting into the budget and design tool limitations of a hobbyist is very cool. FPGA? sign me up!


                I don't know what I would use a FPGA for, but I would love to play around with having one connected to the Galileo. It would help with IO and would be pretty unique. Galileo's pci-e port, while being unique and very capable is currently mostly going unused. WiFi cards can easily be done via USB. It would be nice to have a better use for it.


                My suggestion is to try to find a way to add on a HDMI header to the FPGA. There are ways of doing HDMI out with a FPGA. Having video as an option would add a lot of value to the system.

                • 5. Re: Developing a New Galileo Shield

                  Hey BillS,


                  As the current schematics and board files of the Galileo show (Intel Galileo (Gen 1) Development Board Documents), the second PCIe port just has floating pins.  The first PCIe port is shown in yellow while the unconnected PCIe port #2 is shown in red in the board file below:




                  I checked all signal layers using Cadence's Free Viewer (http://www.cadence.com/products/pcb/Pages/downloads.aspx) and it appears that these haven't been routed, so that is definitely something I will talk to the Galileo team about for their second iteration.


                  Thanks for the Minnowboard + "BOB" suggestion.  I can certainly see where it'd be useful to prototype with this new shield.  However, since I'm using the current Galileo board rev on the market, I'm stuck with plugging the FPGA into the single PCIe port.  Do they also have sensor expansion boards?  I didn't seem them immediately on their site.


                  I'm debating a common bus for the sensors vs. connecting each one individually to the FPGA as a point-to-point.  A large common bus would certainly simplify things, I'm just worried about bus contention and how that would affect performance, especially if you're trying to use multiple sensors/devices at once (say, streaming video while reading temperature data).


                  I understand there are a lot of issues with current Arduino shields with Galileo.  Case and point, my post about using the UltimateGPS module, which I was converting over from my homebrew project to Galileo (Re: Adafruit Ultimate GPS).  Again, I will pass that on to the Galileo folks for the second board iteration, but for now I'd like to keep this shield I'm designing to primarily sensors, IO devices and an FPGA.


                  I have found a few FPGAs for relatively cheap that do include a PCIe hard IP core (<$100 per unit on Digikey for the Cyclone IV/V).  I'm also looking at a DMA backend for PCIe that would be free for testing purposes and fits well within the logic elements of the FPGAs I'm researching.  See my post to Alexander below for more on this.  I did take a look at the ECP3 and I noticed that the IP I'm researching for the DMA didn't support their device, but that shouldn't stop me from asking them about the IP and what other FPGAs they have in their pipeline.  I'll drop them a note.


                  The Yocto project looks awesome; it's definitely something I could have used when designing with Petalinux on my Xilinx devkit or with linux on the Zedboard.  It is a pain to find commonality between devices and it looks like this takes a big step in helping with that.




                  • 6. Re: Developing a New Galileo Shield

                    Hi AlexanderMerz,


                    Believe me, like I told BillS, I understand the shield struggle myself (see my comment about the UltimateGPS).  I know I'm being really vague at this point, since I can't promise anything yet and we're all here just brainstorming, but let's dive into this shield compatibility issue a bit more.  As I said, I'd rather keep my shield primarily for sensor, IO and FPGA use and have the Galileo team update their board to make it more compatible, but do you think there's a way to mimic a more compatible shield interface?  What are some of the common issues with non-working Arduino shields on Galileo today?  As I've only had GPS issues, I'm not aware of all the problems that I'm sure the community is experiencing.


                    I agree that we need to get a wiki or something set up and that documentation is key.  We also need to explain our any RTL or software that you will need in a very thorough manner.  I am a HW guy yes, but my background in computer engineering has given me a firm enough SW grasp to understand the need for clean code and documentation.  My years of IT work writing detailed HOWTO guides also drives my love for documentation and I'll definitely see that you get the information you need.


                    I also understand that makers aren't going out and spending tons of money for board design software, fancy IP and flashy FPGAs.  As a final test, I'm planning on testing the entire process (HW, SW, documentaiton, etc...) at my own home without any fancy tools.  That means a cheap, working board, free software tools (Eagle, Linux, Altera's Quartus Web Edition or Xilinx's ISE WebPACK, etc...) and readily available components or existing shields/modules available on the SparkFun, Adafruit, Digikey, Mouser, etc...  One interesting area, as I was explaining to BillS, is the DMA backend IP for the Hard IP core on the FPGA, which could run $10000s easily.  I may have found a solution, which is still in the early research phase, of providing a resource that offers a free-to-try, full-featured PCIe DMA IP.  I have been talking to a company called Xillybus (An FPGA IP core for easy DMA over PCIe with Windows and Linux | xillybus.com) about possibly using their product, which offers such a thing.  But again, still too early to say :-)  We'd provide the blank FPGA to you and then you could download their free-to-try IP.  For the other RTL (sensor communication, etc..), we'd test that in-house and provide it open source.


                    Hope that helps.




                    • 7. Re: Developing a New Galileo Shield

                      Hey mon2,


                      I'm glad you chimed in!  I'm just beginning on this over here and want to collaborate with as many people as possible to make a great shield.  Are you an Intel guy?  I didn't see an email address in your profile, but feel free to ping me via email and let's chat some more.




                      • 8. Re: Developing a New Galileo Shield

                        Thanks for the comprehensive reply.


                        To clarify my answer: I don't expect the shield to make the Galileo 100% compatible with the Arduino. This makes no real sense. For the price of the Galileo and your shield, you might get 15 or more Arduinos.

                        Instead I hope, the shield can make the migration easier.


                        Let me explain more in detail.

                        The function Arduino - PulseIn isn't implemented on the Galileo. But this function is essential for using sensors like bare ultrasound sensors. It did some research on how to implement it, like you can directly use the sysfs devices to emulate digitalWrite or analogWrite. No way. To make it even harder, it might be neccessary to modify the kernel driver  to implement such a function, and that still might not deliever reliable results.

                        But with your shield, it would be no big deal.

                        Now let's see this from the view of Joe McMaker, your friendly neighbor and student who likes to do some tinker projects during the weekend. He have some experience with electronics, but often relies on Google to find a suitable Arduino sketch, that matches his needs with some modifing. And to be realistic, today, for each existing Linux/C/Python/whatever program to control hardware, there are 100 Arduino sketches doing the same job.

                        He will understand, if you explain him, pulseIn() and other functions will not or imperfect work on the Galileo, but he will also not have the neccessary time learn how to deal with FPGA. It would be nice to have a well documented library "fpga.h" and a preconfigurated FPGA, that covers such funtion like pulseIn(). So he could replace the original calls of pulseIn() with the fpga_pulseIn().

                        Later, he might be interested in playing with the FPGA directly, but he shouldn't force to spend time on a specific hardware that ist not directly related to his project at this point.


                        In the answer to BillS, you expressed your thoughts about a bus-based connection between the sensors or not. I recommend you to take a look at Tinkerforge , this project is not far away from your idea and they are using a bus.

                        • 9. Re: Developing a New Galileo Shield

                          Using PCI-e interface through FPGA sounds too complicated to me (but maybe because I never done anything like this before).

                          Yet it might be possible to connect high-bandwidth sensors (Audio, Camera) through USB, and the rest of the sensors through either SPI or I2C busses.

                          Also I see that you want to include almost all possible sensors on your shield. That might be not very convenient. For example a user might want to have sensors located in some particular locations in his project (e.g. attach temperature sensor to the object which temperature is being measured, or put ultrasonic sensor on the front of the robot to measure the distance to obstacles). So it makes more sense to make sensors modular, so that they don't have to be located on the shield. This also will allow attaching more than one sensor of each kind (add jumpers to configure I2C address?!). Actually there are some companies that already make a such collections of sensor modules (http://www.unmannedtechshop.co.uk/grove.html, http://www.parallax.com/catalog/sensors, http://www.tinkerkit.com/modules-2/)

                          Regarding Clock, 1MHz counter, and precision clock synchronization - Can you please elaborate or give some examples of applications for these? Quark already includes HPET and an RTC (just connect the battery). Are these capabilities not good enough for your applications?

                          • 10. Re: Developing a New Galileo Shield

                            Hi dfreyance,


                            I understand that I haven't made a very good case on time sync yet, so to help out I chatted with our in-house expert and the creator of the technology, Kevin, to give everyone a little more insight into this technology.


                            Time synchronization falls very well within a subset of the IoT realm which is called cyber physical systems (http://en.wikipedia.org/wiki/Cyber-physical_system), where you have multiple computer systems communicating with each other (i.e. Galileo-powered robots) that are controlling physical elements (servos, etc…).  Another example (besides robots) would be to have multiple Galileo’s with the shield around your home, talking to each other in a coordinated manner and controlling devices (thermostat, doorlock, coffee maker, etc..)


                            Other cool demos he passed along include:


                            Synchronized displays (http://www.planar.com/):


                            This resolves the genlock issue (http://en.wikipedia.org/wiki/Genlock).


                            …and synchronized networked home speakers using 802.1AS (time sync): http://www.ieee802.org/1/files/public/docs2008/as-kbstanton-8021AS-overview-for-dot11aa-1108.pdf


                            Haha and I hear you on the FPGA, I think it’s awesome too!  Believe me, I had the same problem when I got my Raspberry Pi and other dev boards; I had no idea what to do with it, but I found something cool to make! I understand there’s a bunch of sensors out there for Arduino already; I just had thought making a shield that offers multiple sensors on a fully-compatible Galileo shield would be useful.  Even better, we could stick mainly to having headers that would be compatible with a variety of interfaces (SPI, etc…) that would allow you to choose your modules/sensors to plug in.  That would certainly add flexibility.  I explain more in my post to Sergey, which I’ll post in a bit.


                            HDMI sounds like a great add-on, as long as I can get it to fit on this FPGA.  I’ll add that to the wishlist




                            • 11. Re: Developing a New Galileo Shield

                              Hi AlexanderMerz,


                              I appreciate the clarification.  That makes a lot more sense.  If the PulseIn() function is so essential to a lot of sensors, then this is something that I will definitely bring up to the Galileo team.  And yes, the FPGA would make this function VERY easy to implement and certainly something I can consider adding to a basic RTL image for the FPGA; I just added it to my “RTL idea” list.


                              I plan on making some basic RTL (not including the PCIe DMA IP) available open source that’s well-documented and includes demo code for interface logic to sensors.  I know how it is to find a chunk of code you want to try, only to find that you have to spend hours getting some other part of the device talking just so you can use it.


                              Thanks for the Tinker Forge suggestion, I’ll dig into that more and see what they’ve got going there.




                              • 12. Re: Developing a New Galileo Shield

                                Hi SergeyK,


                                I understand that PCIe does seem a bit complicated, but we are working on a solution that will make it relatively easy to read/write via a DMA backend, which will hopefully simplify things (see my previous posts regarding Xillybus)


                                After looking through the cameras that were out there, I also jumped on the idea of a USB camera, whereas the rest of the sensors could be on a serial bus.  I still would like to have an interface to the sensors that's a little faster than 4MHz (maximum SPI rating on Galileo, with potential to go up to 25MHz), thus the FPGA.  However, if the sensors themselves can't talk too fast, the FPGA might be moot.  People do seem to like the FPGA from at least the standpoint of expandability via IOs, so I think we will definitely keep it around.


                                Haha, well the list of sensors was more of an idea sheet; I wouldn't think we'd put all these on the board.  And yes, I completely agree with the sensor modularity idea.  I'm just beginning the sensor search, but I want to stay focused on modules and things that would plug into the shield if possible, which are available to makers.  It would be even better if we had headers that talked various common interfaces (I2C, SPI, etc...) and therefore people could just plug it whatever modules they'd like.  I think this shield will be a bunch of headers primarily, offering complete flexibility.  Thanks for the links, I'll check them out.  I was already checking out the ultrasonic PING sensor by Parallax.


                                In regards to time sync, I have provided a few good examples from our time sync pro, above.  The purpose of the shield is to demonstrate this new technology, which is why the timer and clock are on the board.  I realize that the Quark already has the HPET and RTC, but we want to enable people to try out the time sync technology which is also on board the Quark (search for IEEE 1588 in the spec).




                                • 13. Re: Developing a New Galileo Shield

                                  Hi everyone,


                                  Just wanted to provide a quick update.  I want to thank Jim for not only posting on Twitter about the shield:



                                  ...but also for getting me in touch with the Galileo team in Ireland!  I will be discussing your great ideas for Galileo improvements and fixes with them.  If you have more, or more shield ideas, I'm all ears




                                  • 14. Re: Developing a New Galileo Shield

                                    Oh, also from Intel folks, there's a lot of talk about how popular FPGA shields for Arduino are in the maker forums.  There are a lot of cool designs out there which are doing something similar to my FPGA idea.  The one key difference is the PCIe link, which does require an FPGA with transceivers, so they don't transfer exactly, but they are useful for seeing how people have pinned out IOs.

                                    I've currently zeroed in on a low-end Cyclone IV (EP4CGX15, EP4CGX22 or EP4CGX30), which can be obtained on Digikey for $25, $50 or $75 depending on the number of logic elements you'd like.  I'd like to get a QFP or something easier for people to solder, but it's hard finding an FPGA with transceivers in an easy-to-solder package, if people decide to solder the boards together themselves.  The Cyclone IV does have one chip in a QFN (EP4CGX15), but that's still not the easiest to solder, plus you can't migrate between multiple FPGA sizes.  With the BGA package, you can migrate between the three packages I listed at the start of this post with no problem. 

                                    Again, the shield is still in early development, so I'll keep updating here as I find new information :-)







                                    1 2 Previous Next