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
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 159875

Article: 159875
Subject: Re: FPGA as heater
From: lasselangwadtchristensen@gmail.com
Date: Wed, 12 Apr 2017 15:09:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
Den onsdag den 12. april 2017 kl. 22.20.19 UTC+2 skrev John Larkin:
> On Wed, 12 Apr 2017 12:37:59 -0700 (PDT), Kevin Neilson
> <kevin.neilson@xilinx.com> wrote:
>=20
> >> > If you really need to control output delay you can use the IODELAY b=
lock, possibly along with a copper trace feedback line.
> >>=20
> >>=20
> >> Our output data-valid window is predicted by the tools to be very
> >> narrow relative to the clock period. We figure that controlling the
> >> temperature (and maybe controlling Vcc-core vs temperature) will open
> >> up the timing window. The final analysis will have to be experimental.
> >>=20
> >> We can't crank in a constant delay to fix anything; the problem is the
> >> predicted variation in delay.
> >>=20
> >
> >I still think the IODELAY could help you.  The output goes through an ad=
justable IODELAY, then you route the output back in through a pin, adjust t=
he input IODELAY to figure out where the incoming edge is, and then use a f=
eedback loop to keep the output delay constant.  It's a technique used for =
deskewing DRAM data.  I think the main clock would also have to be deskewed=
 with a BUFG so you have a good reference for the input.  Or, if you charac=
terized the delay-vs-temp in the lab, you could run in open-loop mode by ad=
justing the IODELAY tap based on the temperature you read.=20
> >
> >Yes, the tools are definitely pessimistic.  They're only useful for wors=
t-case.  I'm pretty sure you can put in the max temperature when doing PAR,=
 so you could isolate the effects of just that, but it will still probably =
be worse variation than in reality.
>=20
> My FPGA guy says that the ZYNQ does not have adjustable delay after
> the i/o block flops. We can vary drive strength in four steps, and we
> may be able to do something with that.

you are right the 7010 and 7020 only have high range IO so no odelay

are you just trying to keep a fixed alignment between clock and data output=
?

you can do tricks with DDR output flops, data out with a DDR with both inpu=
ts
as data, clock out with a DDR with 0,1 as input

-Lasse



Article: 159876
Subject: Re: FPGA as heater
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Wed, 12 Apr 2017 15:22:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
> My FPGA guy says that the ZYNQ does not have adjustable delay after
> the i/o block flops. We can vary drive strength in four steps, and we
> may be able to do something with that.
> 

Hmm.  I've used a real-time-adjustable ODELAY block, but that wasn't in a Zynq.

If you can add more hardware to the board, you could re-register the data in some external 74LS flops.

You could use unregistered outputs and make your own delay line with a carry chain, which you can create with behavioral code.


Article: 159877
Subject: Re: FPGA as heater
From: John Larkin <jjlarkin@highland_snip_technology.com>
Date: Wed, 12 Apr 2017 16:21:59 -0700
Links: << >>  << T >>  << A >>
On Wed, 12 Apr 2017 15:22:25 -0700 (PDT), Kevin Neilson
<kevin.neilson@xilinx.com> wrote:

>> My FPGA guy says that the ZYNQ does not have adjustable delay after
>> the i/o block flops. We can vary drive strength in four steps, and we
>> may be able to do something with that.
>> 
>
>Hmm.  I've used a real-time-adjustable ODELAY block, but that wasn't in a Zynq.
>
>If you can add more hardware to the board, you could re-register the data in some external 74LS flops.

We are exactly trying to drive external flops, some 1 ns CMOS parts.
They are clocked by the same clock that is going into the ZYNQ, and
the FPGA needs to set up their D inputs reliably. We can't use a PLL
or DLL inside the FPGA.

So the problem is that the Xilinx tools are reporting a huge (almost
3:1) spread in possible prop delay from our applied clock to the iob
outputs. The tools apparently assume the max process+temperature+power
supply limits, without letting us constrain these, and without
assigning any specific blame.


>
>You could use unregistered outputs and make your own delay line with a carry chain, which you can create with behavioral code.

I think that has even higher uncertainty, probably more than a full
clock period, so we couldn't reliably load those external flops.


-- 

John Larkin         Highland Technology, Inc
picosecond timing   precision measurement 

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com


Article: 159878
Subject: Re: FPGA as heater
From: rickman <gnuarm@gmail.com>
Date: Wed, 12 Apr 2017 19:41:45 -0400
Links: << >>  << T >>  << A >>
On 4/12/2017 7:21 PM, John Larkin wrote:
> On Wed, 12 Apr 2017 15:22:25 -0700 (PDT), Kevin Neilson
> <kevin.neilson@xilinx.com> wrote:
>
>>> My FPGA guy says that the ZYNQ does not have adjustable delay after
>>> the i/o block flops. We can vary drive strength in four steps, and we
>>> may be able to do something with that.
>>>
>>
>> Hmm.  I've used a real-time-adjustable ODELAY block, but that wasn't in a Zynq.
>>
>> If you can add more hardware to the board, you could re-register the data in some external 74LS flops.
>
> We are exactly trying to drive external flops, some 1 ns CMOS parts.
> They are clocked by the same clock that is going into the ZYNQ, and
> the FPGA needs to set up their D inputs reliably. We can't use a PLL
> or DLL inside the FPGA.
>
> So the problem is that the Xilinx tools are reporting a huge (almost
> 3:1) spread in possible prop delay from our applied clock to the iob
> outputs. The tools apparently assume the max process+temperature+power
> supply limits, without letting us constrain these, and without
> assigning any specific blame.
>
>
>>
>> You could use unregistered outputs and make your own delay line with a carry chain, which you can create with behavioral code.
>
> I think that has even higher uncertainty, probably more than a full
> clock period, so we couldn't reliably load those external flops.

The way you have constrained the design I think you will need to design 
your own chip.  I would say you need to find a way to relax one of your 
many constraints.  Not using the PLL/DLL is a real killer.  That would 
be a good one to fix.

