I just got a brand new shiny Au two days ago, along with an IO element and a breadboard shield, and I was going through the first couple of Tutorial examples over the weekend, which worked all fine. But I am afraid, I don’t quite understand them, or more precisely, the stuff that goes on behind the scenes. To begin with, I have no experience or knowledge in Verilog at all, and even less in Lucid - I do know some VHDL though.
Here is what I don’t understand: Who sits on top of the au_top model in Verilog and knows where to route the clk and the rst_n signals, as well as the led vector and the usb_rc and usb_tx signals to? There must be some correspondence to the physical signals on the board - where is that defined? And how would I define those if I were to try to convert the tutorials to VHDL, which I would very much like to do to gain some familiarity back? :huh: Where can I find out about these things to read up on?
Since no one else responded yet, and I think I meanwhile figured out the answers to my questions by myself, I guess I should provide my own answers here in case someone else has the same question somewhere down the road and stumbles upon this forum entry.
The answer to the first part of the question is relatively simple: In Vivado, the mapping between signal names of the top level entity or module of the design to the physical pins of the chip is handled via “constraints.” Which pins of the Artix-7 chip are used for the clock, the reset, and the USB Tx and USB Rx signals, as well as for the eight LEDs is probably best obtained all in one place from the schematics. But since Vivado uses the same constraint files for both Verilog and VHDL, the Verilog constraint file from the Au-Base-Project provided by Alchitry, i.e. the file au.xdc in Au-Base-Project/au_base_project.srcs/constrs_1/new/ can simply be imported into a Vivado VHDL project and used “as is” if the names of the signals in the port of the top VHDL entity match the ones in the Verilog top module. If not, this file is easy enough to edit to reflect different naming convention needs. For all I know, that’s all that is needed for the mapping of signal names to pins under VHDL (or Verilog for that matter) in Vivado.
Since Vivado supports mixed language projects, the “hello world” project Au-Base-Project can be ported to VHDL initially even without converting the somewhat more advanced Verilog file reset_conditioner.v to VHDL - at least in principle. Unfortunately, the choice of names for the input and output reset signal in that module is not only not overly creative, it is also conflicting with VHDL keywords, as “in” and “out” are keywords in VHDL. But once all occurrences of these names are changed to something more descriptive, say rstIn and rstOut, this Verilog module can be used in any VHDL architecture as if it were another VHDL entity.
Two more things I learned to watch out for if a VHDL (or Verilog actually) project is created from scratch in Vivado:
The Alchitry Au Artix-7 device that Vivado will ask for is xc7a35tftg256-1.
Vivado does not generate a .bin file for the Alchitry loader by default. Therefore, one has to check the “-bin_file” box in the “Bitstream” section of the “Implementation Run Properties” Window under the “Options” tab in Vivado to get this .bin file in the usual place.
If there is anything I have overlooked, please feel free to chime in and correct and/or add as needed. I am brand new to this and know next to nothing.
Also, and at least as importantly, is this a serious Alchitry forum or a spam dump site??? Could somebody please clean up all that garbage that is not related to Alchitry products and that started to creep up during all of February 2020? I find it disgusting and hugely distracting from the few serious entries (and kudos to some of the folks who posted great solutions!!!)! Is the Alchitry forum Administrator on vacation?
Of course, it is Alchitry’s forum, and they can administer it any way they see fit. But not to administer it at all, as it currently appears to be the case, can hardly be in their best interest, IMHO.