Using Vivado in tcl mode.

[hamster_nz]

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: [Select]

(cd ../vivado; echo source build.tcl |  vivado -mode tcl | tee /tmp/log)


And in the ../vivado directory I have the 'build.tcl' script:

Code: [Select]

set_part "xc7a35tcpg236-1"

# read all design files
read_vhdl ../src/sign_extender.vhd
read_vhdl ../src/data_bus_mux_a.vhd
read_vhdl ../src/decode.vhd
read_vhdl ../src/data_bus_mux_b.vhd
read_vhdl ../src/program_counter.vhd
read_vhdl ../src/station_alu.vhd
read_vhdl ../src/result_bus_mux.vhd
read_vhdl ../src/ram.vhd
read_vhdl ../src/station_test.vhd
read_vhdl ../src/top_level.vhd
read_vhdl ../src/riscv_cpu.vhd
read_vhdl ../src/register_file.vhd
read_vhdl ../src/branch_test.vhd
read_vhdl ../src/station_shifter.vhd
read_vhdl ../src/program_memory.vhd

# read constraints
read_xdc ../src/cmod_a7.xdc

# Synthesize Design
synth_design -top top_level -part "xc7a35tcpg236-1" -flatten_hierarchy none
# Opt Design
opt_design
# Place Design
place_design
# Route Design
route_design
report_timing -nworst 1
report_utilization -hierarchical

# Write out bitfile
## write_bitstream -force my_proj.bit

A 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: [Select]

...
Timing Report

