How to add own logic to Arty board flow?

[Paul_kimelman]

The Arty board examples and tutorials use the Vidado drag and drop editor. But, there is no example how one would add their own custom logic. I have hacked this so far by dropping a peripheral and then replacing the stub verilog file, but it would help to show how this should be done. The natural would be to drop in a custom bus i/f file (e.g. using the AXI to AHB or AXI to APB bridge to a stub) and also how you add pins to the port list. Hacking away at it seems just wrong - if there is some intended flow, it is not apparent. The old way of editing the .ucf file and adding the ports to the top file does not seem like a fit for this SDK/Microblaze environment. 

Thanks, Paul

[asmi]

I don't understand why would I not want to use AXI in my designs because it's very convenient, but if so - you may want to take a look at their Microblaze MCS IP to see if it will fit your needs. It is AXI-less so to speak too. It can be configured with simple handshake-based IO bus which is memory-mapped into MCU's address space, or you can use GPIO to interface with your modules. You can forego the use of designer and directly instantiate it in your HDL code too  Give it a go.

[D@n]

@asmi, @Paul_kimelman,

So ... I've been thinking about this problem from a different standpoint, and perhaps a different viewpoint might be valuable ... perhaps not, but I won't know unless I speak up.  Here was my thought: after now having built designs several times over, the various components within a design generally fall into a couple categories. 

Top level: Every component tends to have some top level ports, and port declarations, which then get passed to a second module holding the non-vendor specific stuff.  Some cores require vendor specific logic, and these require variable declarations to be at the top of the file, and logic somewhere past the variable declarations.

The vendor independent module(main): Most components within a design then need to be placed within a main module.  These would also need access to their external I/O ports, a place to declare their variables before they are used (and possibly referenced by other cores), and a place for their logic to sit.

This main level might also contain any bus interconnect, since components tend to want to be placed on a bus for access by a local processor.  Something is needed, then, to 1) allocate addresses, 2) allocate interrupts to interrupt controllers, 3) handle the bus decode logic for the various peripherals, etc.  Further, as addresses are allocated, some .h/.c/.cpp files need to be written so that the processor can know 1) what components are connected to the system, 2) what peripheral addresses have been given to each, and 3) what interrupts have been assigned to each of them.

The end result should also remain something that is human readable Verilog.

This has been my current approach for building a design for the Nexys-Video.  I have put together a set of core definition files, each containing snippets of Verilog code that would be cut and pasted where needed.  These are then used to create a top level design, and even a vendor-independent main module containing any bus interactions.  So far, it is only working for this one processor, although it could easily be ported to others.

It's not done, but my goal was to make it so that the end result would be entirely in Verilog, and so could be evaluated and debugged as such.  Indeed, I'd also like to get it to where it supports multiple busses (AXI ?, WBv3, WBv4/pipelined, etc), and even bus hierarchies, but ... it's still a work in progress, and not nearly as pretty as Xilinx's tool flow.

It's a thought.  Perhaps it's closer to what you are looking for, since it leaves you with all the Verilog code that you can then investigate on your own as you see fit.

Dan

P.S.  The license is intended to apply only to the code within, not the code of yours that you might apply it to.  (Like GCC)

[asmi]

@D@n With all due respect, I think Microblaze ICS would be a much better fit for his needs as this MCU is also supported by Xilinx SDK toolchain, so writing/compiling/debugging code for it would be just as easy as for "full-blown" Microblaze (or Zynq ARM for that matter). MCU is as much about hardware as it is about software, and just about all hand-made MCU cores I've come across have no toolchain to develop code for it. Me being a software developer, having a good toolchain this is a biiig thing  Sorry, but writing assembly code in year 2017 is a no-go, and I know if from my own experience since asm projects tend to become an unmanageable mess of "write-only" code way too quickly.

[asmi]

