Using Vivado in tcl mode. - Page 1
Forum section: electronics / general

author: hamster_nz
author_rank: Super Contributor
timestamp: December 29, 2019, 08:07:33 am
content: I've just discovered the joy of using Vivado in 'tcl mode" or "non-project mode" to build a project where I am trying different things, and just want to find utilization and timing.In my source directory I run (well, actually just hit up arrow and hit enter):Code:(cd ../vivado; echo source build.tcl | vivado -mode tcl | tee /tmp/log)And in the ../vivado directory I have the 'build.tcl' script:Code:set_part "xc7a35tcpg236-1"# read all design filesread_vhdl ../src/sign_extender.vhdread_vhdl ../src/data_bus_mux_a.vhdread_vhdl ../src/decode.vhdread_vhdl ../src/data_bus_mux_b.vhdread_vhdl ../src/program_counter.vhdread_vhdl ../src/station_alu.vhdread_vhdl ../src/result_bus_mux.vhdread_vhdl ../src/ram.vhdread_vhdl ../src/station_test.vhdread_vhdl ../src/top_level.vhdread_vhdl ../src/riscv_cpu.vhdread_vhdl ../src/register_file.vhdread_vhdl ../src/branch_test.vhdread_vhdl ../src/station_shifter.vhdread_vhdl ../src/program_memory.vhd# read constraintsread_xdc ../src/cmod_a7.xdc# Synthesize Designsynth_design -top top_level -part "xc7a35tcpg236-1" -flatten_hierarchy none# Opt Designopt_design# Place Designplace_design# Route Designroute_designreport_timing -nworst 1report_utilization -hierarchical# Write out bitfile## write_bitstream -force my_proj.bitA million lines of stuff scrolls past, and a short while later I get the worst timing, the path details and the utilization appear in the terminal window, without having to click on anything or navigate anywhere:Code:...Timing ReportSlack (MET) : 0.174ns (required time - arrival time)Source: i_program_memory/instr_reg_reg/CLKARDCLK(rising edge-triggered cell RAMB36E1 clocked by clk_pin {rise@0.000ns fall@6.900ns period=13.800ns})Destination: i_program_memory/instr_reg_reg/RSTRAMARSTRAM(rising edge-triggered cell RAMB36E1 clocked by clk_pin {rise@0.000ns fall@6.900ns period=13.800ns})Path Group: clk_pinPath Type: Setup (Max at Slow Process Corner)Requirement: 13.800ns (clk_pin rise@13.800ns - clk_pin rise@0.000ns)Data Path Delay: 13.231ns (logic 6.302ns (47.629%) route 6.929ns (52.371%))Logic Levels: 18 (CARRY4=9 LUT2=2 LUT4=1 LUT5=1 LUT6=4 RAMD32=1)Clock Path Skew: 0.000ns (DCD - SCD + CPR)Destination Clock Delay (DCD): 4.848ns = ( 18.648 - 13.800 )Source Clock Delay (SCD): 5.145nsClock Pessimism Removal (CPR): 0.297nsClock Uncertainty: 0.035ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PETotal System Jitter (TSJ): 0.071nsTotal Input Jitter (TIJ): 0.000nsDiscrete Jitter (DJ): 0.000nsPhase Error (PE): 0.000nsLocation Delay type Incr(ns) Path(ns) Netlist Resource(s)------------------------------------------------------------------- -------------------(clock clk_pin rise edge) 0.000 0.000 rL17 0.000 0.000 r clk (IN)net (fo=0) 0.000 0.000 clkL17 IBUF (Prop_ibuf_I_O) 1.476 1.476 r clk_IBUF_inst/Onet (fo=1, routed) 1.972 3.448 clk_IBUFBUFGCTRL_X0Y0 BUFG (Prop_bufg_I_O) 0.096 3.544 r clk_IBUF_BUFG_inst/Onet (fo=213, routed) 1.602 5.145 i_program_memory/clkRAMB36_X1Y3 RAMB36E1 r i_program_memory/instr_reg_reg/CLKARDCLK------------------------------------------------------------------- -------------------RAMB36_X1Y3 RAMB36E1 (Prop_ramb36e1_CLKARDCLK_DOADO)2.454 7.599 f i_program_memory/instr_reg_reg/DOADOnet (fo=16, routed) 1.205 8.804 i_riscv_cpu/i_decoder/instrSLICE_X49Y14 LUT6 (Prop_lut6_I0_O) 0.124 8.928 f i_riscv_cpu/i_decoder/out_immed_INST_0_i_1/Onet (fo=43, routed) 0.354 9.282 i_riscv_cpu/i_decoder/out_immed_INST_0_i_1_n_0SLICE_X49Y14 LUT2 (Prop_lut2_I1_O) 0.124 9.406 r i_riscv_cpu/i_decoder/out_reg_a_INST_0/Onet (fo=36, routed) 1.061 10.467 i_riscv_cpu/i_register_file/registers_1_reg_0_31_0_5/ADDRA0SLICE_X50Y14 RAMD32 (Prop_ramd32_RADR0_O)0.150 10.617 r i_riscv_cpu/i_register_file/registers_1_reg_0_31_0_5/RAMA/Onet (fo=10, routed) 0.816 11.433 i_riscv_cpu/reg_read_data_aSLICE_X48Y12 LUT2 (Prop_lut2_I0_O) 0.328 11.761 r i_riscv_cpu/ram_addr_INST_0_i_4/Onet (fo=1, routed) 0.000 11.761 i_riscv_cpu/ram_addr_INST_0_i_4_n_0SLICE_X48Y12 CARRY4 (Prop_carry4_S_CO)0.532 12.293 r i_riscv_cpu/ram_addr_INST_0/COnet (fo=1, routed) 0.000 12.293 i_riscv_cpu/ram_addr_INST_0_n_0SLICE_X48Y13 CARRY4 (Prop_carry4_CI_CO)0.114 12.407 r i_riscv_cpu/ram_addr_INST_0/COnet (fo=1, routed) 0.000 12.407 i_riscv_cpu/ram_addr_INST_0_n_0SLICE_X48Y14 CARRY4 (Prop_carry4_CI_CO)0.114 12.521 r i_riscv_cpu/ram_addr_INST_0/COnet (fo=1, routed) 0.000 12.521 i_riscv_cpu/ram_addr_INST_0_n_0SLICE_X48Y15 CARRY4 (Prop_carry4_CI_CO)0.114 12.635 r i_riscv_cpu/ram_addr_INST_0/COnet (fo=1, routed) 0.000 12.635 i_riscv_cpu/ram_addr_INST_0_n_0SLICE_X48Y16 CARRY4 (Prop_carry4_CI_CO)0.114 12.749 r i_riscv_cpu/ram_addr_INST_0/COnet (fo=1, routed) 0.000 12.749 i_riscv_cpu/ram_addr_INST_0_n_0SLICE_X48Y17 CARRY4 (Prop_carry4_CI_CO)0.114 12.863 r i_riscv_cpu/ram_addr_INST_0/COnet (fo=1, routed) 0.000 12.863 i_riscv_cpu/ram_addr_INST_0_n_0SLICE_X48Y18 CARRY4 (Prop_carry4_CI_CO)0.114 12.977 r i_riscv_cpu/ram_addr_INST_0/COnet (fo=1, routed) 0.000 12.977 i_riscv_cpu/ram_addr_INST_0_n_0SLICE_X48Y19 CARRY4 (Prop_carry4_CI_O)0.348 13.325 r i_riscv_cpu/ram_addr_INST_0/Onet (fo=2, routed) 0.557 13.882 i_ram/ram_addrSLICE_X49Y17 LUT6 (Prop_lut6_I2_O) 0.303 14.185 r i_ram/busy_INST_0_i_4/Onet (fo=1, routed) 0.000 14.185 i_ram/busy_INST_0_i_4_n_0SLICE_X49Y17 CARRY4 (Prop_carry4_S_CO)0.570 14.755 r i_ram/busy_INST_0_i_1/COnet (fo=1, routed) 0.532 15.286 i_ram/busy21_inSLICE_X44Y17 LUT4 (Prop_lut4_I3_O) 0.313 15.599 r i_ram/busy_INST_0/Onet (fo=62, routed) 0.403 16.002 i_riscv_cpu/i_program_counter/p_0_inSLICE_X44Y16 LUT6 (Prop_lut6_I1_O) 0.124 16.126 r i_riscv_cpu/i_program_counter/pc_next_INST_0/Onet (fo=1, routed) 0.808 16.934 i_program_memory/pc_nextSLICE_X44Y17 LUT6 (Prop_lut6_I0_O) 0.124 17.058 r i_program_memory/instr_reg_reg_i_2/Onet (fo=1, routed) 0.573 17.631 i_program_memory/instr_reg_reg_i_2_n_0SLICE_X45Y19 LUT5 (Prop_lut5_I0_O) 0.124 17.755 r i_program_memory/instr_reg_reg_i_1/Onet (fo=1, routed) 0.622 18.377 i_program_memory/instr_reg_reg_i_1_n_0RAMB36_X1Y3 RAMB36E1 r i_program_memory/instr_reg_reg/RSTRAMARSTRAM------------------------------------------------------------------- -------------------(clock clk_pin rise edge) 13.800 13.800 rL17 0.000 13.800 r clk (IN)net (fo=0) 0.000 13.800 clkL17 IBUF (Prop_ibuf_I_O) 1.406 15.206 r clk_IBUF_inst/Onet (fo=1, routed) 1.868 17.074 clk_IBUFBUFGCTRL_X0Y0 BUFG (Prop_bufg_I_O) 0.091 17.165 r clk_IBUF_BUFG_inst/Onet (fo=213, routed) 1.484 18.648 i_program_memory/clkRAMB36_X1Y3 RAMB36E1 r i_program_memory/instr_reg_reg/CLKARDCLKclock pessimism 0.297 18.945clock uncertainty -0.035 18.910RAMB36_X1Y3 RAMB36E1 (Setup_ramb36e1_CLKARDCLK_RSTRAMARSTRAM)-0.359 18.551 i_program_memory/instr_reg_reg-------------------------------------------------------------------required time 18.551arrival time -18.377-------------------------------------------------------------------slack 0.174# report_utilization -hierarchicalCopyright 1986-2019 Xilinx, Inc. All Rights Reserved.------------------------------------------------------------------------------------| Tool Version : Vivado v.2019.2 (lin64) Build 2708876 Wed Nov 6 21:39:14 MST 2019| Date : Sun Dec 29 21:04:14 2019| Host : hamster-nuc running 64-bit Ubuntu 16.04.6 LTS| Command : report_utilization -hierarchical| Design : top_level| Device : 7a35tcpg236-1| Design State : Routed------------------------------------------------------------------------------------Utilization Design InformationTable of Contents-----------------1. Utilization by Hierarchy1. Utilization by Hierarchy---------------------------+-----------------------+-----------------+------------+------------+---------+------+-----+--------+--------+--------------+| Instance | Module | Total LUTs | Logic LUTs | LUTRAMs | SRLs | FFs | RAMB36 | RAMB18 | DSP48 Blocks |+-----------------------+-----------------+------------+------------+---------+------+-----+--------+--------+--------------+| top_level | (top) | 813 | 740 | 72 | 1 | 65 | 2 | 0 | 0 || (top_level) | (top) | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 || i_program_memory | program_memory | 4 | 4 | 0 | 0 | 0 | 1 | 0 | 0 || i_ram | ram | 56 | 56 | 0 | 0 | 33 | 1 | 0 | 0 || i_riscv_cpu | riscv_cpu | 752 | 680 | 72 | 0 | 31 | 0 | 0 | 0 || (i_riscv_cpu) | riscv_cpu | 32 | 32 | 0 | 0 | 0 | 0 | 0 | 0 || i_branch_test | branch_test | 29 | 29 | 0 | 0 | 0 | 0 | 0 | 0 || i_data_bus_mux_a | data_bus_mux_a | 16 | 16 | 0 | 0 | 0 | 0 | 0 | 0 || i_data_bus_mux_b | data_bus_mux_b | 18 | 18 | 0 | 0 | 0 | 0 | 0 | 0 || i_decoder | decoder | 78 | 78 | 0 | 0 | 0 | 0 | 0 | 0 || i_program_counter | program_counter | 185 | 185 | 0 | 0 | 31 | 0 | 0 | 0 || i_register_file | register_file | 73 | 1 | 72 | 0 | 0 | 0 | 0 | 0 || i_result_bus_mux | result_bus_mux | 32 | 32 | 0 | 0 | 0 | 0 | 0 | 0 || i_sign_extender | sign_extender | 24 | 24 | 0 | 0 | 0 | 0 | 0 | 0 || i_station_alu | station_alu | 144 | 144 | 0 | 0 | 0 | 0 | 0 | 0 || i_station_shifter | station_shifter | 121 | 121 | 0 | 0 | 0 | 0 | 0 | 0 |+-----------------------+-----------------+------------+------------+---------+------+-----+--------+--------+--------------+* Note: The sum of lower-level cells may be larger than their parent cells total, due to cross-hierarchy LUT combiningNext up is to get it to run my verification test benches so I can do regression automated testing without having to do anything.The best, best thing, is that I can change code and build over an SSH session from a laptop, while sitting on the sofa, rather than disappearing to my study nook.