Slack (MET) :             0.174ns  (required time - arrival time)
  Source:                 i_program_memory/instr_reg_reg/CLKARDCLK
                            (rising edge-triggered cell RAMB36E1 clocked by clk_pin  {[email protected] [email protected] period=13.800ns})
  Destination:            i_program_memory/instr_reg_reg/RSTRAMARSTRAM
                            (rising edge-triggered cell RAMB36E1 clocked by clk_pin  {[email protected] [email protected] period=13.800ns})
  Path Group:             clk_pin
  Path Type:              Setup (Max at Slow Process Corner)
  Requirement:            13.800ns  (clk_pin [email protected] - clk_pin [email protected])
  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.145ns
    Clock Pessimism Removal (CPR):    0.297ns
  Clock Uncertainty:      0.035ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Total Input Jitter      (TIJ):    0.000ns
    Discrete Jitter          (DJ):    0.000ns
    Phase Error              (PE):    0.000ns

    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                         (clock clk_pin rise edge)    0.000     0.000 r
    L17                                               0.000     0.000 r  clk (IN)
                         net (fo=0)                   0.000     0.000    clk
    L17                  IBUF (Prop_ibuf_I_O)         1.476     1.476 r  clk_IBUF_inst/O
                         net (fo=1, routed)           1.972     3.448    clk_IBUF
    BUFGCTRL_X0Y0        BUFG (Prop_bufg_I_O)         0.096     3.544 r  clk_IBUF_BUFG_inst/O
                         net (fo=213, routed)         1.602     5.145    i_program_memory/clk
    RAMB36_X1Y3          RAMB36E1                                     r  i_program_memory/instr_reg_reg/CLKARDCLK
  -------------------------------------------------------------------    -------------------
    RAMB36_X1Y3          RAMB36E1 (Prop_ramb36e1_CLKARDCLK_DOADO[1])
                                                      2.454     7.599 f  i_program_memory/instr_reg_reg/DOADO[1]
                         net (fo=16, routed)          1.205     8.804    i_riscv_cpu/i_decoder/instr[1]
    SLICE_X49Y14         LUT6 (Prop_lut6_I0_O)        0.124     8.928 f  i_riscv_cpu/i_decoder/out_immed[30]_INST_0_i_1/O
                         net (fo=43, routed)          0.354     9.282    i_riscv_cpu/i_decoder/out_immed[30]_INST_0_i_1_n_0
    SLICE_X49Y14         LUT2 (Prop_lut2_I1_O)        0.124     9.406 r  i_riscv_cpu/i_decoder/out_reg_a[0]_INST_0/O
                         net (fo=36, routed)          1.061    10.467    i_riscv_cpu/i_register_file/registers_1_reg_0_31_0_5/ADDRA0
    SLICE_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/O
                         net (fo=10, routed)          0.816    11.433    i_riscv_cpu/reg_read_data_a[0]
    SLICE_X48Y12         LUT2 (Prop_lut2_I0_O)        0.328    11.761 r  i_riscv_cpu/ram_addr[0]_INST_0_i_4/O
                         net (fo=1, routed)           0.000    11.761    i_riscv_cpu/ram_addr[0]_INST_0_i_4_n_0
    SLICE_X48Y12         CARRY4 (Prop_carry4_S[0]_CO[3])
                                                      0.532    12.293 r  i_riscv_cpu/ram_addr[0]_INST_0/CO[3]
                         net (fo=1, routed)           0.000    12.293    i_riscv_cpu/ram_addr[0]_INST_0_n_0
    SLICE_X48Y13         CARRY4 (Prop_carry4_CI_CO[3])
                                                      0.114    12.407 r  i_riscv_cpu/ram_addr[4]_INST_0/CO[3]
                         net (fo=1, routed)           0.000    12.407    i_riscv_cpu/ram_addr[4]_INST_0_n_0
    SLICE_X48Y14         CARRY4 (Prop_carry4_CI_CO[3])
                                                      0.114    12.521 r  i_riscv_cpu/ram_addr[8]_INST_0/CO[3]
                         net (fo=1, routed)           0.000    12.521    i_riscv_cpu/ram_addr[8]_INST_0_n_0
    SLICE_X48Y15         CARRY4 (Prop_carry4_CI_CO[3])
                                                      0.114    12.635 r  i_riscv_cpu/ram_addr[12]_INST_0/CO[3]
                         net (fo=1, routed)           0.000    12.635    i_riscv_cpu/ram_addr[12]_INST_0_n_0
    SLICE_X48Y16         CARRY4 (Prop_carry4_CI_CO[3])
                                                      0.114    12.749 r  i_riscv_cpu/ram_addr[16]_INST_0/CO[3]
                         net (fo=1, routed)           0.000    12.749    i_riscv_cpu/ram_addr[16]_INST_0_n_0
    SLICE_X48Y17         CARRY4 (Prop_carry4_CI_CO[3])
                                                      0.114    12.863 r  i_riscv_cpu/ram_addr[20]_INST_0/CO[3]
                         net (fo=1, routed)           0.000    12.863    i_riscv_cpu/ram_addr[20]_INST_0_n_0
    SLICE_X48Y18         CARRY4 (Prop_carry4_CI_CO[3])
                                                      0.114    12.977 r  i_riscv_cpu/ram_addr[24]_INST_0/CO[3]
                         net (fo=1, routed)           0.000    12.977    i_riscv_cpu/ram_addr[24]_INST_0_n_0
    SLICE_X48Y19         CARRY4 (Prop_carry4_CI_O[1])
                                                      0.348    13.325 r  i_riscv_cpu/ram_addr[28]_INST_0/O[1]
                         net (fo=2, routed)           0.557    13.882    i_ram/ram_addr[29]
    SLICE_X49Y17         LUT6 (Prop_lut6_I2_O)        0.303    14.185 r  i_ram/busy_INST_0_i_4/O
                         net (fo=1, routed)           0.000    14.185    i_ram/busy_INST_0_i_4_n_0
    SLICE_X49Y17         CARRY4 (Prop_carry4_S[1]_CO[2])
                                                      0.570    14.755 r  i_ram/busy_INST_0_i_1/CO[2]
                         net (fo=1, routed)           0.532    15.286    i_ram/busy21_in
    SLICE_X44Y17         LUT4 (Prop_lut4_I3_O)        0.313    15.599 r  i_ram/busy_INST_0/O
                         net (fo=62, routed)          0.403    16.002    i_riscv_cpu/i_program_counter/p_0_in
    SLICE_X44Y16         LUT6 (Prop_lut6_I1_O)        0.124    16.126 r  i_riscv_cpu/i_program_counter/pc_next[18]_INST_0/O
                         net (fo=1, routed)           0.808    16.934    i_program_memory/pc_next[18]
    SLICE_X44Y17         LUT6 (Prop_lut6_I0_O)        0.124    17.058 r  i_program_memory/instr_reg_reg_i_2/O
                         net (fo=1, routed)           0.573    17.631    i_program_memory/instr_reg_reg_i_2_n_0
    SLICE_X45Y19         LUT5 (Prop_lut5_I0_O)        0.124    17.755 r  i_program_memory/instr_reg_reg_i_1/O
                         net (fo=1, routed)           0.622    18.377    i_program_memory/instr_reg_reg_i_1_n_0
    RAMB36_X1Y3          RAMB36E1                                     r  i_program_memory/instr_reg_reg/RSTRAMARSTRAM
  -------------------------------------------------------------------    -------------------

                         (clock clk_pin rise edge)   13.800    13.800 r
    L17                                               0.000    13.800 r  clk (IN)
                         net (fo=0)                   0.000    13.800    clk
    L17                  IBUF (Prop_ibuf_I_O)         1.406    15.206 r  clk_IBUF_inst/O
                         net (fo=1, routed)           1.868    17.074    clk_IBUF
    BUFGCTRL_X0Y0        BUFG (Prop_bufg_I_O)         0.091    17.165 r  clk_IBUF_BUFG_inst/O
                         net (fo=213, routed)         1.484    18.648    i_program_memory/clk
    RAMB36_X1Y3          RAMB36E1                                     r  i_program_memory/instr_reg_reg/CLKARDCLK
                         clock pessimism              0.297    18.945
                         clock uncertainty           -0.035    18.910
    RAMB36_X1Y3          RAMB36E1 (Setup_ramb36e1_CLKARDCLK_RSTRAMARSTRAM)
                                                     -0.359    18.551    i_program_memory/instr_reg_reg
  -------------------------------------------------------------------
                         required time                         18.551
                         arrival time                         -18.377
  -------------------------------------------------------------------
                         slack                                  0.174




