Both XIlinx and Altera waste copious amount of time and resources creating tools to "help" FPGA system designers.  The issue, in my opinion, is that these tools only work well for quick toy-examples.  When trying to use the tool in an actual systems they just fall apart, in my experience.  

I spend considerable amounts of time hacking the block-diagram / system raw files (typically a XML file) to work around tool bugs and limitations.  It would be nice if I could just access clean, scalable, and modular HDL blocks.  They (the vendors) could spend their time and resources on usable documentation vs. an unusable tool (I am looking at you Vivado block-diagram thinga-ado-hicky).

I guess all this XML hacking will be transferable to some other use ...

Chris, 

I tend to agree I have a love hate relationship with the Vivado block diagram editor. A graphical top level can be very useful for creating the architecture, enabling modular design (if done right) and can ease understanding of the design intent. That being said you cannot actually do this with Vivado (the initial architecture), although it is a evolving product so I wonder where its road map will take it. 

I used to use HDL designer a lot from mentor at previous companies I always liked the way that worked, it allowed you to create a visual architecture very easily and it made modular design easy with its libraries structure. You could also use generics and generate loops if I remember correctly. 

It is an interesting point re use of version control tools and schematic editors, you can extract a TCL description of the block diagram in Vivado and store that within your VCS system. With HDL designer we used to just store the generated VHDL netlist from the tool. 

Adam 

@adamt99 (Adam),

I feel most at peace with the Sigasi point of view, the graphical displays are great for viewing the results and a means of debugging.  From my perspective it would be better to have a clean method to connect the "blocks" and access the attributes in source code (e.g. in tcl).  Then everything falls into place, version control, collaboration, scalability, programability, etc.  

It is an interesting point re use of version control tools and schematic editors, you can extract a TCL description of the block diagram in Vivado and store that within your VCS system. With HDL designer we used to just store the generated VHDL netlist from the tool.

I think the main entry source is what needs to be in version control along with the generated HDL (to CYA when a tool update breaks everything :)  Now we store the XML description (the .bd file) and that works great (sarcasm).  Trying to get others to reuse the BD I have put together not a fun task.

I think that it's the limitation of the tools that make it so troublesome. Bob Zeidman in his book "Introduction to Verilog" seems very much in favour of schematic editors.

Is that the same thing as the block-diagram tools you are referring to?

@SpiderKenny I am not familiar with Zeidman's book but it seems odd that any contemporary text book on HDL would think schematic entry is useful.  If one is not exploiting the modularity and levels of abstraction an HDL provides they are going to have a hard time competing. 

That doesn't mean you shouldn't completely comprehend the low-levels of digital circuits and understand the output of the tools but using schematic entry or block-diagram editors, even for top-level, ends up being laborious and inefficient, not to mention you can't leverage mature tools such as version control, documentation extraction, etc. (meaningless to compare schematic revisions).

At least that is my experience and I can't see schematic entry being useful.

Remember that Digital design consists of creating leaf level components and then configuring and interconnecting them into a design. Component designers do the former and never use schematic capture. Architects do the later and always use schematic capture.

Debugging always uses schematic viewers.

I agree that vendors shouldn't try to implement their own block editors because anything that they can offer for free will be little more than a toy. We need to create an opensourced EDA tool chain using tools like kactus2 and have everyone support that.

John Eaton

Viewers are great tools and can be very useful in analyzing and debugging.

http://www.slideshare.net/sigasi/graphical-program... 

Might be different strokes for different folks but I just do not see the utility of schematic / block entry.  For architecture, the tools are too specific not generic enough to define an architecture that can be generally used, I will stick to my paper and pencil for that :)

@jt_eaton 

>We need to create an opensourced EDA tool chain using tools like kactus2 and have everyone support that.

I would second that.

@cfelton IPI (Xilinx) is not mandatory to create a design. It is just another way to create a hardware design. It's been designed to integrate high-level blocks altogether to create a complete system. As a Xilinx employee I can see almost all my customers using it even for big design (if 75% of a KU115 is big for you). IPI does not replace paper and pen to think about the entire system with all interfaces, but the design realization part is accelerated.

I am a DSP expert not a hardware designer, I don't write VHDL even if I can read it, I create all my IPs using Vivado HLS or System Generator for DSP (Simulink blockset) and generate all my designs using IPI to test them on hardware. I think that this kind of tool allows people like me, not hardware expert, to create complex designs. It opens FPGA designs to a whole new set of potential customers.

My 2 cents...

@oliviert, thanks for the comments!  Correct, it is not required to use the block-diagram (BD) systems but if you want to use the IP (cores), “they” in many ways require the use of the BD tools.  I haven’t had much success using IP directly by instantiating it outside of the BDs.

IPI does not replace paper and pen to think about the entire system with all interfaces, but the design realization part is accelerated.

This is my source of my grumblings, the BDs sit in this nether region – it is no good for initial design, analysis, and/or architecture capture and it is no good for modularity and scalability.  The individual components are often modular (parameterizable) but the resulting system is not.  Example, if I have signal processing system and I have a range of products from low-end to high-end and I want to easily modify my design to have different ADC/DAC bit-widths and include 1-N channels.  With my complex system that I have developed I should be able to modify a couple top-level parameters and generate my gateware for my range of products and not waste my time managing multiple BD sources (not to mention source control and collaboration is hideous with BDs).

Best of my knowledge the BD systems do not support this very well.  I don’t have an equivalent generate statement in the BD to replicate channels based on a set of parameters.

This same problem occurs in DSP design and analysis world, personally I don’t ever use Simulink, the work I do is developing new algorithms and analysis.  Because of the same problems mentioned above, it (simulink) is not flexible enough.  If I were merely creating small examples or toy examples frequently it would work great but if I need to be efficient and competitive designing and maintaining new and innovative complex systems, simulink, BDs, etc. are not useful, in my opinion.

From my perspective, I have not heard enough pros to justify BDs, I am amazed at their proliferation.

@oliviert The existing landscape of HDL HLS is a misnomer :)  

Computer Science: "In low-level languages like C"
Computer Engineering: "In high-level languages like C"

— Stacey Mason (@stcymsn) March 16, 2015