I haven't use the Xilinx tools in a long time, but I seem to recall 
there was a way to work with a single temperature.  It may have been the 
hot number or the cold number, but not an arbitrary value in between. 
But that may have been the post layout simulation timing.  Simulation is 
not a great way to verify timing in general, but it could be made to 
work for your case.  I'd say get a Xilinx FAE involved.

-- 

Rick C

Article: 159879
Subject: Re: Master Xilinx FPGA like Jtag bridge.
From: abirov@gmail.com
Date: Thu, 13 Apr 2017 02:30:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, March 24, 2017 at 10:08:43 PM UTC+6, Adam G=C3=B3rski wrote:
> >>>>>>> How to make master FPGA to connect to many FPGAs ?
> >>>>>>>
> >>>>>>> Two FPGAs connected by serial  TDI - TDO, and two fpgas  TMS TCK
> >>>>>>> TDO and TDI connect to master fpga, master fpga has TMS TDI TDO
> >>>>>>> TCK connected and working to pc normally, it need to make
> >>>>>>> connection JTAG of two fpgas to other 4 ports or somehow can
> >>>>>>> connect to master's jtag port ?
> >>>>>>
> >>>>>> |   |---------|-TMS----|------------|-TMS----
> >>>>>> |   | FPGA 0  |-TCK----|            |-TCK----
> >>>>>> |   |         |-TDO----|            |-TDO----
> >>>>>> |   |---------|        |            |-TDI----
> >>>>>> |       |              |            |
> >>>>>> |      TDI             |            |
> >>>>>> |       |              |            |
> >>>>>> |       |              | MASTER FPGA|
> >>>>>> |       |              |            |
> >>>>>> |      TDO             |            |
> >>>>>> |       |              |            |
> >>>>>> |   |---------|-TMS----|            |
> >>>>>> |   | FGPA 1  |-TCK----|            |
> >>>>>> |   |         |-TDI----|            |
> >>>>>> |   |---------|        |------------|
> >>>>>>
> >>>>>
> >>>>> Why do you want the master FPGA to control the others rather than
> >>>>> loading them all in one chain?  Connect all TMS and TCK lines in
> >>>>> parallel and connect all TDI and TDO in one big daisy chain.  If th=
e
> >>>>> slave FPGAs are loaded by the master, where will the data come from=
?
> >>>> It is reverse engineering, someone did this but i just want reuse
> >>>> board only
> >>>
> >>> The JTAG signals to the master chip, do they connect to general I/Os =
as
> >>> well as to the FPGA JTAG signals?  Or just JTAG or just I/Os?
> >>>
> >>> You didn't say where you expect the data to come from to program the
> >>> chained slave FPGAs.  Is it supposed to come from the main JTAG port =
as
> >>> if it was talking to the slave chain?  Or will the master FPGA have a
> >>> separate interface from an MCU or a Flash chip?
> >>>
> >>> What is your overall plan?
> >> Slave FPGAs connects to USER I/O ports. for example:
> >> TMS of salve FPGA chip connects to user i/o pin  CC
> >> TDI of slave FPGA chip connects to user i/0 pin  VRP
> >> TCK of slave FPGA ship connects to user i/o pin  CC
> >
> > What do you connect the user I/O of the master to internally?  If you
> > try using the JTAG on the master it will control the master, no?
> >
>=20
> Perhaps you are looking  for something similar like Altera JAM Player=20
> for embedded.
>=20
> Take a look here=20
> https://www.altera.com/support/support-resources/support-centers/devices/=
programming-tools/jam-stapl/tls-jam-embedded.html
>=20
> There is pice of C code able to send chip image from embedded system to=
=20
> another fpga.
>=20
> Unfortunatell I don't know X as good as I would like to.
>=20
> BR
>=20
> Adam

I dont know C

Article: 159880
Subject: Re: FPGA as heater
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Thu, 13 Apr 2017 15:22:52 -0700 (PDT)
Links: << >>  << T >>  << A >>

> We are exactly trying to drive external flops, some 1 ns CMOS parts.
> They are clocked by the same clock that is going into the ZYNQ, and
> the FPGA needs to set up their D inputs reliably. We can't use a PLL
> or DLL inside the FPGA.
>=20
> So the problem is that the Xilinx tools are reporting a huge (almost
> 3:1) spread in possible prop delay from our applied clock to the iob
> outputs. The tools apparently assume the max process+temperature+power
> supply limits, without letting us constrain these, and without
> assigning any specific blame.

Like Lasse said above, you can adjust the output delay with a half-cycle re=
solution using ODDRs.  This sounds good enough for your application.  I use=
d that exact method once for a DRAM (single-data-rate) interface.  (I think=
 the training method was to write data to an unused location in DRAM with v=
arious phase relationships, read it back, and see which writes were success=
ful.)  Your issue sounds a lot like the same issues people have with DRAM. =
 I don't think you'll see a 3:1 variation in reality.


Article: 159881
Subject: Re: FPGA as heater
From: John Larkin <jjlarkin@highlandtechnology.com>
Date: Thu, 13 Apr 2017 21:12:46 -0700
Links: << >>  << T >>  << A >>
On Thu, 13 Apr 2017 15:22:52 -0700 (PDT), Kevin Neilson
<kevin.neilson@xilinx.com> wrote:

>
>> We are exactly trying to drive external flops, some 1 ns CMOS parts.
>> They are clocked by the same clock that is going into the ZYNQ, and
>> the FPGA needs to set up their D inputs reliably. We can't use a PLL
>> or DLL inside the FPGA.
>> 
>> So the problem is that the Xilinx tools are reporting a huge (almost
>> 3:1) spread in possible prop delay from our applied clock to the iob
>> outputs. The tools apparently assume the max process+temperature+power
>> supply limits, without letting us constrain these, and without
>> assigning any specific blame.
>
>Like Lasse said above, you can adjust the output delay with a half-cycle resolution using ODDRs. 

