Is there any other way to generate project for vivado 2013.3 ?

[chinmay shekhar]

I don't have license for Vivado 2015.4. I am trying to generate project for vivado 2013.3. I tried running protosyn after sourcing settings64.sh for vivado 2013.3. It generates project (.xpr) but inside that no sources are generated. Can i manually add each modules into a new project in vivado 2013.3 ?

[jbalkind]

Hi Chinmay,

You should check the protosyn_logs folder and potentially the runs folder for runme.log to determine which commands are failing. My expectation is that rather than the modules being missing, the older version of vivado does not support some of the commands that protosyn or the other .tcl scripts are using. If you want to use 2013.3, you'll have to figure out the issue with those commands as we're only supporting 2015.4 and newer. We may be able to answer some questions but I expect we won't know much and will just end up googling the same way you will.

Additionally, you will likely have to recreate the IP cores in vivado GUI as it's unlikely you'll be able to cleanly downgrade all of the IP from 2015.4 to 2013.3. I have been able to downgrade some (but not all) IP cores from 2017.1 to 2016.4 cleanly, but was unable to go from 2017.1 to 2015.4. As such, I would guess that you'll need to regenerate everything.

Please let us know if we can help further. My main recommendation would be to try getting hold of a newer version of Vivado.

Thanks,

Jon

[chinmay shekhar]

Hi jon,

I am trying to manually add all the modules in a vivado 2013 project, also there are some ip blocks for vc707 which are not present in the openpiton source folder, can you give me the basic information of that ip blocks so that i can recreate them here?

Thanks,
Chinmay

[jbalkind]

Hi Chinmay,

Which IP blocks do you think are missing? As far as we are aware we provided the relevant .xci or .prj files for all the IP blocks that will work on the vc707. If we didn't then that was an unintended oversight and we can send those your way.

Thanks,

Jon

[chinmay shekhar]

Hi Jon,

I have recreated all the ip blocks. Since i manually added all the source files in my project, do i need to do some additional things? Like running some scripts for adding defines or something? I selected vc707 board and i am running vivado 2013.3

[Alexey Lavrov]

Hi Chinmay,

The set of defines depends on type of a system you are trying to build.

For example, for full system on Genesys2 without Ethernet you need next defines:

NO_SCAN

FPGA_SYN

PITON_FPGA_SYNTH

PITON_PROTO

PITON_FULL_SYSTEM

PITON_FPGA_NO_DMBR

SPLIT_L1_DCACHE

FPGA_SYN_1THREAD

FPGA_FORCE_SRAM_ICACHE_TAG

FPGA_FORCE_SRAM_LSU_ICACHE

FPGA_FORCE_SRAM_DCACHE_TAG

FPGA_FORCE_SRAM_LSU_DCACHE

FPGA_FORCE_SRAM_RF16X160

FPGA_FORCE_SRAM_RF32X80

VC707_BOARD

PITON_FPGA_MC_DDR3

PITON_FPGA_SD_BOOT

PITON_NO_CHIP_BRIDGE

PITON_UART16550

However, as Jon wrote before, I would strongly recommend to try running protosyn, because it does some preprocessing of verilog files which you might need later.

Alexey

[jbalkind]

Additionally, the preprocessing that Alexey mentions is done by pyhp. All .v.pyv files must be turned into .tmp.v files using pyhp. This is one thing that sims and protosyn both do and part of why we recommend to just figure out the issues with protosyn on vivado 2013.3. If you want to run pyhp you will need to set the environment variables in piton/design/xilinx/pyhp_setup.tcl to make sure it generates things correctly. Doing this manually could be a real pain, though you can check what sims and protosyn do for reference if you really want to write your own script or copy a piece of one of those.

Again, likely the best solution is to figure out the issues with protosyn by checking the output in protosyn_logs/ and synth_1/runme.log when you run it with Vivado 2013.3. We don't think there are going to be many errors related to newer commands and they should be fixable if you google for them or ask us.

Thanks,

Jon

[chinmay shekhar]

Hi Jon,

when i run protosyn for vivado 2013.3 i get following two errors
in build/vc707/system/vivado.log
714: ERROR: [Common 17-69] Command failed: No IP specified.  Please specify IP with 'objects'.

and in build/vc707/system/vivado_

17634.backup.log
705: [Common 17-142] Invalid property name 'board_part'.  Please use the 'list_property' command to find properties supported by the target 'project' object.

