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

[Paul_kimelman]

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.

I mean that you do not know that the board has the pin names backwards. The UART standard is to refer to TX and RX from  one's own position not from the other side. So, you do not know that the xdc file is backwards unless you find that drawing and realize the arrows are inverted from normal. 

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.

Actually, the common approach when they know the MCU and Board (e.g. Keil, IAR, NXP MCUXpresso, Greenhills, etc -- all professional tools) is to decouple the knowledge of the board/MCU from the linker script assignments. I would expect to define section allocations but not define the total memory in a user controlled script since that makes it non-portable. If you define the memory regions outside, then you can use it on any MCU that has enough memory since it will just place it for you. 
If they are picking up new info on the system, I would expect that warning to indicate that they pick up everything ***except*** the memory info which they only pick up exactly once apparently. It is common sense in my view.

I am not sure you argument: anything that makes it harder to use or more likely to go wrong is worth looking at how to make it better and less likely to go wrong. Your argument on reset is equally flawed. I agree that most of the world uses active low reset, so why doesn't the MBlaze use active low reset like everyone else? If they choose not to, then call it out in the instantiation template. I built professional tools for years and I was able to make it as easy to pick up and use as possible.

[Paul_kimelman]

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.

I was referring to the one Jon had pointed to at WPI. I am glad you got this right. The one from WPI just shows reset but makes no comment. It does talk about the UART thing but implies Diligent is consistent where it appears not (at least not with Arty). The real problem is knowing the actual direction. I believe xdc and ucf files should always indicate direction if not obvious and for LEDs if active Low (grounding the pin, power to LED) or High (sourcing the LED, which can cause problems with nearby pins when the rail drops due to current); likewise for reset.

The real Digilent's problem is that most of their users can't be bothered to RTFM. Here's a picture from Arty's reference document: https://reference.digilentinc.com/_detail/arty/arty_uart.png?id=reference%3Aprogrammable-logic%3Aarty%3Areference-manual You can't get any clearer than that.

Yes, but a drawing is not enough since you do not know you need it. It was only when I compared the drawing and the naming below and then realized the MicroBlaze uses the opposite meaning (TX is from the FPGA to the PC). It is odd that that drawing uses the PC's view of TX and RX vs. the boards, since it is a board spec. The UART concept is from the side you are on - you are designing for a board, not for FTDI, so it is backwards in my view. If the xdc file had the bolded comment adder below, this would have been fine.

set_property -dict { PACKAGE_PIN D10   IOSTANDARD LVCMOS33 } [get_ports { uart_rxd_out }]; #IO_L19N_T3_VREF_16 Sch=uart_rxd_out (out of FPGA)
set_property -dict { PACKAGE_PIN A9    IOSTANDARD LVCMOS33 } [get_ports { uart_txd_in }]; #IO_L14N_T2_SRCC_16 Sch=uart_txd_in (into FPGA)

 

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?

