asmi

You don't have to connect them into multiprocessor system - for example you can use them to control different submodules, which may of may not interconnect with other parts of the system. And if you connect them to different pins, you can essentially have several independent MCUs inside a single package - can be handy if your system does not require many IO pins so that you can fit several of them into a single chip. Or you can use one MCU that is running on low frequency to gate clock (or hold in reset) to others and this way power them down to save power - useful for battery-powered systems. Or you can combine them into a sort of SIMD system. There is a lot of possibilities if approached creatively.

I would add that this MCS uses about 1k LUTs and 1k FFs, so you can add more cores - up to 4 (since there are only 4 JTAG debug registers available). You will have to create a separate core for each instance though as debug register needs to be redefined in each of them.

I work in software development, and in a lot of my contracts my job was to clean up after those "best" lazy engineers... Real best engineers don't know the meaning of word "lazy" because they know the price of error could be very high. Currently I work for one of major automakers building software for some of its' shop floor robots, and here mistake can cost lives and injuries of people, not to mention destroyed hardware. So I'd better take my time than go to jail... You can install them side-by-side, without deleting old version. At least that's the way it works in Windows. I like Artix-7 too, but it's a bit of an overkill for good portion of my projects, so I can't wait to get my hands on their brand new Spartan-7 chips. On the other side of the spectrum, I would like to get Arty-Z7 with Zynq, as one of my project involves computer vision and for that I need a lot more horsepower out of MCU than softcore (or even several of them on a single chip) can provide.

When it comes to pin naming, I've seen it both ways approximately equally often, so I wouldn't call either one "normal". Which is why I always read datasheets to find out the right way, and don't just hope that I can guess it right. There is more into linker script than memory. And the reason they can pick it up once is because that's the only time they can be sure they won't overwrite user edits.If I would be them, I'd ask user if he modified that script offering to overwrite it, but existing solution is quite sensible from "the principle of least surprise" standpoint. As for active-high reset - I don't know if that's the case with ASICs, but for FPGA IPs it's extremely rare to use any active-low signals internally. As a matter of fact, I can only recall one IP that has active-low input - and coincidentally this is IP to manage reset signals throughout the system. Actually it's the opposite - it's amateurs are people who want results "right here and right now". Real professionals know that they gotta read documentation before doing anything with component/part/library they've never worked before. And you've just kinda proved the point - if you would've spent 15 minutes skimming through datasheet, you wouldn't end up wasting so much time chasing ghosts. In my opinion, lazy people do not deserve to call themselves professional engineers. BTW - new version of Vivado (2017.1) has been released just today. You might want to get it installed to see if it more stable for you or not.

Sorry, I've lost you here. You are going to use UART but you don't know if you need to know a pinout of this port? The picture in the reference shows directions. Really? Every MCU linker I've ever seen defines MCU's memory layout in a linker script, begardless of platform. I worked with ARM Cortex M0,M0+, M3, M4 and M7, and all of them has the same ldscript file, and all environments have it in one way or another. That's where you typically go to make changes if your board have some external memory attached to MCU (via SMC, Q-SPI or some other way, but first two are most often). I can't really fault Xilinx here - Vivado is a professional tool, which implies that it's users have of some knowledge of the basics.

If you mean my tutorial - I actually have inverter for reset in my hdl code. Besides active-low reset is pretty much de-facto standard, I can't remember when I've seen a board that would have active-high reset. Same goes for UART signals - I even included comments specifying correct pin assignments, and a screenshot of all of them assigned. The real Digilent's problem is that some users can't be bothered to RTFM. Here's a picture from Arty's reference document: https://reference.digilentinc.com/reference/programmable-logic/arty/reference-manual You can't get any clearer than that. That isn't a bug, it is done like that on purpose, SDK even issues a warning to that effect, but who reads them, right?

I've posted detailed step-by-step instructions here: http://thingselectronic.blogspot.ca/2017/04/creating-vivado-project-with-microblaze.html Please let me know if you made it to work, or if you have any questions.

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'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?

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.

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 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.

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.

Hmmm I see what is the problem. I always work on components first, and only once complete & verified, integrate them into the main system. Because components use standard AXI bus, there is no need to debug the actual communications as if they both follow spec, it will just work. This is obviously the flow that Xilinx wants us to use, so I chose to adapt it in my design process (and I used similar flow before anyways, because debugging system with several half-implemented pieces is much harder as there are too many moving parts, and often it's not clear where the problem is). But what do I know - I'm just a hobbyist who loves building things just for the heck of it. I've studied this stuff in the university 10 years ago, but then went for a somewhat different career (software development) So maybe it's different in professional environment, but I use the same approach in my professional software development, so it seems very natural to me.

You can absolutely do that - there is a wizard that allows you to generate AXI-wrapper for whatever interface (or interfaces, as it's commonly the case). It's somewhat hidden (Tools -> Create or Package New IP, then pick "Create a new AXI peripheral" option, the rest is pretty self-explanatory). This will generate a separate Vivado project which you can customize to your heart's content, after that you wire your own modules to generated wrappers, package IP - and you're good to go! Here is the video which shows this flow and explains the steps (he does just what you want - creates an AXI-lite wrapper and wires his own custom module to it): As for the general approach - it seems that Xilinx's idea for how design process is set up is this: 1. Modules are developed much more rarely than they are used in designs. 2. Engineer who integrates modules into the system, and engineer who develops custom modules - are two separate persons. Hence separate Vivado projects for the module and the system, and the concept of "packages". A agree it's not very user-friendly, but once you understand the logic behind it it starts to make some sense. I was very apprehensive to it as well in the beginning, but than after realizing that Xilinx is the only FPGA vendor that gives so much IP cores for free, I took my time to learn it, and more or less learnt to love it Good luck with your designs!

You might want to check out this Youtube playlist: It talks mostly about Zynq, but all of concepts described are equally applicable for Microblaze-based systems.