Arty GPIO demo UART communication

[ColoradoAnalog]

I just got an Arty board and have been going through the demo at https://reference.digilentinc.com/arty:gpio  I made it to section 4.2 and now I am stuck. I downloaded Realterm and installed it but am not seeing any results. Do you have more specific instructions about the required settings to get the terminal window to show the messages that are supposed to happen? Are there settings that need to be changed from the defaults other than the ones listed in the demo instructions? Under the Port tab what should the Port setting be?  Do any of the other settings matter?

Thank you

[lemoutan]

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.

[lemoutan]

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

[sLowe]

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

 

[lemoutan]

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.

[sLowe]

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

[lemoutan]

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.

[sLowe]

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

[sLowe]

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.

[lemoutan]

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!

[sLowe]

oops I never synced with github.... That is absolutely where you should look for it. The updated project should be up now.

[lemoutan]

OK. Scrubbed my arty-master root and replaced with your new set. Also noticed that the board-files had changed after re-downloading and checking with winmerge, so plonked them into the relevant data folders under the xilinx software root. I then proceeded in an orderly manner to build the GPIO project first and all went well, up to and including das blinkenlights and uart pushbutton check.

Then I go for the next on the list, the XADC_Demo. All seems to go well, but I notice - next to open target - a hottie labelled something like IP core change, which I thought I'd better check out by clicking. Seems I might need to do some sort of upgrade but the IP is 'locked' and I am presented with this here popup - whim I'm not sure how to appropriately respond to. So I cancel it (top right redcross-dismisswise), with a view to halting until advised. But the IDE goes ahead anyway and does lots of stuff and ends up reporting

Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.
--------------------------------------------------------------------------------------
| Tool Version : Vivado v.2015.4.2 (win64) Build 1494164 Fri Feb 26 04:18:56 MST 2016
| Date         : Wed May 18 23:12:51 2016
| Host         : kahontsi running 64-bit Service Pack 1  (build 7601)
| Command      : upgrade_ip
| Device       : xc7a35ticsg324-1L
--------------------------------------------------------------------------------------

Upgrade Log for IP 'xadc_wiz_0'

1. Summary
----------

CAUTION (success, with warnings) in the upgrade of xadc_wiz_0 from xilinx.com:ip:xadc_wiz:3.0 (Rev. 7) to xilinx.com:ip:xadc_wiz:3.2

After upgrade, an IP may have parameter differences compared to the original customization. Please review the parameters within the IP customization GUI to ensure proper functionality.

2. Upgrade messages
-------------------

WARNING: upgrade cannot add parameter WAVEFORM_TYPE with default value CONSTANT : a parameter called WAVEFORM_TYPE already exists in xadc_wiz_v3_2
WARNING: upgrade cannot add parameter STIMULUS_FREQ with default value 1.0 : a parameter called STIMULUS_FREQ already exists in xadc_wiz_v3_2
WARNING: upgrade cannot add parameter NUM_WAVE with default value 1 : a parameter called NUM_WAVE already exists in xadc_wiz_v3_2
WARNING: upgrade cannot add parameter EXTERNAL_MUXADDR_ENABLE with default value false : a parameter called EXTERNAL_MUXADDR_ENABLE already exists in xadc_wiz_v3_2
WARNING: upgrade cannot add parameter ENABLE_AXI4STREAM with default value false : a parameter called ENABLE_AXI4STREAM already exists in xadc_wiz_v3_2
WARNING: upgrade cannot add parameter FIFO_DEPTH with default value 7 : a parameter called FIFO_DEPTH already exists in xadc_wiz_v3_2
WARNING: there are only case-insensitive matches ENABLE_CONVST for parameter Enable_CONVST
WARNING: there are only case-insensitive matches ENABLE_CONVSTCLK for parameter Enable_CONVSTCLK
Renamed parameter INTERFACE_SELECTION (instead of Interface_Selection) to INTERFACE_SELECTION
Renamed parameter SIM_FILE_NAME (instead of Sim_File_Name) to SIM_FILE_NAME
Renamed parameter TIMING_MODE (instead of Timing_Mode) to TIMING_MODE

-- lots more of similar nature - about 400 lines - and ending up with:


Upgrade Log for IP 'xadc_wiz_0'

1. Summary
----------

SUCCESS in the upgrade of xadc_wiz_0 (xilinx.com:ip:xadc_wiz:3.0) from (Rev. 4) to (Rev. 6)

The XADC_demo bitstream appeared to be generated regardless, so - living dangerously - I decided to prog the board regardless of the above, It all looked as if it worked, stepping up the leds as I twiddled a potentiometer.

