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 63325

Article: 63325
Subject: Re: How do you keep layout info in VHDL?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Wed, 19 Nov 2003 10:54:24 -0800
Links: << >>  << T >>  << A >>
Symon wrote:
> "Duane Clark" <junkmail@junkmail.com> wrote in message
> news:bpg6gk02qv@enews2.newsguy.com...
> 
>>Valentin Tihomirov wrote:
>>
>>>I was always considering VHDL as behaviur/logic (netlist on functional
>>>gates) specification language. There are no means to add more detales
>>>required at PCB layout abstraction layer. VHDL has no means to describe
>>>placement, traces and device packages. I'm I missing missing something?
>>
>>I think the part you are missing is that Symon wants to replace the
>>schematic portion of the PCB layout software. I does not look to me like
>>he was talking about replacing the layout portion. Maybe some people put
>>layout info on the schematic, but I think most do not.
>>
>>-- 
>>My real email is akamail.com@dclark (or something like that).
> 
> 
> Thanks Duane, you've got it exactly! 

I agree that the "netlist capture" portion of
PCB schematic capture could be more easily done
with vhdl or verilog. I like to look at
a schematic too, but let's have the machine
draw it!

Most large digital components have a free
vendor-supplied BSDL file that could be
converted to an entity with a script.

All of the architectures could be null
for the purpose of netlist capture.

The top_pcb.vhd file would be formatted
like a testbench with all of the
signal (wire) declarations, entity
instances, and port maps.

A simulation compile could find
unintended shorts and opens, and
a viewer could display a schematic
for checking wires and entity instances.

A script could process top_pcb.vhd
to create a netlist compatible
with PADS, Allegro etc for layout.

The top_pcb.vhd file could be used
again when the fpgas code is complete
for a board level digital simulation.


  -- Mike Treseler






Article: 63326
Subject: Re: How to RLOC adders in VHDL/Synplify to avoid broken carry chains?
From: "Francisco Rodriguez" <prodrig@disca.upv.es>
Date: Wed, 19 Nov 2003 20:05:21 +0100
Links: << >>  << T >>  << A >>
Hi

"Symon" <symon_brewer@hotmail.com> escribió en el mensaje
news:bpg87l$1nmpu4$1@ID-212844.news.uni-berlin.de...
>
> "Ken" <aeu96186_MENOWANTSPAM@yahoo.co.uk> wrote in message
> news:bpg5k3$4a$1@dennis.cc.strath.ac.uk...
> >
> > Hello folks,
> >
> > I am implementing a filter on a -5 Virtex-II part (3000) and the
critical
> > path is one of the longest adder carry chains in the design (28 bits).
> >
> > I have noticed that the minimum period of my design is being clobbered
by
> > the carry chain of the longest adder changing CLB column half-way
through
> > instead of carrying on up the carry chain in the column it started in...
> >
> > So, I would like to be able to put in my VHDL code an RLOC constraint
(or
> > something) that would inform Synplify Pro not to do any clever
> optimisation
> > that will prevent Xilinx ISE 5.2.03i from keeping the carry chain in one
> > column (an old Ray Andraka post has led me to believe this is what is
> > happening).
> >
> > Googling about has yielded some discussions on it but I cannot see
exactly
> > how I would specify this in my VHDL to ensure that the carry chain
remains
> > in one column.
> >
> > Can someone give me some pointers please (ideally a quick code snippet
to
> > demonstrate  :-)   )?
> >
> > Thanks in advance for your time,
> >
> > Ken
> >
> >
> Ken,
>     Have you read the constraints guide in the Xilinx software manuals?
Look
> for the RLOC section. You end up with stuff in your UCF like :-
>
> INST "*un6_burp_cry_0" RLOC = "X6Y4";
> INST "*un6_burp_cry_1" RLOC = "X6Y4";
> INST "*un6_burp_cry_2" RLOC = "X6Y5";
> INST "*un6_burp_cry_3" RLOC = "X6Y5";
> INST "*un6_burp_cry_4" RLOC = "X6Y8";
> etc...
>
>     I used the floorplanner to get the names of things I want to RLOC. For
> your problem, you could place the carry chain with floorplanner and send
the
> output to a temporary UCF to give you a start on your RLOC stuff. Hope
that
> makes sense! Read about H_SETs, HU_SETs and U_SETs too.
>         good luck, Syms.
>

I prefer the way used in one of Xilinx's TechXclusives to embed RLOC
attributes
directly in VHDL (Relationally Placed Macros). Here's an example of a RPM to
perform a registered a + b, using
the carry chain using the U_SET attribute.


-- begin VHDL code
library ieee;
use ieee.std_logic_1164.all;
library unisim;
use unisim.vcomponents.all;
use work.rlocs.all;

entity a_plus_b_reg is
    generic (width: integer := 32; setn: integer := 1);
 port (
  clock  : IN  std_logic;
  enable : IN  std_logic;
  a :      IN  std_logic_vector (width-1 downto 0);
  b :      IN  std_logic_vector (width-1 downto 0);
  q :      OUT std_logic_vector (width-1 downto 0)
 );
end a_plus_b_reg;

architecture rpm_arch of a_plus_b_reg is

    attribute INIT:  string;
    attribute BEL:   string;
    attribute RLOC:  string;
    attribute U_SET: string;

    signal prexor_int_q: std_logic_vector (width-1 downto 0);
    signal int_carry:    std_logic_vector (width-1 downto 0);
    signal y:            std_logic_vector (width-1 downto 0);