Error related to IP blocks can be removed by recreating IP blocks for vivado 2013.3 but i am not getting the other one, i think property name is same in both vivado versions. I am attaching vivado.log and vivado_17634.backup.log file with this post. Can you please have a look.

Thanks,
Chinmay

[jbalkind]

Hi Chinmay,

I had this very same problem trying to use something from 2017.1 on 2015.4/2016.4. If you try setting BOARD_PART to "" in piton/tools/src/proto/vc707/board.tcl it may work for you. When I did this for another board, the FPGA_PART declaration was actually sufficient.

Let me know where this gets you.

Thanks,

Jon

[chinmay shekhar]

Hi,

So, the problem i am facing is with tcl scripts especially with gen_project.tcl. I discussed that on Xilinx forum and i got to know that some of the properties are not available in vivado 2013.3. Here is a snippet of gen_project.tcl :-
# Set project properties
set proj [get_projects ${PROJECT_NAME}]
set_property "board" "${BOARD_PART}" $proj
set_property "compxlib.activehdl_compiled_library_dir" "${PROJECT_DIR}/${PROJECT_NAME}.cache/compile_simlib/activehdl" $proj
set_property "compxlib.funcsim" "1" $proj
set_property "compxlib.ies_compiled_library_dir" "${PROJECT_DIR}/${PROJECT_NAME}.cache/compile_simlib/ies" $proj
set_property "compxlib.modelsim_compiled_library_dir" "${PROJECT_DIR}/${PROJECT_NAME}.cache/compile_simlib/modelsim" $proj
set_property "compxlib.overwrite_libs" "0" $proj
set_property "compxlib.compiled_library_dir" "${PROJECT_DIR}/${PROJECT_NAME}.cache/compile_simlib/questa" $proj
set_property "compxlib.riviera_compiled_library_dir" "${PROJECT_DIR}/${PROJECT_NAME}.cache/compile_simlib/riviera" $proj
set_property "compxlib.timesim" "1" $proj
set_property "compxlib.vcs_compiled_library_dir" "${PROJECT_DIR}/${PROJECT_NAME}.cache/compile_simlib" $proj
set_property "corecontainer.enable" "0" $proj
set_property "default_lib" "xil_defaultlib" $proj
set_property "enable_optional_runs_sta" "0" $proj
set_property "ip_cache_permissions" "" $proj
set_property "ip_output_repo" "" $proj
set_property "managed_ip" "0" $proj
if {[string equal ${BOARD_PART} ""] != 0} {
    set_property "part" "${FPGA_PART}" $proj
}
set_property "sim.ip.auto_export_scripts" "1" $proj
set_property "simulator_language" "Mixed" $proj
set_property "source_mgmt_mode" "All" $proj
set_property "target_language" "Verilog" $proj
set_property "target_simulator" "VCS" $proj

I marked all the properties which are unavailable in vivado 2013.3 with red color. I wanted to know, will i need these libraries and properties if i manually add modules in vivado 2013.3 project instead of running protosyn ?

On Thursday, July 27, 2017 at 4:09:58 PM UTC+5:30, chinmay shekhar wrote:

[jbalkind]

Hi Chinmay,

The following properties look like they're associated with simulation and so shouldn't be important:

set_property "compxlib.activehdl_compiled_library_dir" "${PROJECT_DIR}/${PROJECT_NAME}.cache/compile_simlib/activehdl" $proj

set_property "compxlib.ies_compiled_library_dir" "${PROJECT_DIR}/${PROJECT_NAME}.cache/compile_simlib/ies" $proj
set_property "compxlib.modelsim_compiled_library_dir" "${PROJECT_DIR}/${PROJECT_NAME}.cache/compile_simlib/modelsim" $proj

set_property "compxlib.riviera_compiled_library_dir" "${PROJECT_DIR}/${PROJECT_NAME}.cache/compile_simlib/riviera" $proj

set_property "compxlib.vcs_compiled_library_dir" "${PROJECT_DIR}/${PROJECT_NAME}.cache/compile_simlib" $proj

set_property "sim.ip.auto_export_scripts" "1" $proj

set_property "target_simulator" "VCS" $proj

The following is associated with core container which we don't use and didn't exist for 2013.3 anyway:

set_property "corecontainer.enable" "0" $proj

This one is about static timing analysis so you can probably get rid of it:

set_property "enable_optional_runs_sta" "0" $proj

This leaves us with:

set_property "default_lib" "xil_defaultlib" $proj

set_property "ip_cache_permissions" "" $proj
set_property "ip_output_repo" "" $proj

Given that those three all set defaults or set values to empty strings, they're probably not important either and so I'd guess you might be able to just remove them.