I can declare the differential-input clock polarity either way, which
would shift things 3.5 ns (out of a 7 ns clock.) But the guaranteed
data-valid window is less than 2 ns.


> This sounds good enough for your application.  I used that exact method once for a DRAM (single-data-rate) interface.  (I think the training method was to write data to an unused location in DRAM with various phase relationships, read it back, and see which writes were successful.)  Your issue sounds a lot like the same issues people have with DRAM.  I don't think you'll see a 3:1 variation in reality.

I sure hope so.



-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics 


Article: 159882
Subject: Re: FPGA as heater
From: lasselangwadtchristensen@gmail.com
Date: Fri, 14 Apr 2017 05:10:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
Den fredag den 14. april 2017 kl. 06.12.52 UTC+2 skrev John Larkin:
> On Thu, 13 Apr 2017 15:22:52 -0700 (PDT), Kevin Neilson
> <kevin.neilson@xilinx.com> wrote:
> 
> >
> >> We are exactly trying to drive external flops, some 1 ns CMOS parts.
> >> They are clocked by the same clock that is going into the ZYNQ, and
> >> the FPGA needs to set up their D inputs reliably. We can't use a PLL
> >> or DLL inside the FPGA.
> >> 
> >> So the problem is that the Xilinx tools are reporting a huge (almost
> >> 3:1) spread in possible prop delay from our applied clock to the iob
> >> outputs. The tools apparently assume the max process+temperature+power
> >> supply limits, without letting us constrain these, and without
> >> assigning any specific blame.
> >
> >Like Lasse said above, you can adjust the output delay with a half-cycle resolution using ODDRs. 
> 
> I can declare the differential-input clock polarity either way, which
> would shift things 3.5 ns (out of a 7 ns clock.) But the guaranteed
> data-valid window is less than 2 ns.
> 

the point of using DDR was not to shift the clock but to keep the clock and 
data aligned

"regenerating" the clock with a DDR, means the clock and data gets treated the same and both have the same path DDR-IOB so they should track

getting the output clock aligned with the input clock (if needed) might be possible using the "zero-delay-buffer" mode of the MMCM


Article: 159883
Subject: Re: fan speed controller
From: Neon John <no@never.com>
Date: Fri, 14 Apr 2017 11:47:57 -0400
Links: << >>  << T >>  << A >>
On 11 Apr 2017 09:52:20 -0700, Winfield Hill
<hill@rowland.harvard.edu> wrote:

> Here's my fan speed controller.  Quite serious.
>https://www.dropbox.com/s/7gsrmb9uci1wdb9/RIS-764Gb_fan-speed-controller.JPG?dl=0
>
> First there's an LM35 TO-220-package temp sensor
> mounted to the heat sink, amplify and offset its
> 10mV/deg signal by 11x, to generate a fan-speed
> voltage, present to a TC647 fan-speed PWM chip,
> add optional MOSFET for when using a non-PWM fan.
> E.g., cool, fan runs at 0%, ramps its speed over
> a 30 to 40 degree range, thereafter runs at 100%.
> TC647 chip senses stalled fan, makes error signal.
>

Complicated.  Here's my simple controller.

https://www.dropbox.com/s/u6b7ujxv3y5g20p/Tnduction_fan_controller.pdf?dl=1

The ATtiny88 is about as cheap as the LM35.  The microprocessor allows
many things other than simple linear control.  It has derivative
action, for instance, to catch a rapidly heating heat sink before it
gets very hot.  Other features include a POST that, among other
things, spins the fan to full speed for about a second before settling
down into the control loop.  I've found some fans that have enough
bearing stiction that they won't start at the 20% of full voltage that
idle provides.  So the full power pulse gives them a starting kick.

The 3rd output is designed to allow any voltage up to the transistor's
limit to be controlled.  I designed this controller for a device that
had a 45 volt fan.  

The board is tiny - about the size of 2 postage stamps.  The LM35 in a
surface mount package is on the bottom of the board.  The board is
designed to be glued in place with the LM35 in contact with the heat
sink.  I use the E6000 neoprene adhesive available at Wal-mart in
their marine department or in calking gun tubes from McMaster.  It is
VERY strong but pulls loose from the substrate when stretched.

I'm going to open source this design so as soon as I get a round tuit,
I'll put the CAD files (KiCAD) and firmware source and hex on
http://www.neon-john.com.

John
John DeArmond
http://www.neon-john.com
http://www.tnduction.com 
Tellico Plains, Occupied TN
See website for email address


Article: 159884
Subject: Re: fan speed controller
From: Winfield Hill <hill@rowland.harvard.edu>
Date: 14 Apr 2017 10:07:41 -0700
Links: << >>  << T >>  << A >>
Neon John wrote...
>
> Complicated.  Here's my simple controller.
>
>https://www.dropbox.com/s/u6b7ujxv3y5g20p/Tnduction_fan_controller.pdf?dl=1
>
>The ATtiny88 is about as cheap as the LM35.  The microprocessor allows
>many things other than simple linear control.  It has derivative
>action, for instance, to catch a rapidly heating heat sink before it
>gets very hot.  Other features include a POST that, among other
>things, spins the fan to full speed for about a second before settling
>down into the control loop.  I've found some fans that have enough
>bearing stiction that they won't start at the 20% of full voltage that
>idle provides.  So the full power pulse gives them a starting kick.
>
>The 3rd output is designed to allow any voltage up to the transistor's
>limit to be controlled.  I designed this controller for a device that
>had a 45 volt fan.  
>
>The board is tiny - about the size of 2 postage stamps.  The LM35 in a
>surface mount package is on the bottom of the board.  The board is
>designed to be glued in place with the LM35 in contact with the heat
>sink.  I use the E6000 neoprene adhesive available at Wal-mart in
>their marine department or in calking gun tubes from McMaster.  It is
>VERY strong but pulls loose from the substrate when stretched.
>
>I'm going to open source this design so as soon as I get a round tuit,
>I'll put the CAD files (KiCAD) and firmware source and hex on
>http://www.neon-john.com.
>
>John
>John DeArmond
>http://www.neon-john.com
>http://www.tnduction.com 
>Tellico Plains, Occupied TN
>See website for email address

 Thanks John, that is pretty simple.  Of course the processor
 requires a program, but if you put it up, that's good.  And
 include the controller code-burning instructions.


