Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 160350

Article: 160350
Subject: Re: FPGA one-shot
From: rickman <gnuarm@gmail.com>
Date: Fri, 15 Dec 2017 00:56:37 -0500
Links: << >>  << T >>  << A >>
krw@notreal.com wrote on 12/14/2017 9:59 PM:
> On Thu, 14 Dec 2017 12:50:30 -0500, rickman <gnuarm@gmail.com> wrote:
>
>> krw@notreal.com wrote on 12/14/2017 10:35 AM:
>>> On Thu, 14 Dec 2017 10:02:25 -0500, rickman <gnuarm@gmail.com> wrote:
>>>
>>>> krw@notreal.com wrote on 12/14/2017 9:12 AM:
>>>>> On Thu, 14 Dec 2017 02:10:06 -0500, rickman <gnuarm@gmail.com> wrote:
>>>>>
>>>>>> John Larkin wrote on 12/13/2017 10:43 PM:
>>>>>>>
>>>>>>> I have an async signal, call it TRIG, inside a Zynq 7020.
>>>>>>>
>>>>>>> At the rising edge of TRIG, I want to make an async one-shot. It will
>>>>>>> leave the chip as RX and reset some outboard ecl logic. Anything from,
>>>>>>> say, 2 ns to 10 ns width would work.
>>>>>>>
>>>>>>> The board is built, and we can't easily add more connections to the
>>>>>>> FPGA or hack in glue logic. Well, it would be ugly.
>>>>>>>
>>>>>>> Here are some ideas:
>>>>>>>
>>>>>>> https://www.dropbox.com/s/4azi5hzkqzsyeiy/FPGA_OneShots.JPG?raw=1
>>>>>>>
>>>>>>> We could play with i/o cell slew rates and drive strengths to tune the
>>>>>>> timing. And use as many delay stages (circuit B) as we like... there
>>>>>>> are tons of unused balls.
>>>>>>>
>>>>>>> Or maybe use some internal delay path, if we can find one that is
>>>>>>> reasonably repeatable.
>>>>>>>
>>>>>>> The compiler will probably let us do circuit A or B without whining
>>>>>>> much, but might object to the third one.
>>>>>>>
>>>>>>> I grew up on async hairball logic, so this seems reasonable to me, but
>>>>>>> my FPGA guys are horrified. We don't want to spin up a 250 MHz PLL
>>>>>>> here and do it synchronously, for various reasons.
>>>>>>>
>>>>>>> An internal passive pullup resistor charging an i/o pin capacitance
>>>>>>> would be fun, but I don't think we could make a short enough blip.
>>>>>>>
>>>>>>> Any other ideas or comments?
>>>>>>
>>>>>> The variation in delay in an FPGA for any given route aren't all that bad,
>>>>>> about the same as with regular logic.
>>>>>
>>>>> It's higher in FPGAs since the wires are longer (higher capacitance),
>>>>> though distance between gates may (or may not) be similar.  The wires
>>>>> in an FPGA are "fixed" length, where they are only as long as needed
>>>>> in an ASIC.  There is also a lot of capacitance from all of the muxes
>>>>> (pass gates) hanging off the wire.  The higher magnitude will mean a
>>>>> higher variation, too.
>>>>>
>>>>>> I assume Xilinx still has a manual
>>>>>> chip editing tool.  It will give you delays of routes.  So you can do a run
>>>>>> of the chip and manually reroute the one delay path to get your time delay.
>>>>>> There are ways to force placement of the FF with attributes in your source
>>>>>> code.  So as long as the routes you need are not used it would be a simple
>>>>>> matter to hand route the same path each time.  Getting a 2 ns minimum pulse
>>>>>> width shouldn't be hard at all.
>>>>>
>>>>> A very poor way of doing things but it may be the only way to make
>>>>> such a kludge.
>>>>>
>>>>>> You seem to be thinking you can tune the loop with I/O pad delays, but that
>>>>>> will still require manual work in the chip editor to make adjustments each
>>>>>> time you get a different route on the delay path and so need different I/O
>>>>>> pad slew rates.
>>>>>>
>>>>>> One other thought is to use some number of LUTs as the main delay element,
>>>>>> there are ways to force the use of such a component in HDL source.  By
>>>>>> constraining the placement to cells that are in the same logic block you
>>>>>> will get consistent route delays and routing variation should go away.  I
>>>>>> believe it is the inter-logic cell routes that have lots of variation.
>>>>>>
>>>>>> The main reason why your FPGA guys are reacting in horror is because they
>>>>>> know what a royal PITA it will be to learn the tools well enough to make all
>>>>>> this happen.
>>>>>
>>>>> Not to mention the maintenance of this kludge for the life of the
>>>>> product.
>>>>
>>>> Something like this was done in test equipment from a major manufacturer.
>>>> They needed to mux a clock and the delay through the chip needed to be
>>>> minimal.  I don't recall if the LUT was hand placed or not, but the routing
>>>> was done by hand in the chip editor.  I found out about it because we had to
>>>> touch the chip.  My boss was the guy who had originally done this and not
>>>> documented a single thing on it.  He gave a demonstration on how to do the
>>>> hand mod to few of us and that was how he passed the torch, by oral
>>>> tradition.  lol
>>>
>>> What a wonderful way to run a company.  I assume they're no longer in
>>> business?
>>
>> Ever hear of TTC?
>
> No.  I think I know why.
>
>> I was interviewed with TTC but came on board Acterna.
>> TTC merged with Dynatech and WWG along with nearly a billion in debt which
>> ultimately sunk the company, not anything about their designs.  I believe
>> TTC was very well respected in the test equipment world.  I don't know who
>> bought the pieces.
>
> Makes complete sense.  Knowledge locked up in someone's head =>
> company in pieces.