begin

    int_carry(0)  <= '0';

    reg: for i in 0 to width-1 generate
        attribute U_SET of q_reg: label is "uset" & integer'image(setn);
        attribute RLOC  of q_reg: label is "X0" & "Y" &
integer'image(integer(i/2));
        attribute BEL   of q_reg: label is "FF" & belname_xy(i);
    begin
        q_reg: FDE port map (
                   D => y(i), CE => enable, C => clock,
                   Q => q(i));
    end generate;

    gena: for i in 0 to width-2 generate
        attribute INIT  of q_lut: label is "6";
        attribute U_SET of q_lut: label is "uset" & integer'image(setn);
        attribute U_SET of q_mxy: label is "uset" & integer'image(setn);
        attribute U_SET of q_xor: label is "uset" & integer'image(setn);
        attribute RLOC  of q_lut: label is "X0" & "Y" &
integer'image(integer(i/2));
        attribute RLOC  of q_mxy: label is "X0" & "Y" &
integer'image(integer(i/2));
        attribute RLOC  of q_xor: label is "X0" & "Y" &
integer'image(integer(i/2));
        attribute BEL   of q_lut: label is belname_fg(i);
        attribute BEL   of q_xor: label is "XOR" & belname_fg(i);
    begin
        q_lut: LUT2
               --synthesis off
         generic map (INIT => x"6")
      --synthesis on
      port map (
                   I1 => b(i), I0 => a(i),
                   O  => prexor_int_q(i) );
        q_mxy: MUXCY port map (
                   DI => a(i), CI => int_carry(i), S => prexor_int_q(i),
                   O  => int_carry(i+1) );
        q_xor: XORCY port map (
                   LI => prexor_int_q(i), CI => int_carry(i),
                   O  => y(i) );
    end generate;

    genb: for i in width-1 to width-1 generate
        attribute INIT  of q_lut: label is "6";
        attribute U_SET of q_lut: label is "uset" & integer'image(setn);
        attribute U_SET of q_xor: label is "uset" & integer'image(setn);
        attribute RLOC  of q_lut: label is "X0" & "Y" &
integer'image(integer(i/2));
        attribute RLOC  of q_xor: label is "X0" & "Y" &
integer'image(integer(i/2));
        attribute BEL   of q_lut: label is belname_fg(i);
        attribute BEL   of q_xor: label is "XOR" & belname_fg(i);
    begin
        q_lut: LUT2
                   --synthesis off
                   generic map (INIT => x"6")
                   --synthesis on
                   port map (
                       I1 => b(i), I0 => a(i),
                       O  => prexor_int_q(i) );
        q_xor: XORCY port map (
                   LI => prexor_int_q(i), CI => int_carry(i),
                   O  => y(i) );
    end generate;

end rpm_arch;
-- end VHDL code


The resulting RPM is a column of 1 x w/2 slices, being w the value assigned
to the width the generic
The setn generic lets you create different U_SET names for different
instances of the entity (if the instances
have no relative positions) or the same U_SET name and applying different
RLOCs to each instance
(if the instances have relative positions).

The rlocs package contains a couple of simple functions to return the
strings "F" or "G"
or the couple "X" or "Y", to differentiate the luts/ffs inside a single
slice. Read the constraints guide
about RLOC, RLOC_ORIGIN and the different kinds of sets you can create. And
the RPM techxcluvise,
of course.

If you prefer the placer to select the absolute positioning of the RPM, then
that's all you need.
If you want total control, then you can select the RPM position attaching an
RLOC_ORIGIN
to the U_SET name in the UCF file.

I've successfully used this entity on the virtex2 architecture & XST. Don't
know how to tell
Synplify Pro to attach those attributes, but it shouldn't be that difficult.

The drawback is your design is no longer portable. You're stuck with Xilinx
parts that use the XY
coordinate system (not all of them). But you can create different versions
for different architectures, of course.

Best regards

    Francisco Rodriguez






Article: 63327
Subject: Re: 400 Mb/s ADC
From: "MM" <mbmsv@yahoo.com>
Date: Wed, 19 Nov 2003 14:27:06 -0500
Links: << >>  << T >>  << A >>
> we accumualte averages (of cross products of fourier tranforms)

What are you going to be using for calculations? If you are planning on
using DSP cards, then you don't need to go through PCI. You coud transfer
data directly from your A/D card to a DSP card using for example FPDP
interface.

There is a number of companies who do similar things for radar and sonar.
Look at the products by Pentek, ICS, Gage, etc...

BTW, I think this discussion drifted away from the FPGA topic, so it
probably doesn't belong here...

/Mikhail



Article: 63328
Subject: Re: 400 Mb/s ADC
From: "Nik Simpson" <n_simpson@bellsouth.net>
Date: Wed, 19 Nov 2003 14:52:46 -0500
Links: << >>  << T >>  << A >>
Jeff Peterson wrote:
>> 1. Just capturing the data performing some operation on it, storing
>> the results and throwing away the sample
>
> we accumualte averages (of cross products of fourier tranforms)
>

So the basic problem is getting 400MB/s of data into memory and processing
it, but are you reading 400MB every second, or sampling say once every ten
seconds. If it's every second, then you've got a bigger problem because I'd
be surprised if you can process it fast enough to get the job done before
the next sample comes along.

>>
>> 2. You might be actually planning to capture to disk 400MB/s for a
>> sustained period which has some pretty hairy implications for
>> storage capacity.
>>
> we wont store the raw data, just a very much reduced set.