author: scatha
author_rank: Regular Contributor
timestamp: December 29, 2019, 09:23:17 am
content: Non-project mode is a lot nicer particularly for large projects, I hardly ever touch the Vivado GUI apart from simulation and floorplanning. Just drive everything via Makefiles and write dcp checkpoints as appropriate. Makes version control a lot easier as well.

author: rstofer
author_rank: Super Contributor
timestamp: December 29, 2019, 06:01:33 pm
content: Quote from: scatha on December 29, 2019, 09:23:17 amMakefiles also give you the opportunity to compile/assemble source files that result in, say, .hex files for inclusion into BlockRAM before starting the FPGA tools.I haven't spent any time with TCL but it looks like I'll have to learn. For those of us still using ModelSim, TCL is a required subject.

author: bitflipper99
author_rank: Newbie
timestamp: December 31, 2019, 07:37:46 am
content: Hi I'm new to FPGAs and cut my teeth with Vivado. As someone who still relies heavily on Vivado's Block Designs I find it hard imaging working on a project in a command line with all the nets without using a GUI (or using connection automation). Do you write everything in a top level wrapper manually or use third party tools to connect IPs?

author: hamster_nz
author_rank: Super Contributor
timestamp: December 31, 2019, 08:59:04 am
content: Quote from: bitflipper99 on December 31, 2019, 07:37:46 amWhen I worked on a commercial design for video processing using an Intel ARM+FPGA part. The general flow was to to use the system designer (I think it was it called QSYS then, maybe still is) to configure the CPU and I/O ring, using place-holder logic for the actual custom hardware. The IP design was then generated.Wrappers were put around the IP top level files (like the CPU or transceiver blocks) and the resulting HDL files checked into version control. Any vendor specific IP blocks (FIFOs, block RAM, clocking) were also generated then put behind wrappers before being added into version control.From then on it was nearly all at the HDL source level.As resources got thin we then gradually stripped out all the bloat (like big CPU bus-connected transceiver reset controllers,or inefficient register files) and replaced it with smaller, more targeted blocks, that did what we wanted and nothing more. This released quite a bit of the fabric resources.If we ever had to change something major with base system configuration one unlucky engineer would generate a new set files for the updated system design, then merge the required changes into the current HDL source tree. Usually it wasn't an epic undertaking. Because of the wrappers around the IP blocks most changes could be integrated very quickly if they didn't alter the external module interfaces, or you could do what software guys would call a "dark release" and use the new IP but not expose the new interfaces to the rest of the design until after it had all been integrated and tested.In that case the bulk of the grunt work was automated, but you weren't able to just regenerate the QSYS system IP as it nuked many customizations. BUt on the upside, one bonus was that by putting wrappers around everything that was vendor specific meant that the design could be deployed on both Intel and Xilinx parts, once somebody had generated equivalent IP from the other vendor and made them fit inside the same HDL wrapper.For my own hobby projects I shun IP blocks as much as possible, as I am mainly playing with things that tickle my interest and I want to be able to publish things.