You didn't read a word I wrote.  The company failed because like so many in 
the dot com bubble they didn't see it was a bubble and borrowed a shit-ton 
of money to expand, then when the bubble burst they couldn't pay the debt. 
it had nothing to do with the dick-head I had for a boss.

The dick-head came from the company's history developing as a startup and 
having loose engineering management principles.  So he didn't know any 
better because they never taught him any better.  But the company was a 
technical success.  Ask anyone who works in telecom if they've ever used a 
T-BERD.  It is highly regarded test equipment from what I've heard and very 
widely used.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Article: 160351
Subject: Re: FPGA one-shot
From: Allan Herriman <allanherriman@hotmail.com>
Date: 15 Dec 2017 10:21:42 GMT
Links: << >>  << T >>  << A >>
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).

I haven't done manual routing on an FPGA since the '90s.

I haven't done manual placement for a few months.  Even then, it was all 
in the form of relative placements in HDL, so the tools still have the 
ability to move the entire macro around on the die.

Allan

Article: 160352
Subject: Re: FPGA one-shot
From: krw@notreal.com
Date: Fri, 15 Dec 2017 07:19:06 -0500
Links: << >>  << T >>  << A >>
On Fri, 15 Dec 2017 00:56:37 -0500, rickman <gnuarm@gmail.com> wrote:

