timing issue on AU250

[corundum]

timing issue on AU250

[Winters123]

Hey Alex, thanks for the tip about AU250. It actually met the timing with the placement constraints added. 👍 Guess I should do the same for vcu118 as well. Will update here if it works.

[Winters123]

Hi Alex, just an update on vcu118. Timing constraints are met with placement constraints added (for my project, I only need to constraint the pcie-related part to make it work). And I think you're right about the placement issue in vivado on large boards.

[alexforencich]

yeah, I am going to be adding similar constraints to all of the multi-SLR parts. Just have to do some more vivado runs to make sure they all do what they're supposed to.

[alexforencich]

You might want to look in to doing some placement constraints. Vivado has had issues placing the design on some of the larger boards, including the U250. Sometimes the issues are SLR crossings, in some cases crossing multiple times, in other cases the issues are simply poor placement within an SLR. I added some additional constraints for the U250 in my copy here: https://github.com/alexforencich/corundum . Try those out and see if it helps. You may need to add some additional constraints. Also, FYI, the port and interface modules have been renamed.

[Winters123]

That's great to hear. Thanks! I'm trying the current code with the new constraints to see if it helps.

I did find the same placement problem on vcu118 as well since some minor modifications of my own code resulted in some high path delays in other parts.

Thanks for reminding me of the rename. I wonder if this is just a rename or also involving some logic changes?

[alexforencich]

No logic changes in those modules, rename was done now because 'interface' is apparently a reserved word in system verilog and was causing trouble when running under cocotb. There will be extensive changes coming down the pipe, but I have been primarily working on rebuilding the testbenches to use cocotb instead of myhdl, once that is done then I will get back to working on the core logic.

[Winters123]

Thanks for the tip. By the way, does the coming updates of the design include something that allows some sort of switch mechanism between ports/interfaces? As this may be a useful way to support things like NFV acceleration or so. (Its just a random wonder and I have no clue if it makes sense to others...)

[alexforencich]

The updates are mainly going to be around device support (Arria 10, Stratix 10 DX), variable-length descriptor support, and metadata support. Switching is not on the roadmap at the moment, at least in terms of what I am going to be working on personally. But, I would be happy to bounce ideas around for other potential features, either in the discussion section here, or on the mailing list.

[happyPisces]

@alexforencich
Hi Alex, I have also met timing issue when running corundum on NetFPGA SUME. I added some new placement constraints as flows,
create_pblock pblock_slr0
add_cells_to_pblock [get_pblocks pblock_slr0] [get_cells -quiet [list pcie3_7x_inst/inst]]
resize_pblock [get_pblocks pblock_slr0] -add {SLICE_X166Y319:SLICE_X221Y196}

create_pblock pblock_slr1
add_cells_to_pblock [get_pblocks pblock_slr1] [get_cells -quiet [list core_inst/dma_if_pcie_us_inst]]
add_cells_to_pblock [get_pblocks pblock_slr1] [get_cells -quiet [list core_inst/dma_if_mux_inst]]
resize_pblock [get_pblocks pblock_slr1] -add {SLICE_X118Y349:SLICE_X169Y150}

create_pblock pblock_slr2
add_cells_to_pblock [get_pblocks pblock_slr2] [get_cells -quiet [list sfp_1_pcs_pma_inst]]
resize_pblock [get_pblocks pblock_slr2] -add {SLICE_X171Y499:SLICE_X221Y475}

create_pblock pblock_slr3
add_cells_to_pblock [get_pblocks pblock_slr3] [get_cells -quiet [list core_inst/iface[1].interface_inst]]
resize_pblock [get_pblocks pblock_slr3] -add {SLICE_X106Y324:SLICE_X169Y125}

Some critical paths are eliminated, but some within dma_if_pcie_us_wr_inst and iface[1].interface_inst can still not meet the timing requirements. Do you have an updated version of constraints for NetFPGA?

[alexforencich]

The NetFPGA SUME needs a lot of work. The Virtex 7 FPGA on there is rather old and slow, and some of the changes that have been made since it was initially supported have not helped timing on that part. Once I get variable-length descriptors implemented along with a couple of other odds and ends, I may take another look at what the issue is with the NetFPGA. However, the part is quite a few years old, it might be a better idea to get a board with a newer, faster, and possibly even larger FPGA.