author: hamster_nz
author_rank: Super Contributor
timestamp: December 31, 2019, 09:01:35 am
content: Oh, I did get simulation working from the non-project mode too. The documentation was pretty sparse here, especially for somebody as clueless about tcl as I am.Here's the .tcl file:Code:read_vhdl ../src/sign_extender.vhdread_vhdl ../src/data_bus_mux_a.vhdread_vhdl ../src/decode.vhdread_vhdl ../src/data_bus_mux_b.vhdread_vhdl ../src/program_counter.vhdread_vhdl ../src/station_alu.vhdread_vhdl ../src/result_bus_mux.vhdread_vhdl ../src/ram.vhdread_vhdl ../src/station_test.vhdread_vhdl ../src/top_level.vhdread_vhdl ../src/riscv_cpu.vhdread_vhdl ../src/register_file.vhdread_vhdl ../src/branch_test.vhdread_vhdl ../src/station_shifter.vhdread_vhdl ../src/program_memory.vhdread_vhdl ../src/tb_riscv.vhdsave_project_as sim -forceset_property top tb_riscv [get_fileset sim_1]launch_simulation -simset sim_1 -mode behavioralrun 5usquit

author: legacy
author_rank: Super Contributor
timestamp: December 31, 2019, 04:18:33 pm
content: Quote from: rstofer on December 29, 2019, 06:01:33 pmYep. And also for internet-working-simulations (nodes of computers, routers, etc).TCL + TK (aka TCL/TK) is a required subject.

