Snickerdoodle board on FLOSS Weekly

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?

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?

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.

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.

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.

"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.)

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

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

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.

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.

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.

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.

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.

<< 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.

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.

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

Clem