• Content Count

  • Joined

  • Last visited

  • Days Won


gwideman last won the day on November 23 2018

gwideman had the most liked content!

About gwideman

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. One thing I realized in the course of mulling this question: Part of my early resistance to splitting pio[...] into pioA, pioB and pioC was that I wanted to implement a bus that would span those ranges, and had a mental block about how to achieve that. It's not very difficult, but in case someone else has the same hiccup, I'll post an example solution here: module top( input sysclck, output [1:0] led, input [14:1] pioA, input [23:17] pioB, input [48:26] pioC ); wire [8:1] mybus; assign mybus[4:1] = pioA[14:11]; assign mybus[8:5] = pioB[20:17]; assign led[0] = &mybus; assign led[1] = &pioA[10:1]; endmodule I should note in passing that the supplied xdc file has another problem. In the supplied xdc file, pio[1]..pio[9] are written as pio[01]..pio[09], as in: set_property -dict { PACKAGE_PIN M3 IOSTANDARD LVCMOS33 } [get_ports { pio[01] }]; #IO_L8N_T1_AD14N_35 Sch=pio[01] The xdc file is a TCL language file, and it may not be evident what the { pio[01] } actually means. It looks like it would be an array pio, with index 01, which one might assume is an integer, and thus equivalent to plain 1. In fact, the {...} is syntax to enclose a string, which is not to be interpolated (no substitutions made). So the result of { pio[01] } is the string: " pio[01] " ... including the spaces! In short, the string " pio[01] " is used verbatim as a string key for some array/hashtable/dictionary. It does not imply that there's an array called "pio", from which this code fetches the item at index 1. But then how does this match up to a particular port object declared in module top's declaration (where pio[14:1] treats the numbers in the index range as integers). There is some mechanism in get_ports or somewhere that must match this string index ("key") to top's port declaration. So the {...} string as written in the xdc file has to follow the pattern that the matching algorithm uses, which pio[01] does not, apparently. Consequently, xdc's pio[01] fails to match top.v's pio[1], etc. (And Vivado will give some obtuse error message about "Unspecified I/O Standard", and fails to generate bitstream.) Instead, you have to edit the xdc file for all the cases where pio[xx] has a leading zero, and remove it. So, for example, { pio[01] } should be edited to { pio[1] }. This does satisfy the matching algorithm. For further illumination on this syntax, you might like to try the following code: set result A append result { pioA[01] } append result B puts $result ... at an online TCL interpreter, like: This prints a result "A pioA[01] B", demonstrating that the action of the {...} syntax used in the xdc file is simply to produce a string, which is used verbatim as an argument to get_ports.
  2. Hi @xc6lx45, Yeah, I ended up renaming and renumbering as well. I just figured if the xdc was supplied written as a discontinuous array, there must be some way to use it as such. Graham
  3. On Cmod A7, the xdc file lists pio[1] to pio[48], but there are gaps at 15,16 (which are instead analog input pins) and 24,25 (which don't exist). So when I create a Verilog top module that uses pio, how to I specify these discontinuous ranges? Conceptually I want: module top ( input sysclk, output [1:14, 17:23, 26:48] ) but obviously that's not valid syntax. So how DO you use the full set of pio's as written in the xdc file? The file in question:
  4. Thanks @xc6lx45, for providing a very thoughtful answer.
  5. I chose 6 cpus, but it only appears to use 1 to 2 as I mentioned, and 8G RAM in the system. The board is the Cmod A7 Artix 7-35. The project is about as minimal as you can get and still have it do something observable. Well I supposed it could be reduced to a 1-bit counter with 1 output. But I wanted it to be visible on LEDs. :-).
  6. Hi folks. Could someone give me a reality check on how fast the Vivado tool chain is expected to run? I mean the entire Synthesis, Implementation, Generate Bitstream sequence. Here's what I get on a simple "hello world" design involving a single top.v with a simple 40-bit counter, sending 8 outputs to pins, no additional IP, targeting a CMod A7-35. I am using pretty much out-of-the-box settings in Vivado, so far as I am aware. If I make a minor change to top.v, then click on "Generate Bitstream", this invokes the entire chain (no surprise), which takes a total of over 3 minutes to run, using 100% of one CPU, and sometimes up to an additional 50% of another. Windows 7, on AMD Phenom 6 core CPU with 8G or RAM. There does not seem to be undue memory paging and not all that much disk activity in general, so this seems to be CPU bound. Is this normal? Or am I unwittingly asking it to go particularly slow somehow? Graham
  7. ... and not being able to stand the suspense, I just tried out my conclusions from that last post, and indeed the following settings work with no smoke. CONFIG_VOLTAGE: 3.3 CFGBVS (Configuration Bank Voltage Selection): VCC0 (selects high range of I/O voltages) For what it's worth, these settings end up in the xdc file: set_property CONFIG_VOLTAGE 3.3 [current_design] set_property CFGBVS VCCO [current_design] ... and I'm not sure why they aren't part of the default xdc that Digilent supplies. It would be interesting to know if any other values are valid, given the Cmod A7's schematic. -- Graham
  8. Hi @[email protected], thanks again for your comments. I now have a sample which avoids warning messages (mostly, see below). I show it below for others who may stumble in here with the same questions. The key element for avoiding the RPBF-3 DRC warnings (as [email protected]) said) is to treat the I/Os either as unidirectional inputs or outputs (and let Vivado sort out the appropriate configuration) or to treat them explicitly as a tristate output driver plus an input buffer, using the IOBUF primitive. Below are an xdc file and module that use the former strategy. ## xdc file for demo_counter # Clock signal 12 MHz set_property -dict {PACKAGE_PIN L17 IOSTANDARD LVCMOS33} [get_ports clk] create_clock -period 83.330 -name sys_clk_pin -waveform {0.000 41.660} -add [get_ports clk] ## GPIO Pins (uncomment rows in the Digilent-provide xdc file) set_property -dict {PACKAGE_PIN M3 IOSTANDARD LVCMOS33} [get_ports {pio[1]}] [... etc to pio[8] ] # Rename ports that need to be treated differently in module arg list set_property -dict {PACKAGE_PIN A14 IOSTANDARD LVCMOS33} [get_ports enpio] # set_property -dict {PACKAGE_PIN A14 IOSTANDARD LVCMOS33} [get_ports {pio[9]}] ##-------- Set using Vivado I/O Ports panel -------- set_property DRIVE 4 [get_ports {pio[1]}] [... etc to pio[8] ] set_property SLEW SLOW [get_ports {pio[1]}] [... etc to pio[8] ] set_property PULLUP true [get_ports enpio] ##------- Set using Vivado Tools > Edit Device Properties ------- set_property CONFIG_VOLTAGE 3.3 [current_design] set_property CFGBVS VCCO [current_design] . module top (clk, pio, enpio); input clk; output [8:1] pio; input enpio; reg [31:0] counter_0 = 0; // count clock cycles reg [ 7:0] counter_1 = 0; // counter for output pins localparam MASTER_CLOCK_F = 12000000; // in hertz localparam COUNT_PER_SEC = 10; localparam MASTER_CYCLES_PER_COUNT = MASTER_CLOCK_F / COUNT_PER_SEC; assign pio[8:1] = counter_1 ; [email protected](posedge clk) begin if (enpio == 1'b1) begin if (counter_0 == MASTER_CYCLES_PER_COUNT-1) counter_0 <= 0; else counter_0 <= counter_0 + 1; end if (enpio == 1'b1 && counter_0 == MASTER_CYCLES_PER_COUNT-1) counter_1 <= counter_1 + 1; end endmodule The main point to note (with regard to avoiding RPBF-3 warnings) is that in the xdc file, the port(s) used as outputs are given a name separate from the port(s) used as inputs. This allows them to be listed and named separately in the module top (xxx) argument list, so that those arguments can separately be given attributes of either input or output. With that done, it seems there' s no need to make any other accommodations (such as the earlier-suggested assigning z to outputs or inputs). This design still produces a couple of warnings: -- "debug core was not detected" (Fair enough, I guess.) -- [Synth 8-6014] Unused sequential element counter_1_reg was removed. This one appears to be a Vivado bug: OK, I hope that helps others who want a clean starting point for exercising the Cmod A7 with Verilog and Vivado. -- Graham
  9. @[email protected] Thanks for the advice, yes I realize that the inout IOs really consist of an output, its tristate control, and its input. What I don't understand is how to explicitly or implicitly tell Vivado/Verilog how to configure that. I have modified @JColvin 's example with what I think you're suggesting (see below), but I'm still getting RPBF-3 DRC warnings on all of pio[9..1] (the 8-bit counter.output, and the 1 bit enable input.) Any further ideas? Thanks. module top (clk, pio); input clk; inout [9:1] pio; reg [31:0] counter_0 = 0; // count clock cycles reg [ 7:0] counter_1 = 0; // count seconds wire [7:0] counter_1_in; wire en; // enable the counters when asserted localparam CLOCK_FREQUENCY = 12000000; // in hertz assign pio[8:1] = 1'b1 ? counter_1: 8'bz ; // output counter #1 on GPIO 1-8 assign counter_1_in = pio[8:1]; assign en = pio[9]; // take enable as input from GPIO 9 assign pio[9] = 1'bz ; [email protected](posedge clk) begin if (en == 1'b1) //if GPIO 9 is set logic high begin if (counter_0 == CLOCK_FREQUENCY-1) counter_0 <= 0; //reset counter after F-1 else counter_0 <= counter_0 + 1; //inc counter end if (en == 1'b1 && counter_0 == CLOCK_FREQUENCY-1) // once-per-sec... counter_1 <= counter_1 + 1; // inc secs counter else counter_1 <= counter_1; end endmodule
  10. Hi folks, I'm using some very basic examples with Cmod A7, which work in the sense that they result in a behaving FPGA. However, I'm trying to get rid of, or at, least understand the various warnings. One warning that occurs for all examples I tried is: CFGBVS-1#1 Warning Missing CFGBVS and CONFIG_VOLTAGE Design Properties 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: ... OK, I see where to set them in the Tools > Edit Device Properties window, but I'm not sure what to set them to for the Cmod A7. Available values are: CONFIG_VOLTAGE: 1.5, 1.8, 2.5, 3.3 CFGBVS (Configuration Bank Voltage Selection): GND, VCC0 ... but I'm not too inclined to just experiment with different values, for fear of doing some damage. (Though somehow, the default blank settings appear to work, other than the warning message.) Questions: Do these settings set something in the FPGA configuration, or do they merely inform Vivado of the hardware's design? Does the specific wiring of this board impose/require only certain values for these items, or can alternatives be chosen? What is/are those settings, and under what circumstances do you use them? This appears to relate: Also ug470_7series_Config.pdf, "Configuration Banks Voltage Select" section. I note on the Cmod A7 schematic that: CONFIG block of IC2 (FPGA): Various xxx_0 inputs (ie: bank 0) are wired to 3.3V signals CFGBVS_0 is externally pulled up to 3.3V POWER block of IC2 shows VCCO_0 and VCCO_14 wired to 3.3V So my guess is that the settings should be: CONFIG_VOLTAGE: 3.3 CFGBVS (Configuration Bank Voltage Selection): VCC0 (selects high range of I/O voltages) I infer that these are actually fixed requirements of the Cmod A7, and if so, maybe they could be set in the board definition file or the default XDC file? Thoughts? Thanks. Graham
  11. Hi JColvin -- thanks for that project, it was helpful getting started. Especially after I realized that pin 1 is at the Pmod end, not the USB end :-). Couple of followups -- I think there might be an issue in the xdc file: set_property ... [get_ports clk] create_clock ... [get_ports sysclk] ... I think the two clock names should match. At least, Vivado gave me a warning until I changed the second one to 'clk'. Now, a question: I get warnings for all the I/Os as follows: [DRC RPBF-3] IO port buffering is incomplete: Device port pio[1] expects both input and output buffering but the buffers are incomplete. ... and same for all the other pios. Any idea what this error message is all about? I guess it's complaining that the I/O pins have INOUT capability, but this design only uses them in one direction? Google isn't coughing up anything very helpful for me. Thanks! Graham
  12. Thanks jcolvin and Dan, I will look into those projects. -- Graham
  13. Thanks for your response, but ... that's pretty disappointing. Having, before purchase, taken note of the fact that demos were available, I thought they would actually contain code showing known good examples, so we would be off-to-the-races with hardware we could exercise, and revise to use other I/Os. As a non-student customer, withholding that code subtracts value from the product -- it's just a time-wasting obstacle. As for the xadc project, it only exercises inputs, and at that analog inputs. These are not of interest at the moment. In fact it was only belatedly that I discovered that these I/Os are not direct to the FPGA, and can't be used as GPIOs (unless you remove the intervening voltage divider/filter components). Of course my complaint here is not fatal, I can probably work out what's needed from the example that runs the on-board LEDs, and examples from elsewhere for other boards. It just seems dumb that a product that in other respects is so ready to plug into a breadboard and play actually lacks examples to do so.
  14. I'm wondering where do we find the source for the Cmod A7 Stopwatch demo? One the demo's page ( I can only find links for the bit and bin files. Since this is the only one of the Cmod A7 demos that exercises the pins (as opposed to on-board features), it would be useful to have a known-good demo project to modify. Thanks!
  15. OK thanks. Yes, updating that tutorial would save a lot of time and confusion. I later noticed that Xilinx's page for 2017.2 has a bit more description relating to free WebPACK than the page for 2017.3, though it's still not clear how to invoke the free aspect. Further confusion is added by the Xilinx page you arrive at from Vivado's License Manager, as that page omits the Activation-based licenses, and the licenses it does show include a Free one for pre-2015, as though you can't license 2016 and later for free. Evidently that doesn't mean you can't use 2016 and later, it means that no license is required, and you don't need to be using the License Manager at all!