On Sat, 16 Dec 2017 12:44:35 -0500, rickman wrote:
Allan Herriman wrote on 12/16/2017 11:32 AM:
On Sat, 16 Dec 2017 09:27:37 -0500, rickman wrote:
Allan Herriman wrote on 12/16/2017 4:50 AM:
On Fri, 15 Dec 2017 10:57:50 -0500, rickman wrote:
Allan Herriman wrote on 12/15/2017 5:21 AM:
On Thu, 14 Dec 2017 10:18:25 -0500, rickman wrote:
Allan Herriman wrote on 12/14/2017 6:39 AM:
On Thu, 14 Dec 2017 10:49:41 +0000, Allan Herriman wrote:
The placement and routing is quite easy to control from your
favourite HDL, once you know how. This is important to get
right as otherwise
results will not be repeatable.
This Xilinx forum thread gives some examples of placement and
When you say "routing", it doesn't appear to deal with the actual
He does mention that the attributes assign specific I/Os on the
which pin is connected to which is determined. But the routing
interconnects still need to be wired up in the chip editor I
There is no manual step needed. Once you lock the pins, the
routing will be fixed (to an extent).
"To an extent" is one of those things where the devil is in the
Routing within a block is dedicated and either a path exists or it
doesn't. But routing between blocks is much more flexible and so
subject to variations depending on what the software chooses.
In general, I agree with that. Look sideways at the PAR software or
make a trivial change to the source code and it will do something
completely different, and often something unexpected. Sometimes it
will do something wildly suboptimal.
But in this case, I believe Larkin has just one connection that will
be contained within a single switch box next to the IOB. It will not
use any inter-switchbox routing (with all the uncertainty that
My experience has been that in this particular case (and this
particular case only), locking the pins correctly may remove any
choice the router has, resulting in repeatable routing. (I won't say
repeatable timing, because we still have PVT to worry about.)
Depending on the exact switchbox resources used, this may also
require that other routing be prohibited in that area to work.
Perhaps I should point out that whilst I have done some of this sort
of manual placement and routing recently, I have not done the exact
route of IBUF output to OUTFF clear input. Sometimes there are
quirks that do not become apparent until the design hits the tools.
I guess my work with Xilinx parts is getting old. I didn't remember
the IOB FFs *having* accessible async Clear/Preset inputs which would
have required a FF from the fabric. But I looked at the Xynq data
sheet and the IOB FF have accessible Clear/Preset inputs. So there
will be routing on the general fabric as I expect there is no direct
connection between the input and the Clear pin within the IOB.
I can't try it here (I'm not at work and I deliberately don't have the
tools installed at home) but I believe both signals appear on the same
switchbox, which is about as close to a direct connection as one can
get outside a slice.
As to your presumption of this removing "any choice the router has", I
think that is fallacious. The switch matrix is a general purpose
routing medium and I have seen the tool do, as you say, "wildly
I'm fairly sure that rather than being general purpose, the switch
matrix is sparse and doesn't support all input to output connections.
(The exact details are not documented publicly.) With pin locking, one
can force particular paths through the switchbox. This is based on my
observations of tool behaviour rather than an inspection of the die,
thus there is a chance that it is wrong as you suggest.
Please note that I'm only referring to intra-switchbox routing. All
bets are off once the routing goes outside the local switchbox.
The only way to tell is to give it a try.
You are more familiar with the newer devices than I am. The issue isn't
even if you can get the route through the local switchbox. It is
whether it will always pick the same route. As you say, the switch
matrix is somewhat sparse, but the issue is whether it goes through a
single switchbox or not. I guess we'll find out when John tries it.
I thought the problem was going to be the lack of a reset pin on the IOB
FF which would have forced the use of a fabric FF with routing to/from
Then I think the locking of LUTs (for delay) and the FF to a single
would have been the approach with the best shot at producing a
controlled pulse width even if the routing delay to the IOB would have
been variable. But that can be constrained since it is a path from the
"clock" (trigger input) to the output pin.
I ran an experiment today at work. I used the following VHDL source in
the smallest Kintex 7 part (which has the same fabric as the OP's Zynq).
The net obuf_input (FF Q to pin driver) used dedicated routing and didn't
go through any switchboxes at all.
The net ibuf_output (which connects back to the FF reset input) was
restricted to the local switchbox as expected. It needed multiple passes
though the switchbox though, as clearly this isn't a connection that
Xilinx expects customers to use often.
I didn't check, but I imagine that the path through the switchbox would
change if other routing was also passing through the switchbox (which
does happen in a dense design).
I have not simulated this code or tested it in any way. Use at own risk.
entity larkin_oneshot is
IOSTANDARD : string := "LVCMOS18"
trig : in std_logic;
oneshot_pin : inout std_logic
end entity larkin_oneshot;
architecture rtl of larkin_oneshot is
signal obuf_input : std_logic;
signal ibuf_output : std_logic;
begin -- architecture rtl of entity larkin_oneshot
iobuf_inst : component IOBUF
generic map (
IBUF_LOW_PWR => FALSE,
SLEW => "FAST",
IOSTANDARD => IOSTANDARD
port map (
O => ibuf_output,
IO => oneshot_pin,
I => obuf_input,
T => '0'
oddr_inst : component ODDR
generic map (
DDR_CLK_EDGE => "SAME_EDGE",
SRTYPE => "ASYNC"
port map (
Q => obuf_input,
C => trig,
CE => '1',
D1 => '1',
D2 => '1',
R => ibuf_output
end architecture rtl; -- of entity larkin_oneshot
That's cool. We'll try it and see what it does.