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?

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.

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

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.

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

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