Do IPI designs require a processor such as MicroBlaze or other?

[tnkumar]

https://digilent.com/reference/vivado/getting-started-with-ipi/2018.2 

Can we do IPI designs without a processor and just using FPGA logic? I like the concept of dragging blocks and connecting to switches and LEDs, but do not want AXI for programming with a processor

[zygot]

Yes. Yes, for ZYNQ devices as well. No hard processor, no soft processor necessary.

As your designs get more complicated you will find it a lot easier to ditch the "training wheels" and just create all HDL designs. There are other reasons to ditch the board design flow too. To name one, some Xilinx IP instantiated in the board design flow has fewer options and design choices than when they are created as standalone HDL IP cores. I could go on but you should do what is comfortable... until it's not. Just saying, there's a great big world out there outside the garden walls.... Inside the enclosure, Xilinx takes care of the details for you... up to a point, anyway. Outside the garden you are responsible for the details. More works means more control over what you want to accomplish.

For anyone thinking that the HDL design is too hard, consider that the a lot of the free IP ends up as HDL source code that you can read and learn from.

Edited December 5, 2021 by zygot

[tnkumar]

3 hours ago, zygot said:

Yes. Yes, for ZYNQ devices as well. No hard processor, no soft processor necessary.

As your designs get more complicated you will find it a lot easier to ditch the "training wheels" and just create all HDL designs. There are other reasons to ditch the board design flow too. To name one, some Xilinx IP instantiated in the board design flow has fewer options and design choices than when they are created as standalone HDL IP cores. I could go on but you should do what is comfortable... until it's not. Just saying, there's a great big world out there outside the garden walls.... Inside the enclosure, Xilinx takes care of the details for you... up to a point, anyway. Outside the garden you are responsible for the details. More works means more control over what you want to accomplish.

For anyone thinking that the HDL design is too hard, consider that the a lot of the free IP ends up as HDL source code that you can read and learn from.

Thanks @zygot- When doing IPI based designs, how do I connect switches from the board to inputs of the logic and outputs to LEDs (without a soft processor such as Microblaze, so no AXI)?

[zygot]

Well, the first line of my reply was a direct answer to your question. Perhaps you failed to notice that, while I mentioned that you could use the drag and drop board design flow, I gave some pretty strong hints that perhaps you shouldn't.

Except for ZYNQ designs that include a ZYNQ subsystem block, I've never used the board design flow. My answer is based on vendor demo projects that I've seen that proves my point that it's possible, sans processor. That doesn't mean that AXI is never involved. There are, as I've mentioned IP that, if put into a board design, will force you to use and AXI interface. In this case you will be trusting the tools to work out all of the AXI details for you.

There's a wide range of board design IP blocks available that cover a lot of logic structures that could be done in HDL text format. A large number doesn't mean sufficient to do anything that you want to do.

When you say, FPGA logic, what exactly are you thinking about? If it's in the IP catalog, then, with some effort, you can build a board design without writing one HDL source file. I can't think of anything that I'd want to do that way.

Whether you use the board file design flow or the HDL design flow you still have to assign pin constraints, like location, IOSTANDARD, and such. If your project setting specifies a device, then you will have to make your own constraint file. If your project setting specifies a board, then the tools will take care of at least the pin locations for you, as well as default IOSTANDARD (most of the time). If you want a different IOSTANDARD or want to set slew, or output current, then you'll have to use the tools to do that. I much prefer writing HDL source code and constraints myself. I can control these and keep track of them as I see fit. But, my way isn't the only way to do things.

If you have some logic that is in a Verilog or VHDL source file and you want to connect the board design to your HDL, this is possible too. In fact, all of my ZYNQ designs are done this way. The board design has the ZYNQ subsystem block and any AXI IP that I don't want to write for myself. I have Vivado create a wrapper, that I instantiate into my own toplevel source file, or use as a template to instantiate the board_design.v that is created when you generate the board design. All of the signals that go to pins are made external in the board design. The HDL toplevel then has these on the entity port. My constraints file then includes all of the pin and timing constraints. The board design then is just one of many source files in the overall design. I should mention that any ports on a IPI block that you can connect a wire to can be made external and connected to your own HDL code.

While I can give you a correct answer to your question, I can't offer assistance or a tutorial on a design flow that I never use, or strongly discourage. Perhaps, you'll get replies to your question from someone who loves the board design approach for real world projects. Like training wheels on a bicycle, there's a time when they are helpful, then there's the rest of the time where they just interfere with letting you do what you want to do on your bike. I get the attraction of GUI drag and drop design. I also get the limitations and frustrations, especially when you want to implement an old design in newer tools and something goes wrong.