author: tggzzz
author_rank: Super Contributor
timestamp: December 31, 2019, 04:33:03 pm
content: Quote from: hamster_nz on December 31, 2019, 08:59:04 amThat is all saneThe last time I looked at Vivado used like that (years ago), I found it difficult to determine the minimal set of files that could considered as my "source" files. By that I mean the set of files that could be copied to a directory tree, from which the complete project could be regenerated.Is there a simple canonical statement of the necessary files?Consider Zynq PS as a separate case

author: legacy
author_rank: Super Contributor
timestamp: January 01, 2020, 06:49:21 am
content: Quote from: tggzzz on December 31, 2019, 04:33:03 pmVHDL and/or Verilog sources, plus physical and timing constraints.

author: tggzzz
author_rank: Super Contributor
timestamp: January 01, 2020, 09:57:24 am
content: Quote from: legacy on January 01, 2020, 06:49:21 amThat's necessary, but is it sufficient? How about any autogenerated files/scripts, especially those knitting IP blocks, PS, and PL together??While analogies are dangerous, one analogy (which I've seen IRL) is a finite state machine compiler which spits out C. While it is sufficient to store only the C in a repository, that isn't sufficient when you want to change the FSM.

author: legacy
author_rank: Super Contributor
timestamp: January 01, 2020, 10:46:36 am
content: Quote from: tggzzz on January 01, 2020, 09:57:24 amFor me: yes.Quote from: tggzzz on January 01, 2020, 09:57:24 amI do not use any IP blocks etc. Just pure HDL code, even because I can only simulate pure HDL code.