So disk output bandwidth is not going to be a problem, what you are looking
for is a way of getting 400MB/s of data into memory for post-processing,
correct. Is it possible to break-up the input stream, so for example instead
of reading a single stream of 400MB/s, you've five devices reading 80MB/s in
parralel? Is the design of the device capturing the data set in stone or can
it be "parrallelized" if so it would make the problem much simpler and any
solution more scalable and less expensive.


-- 
Nik Simpson



Article: 63329
Subject: Xilinx UCF file conditional includes ?
From: "Robert Finch" <robfinch@sympatico.ca>
Date: Wed, 19 Nov 2003 15:00:36 -0500
Links: << >>  << T >>  << A >>
Is there a way to conditionally include sections of a UCF file ? I currently
have a design with conditional compilation but the I/O ports and ROM
contents specified in the UCF file need to differ based on how it's
compiled.

It'd be nice if there was some sort of #ifdef #else etc... and macro
processing.....

Rob




Article: 63330
Subject: Re: State Machines....
From: "Antonio Pasini" <NOSPAM_pasini.a@tin.it>
Date: Wed, 19 Nov 2003 20:04:14 GMT
Links: << >>  << T >>  << A >>
"Peter Alfke" <peter@xilinx.com> ha scritto nel messaggio
news:3FBBB033.E8A6616A@xilinx.com...

> There is an April 2001 TechXclusives "Using leftover multipliers and
> BlockRAMs" that describes a surprisingly simple structure for a state
> machine with up to 256 states. I never got any feedback on this idea.
> There is no software tool, but it's pretty straightforward, and "pencil
> and paper" might suffice...
> http://support.xilinx.com/xlnx/xweb/xil_tx_home.jsp

Just read the article...  I like the idea, I'll try to remember the trick
next design.

Makes medium/big fsm simplicity itself: no routing issues, etc.. very
clever.
But... too much work for translating to numeric "init" format...

Why don't you try to "whisper" a bit at the ears of ISE StateCad mantainers
?

Maybe outputting INIT tables from a StateCad graph could boost the use of
this particular trick.







Article: 63331
Subject: Re: State Machines....
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Wed, 19 Nov 2003 12:18:26 -0800
Links: << >>  << T >>  << A >>
stan wrote:
> hi ... I have a question for the experts , I am doing a post mortem of
> my last project , it was a communication processor that was basicly a
> lot of dataflow paths controlled by several rather complex state
> machines ( 100-200 states ) , 
> 

Some hardware objects are not efficiently
described as a state machine.
For example, an 8 bit shift register could be
described using a single variable assignment or as a case
of 256 variable states.

Complex sequential logic is easiest for me to
describe using clocked processes with
lots of local variables.

The state machine model is a clocked process
with a single enumerated local variable or signal.
With a state editor as your design entry, this is all you can do.

With synthesis tools, you can have many
local variables of many types in a single clocked process.
You might have a local counter register and a shift register, etc.
One page of clear code replaces pages of circles and arrows.


 > The bigger downside here is that since the state machines took longer
 > than I expected ( I scheduled 3 weeks of design, project took 6 weeks
 > )  my manager has warned me to find another job

I expect that he could not really find anyone faster.
Keep honing your skills, and politely ignore the
"schedule as whip" tactic.

          -- Mike Treseler


Article: 63332
Subject: Re: State Machines....
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Wed, 19 Nov 2003 20:30:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <21Qub.58264$hV.2182491@news2.tin.it>,
Antonio Pasini <NOSPAM_pasini.a@tin.it> wrote:

>Makes medium/big fsm simplicity itself: no routing issues, etc.. very
>clever.
>But... too much work for translating to numeric "init" format...

Do what I did when I had to implement the Rijndael S-boxes:  Write a
small program that takes an abstract representation and dumps the init
strings.  Heck, I may end up having to write one myself, if so, I'd
release it.

-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 63333
Subject: Re: Small PLD choices
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 20 Nov 2003 09:49:20 +1300
Links: << >>  << T >>  << A >>
Al Clark wrote:
> 
> We have been using Max EPM3032 and EPM3064 devices for several of our
> designs.
> 
> The features I like with these devices is as follows:
> 
> 1. Very Cheap - $1.30 for 3032 devices in small quantities
> 2. Easy tools with 74 style schematic capture entry.
> 3. 3.3V operation with 5V tolerant I/O
> 
> The MAX 3000 is also a power hog which is the main reason I am searching
> for alternatives.
> 
> I looked at the Xilinx CoolRunner and CoolRunner 2 parts. Here were my
> impressions based from their web site. I would appreciate comments.
> 
> CoolRunner:
> 
> 1. Although they have these parts on their web site, they seem to be
> deemphasised. This suggested to me that maybe this line is on the way
> out.
> 
> 2. I like the 3.3V supply with the 5V tolerance.
> 
> 3. Power is lower than Altera, prices are higher.
> 
> CoolRunner 2:
> 
> 1. Xilinx wants to sell these parts.
> 2. They use 1.8V supplies which is just about the only supply I don't
> already need in my design.
> 3. They are not 5V tolerant which may or may not be important (but often
> is)
> 4. They cost more than Altera Max 3000 or CoolRunner.

 Relative price is a good indicator of CR/CR2 - commonly the newer 
devices are cheaper, to encourage design migration.
 Getting an accurate relative price right now is not easy, as 
vendors are trying to nudge up margins comming out of the slump.
 
 Xilinx have a CR2 webseminar inside the next 48 hrs.

> What other players or parts should I consider?
> 
> 1. I want schematic entry, reasonably small size in QFP, low power and
> low cost.