-- 
 Thanks,
    - Win

Article: 159885
Subject: Re: fan speed controller
From: John Larkin <jjlarkin@highland_snip_technology.com>
Date: Fri, 14 Apr 2017 10:58:11 -0700
Links: << >>  << T >>  << A >>
On Fri, 14 Apr 2017 11:47:57 -0400, Neon John <no@never.com> wrote:

>On 11 Apr 2017 09:52:20 -0700, Winfield Hill
><hill@rowland.harvard.edu> wrote:
>
>> Here's my fan speed controller.  Quite serious.
>>https://www.dropbox.com/s/7gsrmb9uci1wdb9/RIS-764Gb_fan-speed-controller.JPG?dl=0
>>
>> First there's an LM35 TO-220-package temp sensor
>> mounted to the heat sink, amplify and offset its
>> 10mV/deg signal by 11x, to generate a fan-speed
>> voltage, present to a TC647 fan-speed PWM chip,
>> add optional MOSFET for when using a non-PWM fan.
>> E.g., cool, fan runs at 0%, ramps its speed over
>> a 30 to 40 degree range, thereafter runs at 100%.
>> TC647 chip senses stalled fan, makes error signal.
>>
>
>Complicated.  Here's my simple controller.
>
>https://www.dropbox.com/s/u6b7ujxv3y5g20p/Tnduction_fan_controller.pdf?dl=1
>
>The ATtiny88 is about as cheap as the LM35.  The microprocessor allows
>many things other than simple linear control.  It has derivative
>action, for instance, to catch a rapidly heating heat sink before it
>gets very hot.  Other features include a POST that, among other
>things, spins the fan to full speed for about a second before settling
>down into the control loop.  I've found some fans that have enough
>bearing stiction that they won't start at the 20% of full voltage that
>idle provides.  So the full power pulse gives them a starting kick.
>
>The 3rd output is designed to allow any voltage up to the transistor's
>limit to be controlled.  I designed this controller for a device that
>had a 45 volt fan.  
>
>The board is tiny - about the size of 2 postage stamps.  The LM35 in a
>surface mount package is on the bottom of the board.  The board is
>designed to be glued in place with the LM35 in contact with the heat
>sink.  I use the E6000 neoprene adhesive available at Wal-mart in
>their marine department or in calking gun tubes from McMaster.  It is
>VERY strong but pulls loose from the substrate when stretched.
>
>I'm going to open source this design so as soon as I get a round tuit,
>I'll put the CAD files (KiCAD) and firmware source and hex on
>http://www.neon-john.com.
>
>John
>John DeArmond
>http://www.neon-john.com
>http://www.tnduction.com 
>Tellico Plains, Occupied TN
>See website for email address

The LM35 is supposedly not c-load stable, but most things are c-load
stable with enough c.

It is a kinda tricky part.


-- 

John Larkin         Highland Technology, Inc
picosecond timing   precision measurement 

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com


Article: 159886
Subject: Re: FPGA as heater
From: rickman <gnuarm@gmail.com>
Date: Fri, 14 Apr 2017 14:29:22 -0400
Links: << >>  << T >>  << A >>
On 4/14/2017 8:10 AM, lasselangwadtchristensen@gmail.com wrote:
> Den fredag den 14. april 2017 kl. 06.12.52 UTC+2 skrev John Larkin:
>> On Thu, 13 Apr 2017 15:22:52 -0700 (PDT), Kevin Neilson
>> <kevin.neilson@xilinx.com> wrote:
>>
>>>
>>>> We are exactly trying to drive external flops, some 1 ns CMOS parts.
>>>> They are clocked by the same clock that is going into the ZYNQ, and
>>>> the FPGA needs to set up their D inputs reliably. We can't use a PLL
>>>> or DLL inside the FPGA.
>>>>
>>>> So the problem is that the Xilinx tools are reporting a huge (almost
>>>> 3:1) spread in possible prop delay from our applied clock to the iob
>>>> outputs. The tools apparently assume the max process+temperature+power
>>>> supply limits, without letting us constrain these, and without
>>>> assigning any specific blame.
>>>
>>> Like Lasse said above, you can adjust the output delay with a half-cycle resolution using ODDRs.
>>
>> I can declare the differential-input clock polarity either way, which
>> would shift things 3.5 ns (out of a 7 ns clock.) But the guaranteed
>> data-valid window is less than 2 ns.
>>
>
> the point of using DDR was not to shift the clock but to keep the clock and
> data aligned
>
> "regenerating" the clock with a DDR, means the clock and data gets treated the same and both have the same path DDR-IOB so they should track
>
> getting the output clock aligned with the input clock (if needed) might be possible using the "zero-delay-buffer" mode of the MMCM

He has already said he has some constraint that won't let him use a PLL 
or DLL inside the FPGA, so I expect he can't use this either.  I can't 
imagine what his constraint is, maybe the clock is not regular like a 
typical clock but rather is an async data strobe.

I don't recall the upper limits of what can be done with the SERDES that 
most FPGAs have on chip.  But they all run at multi-GHz data rates and 
are clocked much slower with an internal clock multiplier.  Likely that 
can't be used either.

It does seem pretty silly to be adjusting timing by varying the 
temperature of the die.  Not just crude, but fairly ineffective as 
delays are controlled by local temperature and a die can have hot spots. 
  If the full problem were explained perhaps a solution could be offered.

Anyone know what a "1 ns CMOS part" means?

-- 