In summary, you can probably remove all of those and see what happens.

Jon

[chinmay shekhar]

Hi Jon,

As you told i removed those scripts and tried running "protosyn -b vc707", it worked and bit-stream is generated but when i try running os nothing happens when i press reset. I have tried OS run with the bit file provided in openpiton package, it is working. I am not able to figure out what is missing in the design.

Thanks,
Chinmay

On Thursday, July 27, 2017 at 4:09:58 PM UTC+5:30, chinmay shekhar wrote:

[Jonathan Balkind]

Hi Chinmay,

 

You'd need to look through the vc707/system/vc707_system/vc707_system.runs/synth_1/runme.log and vc707/system/vc707_system/vc707_system.runs/impl_1/runme.log log files to see if there are any "CRITICAL WARNING" or "ERROR" messages. It's unlikely there are any errors at least if it produced a system.bit, but it's possible that Vivado 2013 doesn't support a command we use, or that one of the IP cores has some other bug in 2013 that was fixed by 2015.4. Is there still really no way you could get a licence for 2015.4 or newer? It may save you a lot of time and effort.

 

You may want to add some debug nets to the design, perhaps on the PC (ifu_exu_pc_d) and initial interrupt packet from ciop_iob. This would let you tell if the initial startup sequence is operating correctly.

 

Jon

--
You received this message because you are subscribed to the Google Groups "OpenPiton Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpiton+...@googlegroups.com.
To post to this group, send email to open...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openpiton/fd0f7c1d-c3d0-4ceb-abad-49a9c7a8a207%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[chinmay shekhar]

Hi Jon,

I got the license for vivado 2015.4. I successfully tested uart streaming with uart dmw-ddr option but still unable to run OS. I checked the impl_1/

runme.log. There are 4 critical warnings:-

CRITICAL WARNING: [Netlist 29-160] Cannot set property 'VCCAUX_IO', because the property does not exist for objects of type 'pin'. [/home/esdm/project_piton/openpiton/piton/design/chipset/mc/xilinx/vc707/ip_cores/mig_7series_0/mig_7series_0/user_design/constraints/mig_7series_0.xdc:608]

CRITICAL WARNING: [Netlist 29-160] Cannot set property 'IOSTANDARD', because the property does not exist for objects of type 'pin'. [/home/esdm/project_piton/openpiton/piton/design/chipset/mc/xilinx/vc707/ip_cores/mig_7series_0/mig_7series_0/user_design/constraints/mig_7series_0.xdc:609]
CRITICAL WARNING: [Netlist 29-160] Cannot set property 'PACKAGE_PIN', because the property does not exist for objects of type 'pin'. [/home/esdm/project_piton/openpiton/piton/design/chipset/mc/xilinx/vc707/ip_cores/mig_7series_0/mig_7series_0/user_design/constraints/mig_7series_0.xdc:610]
CRITICAL WARNING: [Vivado 12-1387] No valid object(s) found for set_false_path constraint with option '-to [get_clocks net_axi_clk_clk_mmcm]'. [/home/esdm/project_piton/openpiton/piton/design/xilinx/vc707/constraints.xdc:48]

but uart dmw-ddr is running fine so i suppose these warnings are not causing the problem.

Thanks,
Chinmay

On Thursday, July 27, 2017 at 4:09:58 PM UTC+5:30, chinmay shekhar wrote:

[Alexey Lavrov]

Hi Chinmay,

Can you describe a problem with booting OS more detailed?

If you are using uart-dmw, you have switch #8 on the board turned on. Make sure you turn it off when trying to boot OS.

Alexey

[chinmay shekhar]

Hi Alexey,

I run protosyn -b vc707 then I program the FPGA with the generated bitstream. I insert SD card containing the OS image and press reset. Third led blinks the once and then nothing happens. I turned off switch 8 before programming fpga.
I already tested os with bitfile provided in openpiton package, it's working there.

Thanks,
Chinmay

[Jonathan Balkind]

Have you tried this on a fresh copy of the repository? I'm wondering whether you could have made a modification somewhere for vivado 2013 that could have caused a problem.

--
You received this message because you are subscribed to the Google Groups "OpenPiton Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpiton+...@googlegroups.com.

To post to this group, send an email to open...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openpiton/626b4944-6e59-4963-b019-7895ec490dab%40googlegroups.com.

[chinmay shekhar]

Hi Jon,