If power is more important than speed, look at Atmel ATF15xx families.
They have POF2JED Sw, so you can migrate your Altera design to Atmel,
and they are close pinouts to the MAX7032.7064 devices.

 Other devices are Lattice 4000Z family, and Altera are 'horizon
promising'
MAX 2 families, but with some caveats :
- Currently vaporware
- They only claim 90% power reduce, which leaves them well above CR2 and
  4000Z levels
- Smallest MAX-2 device mentioned is 128 MC, so that's larger than
3032/3064's
  That's a fairly large chunk of market to ignore....
  
 Lattice's WEB boast's about their Static Icc edge over CR2, but they 
never mention dynamic Icc (mA/Mhz), so one can conclude they are close, 
but just loose out on that one :)

-jg

Article: 63334
Subject: Re: Anyone use HDL as design tool for PCBs?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 20 Nov 2003 10:04:58 +1300
Links: << >>  << T >>  << A >>
Symon wrote:
> Hi Allen,
>     Thanks for the reply! The tool I use at the moment, ORCAD, has separate
> layout and schematic entry bits. So, I agree that layout, i.e. drawing the
> traces, makes no sense in VHDL. However, the schematic entry is a pain in
> the @rse, after all it's just wiring up components to each other. You end up
> typing in lots of attributes anyway, part numbers, value, package size, pcb
> footprint. Seems to me that the physical wiring of the parts is perfectly
> feasible in HDL, and I can use Perl scripts to speed things along, like I do
> with VHDL for my FPGA innards designs. Maybe for some things like a SMPS, a
> diagram is very useful, perhaps necessary. However, for connecting a DRAM to
> a FPGA, the picture adds very little if anything. Some kind of hybrid is
> called for, like we already can do with logic inside FPGAs.
>     Also, I would expect a HDL to be just as good at pin-swapping / gate
> swapping, but, once again, I agree that layout remains inherently graphical.
> As you point out the geometry of the traces is vital, and often forms part
> of the circuit.

 You are actually looking for a hybrid - as you say R's and C's do not
HDL well.

 The NETLIST formats of most PCB systems is quite simple, and some
import many
variants.

 Better packages allow you to MERGE and CHECK netlists (ie split
imports), so you
could create a Analog Schematic + Block structure/IC number in 
Schematic (to keep BOM correct) and then move to HDL for digital
interconnects.

 If the device ( eg U1 TQFP100 ) is already imported via the SCH leg,
all your HDL->NET has to do is handle the PinNumber -- NetName
collections.

 That should not be too hard for someone used to scripts.

 You can also go backwards - eg after PINSWAP, a PCB script can create
the
PIN - Name list in the HDL format, for manual paste.

 -jg

Article: 63335
Subject: Re: Architecture desing using national serializer and deserialiser
From: "Daniel Lang" <invalid@xtyrvos.caltech.edu>
Date: Wed, 19 Nov 2003 13:12:38 -0800
Links: << >>  << T >>  << A >>
"Jon" <someone@microsoft.com> wrote in message
news:bpaned$n7f$1@news2.netvision.net.il...
> Hello
>
>  I need help on using serializer and deserializer in an electornic card.
>  The serializer and deserializer are from national DS90CR287 and DS90CR288
>  I'm working with an electronic card that use a serializer of 4 channels
>  where the input clock is 40Mhz. when the data in the inputs of the
>  serializer changes in a slow rate the deserializer and FPGA  in the other
>  card can decode the data properly. when the data in the inputs of the
>  serializer changes in a high rate ( every 50ns ) the data after the
>  deserializer and the FPGA in the other card can't decode the data.
>
>  The thing is that there are some cards the work and some others that
> doesn't
>  work.
>  When I look for a diference I found that the 3.3v supply to the
serializer
>  is stable where  the card works O.K and when the 3.3v supply has noise
the
>  card doesn't work .

It sounds like the PLL is getting too much noise.  The datasheet recommends
a maximum of 100 mV P-P noise on the VCC.  You may want to add a LC filter
on the power to the PLL VCC pin and/or run the chip from a low noise linear
regulator (LT1963A or equivalent).  Make sure all the VCC pins are bypassed
and keep the noisy digital lines away from the PLL area.

Daniel Lang



Article: 63336
Subject: Re: Is this a good starter kit?
From: "Alex Gibson" <alxx/*nospam*/@@/*nospam*/ihug./*nospam*/com./remove/au>
Date: Thu, 20 Nov 2003 09:18:18 +1100
Links: << >>  << T >>  << A >>