Rick C

Article: 159887
Subject: Re: fan speed controller
From: Neon John <no@never.com>
Date: Sat, 15 Apr 2017 10:20:30 -0400
Links: << >>  << T >>  << A >>
On 14 Apr 2017 10:07:41 -0700, Winfield Hill
<hill@rowland.harvard.edu> wrote:


> Thanks John, that is pretty simple.  Of course the processor
> requires a program, but if you put it up, that's good.  And
> include the controller code-burning instructions.

I'll put up the code and instructions on programming.  I used Atmel's
Studio development environment (unfortunately based on Microsoft
Studio) for development (use GNU-C suite backend) and use AVRDUDE in a
command script to program in production.

The genuine Atmel programmer is about $35 from Digikey et al but there
are plenty of articles on the web about how to build $5 programmers. I
notice that AVRDUDE even has a model based on a parallel port. Check
out http://www.avrfreaks.com.

John

John DeArmond
http://www.neon-john.com
http://www.tnduction.com 
Tellico Plains, Occupied TN
See website for email address


Article: 159888
Subject: Re: fan speed controller
From: Neon John <no@never.com>
Date: Sat, 15 Apr 2017 10:23:42 -0400
Links: << >>  << T >>  << A >>
On Fri, 14 Apr 2017 10:58:11 -0700, John Larkin
<jjlarkin@highland_snip_technology.com> wrote:


>The LM35 is supposedly not c-load stable, but most things are c-load
>stable with enough c.
>
>It is a kinda tricky part.

It is in this design.  There are several hundred of these boards in
service in our products.  I added the cap because the processor was
picking up lots of RFI from the intense RF field inside the induction
heater.

John
John DeArmond
http://www.neon-john.com
http://www.tnduction.com 
Tellico Plains, Occupied TN
See website for email address


Article: 159889
Subject: Re: fan speed controller
From: John Larkin <jjlarkin@highlandtechnology.com>
Date: Sat, 15 Apr 2017 08:11:15 -0700
Links: << >>  << T >>  << A >>
On Sat, 15 Apr 2017 10:23:42 -0400, Neon John <no@never.com> wrote:

>On Fri, 14 Apr 2017 10:58:11 -0700, John Larkin
><jjlarkin@highland_snip_technology.com> wrote:
>
>
>>The LM35 is supposedly not c-load stable, but most things are c-load
>>stable with enough c.
>>
>>It is a kinda tricky part.
>
>It is in this design.  There are several hundred of these boards in
>service in our products.  I added the cap because the processor was
>picking up lots of RFI from the intense RF field inside the induction
>heater.
>
>John
>John DeArmond
>http://www.neon-john.com
>http://www.tnduction.com 
>Tellico Plains, Occupied TN
>See website for email address

LM35 output is an emitter follower with a weak pulldown. An ideal RF
detector.

And it latches up if it possibly can.

LM71, SPI interface, is a nice part.


-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics 


Article: 159890
Subject: Re: FPGA as heater
From: John Robertson <spam@flippers.com>
Date: Sat, 15 Apr 2017 09:21:42 -0700
Links: << >>  << T >>  << A >>
On 2017/04/11 7:26 PM, John Larkin wrote:
> On Tue, 11 Apr 2017 21:09:52 -0400, krw@notreal.com wrote:
>
>> On Mon, 10 Apr 2017 20:06:57 -0700, John Larkin
>> <jjlarkin@highlandtechnology.com> wrote:
>>
>>> On Mon, 10 Apr 2017 22:15:50 -0400, krw@notreal.com wrote:
>>>
>>>> On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin
>>>> <jjlarkin@highland_snip_technology.com> wrote:
>>>>
>>>>> We have a ZYNQ whose predicted timing isn't meeting decent margins.
>>>>> And we don't want a lot of output pin timing variation in real life.
>>>>>
>>>>> We can measure the chip temperature with the XADC thing. So, why not
>>>>> make an on-chip heater? Use a PLL to clock a bunch of flops, and vary
>>>>> the PLL output frequency to keep the chip temp roughly constant.
>>>>
>>>> Why not?  Don't bother with the output frequency, just vary the number
>>>> of flops wiggling.
>>>
>>> That would work too. Maybe have a 2-bit heat control word, to get
>>> coarse steps of power dissipation, 4 groups of flops. I suppose a
>>> single on-off bit could be a simple bang-bang thermostat.
>>>
>>> The PLL thing would be elegant, proportional control of all the flops
>>> in the distributed heater array.
>>
>> You can do the same thing with the flops.  Use a shift register to
>> enable flops in a "thermometer code" sort of thing.  Too low - shift
>> right.  Wait.  Still to low - shift right.  Wait.  Too high - shift
>> left...
>>
>> There are all sorts of algorithms  that can be built into spare flops.
>>>
>>> I'm thinking we could reduce the overall effect of ambient temp
>>> changes by some healthy factor, 4:1 or 10:1 or something.
>>
>> Seems reasonable.  IBM used to add heater chips for the same purpose
>> (bipolar circuits run faster at high temperature).
>
> CMOS is slower at high temps. Somewhere between about 1000 and 3000
> PPM/K prop delay.
>

Do you use that property of CMOS (slower the warmer it gets) as an 
automatic negative feedback loop for your heater?

John