author: legacy
author_rank: Super Contributor
timestamp: January 01, 2020, 11:00:19 am
content: Quote from: tggzzz on January 01, 2020, 09:57:24 amIn this case, I put this stuff into a dedicated folder, from where I create the C files I need, and things don't go mixed together into the same project level to avoid confusion. A practical example is Yacc and Lex files, or Ant files, used as "meta" sources to automatically generate a finite state machine in C.Anyway, I do consider "project files" everything I do physically edit. I do not consider "project files" everything is automatically generated. Hence, in this case, Yacc and Lex are project files, whereas their automatically generated C files are not.

author: tggzzz
author_rank: Super Contributor
timestamp: January 01, 2020, 11:35:09 am
content: Quote from: legacy on January 01, 2020, 11:00:19 amYes, but...Now it is very convenient to use the Vivado graphical tools for some of the high level "knitting" interconnections (especially the PS/PL) and some other design artefacts. Which files are source files at that level?No, I don't expect a full answer from you, but it would be nice if Xilinx provided comprehensive information.

author: legacy
author_rank: Super Contributor
timestamp: January 01, 2020, 12:36:38 pm
content: Quote from: tggzzz on January 01, 2020, 11:35:09 amAh, ok, now I have understood what you mean.Sorry, this is out of my workflow. I cannot help

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 01, 2020, 03:26:05 pm
content: Quote from: tggzzz on January 01, 2020, 09:57:24 amIf you're talking about ÏP blocks generated from the IDE's integrated IP generator, I think eventually it just spits out HDL files that are sufficient to include in your project to build it. You don't need the original config files that it also generates (unless you need to modify the IP blocks). If you'd prefer your automated build chain to re-generate all IPs every time from config files, then I don't know - the IP generator may have a command line, you'd need to look that up in the help. But if not, only HDL files are necessary AFAIK.