>krw@notreal.com wrote on 12/14/2017 9:59 PM:
>> On Thu, 14 Dec 2017 12:50:30 -0500, rickman <gnuarm@gmail.com> wrote:
>>
>>> krw@notreal.com wrote on 12/14/2017 10:35 AM:
>>>> On Thu, 14 Dec 2017 10:02:25 -0500, rickman <gnuarm@gmail.com> wrote:
>>>>
>>>>> krw@notreal.com wrote on 12/14/2017 9:12 AM:
>>>>>> On Thu, 14 Dec 2017 02:10:06 -0500, rickman <gnuarm@gmail.com> wrote:
>>>>>>
>>>>>>> John Larkin wrote on 12/13/2017 10:43 PM:
>>>>>>>>
>>>>>>>> I have an async signal, call it TRIG, inside a Zynq 7020.
>>>>>>>>
>>>>>>>> At the rising edge of TRIG, I want to make an async one-shot. It will
>>>>>>>> leave the chip as RX and reset some outboard ecl logic. Anything from,
>>>>>>>> say, 2 ns to 10 ns width would work.
>>>>>>>>
>>>>>>>> The board is built, and we can't easily add more connections to the
>>>>>>>> FPGA or hack in glue logic. Well, it would be ugly.
>>>>>>>>
>>>>>>>> Here are some ideas:
>>>>>>>>
>>>>>>>> https://www.dropbox.com/s/4azi5hzkqzsyeiy/FPGA_OneShots.JPG?raw=1
>>>>>>>>
>>>>>>>> We could play with i/o cell slew rates and drive strengths to tune the
>>>>>>>> timing. And use as many delay stages (circuit B) as we like... there
>>>>>>>> are tons of unused balls.
>>>>>>>>
>>>>>>>> Or maybe use some internal delay path, if we can find one that is
>>>>>>>> reasonably repeatable.
>>>>>>>>
>>>>>>>> The compiler will probably let us do circuit A or B without whining
>>>>>>>> much, but might object to the third one.
>>>>>>>>
>>>>>>>> I grew up on async hairball logic, so this seems reasonable to me, but
>>>>>>>> my FPGA guys are horrified. We don't want to spin up a 250 MHz PLL
>>>>>>>> here and do it synchronously, for various reasons.
>>>>>>>>
>>>>>>>> An internal passive pullup resistor charging an i/o pin capacitance
>>>>>>>> would be fun, but I don't think we could make a short enough blip.
>>>>>>>>
>>>>>>>> Any other ideas or comments?
>>>>>>>
>>>>>>> The variation in delay in an FPGA for any given route aren't all that bad,
>>>>>>> about the same as with regular logic.
>>>>>>
>>>>>> It's higher in FPGAs since the wires are longer (higher capacitance),
>>>>>> though distance between gates may (or may not) be similar.  The wires
>>>>>> in an FPGA are "fixed" length, where they are only as long as needed
>>>>>> in an ASIC.  There is also a lot of capacitance from all of the muxes
>>>>>> (pass gates) hanging off the wire.  The higher magnitude will mean a
>>>>>> higher variation, too.
>>>>>>
>>>>>>> I assume Xilinx still has a manual
>>>>>>> chip editing tool.  It will give you delays of routes.  So you can do a run
>>>>>>> of the chip and manually reroute the one delay path to get your time delay.
>>>>>>> There are ways to force placement of the FF with attributes in your source
>>>>>>> code.  So as long as the routes you need are not used it would be a simple
>>>>>>> matter to hand route the same path each time.  Getting a 2 ns minimum pulse
>>>>>>> width shouldn't be hard at all.
>>>>>>
>>>>>> A very poor way of doing things but it may be the only way to make
>>>>>> such a kludge.
>>>>>>
>>>>>>> You seem to be thinking you can tune the loop with I/O pad delays, but that
>>>>>>> will still require manual work in the chip editor to make adjustments each
>>>>>>> time you get a different route on the delay path and so need different I/O
>>>>>>> pad slew rates.
>>>>>>>
>>>>>>> One other thought is to use some number of LUTs as the main delay element,
>>>>>>> there are ways to force the use of such a component in HDL source.  By
>>>>>>> constraining the placement to cells that are in the same logic block you
>>>>>>> will get consistent route delays and routing variation should go away.  I
>>>>>>> believe it is the inter-logic cell routes that have lots of variation.
>>>>>>>
>>>>>>> The main reason why your FPGA guys are reacting in horror is because they
>>>>>>> know what a royal PITA it will be to learn the tools well enough to make all
>>>>>>> this happen.
>>>>>>
>>>>>> Not to mention the maintenance of this kludge for the life of the
>>>>>> product.
>>>>>
>>>>> Something like this was done in test equipment from a major manufacturer.
>>>>> They needed to mux a clock and the delay through the chip needed to be
>>>>> minimal.  I don't recall if the LUT was hand placed or not, but the routing
>>>>> was done by hand in the chip editor.  I found out about it because we had to
>>>>> touch the chip.  My boss was the guy who had originally done this and not
>>>>> documented a single thing on it.  He gave a demonstration on how to do the
>>>>> hand mod to few of us and that was how he passed the torch, by oral
>>>>> tradition.  lol
>>>>
>>>> What a wonderful way to run a company.  I assume they're no longer in
>>>> business?
>>>
>>> Ever hear of TTC?
>>
>> No.  I think I know why.
>>
>>> I was interviewed with TTC but came on board Acterna.
>>> TTC merged with Dynatech and WWG along with nearly a billion in debt which
>>> ultimately sunk the company, not anything about their designs.  I believe
>>> TTC was very well respected in the test equipment world.  I don't know who
>>> bought the pieces.
>>
>> Makes complete sense.  Knowledge locked up in someone's head =>
>> company in pieces.
>
>You didn't read a word I wrote.

You're lying, as always.

>The company failed because like so many in 
>the dot com bubble they didn't see it was a bubble and borrowed a shit-ton 
>of money to expand, then when the bubble burst they couldn't pay the debt. 
>it had nothing to do with the dick-head I had for a boss.

No, they failed because their business practices sucked and their
people sucked more.

>The dick-head came from the company's history developing as a startup and 
>having loose engineering management principles.  So he didn't know any 
>better because they never taught him any better.  But the company was a 
>technical success.  Ask anyone who works in telecom if they've ever used a 
>T-BERD.  It is highly regarded test equipment from what I've heard and very 
>widely used.

So you agree with me.  Funny that.


Article: 160353
Subject: Re: FPGA one-shot
From: krw@notreal.com
Date: Fri, 15 Dec 2017 07:21:46 -0500
Links: << >>  << T >>  << A >>
On 15 Dec 2017 10:21:42 GMT, Allan Herriman
<allanherriman@hotmail.com> wrote:

>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).

Nonsense.  The next release of the routing software, or even the next
modification to the HDL may completely change the routing.
>
>I haven't done manual routing on an FPGA since the '90s.

Have you tuned for exact timing of asynchronous timing?

>I haven't done manual placement for a few months.  Even then, it was all 
>in the form of relative placements in HDL, so the tools still have the 
>ability to move the entire macro around on the die.

...and you're not controlling the largest variable, the routing.