There's a larger issue with the board design. Vivado can't write testbenches for custom designs. In my world every source file has it's own testbench. Vivado just isn't designed to accomodate professional FPGA development in terms of simulation.

Edited December 5, 2021 by zygot

[tnkumar]

1 hour ago, zygot said:

Well, the first line of my reply was a direct answer to your question. Perhaps you failed to notice that, while I mentioned that you could use the drag and drop board design flow, I gave some pretty strong hints that perhaps you shouldn't.

Except for ZYNQ designs that include a ZYNQ subsystem block, I've never used the board design flow. My answer is based on vendor demo projects that I've seen that proves my point that it's possible, sans processor. That doesn't mean that AXI is never involved. There are, as I've mentioned IP that, if put into a board design, will force you to use and AXI interface. In this case you will be trusting the tools to work out all of the AXI details for you.

There's a wide range of board design IP blocks available that cover a lot of logic structures that could be done in HDL text format. A large number doesn't mean sufficient to do anything that you want to do.

When you say, FPGA logic, what exactly are you thinking about? If it's in the IP catalog, then, with some effort, you can build a board design without writing one HDL source file. I can't think of anything that I'd want to do that way.

Whether you use the board file design flow or the HDL design flow you still have to assign pin constraints, like location, IOSTANDARD, and such. If your project setting specifies a device, then you will have to make your own constraint file. If your project setting specifies a board, then the tools will take care of at least the pin locations for you, as well as default IOSTANDARD (most of the time). If you want a different IOSTANDARD or want to set slew, or output current, then you'll have to use the tools to do that. I much prefer writing HDL source code and constraints myself. I can control these and keep track of them as I see fit. But, my way isn't the only way to do things.

If you have some logic that is in a Verilog or VHDL source file and you want to connect the board design to your HDL, this is possible too. In fact, all of my ZYNQ designs are done this way. The board design has the ZYNQ subsystem block and any AXI IP that I don't want to write for myself. I have Vivado create a wrapper, that I instantiate into my own toplevel source file, or use as a template to instantiate the board_design.v that is created when you generate the board design. All of the signals that go to pins are made external in the board design. The HDL toplevel then has these on the entity port. My constraints file then includes all of the pin and timing constraints. The board design then is just one of many source files in the overall design. I should mention that any ports on a IPI block that you can connect a wire to can be made external and connected to your own HDL code.

While I can give you a correct answer to your question, I can't offer assistance or a tutorial on a design flow that I never use, or strongly discourage. Perhaps, you'll get replies to your question from someone who loves the board design approach for real world projects. Like training wheels on a bicycle, there's a time when they are helpful, then there's the rest of the time where they just interfere with letting you do what you want to do on your bike. I get the attraction of GUI drag and drop design. I also get the limitations and frustrations, especially when you want to implement an old design in newer tools and something goes wrong.

There's a larger issue with the board design. Vivado can't write testbenches for custom designs. In my world every source file has it's own testbench. Vivado just isn't designed to accomodate professional FPGA development in terms of simulation.

Thanks @zygot for your detailed response. I will check with Verilog code, without IP blocks 

[tnkumar]

On 12/5/2021 at 6:52 PM, tnkumar said:

Thanks @zygot for your detailed response. I will check with Verilog code, without IP blocks 

I progressed with IPI and got it working @zygot - But I will keep your shared perspectives in mind

[asmi]

On 12/5/2021 at 6:25 PM, zygot said:

There's a larger issue with the board design. Vivado can't write testbenches for custom designs. In my world every source file has it's own testbench. Vivado just isn't designed to accomodate professional FPGA development in terms of simulation.

?‍♂️ Of course you can. You can create however many testbenches you want in a single project, and each one can have it's own configuration, or you can have multiple simulation settings for the same testbench. More information is here:

https://www.xilinx.com/video/hardware/using-vivado-logic-simulator-for-multiple-sim-sets.html

You can also integrate your own HDL modules right into IPI diagram, and you don't have to use AXI bus for that - through that bus obviously greatly expands your connectivity options. I use this approach all the time because you don't have to mess around with connecting wires manually. The only limitation is that current SystemVerilog modules can not be added, so you will have to write a Verilog wrapper for any SV code you might have in order to add them into IPI diagram.