# report_utilization -hierarchical
Copyright 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 Information

Table of Contents
-----------------
1. Utilization by Hierarchy

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



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

[scatha]

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.

[rstofer]

Just drive everything via Makefiles and write dcp checkpoints as appropriate. Makes version control a lot easier as well.

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

[bitflipper99]

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?

[hamster_nz]

Do you write everything in a top level wrapper manually or use third party tools to connect IPs?

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

[hamster_nz]

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: [Select]

read_vhdl ../src/sign_extender.vhd
read_vhdl ../src/data_bus_mux_a.vhd
read_vhdl ../src/decode.vhd
read_vhdl ../src/data_bus_mux_b.vhd
read_vhdl ../src/program_counter.vhd
read_vhdl ../src/station_alu.vhd
read_vhdl ../src/result_bus_mux.vhd
read_vhdl ../src/ram.vhd
read_vhdl ../src/station_test.vhd
read_vhdl ../src/top_level.vhd
read_vhdl ../src/riscv_cpu.vhd
read_vhdl ../src/register_file.vhd
read_vhdl ../src/branch_test.vhd
read_vhdl ../src/station_shifter.vhd
read_vhdl ../src/program_memory.vhd
read_vhdl ../src/tb_riscv.vhd

save_project_as sim -force
set_property top tb_riscv [get_fileset sim_1]
launch_simulation -simset sim_1 -mode behavioral
run 5us
quit



[legacy]

For those of us still using ModelSim, TCL is a required subject.

Yep. And also for internet-working-simulations (nodes of computers, routers, etc).
TCL + TK (aka TCL/TK) is a required subject.

[tggzzz]

Do you write everything in a top level wrapper manually or use third party tools to connect IPs?

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

That is all sane

The 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

[legacy]

Is there a simple canonical statement of the necessary files?

VHDL and/or Verilog sources, plus physical and timing constraints.

[tggzzz]

Is there a simple canonical statement of the necessary files?

VHDL and/or Verilog sources, plus physical and timing constraints.

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

[legacy]

That's necessary, but is it sufficient?

For me: yes.

How about any autogenerated files/scripts, especially those knitting IP blocks, PS, and PL together??

I do not use any IP blocks etc. Just pure HDL code, even because I can only simulate pure HDL code.

[legacy]

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

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

[tggzzz]

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

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

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

[legacy]

No, I don't expect a full answer from you, but it would be nice if Xilinx provided comprehensive information.

Ah, ok, now I have understood what you mean.
Sorry, this is out of my workflow. I cannot help 

[SiliconWizard]

Is there a simple canonical statement of the necessary files?

VHDL and/or Verilog sources, plus physical and timing constraints.