author: tggzzz
author_rank: Super Contributor
timestamp: January 01, 2020, 03:39:14 pm
content: Quote from: SiliconWizard on January 01, 2020, 03:26:05 pmThat makes sense.I'm used to processes and environments (in a general sense) in which I do many small "experiments", and if I don't like the result I revert to the previous variant. Variants are stored in some form of source code repository.While a waterfall process can work where everything is known in advance, in practice that hasn't been my experience.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 01, 2020, 04:24:04 pm
content: If you're going to make frequent changes to IP blocks and still want to use an automated command-line build, going back to the IDE every time you'd need to modify an IP block would be cumbersome and would kind of defeat the whole benefit of the command-line approach...In this case, I think you'd have two options: figure out the config file format (which are likely just text files) for IP blocks, and figure out how to call the IP generator on the command-line, OR just take the output HDL files as I suggested, and modify them directly. Usually they just contain a series of instantiations of primitives that are documented...

author: tggzzz
author_rank: Super Contributor
timestamp: January 01, 2020, 04:36:30 pm
content: There's validity to that, but I have an aversion to changing any auto-generated code.There is wiggle room in a definition of "frequent", of course. In my case I would like/expect far more invocations via the command line, but during a project there would also be many changes via the non-command line mode.In either case I want to store my design in a source code repository of some sort. I've seen the horrible mess that can result from regarding a directory tree or virtual machine memory image (in Smalltalk terms) as being the principal definition of a project.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 01, 2020, 06:11:10 pm
content: Anyway, if you're OK with invoking the IP generators from the IDE and are just wondering which files you need to actually store in a repository...I haven't used Vivado much yet, but with ISE, I can say that all you'd need to store would be: your source files of course, the constraint files, and the .xco files (for the IP generator); but if you don't want to bother re-generating the IP blocks, put the whole "ipcore_dir" directory in the repository. If you find a way of invoking the IP generator from the command-line, I think all that would be strictly required to keep are the .xco files (or whatever is the equivalent for Vivado...)In any case, I think actually putting the whole "ipcore_dir" directory (or equivalent) in the repository would be a good idea for one reason, the same that would make storing any auto-generated source files a good idea: getting an exact snapshot of source files that you can build any specific version with. If you're only storing the configuration files (for auto-generated stuff), the problem is that suddenly, your repository doesn't reflect your exact source code, as some source files (auto-generated) will depend on the version of the tools you used. Of course for this, you can clearly indicate the required version of the tools for a given version of your design instead, and not store the output generated files... it's a whole discussion in itself...And that said, I still think someone willing to mostly do without the IDE should consider NOT using GUI IP generators, and instantiate the base primitives themselves instead. Then you have full control over your whole source code, and don't need to worry about storing extra cryptic files... (Now whereas doing this is usually not that hard, I'm wondering about the memory controller IPs on Vivado... that's probaby a special case as there are no embedded memory controllers in the 7 series, so the corresponding IPs are probably pretty involved and good luck writing them yourself with primitives - if someone has already done this, please chime in!)

author: hamster_nz
author_rank: Super Contributor
timestamp: January 01, 2020, 07:25:01 pm
content: You pretty much have to use the IP generators for the high speed transceivers, at least for the initial HDL generation.It adds a whole lot of magic numbers for undocumented registers, that are most likely needed if it is going to work.

author: legacy
author_rank: Super Contributor
timestamp: January 01, 2020, 07:31:01 pm
content: Quote from: hamster_nz on January 01, 2020, 07:25:01 pmis that required for the LVDS transceivers? or is it enough to specify LVDS in the constraint file? not yet tried.

author: asmi
author_rank: Super Contributor
timestamp: January 03, 2020, 11:05:37 pm
content: Quote from: legacy on January 01, 2020, 07:31:01 pmLVDS transceivers are not "hi speed" in Xilinx parlance. When they talk "hi speed", they mean Multi Gigabit Transceivers (MGTs for short).For LVDS you can get away with HDL-only way of instantiating ISERDES/OSERDES directly and setting them up the way you want.