"Mike Silva" <snarflemike@yahoo.com> wrote in message =
news:20619edc.0311171148.4b9d44f5@posting.google.com...
> This Digilent combo package looks to me like an excellent way to learn
> FPGAs (but then, I don't know anything yet!):
>=20
> http://www.digilentinc.com/Catalog/digilab_2_dio2.html
>=20
> Do more experienced eyes see any gotchas with this setup?  I realize
> the FPGA is bigger than a beginner needs, but the price seems good,
> and I gather the part is from a mainstream FPGA family.
>=20
> Thanks.

I got myself a similar combo but with the dio1
and a couple of the breadboards
http://www.digilentinc.com/Catalog/digilab__io1.html
http://www.digilentinc.com/Catalog/digilab_breadboard___wire-wrap.html
the lack of memory is a bit annoying sometimes

Have you had a look at http://www.burched.biz/
http://www.burched.biz/b5xsvp.html


Alex

Article: 63337
Subject: Re: State Machines....
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 19 Nov 2003 17:26:09 -0500
Links: << >>  << T >>  << A >>
Using RAM/ROM for a FSM is about as basic as it gets.  I remember using
that method some 20 years ago about the same time fuse PLDs were
starting to appear.  Back then fuse ROMs were just about this same
size.  


Peter Alfke wrote:
> 
> There is an April 2001 TechXclusives "Using leftover multipliers and
> BlockRAMs" that describes a surprisingly simple structure for a state
> machine with up to 256 states. I never got any feedback on this idea.
> There is no software tool, but it's pretty straightforward, and "pencil
> and paper" might suffice...
> http://support.xilinx.com/xlnx/xweb/xil_tx_home.jsp
> 
> Peter Alfke, Xilinx Applications
> =============================
> Robert Sefton wrote:
> >
> > Stan -
> >
> > I agree with Jonathan that 200 states is nuts. Very error prone and
> > probably very difficult to maintain/modify. Were you parsing the
> > incoming data stream and making state decisions based on that? If so, a
> > programmable communications processor or an embedded processor (like
> > Nios for Altera) is a much better and more flexible choice. Some tasks
> > just aren't meant to be done in hardware, and parsing data streams is
> > one of them.
> >
> > Nice reward for delivering a working design. I hope you find a way to
> > exit that situation.
> >
> > Robert
> >
> > "stan" <stanandsue2000@yahooREMOVE.com> wrote in message
> > news:3fbb8795.3574357@news.compuserve.com...
> > > hi ... I have a question for the experts , I am doing a post mortem of
> > > my last project , it was a communication processor that was basicly a
> > > lot of dataflow paths controlled by several rather complex state
> > > machines ( 100-200 states ) ,  I did the design by thinking out the
> > > control and drawing the state diagrams and then coding them into VHDL
> > > for Quartus and into a Stratix .. it worked , after handing over the
> > > design to the test department they loaded a board and signed off on
> > > the design within a week. My fellow engineers were rather impressed
> > > since they knew how complex the control was.
> > >
> > > The downside here was the state machines became complex and took quite
> > > a while to figure out ... then transcibing them into VHDL and also
> > > drawing a pretty state chart for documenting the design took a while.
> > > Yes I know some say start right with typing VHDL but I find that hard
> > > to comceptualize.  Since this is a small company big $$ tools are out
> > > of the question.
> > >
> > > So my question ... are there tools out there that can make this
> > > process faster ?  like drawing the state charts on the screen and
> > > outputing VHDL ?  or other suggestions ???  again if these are $5-10K
> > > tools I won't be getting them in this company so shareware or <$1K
> > > tools are preferred even if they lack in some areas.
> > >
> > > The bigger downside here is that since the state machines took longer
> > > than I expected ( I scheduled 3 weeks of design, project took 6 weeks
> > > )  my manager has warned me to find another job ( fat chance ) as he
> > > has handed in a review requesting a 20% pay cut ... but my real
> > > question is about the tools so I may do better next time
> > >
> > > thanks for any constructive feedback , stan

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 63338
Subject: Re: State Machines....
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 19 Nov 2003 15:29:12 -0800
Links: << >>  << T >>  << A >>
I am not asking for the Nobel prize. I just wonder whether this is a
practical, compact, cheap, fast and easy way to build a state machine
inside an FPGA...
Peter Alfke
=============================
rickman wrote:
> 
> Using RAM/ROM for a FSM is about as basic as it gets.  I remember using
> that method some 20 years ago about the same time fuse PLDs were
> starting to appear.  Back then fuse ROMs were just about this same
> size.
> 
> Peter Alfke wrote:
> >
> > There is an April 2001 TechXclusives "Using leftover multipliers and
> > BlockRAMs" that describes a surprisingly simple structure for a state
> > machine with up to 256 states. I never got any feedback on this idea.
> > There is no software tool, but it's pretty straightforward, and "pencil
> > and paper" might suffice...
> > http://support.xilinx.com/xlnx/xweb/xil_tx_home.jsp
> >
> > Peter Alfke, Xilinx Applications
> > =============================
> > Robert Sefton wrote:
> > >
> > > Stan -
> > >
> > > I agree with Jonathan that 200 states is nuts. Very error prone and
> > > probably very difficult to maintain/modify. Were you parsing the
> > > incoming data stream and making state decisions based on that? If so, a
> > > programmable communications processor or an embedded processor (like
> > > Nios for Altera) is a much better and more flexible choice. Some tasks
> > > just aren't meant to be done in hardware, and parsing data streams is
> > > one of them.
> > >
> > > Nice reward for delivering a working design. I hope you find a way to
> > > exit that situation.
> > >
> > > Robert
> > >
> > > "stan" <stanandsue2000@yahooREMOVE.com> wrote in message
> > > news:3fbb8795.3574357@news.compuserve.com...
> > > > hi ... I have a question for the experts , I am doing a post mortem of
> > > > my last project , it was a communication processor that was basicly a
> > > > lot of dataflow paths controlled by several rather complex state
> > > > machines ( 100-200 states ) ,  I did the design by thinking out the
> > > > control and drawing the state diagrams and then coding them into VHDL
> > > > for Quartus and into a Stratix .. it worked , after handing over the
> > > > design to the test department they loaded a board and signed off on
> > > > the design within a week. My fellow engineers were rather impressed
> > > > since they knew how complex the control was.
> > > >
> > > > The downside here was the state machines became complex and took quite
> > > > a while to figure out ... then transcibing them into VHDL and also
> > > > drawing a pretty state chart for documenting the design took a while.
> > > > Yes I know some say start right with typing VHDL but I find that hard
> > > > to comceptualize.  Since this is a small company big $$ tools are out
> > > > of the question.
> > > >
> > > > So my question ... are there tools out there that can make this
> > > > process faster ?  like drawing the state charts on the screen and
> > > > outputing VHDL ?  or other suggestions ???  again if these are $5-10K
> > > > tools I won't be getting them in this company so shareware or <$1K
> > > > tools are preferred even if they lack in some areas.
> > > >
> > > > The bigger downside here is that since the state machines took longer
> > > > than I expected ( I scheduled 3 weeks of design, project took 6 weeks
> > > > )  my manager has warned me to find another job ( fat chance ) as he
> > > > has handed in a review requesting a 20% pay cut ... but my real
> > > > question is about the tools so I may do better next time
> > > >
> > > > thanks for any constructive feedback , stan
> 
> --
> 
> Rick "rickman" Collins
> 
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
> 
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 63339
Subject: Re: State Machines....
From: "Robert Sefton" <rsefton@abc.net>
Date: Wed, 19 Nov 2003 16:08:54 -0800
Links: << >>  << T >>  << A >>
Hey Peter -

I think it's a great solution, especially with the large number of
outputs that can be generated. I also like the multiplier as
barrel-shifter. I designed a 32-bit barrel shifter running at 27MHz in
an XC4000 part ten years ago and it took up the whole part.

Robert

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3FBBFCC8.E3A34A0D@xilinx.com...
> I am not asking for the Nobel prize. I just wonder whether this is a
> practical, compact, cheap, fast and easy way to build a state machine
> inside an FPGA...
> Peter Alfke



Article: 63340
Subject: Re: State Machines....
From: "Jim Granville" <no.spam@designtools.co.nz>
Date: Thu, 20 Nov 2003 13:27:18 +1300
Links: << >>  << T >>  << A >>
> =============================
> rickman wrote:
> >
> > Using RAM/ROM for a FSM is about as basic as it gets.  I remember using
> > that method some 20 years ago about the same time fuse PLDs were
> > starting to appear.  Back then fuse ROMs were just about this same

Some even included registers, to make single chip state engines ...

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3FBBFCC8.E3A34A0D@xilinx.com...
> I am not asking for the Nobel prize. I just wonder whether this is a
> practical, compact, cheap, fast and easy way to build a state machine
> inside an FPGA...
<paste>> > There is no software tool, but it's pretty straightforward, and
"pencil
> > > and paper" might suffice...

It is a good idea, but the SW tool side could need work to help it take
off.. :)
It should be FAST, and quite tolerant of state code revisions - with good
tools,
the state table could be revised without a P&R :)