That's necessary, but is it sufficient? How about any autogenerated files/scripts, especially those knitting IP blocks, PS, and PL together??

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

[tggzzz]

Is there a simple canonical statement of the necessary files?

VHDL and/or Verilog sources, plus physical and timing constraints.

That's necessary, but is it sufficient? How about any autogenerated files/scripts, especially those knitting IP blocks, PS, and PL together??

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

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

[SiliconWizard]

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

[tggzzz]

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.

[SiliconWizard]

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!)

[hamster_nz]

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.

[legacy]

You pretty much have to use the IP generators for the high speed transceivers

is that required for the LVDS transceivers? or is it enough to specify LVDS in the constraint file? not yet tried.

[asmi]

is that required for the LVDS transceivers? or is it enough to specify LVDS in the constraint file? not yet tried.

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

[asmi]

I would also note read_mem command which would read in all BRAM init files. It cost me quite a bit to figure out
Also - non-project mode allows something you can't achieve via GUI: repeated optimizations on the same project. Like this:

Code: [Select]

set step 4_phys_opt
phys_opt_design -directive AggressiveExplore > $out_dir/${step}_explore.log
phys_opt_design -directive AggressiveFanoutOpt > $out_dir/${step}_fanout.log
phys_opt_design -directive AlternateReplication > $out_dir/${step}_replication.log
AFAIK can't do this via GUI.

Here's my script:

Code: [Select]

#running: vivado -mode batch -source run.tcl

set out_dir ./out
set top_module core_top
set part_num xc7a35tftg256-2

file mkdir $out_dir
foreach fname [glob -nocomplain $out_dir/*] {
    file delete $fname
}

source ./sources.tcl

#synthesize design
set step 1_synth
synth_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 none
write_checkpoint -force $out_dir/$step
report_timing_summary -file $out_dir/${step}_timing_summary.rpt
report_utilization -file $out_dir/${step}_util.rpt
report_power -file $out_dir/${step}_power.rpt

#optimization
set step 2_opt
opt_design -directive Explore -debug_log > $out_dir/${step}.log
report_timing_summary -file $out_dir/${step}_timing_summary.rpt
report_utilization -file $out_dir/${step}_util.rpt
write_checkpoint -force $out_dir/${step}

set step 3_place
place_design -directive ExtraPostPlacementOpt > $out_dir/${step}.log
report_timing_summary -file $out_dir/${step}_timing_summary.rpt
report_utilization -file $out_dir/${step}_util.rpt
write_checkpoint -force $out_dir/${step}

set step 4_phys_opt
phys_opt_design -directive AggressiveExplore > $out_dir/${step}_explore.log
phys_opt_design -directive AggressiveFanoutOpt > $out_dir/${step}_fanout.log
phys_opt_design -directive AlternateReplication > $out_dir/${step}_replication.log
report_timing_summary -file $out_dir/${step}_timing_summary.rpt
report_utilization -file $out_dir/${step}_util.rpt
write_checkpoint -force $out_dir/${step}

set step 5_route
route_design -directive Explore > $out_dir/${step}.log

write_checkpoint -force $out_dir/${step}
report_timing_summary -file $out_dir/${step}_timing_summary.rpt
report_timing -sort_by group -max_paths 100 -path_type summary -file $out_dir/${step}_timing.rpt
report_clock_utilization -file $out_dir/${step}_clock_util.rpt
report_utilization -file $out_dir/${step}_util.rpt
report_power -file $out_dir/${step}_power.rpt
report_drc -file $out_dir/${step}_drc.rpt
write_verilog -force $out_dir/impl_netlist.v
write_xdc -no_fixed_only -force $out_dir/impl.xdc

write_bitstream -force $out_dir/impl.bit
sources.tcl:

Code: [Select]

read_verilog -sv [ glob ./hdl/*.sv]

read_mem [ glob ./hdl/*.mem]

read_xdc  [ glob ./xdc/*.xdc]
simulation.tcl (to be used for simulations):

Code: [Select]

set sim_proj_name sim
set top_name core_top_tb

source ./sources.tcl

read_verilog -sv [ glob ./tb/*.sv]


save_project_as -force $sim_proj_name
set_property top $top_name [get_fileset sim_1]
launch_simulation -simset sim_1 -mode behavioral
start_gui


[jklasdf]

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

[asmi]

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.