Article: 159891
Subject: Re: FPGA as heater
From: rickman <gnuarm@gmail.com>
Date: Sat, 15 Apr 2017 12:37:44 -0400
Links: << >>  << T >>  << A >>
On 4/15/2017 12:21 PM, John Robertson wrote:
> On 2017/04/11 7:26 PM, John Larkin wrote:
>> On Tue, 11 Apr 2017 21:09:52 -0400, krw@notreal.com wrote:
>>
>>> On Mon, 10 Apr 2017 20:06:57 -0700, John Larkin
>>> <jjlarkin@highlandtechnology.com> wrote:
>>>
>>>> On Mon, 10 Apr 2017 22:15:50 -0400, krw@notreal.com wrote:
>>>>
>>>>> On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin
>>>>> <jjlarkin@highland_snip_technology.com> wrote:
>>>>>
>>>>>> We have a ZYNQ whose predicted timing isn't meeting decent margins.
>>>>>> And we don't want a lot of output pin timing variation in real life.
>>>>>>
>>>>>> We can measure the chip temperature with the XADC thing. So, why not
>>>>>> make an on-chip heater? Use a PLL to clock a bunch of flops, and vary
>>>>>> the PLL output frequency to keep the chip temp roughly constant.
>>>>>
>>>>> Why not?  Don't bother with the output frequency, just vary the number
>>>>> of flops wiggling.
>>>>
>>>> That would work too. Maybe have a 2-bit heat control word, to get
>>>> coarse steps of power dissipation, 4 groups of flops. I suppose a
>>>> single on-off bit could be a simple bang-bang thermostat.
>>>>
>>>> The PLL thing would be elegant, proportional control of all the flops
>>>> in the distributed heater array.
>>>
>>> You can do the same thing with the flops.  Use a shift register to
>>> enable flops in a "thermometer code" sort of thing.  Too low - shift
>>> right.  Wait.  Still to low - shift right.  Wait.  Too high - shift
>>> left...
>>>
>>> There are all sorts of algorithms  that can be built into spare flops.
>>>>
>>>> I'm thinking we could reduce the overall effect of ambient temp
>>>> changes by some healthy factor, 4:1 or 10:1 or something.
>>>
>>> Seems reasonable.  IBM used to add heater chips for the same purpose
>>> (bipolar circuits run faster at high temperature).
>>
>> CMOS is slower at high temps. Somewhere between about 1000 and 3000
>> PPM/K prop delay.
>>
>
> Do you use that property of CMOS (slower the warmer it gets) as an
> automatic negative feedback loop for your heater?

That would likely not work nearly as well as directly measuring the 
temperature of the die.  Notice he said the chip has a built in 
thermometer.  The only issue with using the thermometer is the 
temperature across the die will vary.  Using the delay to control the 
heater might work well in concept, but would be hard to measure and 
still only work for the output being measured.  Any other outputs will 
be spread around the die and so not isothermal.  But mostly the timing 
would be hard to measure.

He has an oven/refrigerator.  He could measure the change in timing over 
temperature for some number of samples.  This would give him an idea of 
how much spread is involved.  There are multiple sources of timing 
spread and he can control one and sort of control another.  He wants an 
idea of how much timing spread is left.

-- 

Rick C

Article: 159892
Subject: Re: FPGA as heater
From: John Robertson <spam@flippers.com>
Date: Sat, 15 Apr 2017 10:15:54 -0700
Links: << >>  << T >>  << A >>
On 2017/04/15 9:37 AM, rickman wrote:
> On 4/15/2017 12:21 PM, John Robertson wrote:
>> On 2017/04/11 7:26 PM, John Larkin wrote:
>>> On Tue, 11 Apr 2017 21:09:52 -0400, krw@notreal.com wrote:
>>>
>>>> On Mon, 10 Apr 2017 20:06:57 -0700, John Larkin
>>>> <jjlarkin@highlandtechnology.com> wrote:
>>>>
>>>>> On Mon, 10 Apr 2017 22:15:50 -0400, krw@notreal.com wrote:
>>>>>
>>>>>> On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin
>>>>>> <jjlarkin@highland_snip_technology.com> wrote:
>>>>>>
>>>>>>> We have a ZYNQ whose predicted timing isn't meeting decent margins.
>>>>>>> And we don't want a lot of output pin timing variation in real life.
>>>>>>>
>>>>>>> We can measure the chip temperature with the XADC thing. So, why not
>>>>>>> make an on-chip heater? Use a PLL to clock a bunch of flops, and
>>>>>>> vary
>>>>>>> the PLL output frequency to keep the chip temp roughly constant.
>>>>>>
>>>>>> Why not?  Don't bother with the output frequency, just vary the
>>>>>> number
>>>>>> of flops wiggling.
>>>>>
>>>>> That would work too. Maybe have a 2-bit heat control word, to get
>>>>> coarse steps of power dissipation, 4 groups of flops. I suppose a
>>>>> single on-off bit could be a simple bang-bang thermostat.
>>>>>
>>>>> The PLL thing would be elegant, proportional control of all the flops
>>>>> in the distributed heater array.
>>>>
>>>> You can do the same thing with the flops.  Use a shift register to
>>>> enable flops in a "thermometer code" sort of thing.  Too low - shift
>>>> right.  Wait.  Still to low - shift right.  Wait.  Too high - shift
>>>> left...
>>>>
>>>> There are all sorts of algorithms  that can be built into spare flops.
>>>>>
>>>>> I'm thinking we could reduce the overall effect of ambient temp
>>>>> changes by some healthy factor, 4:1 or 10:1 or something.
>>>>
>>>> Seems reasonable.  IBM used to add heater chips for the same purpose
>>>> (bipolar circuits run faster at high temperature).
>>>
>>> CMOS is slower at high temps. Somewhere between about 1000 and 3000
>>> PPM/K prop delay.
>>>
>>
>> Do you use that property of CMOS (slower the warmer it gets) as an
>> automatic negative feedback loop for your heater?
>
> That would likely not work nearly as well as directly measuring the
> temperature of the die.  Notice he said the chip has a built in
> thermometer.  The only issue with using the thermometer is the
> temperature across the die will vary.  Using the delay to control the
> heater might work well in concept, but would be hard to measure and
> still only work for the output being measured.  Any other outputs will
> be spread around the die and so not isothermal.  But mostly the timing
> would be hard to measure.
>
> He has an oven/refrigerator.  He could measure the change in timing over
> temperature for some number of samples.  This would give him an idea of
> how much spread is involved.  There are multiple sources of timing
> spread and he can control one and sort of control another.  He wants an
> idea of how much timing spread is left.
>