Article: 160354
Subject: Re: FPGA one-shot
From: rickman <gnuarm@gmail.com>
Date: Fri, 15 Dec 2017 10:57:50 -0500
Links: << >>  << T >>  << A >>
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.

It has been a long time since I opened up a Xilinx chip in the editor, but 
the interconnects have always been in levels.  There are direct links 
between adjacent blocks, north, east, south and west.  These are the fastest 
and not subject to much variation from routing choices since there aren't 
any choices other than use them or not.

See the diagonal traces between blocks in the chip editor image in the link 
you provided?  Those will not be direct traces.  The software will have to 
pick a route through the routing matrix which can be very different from run 
to run.  When the circuit has an async feedback path, the software can't 
time it, so there is no way to place a timing constraint to make it use a 
faster path.  So the tools won't help you here.  This has to be addressed 
manually on each run of the tools.

You might be able to put together a script to semi-automate it, but you will 
need to handle this outside of the normal automated tool usage.  It should 
be completely documented so it can be repeated anytime the device is touched.


> I haven't done manual routing on an FPGA since the '90s.
>
> I haven't done manual placement for a few months.  Even then, it was all
> in the form of relative placements in HDL, so the tools still have the
> ability to move the entire macro around on the die.

Placement is easy, it can be done in the HDL.  Routing is another matter 
altogether.

There are (or were) things called "hard" macros.  This is a piece of logic 
with routing that is already done and can be dropped into a design as an 
entity.  I don't know if they are supported in HDL.  I don't know they are 
still supported at all.  Their down side is that nothing could be routed 
through the hard macro since the tools have no idea what can be used and 
what can't.  I suspect it was just too hard a problem to deal with for the 
routing tools to work optimally.  This is similar to the issues of partial 
reconfiguration.  The partial reconfiguration was the easy part.  Developing 
tools to support designing modules to use in partial reconfiguration was the 
hard part.  Same problem, getting the tools to effectively route in just a 
portion of the chip.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Article: 160355
Subject: Re: FPGA one-shot
From: Allan Herriman <allanherriman@hotmail.com>
Date: 16 Dec 2017 09:50:23 GMT
Links: << >>  << T >>  << A >>
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,

'nuf said.


Allan

Article: 160356
Subject: Re: FPGA one-shot
From: rickman <gnuarm@gmail.com>
Date: Sat, 16 Dec 2017 09:27:37 -0500
Links: << >>  << T >>  << A >>
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

Article: 160357
Subject: Re: FPGA one-shot
From: Allan Herriman <allanherriman@hotmail.com>
Date: 16 Dec 2017 16:32:24 GMT
Links: << >>  << T >>  << A >>
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

Article: 160358
Subject: Re: FPGA one-shot
From: rickman <gnuarm@gmail.com>
Date: Sat, 16 Dec 2017 12:44:35 -0500
Links: << >>  << T >>  << A >>
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

Article: 160359
Subject: Re: FPGA one-shot
From: Les Cargill <lcargill99@comcast.com>
Date: Sat, 16 Dec 2017 11:59:51 -0600
Links: << >>  << T >>  << A >>
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


Article: 160360
Subject: Re: FPGA one-shot
From: Allan Herriman <allanherriman@hotmail.com>
Date: 18 Dec 2017 08:54:34 GMT
Links: << >>  << T >>  << A >>
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

Article: 160361
Subject: Re: FPGA one-shot
From: rickman <gnuarm@gmail.com>
Date: Mon, 18 Dec 2017 12:07:40 -0500
Links: << >>  << T >>  << A >>
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

Article: 160362
Subject: Re: FPGA one-shot
From: Allan Herriman <allanherriman@hotmail.com>
Date: 19 Dec 2017 10:11:55 GMT
Links: << >>  << T >>  << A >>
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


> 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

Article: 160363
Subject: Re: FPGA one-shot
From: rickman <gnuarm@gmail.com>
Date: Tue, 19 Dec 2017 09:30:54 -0500
Links: << >>  << T >>  << A >>
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

Article: 160364
Subject: Re: FPGA one-shot
From: John Larkin <jjlarkin@highlandtechnology.com>
Date: Tue, 19 Dec 2017 07:29:40 -0800
Links: << >>  << T >>  << A >>
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 


