41 Replies Latest reply on Dec 4, 2015 3:14 PM by clem57

    Snickerdoodle board on FLOSS Weekly

    Drew Fustini

      The Snickerdoodle board (featuring the Xilinx Zynq) was featured on FLOSS Weekly yesterday:


      FLOSS Weekly #360

      https://twit.tv/shows/floss-weekly/episodes/360?autostart=false

      An affordable platform for powering everything robots, drones, and computer vision.


      Snickerdoodle is a $55 hybrid development board that has an ARM application processor with an onboard FPGARyan Cousins (rcousins) cousins of krtkl (the creators) and David Scheltema (interested1) of MAKE magazine join Randal and Aaron to discuss the board.


      Here's the episode on YouTube:

       

       

       

      cheers,

      drew

        • Re: Snickerdoodle board on FLOSS Weekly
          John Beetem

          I haven't watched the video since most of my computers don't have sound hooked up, so this comment may already be addressed in the video:

           

          Snickerdoodle has a very impressive price for a Zynq board, but what's it doing on FLOSS weekly?  Don't you have to use the proprietary Xilinx Vivado software to program the Zynq FPGA?

            • Re: Snickerdoodle board on FLOSS Weekly
              gdstew

              Don't you have to use the proprietary Xilinx Vivado software to program the Zynq FPGA?

               

               

              Indeed you do. Just like you need proprietary software to use any ARM SoC GPU, except for the Pi. Now if we could just get schematics for the B+ and 2.

               

              The ARM cores on the Zynq can and do use Linux of course and its' GPU is also proprietary so like all of the others in some way or another it's a mixed bag.

               

              And just like the GPUs, I don't really see anything in the near (or distant) future that will change the proprietary nature of business model currently in use

              by all of the major. and most of the minor FPGA (or GPU) players.

              • Re: Snickerdoodle board on FLOSS Weekly
                Drew Fustini

                The closed toolchain is not ideal, but this is pretty much an universal problem for FPGA design.

                 

                I think FLOSS (Free/Libre/Open Source Software) is still relevant if a FPGA based project like this is releasing HDL "source code".

                 

                I've not gotten clarification on yet on whether their board is Open Source Hardware.  I hope that they will release schematics, PCB layout and BOM.  Could you comment, rcousins?

                  • Re: Snickerdoodle board on FLOSS Weekly
                    rcousins

                    fustini We're going to be posting the schematics & BOM in the next week or two (just have a few final tweaks to make to the power supply subsystem that will further decrease the standby/sleep power consumption).

                     

                    johnbeetem gdstew Of course, you could always synthesize an FPGA *in* the FPGA and run whichever open-source toolchain you'd like. While it's disappointing the tools aren't open, FPGAs are fundamentally the most open source silicon component you could ever ask for - you are in complete control over what the chip is doing at the gate level.

                     

                    We can only make open the software that's in our control (with the two primary closed-source items being the FPGA toolchain and the TI radio firmware). There are numerous technical (and, of course, "business") reasons these companies haven't totally opened up these tools, but we don't really believe/have faith in the 'sit and wait' method when it comes to changing paradigms or corporate philosophies.

                     

                    We just want to provide powerful tools for people to create and learn about new things. It's still possible to be a highly productive carpenter regardless of open/closed the designs of your hammer/saw/drill are. Ultimately, if enough people get this technology into their hands and truly want to affect change, we believe the "people" will find a way.

                     

                    As an aside, if someone has an open FPGA toolchain that has been proven to work with Zynq, we're more than happy to try it out and see how we can support it.

                     

                    -Ryan

                      • Re: Snickerdoodle board on FLOSS Weekly
                        John Beetem

                        Ryan Cousins wrote:

                         

                        John Beetem gdstew Of course, you could always synthesize an FPGA *in* the FPGA and run whichever open-source toolchain you'd like. While it's disappointing the tools aren't open, FPGAs are fundamentally the most open source silicon component you could ever ask for - you are in complete control over what the chip is doing at the gate level.

                        I understand that FPGA vendors are afraid to release their bitstream formats for reasons that seem good to them, and so their tools are therefore proprietary.  My objection is that some projects claim that they are FLOSS (Free-as-in-Liberty Open-Source Software) when a key component cannot be programmed with FLOSS tools.  BeagleBoard and BeagleBone are up front that the GPU is proprietary and cannot be programmed with FLOSS tools, but the GPU is a small part of BeagleBoard/Bone and many projects don't need it and can therefore be fully FLOSS.  Except for the GPU, there is enough information in the TI SoC tomes to write bare-metal applications.

                         

                        RasPi is more of a stretch.  As I understand it, the Broadcom documentation doesn't really give you enough information to write your own operating system and you must reverse-engineer from the Linux source code and use a "binary blob" to boot the GPU.  OTOH, they do document the GPU but I haven't heard whether RasPi users have been successful writing their own GPU applications and integrating them into actual RasPis.

                         

                        Yes, FPGAs are indeed powerful components but I don't agree with calling them an "open-source silicon component".  Yes, you can use them as a component of an OSHW design, but since you can't program them using a FLOSS toolchain (except for Lattice iCE40 thanks to the amazing IceStorm) you don't have any of RMS's "four freedoms".  If the proprietary tools don't give you the correct result, you can't go into the source code and figure out why.  You have to try a bunch of "black magic" and play with different ways of expressing a design at the source code level to cajole the software into doing the right thing.  This sort of nonsense is exactly what led RMS to his crusade.

                         

                        "Synthesizing an FPGA in an FPGA" can be useful, but as far as I can tell it makes terribly inefficient use of silicon resources and you cannot get good performance.  I think my Flavia project Flavia: the Free Logic Array is a wonderful tool for teaching about programmable logic, since it's small and fast: you can recompile and download a small design in a second or two.  IMO that's awesome compared to the longueurs you face using proprietary tools -- assuming you have the patience to download them in the first place and get the license to work.  OTOH, Flavia is really only suitable for small projects.  You can do a much bigger project with a tiny Lattice iCE40-HX1K and IceStorm than you can do with Flavia and the much larger Xilinx Spartan-6 LX9.

                         

                        Now, maybe there's a much better way to do an "FPGA within an FPGA".  However, I would think that if it were possible and practical we would have seen it by now.

                         

                        I should also mention that Flavia and other projects that manipulate Xilinx bitstreams can only do so because of the availability of Xilinx Design Language (XDL): Taming the Wild Bitstream.  I think I read somewhere that XDL is no longer available with Vivado.  I don't know if there's a substitute for it.

                          • Re: Snickerdoodle board on FLOSS Weekly
                            rcousins

                            johnbeetem By that logic, no ARM or x86 project or platform could *ever* be considered "FLOSS." Is anyone expecting ARM or Intel to provide the masks for their chips? How do you change the arrangement of the gates on the STM32 sitting on my desk? I'm a bit confused as to why FPGAs are somehow held to a different standard of "openness" than any other (closed) silicon component simply because they give you more granular control over the function and configuration of the chip. Oh, and the tools are free.

                             

                            Ignoring that for a moment, Zynq has a hard ARM core and you can use any open source tool you'd like to do whatever you want with the microprocessor - the I/O are simply routed through the programmable fabric (using the same AXI busses as any other ARM uC/uP).

                             

                            michaelkellett Hopefully a $55 board with an ARM processor, FPGA, and wireless falls into the category of 'low cost' - we've even taken care of the "talking to Xilinx" part for you

                             

                            Thanks, gdstew! Fully funded this morning...

                              • Re: Snickerdoodle board on FLOSS Weekly
                                michaelkellett

                                The Zynq is not in the running re low cost FPGAs  (and isn't meant to be) - the Lattice parts are MUCH simpler, come in packages you can hand solder (at least some of them) and in volume can cost less than $1 - not aimed at the same market at all.

                                 

                                But the cost of using a Zynq or any other SOC FPGA isn't just money - in order to get it to do anything much (ie to make serious use of the processor) you need a full blown OS which implies many megabytes of code - which will be sourced from a third party somehow (free or whatever).

                                If the application needs all this that's fine but if you just want an FPGA you'll do better not to have to maintain all the other stuff. In a lot of my work we end up with an FPGA (small by X standards at between 8 and 35k LUTs) and a Cortex M4 micro - if the Zynq chip was free we still wouldn't use it because the total cost of building and maintaining the product would go up.

                                 

                                Finally, how can I put this nicely, when a snag occurs with a chip you need to talk directly to the people who made it - the last thing you need is someone else doing your talking.

                                 

                                Your board may well be very nice (it's certainly a cheap way of getting  a Zynq chip)  and I wish you well with it but the cost of actually doing anything is only dominated by the cost of a dev board in home/hobby projects.

                                 

                                MK

                                  • Re: Snickerdoodle board on FLOSS Weekly
                                    weatherbee

                                    "you need a full blown OS which implies many megabytes of code"

                                     

                                    With regards to the Zynq specifically this is actually a completely false statement. The free Xilinx tools are designed to target Linux, FreeRTOS and *bare metal* and will include C driver files for any peripherals you use (like configuring the DDR at startup etc.).   You can go right ahead and write a 5 line program in main.c and load/execute it over JTAG just like a microcontroller and w/o any operating system.   This is totally supported by Xilinx and in fact is the way that most of the tutorials at http://zynqbook.com are done.    This is no suprise as you need to keep in mind that the very serious industries in which Zynq is used don't just care about slapping 10 million lines of buggy "off-the-shelf" code into a Linux powered multimedia appliance so they can make the next 8 week product cycle deadline.

                                  • Re: Snickerdoodle board on FLOSS Weekly
                                    John Beetem

                                    Ryan Cousins wrote:

                                     

                                    John Beetem By that logic, no ARM or x86 project or platform could *ever* be considered "FLOSS." Is anyone expecting ARM or Intel to provide the masks for their chips? How do you change the arrangement of the gates on the STM32 sitting on my desk? I'm a bit confused as to why FPGAs are somehow held to a different standard of "openness" than any other (closed) silicon component simply because they give you more granular control over the function and configuration of the chip. Oh, and the tools are free.

                                    ARM and x86 silicon is not software.  It's hardware.  It's proprietary hardware and nobody expects ARM or x86 to become OSHW.

                                     

                                    However, ARM and x86 silicon are a hardware platform that can be used for FLOSS (Free-as-in-Liberty Open-Source Software).  The ARM and x86 intruction sets are published, including both assembly language and their binary codings.  So as a programmer, you can write FLOSS that runs on those platforms and when you distribute source code your users have the option of modifying your source code for their own needs and recompiling it for their hardware.

                                     

                                    In addition, you can write a compiler for any language you want and generate ARM or x86 machine language.  You are not dependent on the chip maker.  You are not required to use (for example) PL/M for the x86 machine or (as a silly example) APL for the ARM.  You buy the chip, the manufacturer tells you what the instruction bits do, and you can write whatever software you want.  You have freedom.

                                     

                                    You don't get that kind of freedom with FPGAs other than iCE40.  You can't write your own compiler because you don't know what the machine-language bits do.  You have to use the Free-as-in-Beer tools from the FPGA vendor.  If they don't do what you want there's nothing you can do about it.  Yes, that's adequate for the majority of FPGA users and you can produce useful chips -- I do this professionally as a free-lance FPGA designer.  But there are a bunch of things that are impractical.  My favorite example is reconfigurable computing: FPGA tool bottleneck stalls HPC.  Reconfigurable computing doesn't sell a lot of chips for an FPGA vendor, so there's no motivation for them to produce tools that support it.  If FPGAs supported FLOSS, that wouldn't be a problem: other people could create that software.  The fact that the bitstream formats are proprietary means that they can't, and an amazingly useful FPGA application is stalled.

                                     

                                    I'm not asking Xilinx or any other FPGA vendor to provide masks, just like I don't expect Intel or ARM to document how they implement their instruction sets.  I just want to know how to set the bits in FPGA bitstreams to perform the functions documented in their architecture documentation.  That's all I need for FLOSS.

                                     

                                    Hope this helps

                                      • Re: Snickerdoodle board on FLOSS Weekly
                                        rcousins

                                        ARM and x86 silicon is not software.  It's hardware.  It's proprietary hardware and nobody expects ARM or x86 to become OSHW.

                                         

                                        However, ARM and x86 silicon are a hardware platform that can be used for FLOSS (Free-as-in-Liberty Open-Source Software).  The ARM and x86 intruction sets are published, including both assembly language and their binary codings.  So as a programmer, you can write FLOSS that runs on those platforms and when you distribute source code your users have the option of modifying your source code for their own needs and recompiling it for their hardware.

                                         

                                        In addition, you can write a compiler for any language you want and generate ARM or x86 machine language.  You are not dependent on the chip maker.  You are not required to use (for example) PL/M for the x86 machine or (as a silly example) APL for the ARM.  You buy the chip, the manufacturer tells you what the instruction bits do, and you can write whatever software you want.  You have freedom.

                                         

                                        Again, this part has an ARM processor.

                                        << "Synthesizing an FPGA in an FPGA" can be useful, but as far as I can tell it makes terribly inefficient

                                        use of silicon resources and you cannot get good performance.

                                         

                                        >> I'm not real big on this idea either for exactly the same reason.

                                         

                                        Neither am I, but it *is* possible...and you can make it as proprietary or open as you'd like. I can almost taste the freedom.

                                         

                                        << If the proprietary tools don't give you the correct result, you can't go into the source code and figure out why.

                                         

                                        >> I probably couldn't figure it out even if I had the source code. High speed logic routing and optimization

                                        of large FPGA designs is beyond my skill set and I would venture a guess that it is beyond yours and most

                                        other peoples' in the business as well.

                                         

                                        Indeed. Unfortunately this is a slightly different situation than messing something up and just doing a 'core dump' and starting over. If you decide you're more qualified than the chip/tool designers (and their 100s of thousands/millions of hours of experience and their army of engineers) to figure out what they've been doing wrong all this time and you start fiddling with the timing/optimization of these parts at the gate level, you're about 1,000x more likely to do something that's going to result in screwing something up so badly that the parts gets so hot that they melt solder and fall off the PCB than you are to find a better solution - regardless of the warm fuzzies you might experience along the way.


                                        On the other hand, it would be kinda cool to see...

                                        • Re: Snickerdoodle board on FLOSS Weekly
                                          weatherbee

                                          So if you have a closed-source binary bitstream for the FPGA that implements a GPU/DSP/accelerator and you openly provide the instruction set that that closed HDL source accelerator executes (Which is also synthesized with a closed source FPGA toolchain).

                                           

                                          Then all of a sudden that would be open-source?

                                           

                                          Because that's precisely how most semiconductor IP is deployed --- like the ARM or GPU on your RPi/Arduino/BeagleBone

                                          But magically they are more "open source" than Zynq?

                                            • Re: Snickerdoodle board on FLOSS Weekly
                                              shabaz

                                              Hi Jamil,

                                               

                                              You may have a great product, but your last two comments are quite rude. You only quoted a portion of the sentence, it actually said

                                              "in order to get it to do anything much (ie to make serious use of the processor) you need a full blown OS" and that is the case.

                                              Who has the time to re-write the tens of thousands of lines of code that are present in rich Linux libraries to run bare-metal?

                                              To make intensive use of an application processor in a practical amount of time, you do need the support of a full-blown OS.

                                              With all the associated problems of having a team to manage the OS, packages and build.

                                               

                                              It seems a team-wide issue. Your colleague (Ryan) was also rude on hackaday to makers in general when he said (quote):

                                              ""I am coming to the realization (maybe a little too late) that “makers” really aren’t interested in building anything beyond a LED-enabled garage door opener or an automated cat feeder."

                                               

                                              If makers are your target market, then you and your team might want to be polite to potential customers.

                                               

                                              Someone else on hackaday said to Ryan "You should really have a friendlier person handling your social media presence. I know you probably didn’t intend it, but you kinda came off as a xyz".

                                                • Re: Snickerdoodle board on FLOSS Weekly
                                                  rcousins

                                                  shabaz In reference to the partial conversation you quoted, I subsequently apologized to this person on Hackaday

                                                   

                                                  <<Hi xxx and everyone – I apologize. I haven’t slept much recently…or in a long time. I haven’t had a decent meal in weeks. I haven’t seen a lot of my closest friends in months. I literally wake up and do nothing but work on this project all day every day 7 days a week. It’s not a hobby or a past time. It’s my life. Needless to say, it means a lot to me.

                                                  I don’t expect everyone to agree with what we’re doing or find it interesting or really care about us or our project for that matter. I do occasionally let my frustration get the better of me when I hear people badmouthing or second-guessing our intentions, our ability, our dedication, and, in some cases, our integrity. And for that, I am sorry.

                                                  We have put more of our time, bodies, and souls into this than most would consider reasonable or even humanly possible. We’ve been told – and continue to be told – it’s a bad idea and that we should give up and do something different/easier for more reasons and by more people than I can count.

                                                  Ultimately, if we can’t get anyone else to buy into the *vision* of what we’re proposing to provide, there’s really no one to blame but ourselves. And if that’s that case, it’s just something we’ll have to live with.

                                                  So again, my apologies for coming off as a **. My emotions got the better of me.>>

                                                   

                                                  Not sure if you've ever been part of a crowdfunding campaign or a public product launch but to say it's a stressful time would be a severe understatement. I got caught up in the moment (after taking countless personal and professional bashings for a product we'd just released into the wild a few days prior). The moment passed and I have since had dozens of fruitful and civil conversations with the folks at Hackaday and the folks here at Element, like yourself. Only time will tell how the maker audience receives our product, but we certainly hope the initial dream when we started on this project - of making professional-caliber development tools more accessible and usable for makers, students, and hobbyists so that they may take their projects to the next level and directly contribute to the next generation of great technological advances - comes to fruition.

                                                   

                                                  And I'd have to politely disagree with your statement that this was being misrepresented:

                                                  "in order to get it to do anything much (ie to make serious use of the processor) you need a full blown OS" and that is the case.

                                                   

                                                  in the sense that these two statements: "in order to get it to do anything much" and "to make serious use of the processor" contradict each other (or, at the very least, one does not imply the other). Maybe to "make serious use of the processor" typically does involve a full-blown OS. But it's just not true that you need a full blown OS to "get it to do anything much." Unless I am misunderstanding what you are saying or you see it differently?

                                                    • Re: Snickerdoodle board on FLOSS Weekly
                                                      shabaz

                                                      Hi Ryan,

                                                       

                                                      I'm not going to comment any more on the rest, but regarding the OS issue, everyone's opinion on what 'serious use' (which is how the text 'do anything much' was qualified in the original text) means could vary. Serious use means different things to different people, as does doing anything much. I interpret serious use as "using modern protocols, application frameworks and software services which by nature entail using many of the building blocks of the built-in SoC". These would in a lot of cases entail the use of an OS such as Linux in practice. And in other peoples opinion serious use may not mean the same thing at all.

                                                      Basically, a body of engineers would agree, and a body of engineers may disagree, and

                                                      there is no harm in that.

                                                      Which is why it is odd for someone to say it is a "completely false statement" in bold

                                                      and italics on this point.


                                                        • Re: Snickerdoodle board on FLOSS Weekly
                                                          rcousins

                                                          Fair enough, shabaz. Not trying to beat this into submission or anything but (formatting aside), I think you gotta admit that "do anything much" is a generalization - and, contextually or not, it is actually not true. I totally appreciate that this particular comment was being made from one individual's point of view. But there are thousands (or more) of application examples taking full advantage of  uPs yet are not running any sort of OS (i.e. bare metal).

                                                           

                                                          Naturally every system is different and different approaches to the same problem can be equally valid.

                                                      • Re: Snickerdoodle board on FLOSS Weekly
                                                        weatherbee

                                                        Shabaz, I'm not out to hurt anyone's feelings here.  My comments were a bit sarcastic and hyperbolic for the sake of illustration but definitely not intended to be rude or hurtful. 

                                                         

                                                        My interpretation was that the original writer was *complaining* about having to boot a full blown multi-megabyte OS and I was pointing out the the gratis Zynq toolchain heavily directly supports not doing this.

                                                         

                                                        And my reference to "serious applications" wasn't intended to disparage makers but rather contrast the OS support demands of commercial industrial uses (like motor controls) with commercial consumer uses (like BluRay players).   I can assure you genuinely that the comment was not at all directed towards the maker community.

                                                         

                                                        With regards to the second comment my entire point is that the snickerdoodle being held to a higher open-source standard than every other single board computer designed for this market simply because we have an FPGA.   That's not at all fair and equitable at all as noone is asking Broadcom to release the source code to the tools they used to synthesize the VideoCore IV or asking ARM or Intel to do the same for their synthesis tools.

                                                         

                                                        So again I apologize if I hurt anyone's feelings but the original premise of this thread --- that somehow we aren't open-source/didn't deserve to be considered open-source/should have not been interviewed on FLOSS weekly when we are openly giving away a lot of material to the community that was very costly in real dollars $$$ and personal sacrifice to produce and much of which was funded out of own pockets did hurt my feelings.

                                                          • Re: Snickerdoodle board on FLOSS Weekly
                                                            michaelkellett

                                                            My, but you guys have a serious attitude issue !!

                                                             

                                                            I'm the original writer referred to here:

                                                             

                                                            My interpretation was that the original writer was *complaining* about having to boot a full blown multi-megabyte OS and I was pointing out the the gratis Zynq toolchain heavily directly supports not doing this.

                                                             

                                                             

                                                            and I wrote in response to the suggestion that because your board only costs $55 it makes the Zynq cheap compared with simple FPGA s from Lattice.

                                                            I wasn't *complaining* - I was pointing out that there are applications where the Zynq and other similar SOC chips are not appropriate.

                                                             

                                                            And with regard to the cost of the dual ARM application processors on the Zynq - what is the point of them if you don't use them - they cost silicon (ie money) power etc. And how much other stuff does your 5 line program drag into the system ?

                                                             

                                                            And yet another point - the "gratis" tool chain  - is that like Free-as-in-Beer but with an overtone that we should damn well be grateful too !

                                                             

                                                            If I use a stand alone processor I can CHOOSE the tool chain (which I think was part of the point JB was making).

                                                             

                                                            Let's get this into perspective,

                                                            the Zynq is a nice chip for the applications that it fits, it's not the only FPGA SOC (Micro Semi and Altera have parts too), it's not the first (that was Atmel) and it isn't the answer to every FPGA user's prayer.

                                                            Your board may be quite nice too (I said that earlier)  - it's certainly cheap but if you want to prototype a mW power data logging system it's about a such use as bull in a china shop.

                                                             

                                                            You need to lighten up a bit, fine to be proud of your work but don't oversell it, and don't be so pushy - other people have feelings (and brains) too.

                                                             

                                                            MK

                                                              • Re: Snickerdoodle board on FLOSS Weekly
                                                                John Beetem

                                                                Michael Kellett wrote:

                                                                 

                                                                And yet another point - the "gratis" tool chain  - is that like Free-as-in-Beer but with an overtone that we should damn well be grateful too !

                                                                I'm grateful for Free Beer -- especially at the end of a long day at the Embedded Systems Conference or ARM TechCon

                                                                • Re: Snickerdoodle board on FLOSS Weekly
                                                                  weatherbee

                                                                  Michael Kellett wrote:

                                                                   

                                                                  My, but you guys have a serious attitude issue !!

                                                                  I'm not sure where you are drawing this assertion from but I believe I did a more than adequate job earlier of apologizing for how some readers may have interpreted the manner in which I presented the facts.

                                                                  That said, I'm still going to stick to the technical facts as there is no other reason to participate in the technical forums.

                                                                  Hopefully, a debate of the technical facts is possible without having disagreements degrade into personal attacks.

                                                                  • Re: Snickerdoodle board on FLOSS Weekly
                                                                    weatherbee

                                                                    And yet another point - the "gratis" tool chain  - is that like Free-as-in-Beer but with an overtone that we should damn well be grateful too !

                                                                    With regards to the term "gratis" I can reassure you there was no "overtone" as you put it demanding that you or others be grateful.

                                                                    In fact the term "gratis" was a direct reference to how proprietary software that is provided at no charge is described by Richard Stallman himself.

                                                                     

                                                                    See:  https://www.youtube.com/watch?v=uFMMXRoSxnA&feature=youtu.be&t=2m40s

                                                                    • Re: Snickerdoodle board on FLOSS Weekly
                                                                      rcousins

                                                                      Let's get this into perspective,

                                                                      the Zynq is a nice chip for the applications that it fits, it's not the only FPGA SOC (Micro Semi and Altera have parts too), it's not the first (that was Atmel) and it isn't the answer to every FPGA user's prayer.

                                                                      Your board may be quite nice too (I said that earlier)  - it's certainly cheap but if you want to prototype a mW power data logging system it's about a such use as bull in a china shop.

                                                                       

                                                                      You need to lighten up a bit, fine to be proud of your work but don't oversell it, and don't be so pushy - other people have feelings (and brains) too.

                                                                       

                                                                      Certainly understood, michaelkellett - all I was saying was 'hopefully $55 for ARM + wireless + >150 reconfigurable I/O (FPGA) falls into the category of low-cost.' Wasn't trying to imply that you need/should/have to use it. We understand as well as anybody that this isn't for everybody or every application. Just trying to bring what has traditionally been extremely expensive and complicated capabilities to an audience that otherwise wouldn't have access to/the ability to use it so that they may create the kinds of things that having these capabilities enables them to create. That's all.

                                                                       

                                                                      We try to go out of our way to engage with the community as much as possible to answer questions and clarify things. Would I rather meet everyone here in person? Of course - and I go to as many in-person events to talk with as many folks like yourself as possible. But we want to provide support or knowledge or whatever it may be in whatever form that might take whenever possible. This typically leads to dynamic, thought-provoking discussion about all kinds of topics, but if people would prefer that we leave the forum for whatever reason, just let me know.

                                                                        • Re: Snickerdoodle board on FLOSS Weekly
                                                                          michaelkellett

                                                                          No  - don't go - this is one of the most interesting threads on E14 in while !

                                                                           

                                                                          I just told myself to get on with some work until I saw that bit on your post.

                                                                           

                                                                          Re: Software/Hardware  - it seems to me that there is quite a big blurry bit in the middle - to me it's definitely hardware when you get thinking about registers and clock cycles and software when you write apps that run anywhere. But I write mainly very low level software where I'm interacting very closely with the hardware so it might be C but it's close to the metal. Ashenden is right that good use of  HDLs requires software skills but I suppose there is a corollary that says that to do good software work near the boundary you need hardware skills.

                                                                           

                                                                          MK

                                                                • Re: Snickerdoodle board on FLOSS Weekly
                                                                  weatherbee

                                                                  "ARM and x86 silicon is not software"

                                                                   

                                                                  Believe it or not so far as we are talking about not having a FLOSS toolchain to synthesize HDL to a particular FPGA, ARM cores are in general provided as HDL and so far as HDL is a software discipline (which is how it is described by at least some portion of industry experts) it is in a sense software.

                                                                   

                                                                  So in a sense (and especially with gate array ASICs, but progressively less so with Standard-cell and full-custom ASICs) you are very likely already using closed-source HDL defined "silicon" that looks pretty much identical to an FPGA (with the exception of being field re-programmable) and that is characterized as FLOSS friendly/compatible/worthy so long as the instruction set is openly published.

                                                                   

                                                                  What isn't software arguably is the underlying physical transistor/cell libraries used by the foundries to actually implement the HDL provided by ARM and their licensees (like Broadcom, TI, etc.)

                                                                    • Re: Snickerdoodle board on FLOSS Weekly
                                                                      John Beetem

                                                                      Jamil Weatherbee wrote:

                                                                       

                                                                      "ARM and x86 silicon is not software"

                                                                       

                                                                      Believe it or not so far as we are talking about not having a FLOSS toolchain to synthesize HDL to a particular FPGA, ARM cores are in general provided as HDL and so far as HDL is a software discipline (which is how it is described by at least some portion of industry experts) it is in a sense software.

                                                                      As a matter of fact, I don't believe it.  In my experience, hardware and software are very different and suited to very different things.  When designing hardware you have to think about everything happening at once, and how to make them all happen at once faster, whereas with software you're usually thinking about a single often complex thread of execution.  Verilog looks a lot like C, which is convenient but can be misleading.  Marketing would like you to believe that a C programmer can effortlessly become a Verilog designer because the languages have similar syntax.  In practice, I've heard that many C programmers try to write in Verilog as if it were C and produce terrible designs.

                                                                       

                                                                      At Design West 2013 there was a talk called "FPGA Design: What works and what makes you work weekends" at the Expo Theater.  The two speakers were Charles Fulks and RC Cofer.  According to my notes, it was Charles Fulks who said he preferred that his FPGA designers use VHDL instead of Verilog to make it obvious that they aren't using a programming language and must think differently.

                                                                       

                                                                      I don't know who your industry experts are who think of "HDL as a software discipline", so if you supply links I might be interested in how they come to that conclusion.

                                                                        • Re: Snickerdoodle board on FLOSS Weekly
                                                                          Jan Cumps

                                                                          I would classify it as hardware too. But the fact that we're discussing it here - (and more similar discussions are happening on the webs) - may indicate that we're verging into an area where boundaries are new and not so clear.

                                                                           

                                                                          The reason why I consider it hardware is because a VHDL or Verilog source file can be represented as a schematic (you can convert from HDL to schematic and vice versa). And for me that means it's hardware. But I also think that someone can step in and just invalidate my arguments here.

                                                                            • Re: Snickerdoodle board on FLOSS Weekly
                                                                              weatherbee

                                                                              Jan Cumps wrote:

                                                                               

                                                                              I would classify it as hardware too. But the fact that we're discussing it here - (and more similar discussions are happening on the webs) - may indicate that we're verging into an area where boundaries are new and not so clear.

                                                                               

                                                                              The reason why I consider it hardware is because a VHDL or Verilog source file can be represented as a schematic (you can convert from HDL to schematic and vice versa). And for me that means it's hardware. But I also think that someone can step in and just invalidate my arguments here.

                                                                              I agree that the line between software and hardware is fuzzier than it has ever been.

                                                                               

                                                                              An interesting thought experiment would be to consider that for the kind of deterministic bounded software we are talking about (meaning the kind that runs on a conventional computer) there necessarily exists a schematic that would describe any real conventional computer and the initial program that is loaded into its memory at reset.

                                                                                • Re: Snickerdoodle board on FLOSS Weekly
                                                                                  John Beetem

                                                                                  Jamil Weatherbee wrote:

                                                                                  An interesting thought experiment would be to consider that for the kind of deterministic bounded software we are talking about (meaning the kind that runs on a conventional computer) there necessarily exists a schematic that would describe any real conventional computer and the initial program that is loaded into its memory at reset.

                                                                                  Absolutely.  You can take all the expressions in a program and convert them into a data flow graph, which is essentially the same as a schematic.  Optimizing compilers do this.  You can then take the control flow sans expressions and render it as a flowchart, which maps trivially into a one-hot state machine implementation.

                                                                                   

                                                                                  That makes a nice model, but is an absurd way to implement software.  Any practical program results in a huge amount of logic, only a tiny fraction of which needs reëvaluation on any given clock cycle.  The reason a microprocessor is such a cheap way to implement software is that the logic functions are all shared by a single CPU or a small number of them.

                                                                                    • Re: Snickerdoodle board on FLOSS Weekly
                                                                                      weatherbee

                                                                                      John Beetem wrote:

                                                                                       

                                                                                      Absolutely.  You can take all the expressions in a program and convert them into a data flow graph, which is essentially the same as a schematic.  Optimizing compilers do this.  You can then take the control flow sans expressions and render it as a flowchart, which maps trivially into a one-hot state machine implementation.

                                                                                       

                                                                                      That makes a nice model, but is an absurd way to implement software.  Any practical program results in a huge amount of logic, only a tiny fraction of which needs reëvaluation on any given clock cycle.  The reason a microprocessor is such a cheap way to implement software is that the logic functions are all shared by a single CPU or a small number of them.

                                                                                      And that CPU is a FSMD.  I think the very fact that you can implement general purpose microcontrollers/microprocessors in an FPGA at a relatively low cost addresses the practicality of the model I was using.

                                                                                      My point was that the initial "code" and "data" can be described as a schematic containing flip flops that are wired to reset in a specific state. 

                                                                                • Re: Snickerdoodle board on FLOSS Weekly
                                                                                  weatherbee

                                                                                  John Beetem wrote:

                                                                                   

                                                                                  As a matter of fact, I don't believe it.  In my experience, hardware and software are very different and suited to very different things.  When designing hardware you have to think about everything happening at once, and how to make them all happen at once faster, whereas with software you're usually thinking about a single often complex thread of execution.  Verilog looks a lot like C, which is convenient but can be misleading.  Marketing would like you to believe that a C programmer can effortlessly become a Verilog designer because the languages have similar syntax.  In practice, I've heard that many C programmers try to write in Verilog as if it were C and produce terrible designs.

                                                                                   

                                                                                  At Design West 2013 there was a talk called "FPGA Design: What works and what makes you work weekends" at the Expo Theater.  The two speakers were Charles Fulks and RC Cofer.  According to my notes, it was Charles Fulks who said he preferred that his FPGA designers use VHDL instead of Verilog to make it obvious that they aren't using a programming language and must think differently.

                                                                                   

                                                                                  I don't know who your industry experts are who think of "HDL as a software discipline", so if you supply links I might be interested in how they come to that conclusion.

                                                                                  Informally I've heard it described this way on several occasions by others and it is the way I have also personally experienced hardware design having started very young in embedded with a low-level software approach (assembly, Forth, C) eventually moving mostly to analog, power electronics and digital hardware design.

                                                                                   

                                                                                  One formal reference I can quote that implies this is Peter J. Ashenden's 2008 tome on VHDL "The Designer's Guide to VHDL Third Edition" pp. xvii:

                                                                                  "One pervasive theme running through the presentation in this book is that modeling a system using a hardware description language is essentially a software design exercise.  This implies that good software engineering practice should be applied.  Hence the treatment in this book draws directly from experience in software engineering."

                                                                                   

                                                                                  Also, I can point out that technologies like model based design, HDL simulation, high level synthesis and massively parallel programming suggest a much stronger link between software and hardware disciplines than I think is commonly credited.

                                                                                    • Re: Snickerdoodle board on FLOSS Weekly
                                                                                      John Beetem

                                                                                      Jamil Weatherbee wrote:

                                                                                       

                                                                                      One formal reference I can quote that implies this is Peter J. Ashenden's 2008 tome on VHDL "The Designer's Guide to VHDL Third Edition" pp. xvii:

                                                                                      "One pervasive theme running through the presentation in this book is that modeling a system using a hardware description language is essentially a software design exercise.  This implies that good software engineering practice should be applied.  Hence the treatment in this book draws directly from experience in software engineering."

                                                                                      This brings up an interesting issue with VHDL and Verilog.  VHDL stands for VHSIC Hardware Description Language, originally designed to document and simulate IC behavior.  Simularly, Verilog (from Verification+Logic) was also designed originally for simulation.  As new users discover to their chagrin, neither language was created as a hardware design language and it's easy to write VHDL or Verilog that simulates fine but when you try to synthesize for an FPGA it either doesn't work or generates horrible logic.

                                                                                       

                                                                                      So you can in fact write VHDL or Verilog that is very much like software, but you'll probably regret it

                                                                                        • Re: Snickerdoodle board on FLOSS Weekly
                                                                                          weatherbee

                                                                                          John Beetem wrote:

                                                                                           

                                                                                          This brings up an interesting issue with VHDL and Verilog.  VHDL stands for VHSIC Hardware Description Language, originally designed to document and simulate IC behavior.  Simularly, Verilog (from Verification+Logic) was also designed originally for simulation.  As new users discover to their chagrin, neither language was created as a hardware design language and it's easy to write VHDL or Verilog that simulates fine but when you try to synthesize for an FPGA it either doesn't work or generates horrible logic.

                                                                                           

                                                                                          So you can in fact write VHDL or Verilog that is very much like software, but you'll probably regret it

                                                                                          There is only a subset of VHDL that is trivially synthesizable.  The rest can be used for test benches, system simulations or even as a general purpose parallel programming language that is executable on an ordinary computer.

                                                                                           

                                                                                          However, the ordinary computer you are running that test bench, simulation or program on can definitely be described in a synthesizable form of VHDL and so it follows logically that all VHDL in a sense can be hardware or software which begs the original question:  is there even a difference?

                                                                                           

                                                                                          Now, at the risk of starting a religious war over the software vs. hardware question I would assert that some forms of describing computation are less difficult than others for humans to utilize and this depends on both the application and who/what is expressing it but ultimately the hardware expression of computation is always equal or more capable than the general purpose software expression.  That's why http://snickerdoodle.io has both so you can pick what you want to use.  This isn't intended as a plug specifically but that in my mind makes an FPGA SoC the ultimate computing resource.

                                                                                            • Re: Snickerdoodle board on FLOSS Weekly
                                                                                              John Beetem

                                                                                              Jamil Weatherbee wrote:

                                                                                               

                                                                                              ... which begs the original question:  is there even a difference [between hardware and software]?

                                                                                              Probably my favorite computer science quote is from David Wheeler: "All problems in computer science can be solved by another level of indirection."

                                                                                               

                                                                                              Software always involves a level of indirection.  Software produces machine code that needs to be interpreted by a computing machine, whereas hardware doesn't need this level of indirection.  Hard to say what this means for FPGAs: are an FPGA's LUTs, configurable muxes, and Programmable Interconnect Points (PIPs) another level of indirection or merely a trivial implementation detail?  I would say the latter, since it is trivial to map an FPGA into a hard-wired gate array, replacing the programmable LUTs, muxes, and PIPs with wires and vias.

                                                                                               

                                                                                              JMO/YMMV

                                                                                  • Re: Snickerdoodle board on FLOSS Weekly
                                                                                    gdstew

                                                                                    Ryan,

                                                                                     

                                                                                    I know, I know. I checked it out first thing this morning !! Now the really hard part, waiting for March 2016.

                                                                                  • Re: Snickerdoodle board on FLOSS Weekly
                                                                                    gdstew

                                                                                    << but the GPU is a small part of BeagleBoard/Bone and many projects don't need it and can therefore be fully FLOSS.

                                                                                     

                                                                                    >> And others do need it which makes it not FLOSS. Is this some kind of quantum FLOSS ? You make this argument

                                                                                    all the time and it still does not make sense. By the very definition there is no FLOSS when your SoC contains proprietary

                                                                                    hardware no matter how fine you try (and try, and try) to split that hair.

                                                                                     

                                                                                     

                                                                                    << As I understand it, the Broadcom documentation doesn't really give you enough information to write your own operating system and you must reverse-engineer from the Linux source code and use a "binary blob" to boot the GPU.

                                                                                     

                                                                                    >> BSD ? RISCOS ? There has also bee a port to an RTOS. I don't remember which RTOS but I was part of a

                                                                                    discussion about porting it in these forums and the person trying to do it made the same argument as you. After

                                                                                    pointing him to the Broadcom documentation he was able to complete the port. Your "understanding" needs updating.

                                                                                     

                                                                                    >> Since the GPU documentation has been released, an assembler and disassembler have been made available

                                                                                    which allows anyone to disassemble the boot code. Since BSD, RISCOS, a couple of bare metal projects and

                                                                                    the RTOS port I spoke of earlier use the existing boot loader, I'm not sure why using the binary blob is such a

                                                                                    bad thing but it is nice to be able to produce an alternative.

                                                                                     

                                                                                     

                                                                                    << OTOH, they do document the GPU but I haven't heard whether RasPi users have been successful writing their own GPU applications and integrating them into actual RasPis.

                                                                                     

                                                                                    >> I have seen a couple of projects that do. Google it with "using raspberry pi GPU" and learn.

                                                                                     

                                                                                     

                                                                                    << If the proprietary tools don't give you the correct result, you can't go into the source code and figure out why.

                                                                                     

                                                                                    >> I probably couldn't figure it out even if I had the source code. High speed logic routing and optimization

                                                                                    of large FPGA designs is beyond my skill set and I would venture a guess that it is beyond yours and most

                                                                                    other peoples' in the business as well.

                                                                                     

                                                                                     

                                                                                    << "Synthesizing an FPGA in an FPGA" can be useful, but as far as I can tell it makes terribly inefficient

                                                                                    use of silicon resources and you cannot get good performance. 

                                                                                     

                                                                                    >> I'm not real big on this idea either for exactly the same reason.

                                                                                     

                                                                                     

                                                                                    << I think my Flavia project Flavia: the Free Logic Array is a wonderful tool for teaching about programmable logic, since it's small and fast: you can recompile and download a small design in a second or two.  IMO that's awesome compared to the longueurs you face using proprietary tools -- assuming you have the patience to download them in the first place and get the license to work.  OTO FH,lavia is really only suitable for small projects.  You can do a much bigger project with a tiny Lattice iCE40-HX1K and IceStorm than you can do with Flavia and the much larger Xilinx Spartan-6 LX9.

                                                                                     

                                                                                    >> As you say, the Vivado Design Suite is not a tool for teaching about programmable logic. It is a fully

                                                                                    professional tool for creating large, high speed logic designs. Comparing these two objectives and the

                                                                                    complexity of the tools needed are like comparing building and an Estes model rocket to a Saturn V. It

                                                                                    just doesn't work as a reasonable argument.

                                                                                     

                                                                                    >> It took about 20 minutes to download the 6.9 GB VDS and another few minutes to download some other files.

                                                                                    Modern high speed Internet (mine is "only" 50 Mb/s although I have seen it hit, but not hold closer to 80 on

                                                                                    one or two occasions) is a wonderful thing. YMMV.

                                                                                      • Re: Snickerdoodle board on FLOSS Weekly
                                                                                        John Beetem

                                                                                        Gary Stewart wrote:

                                                                                         

                                                                                        After pointing him to the Broadcom documentation he was able to complete the port. Your "understanding" needs updating... Google it with "using raspberry pi GPU" and learn.

                                                                                         

                                                                                        ....

                                                                                         

                                                                                        I probably couldn't figure it out even if I had the source code. High speed logic routing and optimization of large FPGA designs is beyond my skill set and I would venture a guess that it is beyond yours and most other peoples' in the business as well.

                                                                                        I'm delighted to hear that people are successful using the RasPi GPU in practice.  I may check it out myself some time.  I've looked at the GPU instruction set and it's a nice SIMD architecture.  Amazing amount of performance there in a $20 - $35 board.

                                                                                         

                                                                                        Regarding your experience with design automation software: I would venture to say that very few people have the motivation to learn Linux kernel programming, yet there are enough that do to produce an amazingly great FLOSS operating system.  In fact, I've done a great deal of design automation research and teaching in my career and the optimization algorithms involved are not any more complex that those used by optimizing compilers.  The lesson of Linux is that the number of people required to get a project like this started is one and that a small number of people joining in can do great things (confirmed by the lessons of Unix, C, and ARM).  Indeed, a small, indpendent project not hampered by millions of lines of legacy code can do amazing things.

                                                                                         

                                                                                        In case it isn't clear, I'm not in the least bit interested in looking at Xilinx source code.  I just want them to document their bitstream format -- something already done by every major CPU maker -- so that the open-source community can write our own tools.

                                                                                          • Re: Snickerdoodle board on FLOSS Weekly
                                                                                            gdstew

                                                                                            << Regarding your experience with design automation software: I would venture to say that very few people have the motivation to learn Linux kernel programming, yet there are enough that do to produce an amazingly great FLOSS operating system.

                                                                                             

                                                                                            >> If you have a different experience with free PCB software I would love to hear where I can pick up a free version that really matches any of the commercial products.

                                                                                            Clearly the "Linux experience" doesn't apply here.

                                                                                             

                                                                                             

                                                                                            << In fact, I've done a great deal of design automation research and teaching in my career and the optimization algorithms involved are not any more complex that those used by optimizing compilers.

                                                                                             

                                                                                            >> Yet after 15+ years they don't appear in free PCB software. Perhaps you could be the one, or are you not that interested (see what I mean ?). Also I would venture

                                                                                            another guess that there are significant differences between PCB and FPGA optimization due to such things as vastly tighter physical contraints, route restictions due to

                                                                                            physical gate/cell/LUT layout and interconnection number limits, greater noise and crosstalk problems, power, clock distribution, and the difference in the scale of the

                                                                                            number of routes/connections. And that's just for one device/family.

                                                                                             

                                                                                             

                                                                                            << The lesson of Linux is that the number of people required to get a project like this started is one and that a small number of people joining in can do great things (confirmed by the lessons of Unix, C, and ARM).  Indeed, a small, indpendent project not hampered by millions of lines of legacy code can do amazing things.

                                                                                             

                                                                                            >> Yet again even after 15+ years all that wonderfulness has not happened when it comes to relatively "simple" PCB design software. Why would the much more

                                                                                            complicated FPGA tool set(s) be different ? One mans being hampered by legacy code is another mans years of experience and hard learned lessons. In the case

                                                                                            of FPGAs I'll go with experience and years of bugs fixed instead of years of fixing bugs. Also, ARM does not really belong in that group at all, it is now and has

                                                                                            always been a fully proprietary product.

                                                                                             

                                                                                             

                                                                                            << In case it isn't clear, I'm not in the least bit interested in looking at Xilinx source code.

                                                                                            <<"If the proprietary tools don't give you the correct result, you can't go into the source code and figure out why."

                                                                                             

                                                                                            >> So there are exceptions ?

                                                                                             

                                                                                             

                                                                                            << I just want them to document their bitstream format

                                                                                             

                                                                                            >> Yes, and I have said on several occasions that I would like to see that too, but it is not going to happen no matter how many times you or I say we want it. So now what ?

                                                                                            The next best thing is reasonably priced fully professional tools that take full advantage of the intimate knowledge of the physical devices and years of experience with building

                                                                                            tools for them. Until recently these tools have been non-existent and they are still the exception.

                                                                                             

                                                                                             

                                                                                            >> something already done by every major CPU maker

                                                                                             

                                                                                            << You can't distribute the "software" to make your own ARM core or any other major CPU core for that matter in a gate array or FPGA without getting sued.

                                                                                              • Re: Snickerdoodle board on FLOSS Weekly
                                                                                                John Beetem

                                                                                                Gary Stewart wrote:

                                                                                                 

                                                                                                If you have a different experience with free PCB software I would love to hear where I can pick up a free version that really matches any of the commercial products.  Clearly the "Linux experience" doesn't apply here.

                                                                                                I don't design PC boards these days so I haven't checked out the latest open-source or freeware PCB software packages.  I've heard that some are quite good.  It's not really necessary to match a commercial product -- you just need something that's adequate for your needs.  I've watched layout gurus work with commercial software packages and frankly I'm not impressed with the usability of the software I've seen.

                                                                                                 

                                                                                                Anyway, here are some open-source or freeware PCB links:

                                                                                                 

                                                                                                KiCAD: http://www.eetimes.com/author.asp?doc_id=1320005

                                                                                                Low Cost PCB tools: http://www.eetimes.com/author.asp?section_id=36&doc_id=1319924

                                                                                                Software is too expensive: http://www.element14.com/community/thread/31852

                                                                                                Gary Stewart wrote:

                                                                                                 

                                                                                                Yet after 15+ years they don't appear in free PCB software. Perhaps you could be the one, or are you not that interested (see what I mean ?).  Also I would venture another guess that there are significant differences between PCB and FPGA optimization due to such things as vastly tighter physical contraints, route restictions due to

                                                                                                physical gate/cell/LUT layout and interconnection number limits, greater noise and crosstalk problems, power, clock distribution, and the difference in the scale of the number of routes/connections. And that's just for one device/family.

                                                                                                Placement and routing for FPGAs is simpler than PCB because you don't have to deal with so many design rules.  Routing is quite easy once you know where the PIPs are.  I don't need to be "the one" -- arachne-pnr is in my experience a fine tool for Lattice iCE40.

                                                                                                Gary Stewart wrote:

                                                                                                 

                                                                                                Yes, and I have said on several occasions that I would like to see [FPGA vendors document their tool chains] too, but it is not going to happen no matter how many times you or I say we want it. So now what?

                                                                                                If you and/or I are the only ones who ask for it, of course nothing is going to happen.  But if everyone who cares about the issue advocates for it, the spark can catch on and become a fire.

                                                                                                 

                                                                                                Meanwhile, there have been and are projects to reverse-engineer bitstream formats.  There have been several attempts for Xilinx FPGAs, but I don't know of any that completed the job.  IceStorm chose a simpler FPGA and is the only one I know of that has a complete mapping.  This is a fantastic achievement and Lattice appears to realize that this is a good thing for Lattice: it increases interest in their chips and differentiates their chips from Brands X and A.  When Brand X and A realize that Lattice is taking away business, they'll be motivated to document their bitstreams.  I've been waiting 25 years for this.  A few more is nothing.

                                                                                                 

                                                                                                You have to be careful about reverse-engineering in the USA.  Europe allows reverse-engineering for interoperability, which is probably why all the bitstream reverse-engineering work I've seen is from Europe.

                                                                                                • Re: Snickerdoodle board on FLOSS Weekly
                                                                                                  clem57

                                                                                                  Last point... I have seen cpu architecture simulated in software not efficient but great debugging tool.

                                                                                                  Clem

                                                                                        • Re: Snickerdoodle board on FLOSS Weekly
                                                                                          gdstew

                                                                                          Drew: I hope that they will release schematics, PCB layout and BOM.

                                                                                           

                                                                                          Schematics and BOM definitely, never really understood the need for PCB layout unless there is a layout related problem. If there is, there is not much I can do to fix it

                                                                                          especially in today's 6 or more layer SBC world. Cloning ? I like seeing all the different products with different capabilities. This has not really hurt pricing competition

                                                                                          either as a lot of the competing SBCs' prices hover reasonably around the Raspberry Pi price and I recently bought a 1.6 GHz quad-core 1 GB Orange Pi PC for a little

                                                                                          less than 19 USD including shipping.

                                                                                           

                                                                                           

                                                                                          Ryan

                                                                                           

                                                                                          After over 40 years I've learned to live the fact that certain things in the electronics industry are just going to be proprietary. As long as I can get good tools at reasonable prices,

                                                                                          which has always been the biggest problem I've had with proprietary tool sets, I can live with it. The Vivado Design Suite is free which is a very good price ! I haven't had time

                                                                                          to check out the licensing restrictions yet (won't really need it until March 2016) but i assume this is for non-commercial designs which is what I want to do for now anyway. I

                                                                                          would like to see open tool sets that would remove such restrictions available, I just don't think it is going to happen for certain products which include FPGAs and GPUs.

                                                                                           

                                                                                           

                                                                                          P.S. 99% FUNDED !!!!!!  20:41 CDT. I think we're going to make it