So I'm not sure what happened there or whether it's 'safe' to proceed to the final BSD project in the triplet. But I might as well build and see what happens, so ...

During the project build, I get the heebie-jeebies with some intermittent chunks of orange text turning up:

WARNING: [BD 41-176] The physical port 'di' specified in the portmap, is not found on the block! 
WARNING: [BD 41-176] The physical port 'di' specified in the portmap, is not found on the block!

WARNING: [Vivado 12-3482] The generated wrapper file has already been imported into the project, the imported file is:
'/xilinx/Arty-master/Projects/BSD/proj/bsd.srcs/sources_1/imports/hdl/system_wrapper.vhd'

But at some point I inadvertently mouseclicked and lost my place in that message stream and couldn't find it again. There was some warning about a script having been created in viv 2013.1. Now I saw that before, about a month ago, and it seemed to be bad news. But never mind. The microblaze clock/rst bits appear to have moved to the new model, so that's something. I shall now attempt to generate the bitstream, despite those many bits of warningage.

BTW - in the wiki it states:

• Vivado Design Suite 2015.4
  • You must use this version or the project will not generate

Presumably it'll also now be OK in 2016.1 and later though?

OK, So it got all the way to writing a bitstream entirely without further incident. Off to the sdk then.

 

Ah. Screeched to a grinding halt. The 'import projects' dialog in the sdk is yellow-bang-triangly headered with a warning that "Some projects cannot be imported because they already exist in the workspace". Perhaps this is not too surprising but neither vivado nor sdk is software written by me so I don't have any confidence about how to safely remove traces of former imports. Not that I can see anything obviously removable in any case. What's the 'official' way to delete old projects from the sdk's workspace without inadvertently destroying any potential metafile/folder integrity the sdk workspace management might be relying upon? I've long gotten out of the habit of just blithely deleting files or folders and finding out later that some 'system database' is thereby up-buggered. The SDK.log file was last updated on the 12th. And before you ask, I could not have 'just ignore[d] any warnings' and clicked 'finish' - as per wiki advice - since the finish button was disabled.

 

Almost there!

[sLowe]

First off that upgrade message doesn't really involve you that much. Xilinx decided to improve their packaging of the IP's. They will work the same regardless but the new format may be more compliant with future tools and may be smaller in size. That change just happened and the transition is still happening. So who knows maybe it could cause problems. 

Those other warnings don't raise any flags with me since I don't believe any of those signals are used explicitly in the design. The BSD wiki is correct, the current project will only build with 15.4 now. Since so many IP's change, there isn't really a good way of making projects span multiple versions short of writing everything in HDL. To go to 2016.1, someone will need to go through the same process I went through to upgrade it to 15.4. Although we usually try to only keep our designs updated to the latest even release so that will most likely happen when 16.2 comes out.

To delete the work space, it is safe to exit SDK then delete the .sdk folder in \Arty\Projects\BSD\proj. (not the sdk folder located at Arty\Projects\BSD. ) I would do this, then export your hardware from vivado. File->export hardware. check "include bitstream" then launch SDK from vivado.  (local to folder) Launch SDK can be found in the file tab as well. 

Once in SDK you should see your hardware platform. Click file->new->application project. Name your project, then click next. Select hello world then click finish. 

Here is your basic program. This should be able to run and print out "hello world" just fine and where in the future you can create new projects from scratch!

To run the faux arduino bsd demo delete all the files located in the src folder and copy over everything from the src folder of the  Arty/projects/bsd/sdk/user into the src folder of your project. Your new generated BSP and hardware platform should be the same as the ones in the sdk folder so you don't really need these.  This code should run now and you can play around with digital I/O reads and writes. Just be sure to look at the digital.c library for how conventional xilinx projects do GPIO. I'm sure I missed a step so we will see how far you get.

The programming flow is click xilinx tools->program fpga, then click into your main C file and click run on system debugger. Good luck! I'm sure I missed a step somewhere.

[lemoutan]

9 hours ago, sLowe said:

To go to 2016.1, someone will need to go through the same process I went through to upgrade it to 15.4. Although we usually try to only keep our designs updated to the latest even release so that will most likely happen when 16.2 comes out.

That comes across to me (as someone with no investment in the IDE) as pretty much having to come up with a new IDE every time some new hardware is released. I'm imagining that vivado, whilst possibly an improvement over the previous ISE with respect to this kind of updatability/scalability, is still seriously short of being future-proof. However, I guess it's easy to criticise from the sidelines. Anyway, that's by the way.