Article: 160365
Subject: Re: FPGA motherboard for 80386 CPU
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 20 Dec 2017 05:49:27 -0800 (PST)
Links: << >>  << T >>  << A >>
On Monday, November 13, 2017 at 3:06:44 PM UTC-5, lasselangwad...@gmail.com wrote:
> Den mandag den 13. november 2017 kl. 20.54.12 UTC+1 skrev Rick C. Hodgin:
> > On Monday, November 13, 2017 at 2:47:48 PM UTC-5, lasselangwad...@gmail.com wrote:
> > > Den mandag den 13. november 2017 kl. 17.49.15 UTC+1 skrev Rick C. Hodgin:
> > > > On Monday, November 13, 2017 at 11:28:09 AM UTC-5, lasselangwad...@gmail.com wrote:
> > > > > Den fredag den 10. november 2017 kl. 23.03.06 UTC+1 skrev Rick C. Hodgin:
> > > > > > > then you should probably start with a basic verilog project with some blinking leds and not a giant hairball of a CISC cpu...
> > > > > > 
> > > > > > I've done that.  I've made the KITT car red light thing.  I've 
> > > > > > responded to buttons.  I've debounced inputs.  An on Arduino, 
> > > > > > which is basically C code, I've made tone generators, sent output
> > > > > > on a clock to a remote device on 18 pins, etc.
> > > > > 
> > > > > any of that in verilog?
> > > > 
> > > > Yes.  Using Lattice's Diamond software on a Lattice XP2 Brevia board:
> > > 
> > > writing verilog or copy-pasting verilog ?
> > 
> > Writing Verilog.  I've also written a CPU core that synthesized in
> > Altera's Quartus II software, but I never debugged it and I have no
> > idea if it actually works:
> > 
> >     http://libsf.org:8990/projects/LIB/repos/libsf/browse/arxoda/oppie/oppie1/oppie1.v
> > 
> >     http://libsf.org:8990/projects/LIB/repos/libsf/browse/arxoda/oppie/oppie1/debo-1-actual.png
> > 
> >     http://libsf.org:8990/projects/LIB/repos/libsf/browse/arxoda/oppie/oppie-1.png
> > 
> > > anyway, 99% of such a project will be done in a simulator
> > 
> > That would be great.  How do I do it?  What tools are available for
> > the Alter Cyclone V GX Starter Kit toolset?
> 
> what's wrong with icarus iverilog? no point in looking at specific boards or fpgas until you have it working in a simulator

How would I get a project like this working in simulation first?  I'm
going to be reading real input from another piece of hardware.  I'll
be giving it a clock signal, and responding to events based on whatever
it's doing.

About the only real ability I have to control the CPU is in the clock
signal, which I should be able to step as needed on the Am386 part,
which is static.

Would I build a state machine and give it sample inputs and make sure
it's all working?  What if the state machine I build does not match
what I find in the real-world Am386 hardware protocols?

I'm expecting to find a lot of things it does that are non-standard.
I am expecting to be able to capture and code for each of them one-
by-one, with the bulk of the design being as predicted.

-- 
Rick C. Hodgin

Article: 160366
Subject: Re: FPGA motherboard for 80386 CPU
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 21 Dec 2017 01:33:37 -0800 (PST)
Links: << >>  << T >>  << A >>
On Monday, November 13, 2017 at 3:15:12 PM UTC-5, Rick C. Hodgin wrote:
> On Monday, November 13, 2017 at 3:06:44 PM UTC-5, lasselangwad...@gmail.com wrote:
> > what's wrong with icarus iverilog? no point in looking at specific boards or fpgas until you have it working in a simulator
> 
> I've found the tools clunky.  I want to see some kind of visualization
> like this:
> 
>     http://www.visual6502.org/JSSim/index.html
> 
> Which produces information on runtime like this:
> 
>     http://www.visual6502.org/JSSim/expert.html
> 
> And produces some kind of output like this:
> 
>     (click the "Trace More" button many times)
> 
> -----
> The reason I stopped working in Verilog was because I found it textual
> and confusing.  I had intended to write my Logician tool, which would
> be a Blender node-like arrangement of hardware, allowing me to sample
> all data lines, and visualize it as with the 6502 visualization.
> 
>     Blender Node Editor (at 1:18 and after):
>     https://www.youtube.com/watch?v=sc-ptGft9Vk&t=1m18s
> 
> I haven't had time to do it yet, but there must be some tool closer
> to that out there.  If not, that's where we should start (writing
> that tool for people to use).

I came across this toolset from ARM recently.

This is almost exactly what I envisioned Logician's interface 
looking like at 2:15:
    https://www.youtube.com/watch?v=n9cUiEdqdJU&t=2m15s

Specifically here at 2:36:
    https://www.youtube.com/watch?v=n9cUiEdqdJU&t=2m36s

The drag-and-drop / "connect noodles" approach is what I
envisioned from Blender.  So, this tool has almost exactly
what I'm looking for.

Except ... I do not like seeing outputs like these at 1:32:
    https://www.youtube.com/watch?v=n9cUiEdqdJU&t=1m32s

The idea is:  I work in direct models of hardware units, and 
the tool generates the required source code for me.

-- 
Rick C. Hodgin 