Also you can create multiple diagrams within the same project - either for reusing common sub-blocks (though you can create logical sub-blocks within single diagram too), or - how I use it most often - for simulating my own HDL modules which have AXI bus interface, as AXI Verification IP allows you to check AXI compliance and easily simulate whatever AXI transaction you need, or it can simulate a memory which is "visible" to the simulation testbench such that you can inject some predefined data if that what you need (this is handy if you work on a module which need to have some sort of DMA capability). These additional diagrams can be used for simulation only, or for both simulation and actual hardware design.

So, yeah, this is what professional do - they learn their tools instead of blaming them. Only amateurs blame their tools.

[tnkumar]

15 hours ago, asmi said:

?‍♂️ Of course you can. You can create however many testbenches you want in a single project, and each one can have it's own configuration, or you can have multiple simulation settings for the same testbench. More information is here:

https://www.xilinx.com/video/hardware/using-vivado-logic-simulator-for-multiple-sim-sets.html

You can also integrate your own HDL modules right into IPI diagram, and you don't have to use AXI bus for that - through that bus obviously greatly expands your connectivity options. I use this approach all the time because you don't have to mess around with connecting wires manually. The only limitation is that current SystemVerilog modules can not be added, so you will have to write a Verilog wrapper for any SV code you might have in order to add them into IPI diagram.

Also you can create multiple diagrams within the same project - either for reusing common sub-blocks (though you can create logical sub-blocks within single diagram too), or - how I use it most often - for simulating my own HDL modules which have AXI bus interface, as AXI Verification IP allows you to check AXI compliance and easily simulate whatever AXI transaction you need, or it can simulate a memory which is "visible" to the simulation testbench such that you can inject some predefined data if that what you need (this is handy if you work on a module which need to have some sort of DMA capability). These additional diagrams can be used for simulation only, or for both simulation and actual hardware design.

So, yeah, this is what professional do - they learn their tools instead of blaming them. Only amateurs blame their tools.

Thanks @asmi for sharing the details about simulation sets. Very useful. Can you point to where I can learn more about AXI?

[zygot]

@asmi

I'm quite OK with you keeping me honest... you seem so enjoy it so much; even when you don't catch a misstatement at least others get as alternate view. Don't stop doing it. Many perspectives are better than one. Always. And, of course I'm not immune from making incorrect statements.

But, at least take me to task with things that I've written. I wrote that Vivado doesn't create testbenches for users' designs, not that users' can write testbenches. Personally, I've never seen a testbench provided for a board design, but that doesn't mean that no one does it. The GUI drag and drop design flows offered by Intel and Xilinx just don't promote good practices in my opinion, and because it's compelling I see it as a trap for inexperienced users. I've worked for  lot of companies as a contractor or employee and never came across any source code that created a board design, or any project involving one.

As to the professional comment; that was poor choice of words on my part. I never said that you couldn't add multiple testbenches to Vivado. I personally don't find that Vivado makes it easy to support design and verification the way that I prefer to do it. That's why I still use the free version of ModeSim provided with Quartus for logic designs that don't have vendor specific primitives, regardless of the tool or device that I'm using. Not that ModelSim doesn't have it's issues. But ModelSim doesn't crash and burn the way that Vivado has done for me on quite a few occasions and isn't buggy. But if anyone is happy with what they are doing, I'm happy for them. Nonetheless, I still encourage those starting out with FPGA development to stick with the HDL design and verification flow.

Edited December 11, 2021 by zygot

[zygot]

5 hours ago, tnkumar said:

Can you point to where I can learn more about AXI?

Xilinx Document Navigator. Use it.

It used to be a lot easier to find technical information and application notes from Altera and Xilinx but this tool installed with Vivado is the best way to browse what's available from Xilinx. Lately, I've found it difficult to even use DocNav as most of the time I have to be logged into my Xilinx user account to access information. For some reason DocNav on Centos has been crashing after downloading one document. The cookie wars between those monetizing the internet and those trying to protect user security seems to be getting out of hand these days.

You can also find information about various industry standard busses from ARM.

Digilent and other vendors like ADI have IP repositories in Github that include a some AXI HDL examples. @D@nhas some useful insights here: https://zipcpu.com/

If you are going to use ARM based FPGA devices effectively then you need to learn how the AXI or AMBA busses that connect the ARM cores to the logic work. Not everyone owning a ZYNQ based platform posting to the Digilent Forums want to be bothered, or has the time, or has the skill needed to design interfaces to these busses. That's the only reason why I'd suggest using alternate means.