Thanks for the explanation. I am not a qualified board designer, just a 
bit of a hacker designing and making the few I need for my restoration 
business. It is nice to get the background of design considerations as I 
find that information useful in determining where designs have gone 
wrong in our equipment and try to make improvements to the systems.

As an example - Common/Ground designs in early arcade games were not 
always at their best. A number of early electronic pinball games used to 
burn up driver transistors and coils at random until I traced the 
problem - which was  a design error where all the commons (MPU, Audio, 
Solenoids, Lamps) came together at the regulator board through several 
different pins, and as each pin connection oxidized slightly it allowed 
ground potential differences between the MPU and the solenoid logic 
grounds, leading to the transistors being slightly biased on...
And this game logic had been designed by Rockwell.

John

Article: 159893
Subject: Re: FPGA as heater
From: Gabor <nospam@nospam.com>
Date: Sat, 15 Apr 2017 14:14:34 -0400
Links: << >>  << T >>  << A >>
On Saturday, 4/15/2017 1:15 PM, John Robertson wrote:

> 
> As an example - Common/Ground designs in early arcade games were not 
> always at their best. A number of early electronic pinball games used to 
> burn up driver transistors and coils at random until I traced the 
> problem - which was  a design error where all the commons (MPU, Audio, 
> Solenoids, Lamps) came together at the regulator board through several 
> different pins, and as each pin connection oxidized slightly it allowed 
> ground potential differences between the MPU and the solenoid logic 
> grounds, leading to the transistors being slightly biased on...
> And this game logic had been designed by Rockwell.
> 
> John

This sort of poor design is common in consumer electronics.  Likely
the engineer wanted more or better ground connections, but got shot
down due to increased cost of connectors with either more pins or
better plating (silver or gold).  As long as the oxidation issue
happens _after_ the warranty period expires, there's no incentive
to correct the design, either.

-- 
Gabor

Article: 159894
Subject: glitching AND gate
From: David Bridgham <dab@froghouse.org>
Date: Sun, 23 Apr 2017 13:34:34 -0000 (UTC)
Links: << >>  << T >>  << A >>
I have a question about how FPGAs handle signals into combinational
logic.  I have following setup:

always @(posedge interrupt_check) interrupt_detect <= interrupt_request;

assign interrupt_ack = interrupt_request & enable;

The interrupt_request signal may happen at any time relative to
interrupt_check so I know that interrupt_detect may be metastable for a
bit.  However, enable is guaranteed to be asserted a minimum of 150ns
after interrupt_check so it ought to hold interrupt_ack low until
interrupt_detect is stable.

And there's my question.  Will the AND gate implementation in an FPGA do
that?  Or are LUTs odd enough that I can't depend on it?  If the answer
is FPGA specific, I'm using an Artix 7 FPGA.

I've considered "fixing" this by changing the AND gate to a flop with:

always @(posedge enable) interrupt_ack <= interrupt_detect;

but that has the problem that I'm left looking for a signal to clear
that flop at the right time.  I want to clear it when enable goes low
again but that's not allowed.

Thanks for any insight,
Dave

Article: 159895
Subject: Re: glitching AND gate
From: rickman <gnuarm@gmail.com>
Date: Sun, 23 Apr 2017 15:51:33 -0400
Links: << >>  << T >>  << A >>
On 4/23/2017 9:34 AM, David Bridgham wrote:
> I have a question about how FPGAs handle signals into combinational
> logic.  I have following setup:
>
> always @(posedge interrupt_check) interrupt_detect <= interrupt_request;
>
> assign interrupt_ack = interrupt_request & enable;
>
> The interrupt_request signal may happen at any time relative to
> interrupt_check so I know that interrupt_detect may be metastable for a
> bit.  However, enable is guaranteed to be asserted a minimum of 150ns
> after interrupt_check so it ought to hold interrupt_ack low until
> interrupt_detect is stable.
>
> And there's my question.  Will the AND gate implementation in an FPGA do
> that?  Or are LUTs odd enough that I can't depend on it?  If the answer
> is FPGA specific, I'm using an Artix 7 FPGA.
>
> I've considered "fixing" this by changing the AND gate to a flop with:
>
> always @(posedge enable) interrupt_ack <= interrupt_detect;
>
> but that has the problem that I'm left looking for a signal to clear
> that flop at the right time.  I want to clear it when enable goes low
> again but that's not allowed.

I'm sorry but I can't picture the timing from your description.  You 
have two circuits with one input in common.  You then ask "Will the AND 
gate implementation in an FPGA do that?"  I don't understand what you 
are asking.

Are you saying that enable is not asserted *until* at least 150 ns after 
interrupt_check rising edge?  Or that enable is *held* for 150 ns after 
the interrupt_check rising edge?

Is the idea that interrupt_detect is not considered by other logic until 
interrupt_ack is asserted?  Or is interrupt_detect supposed to be 
conditioned by enable rather than interrupt_request?

-- 

Rick C

Article: 159896
Subject: Re: glitching AND gate
From: Gabor <nospam@nospam.com>
Date: Mon, 24 Apr 2017 08:30:06 -0400
Links: << >>  << T >>  << A >>
On Sunday, 4/23/2017 9:34 AM, David Bridgham wrote:
> I have a question about how FPGAs handle signals into combinational
> logic.  I have following setup:
> 
> always @(posedge interrupt_check) interrupt_detect <= interrupt_request;
> 
> assign interrupt_ack = interrupt_request & enable;
> 
> The interrupt_request signal may happen at any time relative to
> interrupt_check so I know that interrupt_detect may be metastable for a
> bit.  However, enable is guaranteed to be asserted a minimum of 150ns
> after interrupt_check so it ought to hold interrupt_ack low until
> interrupt_detect is stable.
> 
> And there's my question.  Will the AND gate implementation in an FPGA do
> that?  Or are LUTs odd enough that I can't depend on it?  If the answer
> is FPGA specific, I'm using an Artix 7 FPGA.
> 
> I've considered "fixing" this by changing the AND gate to a flop with:
> 
> always @(posedge enable) interrupt_ack <= interrupt_detect;
> 
> but that has the problem that I'm left looking for a signal to clear
> that flop at the right time.  I want to clear it when enable goes low
> again but that's not allowed.
> 
> Thanks for any insight,
> Dave
> 