As for the sdk issues, I'm a bit confused by your solution above. I was following the project flow as described in the wiki writeup where I'd done 4.1 and 4.2 (thus omitting all of 5, which was ok as I already had a workspace rooted at /xilinx/sdkws2015.4/), 6.1, 6.2 and got stuck at 6.3. Like I said, I'd completely scrubbed the arty-master project folder root (with child GPIO, XADC_Demo and BSD projects) and so don't understand how anything there - perforce created after anything in that workspace - could possibly 'contaminate' the sdk's workspace management. So how can removal of the (in my case) /xilinx/Arty-master/Projects/BSD/proj/bsd.sdk (I presume you mean bsd.sdk when you say 'delete the .sdk folder') mollify the SDK? It's surely just going to get recreated again at vivado's 'Export SDK' time to be there ready for the sdk to use?

Ah - maybe I see what you're getting at with your instruction to create a new app via the 'hello world' route rather than follow the aforementioned 6.2 and 6.3 instructs (i.e. import existing). BTW I'm just writing this as a 'real time' narrative here. OK - I can see how that might work (though I'd rather properly excoriate the old stuff from under sdkws2015.4 and re-invent history - but perhaps that interferes with or upsets webtalk?). Tum-ti-tum ... I'll call it bsd1, it's using OS Platform standalone, Hardware Platform system_wrapper_hw_platform_0, processor microblaze_0, Target softlang C (32bit) and board support package 'create new bsd1_bsp. Umm, do I really want to do that? Where's the 'hello world' app? Use existing is disabled, so it's my only choice. Oh well ... Finish ... Stuff happens. Stops. There's a bsd1 branch as well as a bsd1_bsp. 

I can't see any "hello world" being printed anywhere and seem unable to debug this at source level. I'm getting assembly language here. Whilst my previous experience goes back to programming the old 6502 I'm not sure I want to be doing that any more! Maybe I'll just skip all this and try to do your BSD thing ...

Oh good grief it's just dawned on me - the SDK workspace originally set up last month is quite irrelevant here isn't it? Of course there's nothing there to remove. It's all being done under that bsd.sdk folder. But in that case why on earth - last time - did the sdk 'think' there was an older project with the same name 'in the way'? I'd completely scrubbed that entire arty-master tree! I don't understand what's going on here. The sdk workspace idea is past its sell-by date?

Never mind. Let's do what you say and replace all that helloworld.c stuff (under /xilinx/Arty-master/Projects/BSD/proj/bsd.sdk/bsd1/src) with stuff from /xilinx/Arty-master/Projects/BSD/sdk/bsd/src (I'm guessing a bit here since there's no  Arty[-master]/projects/bsd/sdk/user as such). These sources are a core folder and three files - lscript.ld, sketch.[ch] - which indeed look like arduino blinkiness. Here's hoping I can debug at source level ...

OK, I seem to be in the middle of some actual C here and have just stepped over a "print("Starting...\n\r");" but in the myriad of panes and tabs I cannot for the life of me see any of them showing a "Starting...". Has that happened exclusively on the UART? I thought the uart - in the sdk - could be rerouted to some sdk console (but perhaps that doesn't happen by default). ANYway ..., let's step into setup. OK, so far so good. Now for (tada ...) loop(). Stepover the digitalWrite(PIN_LED0, HIGH); and a led on the board lights. Well, whaddya know? ... And I can even step into digitalWrite etc.

I'm still not sure about the 'workflow' and the 'what's going on' in these IDEs y'know. I'm going to have to digest all this.

Gazes at blinking led ...

Thanks again.

 

 

[sLowe]

No problem! I think you are over the biggest hump and will slowly become familiar with the tools. To see the UART I usually use a third party serial program. I use real term but a ton of people seem to like tera term. You can see it in sdk if you select run as->launch on hardware (GDB) then click the run menu-> run configurations. Select GDB, then go to the STDIO Connection then check "Connect STIO to Console" then select the serial port and Baud rate which I believe is 9600 for this application.  This will put you UART in the console window at the bottom of sdk.

Glad to help!

[Rockiesmike]

On 4/5/2016 at 1:15 PM, JColvin said:

Hi ColoradoAnalog,

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

Thanks,
JColvin

Hi JColvin,

Are and where are the latest demo projects updates located in Digilent?  I have Speedway Sept 2015 version 1015.2r1 for the Arty board and would like to have access to the latest version.

Thanks

Mike

[jpeyron]

Hi Mike,

Here is the link to our Github where our most recent demos are. Here is a link to our resources page for the Arty.

cheers,

Jon

[sLowe]

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

 

 

[sLowe]

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

 

[lemoutan]

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

[lemoutan]

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?

[lemoutan]

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?

[sLowe]

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

[lemoutan]

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?

 

[sLowe]

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

[lemoutan]

The unbearable redness of 'open implemented design':

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