The warning says "Linker script will not be updated automatically. Users need to update it manually". The problem is that you need to know that the linker script is where it knows how much memory there is (nothing says that anywhere and I assumed the BSP and its info handled that as is common in many Eclipse systems. It says, as shown below, that "the new specification file will be copied in", the HW inferred compiler options will be updated", and "SW specifications files (MSS) will be updated". Now, I would assume that one of those would be the source of this info. Most vendors do it this way: the actual processor memory is defined outside the linker file, and the linker file simply assigns uses such as text and data, heap, etc. That is a much cleaner method. In any case, I did not know this and I suspect many will not who are used to more common tools such as for ARM Cortex-M. Regards, Paul

[D@n]

@Paul_kimelman,

I'm actually with you on this one.  I've messed up knowing which pin is a tx vs rx UART pin so often that I finally built a Hello World design using no other I/O ports than the tx and clock just to know I got it right.  A similar design works by reading a line of text and writing it back out, so you know you've got your ports right.

As for the spec and documentation ... I've always been of the "trust, but verify" crowd.  I trust nothing completely until I've proven it.  This goes for tutorials as well. 

Dan

[zygot]

I've written my own IP and added it to the Vivado IP. It's quite an undertaking. I suggest that you pore through Xilinx documentation and tutorials to see how this is done.

I avoid MicroBlaze as much as possible but when I use a Zynq I'm pretty much tied to the normal flow. What I do in this case is build my board design and have Vivado create an HDL toplevel... making sure that I DON"T let Vivado manage it. I can then write a wrapper as a new toplevel HDL that instantiates the old board design and my own HDL modules.

[Paul_kimelman]

1 hour ago, zygot said:

I've written my own IP and added it to the Vivado IP. It's quite an undertaking. I suggest that you pore through Xilinx documentation and tutorials to see how this is done.

I avoid MicroBlaze as much as possible but when I use a Zynq I'm pretty much tied to the normal flow. What I do in this case is build my board design and have Vivado create an HDL toplevel... making sure that I DON"T let Vivado manage it. I can then write a wrapper as a new toplevel HDL that instantiates the old board design and my own HDL modules.

Hi Zygote. I found that when I used MicroblazeMCS, I was able to do so in a very normal flow. It creates what ISE called a "core" which I get to instantiate into my top. This is unlike the craziness of the designer which makes it very hard to integrate into the system since it will not do external properly and it will not accept an incomplete system - they want you to import your IP as a package or set of. You have to match naming and ports and their whole packager is a disaster (I found it would not forget a port I had deleted nor a param I had removed, and its auto association only seems to work for AXI names if you follow their exact names - gets clock wrong, etc.

But, the MBlazeMCS was fine - I did not need more than it supplies and I wrote a simple IO bus to APB bridge (all of 8 lines).

On your point about modifying the wrapper (or using your own), then you have to never make a change to the "designed" system. The MCS model at least allows you to update it (e.g. change memory, add more peripherals, etc) with no issues (other than SDK not updating the memory size - has to be done manually). You can also add other peripherals as cores like normal. 

[asmi]

42 minutes ago, Paul_kimelman said:

But, the MBlazeMCS was fine - I did not need more than it supplies and I wrote a simple IO bus to APB bridge (all of 8 lines).

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.

[Paul_kimelman]

3 hours ago, asmi said:

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.

This is an interesting point. I don't need the extra horsepower since my focus is on the digital IP (which is of course being developed for use in Si chips), but it is an interesting point. Of course multi-core is kind of a hassle to program. I have not bothered connecting the debug up by the way; I suppose i ought to, but I have only been running test code on the MB that stimulates the HW. I might want to if I connect up some of the Pmod devices I got (for fun).

[asmi]

17 hours ago, Paul_kimelman said:

This is an interesting point. I don't need the extra horsepower since my focus is on the digital IP (which is of course being developed for use in Si chips), but it is an interesting point. Of course multi-core is kind of a hassle to program. I have not bothered connecting the debug up by the way; I suppose i ought to, but I have only been running test code on the MB that stimulates the HW. I might want to if I connect up some of the Pmod devices I got (for fun).

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.

[Paul_kimelman]

1 hour ago, asmi said:

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.

interesting. One obvious use would be to have one running a Pmod display, so the other(s) simply write into a frame buffer and then trigger an interrupt into it to update. 
I suppose I could also add a serial port mux/demux, so you can use an input char to select different MCUs to speak with. That could be interesting. I would need to buffer the output, but that is OK. I need to think about that, as it could add an interesting use model for certain types of tests. 
Thanks, Paul

[D@n]

@ALICEPENA2017,

Who are you trying to contact?

Have you considered using the messenger portion of this forum?  Click on the individuals name you are interested in, and then message them.  No e-mails are required.

Dan

[Paul_kimelman]

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

Yes, and I have worked medical and auto safety system - both HW and SW. I build IP for chips now and that would be $M down the tubes if bugs in it. I have spent plenty of time cleaning up after SW engineers more often than HW. This is not because they are lazy, but because they are sloppy. You can study the manuals for a year and it will not fix sloppiness, disorder, etc. In design engineering, you have to be better because it is going into Si. But, that does not stop you being "lazy" in the sense of not wanting to waste time on having to read more documents because the tools vendors and others have done a sloppy job or because people cannot organize their info into tables and so on.

You can install them side-by-side, without deleting old version. At least that's the way it works in Windows.

It is too big. I am running on an SSD and Vivado is 25GB on disk, and that is with support for various things turned off. 

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.

I am hoping that Spartan7 is a solid device and not the disaster that is Spartan6. But, truthfully, I am only using these for IP pre-Si validation, so I don't care much. 

I can see you would want a high end Cortex-A processor if its is your whole app - a lot of setup work though. I have been doing some experiments in vision with CNN approaches for classification, but that is all about vectors and data plane - the processor is not used much.  Anyway, looks interesting with the Arty Zynq board.

[asmi]

1 hour ago, Paul_kimelman said:

But, note that the tutorial someone put up has 2 huge problems for Arty: the reset of ck_io is active low (button down is Low, else it rests High, but MBlaze wants active High and so will do nothing unless you invert the signal), the UART direction for Arty is not clear and so if you connect RX to RX and TX to TX it will fail to work.

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.

1 hour ago, Paul_kimelman said:

is not clear and so if you connect RX to RX and TX to TX it will fail to work. This seems to be a Diligent problem. I would suggest Digilent add a direction in the comments of the xcd file so it is clear for any signals like that.

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.

1 hour ago, Paul_kimelman said:

On an related note, I discovered a bug in SDK you may not know about. If you pick a RAM size for the MicroBlaze and export to SDK, it adds to the linker file. If you increase it via the IP builder and re-export, the SDK does not change. I was finding 32K to be not enough so I changed to 64K and it still failed the link. I found I had to edit the linker file and change the size myself and then it all w

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?

[jpeyron]

@Paul_kimelman,

You make some good points and suggestions. I have passed these along to the appropriate people as well. 

thank you,

Jon

[Paul_kimelman]

I would also suggest on that ref page that it has a small intro that notes that you can choose to develop using the Designer which is good if you are planning on using pre-built pieces and adding software, or if you are OK with packaging AXI bus IP (and only AXI - their bridges are broken). If you want a more traditional flow but still want the MicroBlaze processor, then point them to the MicroBlaze MCS. But, note that the tutorial someone put up has 2 huge problems for Arty: the reset of ck_io is active low (button down is Low, else it rests High, but MBlaze wants active High and so will do nothing unless you invert the signal), the UART direction for Arty is not clear and so if you connect RX to RX and TX to TX it will fail to work. This seems to be a Diligent problem. I would suggest Digilent add a direction in the comments of the xcd file so it is clear for any signals like that.

On an related note, I discovered a bug in SDK you may not know about. If you pick a RAM size for the MicroBlaze and export to SDK, it adds to the linker file. If you increase it via the IP builder and re-export, the SDK does not change. I was finding 32K to be not enough so I changed to 64K and it still failed the link. I found I had to edit the linker file and change the size myself and then it all works.

[jpeyron]

Hi @Paul_kimelman,

Thank you for your suggestion. I can see how that could be helpful. I have passed your suggestion to the appropriate people.

cheers,

Jon

[Paul_kimelman]

3 hours ago, jpeyron said:

Hi @Paul_kimelman,

I'm glad to hear it sounds like you have it working. The second link I posted above i believe covers what you are talking about. The Arty programming guide programs the quad spi flash from Vivado using a .bin file.

cheers,

Jon

Jon, my point is that https://reference.digilentinc.com/reference/programmable-logic/arty/start should have that 2nd link. If the URL is your resource for everything, that would be a good place to have a tutorial on loading into SPI ROM when you only want to use the tools to do so. Thanks, Paul

[Paul_kimelman]

OK, I found it on a Xilinx forum. You have to delete the .plugins directory and then reimport the project. Pretty crazy but the SDK is known to have problems.

 

[D@n]

@Paul_kimelman,

I seem to recall having this problem within Linux before.  The solution was to start it from a terminal that had only freshly had the environment variables set.  Not sure if that's your problem, but ... it's one I had that fit the symptoms you've just shared.

Dan

[Paul_kimelman]

Hi Jon. Sigh, one more thing. The SDK crashed suddenly - not sure why. I cannot get it to run now. I use Launch SDK and it starts with the splash screen but then dies. Any ideas how to recover and move on??? I exited Vivado and restarted and I tried re-exporting, but no luck. If I start SDK by itself, it does not seem to know the workspace.

[jpeyron]

Hi @Paul_kimelman,

I'm glad to hear it sounds like you have it working. The second link I posted above i believe covers what you are talking about. The Arty programming guide programs the quad spi flash from Vivado using a .bin file.

cheers,

Jon

[Paul_kimelman]

OK, thanks. The tutorial has you creating boot apps and all. I just wanted a simple program and go. I finally found the SPI ROM from Micron and found you have to set the .bin file creation. So, I have it working now I think. I would suggest your tutorial explain that if you just want to program it to skip all of that and do the other; you do not have to create a boot loader app if programming in Vivado is enough. Thanks

[jpeyron]

Hi @Paul_kimelman,

We have the tutorial How To Store Your SDK Project in SPI Flash here and the Arty programming guide here that programs the quad spi flash from Vivado.

cheers,

Jon

[Paul_kimelman]

Hi Jon. I have it all working so I now need to write to SPI ROM so it can boot from there each time. I do not see how you do this - not like IMPACT where it shows the ROM. Is there some Vivado thing I need to use for this? I don't want the app/image accessing the SPI ROM, just using it as an FPGA boot image. Sorry, I should say that there is the Add Config Memory device dialog, but I do not know what part you have  on the ARTY and the ref man does not explain it in this context: "Quad-SPI programming can be done using the hardware manager in Vivado or with the iMPACT tool included with ISE.". It does not say which to pick?

 

Thanks, Paul

[Paul_kimelman]

I have it all working now, but this would be useful for you to have a link to. I think the MBLaze MCS scheme is much better for anyone who wants a normal ASIC flow and to add their own IP in a flexible way. The Designer tool is fine if you want to follow inside the Xilinx scheme and use AXI and all (their bridge is a disaster and does not work).

[jpeyron]

Hi @Paul_kimelman,

We do not have a Microblaze MCS tutorial or demo but i did find a tutorial here that might be helpful.

cheer,

Jon