AND gates in an FPGA work like real AND gates.  The LUTs are designed
not to glitch when inputs change, but the output should remain the same.
LUTs may glitch when multiple inputs change and some combination of
values during the change would cause the output to change.  However
this is usually due to the skew between inputs.  Also in an AND gate
of any size that fits in one LUT, any combination of other inputs
would not make the output go high, and therefore you should not get
a glitch on the outputs.

On the other hand, FPGAs are not really designed to do asynchronous
sequential logic well.  What you're trying to do is typically done
using a high-speed free-running clock to sample the input signals
and then make decisions synchronously.

-- 
Gabor

Article: 159897
Subject: Re: glitching AND gate
From: David Bridgham <dab@froghouse.org>
Date: Mon, 24 Apr 2017 12:46:52 -0000 (UTC)
Links: << >>  << T >>  << A >>
On Sun, 23 Apr 2017 15:51:33 -0400, rickman wrote:

> I'm sorry but I can't picture the timing from your description.  You 
> have two circuits with one input in common.

One input in common?  Well crap, I screwed up the verilog.  Try this
instead:

always @(posedge interrupt_check) interrupt_detect <= interrupt_request;

assign interrupt_ack = interrupt_detect & enable;

> You then ask "Will the AND gate implementation in an FPGA do that?"  I
> don't understand what you are asking.

If an actual AND gate has an input that's 0, the output will be 0
regards of the other input.  If the other input is 0, is 1, is a clock,
or even if it's somewhere in-between because the driver has gone
metastable, the output of the AND gate will be 0.  My question was, can
I depend on that from a synthesized AND gate in an FPGA?

> Are you saying that enable is not asserted *until* at least 150 ns after 
> interrupt_check rising edge?  Or that enable is *held* for 150 ns after 
> the interrupt_check rising edge?

The former; enable is not asserted until at least 150ns after
interrupt_check rising edge.

> Is the idea that interrupt_detect is not considered by other logic until 
> interrupt_ack is asserted?  Or is interrupt_detect supposed to be 
> conditioned by enable rather than interrupt_request?

Both, I think.  Well, interrupt_detect is not used by any other logic,
only interrupt_ack.  interrupt_detect is internal to just what you see
there while interrupt_ack is the signal that goes on to the rest of the
logic.

To see more of the context of this question, I'm working on bus
arbitration circuitry for the Unibus and QBUS.  I'm writing up what I'm
doing in a short paper that you can find at the URL below.  The paper
isn't done yet but it's starting to get closer.

http://www.froghouse.org/~dab/papers/bus-arbitration/ba.html

Article: 159898
Subject: Re: glitching AND gate
From: David Bridgham <dab@froghouse.org>
Date: Mon, 24 Apr 2017 14:04:34 -0000 (UTC)
Links: << >>  << T >>  << A >>
On Mon, 24 Apr 2017 08:30:06 -0400, Gabor wrote:

> On the other hand, FPGAs are not really designed to do asynchronous
> sequential logic well.  What you're trying to do is typically done
> using a high-speed free-running clock to sample the input signals and
> then make decisions synchronously.

I've read this before, that FPGAs are not really suitable for
asynchronous logic.  And yet, if the gates are glitch-free than I'm not
seeing the problem with doing what I'm suggesting here.  Converting the
input signals to synchronous seems like a bunch of extra work for
something that ought to be fairly straightforward.

In the larger picture, I do have a desire someday to play around with
asynchronous designs.  Not this project with the QBUS but a future
project, possibly even implementing an entire processor asynchronously.
Being able to use FPGAs would sure be easier than having to get out the
wire-wrap gun.

Article: 159899
Subject: Re: glitching AND gate
From: Jan Coombs <jenfhaomndgfwutc@murmic.plus.com>
Date: Mon, 24 Apr 2017 16:48:47 +0100
Links: << >>  << T >>  << A >>
On Mon, 24 Apr 2017 14:04:34 -0000 (UTC)
David Bridgham <dab@froghouse.org> wrote:

> On Mon, 24 Apr 2017 08:30:06 -0400, Gabor wrote:
> 
> > On the other hand, FPGAs are not really designed to do
> > asynchronous sequential logic well.  What you're trying to
> > do is typically done using a high-speed free-running clock
> > to sample the input signals and then make decisions
> > synchronously.
> 
> I've read this before, that FPGAs are not really suitable for
> asynchronous logic.  And yet, if the gates are glitch-free
> than I'm not seeing the problem with doing what I'm suggesting
> here.  Converting the input signals to synchronous seems like
> a bunch of extra work for something that ought to be fairly
> straightforward. 

Aren't there usually handy latches in the input buffer
structure? Better safe than frustrated...

 
> In the larger picture, I do have a desire someday to play
> around with asynchronous designs.  Not this project with the
> QBUS but a future project, possibly even implementing an
> entire processor asynchronously. Being able to use FPGAs would
> sure be easier than having to get out the wire-wrap gun.

I'd also like to prototype a fully asynchronous processor in
an FPGA.  The Microsemi (ex Actel) Igloo/ProASIC3 parts have no
LUTs. An element of the fine grained fabric can either be a
latch or the equivalent of a LUT3.  But, you may have to
hand-wire the input delays if timing is really critical?

It seems to me that the 2 wire 4 state logic should be fastest,
because only one of the wires needs to make a single transition
to indicate the next data phase. 

On-chip RAM would seem to be a problem though - any ideas?. 


Jan Coombs
-- 




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
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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