author: asmi
author_rank: Super Contributor
timestamp: January 03, 2020, 11:10:25 pm
content: I would also note read_mem command which would read in all BRAM init files. It cost me quite a bit to figure outAlso - non-project mode allows something you can't achieve via GUI: repeated optimizations on the same project. Like this:Code:set step 4_phys_optphys_opt_design -directive AggressiveExplore > $out_dir/${step}_explore.logphys_opt_design -directive AggressiveFanoutOpt > $out_dir/${step}_fanout.logphys_opt_design -directive AlternateReplication > $out_dir/${step}_replication.logAFAIK can't do this via GUI.Here's my script:Code:#running: vivado -mode batch -source run.tclset out_dir ./outset top_module core_topset part_num xc7a35tftg256-2file mkdir $out_dirforeach fname [glob -nocomplain $out_dir/*] {file delete $fname}source ./sources.tcl#synthesize designset step 1_synthsynth_design -top $top_module -part $part_num -retiming -fanout_limit 1000 -gated_clock_conversion on > $out_dir/${step}.log#synth_design -top $top_module -part $part_num -flatten nonewrite_checkpoint -force $out_dir/$stepreport_timing_summary -file $out_dir/${step}_timing_summary.rptreport_utilization -file $out_dir/${step}_util.rptreport_power -file $out_dir/${step}_power.rpt#optimizationset step 2_optopt_design -directive Explore -debug_log > $out_dir/${step}.logreport_timing_summary -file $out_dir/${step}_timing_summary.rptreport_utilization -file $out_dir/${step}_util.rptwrite_checkpoint -force $out_dir/${step}set step 3_placeplace_design -directive ExtraPostPlacementOpt > $out_dir/${step}.logreport_timing_summary -file $out_dir/${step}_timing_summary.rptreport_utilization -file $out_dir/${step}_util.rptwrite_checkpoint -force $out_dir/${step}set step 4_phys_optphys_opt_design -directive AggressiveExplore > $out_dir/${step}_explore.logphys_opt_design -directive AggressiveFanoutOpt > $out_dir/${step}_fanout.logphys_opt_design -directive AlternateReplication > $out_dir/${step}_replication.logreport_timing_summary -file $out_dir/${step}_timing_summary.rptreport_utilization -file $out_dir/${step}_util.rptwrite_checkpoint -force $out_dir/${step}set step 5_routeroute_design -directive Explore > $out_dir/${step}.logwrite_checkpoint -force $out_dir/${step}report_timing_summary -file $out_dir/${step}_timing_summary.rptreport_timing -sort_by group -max_paths 100 -path_type summary -file $out_dir/${step}_timing.rptreport_clock_utilization -file $out_dir/${step}_clock_util.rptreport_utilization -file $out_dir/${step}_util.rptreport_power -file $out_dir/${step}_power.rptreport_drc -file $out_dir/${step}_drc.rptwrite_verilog -force $out_dir/impl_netlist.vwrite_xdc -no_fixed_only -force $out_dir/impl.xdcwrite_bitstream -force $out_dir/impl.bitsources.tcl:Code:read_verilog -sv [ glob ./hdl/*.sv]read_mem [ glob ./hdl/*.mem]read_xdc [ glob ./xdc/*.xdc]simulation.tcl (to be used for simulations):Code:set sim_proj_name simset top_name core_top_tbsource ./sources.tclread_verilog -sv [ glob ./tb/*.sv]save_project_as -force $sim_proj_nameset_property top $top_name [get_fileset sim_1]launch_simulation -simset sim_1 -mode behavioralstart_gui

author: jklasdf
author_rank: Regular Contributor
timestamp: January 21, 2020, 06:05:07 am
content: For the high-speed MGT/GTP/GTX/GTH/etc. transceivers, I usually use the GUI to generate the IP the first time. Vivado will spit out the TCL command (a large quantity of TCL) to generate that IP on the TCL console. I usually don't check in the actual generated IP directory. If you don't need to change that much, then just editing the TCL directly is fairly easy. Otherwise I'll open the GUI again, set up the IP again, and get a new TCL output, and try to reconcile the differences (I usually end up reformatting the TCL Vivado spits out on the TCL console, and sometimes try to parameterize some stuff depending on the values of some variables, or make a function that takes some parameters and generates the actual IP).

author: asmi
author_rank: Super Contributor
timestamp: January 21, 2020, 02:43:51 pm
content: You can use read_ip command to include IP cores into your design.Also I've recently discovered UG905, which explains how to do a timing analysis, as well as place & route of a certain submodule of a project without usual legwork to create some kind of dummy wrapper (which can impact your core's performance). This functionality is only available in non-project mode and fundamentally is leveraging the infrastructure that is normally used for partial reconfiguration. I found this to be super-useful for "internal" cores which do not directly interface with IO - like CPU/GPU cores, or some sort of data processing modules.