Basys3 Xilinx University Lab 3 - No led's

[FlyingBlindOnARocketCycle]

Hello

I am on Lab 3 of this material 2015.  In lab 2 I could not program the Basys3 so I installed Vivado 2016.1 which solved that problem.  Now on lab 3, everything is progressing word per word along with the lab until section 4 "Verify the Functionality"  I am using PuTTY as my terminal emulator.  My setting are 115200 8 bit, 1 stop bit, no parity, no flow control. Per the Windows7 device manager, I am using COM1. "USB Serial Port (COM1)" My only other used com port is Intel(R) Active Management Technology - SOL (COM2). Just to check I did try COM2 which PuTTY could not connect to.

I get no LED out put at all from this design.  The only response from the Basys3 is the TX LED (LD18) does pulse once per key stroke on my keyboard.

The unit is powered and programed from the micro USB.

The Lab1 from this workshop material does function properly.

Thanks

[FlyingBlindOnARocketCycle]

Hi D@n

My XDC files are provided/modified as part of the lab.  Added as two separate sources.

File #1 uart_led_pins_basys3.xdc

# Basys3 xdc
# LED [7:0]
############################
# On-board led             #
############################
set_property -dict {PACKAGE_PIN U16 IOSTANDARD LVCMOS33} [get_ports {led_pins[0]}]
set_property -dict {PACKAGE_PIN E19 IOSTANDARD LVCMOS33} [get_ports {led_pins[1]}]
set_property -dict {PACKAGE_PIN U19 IOSTANDARD LVCMOS33} [get_ports {led_pins[2]}]
set_property -dict {PACKAGE_PIN V19 IOSTANDARD LVCMOS33} [get_ports {led_pins[3]}]
set_property -dict {PACKAGE_PIN W18 IOSTANDARD LVCMOS33} [get_ports {led_pins[4]}]
set_property -dict {PACKAGE_PIN U15 IOSTANDARD LVCMOS33} [get_ports {led_pins[5]}]
set_property -dict {PACKAGE_PIN U14 IOSTANDARD LVCMOS33} [get_ports {led_pins[6]}]
set_property -dict {PACKAGE_PIN V14 IOSTANDARD LVCMOS33} [get_ports {led_pins[7]}]

# CLK source 100 MHz
set_property -dict {PACKAGE_PIN W5 IOSTANDARD LVCMOS33} [get_ports clk_pin]

# BTNU
set_property -dict {PACKAGE_PIN T18 IOSTANDARD LVCMOS33} [get_ports btn_pin]

# RXD UART
set_property -dict {PACKAGE_PIN B18 IOSTANDARD LVCMOS33} [get_ports rxd_pin]

# Reset - BTNC
set_property -dict {PACKAGE_PIN U18 IOSTANDARD LVCMOS33} [get_ports rst_pin]

File #2 uart_led_timing.xdc

# Artix7 xdc
# define clock and period
create_clock -period 10.000 -name clk_pin -waveform {0.000 5.000} [get_ports clk_pin]

# Create a virual clock for IO constraints
create_clock -period 10.000 -name virtual_clock -waveform {0.000 5.000}

# input delay
set_input_delay -clock clk_pin 0.000 [get_ports rxd_pin]
set_input_delay -clock clk_pin -min -0.500 [get_ports rxd_pin]

set_input_delay -clock virtual_clock -max 0.000 [get_ports btn_pin]
set_input_delay -clock virtual_clock -min -0.500 [get_ports btn_pin]

#output delay
set_output_delay -clock virtual_clock -2.000 [get_ports {led_pins[*]}]

 

If the CFGBVS and CONFIG_VOLTAGE properties are supposed to be set somewhere in this project, and according to the error they aren't, it doesn't appear they are set in the XDC's.  They doesn't appear to be set in the basys3_Master.xdc.  Where do I set these?

The reset input goes to a buffer and then a "meta_harden" module that does the two flip-flop stability trick. (I need to study that someday to fully understand why that works)  The reset meta_harden, and everything else,  is clocked with the single clk_in. 

The memory stick thing should be easy enough to try.  The basys3 reference manual has instructions for that and it looks pretty simple. load a bit file on a formatted thumb drive. move a shut block. power-up.  If my issue does turn out to be something with my pc/usd/serial/jtag drivers, loading the bit file to a thumb drive might bypass all that.