Also many people don't seem to realize that many Xilinx IP cores can be generated and used outside of "designer" as simple HDL modules with no AXI intefaces. You just need to invoke the wizard from "IP Catalog" button as opposed to from within a diagram. For example if you want to use MIG to create DDR3 memory controller but for some reason don't want to use AXI - you can do just that! Since Microblaze MCS IP exposes memory-mapped IO bus, if you're THAT persistent, you can even implement some kind of "glue" module to connect non-AXI DDR3 controller to that MCU as well!  Or you can implement any other bus you want - the actual IO bus protocol is simple enough to be bridged to just about anything:

output IO_addr_strobe;
output [31:0]IO_address;
output [3:0]IO_byte_enable;
input [31:0]IO_read_data;
output IO_read_strobe;
input IO_ready;
output [31:0]IO_write_data;
output IO_write_strobe;

 

[D@n]

@asmi,

Understood regarding the toolchain.  Unlike many hobbiest built CPU's, the ZipCPU has GCC, binutils, and most recently newlib (C library) support.  Admittedly, it does not (yet) have floating point support, neither does it have anything more than a rudimentary O/S ... yet.  I do foresee Linux running on it by the end of the year.  Granted, it's not there yet.  But if all you want is a simple micro-controller (which is what the ZipCPU was designed for), then you have the basic toolchain support.

