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?

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.

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.

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

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.

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. 

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

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.

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

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

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.