A good place to start would be UG761_axi_reference_guide.pdf available from DocNav.

Beware that there are subtleties about the use of AXI for ARM based FPGA devices that aren't immediately obvious. Debugging ZYNQ software that encounters AXI buss faults as a result of poor or incomplete AXI-logic interfaces is difficult. Since ZYNQ devices use ARM cores I'd suggest referring to the ARM documentation. I've written AXI IP but don't use it enough to consider myself an expert. Even Xilinx has issues with it according to a few sources. 

 

Edited December 11, 2021 by zygot

[tnkumar]

7 hours ago, zygot said:

Xilinx Document Navigator. Use it.

It used to be a lot easier to find technical information and application notes from Altera and Xilinx but this tool installed with Vivado is the best way to browse what's available from Xilinx. Lately, I've found it difficult to even use DocNav as most of the time I have to be logged into my Xilinx user account to access information. For some reason DocNav on Centos has been crashing after downloading one document. The cookie wars between those monetizing the internet and those trying to protect user security seems to be getting out of hand these days.

You can also find information about various industry standard busses from ARM.

Digilent and other vendors like ADI have IP repositories in Github that include a some AXI HDL examples. @D@nhas some useful insights here: https://zipcpu.com/

If you are going to use ARM based FPGA devices effectively then you need to learn how the AXI or AMBA busses that connect the ARM cores to the logic work. Not everyone owning a ZYNQ based platform posting to the Digilent Forums want to be bothered, or has the time, or has the skill needed to design interfaces to these busses. That's the only reason why I'd suggest using alternate means.

A good place to start would be UG761_axi_reference_guide.pdf available from DocNav.

Beware that there are subtleties about the use of AXI for ARM based FPGA devices that aren't immediately obvious. Debugging ZYNQ software that encounters AXI buss faults as a result of poor or incomplete AXI-logic interfaces is difficult. Since ZYNQ devices use ARM cores I'd suggest referring to the ARM ydocumentation. I've written AXI IP but don't use it enough to consider myself an expert. Even Xilinx has issues with it according to a few sources. 

 

Thanks @zygot for the pointers. I will check it out. I am using MicroBlaze on Arty S7-50

[D@n]

@tnkumar,

I think if I were going to learn AXI, (once I'd gotten past the reference guides), I'd start with learning about skidbuffers.  I know of no other way to meet AXI's requirements, and maintain 100% throughput, than to use some skidbuffers.  (Often times you can cheat, and skip the skidbuffer, but the result--while it might work--isn't AXI compliant.)

Once you know what a skidbuffer is and how to use it, I'd then move on to AXI lite.  Here's my favorite, documented, AXI-lite example.  I use it for everything as my starting point.  (Don't use Xilinx's example design--it's broken.  It'll work for a while, enough to give you the confidence to believe it works, and then it'll suddenly fail on you when you are not expecting it.  This'll leave you looking all over your design for the bug and ... in all the wrong places.)

If you really want to learn AXI in its full glory, then you'll need to understand AXI addressing.  It's ... not simple.  I have a routine I've highly optimized for this purpose that really helps me unwrap bursts.  Once you can unwrap burst addressing, all that's left is to count beats in a burst, and make sure that the AXI ID returned matches the AXI ID requested.

If after all of this you still want more, then consider this discussion on converting an AXI-lite bus master to an AXI bus master.  The big difference between the two, in this application, is the exclusive access.  Beware, however ... Xilinx's IP doesn't support exclusive access.  Microblaze doesn't use it.  The MIG doesn't support it.  etc.  If you need something that'll use exclusive access, then you might need an example slave to work from that supports it.  For most users, though, exclusive access isn't a requirement and the capability can be safely ignored.

Dan

[zygot]

What @D@ncovers is (somewhat) Series7 specific. If you get bored because you've mastered all of the intricacies of AXI then you can purchase an UltraScale+ MPSoC and take on ACP and ACE PS-PL interfaces. Worry about cache coherency and snoop control units too. It'll never stop. A lot has changed with those devices verses the Series7 devices.. something that I'm working on now.

Personally, I'd advise someone with a plain FPGA platform  like the Arty A-whatever or Arty 7-whatever to put off AXI and soft processors and just concentrate on developing your logic development chops. Of course if all depends on what goals you want to accomplish. I believe that it's pretty easy to jump into endeavors that are beyond one's skill level. There are a lot of facets and levels to this programmable logic design stuff.

Edited December 12, 2021 by zygot