Since jpeyron was able to run this lab with success, I am wondering if the design is good and Im screwing up something more along the lines of a system setup kind of thing... not sure what that would be though.  Maybe jpeyron will get back with what version of vivado was used when he/she (sorry jpeyron Its hard to tell if someone is a Mr. or Mrs. from a screen name) successfully ran this HDL?

I ran the labs for like the 8th time last night and spent a bit of time making sure my pc drivers and PuTTY were good.  I still need to dig in with an LED set like a breakpoint marker as you suggested.  The project is small enough that synth and impl don't take that long so that suggestion as a lot of possibility.

Thanks D@n and jpeyron for beating this dead horse with me.  Everyone has busy lives and helping a stranger figure out what they have screwed up is a thankless job... except for the fact that I'm saying thank you.  

 

[FlyingBlindOnARocketCycle]

It is functioning in 2015.4 also.  Odd about the problems with 2016.1.  There appear to be problems with usb/serial driver and 2016.1 also.  I seem to be able to have multiple version of Vivado installed and can open the version I need. 

Thanks a lot for all the effort to this issue.

[jpeyron]

Hello FlyingBlindOnARocketCycle,

We were not able to pin point why the project will work on version 2015.2 but not on 2016.1. 

thank you,

Jon

[FlyingBlindOnARocketCycle]

Have you guys made any headway into identifying the issue with this lab?

[FlyingBlindOnARocketCycle]

Well I'm glad that it might not be me...Crazy how different things are behaving from one rev of vivado to the next.  I guess a 2016 version of the labs may be in order if this material is to be used for live classes.

Thanks for looking into it. 

[jpeyron]

Hello FlyingBlindOnARocketCycle and Dan,

When I went through the labs on tuesday with vivado 2016.1 I did not fix the CFGBVS or CONFIG_VOLTAGE warnings. I just programed the Basys 3 and typed into tera term and it worked. So this morning I re-ran my project and i does not work.  A colleague and I were able to go through the labs and it worked in Vivado 2015.2. I am looking into getting the lab to work in 2016.1.  

thank you,

Jon

[FlyingBlindOnARocketCycle]

I have working late these days and not yet had a chance to revisit my Lab 3 woes.  Sorry to slack off. 

I can not use terra term.  There is a list of reasons that have nothing to do with this effort but I am stuck with PuTTY whether I like it or not.  I do get the screen data using PuTTY when the Basys3 boots the self test from the SPI.  So at least that much of my chain is functional.

jpeyron, what part do you use when setting up your project?  Do you use the part or the Digilent board.  I down loaded the board data from Digilent and have been using that.  I'm just truing to think of some small insignificant step I'm missing that has turned out to be not so insignificant after all.  If I ever get a break I'll try some of D@n's suggestions and get a project going that does something very simple but required uart input and see that happens.

Also, jpeyron did you happen to check the date/time on the downloaded lab files I'm using?  Do those match yours?

Cheers

[D@n]

4 hours ago, jpeyron said:

Hello FlyingBlindOnARocketCycle and Dan,

here are my .xdc files.

I believe they are exacly what you posted earlier. Have you tried using a different serial termial like Tera Term? 

thank you,

Jon

uart_led_timing.xdc

uart_led_pins_basys3.xdc

Ok, now I'm confused.  Neither of those files have any of the extra lines I presented earlier.

jpeyron,

Do you get any of the CFGBVS or CONFIG_VOLTAGE warnings that FlyingBlind... has been getting while using those .xdc files?

Dan

[jpeyron]

Hello FlyingBlindOnARocketCycle and Dan,

here are my .xdc files.

I believe they are exacly what you posted earlier. Have you tried using a different serial termial like Tera Term? 

thank you,

Jon

uart_led_timing.xdc

uart_led_pins_basys3.xdc

[D@n]

Hmm ... I don't get it.  My .xdc file has some additional lines, and I don't see them in the Basys3 master .xdc file.  ?? At any rate, here's what I have at the top of my Basys3.xdc file:

# Config setup
set_property CFGBVS VCCO [current_design]
set_property CONFIG_VOLTAGE 3.3 [current_design]

## Clock signal
set_property PACKAGE_PIN W5 [get_ports i_clk_100mhz]
set_property IOSTANDARD LVCMOS33 [get_ports i_clk_100mhz]
create_clock -period 10.000 -name sys_clk_pin -waveform {0.000 5.000} -add [get_ports i_clk_100mhz]

After that it gets into particular I/O pins, and I've just about renamed each and every one ... so I really don't think you want to read all of those.  Here's one example, though, so you can see how an I/O pin might look:

# Switches
set_property PACKAGE_PIN V17 [get_ports {i_sw[0]}]
set_property IOSTANDARD LVCMOS33 [get_ports {i_sw[0]}]
set_property PACKAGE_PIN V16 [get_ports {i_sw[1]}]
set_property IOSTANDARD LVCMOS33 [get_ports {i_sw[1]}]

Then at the bottom, I've got these lines:

set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]
set_property BITSTREAM.CONFIG.CONFIGRATE 33 [current_design]
set_property CONFIG_MODE SPIx1 [current_design]

 

You'll probably want a CONFIG_MODE of SPIx4 in your design.  I've been trying to recover my flash ever since a user program running within my configuration got wild on me and started writing random things to the flash configuration registers, so CONFIG_MODE of SPIx1 in my design is my attempt to recover from that.  (Writing to the 0 address now produces a bus error--it used to be one of my memory mapped peripheral addresses.  I think I might have learned something in the process ...)

Your description of your reset signal sounds good.  You'll find there are some good metastability references on the web that'll show up following a Google search.

I would certainly like to hear from jpeyron what his .xdc files looked like.  That might be useful.

Hopefully this gets you one step closer, and two steps closer to no longer flying blind.

Dan

[D@n]

Okay, let's keep going here ... I have both the CFGBVS and CONFIG_VOLTAGE properties set within my .xdc file.  The first is set to VCC0, and the second to 3.3.  I'm going to guess these are important, but I've never changed them.  Your pins should also be configured for LVCMOS33 (3.3 Volts).  Hopefully you got your .xdc file from the Basys support page and only commented out the pins you were using and/or renamed the pins you were using ... if not, you might wish to go back to that original and only make the minor adjustments needed.

Your timing error also concerns me.  I have always managed to get rid of timing errors in all of my designs, so you might wish to look into that one.  Do you need an external reset for your design?  Further, if you do, have you double registered it to get rid of any metastability problems before using it?  You do have it clocked before it goes into your design, right?  Asynchronous resets have all kinds of timing problems associated with them.

As for the debug hub error ... I don't know what to make of it.  If your design loads, than you may wish to worry about it later.  You might try loading your design from a memory stick until you've resolved this error.  For more information, Google this on Xilinx's web site--they have a discussion of it there.