Thanks for your advice, I tried with fresh repository and it worked. Now i am able to run OS in single core but now i am stuck with a new problem. I tried implementing 3 cores on vc707 but bitstream did not generate. I went through following process:-
1) modify pyhp_setup.tcl
    set ::env(PTON_X_TILES) 3
    set ::env(PTON_Y_TILES) 1
    set ::env(PTON_NUM_TILES) 3
2) run protosyn -b vc707

i got some errors in runme.log its like "[Place 30-487] The packing of instances into the device could not be obeyed. Please analyze your design to determine if the number of LUTs, FFs, and/or control sets can be reduced."
we can implement 3 cores in vc707 i guess. Did i do something wrong ?
I have attached runme.log with this post.

On Thursday, July 27, 2017 at 4:09:58 PM UTC+5:30, chinmay shekhar wrote:

[Jonathan Balkind]

Hi Chinmay,

 

What does the utilisation look like after synthesis? It sounds like the three cores might not fit since we moved to the newer SD controller, which is larger than the previous one. You could try downsizing a parameter of the core (are you still setting FPGA_SYN_1THREAD?), reducing the cache in the new SD controller, or switching back to the old SD controller. I’ll ask Ang to give you a pointer on the latter option as we had to do it for our Piton chipset too.

 

Jon

 

From: <open...@googlegroups.com> on behalf of chinmay shekhar <chinmays...@gmail.com>

Date: Wednesday, 8 November 2017 at 12:36
To: OpenPiton Discussion <open...@googlegroups.com>

--

You received this message because you are subscribed to the Google Groups "OpenPiton Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpiton+...@googlegroups.com.

To post to this group, send email to open...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openpiton/7793253c-fc29-4941-a6fb-5036f6161a64%40googlegroups.com.

[chinmay shekhar]

Hi Jon,

Can you tell me more about downsizing the parameters of the core. From where i can configure the parameters of the core? Is there any other tcl script besides pyhp_setup.tcl for that ?

Thanks,
Chinmay

[Jonathan Balkind]

Hi Chinmay,

 

This depends what you want to do. Possibilities include:

 

• Looks like FPGA_SYN_1THREAD is set by default but it's there to save area
• THREADS_1 may help here but it has some interactions with FPGA_SYN_1THREAD that I'm not sure about. You could give it a try and just see what happens but don't rely on it
• Set FPGA_SYN_TLB and FPGA_SYN_8TLB
• Change cache parameters in pyhp_setup.tcl
• At the moment, this requires also generating BRAMs appropriate for the new cache parameters. In release 7 we should be able to infer these BRAMs automatically
• Reduce CACHE_ENTRY_WIDTH to 1 or 2 in piton/design/chipset/noc_sd_bridge/rtl/piton_sd_define.vh
• This also requires generating a BRAM appropriate for the new size
• You may also save some area by setting NO_RTL_CSM, which should remove the logic for Coherence Domain Restriction.

 

You may also be able to change PTON_NETWORK_CONFIG in pyhp_setup.tcl to xbar_config. I've never actually tried this on FPGA but in theory it should work since it works in simulation. You can only change PTON_X_TILES and PITON_NUM_TILES when you do this. Don't change PTON_Y_TILES.

To view this discussion on the web, visit https://groups.google.com/d/msgid/openpiton/c9b2666b-d1ca-4462-bdef-8bba3b1dce25%40googlegroups.com.

[jbalkind]

Hi Chinmay,

To follow up on this, I found that NO_RTL_CSM cut out a bit more than I expected when synthesising for something that used almost a whole VC707. Hopefully it has similar results for you.

Thanks,

Jon

To unsubscribe from this group and stop receiving emails from it, send an email to openpiton+unsubscribe@googlegroups.com.

[chinmay shekhar]

Hi Jon,

I tried removing NO_RTL_CSM and it reduced resource utilization but when i tried booting linux, it got stuck in between. I think design is failing because of some reason i am unaware of. There are some timing violations also. How are you avoiding Timing violations in the design ?

Thanks,
Chinmay

[jbalkind]

Hi Chinmay,

I generated a couple of images using NO_RTL_CSM and it doesn't seem like that should be what's causing the problem. I think the timing violations could be the issue. How big are they? You might try opening the vc707_system.xpr project file in Vivado and running implementation with a new strategy like PostRoutePhysOpt. I'd recommend doing this as a new implementation, impl_2.

You might also try reducing the clock frequency of the main chip clock domain. You can do this by changing the 60MHz output clock from the clk_mmcm and the clock of the UART16550. You'll need to adjust the baud rate on your machine to reflect you changing that frequency.

Thanks,

Jon