I have some problems, though, with MicroBlaze that turn me off from it: Because it is a Xilinx IP black box, I can not examine nor test with it using such open tools as Verilator or Gtkwave.  Whereas, I can test and run the ZipCPU with no hardware on my desk other than my desktop computer.  I can verify that the ZipCPU's interfaces and peripherals (flash, uart, I2C, ethernet, and others, most recently an OLEDrgb, and soon to be HDMI) work before I even purchase the FPGA or the peripherals that will be on it.  I can create programs that then interact with the simulation as though they were interacting with the actual FPGA, and set it up so that those programs cannot tell whether or not they are working with the real FPGA or not.  Even more, I can build scope's that exist both within my FPGA simulation and even within my FPGA allowing me to debug my own cores or even someone else's proprietary IP.  Further, because of Verilator's structure (it doesn't support x or z bits, only 1 or 0), I can get about 300k clock cycles per second out of a simulation.  Can you do that with Xilinx's simulator?

Tell me, could I do all of that with MicroBlaze?  Or would I be constrained to run within Xilinx's proprietary test setup, unable to examine the inner workings of why one thing happened versus something else?

Dan

[asmi]

3 minutes ago, D@n said:

@asmi,

Tell me, could I do all of that with MicroBlaze?  Or would I be constrained to run within Xilinx's proprietary test setup, unable to examine the inner workings of why one thing happened versus something else?

Dan

Well, here you go, I knew this was coming. Here is my position on all that - I'm just fine with "Xilinx's proprietary test setup" (I wonder how can you even use their ICs as their are also proprietary ASICs with no source code in sight), I don't need to "verilate" anything as I already have a board. I do, however, have a professional hate for GPL license so I always steer clear from anything that use it - even (or maybe especially so) in hobby projects. For me this is a very clear-cut concept - if I want to publish my code (however small of big it is), I do so under MIT-like license, if I want to get any money for it - I don't publish it at all.

And yes - I'm just fine with AXI bus and "full" Microblaze IP, in this topic I'm just trying to help out a person who for some reason doesn't want to use it in his designs. That's all there's to it - I don't mean to offend anyone or anything like that, so if it did came across too hard - I'm sorry.

[Paul_kimelman]

Hi guys. Asmi, I am unaware of this MicroBlaze MCS. I assume it exists for Artix7. Is there an example app with it. I find starting from an example is simplest as I can just modify what I need. For what I need, I do not care about licensing or any such since I am only using this processor core for simple demo uses and the like. 

I am very interested in that I keep finding more and more bugs with the Xilinx designer flow. The latest, which wasted hours was that I had my sources where I wanted them and the packager kept messing up over and over (suddenly deciding the file is missing, losing info it had from before, making a port re-appear that does not exist, giving a warning on a port long gone, etc). They obviously have never heard of source control and so they think copying files is appropriate, which I find ridiculous (especially as it is not like they are checking if the original file changed). I also found that when I deleted some ports from the source file, it just will not make them go away from the packager which makes it painful. I will have to start over and their automatic scheme is very messed up (does not recognize buses it knows even when I have the exact same names, thinks scan_no_rst is a reset signal and scan_single_clk is a clock, but not recognizing PCLK as a clock). I do not know how people use this who are not doing only FPGA development. It is quite shocking. ISE was not super advanced but it worked very well. Sigh.

[Paul_kimelman]

D@n, I will note that you need to consider who the users of these boards and devices are. I am not at all clear whether they want a source based core. I agree with your view of building things in the traditional ASIC model of a top.v and then instantiated components as sub-systems around the core system(s). IOs then route out through an IO Mux or direct. But, obviously Xilinx has another use model in mind that maybe is a good fit for hobbyists. The drag/drop style is easier for a SW developer and maybe all of the limitations and craziness of their packaging scheme is OK for people. On the other hand, Vivado in general has always felt like a released alpha version - very shaky and constantly changing. 

[D@n]

@Paul_kimelman,

You bring up a very good point, that of the need to consider who the users of these boards and devices are, and one .... I'm not sure I know the answer either.

I can't speak all that well for the Xilinx customer base at large.  I don't know it.  Here on these forums, there are hobbyists, students, teachers, and sometimes even the more professional engineers.  You can tell them apart somewhat by the types of questions they ask.  Beginning students are asking to learn how to build the wheel again.  More advanced students seem to be focused mostly on video processing.  (Why not networking?  I don't know)  Teachers are looking for lesson plans and how to maintain a fleet of FPGA devices. The professional engineers tend to ask for the details of how the board configuration works, since they want to build their own and Digilent hasn't released all of the details.  I haven't noticed the ASIC designers so much, but that might just be because they hide so well within the other groups.

The beginning students all want a source based approach.  They are trying to build blinky, or a serial port.  The Xilinx tool flow is more work than they need.  The more advanced students that write in are struggling with the tool flow.  They've advanced from blinky, and ... are struggling with the transition.  Usually the Xilinx IP is doing something they can't understand, and they are completely stuck trying to figure out why.  Others of these advanced students want to do some seriously complex processing, and ... they are struggling with the same thing you are writing about--how to do integrate something custom into the Xilinx IP.  These are the folks who most often receive my recommendations and advice for open source.  The instructors, to the extent that I can tell them from the other users, tend to be focused on keeping their hardware working--although there has been the occasional instructor looking for lesson material.  As for the hobbyist?  They are all over the map.  Unlike the students, most of the hobbyists tend not to have the good guidance of an instructor--so they write in from that perspective.

Are they interested in an open source tool chain?  Well, I'll be honest: that point and click tool chain looks awfully simple until you try and do something you aren't quite as familiar with, and then wonder why it isn't working.  Then they write in asking for someone to debug their code 'cause they can't figure out what's going on, and don't even know where to start.  Hence, this is a very common request.  The answer they need to hear is how to use the engineering process, to break the problem into components, to debug each component individually and prove that they first work before trying to integrate them into a larger design.  The answer they receive is usually a kind forum engineer showing them what they are missing, but not how to find the problem themselves.  Is this the right approach for the student or the hobbyist?  That's a good question.  Again, I'm not sure I know the answer to it.

Transitioning a little ...  You mentioned RISC-V earlier.  RISC-V was developed from the ground up with ASIC boards in mind.  FPGA's are somewhat of an afterthought for that group.  There are three basic RISC-V cores I know of: a picoRV core for the really small hardware sets (not pipelined), a pipelined "rocket" RV core which is roughly comparable to the ZipCPU in logic count and methodology, and the BoomCPU--a much faster but out of order core taking up about 160k LUTs.  Further, the Berkley  cores are all written in Chisel, not VHDL nor Verilog.  I'm not sure what tool they use for integrating logic together into their designs, but they tend to have fewer designs (from my perspective) as their focus is on ASIC chips.  I'm also not certain how many of these designs match their "privilege" specification, since that was just recently released.

There's also the OpenRISC set of cores.  While an OpenRISC ASIC has been made, I think most of the OpenRISC focus has been on FPGA's.  They have a fascinating model of distributing IP through a python program called FuseSOC.  Just Google orpsoc-cores, and you'll discover a lot of the IP that works with their models, together with several "systems" that have been built up using these various cores.  The FuseSOC system allows them to merge multiple repositories under one system core. 

What OpenRISC doesn't yet have, though, is a method of just specifying a list of component cores which are then placed into a system bus design automagically.  They have a decent interconnect, from what I've seen, but you still have to build a design or two for that interconnect to be on.  The system bus'es tend to be hand built, one system at a time, and so they are somewhat limited in the number of systems they have.  Further, those prebuilt systems also tend to be more Altera focused than Xilinx focused, in as much as more of their prebuilt systems are for the Altera boards than for the couple of the older Xilinx boards on the list.

The other thing about the OpenRISC set of designs is that they tend to focus on the Wishbone, not the AXI, bus.  While the OpenRISC community has a bridge that can be used, it will drop your memory bandwidth by 20x or more since it only allows one transaction to be in flight at a time.  (AXI has about a 200ns latency.  The ZipCPU based WB bridge maintains the bandwidth ...)  Part of the problem is that they tend to work with the WB B3 "classic" specification, which only allows one bus transfer to be in flight at a time.  The B4 spec allows transfers to be pipelined, so many can be in flight at the same time.  Both wishbone spec's, however, are very different from the AXI bus which maintains five adjustable rate information pipelines associated with it together with all the logic that requires.  (WB B4 "pipeline" mode only requires one adjustable rate bus pipeline out, and one always ready return pipeline.)  From this standpoint, using a Xilinx core may end up costing you more of your precious LUTs than an open source core, since the Xilinx cores tend to offer the kitchen sink.

RISC-V and OpenRISC both run Linux.  OpenRISC also has gdb support, although I don't know about RISC-V.   (ZipCPU has neither gdb support, nor does it run Linux, although it does have an assembly level debugger.)  The fascinating thing I've learned, though, from many of the OpenRISC developers is that more folks are interested in bare-metal CPU implementations than they are in running Linux.  As a result, they are looking for simplicity.  They need the core, but they want the core to be simple enough that it doesn't get in the way.  There is a dedicated group, though, that wants Linux.

All of these open source designs run into trouble when they get to the DDR3 memory controller.  (Gosh, even the Xilinx designs tend to run into trouble there!)   Although open source DDR3 controllers exist, I have yet to find one that works on a Xilinx FPGA.

It seems like I've rambled a bit so ... pardon the long winded answer, but I thought you might find a short "market survey" of open source IP "products" valuable.  Also ... forgive me for not linking any of the above, it's late here.  Feel free to ask me for references to any of the above if you would like.

Dan

[asmi]

3 hours ago, Paul_kimelman said:

I am very interested in that I keep finding more and more bugs with the Xilinx designer flow. The latest, which wasted hours was that I had my sources where I wanted them and the packager kept messing up over and over (suddenly deciding the file is missing, losing info it had from before, making a port re-appear that does not exist, giving a warning on a port long gone, etc). They obviously have never heard of source control and so they think copying files is appropriate, which I find ridiculous (especially as it is not like they are checking if the original file changed). I also found that when I deleted some ports from the source file, it just will not make them go away from the packager which makes it painful. I will have to start over and their automatic scheme is very messed up (does not recognize buses it knows even when I have the exact same names, thinks scan_no_rst is a reset signal and scan_single_clk is a clock, but not recognizing PCLK as a clock). I do not know how people use this who are not doing only FPGA development. It is quite shocking. ISE was not super advanced but it worked very well. Sigh.

Every time I get into something like that I always ask myself these questions - "Am I doing something wrong? Is it worth continue fighting the system instead of learning to adapt to it?"

3 hours ago, Paul_kimelman said:

Hi guys. Asmi, I am unaware of this MicroBlaze MCS. I assume it exists for Artix7. Is there an example app with it. I find starting from an example is simplest as I can just modify what I need. For what I need, I do not care about licensing or any such since I am only using this processor core for simple demo uses and the like. 

I'm not aware of any, but it is so incredibly simple that I've created (and verified in hardware on Arty board!) a fully source-based design (yea, the one with TopModule.v as top module and no "block design magic" behind scenes) using Microblaze MCS - including a simple IO bus peripheral that controls onboard LEDs based on MCU's commands - in a little over than 2 hrs (and most of this time was me being dump - I forgot to connect LEDs port and was wondering why it wasn't working lol). If you want I can explain you what I did and post a source code (even though it's incredible simple - less than 100 lines of code in both modules total).

Even if a hobbyist could figure it all out in 2 hrs at 11pm Sunday night before his bedtime (and no, I didn't work with it before, I just read up on it a little few months ago when I was considering building my board with Spartan-6 on it), I'm sure for a pro it would be a piece of cake! Right? 

[Paul_kimelman]

9 hours ago, asmi said:

Every time I get into something like that I always ask myself these questions - "Am I doing something wrong? Is it worth continue fighting the system instead of learning to adapt to it?"

I have been using tools for a lot of years and I built tools for a lot of years (e.g. XRAY debugger for Microtec). I understand what you are saying. But, when a tool is so flaky that it is not a matter of adapting to it but just not doing what you need to because it is too fragile, that is a problem. It is like the only testing they did is on one very narrow use model and everything else is broken. If that is the case, why pretend that it can do anything else? Just say it can only do one thing and you must just follow that or it will fail badly. Instead it pretends to be able to handle real-world uses (beyond hobbyists) and it fails catastrophically.
For example, I do not think they ever tested their AXI to APB bridge after it was 1st developed since it seems very broken. I did it all their way and now I get tons of errors like the below. The problem is I have no idea what this is about. It is a black box (no sources for me to see) so I cannot even see what its problem is. If _1 implies the 2nd port, that would be bad because there is only 1 port defined (by config) so of course it is not connected and would be pruned. So, what options does that give? Your "adapt" is not to trust a single thing they provide? Only narrowly use what Diligent was able to make work? And then what?

  [Opt 31-67] Problem: A LUT3 cell in the design is missing a connection on input pin I2, which is used by the LUT equation. This pin has either been left unconnected in the design or the connection was removed due to the trimming of unused logic. The LUT cell name is: system_i/axi_apb_bridge_0/U0/APB_MASTER_IF_MODULE/PENABLE_i_i_1.

 

9 hours ago, asmi said:

I'm not aware of any, but it is so incredibly simple that I've created (and verified in hardware on Arty board!) a fully source-based design (yea, the one with TopModule.v as top module and no "block design magic" behind scenes) using Microblaze MCS - including a simple IO bus peripheral that controls onboard LEDs based on MCU's commands - in a little over than 2 hrs (and most of this time was me being dump - I forgot to connect LEDs port and was wondering why it wasn't working lol). If you want I can explain you what I did and post a source code (even though it's incredible simple - less than 100 lines of code in both modules total).

Even if a hobbyist could figure it all out in 2 hrs at 11pm Sunday night before his bedtime (and no, I didn't work with it before, I just read up on it a little few months ago when I was considering building my board with Spartan-6 on it), I'm sure for a pro it would be a piece of cake! Right? 

If the Microblaze MCS then allows use of the SDK to build the SW, of course I would be interested. I will try it then because I have given up on this designer thing. I have wasted a lot of time on trying to use their tool but it is just broken. I did not the only way to use it was to follow some narrow use to the letter (including not using their IP catalog to use their provided IP since it was too unreliable). This should have been a 2 hour job - anything I have done with ISE in the past has been 2 hours. Thanks, Paul