On 18 Dec 2017 08:54:34 GMT, Allan Herriman
<allanherriman@hotmail.com> wrote:
>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
>>>>>>> the
>>>>>>>>>> results will not be repeatable.
>>>>>>>>>
>>>>>>>>> This Xilinx forum thread gives some examples of placement and
>>>>>>>>> routing
>>>>>>> in VHDL:
>>>>>>>>>
>>>>>>>>> https://forums.xilinx.com/t5/UltraScale-Architecture/Gated-ring-
>>>>>>> oscillator/m-p/808774/highlight/true#M5557
>>>>>>>>
>>>>>>>> When you say "routing", it doesn't appear to deal with the actual
>>>>>>> routing.
>>>>>>>> He does mention that the attributes assign specific I/Os on the
>>>>>>>> LUTs
>>>>>>> and so
>>>>>>>> which pin is connected to which is determined. But the routing
>>>>>>>> interconnects still need to be wired up in the chip editor I
>>>>>>>> believe.
>>>>>>>
>>>>>>> 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
>>>>>> details.
>>>>>> 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
>>>>> entails).
>>>>>
>>>>> 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
>>>> suboptimal" routes.
>>>
>>>
>>> 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.
>>>
>>> Oh yes.
>>
>> 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
>> the IOB.
>> Then I think the locking of LUTs (for delay) and the FF to a single
>> CLB
>> 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.
>
>
>library ieee;
>use ieee.std_logic_1164.all;
>library unisim;
>use unisim.vcomponents.all;
>
>
>entity larkin_oneshot is
> generic (
> IOSTANDARD : string := "LVCMOS18"
> );
> port (
> 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.
John
--
John Larkin Highland Technology, Inc
lunatic fringe electronics
Reply by rickman●December 19, 20172017-12-19
Allan Herriman wrote on 12/19/2017 5:11 AM:
> On Mon, 18 Dec 2017 12:07:40 -0500, rickman wrote:
>
>> Allan Herriman wrote on 12/18/2017 3:54 AM:
>>> 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
>>>>>>>>> the
>>>>>>>>>>>> results will not be repeatable.
>>>>>>>>>>>
>>>>>>>>>>> This Xilinx forum thread gives some examples of placement and
>>>>>>>>>>> routing
>>>>>>>>> in VHDL:
>>>>>>>>>>>
>>>>>>>>>>> https://forums.xilinx.com/t5/UltraScale-Architecture/Gated-
> ring-
>>>>>>>>> oscillator/m-p/808774/highlight/true#M5557
>>>>>>>>>>
>>>>>>>>>> When you say "routing", it doesn't appear to deal with the
>>>>>>>>>> actual
>>>>>>>>> routing.
>>>>>>>>>> He does mention that the attributes assign specific I/Os on the
>>>>>>>>>> LUTs
>>>>>>>>> and so
>>>>>>>>>> which pin is connected to which is determined. But the routing
>>>>>>>>>> interconnects still need to be wired up in the chip editor I
>>>>>>>>>> believe.
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>> details.
>>>>>>>> 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 entails).
>>>>>>>
>>>>>>> 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
>>>>>> suboptimal" routes.
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> Oh yes.
>>>>
>>>> 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 the IOB.
>>>> Then I think the locking of LUTs (for delay) and the FF to a single
>>>> CLB
>>>> 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.
>>
>> That's certainly expected.
>>
>>
>>> 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.
>>
>> Interesting. Can you provide any details on the switch box routing,
>> like an image, perhaps?
>
>
> The ratsnest doesn't show much:
> http://www.users.on.net/~julide/larkin_oneshot_1.png
>
> but the routing view shows the switchbox (the rectangle on the right). I
> highlighted the ibuf_output net (which goes back to the FF reset input).
> http://www.users.on.net/~julide/larkin_oneshot_2.png
The routing view doesn't do much to indicate how other routing might
conflict. Looks like they have means internally of cross connecting traces
in the switch box through multiple connections. I believe this is done
through pass transistors rather than buffers, so even if one routing
iteration uses four rather than three connections it won't be much
variation. The concern is if local congestion causes this route to leave
the switch box to use a longer route and/or other switch boxes.
>> Or should I install the tools and try it
>> myself? I've always found the chip editor to be a messy tool to learn,
>> but just looking at stuff hasn't been too hard. My main reason for not
>> wanting to install the Xilinx tools is dealing with the licensing issues
>> that always seem to be a PITA.
>
>
> Small parts (such as the one the OP is using) use the free Webpack
> license. It will call home with usage information. You can always use
> an airgap if you don't like that.
> https://www.xilinx.com/support/download.html
I'm talking about the simple hassle of getting the licensing to work. It's
fine 95% of the time, but that other 5% can be a bear. I just don't look
forward to installing any tools using Flexlm.
>> I don't recall if there are any timing constraints for such an async
>> loop. They are hard for the tools to analyze which is the main reason
>> for avoiding them like the plague. Yes, it can be made to work
>> obviously, but FPGA companies have enough to do without supporting this
>> sort of feature which would open huge cans of worms for them. So short
>> of generating a timing analysis script, there will be no automation for
>> even verifying timing of this path every time you route the design.
>
>
> I'm fairly sure you can constrain any path.
I'd love to see the syntax for this. My understanding is all the
constraints operate on endpoints defined by clocks and I/O pads. Async path
loops can not even be evaluated as the tool reports an async loop as an
error. I have never seen a timing constraint that operates on an arbitrary
route or async path segment.
--
Rick C
Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998
Reply by Allan Herriman●December 19, 20172017-12-19
On Mon, 18 Dec 2017 12:07:40 -0500, rickman wrote:
> Allan Herriman wrote on 12/18/2017 3:54 AM:
>> 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
>>>>>>>> the
>>>>>>>>>>> results will not be repeatable.
>>>>>>>>>>
>>>>>>>>>> This Xilinx forum thread gives some examples of placement and
>>>>>>>>>> routing
>>>>>>>> in VHDL:
>>>>>>>>>>
>>>>>>>>>> https://forums.xilinx.com/t5/UltraScale-Architecture/Gated-
ring-
>>>>>>>> oscillator/m-p/808774/highlight/true#M5557
>>>>>>>>>
>>>>>>>>> When you say "routing", it doesn't appear to deal with the
>>>>>>>>> actual
>>>>>>>> routing.
>>>>>>>>> He does mention that the attributes assign specific I/Os on the
>>>>>>>>> LUTs
>>>>>>>> and so
>>>>>>>>> which pin is connected to which is determined. But the routing
>>>>>>>>> interconnects still need to be wired up in the chip editor I
>>>>>>>>> believe.
>>>>>>>>
>>>>>>>> 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
>>>>>>> details.
>>>>>>> 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 entails).
>>>>>>
>>>>>> 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
>>>>> suboptimal" routes.
>>>>
>>>>
>>>> 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.
>>>>
>>>> Oh yes.
>>>
>>> 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 the IOB.
>>> Then I think the locking of LUTs (for delay) and the FF to a single
>>> CLB
>>> 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.
>
> That's certainly expected.
>
>
>> 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.
>
> Interesting. Can you provide any details on the switch box routing,
> like an image, perhaps?
> Or should I install the tools and try it
> myself? I've always found the chip editor to be a messy tool to learn,
> but just looking at stuff hasn't been too hard. My main reason for not
> wanting to install the Xilinx tools is dealing with the licensing issues
> that always seem to be a PITA.
Small parts (such as the one the OP is using) use the free Webpack
license. It will call home with usage information. You can always use
an airgap if you don't like that.
https://www.xilinx.com/support/download.html
> I don't recall if there are any timing constraints for such an async
> loop. They are hard for the tools to analyze which is the main reason
> for avoiding them like the plague. Yes, it can be made to work
> obviously, but FPGA companies have enough to do without supporting this
> sort of feature which would open huge cans of worms for them. So short
> of generating a timing analysis script, there will be no automation for
> even verifying timing of this path every time you route the design.
I'm fairly sure you can constrain any path.
Allan
Reply by rickman●December 18, 20172017-12-18
Allan Herriman wrote on 12/18/2017 3:54 AM:
> 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
>>>>>>> the
>>>>>>>>>> results will not be repeatable.
>>>>>>>>>
>>>>>>>>> This Xilinx forum thread gives some examples of placement and
>>>>>>>>> routing
>>>>>>> in VHDL:
>>>>>>>>>
>>>>>>>>> https://forums.xilinx.com/t5/UltraScale-Architecture/Gated-ring-
>>>>>>> oscillator/m-p/808774/highlight/true#M5557
>>>>>>>>
>>>>>>>> When you say "routing", it doesn't appear to deal with the actual
>>>>>>> routing.
>>>>>>>> He does mention that the attributes assign specific I/Os on the
>>>>>>>> LUTs
>>>>>>> and so
>>>>>>>> which pin is connected to which is determined. But the routing
>>>>>>>> interconnects still need to be wired up in the chip editor I
>>>>>>>> believe.
>>>>>>>
>>>>>>> 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
>>>>>> details.
>>>>>> 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
>>>>> entails).
>>>>>
>>>>> 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
>>>> suboptimal" routes.
>>>
>>>
>>> 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.
>>>
>>> Oh yes.
>>
>> 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
>> the IOB.
>> Then I think the locking of LUTs (for delay) and the FF to a single
>> CLB
>> 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.
That's certainly expected.
> 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.
Interesting. Can you provide any details on the switch box routing, like an
image, perhaps? Or should I install the tools and try it myself? I've
always found the chip editor to be a messy tool to learn, but just looking
at stuff hasn't been too hard. My main reason for not wanting to install
the Xilinx tools is dealing with the licensing issues that always seem to be
a PITA.
I suspect there aren't too many choices for how to route the signal through
the one switch box. But if the design is not otherwise empty and any of the
switch box paths used in this iteration are used by another route, it may
end up using multiple switch boxes resulting in significant routing delays.
Adding a timing constraint for clock to output won't help with this feedback
path.
I don't recall if there are any timing constraints for such an async loop.
They are hard for the tools to analyze which is the main reason for avoiding
them like the plague. Yes, it can be made to work obviously, but FPGA
companies have enough to do without supporting this sort of feature which
would open huge cans of worms for them. So short of generating a timing
analysis script, there will be no automation for even verifying timing of
this path every time you route the design.
--
Rick C
Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998
Reply by Allan Herriman●December 18, 20172017-12-18
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
>>>>>> the
>>>>>>>>> results will not be repeatable.
>>>>>>>>
>>>>>>>> This Xilinx forum thread gives some examples of placement and
>>>>>>>> routing
>>>>>> in VHDL:
>>>>>>>>
>>>>>>>> https://forums.xilinx.com/t5/UltraScale-Architecture/Gated-ring-
>>>>>> oscillator/m-p/808774/highlight/true#M5557
>>>>>>>
>>>>>>> When you say "routing", it doesn't appear to deal with the actual
>>>>>> routing.
>>>>>>> He does mention that the attributes assign specific I/Os on the
>>>>>>> LUTs
>>>>>> and so
>>>>>>> which pin is connected to which is determined. But the routing
>>>>>>> interconnects still need to be wired up in the chip editor I
>>>>>>> believe.
>>>>>>
>>>>>> 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
>>>>> details.
>>>>> 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
>>>> entails).
>>>>
>>>> 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
>>> suboptimal" routes.
>>
>>
>> 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.
>>
>> Oh yes.
>
> 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
> the IOB.
> Then I think the locking of LUTs (for delay) and the FF to a single
> CLB
> 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.
library ieee;
use ieee.std_logic_1164.all;
library unisim;
use unisim.vcomponents.all;
entity larkin_oneshot is
generic (
IOSTANDARD : string := "LVCMOS18"
);
port (
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
Reply by Les Cargill●December 16, 20172017-12-16
John Larkin wrote:
>
> I have an async signal, call it TRIG, inside a Zynq 7020.
>
<snip>
>
> Any other ideas or comments?
>
>
State machines?
--
Les Cargill
Reply by rickman●December 16, 20172017-12-16
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
>>>>> the
>>>>>>>> results will not be repeatable.
>>>>>>>
>>>>>>> This Xilinx forum thread gives some examples of placement and
>>>>>>> routing
>>>>> in VHDL:
>>>>>>>
>>>>>>> https://forums.xilinx.com/t5/UltraScale-Architecture/Gated-ring-
>>>>> oscillator/m-p/808774/highlight/true#M5557
>>>>>>
>>>>>> When you say "routing", it doesn't appear to deal with the actual
>>>>> routing.
>>>>>> He does mention that the attributes assign specific I/Os on the LUTs
>>>>> and so
>>>>>> which pin is connected to which is determined. But the routing
>>>>>> interconnects still need to be wired up in the chip editor I
>>>>>> believe.
>>>>>
>>>>> 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
>>>> details.
>>>> 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 entails).
>>>
>>> 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
>> suboptimal" routes.
>
>
> 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.
>
> Oh yes.
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 the IOB.
Then I think the locking of LUTs (for delay) and the FF to a single CLB
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.
--
Rick C
Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998
Reply by Allan Herriman●December 16, 20172017-12-16
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
>>>> the
>>>>>>> results will not be repeatable.
>>>>>>
>>>>>> This Xilinx forum thread gives some examples of placement and
>>>>>> routing
>>>> in VHDL:
>>>>>>
>>>>>> https://forums.xilinx.com/t5/UltraScale-Architecture/Gated-ring-
>>>> oscillator/m-p/808774/highlight/true#M5557
>>>>>
>>>>> When you say "routing", it doesn't appear to deal with the actual
>>>> routing.
>>>>> He does mention that the attributes assign specific I/Os on the LUTs
>>>> and so
>>>>> which pin is connected to which is determined. But the routing
>>>>> interconnects still need to be wired up in the chip editor I
>>>>> believe.
>>>>
>>>> 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
>>> details.
>>> 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 entails).
>>
>> 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
> suboptimal" routes.
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.
Oh yes.
Allan
Reply by rickman●December 16, 20172017-12-16
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
>>> the
>>>>>> results will not be repeatable.
>>>>>
>>>>> This Xilinx forum thread gives some examples of placement and routing
>>> in VHDL:
>>>>>
>>>>> https://forums.xilinx.com/t5/UltraScale-Architecture/Gated-ring-
>>> oscillator/m-p/808774/highlight/true#M5557
>>>>
>>>> When you say "routing", it doesn't appear to deal with the actual
>>> routing.
>>>> He does mention that the attributes assign specific I/Os on the LUTs
>>> and so
>>>> which pin is connected to which is determined. But the routing
>>>> interconnects still need to be wired up in the chip editor I believe.
>>>
>>> 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 details.
>> 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 entails).
>
> 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.
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 suboptimal" routes. The
only way to tell is to give it a try.
--
Rick C
Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998
Reply by Allan Herriman●December 16, 20172017-12-16
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
>> the
>>>>> results will not be repeatable.
>>>>
>>>> This Xilinx forum thread gives some examples of placement and routing
>> in VHDL:
>>>>
>>>> https://forums.xilinx.com/t5/UltraScale-Architecture/Gated-ring-
>> oscillator/m-p/808774/highlight/true#M5557
>>>
>>> When you say "routing", it doesn't appear to deal with the actual
>> routing.
>>> He does mention that the attributes assign specific I/Os on the LUTs
>> and so
>>> which pin is connected to which is determined. But the routing
>>> interconnects still need to be wired up in the chip editor I believe.
>>
>> 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 details.
> 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 entails).
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.
> It has been a long time since I opened up a Xilinx chip in the editor,