I'm still of the opinion that you shouldn't be flying blind.  Can't you get an LED to give you some information?  1) Is the UART input pin fixed logic high or logic low?  (It should be neither.  The voltage should change when you send a character across the UART interface.  Failing this test means the pins aren't set up right in your design, either mis-routed, at the wrong voltage or ... some such)  2) When it transitions to low, does it return to fixed logic high within the right number of clocks?  (About 8680 clocks for a UART running at 115200 Baud, with one stop bit.  Failing this test would mean the baud isn't set right.)  3) Does your UART receiver ever receive any characters at all?  (This is useful if the previous two tests pass.  Failing this could mean a host of things, but if the previous two tests pass it becmoes a logic test.)  Each of these three tests is easily tested with an LED: Set the LED on the event, clear it some number of clocks (200M+) later.

Dan

[FlyingBlindOnARocketCycle]

Well lets talk about this.  I've gone through lab 2 and 3 to completion several times now and you and I are doing something different.  What is it?  I had to upgrade my Vivado install to version 2016.1 to get the Basys3 to program with the micro USB. (I discovered that on lab 1) I attached a screen shot of my source files/folder for this lab.  Maybe your source material has a different date than mine?

1. When writing the bitstream I get this warning but maybe that's not a big deal.

WARNING: [Labtools 27-3123] The debug hub core was not detected at User Scan Chain 1 or 3.
Resolution:

2. I have a DRC error.

CFGBVS #1 Neither the CFGBVS nor CONFIG_VOLTAGE voltage property is set in the current_design.  Configuration bank voltage select (CFGBVS) must be set to VCCO or GND, and CONFIG_VOLTAGE must be set to the correct configuration voltage, in order to determine the I/O voltage support for the pins in bank 0.  It is suggested to specify these either using the 'Edit Device Properties' function in the GUI or directly in the XDC file using the following syntax:

 set_property CFGBVS value1 [current_design]
 #where value1 is either VCCO or GND

 set_property CONFIG_VOLTAGE value2 [current_design]
 #where value2 is the voltage provided to configuration bank 0

Refer to the device configuration user guide for more information.

3. I having a timing error on the rst pin claiming no input delay.  I attached a screen shot of that also.

 

PS

I receive data on a PuTTY window when running the Digilent factory self test load.

 

Are any of these issues the smoking gun?

In my defense I am flying blind on a rocket cycle.

[jpeyron]

Hello FlyingBlindOnARocketCycle,

I went through lab 2 and 3 to completion. Make sure you follow the lab by changing the virtual clock to 10ns under the Synthesized Design as well as the output Delay to -2ns under edit timing constraints in the implemented Design. These changes allow the design to meet timing otherwise it wont work when programed. I used Tera Term but PuTTY should be just fine.

thank you,

Jon

[D@n]

Yeah, for some reason I don't trust other people's code either.

Here's a shocker, would you believe I've never used ModelSim?  

I'll look forward to hearing how well you do next.

Dan

[FlyingBlindOnARocketCycle]

Roger that Dan.  I'll work on your suggestion #1 tonight.  I'm new to this so its gonna take me a while, but I'll report back. 

On a side note, I do have ModelSim which would be much easier and faster for trouble shooting the design but as this project is one that I downloaded from Xilinx, Im not sure about how to go about running it.  I might work on a ModelSim test bench for this just to verify the project. 

Can you tell that I don't trust the downloaded sample project that comes with the tutorial?  

Thanks for the help!

[D@n]

Okay, I just checked my basys-3 board: I've also got B18 marked as being an RX input from the UART controller.  So that's not your problem.

1. Can you check whether or not anything is ever passing over the UART? Something like if the receive port is ever zero, then set an LED and start a counter.  When the counter gets to its maximum value, turn the LED off ...  This would help to debug whether or not you have your terminal set up properly.  (Oh, I almost forgot to ask--did you turn hardware flow control off?  I had that problem getting my UART going initially ...)

2. Can you check whether or not you receive characters at all from the UART?  Sort of like I described above, if you receive a character then set an LED?

3. Can you then check whether or not you are receiving the character that you think you should be sending, the one that is supposed to make some action?

Yours,

Dan

[FlyingBlindOnARocketCycle]

Thank you for the suggestions.  I did not mention that I had also completed lab 1 in that Xilinx University lab packet I linked to.  That lab uses led's and proved to me that I do not have a faulty Basys3.  It also shows me that I can program the units via the USB/JTAG port.  I would find it odd that the TX and RX would be reversed on a Xilinx/Digilent partnered workshop but I guess it could be bad VHDL.  Although I do get the TX light flashing with each key press and the Digilent documentation on the Basys3 says that the TX and RX are from the point-of-view of the PC.  That would indicate the TX is .... well it would indicate that its wired correctly on the board but not that the VHDL uses it correctly as a receive to the FPGA.  Hmmm I'll have to check that.  I wonder if anyone on this forum would be willing to down load the Basys3 project files and workshop material from Xilinx and see if they also have a problem with lab 3?

I just checked and the VHDL or actually the XDC does call out B18 as the rx pin.  And I keep saying VHDL but the lab is actually all in Verilog.

Thanks

[D@n]

Well, let's work through this:

1. Can you build a design that does nothing but turn the LED's on?  Can you build a similar design that does nothing but turn the LED's off?  If so, then the LED's work, your build process works, and you can load designs to the board still.

2. I have been very successful loading the Basys3 board from a USB stick.  In fact, I've never tried loading it from the JTAG port at all.  Have you tried loading your .bit file onto a USB stick, setting the jumper appropriately, and then restarting the Basys3?  Still, you mentioned that you could load the Basys3 board, so I'll move on and assume this isn't your problem.

3. I have often used LED's on the Basys3 board as a means of telling me what has happened on the board.  This works as in setting an initial value for some register, and then an always block tests whether the condition is true, and if so it sets the register to a different value.  Then you use the register value to drive the LED.  You can often use this technique to narrow down where a fault is happening in your design.  Sure, the method is slow, but it has always been reliable for me.  (Event A happened, cause LED0 turned on, but not event B that was supposed to happen next since LED1 has stayed off.  What part of my logic between A and B is broken, etc.)

4. If you're still stuck, here are some events to look for: Look for the RX data line being high regularly.  Look for it going low, but for no longer than 10 baud periods.  (If it goes low longer, your baud rate is set wrong, etc.)  Also, always be aware of mis-setting the RX and TX lines--I always get confused which those are with respect to, etc.  (If one setting doesn't work ... consider trying the other!)

Hope this helps,

Dan