Article: 160367
Subject: Re: FPGA motherboard for 80386 CPU
From: Richard Damon <Richard@Damon-Family.org>
Date: Fri, 22 Dec 2017 19:23:21 -0500
Links: << >>  << T >>  << A >>
On 12/21/17 4:33 AM, Rick C. Hodgin wrote:
> On Monday, November 13, 2017 at 3:15:12 PM UTC-5, Rick C. Hodgin wrote:
>> On Monday, November 13, 2017 at 3:06:44 PM UTC-5, lasselangwad...@gmail.com wrote:
>>> what's wrong with icarus iverilog? no point in looking at specific boards or fpgas until you have it working in a simulator
>>
>> I've found the tools clunky.  I want to see some kind of visualization
>> like this:
>>
>>      http://www.visual6502.org/JSSim/index.html
>>
>> Which produces information on runtime like this:
>>
>>      http://www.visual6502.org/JSSim/expert.html
>>
>> And produces some kind of output like this:
>>
>>      (click the "Trace More" button many times)
>>
>> -----
>> The reason I stopped working in Verilog was because I found it textual
>> and confusing.  I had intended to write my Logician tool, which would
>> be a Blender node-like arrangement of hardware, allowing me to sample
>> all data lines, and visualize it as with the 6502 visualization.
>>
>>      Blender Node Editor (at 1:18 and after):
>>      https://www.youtube.com/watch?v=sc-ptGft9Vk&t=1m18s
>>
>> I haven't had time to do it yet, but there must be some tool closer
>> to that out there.  If not, that's where we should start (writing
>> that tool for people to use).
> 
> I came across this toolset from ARM recently.

The Tool in the video is NOT from ARM, but is the Xilinx FPGA tool, and 
since some of their FPGAs include a hard core embedded ARM (actually 2), 
and others can create cores within the fabric, the tool provides a good 
environment for building systems around ARM cores, so you cal learn the 
protocols in the cores. There are also a number of peripheral cores 
provided to interface with the processor core provided.

Most of the major FPGA manufactures (at least those with FPGAs big 
enough to have a processor core) have similar pieces in their tools.
> 
> This is almost exactly what I envisioned Logician's interface
> looking like at 2:15:
>      https://www.youtube.com/watch?v=n9cUiEdqdJU&t=2m15s
> 
> Specifically here at 2:36:
>      https://www.youtube.com/watch?v=n9cUiEdqdJU&t=2m36s
> 
> The drag-and-drop / "connect noodles" approach is what I
> envisioned from Blender.  So, this tool has almost exactly
> what I'm looking for.
> 
> Except ... I do not like seeing outputs like these at 1:32:
>      https://www.youtube.com/watch?v=n9cUiEdqdJU&t=1m32s

How else do you want to present the state of signals changing over time?
> 
> The idea is:  I work in direct models of hardware units, and
> the tool generates the required source code for me.
> 

This sort of interface has been around for what, maybe 30 years or more 
(I used a similar graphical interface in the mid 80's for designing 
parts of FPGAs).

These tools generally allow you to mix representations over layers, a 
block in the graphical form can underneath be another graphical sheet, 
or a textual module. And textual module can reference other textual 
modules or graphical modules (actually, under the hood, the system 
parses the graphical design and creates a textual module that get passed 
to the synthesis program).

Article: 160368
Subject: Re: FPGA motherboard for 80386 CPU
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sun, 24 Dec 2017 14:04:15 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, December 22, 2017 at 7:23:27 PM UTC-5, Richard Damon wrote:
> On 12/21/17 4:33 AM, Rick C. Hodgin wrote:
> > I came across this toolset from ARM recently.
> 
> The Tool in the video is NOT from ARM, but is the Xilinx FPGA tool, and 
> since some of their FPGAs include a hard core embedded ARM (actually 2), 
> and others can create cores within the fabric, the tool provides a good 
> environment for building systems around ARM cores, so you cal learn the 
> protocols in the cores. There are also a number of peripheral cores 
> provided to interface with the processor core provided.
> 
> Most of the major FPGA manufactures (at least those with FPGAs big 
> enough to have a processor core) have similar pieces in their tools.

I saw it on the ARM video linked below.  My apologies for mis-ascribing
it.  It's part of their ARM Education Media program.  I have never used
Xilinx FPGAs.  Only Lattice and .

> > This is almost exactly what I envisioned Logician's interface
> > looking like at 2:15:
> >      https://www.youtube.com/watch?v=n9cUiEdqdJU&t=2m15s
> > 
> > Specifically here at 2:36:
> >      https://www.youtube.com/watch?v=n9cUiEdqdJU&t=2m36s
> > 
> > The drag-and-drop / "connect noodles" approach is what I
> > envisioned from Blender.  So, this tool has almost exactly
> > what I'm looking for.
> > 
> > Except ... I do not like seeing outputs like these at 1:32:
> >      https://www.youtube.com/watch?v=n9cUiEdqdJU&t=1m32s
> 
> How else do you want to present the state of signals changing over
> time?

