• 0
ColoradoAnalog

Arty GPIO demo UART communication

Recommended Posts

  • 0

I'll put this here just in case anyone else searches for this. I had to change the port number to get it to work. I found out what the port number was by looking (in Windows 7) at Control Panel > Hardware and Sound > Devices and Printers > Unspecified > Digilent USB Device, then right click and select Properties, then go to the Hardware tab. Here it shows that it is using COM7. After I changed the port number to 7 and reprogramming the FPGA the UART communication worked.

Share this post


Link to post
Share on other sites
  • 0

Hi ColoradoAnalog,

Thanks for posting what you found! I'll make sure the demo project page gets updated appropriately.

Thanks,
JColvin

Share this post


Link to post
Share on other sites
  • 0

I, too, just got an arty board and followed the instructions - including the prerequisite of introducing digilent's board files into (in my case) the folder C:\Software\Xilinx\Vivado\2015.4\data\boards\board_files\arty (amongst several sibling folders for other boards) from the Digilent\vivado-boards-master\new\board_files folder in the github zip. I started with the Arty-master\Projects\XADC_Demo project, using the create_project.tcl script as instructed, and got as far as unearthing 20 critical warnings and 17 non-critical ones. Attempts to export the hardware with bitstream to the SDK simply resulted in a dialog which effectively ends any progress. What am I doing wrong?

In addition, where's the web-server project promised in a well-known youtube video from last year? I know it's xilinx's promise, and not digilent's, but even so.

2016-04-08.png

Share this post


Link to post
Share on other sites
  • 0

Hey Lemoutan,

To see if your board files are actually installed correctly, make a new project then click next until you are asked to specify the part. You should be able to click the boards tab and see the ARTY in the list. 

Next is addressing the critical errors. These should just be warnings about unconnected pins to the XADC IP. This is ok since the design does not need them. 

The dialog you are getting is expected because the export hardware option is used for Microblaze designs. The XADC demo is purely a digital logic demo and does not utilize the Microblaze core. To load this onto your board, open the hardware manager found under Program and Debug then open target. After your computer connects to your board, you can click program to load the demo onto the board.

I haven't heard anything new about the web server demo but if it is just the freeRTOS components of the web server that you want, it is not too hard to get a simple RTOS project going in Vivado. You can respond to this and I can make a little reference design for the resource center.

Hope this helps!

-Sam

 

Share this post


Link to post
Share on other sites
  • 0

Hi sLowe. Thanks for biting!

My complaint was that following the instructions supplied with the product got me nowhere - presumably because software or firmware updates since the instructions and (critically) the software were first committed to paper/website have not been correspondingly upgraded.