Re the OP of large state machines, some form of nested engines might be a
better idea
- 200 states is plausible, but they are not likely to have fully random
path-links, so a
simpler 'umbrella state', with waits from 'task states' could be easier to
manage...

-jg



Article: 63341
Subject: Re: 400 Mb/s ADC
From: jbp@cmu.edu (Jeff Peterson)
Date: 19 Nov 2003 16:30:01 -0800
Links: << >>  << T >>  << A >>
"Nik Simpson" <n_simpson@bellsouth.net> wrote in message news:<vQPub.41$zi3.40@bignews3.bellsouth.net>...
> Jeff Peterson wrote:
> >> 1. Just capturing the data performing some operation on it, storing
> >> the results and throwing away the sample
> >
> > we accumualte averages (of cross products of fourier tranforms)
> >
> 
> So the basic problem is getting 400MB/s of data into memory and processing
> it, but are you reading 400MB every second, or sampling say once every ten
> seconds. If it's every second, then you've got a bigger problem because I'd
> be surprised if you can process it fast enough to get the job done before
> the next sample comes along.
we will take about 64K samples, then can pause while processing...
however all the time we are pausing we are losing data.  so we do want to
keep the duty cycle up.  50% dudty cyle is not a problem. 5% would be.


> 
> >>
> >> 2. You might be actually planning to capture to disk 400MB/s for a
> >> sustained period which has some pretty hairy implications for
> >> storage capacity.
> >>
> > we wont store the raw data, just a very much reduced set.
> 
> So disk output bandwidth is not going to be a problem, what you are looking
> for is a way of getting 400MB/s of data into memory for post-processing,
> correct. Is it possible to break-up the input stream, so for example instead
> of reading a single stream of 400MB/s, you've five devices reading 80MB/s in
> parralel? Is the design of the device capturing the data set in stone or can
> it be "parrallelized" if so it would make the problem much simpler and any
> solution more scalable and less expensive.
this could work.  for example we have considered using 2 x scsi 320 
interfaces.  might work but its a bit of a kludge, and if we got the
two interfaces out of sync we would have a real mess.

Article: 63342
Subject: Re: 400 Mb/s ADC
From: jbp@cmu.edu (Jeff Peterson)
Date: 19 Nov 2003 16:38:34 -0800
Links: << >>  << T >>  << A >>
"MM" <mbmsv@yahoo.com> wrote in message news:<bpg42l$1o09pi$1@ID-204311.news.uni-berlin.de>...
> Do you really need to transfer raw data? Can you do some front-end
> processing to bring the speed down? If answers are 'yes' and 'no'
> respectively, think of repacking. You can pack 8 bytes into one 64-bit word.
> This brings the speed down to 50 MW/s, which should fit into regular 64/66
> PCI.
> 
> 
> /Mikhail
> 

i dont believe we can reduce the data rate by pre-processing.