As in the 6502 simulation, with the ability to then graph the outputs in
the standard form, but I want to see things by value, by logical port,
by time, by change.

> > The idea is:  I work in direct models of hardware units, and
> > the tool generates the required source code for me.
> > 
> 
> This sort of interface has been around for what, maybe 30 years or more 
> (I used a similar graphical interface in the mid 80's for designing 
> parts of FPGAs).
> 
> These tools generally allow you to mix representations over layers, a 
> block in the graphical form can underneath be another graphical sheet, 
> or a textual module. And textual module can reference other textual 
> modules or graphical modules (actually, under the hood, the system 
> parses the graphical design and creates a textual module that get passed 
> to the synthesis program).

I have seen a couple in the Quartus tool and Lattice has something
that is GUI-based, but they are not quite on the same level of use as
the one show in the ARM video.

I may be reading more into the ARM video presentation than actually
exists as I have had a vision in my mind of what I want Logician to
look like, and may be projecting that vision onto the Xilinx tools.

-- 
Rick C. Hodgin

Article: 160369
Subject: Re: FPGA motherboard for 80386 CPU
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 28 Dec 2017 07:32:03 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, November 10, 2017 at 10:35:44 AM UTC-5, Rick C. Hodgin wrote:
> The 80386DX CPU had 132 pins:
> 
>     80386DX and 80386SX pinouts:
>     http://www.rfwireless-world.com/images/80386-pin-diagram.jpg
>     https://image.slidesharecdn.com/salientfeatursof80386-140822084001-phpapp02/95/salient-featurs-of-80386-14-638.jpg?cb=1408709884
> 
>     General architecture:
>     http://www.nptel.ac.in/courses/Webcourse-contents/IISc-BANG/Microprocessors%20and%20Microcontrollers/pdf/Teacher_Slides/mod8/M8L1.pdf
> 
> Of these pins on the DX variant:
> 
>     32 pins -- data
>     30 pins -- address
>      4 pins -- byte enables in 32-bit writes
>      1 pin  -- Read/write
>      1 pin  -- Data/Control
>      1 pin  -- Memory/IO
>      1 pin  -- Bus mastering lock issued by CPU
>      1 pin  -- Bus16 size (16-bit when asserted, normally 32-bit)
>      1 pin  -- Next address (for pipelining)
>      1 pin  -- Address valid signal
>     --
>     73 pins -- For basic I/O
> 
>      3 pins -- Math-coprocessor support
>      1 pin  -- Ready (or Wait, for bus cycles to complete)
>      2 pins -- Hold and Hold Acknowledge (for bus mastering)
>      2 pins -- Interrupt and Non-masktable Interrupt
>     --
>      8 pins -- General coordination with external peripherals
> 
>      1 pin  -- Reset
>      1 pin  -- Double-pumped clock
>     --
>      2 pins -- System input
> 
> The rest of the pins are unused, go to VSS or VCC.  This means that for a
> full 80386 "motherboard" only 83 pins are required to fully support its
> operation, 67 of which are address, data, and data type, leaving really
> only 15 pins of complex operation for a state machine.
> 
> -----
> Would anybody be able to help me create this 80386 motherboard using an
> AMD Am386 CPU, which is a static CPU operating from 0 to 40 MHz?  I would
> like to get it working with a single-step operation for design validation,
> and then to begin ramping it up.
> 
> I figure I'll have an area of ROM which the CPU boots to load, which is a
> tiny real mode program, which begins computing something that can be exam-
> ined by the FPGA to test successful operation.  And then move on to more
> complex operations, including a custom microkernel.

What is a reliable provider for me to download design tools and make
this board?  And are there providers that can do the soldering for me
as part of the price?

-- 
Rick C. Hodgin

Article: 160370
Subject: Re: FPGA motherboard for 80386 CPU
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sat, 30 Dec 2017 09:54:33 -0800 (PST)
Links: << >>  << T >>  << A >>
On Thursday, December 28, 2017 at 10:32:09 AM UTC-5, Rick C. Hodgin wrote:
> What is a reliable provider for me to download design tools and make
> this board?  And are there providers that can do the soldering for me
> as part of the price?

Does anybody have any advice?  If not here, where should I go to get
information about custom boards designed to use with my Altera FPGA?

-- 
Rick C. Hodgin