But since then (it was a month ago) I've found other routes. For example a couple of youtubings - one by Sarah Fagin (https://www.youtube.com/watch?v=aPDT0sPr4jE) which - despite being aimed at the zybo - got me going with a very simple VHDL. That worked a treat, but obviously it's nowhere near as complex as the OutOfTheBox artyistry. Another one (https://www.youtube.com/watch?v=gjGWAr5L9dg) involved creating a basis microblaze from scratch. That one worked most of the way, but the last couple of minutes used the debugger which - for some unknown reason - did not work at all for me. So despite looking promising it turned out another dead end (at least debuggingwise - the actual programming worked fine). Basically then, I can 'do vhdl' with an arty, but that's about it. It may be enough. I conclude, therefore, that Vivado seems to see the necessary artyness configgery quite satisfactorily.

I'd really like to complete (i.e. work through) that XADC demo though and - despite what you say about 'warnings about unconnected pins' - the errors are critical and it's most definitely not OK. I didn't simply see a few warnings (there were also many of those) and whimsically decide to refer to them here as 'critical errors' for the fun of it. They are show-stoppers and - again, being a newbie - I've not much of a clue what to do about them. I'm assuming anyone else taking the same route as I did will encounter the same difficulty. There's nothing to load onto the board because it doesn't get as far as generating a bitstream.

The web server demo (https://www.youtube.com/watch?v=NF7ryZH8lxE) looked really interesting but - again - there's nothing on xilinx's site corresponding to what is now looking like vapourware. Like an earlier poster said here, one's concern is that the license might expire before one gets to play with such stuff.

I very much appreciate your offer to provide an RTOSsy webserver. However, I cannot answer specific questions addressing your "if it is just the freeRTOS components of the web server that you want" because I don't know what I want yet. All I can really say is that it would be nice to be able to reach the board over the internet and get it to do stuff. As things stand, there seems to be no working material knocking about (at xilinx or digilent) to lead you through to that.

I'm just playing around and see the "I'd like to do this" stage as "stage two". My main point is that I expect the quick-start-for-newbies stuff (i.e. "stage one") to work, and it just doesn't. This makes it a very frustrating experience for those trying to learn!

Thanks for listening (if you have been)!

 

Share this post


Link to post
Share on other sites
  • 0

Hey lemoutan!

Sorry to hear about your frustrations. Could you maybe take a screenshot of these "critical errors" you are getting if you still have the project up? When I ran the project I got "critical warnings" that although may look bad and in other projects can point to large issues, these refer to problems that the design accounts for. The xadc demo lets the wizard initialize the IP so that the demo itself does not need to talk to the IP over the DRP interface. That is why those pins are not connected. Those critical warnings can most likely be eliminated if those ports are explicitly driven to 0. (The tools end up doing this anyway.) If the errors do stop bitstream generation that is a big problem and would love to see the errors you are getting. Do they look like the ones below?

  • [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[15]
  • [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[14]
  • [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[13]
  • [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[12]
  • [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[11]
  • [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[10]
  • [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[9]
  • [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[8]
  • [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[7]
  • [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[6]
  • [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[5]
  • [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[4]
  • [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[3]
  • [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[2]
  • [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[1]
  • [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[0]
  • [Synth 8-4442] BlackBox module xadc has unconnected pin dwe_in
  • [Synth 8-4442] BlackBox module xadc has unconnected pin reset_in
  • [Synth 8-4442] BlackBox module xadc has unconnected pin vp_in
  • [Synth 8-4442] BlackBox module xadc has unconnected pin vn_in

It is interesting that the debugger did not work for you in SDK. Were you able to just run the program on your board without debugging it?

It is awesome that you are hungry to play with the ARTY. The learning curve with the tools is pretty steep but as many will tell you the experience is very rewarding!

-Sam

Edited by sLowe

Share this post


Link to post
Share on other sites
  • 0

I thought I might be able to do better than that by looking at the log files. So I looked for them but found only a couple that I'd explicitly saved. They're attached - the shorter 5kb 2015.4 one is the one that told me that I had to use viv 2015.3 to effect some kind of source updating, and the 64k [because it got further] 2015.3 log is where I got stuck because (as mentioned in the xilinx thread) I did not know how to 'open a design' so blindly guessed at what to do next, something happened, but I still failed to complete (because of a missing tcl script which 'they' claimed would be there but wasn't).

As it happens I posted my woes first on the xilinx forum as a more detailed report. It included the 8-4442s you cite above. I kept checking back for replies but responses came there none. Until, that is, I just went back there to get its URL for you and noticed one! Apparently somebody responded on the 26th April, but the forum software didn't tell me (I'd long given up waiting for responses by then). It looks like xilinx's forum is an opt-IN-for-responses notification type whereas here at digilent it must be an opt-OUT-of-responses notification system.

So I should now toddle over to xilinx's forum and apologise to the helpful person there for my late acknowledgement (and try to find out how to opt in for responses!). And then I suppose I'd best try the presented workaround (the claimant notes it's not a solution, just something that seemed to work). I'll need to follow the path I took a month ago, so this recollection may take a while.

[As for the debugger not working, that was in the different microblazer build project. Like I said (possibly confusingly since I used the activity word 'programming' rather than the product word 'program' - sorry about that!) "the actual program[ming] worked fine", to answer your question.]

Now I'll reopen that BSD (nb not the xadc, which I never got around to retrying since attempting to update the BSD sources seemed so spectacularly unproductive) OOtB project (which I'd just abandoned) in viv2015.4, now, just to see what state it's left in (tho I note that vivado 2016.1 is now out - and keeping up with projects not appearing to be upward compatible sourcewise/IDEwise - that's another story!).

Looks like it's in a state where 'Run synthesis' might be the thing to do, so here goes.

(1) OK, synthesis seems green and uneventful (took quite a while though, with 538 warnings, which I'm ignoring) and I'm being encouraged to 'run implementation', so ...

(2) Hmm. Bit of an ambiguous result here. The "Implementation Completed" popup is all "Blue i Info" with Implementation successfully completed and a next to "Open Implemented design" BUT the bottom "design runs" panel is showing a small red exclamation mark with some WNS/TNS/WHS/THS figures in red an a Failed Timing! status. But I guess I'll OK the 'Open' anyway.

This is not at all what I remember from last time is all I can say at this point.

As things in red seem 'dangerous' to me, I'm unwilling to proceed, not that I'd know what the next step is anyway! The design opened ok but I'm not being invited to generate a bitstream or go any further. It's just sitting there, looking red.

bsdproject2015.4tclscriptlog.txt

bsdproject2015.3tclscriptlog.txt

Share this post


Link to post
Share on other sites
  • 0

The unbearable redness of 'open implemented design':

Screenshot 2016-05-10 20.49.14.jpg

As regards the debugging issue, I note a few - presumably pertinent - tcl console messages:

INFO: [Labtools 27-1434] Device xc7a35t (JTAG device index = 0) is programmed with a design that has no supported debug core(s) in it.
WARNING: [Labtools 27-3123] The debug hub core was not detected at User Scan Chain 1 or 3.
Resolution: 
1. Make sure the clock connected to the debug hub (dbg_hub) core is a free running clock and is active OR
2. Manually launch hw_server with -e "set xsdb-user-bscan <C_USER_SCAN_CHAIN scan_chain_number>" to detect the debug hub at User Scan Chain of 2 or 4. To determine the user scan chain setting, open the implemented design and use: get_property C_USER_SCAN_CHAIN [get_debug_cores dbg_hub].
 

So I guess a question here is "How do I 'use' get_property C_USER_SCAN_CHAIN and where?"

Edited by lemoutan
moving text around so the message makes more sense

Share this post


Link to post
Share on other sites
  • 0

Yeah looks like the temperature reference data is not being set up in time for the MIG to look at it. From all the guides I just looked through it seems like it uses this to keep the data lined up since it knows how the memory IC is affected by heat. This temperature reading comes from the XADC sequencer. I was not able to immediately get rid of these errors. The hardest part being that the axi clock in the design is set to 100 MHz which is where is should probably stay. Then the MIG is running at 200 MHz on a different clock domain. Another possible problem is that we are just including too many XADC ports in the sequencer. This many inputs may slow down the update rate to the point where this error is created. Usually I think the way to get around this is by using the mig as a clocking wizard so that everything runs in sync with the speed of the mig. However that doesn't seem viable in this design. 

You can go ahead and run "generate bitstream" and it will work. Although an important signal, it is already averaged and shouldn't change too much. (assuming you aren't in an extreme environment) I ran the memory test with the timing errors and it passed just fine. While this isn't something to just ignore, for your purposes I don't think this timing error will affect you other than the ugly redness at the implemented design.

----------

As far as the debugging goes, wait and see if this design works for debugging. 

If you want to see where I spent the last hour reading about clocking and the MIG in general....

http://www.xilinx.com/support/documentation/ip_documentation/ug086.pdf

http://www.xilinx.com/support/documentation/ip_documentation/mig_7series/v3_0/ug586_7Series_MIS.pdf

http://www.xilinx.com/support/answers/51687.html

-Sam

Share this post


Link to post
Share on other sites
  • 0

Turns out those debugging messages turn up on every project; vhdl sourced, c/microblazy sourced,  whatever. As the message is telling me that there's no debug core, and I don't yet know what that is (is it something that's supposed to be permanently programmed on the board or is it something you have to include - I dunno, I'm an arty/vivado newby!).

I've been able to debug stuff on texas hardware (e.g. an msp432) but of course that isn't with vivado but with their eclipse based ide (or even MS Visual Studio), so both hardware manufacturer and IDE are different.

Currently trying the Basys3 XADC_Demo in viv2015.4. Run synthesis gets me 19 critical warnings, 28 warnings, ignoring. Open synth design gets same red timing errors as on arty, which you're effectively telling me to ignore, so I guess I'll make a bitstream ... a very brief message in top right status, something too quickly disappeared about "Failure!" but goes on to write bitstream regardless. Opening reports - nothing red. Autoconnecting to basys3 ... oh boo:

INFO: [Labtools 27-1434] Device xc7a35t (JTAG device index = 0) is programmed with a design that has no supported debug core(s) in it.
WARNING: [Labtools 27-3123] The debug hub core was not detected at User Scan Chain 1 or 3.
Resolution: 
1. Make sure the clock connected to the debug hub (dbg_hub) core is a free running clock and is active OR
2. Manually launch hw_server with -e "set xsdb-user-bscan <C_USER_SCAN_CHAIN scan_chain_number>" to detect the debug hub at User Scan Chain of 2 or 4. To determine the user scan chain setting, open the implemented design and use: get_property C_USER_SCAN_CHAIN [get_debug_cores dbg_hub].
 

same thing as with arty. I'll not be able to debug. Looking like a vivado or digilent deal, then? The message is aimed at somebody who presumably knows the IDE's architecture/methodology, and maybe the getting started guide-writers didn't see this happening? I don't know how to (1) "make sure", or (2) bring up the hw_server on the command line with those arguments - is hw_server an exe or a .cmd, where does it live, will it be in my path, if I find it is it ok to run it whilst vivado is still running?

So, OK I'll have a look. I appear to have 5 hw_server.bat files spread around various combos of vivadi 2016.1, 2015.4, 2015.3 and their SDKs. And 9 hw_server.exes similarly distributed - but 4 of them appear to be associated with ISE. I guess I'll start with the non SDK bat for 2015.4, which calls a loader.bat after setting up an env. Already this is getting complicated. Am I overthinking and should I just open a command prompt and cd to /Xilinx/Vivado/2015.4/bin/unwrapped/win64.o? Here goes

>.\hw_server.exe -e "set x sdb-user-bscan C_USER_SCAN_CHAIN 2"

Well, something's running. It's just sitting there, saying:

****** Xilinx hw_server v2015.4
  **** Build date : Feb 26 2016-04:46:14
    ** Copyright 1986-1999, 2001-2015 Xilinx, Inc. All Rights Reserved.

INFO: hw_server application started
INFO: Use Ctrl-C to exit hw_server application

INFO: To connect to this hw_server instance use url: TCP:kahontsi:3121

I'm none the wiser though. Changing the 2 to a 4 (after Ctrl-Cing it) results in the same thing. How has that helped me find out why I don't have a debugger?

 

Share this post


Link to post
Share on other sites
  • 0

Ok I think I have this figured out. First off my cube mate filled me in on how to fix those timing errors we were seeing in the BSD, Basically the XADC needs to be put in the same clock domain as the MIG. This can be achieved by disconnecting the clock and reset pins of the XADC and the M13 port on the AXI interconnect. Then attaching the clocks to the uiclk output of the MIG and the reset to the peripheral reset from the rst_mig_7series_0_83M block. I did this and the timing errors went away. Eventually this will be fixed and the project will be updated to at least 2015.4

The debugging error you are seeing is from not having the ILA (Integrated Logic Analyzer) ip in the design. You will still be able to debug the C code in the design later in SDK without this IP. The IP is included in the system edition of Vivado but I don't think it is in the Webpack edition. This tool basically lets you sniff internal signals of the design in real time. It is very useful for digital design projects but if you are using Microblaze, the debugging in SDK will be fine enough.

The reason everything seems to use ISE is because ISE and Vivado use the most of the same background processes so a lot of Vivado tasks have ISE titles.

Have you tried exporting your design and programming it at all in SDK?

-Sam

Share this post


Link to post
Share on other sites
  • 0
6 hours ago, sLowe said:

This can be achieved by disconnecting the clock and reset pins of the XADC and the M13 port on the AXI interconnect.

Knowing not much more about vivado that I did several posts ago, I re-opened the BSD project in the state it was last left in, and guessed that what you're talking about here is to be found in the "IP integrator/Open Block Design" piece of the IDE. And that somehow I've got to find these two things you mention. As there's a magnifying glass in a left hand strip down the side of the enormous microblaze drawing, I guess I'll try that. 11 matches for M13. OK, I can see (in the search results 'tree') a single node called 'Ports' with exactly two leaves M13_ACLK and M13_ARESTN so I imagine that's what you're talking about here. Problem is that as soon as I click on the diagram, that search result box disappears and needs re-searching 'M13' again from scratch - it doesn't 'remember' its previous searches, which is a shame because I think I'm going to be needing those results again and again to find things. Actually, I can't really proceed since I (a) don't really know if I've got the right 'objects', (b) would be wary of removing connections without knowing for sure what the reconnections should be and (c) in any case how to effect such reconnections in such a large diagram. Maybe I could be doing this with more facility in the source code?

But even if I'm able to complete this mini-exercise, I don't think I'll be learning anything. I'll just be following instructions. This sort of level of detailed knowledge about this microblaze doodah (which I'm not terribly interested in - yet - anyway, beyond its black-boxy means-to-an-endness) doesn't strike me as out-of-the-box newbiness. Doubtless a few months down the line I'll be fascinated by it.

" The debugging error you are seeing is from not having the ILA (Integrated Logic Analyzer) ip in the design. "

(seems I can't quote more than one chunk of your post, so I'll just put the above in a different font)

I must say I did wonder how it was going to be possible to debug verilog/vhd (at the source level) anyway, so seeing vivado present these missing debug chain things in such projects struck me as one of those precisely correct but irrelevant warnings anyway. Debugging C code generated by microblaze is a different matter however,  so - since it was integral to the last part of the https://www.youtube.com/watch?v=gjGWAr5L9dg tutorial - I thought I'd start from scratch and go through this 9 minute tutorial again, because it definitely included such c-code debugging. But now that you mention a debuggability difference between Vivado SE and Vivado Web, I note that the youtube tutor doesn't say which 'edition' of vivado he's using (his window title is simply Vivado 2015.4, whereas mine is 2015.4.2) so maybe I cannot do everything in the tutorial anyway (despite everything in the tutorial being seemingly also available to me [all block designs match exactly, at least wrt what he shows]- except for any actual debug source line steppage). As this tutorial (part two) exports to the SDK (the 10ish minute https://www.youtube.com/watch?v=1I5tKvK-DAMOK, so I've reached the stage in the tutorial where he's created three projects (hw/bsp/app) for a hello world template and he's just clicked the Build All on the app project. His build takes a few seconds, with a fair few log messages scrolling in a window, and one of those green progress bars. Mine, in contrast, returns instantly with no progress bar, no loggage, and no errors. This is weird because last time I tried this I remember going on to configure a debugger whereas this time it would seem to be pointless since no compilations appear to have taken place.

 

Oh gawd. Why does nothing ever work the same way as what you are shown? Here's the sdk log at this stage. I don't see any point in continuing.

12:52:13 INFO  : Launching XSDB server: xsdb.bat C:/Software/Xilinx/SDK/2015.4/scripts/xsdb/xsdb/xsdb-server.tcl
12:52:16 INFO  : XSDB server has started successfully.
12:55:30 INFO  : Project 'arty_video_hw' created. You can now create BSPs and application projects targeting this hardware platform.

This log seems to have stopped reporting after having created the first of the three projects, yet I'm staring at an eclipse with three projects in it - and specifically at:

#include <stdio.h>
#include "platform.h"

void print(char *str);

int main()
{
    init_platform();

    print("Hello World\n\r");

    cleanup_platform();
    return 0;
}

So, as they say, wtf?

Share this post


Link to post
Share on other sites
  • 0

Continued ...

OK. As you were. I've noticed that my eclipse project build menu has 'build automatically' checked ON, whereas I just spotted that his did not. So, without my having noticed any logging messages saying I was getting an elf, it turns out that there is one actually sitting there, silently awaiting my discovery of it, so I shall in fact continue. My apologies for - at this stage - giving up too easily (but I've stopped expecting things to just work by now). BTW how much use is this to anyone else? I feel I'm taking up too much of your time and boring everyone to death :).

AND of course everything works as advertised this time - debugging and all, stepping over, etc. - the hardest part trying to work out which COM port I'll be expecting this 'Hello World' string to turn up in.

So basically, what did not work before now appears to work, despite my not (ttbomk) having done anything differently.

Does this, then, confirm to you that the only way I'm ever going to be able to debug is via this sdk? I.e. unless I export a design to the sdk I'll never be able to debug anything? I ask only because I still don't really feel I'm any the wiser with the use of vivado alone, or what its methodology is. At least with verilog/vhdl I can see what I'm doing at that 'atomic' hardware level. At this microblaze level I'm just a 'user' without any real understanding, more or less blindly following examples (OK, and maybe adapting them). I still don't feel I could build an IoT app into Arty. Maybe that just needs more time?

Share this post


Link to post
Share on other sites
  • 0

Just in case it's of any interest I found the sdk log from my previous go at this on 25 April - the one where I didn't have any working debugging. (NB - contains evidence of my paranoid scrubbing of filesystem pathnames - you'll just have to take my word for it that there are no spaces or unusual characters in any of the enroute folder names!).

Also, last time it seems that I'd been using the newer vivado 2016.1, so there is a difference there, although why an updated IDE should failurise (!) a debugging system (with its corresponding SDK 2016.1, which I'd also installed), if that's what it is, isn't a terribly satisfactory conclusion.

SDK.log

Share this post


Link to post
Share on other sites
  • 0

First off any record of people hitting walls and breaking through them will be helpful to any people in your same situation so no worries about posting so much! I will start off with some good news that the Web Server demo from Xilinx finally got posted so that IoT destination just became much easier to get to. Although I would definitely work these projects out until you are comfortable with these small Microblaze demos before diving into that one. I haven't tried it but the source/tutorial can be found here 

http://www.wiki.xilinx.com/ARTY+FreeRTOS+Web+Server

The COM port problem is something we seem to have a tough time explaining. Usually for me, if I am using a third party UART program I just flip between the non-zero com ports until I get an output. (I usually have a lot of boards connected to my computer). In my experience to debug pure HDL, we use simulations to analyze the design. In Microblaze designs this doesn't really apply. Another method is to use the ChipScope IP previously mentioned if the system edition license is there. I know in the Vivado HLS releases ChipScope is free for webPack but I am not certain about vanilla Vivado 2016.1. It may be worth a try to open up help->manage license and look in the certificate section to see if a ChipScope license exists.

In my opinion the main benefit of Microblaze is to abstract you a little from whats actually going on at the logic level since it accelerates the development process and saves the time of designing all of the components needed. If you are interested in getting one step deeper, you can make your own IP blocks to interface into your block design. This process can be found at https://reference.digilentinc.com/zybo/custom_ip_cores Although the content is written for the Zybo, the process is there as long as you replace the other boards with ARTY.

I found that to make the jump from user to designer with the tools was doing what you plan to do by starting to adapt designs then having to dive into the IP user guides when something didn't work. These are pretty dense at first but eventually you get a feel about how Xilinx designed these things and you begin to understand more and more about the tools along the way. 

-Sam

 

Share this post


Link to post
Share on other sites
  • 0

I guess the COM port would be a bit easier if there weren't two of 'em! One may try a cygwin console with ls -l /dev before you plug in the board, then again afterwards. Two more /dev/ttyS* turn up. An stty -F /dev/ttyS<1stOne> and stty -F /dev/ttyS<2ndOne> seems to come out with the higher numbered one ticking at 1200 baud and the lower at 9600.

I can't answer the question about the presence of a ChipScope IP license without knowing what it's called in the IP list (there doesn't seem to be anything called 'ChipScope' or, for that matter, very much of a correspondence between names of IPs in the designer and names of IPs in the licensing).

BTW - how far off the mark was I in my assessment of how one might go about reconnecting that clock'n'reset you mentioned? Or is it easier to just wait for the project update?

Looking forward to seeing how that internet project works out!

Share this post


Link to post
Share on other sites
  • 0

Its not too hard at all! I will make some steps for you.

The first thing you will want to do is disconnect some nets. To disconnect them without deleting the whole interconnect, click the pin label, then right click and select "disconnect pin"

The first two pins will be on the xadc wizard block. The pins to disconnect are named s_axi_aclk and s_axi_aresetn. 

Then connect s_axi_aclk to the uiclk pin on the MIG. Connect s_axi_aresetn to peripheral_aresetn[0:0] on the rst_mig_7series_0_83M block. 

Now we are going to do the same thing with two more pins.

On the microblaze_0_axi_periph block disconnect the M13_ACLK and M13_ARESETN[0:0] pins and connect them to the same respective nets as the XADC signals. The block diagram should look like this after. I have highlighted the reset and clk nets

 

 

bsd_mig_clk.JPG

bsd_mig_reset.JPG

Share this post


Link to post
Share on other sites
  • 0
10 hours ago, sLowe said:

 

Its not too hard at all! I will make some steps for you.

 

Thanks. Although my problem wasn't so much fiddling with a diagram in a GUI so much as in correctly identifying what, within that diagram, needed to be fiddled with. IYSWIM. But anyway, I fiddled in the way directed and ended up (or so I believe) as you've described. As I appear to have hit some kind of upload limit on this forum I can't show the result with an attachment so you'll need to trust a link (if you want to look, that is!). I've highlighted the four connection areas involved and, at the bottom, an area of logging which draws attention to the previous timing problems. Nothing was immediately redone in the IDE merely by those reconnection activities. I suppose that's normal. But I did not really know what to do next (since I'm not learning here, but just following instructions) so just right-clicked on that red 'Design Runs' reporty-area hoping to pick up any clues on what to do next. Right-clicking on synth_1 at the top of the report tree offered some sort of run reset, going back two, so it seemed plausible and I tried that, plus what seemed to be offered next - which was a rerun from there. The synth design completed in a little over nine minutes and it all stopped, but dialog-promptily suggested I run implementation, so obviously I do that and I get a dialog with 36 critical warning messages on the synth node of the report tree

 

INFO: [Common 17-83] Releasing license: Synthesis
2948 Infos, 540 Warnings, 36 Critical Warnings and 0 Errors encountered.
synth_design completed successfully
synth_design: Time (s): cpu = 00:08:31 ; elapsed = 00:08:59 . Memory (MB): peak = 1418.293 ; gain = 1035.410
write_checkpoint: Time (s): cpu = 00:00:09 ; elapsed = 00:00:06 . Memory (MB): peak = 1418.293 ; gain = 0.000
report_utilization: Time (s): cpu = 00:00:00 ; elapsed = 00:00:00.185 . Memory (MB): peak = 1418.293 ; gain = 0.000
INFO: [Common 17-206] Exiting Vivado at Sat May 14 12:02:45 2016...

and a failure (place_design ERROR) and a whole bunch of messages I'm not at all sure how to present in order to demonstrate (very few of the text logging lines are timestamped so they could be going back months as far as I know), but they end with

INFO: [Timing 38-35] Done setting XDC timing constraints.

Phase 1.1.2 IO and Clk Clean Up
Phase 1.1.2 IO and Clk Clean Up | Checksum: 9d3990b7

Time (s): cpu = 00:00:11 ; elapsed = 00:00:10 . Memory (MB): peak = 1335.313 ; gain = 0.000
Phase 1.1 IO Placement/ Clock Placement/ Build Placer Device | Checksum: 12d8fdfba

Time (s): cpu = 00:00:11 ; elapsed = 00:00:10 . Memory (MB): peak = 1335.313 ; gain = 0.000
Phase 1 Placer Initialization | Checksum: 12d8fdfba

Time (s): cpu = 00:00:11 ; elapsed = 00:00:10 . Memory (MB): peak = 1335.313 ; gain = 0.000
ERROR: [Place 30-99] Placer failed with error: 'IO Clock Placer failed'
Please review all ERROR, CRITICAL WARNING, and WARNING messages during placement to understand the cause for failure.
Ending Placer Task | Checksum: d9f81dd5

Time (s): cpu = 00:00:11 ; elapsed = 00:00:10 . Memory (MB): peak = 1335.313 ; gain = 0.000
INFO: [Common 17-83] Releasing license: Implementation
43 Infos, 52 Warnings, 36 Critical Warnings and 4 Errors encountered.
place_design failed
ERROR: [Common 17-69] Command failed: Placer could not place all instances
INFO: [Common 17-206] Exiting Vivado at Sat May 14 12:04:14 2016...

So that happened ...

Share this post


Link to post
Share on other sites
  • 0

For educations sake, the reason we made those connections were to put the XADC core onto the same clock domain as the DDR memory. The design has a couple clock domains. One comes from the clk wizard which generates the system clock and a couple reference clocks for the MIG to use. The MIG then uses these clocks to read and write data. However this data stream has now created a new clock domain. One that is defined by uiclk. The temperature data that comes from XADC needs to be on this new memory/uiclk domain. In order to accomplish this we need to make the XADC clocked by uiclk. The only thing left to consider is that the Microblaze processor needs to also talk to the XADC block. Luckily the axi_peripheral interconnect can buffer and handle clock domain crossing fairly well. This is why we changed the M13 pins on the interconnect. These corresponded to the AXI bus leading to the XADC core. So in review we took the XADC block and placed it into the same clock domain as the MIG. Whenever you see that your design fails timing, checking if your clock domains are the problem is a great first step!

What exactly were your critical warnings in the synthesize stage? Your diagram looks fine so I can't tell what you are running into from the log.  

-Sam

 

Edited by sLowe
Small edits

Share this post


Link to post
Share on other sites
  • 0

The runme.log file (attached) cites date in February at the start, which is why I do not know if the entire content of that file is a result of the (re) synthesis of the reconnected clock. But it has 52 warnings alongside the 36 critical warnings reported right at the end (14 May) - and also in the middle - so I guess the entire file could be relevant and maybe the February dates at the top are a red herring. Anyway, I daresay what you seek may be found in there somewhere!

I can't help feeling, though, that something as simple as altering pin to pin mappings is much easier - and much less error prone - in a text source model where the worst you can do is mistype a name. E.g.  changing the names block1.pinP and block1.pinQ, respectively, to block2.pinR and block3.pinS with a text editor in some network-definition source file would effect a desired rerouting with the minimum of effort. But maybe that's not how the system is described?

It'll have to be another dropboxment for that log file. Even 62kB is too much now.

Edited by lemoutan
Exhausted my upload abilities

Share this post


Link to post
Share on other sites
  • 0

Yeah if this were true verilog, changing nets in text is an option and I am sure there is some tricky way of doing it that way. (maybe editing the Verilog file enclosed inside the block design.) But unfortunately when using block designs, you are for the most part locked into the GUI and its functions. By the way to reset a run usually a little trick I use is putting a space in the system wrapper.vhd file then deleting it and saving. The tools will think the design has changed and will reset your run. The way you found is probably the correct way to do this though.

The dates you are referencing is when Vivado 15.4 was actually built at Xilinx so nothing to worry about there. 

Now for those critical warnings. It is really weird that all of a sudden your GPIO headers on top of your ARTY are complaining now. These correspond to the same named pins on the top right of the design. Especially since none of the other pins are throwing critical warnings (would point to the board files) Without looking at your project, my first step would be to hope the IP got messed up somehow and right click the system.bd file and select "reset output products". This will essentially make your project synthesize from scratch including the xdc file buried inside the gpio IP that is causing the critical warnings. The tools usually keep the same synthesis of IPs from run to run in order to save time. (this run should take longer than your last successful one.) Could you take a screen shot of your full block design and attach it? Sorry for making you take so many pictures. The dropbox links work great!

-Sam

Edited by sLowe

Share this post


Link to post
Share on other sites
  • 0

I've saved two post-reconnect diagrams as landscape pdfs of clock and reset lines. The highlighted connects look as if they're going to the right places. Now for your "reset output products" ruse. Hmm. As I rightclick said system.bd file, I notice the date on it is Sat 14th @ 11:16:37 am. Which is consistent with its having been up to date at the recent rebuild. However, as this ruse is 'resetty' in nature, it may not have been correct, so here goes ... do that output products reset

open_bd_design: Time (s): cpu = 00:00:14 ; elapsed = 00:00:11 .
         Memory (MB): peak = 1370.074 ; gain = 370.988
reset_target all
        [get_files  /xilinx/Arty-master/Projects/BSD/proj/bsd.srcs/sources_1/bd/system/system.bd]
export_ip_user_files -of_objects
        [get_files  /xilinx/Arty-master/Projects/BSD/proj/bsd.srcs/sources_1/bd/system/system.bd]
        -sync -no_script -force -quiet

and then going straight for generate bitstream and it tells me it hast to resynth and reimp so that's looking right ... tick tock ... and less than a minute later I get 12 critical errors in a popup which I can only acknowledge, but it carries on regardless ... for a few minutes and then unceremoniously ends with an implementation failed popup. Showing 17 errors and 2 critical warnings (and 592 warnings). Although one of those critical errors is me when I'd attempted to save a second pdf over another extant one (for those diagrams) so isn't relevant. But the rest seem to be.

So that was a bit of a disaster.

Unfortunately, the runme.log file looks very similar to the previous one (last Saturday's) with its 43 infos, 52 warnings, 0 critwarns and 4 errors. So I don't see any point in re-dropping that. Ah, but there's another - much larger @4Mb - one in /xilinx/Arty-master/Projects/BSD/proj/bsd.runs/synth_1 - but that ends up with "Synthesis finished with 0 errors, 0 critical warnings and 4479 warnings" ... "3059 Infos, 538 Warnings, 0 Critical Warnings and 0 Errors encountered."

Hmm. Now I've no idea what's going on. The IDE finished up with a monstrous regiment of red icons and text. so I thought I'd better exit the IDE and look for the most recent log. And those two runme.log were they, with no signs of the extra errors that turned up today (just those 4 place errors). That's after searching the entire /xilinx directory structure (my root of all vivado/sdk workspaces). There certainly isn't any .bit file, before you ask. Looking at the list of files in reverse timestamp order you'd not have any clue that anything's amiss. I suppose I'd better restart viv and go into the project again, just to see what's what.

Well then, on opening up, the redness is much diminished. Top right toolbar status "place_design ERROR", centre right Implementation pane (!) Failed, and (!) 4 errors [presumably the same 4 place errors as Saturday's], large bottom Design Runs panel - (Design Runs tab) - green tick against synth_1 but red bang against its child impl_1. On examination of that panel's Reports tab (where there was a boatload of bloody decks before) it is now mostly quietly light gray and disabled. It's as if this morning never happened. So I can't show you anything of the horrors I just witnessed! (The system.bsd file, btw, is now timestamped today).

The only thing I can think of doing is a complete cleanup of the BSD project and starting from scratch with the clocky reconnectings. But I'll forbear from that in case you can think of a file you know about which might be more informative.

Edited by lemoutan
forgot to confirm that I reset the output products

Share this post


Link to post
Share on other sites
  • 0

Honestly starting over would be my next step. Your diagram looks exactly like mine upon inspection. Now that you know the steps to take, it would be a relatively quick process and if the errors are still stemming from the shield I/O pins, then the project may just be broken. (I wish I could explain more but the software just isn't perfect) The process should look something like

1.) Exit Vivado and run the cleanup script in the project folder. 

2.) Rebuild the project by calling the create_project.tcl in Vivado 2015.3

3.) Change the clocking nets that we discussed. 

4.) Build the project and hope for a success!

I'm going to go ahead and try to port this to 2015.4 and fix the clocking issues to try to update the project so if that doesn't work hold tight and that hopefully comes out today or tomorrow. But that isn't quite the learning experience you are looking for so I'll try to document any problems I run into.

- Sam

Share this post


Link to post
Share on other sites
  • 0

New 2015.4 project is on the wiki/github now. I didn't run into any problems upgrading it at all. Basically opened the project in 2015.4, upgraded all the IPs and everything built correctly. I still don't know where your critical errors are coming from though. Hopefully starting from scratch will help you out.

Share this post


Link to post
Share on other sites
  • 0

Do you have a link for that? I can't see anything of yours at https://github.com/Digilent/Arty more recent than four months ago.

(Just so you know - I'm going there not because that's where I'm expecting it to be, but only because it seemed like clicking the 'documentation' link at the top of this page might be the quickest way to find arty resources since I forgot where I originally DLd 'em from).

Thanks, btw.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now