yes, repacking might allow a 64/66 PCI to accept the data. i worry
that we will spend lots of time and money, but the margin will be
insufficient for it to actually work.  i have heard that some PCI
cores are not too efficient.

-Jeff

Article: 63343
Subject: Re: State Machines....
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 19 Nov 2003 19:41:27 -0500
Links: << >>  << T >>  << A >>
Did you think my comment was a criticism?  It clearly is a good way to
implement a complex or even not so complex FSM.  As long as you won't
miss the block RAM I can't see anything wrong.  It would be very easy to
set up a simple table of present state, next state with outputs.  In
fact, any time I design a complex FSM, I do that anyway.  HDL is nice,
but often a table makes the output assignments a lot more clear.  



Peter Alfke wrote:
> 
> I am not asking for the Nobel prize. I just wonder whether this is a
> practical, compact, cheap, fast and easy way to build a state machine
> inside an FPGA...
> Peter Alfke
> =============================
> rickman wrote:
> >
> > Using RAM/ROM for a FSM is about as basic as it gets.  I remember using
> > that method some 20 years ago about the same time fuse PLDs were
> > starting to appear.  Back then fuse ROMs were just about this same
> > size.
> >
> > Peter Alfke wrote:
> > >
> > > There is an April 2001 TechXclusives "Using leftover multipliers and
> > > BlockRAMs" that describes a surprisingly simple structure for a state
> > > machine with up to 256 states. I never got any feedback on this idea.
> > > There is no software tool, but it's pretty straightforward, and "pencil
> > > and paper" might suffice...
> > > http://support.xilinx.com/xlnx/xweb/xil_tx_home.jsp
> > >
> > > Peter Alfke, Xilinx Applications
> > > =============================
> > > Robert Sefton wrote:
> > > >
> > > > Stan -
> > > >
> > > > I agree with Jonathan that 200 states is nuts. Very error prone and
> > > > probably very difficult to maintain/modify. Were you parsing the
> > > > incoming data stream and making state decisions based on that? If so, a
> > > > programmable communications processor or an embedded processor (like
> > > > Nios for Altera) is a much better and more flexible choice. Some tasks
> > > > just aren't meant to be done in hardware, and parsing data streams is
> > > > one of them.
> > > >
> > > > Nice reward for delivering a working design. I hope you find a way to
> > > > exit that situation.
> > > >
> > > > Robert
> > > >
> > > > "stan" <stanandsue2000@yahooREMOVE.com> wrote in message
> > > > news:3fbb8795.3574357@news.compuserve.com...
> > > > > hi ... I have a question for the experts , I am doing a post mortem of
> > > > > my last project , it was a communication processor that was basicly a
> > > > > lot of dataflow paths controlled by several rather complex state
> > > > > machines ( 100-200 states ) ,  I did the design by thinking out the
> > > > > control and drawing the state diagrams and then coding them into VHDL
> > > > > for Quartus and into a Stratix .. it worked , after handing over the
> > > > > design to the test department they loaded a board and signed off on
> > > > > the design within a week. My fellow engineers were rather impressed
> > > > > since they knew how complex the control was.
> > > > >
> > > > > The downside here was the state machines became complex and took quite
> > > > > a while to figure out ... then transcibing them into VHDL and also
> > > > > drawing a pretty state chart for documenting the design took a while.
> > > > > Yes I know some say start right with typing VHDL but I find that hard
> > > > > to comceptualize.  Since this is a small company big $$ tools are out
> > > > > of the question.
> > > > >
> > > > > So my question ... are there tools out there that can make this
> > > > > process faster ?  like drawing the state charts on the screen and
> > > > > outputing VHDL ?  or other suggestions ???  again if these are $5-10K
> > > > > tools I won't be getting them in this company so shareware or <$1K
> > > > > tools are preferred even if they lack in some areas.
> > > > >
> > > > > The bigger downside here is that since the state machines took longer
> > > > > than I expected ( I scheduled 3 weeks of design, project took 6 weeks
> > > > > )  my manager has warned me to find another job ( fat chance ) as he
> > > > > has handed in a review requesting a 20% pay cut ... but my real
> > > > > question is about the tools so I may do better next time
> > > > >
> > > > > thanks for any constructive feedback , stan
> >
> > --
> >
> > Rick "rickman" Collins
> >
> > rick.collins@XYarius.com
> > Ignore the reply address. To email me use the above address with the XY
> > removed.
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design      URL http://www.arius.com
> > 4 King Ave                               301-682-7772 Voice
> > Frederick, MD 21701-3110                 301-682-7666 FAX

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 63344
Subject: Re: 400 Mb/s ADC
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 19 Nov 2003 17:02:57 -0800
Links: << >>  << T >>  << A >>

"Jeff Peterson" <jbp@cmu.edu> wrote in message
news:369b6e8b.0311191050.44b781b6@posting.google.com...
> we accumualte averages (of cross products of fourier tranforms)
>

Jeff,
    I think you need to do the 'we accumualte averages (of cross products of
fourier tranforms)' in your FPGA. That way you dramatically reduce your data
rate down to something sensible. It sounds tricky, but not as tricky as
getting 400M x 8 bits x 50% duty cycle = 1.6 Gbps into a PC and processing
it!
            cheers, Syms.