Article: 160371
Subject: Re: FPGA motherboard for 80386 CPU
From: Richard Damon <Richard@Damon-Family.org>
Date: Sat, 30 Dec 2017 15:18:30 -0500
Links: << >>  << T >>  << A >>
On 12/30/17 12:54 PM, Rick C. Hodgin wrote:
> On Thursday, December 28, 2017 at 10:32:09 AM UTC-5, Rick C. Hodgin wrote:
>> What is a reliable provider for me to download design tools and make
>> this board?  And are there providers that can do the soldering for me
>> as part of the price?
> 
> Does anybody have any advice?  If not here, where should I go to get
> information about custom boards designed to use with my Altera FPGA?
> 
I am sure there are numerous 'maker' sites that could help you get 
tools, designed, fabricate, and assemble such a board. I can't recommend 
any in particular, as that isn't the sort of service I use, as I tend to 
use higher level boards and larger volumes, so my providers aren't as 
cost effective as they could be for your make one project.

Article: 160372
Subject: Re: FPGA motherboard for 80386 CPU
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sun, 31 Dec 2017 00:20:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Saturday, December 30, 2017 at 3:18:36 PM UTC-5, Richard Damon wrote:
> On 12/30/17 12:54 PM, Rick C. Hodgin wrote:
> > On Thursday, December 28, 2017 at 10:32:09 AM UTC-5, Rick C. Hodgin wrote:
> >> What is a reliable provider for me to download design tools and make
> >> this board?  And are there providers that can do the soldering for me
> >> as part of the price?
> > 
> > Does anybody have any advice?  If not here, where should I go to get
> > information about custom boards designed to use with my Altera FPGA?
>
> I am sure there are numerous 'maker' sites that could help you get 
> tools, designed, fabricate, and assemble such a board. I can't recommend 
> any in particular, as that isn't the sort of service I use, as I tend to 
> use higher level boards and larger volumes, so my providers aren't as 
> cost effective as they could be for your make one project.

I will try this company:

    https://www.expresspcb.com

-- 
Rick C. Hodgin

Article: 160373
Subject: Re: FPGA motherboard for 80386 CPU
From: Emilian Miron <emilian.miron@gmail.com>
Date: Sun, 31 Dec 2017 07:20:57 -0800 (PST)
Links: << >>  << T >>  << A >>
I've had very good experiences using Oshpark:
https://oshpark.com/

Also, the newest Kicad is very good with push&shove routing.

On Sunday, December 31, 2017 at 3:20:12 AM UTC-5, Rick C. Hodgin wrote:
> On Saturday, December 30, 2017 at 3:18:36 PM UTC-5, Richard Damon wrote:
> > On 12/30/17 12:54 PM, Rick C. Hodgin wrote:
> > > On Thursday, December 28, 2017 at 10:32:09 AM UTC-5, Rick C. Hodgin wrote:
> > >> What is a reliable provider for me to download design tools and make
> > >> this board?  And are there providers that can do the soldering for me
> > >> as part of the price?
> > > 
> > > Does anybody have any advice?  If not here, where should I go to get
> > > information about custom boards designed to use with my Altera FPGA?
> >
> > I am sure there are numerous 'maker' sites that could help you get 
> > tools, designed, fabricate, and assemble such a board. I can't recommend 
> > any in particular, as that isn't the sort of service I use, as I tend to 
> > use higher level boards and larger volumes, so my providers aren't as 
> > cost effective as they could be for your make one project.
> 
> I will try this company:
> 
>     https://www.expresspcb.com
> 
> -- 
> Rick C. Hodgin


Article: 160374
Subject: Re: FPGA motherboard for 80386 CPU
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sun, 31 Dec 2017 13:52:25 -0800 (PST)
Links: << >>  << T >>  << A >>
On Sunday, December 31, 2017 at 10:21:02 AM UTC-5, Emilian Miron wrote:
> I've had very good experiences using Oshpark:
> https://oshpark.com/
> 
> Also, the newest Kicad is very good with push&shove routing.

Thank you, Emilian.  I'll go with them.

> On Sunday, December 31, 2017 at 3:20:12 AM UTC-5, Rick C. Hodgin wrote:
> > On Saturday, December 30, 2017 at 3:18:36 PM UTC-5, Richard Damon wrote:
> > > On 12/30/17 12:54 PM, Rick C. Hodgin wrote:
> > > > On Thursday, December 28, 2017 at 10:32:09 AM UTC-5, Rick C. Hodgin wrote:
> > > >> What is a reliable provider for me to download design tools and make
> > > >> this board?  And are there providers that can do the soldering for me
> > > >> as part of the price?
> > > > 
> > > > Does anybody have any advice?  If not here, where should I go to get
> > > > information about custom boards designed to use with my Altera FPGA?
> > >
> > > I am sure there are numerous 'maker' sites that could help you get 
> > > tools, designed, fabricate, and assemble such a board. I can't recommend 
> > > any in particular, as that isn't the sort of service I use, as I tend to 
> > > use higher level boards and larger volumes, so my providers aren't as 
> > > cost effective as they could be for your make one project.
> > 
> > I will try this company:
> > 
> >     https://www.expresspcb.com

-- 
Rick C. Hodgin



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search