Actions
Forum Thread Details
  • Replies 40 replies
  • Subscribers 472 subscribers
  • Views 4940 views
  • Users 0 members are here
Related

Get Your Xilinx FPGA/Programmable SoC Questions Answered here

rscasny

In the past year or so, the element14 community has been offering quite a few programs, contests, and initatives around Xilinx's FPGA and heterogeneous SoC, ZYNQ. We have hosted webinars, run roadtests, and offered a training program last year called Path to Programmable.

 

I see element14 member interest in Xilinx product knowledge on the rise. I plan on offering more Xilinx-related projects and roadtests in the coming months. (Stay tuned to Path to Programmable 2 with the Ultra96v2) Given all this activity, I thought it would be a great idea to bring in a Xilinx product expert for some well needed Q&A time. So let me introduce you to Adam Taylor ( ).

 

I believe Adam has been an element14 member for several years. He is the Director of ADIUVO Engineering. He is a Chartered Engineer and Fellow of the Institute of Engineering and Technology. He is well known for his Microzed Chronicles. He writes the Exploring the Programmable World for element14. Adam has been instrumental in developing element14's FPGA/Programmable SoC Essentials.

 

Adam also is an expert in the PYNQ framework: Python for ZYNQ productivity. So, if you are asoftware developer who wants to explore the Programmable world, I'd encourage you to ask Adam your top questions.

 

So, if you have any questions revolving around FPGAs, programmable SoCs, a project in progress, perhaps even a question about Vivado, please click REPLY and asked them here.

 

Sincerely,

 

Randall Scasny

-element14 Team

Parents

  • - What trends do you see happening in the FPGA world in the upcoming years?

     

    - Do you see FPGAs moving into the realm of PC's? GPUs, even though they are completely different, have gained a lot of attention in the general computation arena, while at the same time FPGAs haven't apparently gained much more popularity. What do think is the cause of this?

     

    - Do you see any upcoming official opening of the bitstream formats? The formats appear to be slowly being reverse-engineered, whats is the rationale in keeping them closed? I would think that opening them would allow the creation of an ecosystem of 3rd party tools which probably would attract more users to the platform. Making software opensource could also lower development costs, etc. What are your thoughts on all this?

  • in reply to neuromodulator

      wrote:

     

    - Do you see any upcoming official opening of the bitstream formats? The formats appear to be slowly being reverse-engineered, whats is the rationale in keeping them closed? I would think that opening them would allow the creation of an ecosystem of 3rd party tools which probably would attract more users to the platform. Making software opensource could also lower development costs, etc. What are your thoughts on all this?

    I've been advocating for open bitstream formats for decades.  It's great that some are being reverse-engineered and I heartily congratulate the developers of IceStorm and related tools.

     

    I don't see FPGA vendors opening and documenting their bitstream formats.  They have various "official" reasons, none of which I find credible.  I've written about this a lot over the years at element14, for example in my article Taming the Wild Bitstream.  Here's an excerpt:

     

    The excuse most commonly heard from FPGA vendors is that they insist their customers want the bitstream format to be secret to prevent reverse-engineering customer designs. OK, that makes sense except for one thing: millions of μP/μC-based products are designed and sold each year using open CPU architectures, yet there is very little worry that someone is going to reverse-engineer those designs. IMO most FPGA designers would gladly have better tools in exchange for open bitstream formats.

     

    Most FPGAs are part of hardware/software systems, and unless the FPGA performs a trivial function, trying to understand what it does and how it interacts with the software is pretty nasty. Indeed, it’s hard enough to understand someone else’s FPGA even if you have commented VHDL/Verilog source code :-) The best you can do is to make an exact copy, which you can do now with the bitstream itself. Yet people rarely do, because you’re much better off designing better products with better features than copying your competitor’s last-generation products and trying to modify them enough so that you’re not blatently violating copyright.

    I also make the claim in my article that closed bitstreams have held back FPGAs since their inception and have prevented FPGAs from having the huge success of microprocessors and microcontrollers.  Where would microprocessors be today if Intel had kept its instruction set secret and insisted that everyone program in PL/M?

Reply
  • in reply to neuromodulator

      wrote:

     

    - Do you see any upcoming official opening of the bitstream formats? The formats appear to be slowly being reverse-engineered, whats is the rationale in keeping them closed? I would think that opening them would allow the creation of an ecosystem of 3rd party tools which probably would attract more users to the platform. Making software opensource could also lower development costs, etc. What are your thoughts on all this?

    I've been advocating for open bitstream formats for decades.  It's great that some are being reverse-engineered and I heartily congratulate the developers of IceStorm and related tools.

     

    I don't see FPGA vendors opening and documenting their bitstream formats.  They have various "official" reasons, none of which I find credible.  I've written about this a lot over the years at element14, for example in my article Taming the Wild Bitstream.  Here's an excerpt:

     

    The excuse most commonly heard from FPGA vendors is that they insist their customers want the bitstream format to be secret to prevent reverse-engineering customer designs. OK, that makes sense except for one thing: millions of μP/μC-based products are designed and sold each year using open CPU architectures, yet there is very little worry that someone is going to reverse-engineer those designs. IMO most FPGA designers would gladly have better tools in exchange for open bitstream formats.

     

    Most FPGAs are part of hardware/software systems, and unless the FPGA performs a trivial function, trying to understand what it does and how it interacts with the software is pretty nasty. Indeed, it’s hard enough to understand someone else’s FPGA even if you have commented VHDL/Verilog source code :-) The best you can do is to make an exact copy, which you can do now with the bitstream itself. Yet people rarely do, because you’re much better off designing better products with better features than copying your competitor’s last-generation products and trying to modify them enough so that you’re not blatently violating copyright.

    I also make the claim in my article that closed bitstreams have held back FPGAs since their inception and have prevented FPGAs from having the huge success of microprocessors and microcontrollers.  Where would microprocessors be today if Intel had kept its instruction set secret and insisted that everyone program in PL/M?

Children
No Data