Article: 63345
Subject: Re: 400 Mb/s ADC
From: "Nik Simpson" <n_simpson@bellsouth.net>
Date: Wed, 19 Nov 2003 20:09:30 -0500
Links: << >>  << T >>  << A >>
Jeff Peterson wrote:
> "Nik Simpson" <n_simpson@bellsouth.net> wrote in message
> news:<vQPub.41$zi3.40@bignews3.bellsouth.net>...
>> Jeff Peterson wrote:
>>>> 1. Just capturing the data performing some operation on it, storing
>>>> the results and throwing away the sample
>>>
>>> we accumualte averages (of cross products of fourier tranforms)
>>>
>>
>> So the basic problem is getting 400MB/s of data into memory and
>> processing it, but are you reading 400MB every second, or sampling
>> say once every ten seconds. If it's every second, then you've got a
>> bigger problem because I'd be surprised if you can process it fast
>> enough to get the job done before the next sample comes along.
> we will take about 64K samples, then can pause while processing...
> however all the time we are pausing we are losing data.  so we do
> want to
> keep the duty cycle up.  50% dudty cyle is not a problem. 5% would be.
>

From my limited understanding of FFTs the actual processing should be
something that could easily be multi-threaded and would see pretty close to
linear scalability with additional CPUs, so at the very least an SMP system
with at least 2-4 CPUs would help, and assuming it's 64bit floating point
then a 64bit CPU like Opteron or Itanium might come in handy. If the idea of
multiple data streams is possible (and the synchronization problem can be
overcome) then if workload does scale well with CPUs, a cluster of low-cost
single CPU systems each processing part of the data stream would be worth
looking at as this could be easily scaled, i.e. five systems each handling
an 80MB/s stream might be cheaper and faster than one big system trying to
crunch 400MB/s. Additionally, if designed this way, then you could add
additional systems in order to increase the duty cycle, i.e. 10 systems
handing 40MB/s could be relatively cheap and would have roughly 2x the duty
cycle of the original 5 systems.


>
>>
>>>>
>>>> 2. You might be actually planning to capture to disk 400MB/s for a
>>>> sustained period which has some pretty hairy implications for
>>>> storage capacity.
>>>>
>>> we wont store the raw data, just a very much reduced set.
>>
>> So disk output bandwidth is not going to be a problem, what you are
>> looking for is a way of getting 400MB/s of data into memory for
>> post-processing, correct. Is it possible to break-up the input
>> stream, so for example instead of reading a single stream of
>> 400MB/s, you've five devices reading 80MB/s in parralel? Is the
>> design of the device capturing the data set in stone or can it be
>> "parrallelized" if so it would make the problem much simpler and any
>> solution more scalable and less expensive.
> this could work.  for example we have considered using 2 x scsi 320
> interfaces.  might work but its a bit of a kludge, and if we got the
> two interfaces out of sync we would have a real mess.

Is there any way to insert synch markers in the data stream so that the
problem of data streams getting out of sync can be handled?


-- 
Nik Simpson




Article: 63346
Subject: Re: Transforming vector position to binary value
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Thu, 20 Nov 2003 02:00:05 GMT
Links: << >>  << T >>  << A >>
There's nothing conventional about any of this technology.  An ex-boss of
mine used to say: "The second guy who saw the wheel thought it was obvious".
That, by the way, was the only sign of intelligence the guy displayed as far
as I know.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



Article: 63347
Subject: Re: SDRAM-Controller XAPP134
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Thu, 20 Nov 2003 02:21:23 GMT
Links: << >>  << T >>  << A >>
"Simone Winkler" wrote:

> Yes - I read the spec of the SDRAM. But in the Xilinx Application Note
> there's a design of a SDRAM controller that does a lot of things for me.

Consider writing your own SDRAM controller.  It isn't all that difficult and
you'll know exactly what it is doing each and every step of the way.
Besides, you can customize it to deal with your particular needs.

Write a little state machine for each operation.  They write a separate
state machine that would constitute the external command processor.  Done
deal.  Of course, this isn't the only way to do it.  You could, for example,
implement look-ahead processing to pipeline commands or modify burst access
length based on what's coming.  The challenge in high-performance SDRAM
designs (well, one challenge) is the minimization of wasted clock cycles.
Entering and exiting transactions costs clocks and this can be mitigated by
using pipelining, among other techniques.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



Article: 63348
Subject: Re: Xilinx UCF file conditional includes ?
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Thu, 20 Nov 2003 02:23:51 GMT
Links: << >>  << T >>  << A >>
I think you can do this in HDL, can't you?  Place your RLOC's and INIT's in
HDL with the right conditionals.  I could be wrong.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



"Robert Finch" <robfinch@sympatico.ca> wrote in message
news:HZPub.11926$ZF1.1181323@news20.bellglobal.com...
> Is there a way to conditionally include sections of a UCF file ? I
currently
> have a design with conditional compilation but the I/O ports and ROM
> contents specified in the UCF file need to differ based on how it's
> compiled.
>
> It'd be nice if there was some sort of #ifdef #else etc... and macro
> processing.....
>
> Rob
>
>
>



Article: 63349
Subject: Re: Apex power calculator
From: Marc Guardiani <marc@guardiani.com>
Date: Thu, 20 Nov 2003 03:36:15 GMT
Links: << >>  << T >>  << A >>
Dave,

Same result here (w/Mozilla 1.5). My suggestions:
. Try a different browser.
. Update java.
. Contact your local Altera sales rep for help.

Marc

Dave Wilson wrote:
> Hello all,
> 
> I'm trying to find the max power consumption of an Apex20ke240 with
> 3.3v vccio and 1.8v vccint. I've tried the power calculator :
> 
> http://www.altera.com/products/devices/apex/utilities/apx-20kec_calc/apx-20kec_power_calc.jsp
> 
> but it will not let me go past step 1. Has this been discontinued ?
> 
> any suggestions
> 
> Dave




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