This kind of design is pretty uncommon, but you are on the right track. To do delay-line type work you will probably need to force both the instantiation of resources you've mentioned, and the placement, otherwise results may not be the same across tooling runs. You've then got the problem that the results will not be consistent across parts, and will be temperature dependant.
The only examples I've seen are in the Altera cookbook to create random number generators (picking up the background/shot noise) using chains of back to back inverters, one per LUT. See pages 102 of the cookbook and the file
random/chain_delay_race.v in their zip. For this application the part/temperature variance doesn't matter and the injection point into the chains is changed during operation to force hazards to occur.
As you mentioned you'll need to find the cells from the vendor's macro library. Taking the part library you linked to, why not use
INV1 primitives? These look much simpler to wire in than
ARI1. For simulation you'll have a simulation library provided by the vendor somewhere in the tools directory - you'll need to add the hunt around for the paths and add to your simulator's import list (not familiar with Microsemi tooling, sorry). I usually find them using
grep -r [primitive] ~/tools/../ or similar over the tools dir :-/
Sometimes a good way to find example instantiations of primitives is to synthesise something high level in Verilog/vhdl then look at the generated netlists to see how it's done.
If your application needs a fixed delay on an input signal, did you notice the built in delay primitives - I see I/O pads have a INPUT_DELAY attribute, so you could perhaps tweak this to save resources?