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 147400

Article: 147400
Subject: Xilinx MIG v2.3 Spartan3A-DSP DDR2 Interface
From: Berk <berkgurakan@gmail.com>
Date: Mon, 26 Apr 2010 06:17:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hey everyone,

I have been struggling to use the MIG to generate a memory interface
to the DDR2 device. First some background info: I am using the Xilinx=AE
Spartan=AE-3A DSP XtremeDSP=99 Starter Platform. I am using ISE 10.1 with
MIG v2.3.

I have created the MIG from GUI and played around with it. I also
edited the UCF file (just changed the locations basically, did not
mess around with timings). I cannot do any simulation because I am
using Windows 7 and apparently, simulation doesn't work (or maybe some
other problem).

Anyway, the thing is I can download the code to the device and I can
see all the signals go up and down in correct times. (like init_done,
user_cmd_ack, user_data_valid etc.) Then I try to write some data to
the memory, I can see user_cmd_ack go high, then I assert burst_done,
then I can see user_cmd_ack go low. (which means write is succesful,
right?) However, whenever I try to 'read' from the memory, I always
get x"00000000" no matter what the address is. What can be wrong with
it?

Thanks for the help.

Article: 147401
Subject: Re: Xilinx MIG v2.3 Spartan3A-DSP DDR2 Interface
From: Gabor <gabor@alacron.com>
Date: Mon, 26 Apr 2010 06:39:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 26, 9:17=A0am, Berk <berkgura...@gmail.com> wrote:
> Hey everyone,
>
> I have been struggling to use the MIG to generate a memory interface
> to the DDR2 device. First some background info: I am using the Xilinx=AE
> Spartan=AE-3A DSP XtremeDSP=99 Starter Platform. I am using ISE 10.1 with
> MIG v2.3.
>
> I have created the MIG from GUI and played around with it. I also
> edited the UCF file (just changed the locations basically, did not
> mess around with timings). I cannot do any simulation because I am
> using Windows 7 and apparently, simulation doesn't work (or maybe some
> other problem).
>
> Anyway, the thing is I can download the code to the device and I can
> see all the signals go up and down in correct times. (like init_done,
> user_cmd_ack, user_data_valid etc.) Then I try to write some data to
> the memory, I can see user_cmd_ack go high, then I assert burst_done,
> then I can see user_cmd_ack go low. (which means write is succesful,
> right?) However, whenever I try to 'read' from the memory, I always
> get x"00000000" no matter what the address is. What can be wrong with
> it?
>
> Thanks for the help.

DDR2 timing is not easy to meet in the Spartan parts, so you really
can't just muck around with the pinouts.  If you changed the location
of any memory pins you need to re-run the MIG configuration GUI and
use the option to "Verify UCF".  This tells MIG to generate new
timing and directed routing constraints based on the pin locations
from your actual design.

By the way I thought that the Starter boards come with a pre-built
version of the MIG design.  Have you looked into that?

Regards,
Gabor

Article: 147402
Subject: data2mem
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Mon, 26 Apr 2010 09:02:01 -0500
Links: << >>  << T >>  << A >>
I am using data2mem to generate some .mem simulation files. My address for
memory starts at 0x86000000 and if I dump the elf file I can see that.
However when I run data2mem the .mem file starts at address 0x00000000. The
command I am using is 

data2mem -bd memory_init.bmm -bd test.elf -bx -u -i

and my bmm looks like

ADDRESS_SPACE ddr2_sdram MEMORY [0x86000000:0xA5FFFFFF]
  BUS_BLOCK
    system_tb/ddr2_0    [15:0]    OUTPUT = ddr2_0.mem;
  END_BUS_BLOCK;
END_ADDRESS_SPACE;

I cant see anything wrong unless I am missing something with data2mem.

Thanks

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147403
Subject: Re: Xilinx MIG v2.3 Spartan3A-DSP DDR2 Interface
From: Berk <berkgurakan@gmail.com>
Date: Mon, 26 Apr 2010 07:10:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 26 Nisan, 16:39, Gabor <ga...@alacron.com> wrote:
> On Apr 26, 9:17=A0am, Berk <berkgura...@gmail.com> wrote:
>
>
>
>
>
> > Hey everyone,
>
> > I have been struggling to use the MIG to generate a memory interface
> > to the DDR2 device. First some background info: I am using the Xilinx=
=AE
> > Spartan=AE-3A DSP XtremeDSP=99 Starter Platform. I am using ISE 10.1 wi=
th
> > MIG v2.3.
>
> > I have created the MIG from GUI and played around with it. I also
> > edited the UCF file (just changed the locations basically, did not
> > mess around with timings). I cannot do any simulation because I am
> > using Windows 7 and apparently, simulation doesn't work (or maybe some
> > other problem).
>
> > Anyway, the thing is I can download the code to the device and I can
> > see all the signals go up and down in correct times. (like init_done,
> > user_cmd_ack, user_data_valid etc.) Then I try to write some data to
> > the memory, I can see user_cmd_ack go high, then I assert burst_done,
> > then I can see user_cmd_ack go low. (which means write is succesful,
> > right?) However, whenever I try to 'read' from the memory, I always
> > get x"00000000" no matter what the address is. What can be wrong with
> > it?
>
> > Thanks for the help.

Hello,

> DDR2 timing is not easy to meet in the Spartan parts, so you really
> can't just muck around with the pinouts. =A0If you changed the location
> of any memory pins you need to re-run the MIG configuration GUI and
> use the option to "Verify UCF". =A0This tells MIG to generate new
> timing and directed routing constraints based on the pin locations
> from your actual design.

Actually, I did just that. First, I let MIG create a 'wrong' UCF file.
Then I changed the pinouts correctly. Then I
selected "Update Design" and pointed it to my newly edited UCF file.
Then, it changed the pinouts and timings.
But there is no change in the output. By the way I am changing the UCF
file under the user_design folder. I think
this is correct. How can I verify if I'm having a UCF error or
something else?

> By the way I thought that the Starter boards come with a pre-built
> version of the MIG design. =A0Have you looked into that?
> Regards,
> Gabor

Yeah, I did that but my Starter board is not supported.

Thanks a lot.




Article: 147404
Subject: Re: Efficient Multi-Ported Memories for FPGAs
From: Eric <eric.laforest@gmail.com>
Date: Mon, 26 Apr 2010 07:23:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 25, 10:57=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
> As to the XOR, I don't have code to share; I developed it a while ago
> for some asynchronous stuff and it applies well to multi-port writes.

The idea is definitely floating around. Multiple people have
independently suggested it to me after seeing the LVT approach. It's
definitely an interesting approach.

> As I try to put together a clearer explanation, I find I may have been
> wrong about the memory count for the XOR approach such that the LVT
> would use fewer. =A0I still believe the LVT approach requires M*N
> BlockRAMs for an M-write, N-read multi-port memory plus the LVT; I'm
> having trouble remembering why I thought the "+1" was needed. =A0The XOR
> approach appears to need M*(M-1+N) memories.
>
> If you have 3 write ports and 4 read ports, you'll need 3 sets of *6*
> memories. <snip>

Yep, you are right. The number of BlockRAMs required is M*N, plus the
LVT (which uses no Block RAMs).
Thanks for the explanation of the XOR design. You're the first to do
so. It makes a lot of sense, except I don't see why you need the extra
M-1 memories on the read side?

> The LVT needs a memory for each write port but requires multiples of
> them to accommodate every read port in case the multiple reads for any
> one cycle are all from the same write bank for the most recently
> updated value.

*Exactly*

> Depending on the complexity of the LVT, the number of write ports, and
> the allowable latencies, the LVT could be a more effective approach.

It tends to be, given the research so far, but if an extra cycle of
latency (to do the reads to get the decoding data) is acceptable for a
design, the XOR approach could be very useful. The LVT does add delay,
but it's still faster than the alternatives I explored for an
arbitrary number of ports (for small numbers, pure multipumping works
better).

Article: 147405
Subject: Re: Efficient Multi-Ported Memories for FPGAs
From: Eric <eric.laforest@gmail.com>
Date: Mon, 26 Apr 2010 07:32:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 25, 12:03=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
> 5. Your final conclusion about write-and-read schedule is not right.
> When people is using your method, they are still facing write-and-read
> scheduling.
> For example, there is a wait list pool to receive write and read
> requests, and the pool can hold 200 write requests and 200 read
> requests.
<snip>

There is no read/write scheduling problem *within a cycle*. If you
have more pending reads/writes than there are ports, then of course
there will always be a scheduling problem, but that's a different
problem more akin to that solved by reorder buffers in a dynamically
scheduled CPU.

As for simultaneous reads and writes to the same address, the
behaviour is a function of how the underlying Block RAMs are
configured. For a read and a write to the same address, you can
specify that the read port returns either the old value or the current
one being written. This doesn't affect the rest of the LVT-based
design.

In the case of two simultaneous *writes* to the same address, the
default behaviour is like most any other multiported memory:
undefined. However, there is no *physical* conflict in the banks of
Block RAMs, but only in the LVT. So you can go ahead and store both
writes and decide what to store in the LVT as part of your conflict
resolution logic (eg: lower port number has priority, etc...).


Article: 147406
Subject: Inferring mutipliers
From: dgreig <dgreig@ieee.org>
Date: Mon, 26 Apr 2010 08:20:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
Challenge : 18*18 data with one data  vector unsigned and the other
signed. FPGA DSP block actually
                       has separate signals to set the sign of each
operand.
                       If the operands are the full data width of the
DPS block inputs it is not possible to
                       "sign extend" the unsingned operand.

Anyone been able to achieve this task?

Best Regards

David Greig

Article: 147407
Subject: Re: Synplify synthesis error
From: "ilaroche" <isabellelaroche@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Mon, 26 Apr 2010 11:20:00 -0500
Links: << >>  << T >>  << A >>
>Could you try to introduce an error in the package declaration,
>just to see that the compiler/analyzer is actually looking
>at the file you think its looking at?!?
>-- Pontus
>

I removed a ";" at the end of a constant declaration in the package. The
"Compile Only" process that I ran on my entity found the error in the
package. 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147408
Subject: Re: Inferring mutipliers
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Mon, 26 Apr 2010 10:10:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 26 Apr., 17:20, dgreig <dgr...@ieee.org> wrote:
> Challenge : 18*18 data with one data =A0vector unsigned and the other
> signed. FPGA DSP block actually
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0has separate signals to se=
t the sign of each
> operand.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If the operands are the fu=
ll data width of the
> DPS block inputs it is not possible to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"sign extend" the unsingne=
d operand.
>
> Anyone been able to achieve this task?


Signed Mutlipliers usually are unsigned mutlipliers of one bit less
with extra logic to get the sign right.
Therefore you should think of Xilinx DSP block as a 17x17 multiplier.

Use an extra conditional adder after the multiplier to get 18x18 in
your case.

Kolja

Article: 147409
Subject: Re: Xilinx MIG v2.3 Spartan3A-DSP DDR2 Interface
From: Gabor <gabor@alacron.com>
Date: Mon, 26 Apr 2010 10:20:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 26, 10:10=A0am, Berk <berkgura...@gmail.com> wrote:
> On 26 Nisan, 16:39, Gabor <ga...@alacron.com> wrote:
>
>
>
> > On Apr 26, 9:17=A0am, Berk <berkgura...@gmail.com> wrote:
>
> > > Hey everyone,
>
> > > I have been struggling to use the MIG to generate a memory interface
> > > to the DDR2 device. First some background info: I am using the Xilinx=
=AE
> > > Spartan=AE-3A DSP XtremeDSP=99 Starter Platform. I am using ISE 10.1 =
with
> > > MIG v2.3.
>
> > > I have created the MIG from GUI and played around with it. I also
> > > edited the UCF file (just changed the locations basically, did not
> > > mess around with timings). I cannot do any simulation because I am
> > > using Windows 7 and apparently, simulation doesn't work (or maybe som=
e
> > > other problem).
>
> > > Anyway, the thing is I can download the code to the device and I can
> > > see all the signals go up and down in correct times. (like init_done,
> > > user_cmd_ack, user_data_valid etc.) Then I try to write some data to
> > > the memory, I can see user_cmd_ack go high, then I assert burst_done,
> > > then I can see user_cmd_ack go low. (which means write is succesful,
> > > right?) However, whenever I try to 'read' from the memory, I always
> > > get x"00000000" no matter what the address is. What can be wrong with
> > > it?
>
> > > Thanks for the help.
>
> Hello,
>
> > DDR2 timing is not easy to meet in the Spartan parts, so you really
> > can't just muck around with the pinouts. =A0If you changed the location
> > of any memory pins you need to re-run the MIG configuration GUI and
> > use the option to "Verify UCF". =A0This tells MIG to generate new
> > timing and directed routing constraints based on the pin locations
> > from your actual design.
>
> Actually, I did just that. First, I let MIG create a 'wrong' UCF file.
> Then I changed the pinouts correctly. Then I
> selected "Update Design" and pointed it to my newly edited UCF file.
> Then, it changed the pinouts and timings.
> But there is no change in the output. By the way I am changing the UCF
> file under the user_design folder. I think
> this is correct. How can I verify if I'm having a UCF error or
> something else?
>
> > By the way I thought that the Starter boards come with a pre-built
> > version of the MIG design. =A0Have you looked into that?
> > Regards,
> > Gabor
>
> Yeah, I did that but my Starter board is not supported.
>
> Thanks a lot.

Well the obvious thing you can do is check the pad report
to make sure the correct pinout is in use.  You can also go
into the FPGA editor and check that your MIG-related pins
have all the appropriate registers in the IOB tiles.

Then there's the obvious stuff like checking your clock
and reset inputs to be sure they're hooked up properly.
I've often started going down a head-scratching path
with DDR designs only to find that the active-low
reset input was connected to an active high reset signal,
or that the DCM was being reset be a register clocked
on its own output (this doesn't work with DCM's because
the CLK0 output shuts off when reset is active).

HTH,
Gabor

Article: 147410
Subject: Re: Inferring mutipliers
From: dgreig <dgreig@ieee.org>
Date: Mon, 26 Apr 2010 12:22:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 26, 6:10=A0pm, Kolja Sulimma <ksuli...@googlemail.com> wrote:
> On 26 Apr., 17:20, dgreig <dgr...@ieee.org> wrote:
>
> > Challenge : 18*18 data with one data =A0vector unsigned and the other
> > signed. FPGA DSP block actually
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0has separate signals to =
set the sign of each
> > operand.
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If the operands are the =
full data width of the
> > DPS block inputs it is not possible to
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"sign extend" the unsing=
ned operand.
>
> > Anyone been able to achieve this task?
>
> Signed Mutlipliers usually are unsigned mutlipliers of one bit less
> with extra logic to get the sign right.
> Therefore you should think of Xilinx DSP block as a 17x17 multiplier.
>
> Use an extra conditional adder after the multiplier to get 18x18 in
> your case.
>
> Kolja

Okay, for Altera there are actually "signa" and "signb" controls for
inputs a and b respectively, so it is physically possible to have
signal a_i       : unsigned(17 downto 0);
signal b_i       : signed(17 downto 0);
signal axb_o  : signed(35 downto 0);

Suppose the application is DSP on physical data that happens to be
unsigned by nature with the other operand signed - if the data
consists of 18 "good" bits and the application requires all 18 then it
is undesirable not to utilise all of the resources.
Perhaps suppose it is image sensor data and feature detection DSP.
Data is naturally unsigned and the other operand mostly signed. In
this case say 9*9 and 2D DSP. Losing a bit off the image data is
certainly undesirable and the alternative cosly or limits function if
18*18 multipliers have to be inferred as a kludge.

Best Regards

DG

Article: 147411
Subject: Re: Inferring mutipliers
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 26 Apr 2010 19:46:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
dgreig <dgreig@ieee.org> wrote:
> Challenge : 18*18 data with one data  vector unsigned and the other
> signed. FPGA DSP block actually has separate signals to set the 
> sign of each operand.

> If the operands are the full data width of the DPS block inputs 
> it is not possible to "sign extend" the unsingned operand.
 
> Anyone been able to achieve this task?

For twos complement multiply, you subtract instead of add if the
sign bit is one.  So all the signed/unsigned control input does
is to turn an adder into a subtractor.  Signed or unsigned, an
N by N bit product fits into 2N bits.

-- glen

Article: 147412
Subject: Re: Inferring mutipliers
From: "Pete Fraser" <pfraser@covad.net>
Date: Mon, 26 Apr 2010 13:42:51 -0700
Links: << >>  << T >>  << A >>
"dgreig" <dgreig@ieee.org> wrote in message 
news:8c1c9a60-fef0-4aa2-aa00-54761db33af0@s41g2000vba.googlegroups.com...

> Perhaps suppose it is image sensor data and feature detection DSP.
> Data is naturally unsigned and the other operand mostly signed. In
> this case say 9*9 and 2D DSP. Losing a bit off the image data is
> certainly undesirable and the alternative cosly or limits function if
> 18*18 multipliers have to be inferred as a kludge.

One trick I've used is to convert the unsigned data to signed
at the filter input, then back to unsigned on the output.
Most of the video filters I built in the late 70s worked that way.
Once you've wrapped your brain round mid-grey being 0, it's
easy to deal with. 



Article: 147413
Subject: Booting Linux from my own bootloader
From: Martin =?UTF-8?B?QnLDvGNrbmVy?= <bj2spam@alice-dsl.net>
Date: Mon, 26 Apr 2010 22:50:19 +0200
Links: << >>  << T >>  << A >>
Hello,

I'm writing a boot loader to start Linux on the PowerPC440 (Virtex5FXT).
At first the program copies the kernel into the RAM at address
0x00400000 and afterwards it boots Linux with the following lines:

#define LINUX_START_ADDRESS 0x004002b4

int main()
{
	void (*linux)();
	linux = (void*) LINUX_START_ADDRESS;

	... // here is the code which copies the kernel into ram

	(*linux)();
}

With the following steps, booting works fine:
(1). comment out the line (*linux)();
(2). start the program
(3). start xmd and enter "rst -processor"
(4). set the program counter: "rwr pc 0x004002b4"
(5). enter "con"

What does not work:
Starting Linux directly within the program with the last line.
All I can see is the following and thats all.

zImage starting: loaded at 0x00400000 (sp: 0x00569fb0)
Allocating 0x2efa98 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040d000:0x0056837e)...done 0x2d2270 bytes

Linux/PowerPC load: console=ttyUL0 root=/dev/mmcblk0p1 rootdelay=5
Finalizing device tree... flat tree at 0x576300



So the question is: What do I have to do to boot Linux from within the
program?


Best Regards
Martin Brückner

Article: 147414
Subject: ISE tools not detecting IOSTANDARD conflicts within bank
From: Eli <eli.billauer@gmail.com>
Date: Mon, 26 Apr 2010 13:59:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello,

I'm running ISE 9.2.03i on a design for Spartan 3E (3s250e-4tq144).

For whoever wishes to skip the long description below, the idea is
simple: The tools should not agree to place pins with conflicting IO
standards, such as LVTTL and LVCMOS25, on the same bank. And suddenly
I caught the tools not noticing this. This clearly looks like a bug,
among others because slight tweaks with the source Verilog makes the
tools reject the conflict, as they should.

My question is if someone has had similar experience, and if there's a
way to be sure that the tools indeed detect collisions when they
occur.

And now to the long story, for those who want the details. A lot of
details, which I doubt if they're relevant. But anyhow.

Recently, I've been doing this pin placement back-and-forth with the
board designer. Since the logic isn't written yet, I've written dummy
logic for the I/O pins. So each time the board designer wants a
change, I make the change in the UCF file, run an implementation, and
see if there are complaints. If they do, I get an error like the
example at the bottom of this post (in case of an IO standard
violation), or errors about problems in clock routing. For a few
years, this has been my method to quickly approve pinouts, until this
method failed recently.

What I found out, is that the tools agreed to place LVTTL pins and
LVCMOS25 on the same bank, if they were defined as inouts (that is,
bidirectional). I verified this by looking at the pad report and with
FPGA editor. If I made both pins outputs, the tools refused, as they
should. Other irrelevant tweaks with the code (such as commenting out
irrelevant parts) also woke up the sleeping guard.

The method I use for checking is instantiating a module like at the
bottom of this message. The IOSTANDARD parameter is set at
instantiation to the desired standard. The module generates DDR flip-
flops for both input and output, so if placement and routing succeeds,
I know that the certain pin's placement is OK, and that IOB registers
with the given clock can be packed. Or so I thought.

I have, of course, other modules for input-only, output-only,
nonclocked IOs, differential IOs and such.

This looks like a bug in the tools. Unfortunately, I failed to make a
simple example which demonstrates the bug. It looks like the tools are
OK most of the time, but it's disturbing that they may fail on me even
once (and make me approve a faulty board design).

So has anyone encountered a similar problem?

Thanks in advance,
    Eli

---------------------------


Example of error from placer.
============================

ERROR:Place:864 - Incompatible IOB's are locked to the same bank 3
   Conflicting IO Standards are:
   IO Standard 1: Name = LVCMOS25, VREF = NR, VCCO = 2.50, TERM = NONE
   List of locked IOB's:
   	data<0>
   	data<1>

   IO Standard 2: Name = LVTTL, VREF = NR, VCCO = 3.30, TERM = NONE
   List of locked IOB's:
   	testpoints<1>
   	testpoints<3>

The test module
===============

module testiob #(parameter IOSTANDARD = "LVTTL")
   (inout pin,
    input clk);

   wire   in, out, T;
   wire   in_fall, in_rise;

   reg 	  in_fall_d, in_rise_d;

   always @(posedge clk)
     begin
	in_fall_d <= in_fall;
	in_rise_d <= in_rise;
     end

   // This is completely useless setting. It just puts the IOB in
place.
   // It may drive the lines crazy if used for real

   IOBUF  #(.IOSTANDARD(IOSTANDARD)) iobuf
     (.IO(pin), .I(out), .O(in), .T(T));

   ODDR2 #(.SRTYPE("ASYNC")) out_ddr
     (.Q (out),
      .C0   (clk),
      .C1   (!clk),
      .CE (1'b1),
      .R (1'b0),
      .D0 (in_rise_d),
      .D1 (in_fall_d),
      .S (1'b0));

   ODDR2 #(.SRTYPE("ASYNC")) T_ddr
     (.Q (T),
      .C0   (clk),
      .C1   (!clk),
      .CE (1'b1),
      .R (1'b0),
      .D0 (in_rise_d),
      .D1 (in_fall_d),
      .S (1'b0));

   IDDR2 #(.SRTYPE("ASYNC")) in_ddr
     (
      .Q0   (in_rise),
      .Q1   (in_fall),
      .C0   (clk),
      .C1   (!clk),
      .CE   (1'b1),
      .D    (in),
      .R    (1'b0),
      .S (1'b0));

endmodule

Article: 147415
Subject: Re: Quartus II under Windows7?
From: Wastrel <stephensdigital@gmail.com>
Date: Mon, 26 Apr 2010 14:09:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 25, 11:54=A0pm, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> On 23/04/2010 21:39, Rich Webb wrote:
>
>
>
>
>
> > On Fri, 23 Apr 2010 10:19:07 -0700 (PDT), Wastrel
> > <stephensdigi...@gmail.com> =A0wrote:
>
> >> On Apr 21, 1:08 pm, Jon Beniston<j...@beniston.com> =A0wrote:
> >>> It's running ok for me on Windows 7 64-bit.
>
> >>> What particular part of the software are you having problems with?
>
> >>> Jon
>
> >> Well it installs alright, but Altium Designer 6 can't find it -
> >> whereas it did on my XP box. One problem is that Windows 7 likes to
> >> put 32 bit legacy programs under Program FIles(x86), but Quartus won't
> >> install there because it can't handle spaces or special characters in
> >> it's filenames.
>
> > Tell it to use the 8.3 name for the directory (one way of seeing this i=
s
> > to do a "dir /X" from a command prompt). For the directory above, the
> > name would be "c:\progra~2\".
>
> Alternatively, avoid "Program Files" or "Program Files (x86)" like the
> plague - these are seriously stupid path names MS has chosen.
>
> When installing almost any new software, you have a free choice of the
> installation path - if you think you might ever want to refer to the
> program or its files by path name (such as the command line), use
> something like "c:\Progs\" as the base instead of "c:\Program Files".
>
> I have no idea whether this will help you here or not, but it will avoid
> the awkward installation path.- Hide quoted text -
>
> - Show quoted text -

Well Altium support got back to me and said basically the same thing
you guys are: "It works OK for me"

They told me to verify that the system environment variable
"QUARTUS_ROOTDIR" pointed to the right folder - it did. I upgraded the
OS to Windows 7 Professional from "Home Premium" still no joy. When I
run Windows' compatibility troubleshooter it comes back with
"Incompatible Application" so there's something funky going on. I'm
wasting way to much time on this stupid problem, but it's not so easy
finding an XP box anymore so I'm not just sure what my next move is.

Article: 147416
Subject: Re: ISE tools not detecting IOSTANDARD conflicts within bank
From: d_s_klein <d_s_klein@yahoo.com>
Date: Mon, 26 Apr 2010 14:14:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 26, 1:59=A0pm, Eli <eli.billa...@gmail.com> wrote:
> Hello,
>
> I'm running ISE 9.2.03i on a design for Spartan 3E (3s250e-4tq144).
>
> For whoever wishes to skip the long description below, the idea is
> simple: The tools should not agree to place pins with conflicting IO
> standards, such as LVTTL and LVCMOS25, on the same bank. And suddenly
> I caught the tools not noticing this. This clearly looks like a bug,
> among others because slight tweaks with the source Verilog makes the
> tools reject the conflict, as they should.
>
> My question is if someone has had similar experience, and if there's a
> way to be sure that the tools indeed detect collisions when they
> occur.
>
> And now to the long story, for those who want the details. A lot of
> details, which I doubt if they're relevant. But anyhow.
>
> Recently, I've been doing this pin placement back-and-forth with the
> board designer. Since the logic isn't written yet, I've written dummy
> logic for the I/O pins. So each time the board designer wants a
> change, I make the change in the UCF file, run an implementation, and
> see if there are complaints. If they do, I get an error like the
> example at the bottom of this post (in case of an IO standard
> violation), or errors about problems in clock routing. For a few
> years, this has been my method to quickly approve pinouts, until this
> method failed recently.
>
> What I found out, is that the tools agreed to place LVTTL pins and
> LVCMOS25 on the same bank, if they were defined as inouts (that is,
> bidirectional). I verified this by looking at the pad report and with
> FPGA editor. If I made both pins outputs, the tools refused, as they
> should. Other irrelevant tweaks with the code (such as commenting out
> irrelevant parts) also woke up the sleeping guard.
>
> The method I use for checking is instantiating a module like at the
> bottom of this message. The IOSTANDARD parameter is set at
> instantiation to the desired standard. The module generates DDR flip-
> flops for both input and output, so if placement and routing succeeds,
> I know that the certain pin's placement is OK, and that IOB registers
> with the given clock can be packed. Or so I thought.
>
> I have, of course, other modules for input-only, output-only,
> nonclocked IOs, differential IOs and such.
>
> This looks like a bug in the tools. Unfortunately, I failed to make a
> simple example which demonstrates the bug. It looks like the tools are
> OK most of the time, but it's disturbing that they may fail on me even
> once (and make me approve a faulty board design).
>
> So has anyone encountered a similar problem?
>
> Thanks in advance,
> =A0 =A0 Eli
>
> ---------------------------
>
> Example of error from placer.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
>
> ERROR:Place:864 - Incompatible IOB's are locked to the same bank 3
> =A0 =A0Conflicting IO Standards are:
> =A0 =A0IO Standard 1: Name =3D LVCMOS25, VREF =3D NR, VCCO =3D 2.50, TERM=
 =3D NONE
> =A0 =A0List of locked IOB's:
> =A0 =A0 =A0 =A0 data<0>
> =A0 =A0 =A0 =A0 data<1>
>
> =A0 =A0IO Standard 2: Name =3D LVTTL, VREF =3D NR, VCCO =3D 3.30, TERM =
=3D NONE
> =A0 =A0List of locked IOB's:
> =A0 =A0 =A0 =A0 testpoints<1>
> =A0 =A0 =A0 =A0 testpoints<3>
>
> The test module
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> module testiob #(parameter IOSTANDARD =3D "LVTTL")
> =A0 =A0(inout pin,
> =A0 =A0 input clk);
>
> =A0 =A0wire =A0 in, out, T;
> =A0 =A0wire =A0 in_fall, in_rise;
>
> =A0 =A0reg =A0 =A0in_fall_d, in_rise_d;
>
> =A0 =A0always @(posedge clk)
> =A0 =A0 =A0begin
> =A0 =A0 =A0 =A0 in_fall_d <=3D in_fall;
> =A0 =A0 =A0 =A0 in_rise_d <=3D in_rise;
> =A0 =A0 =A0end
>
> =A0 =A0// This is completely useless setting. It just puts the IOB in
> place.
> =A0 =A0// It may drive the lines crazy if used for real
>
> =A0 =A0IOBUF =A0#(.IOSTANDARD(IOSTANDARD)) iobuf
> =A0 =A0 =A0(.IO(pin), .I(out), .O(in), .T(T));
>
> =A0 =A0ODDR2 #(.SRTYPE("ASYNC")) out_ddr
> =A0 =A0 =A0(.Q (out),
> =A0 =A0 =A0 .C0 =A0 (clk),
> =A0 =A0 =A0 .C1 =A0 (!clk),
> =A0 =A0 =A0 .CE (1'b1),
> =A0 =A0 =A0 .R (1'b0),
> =A0 =A0 =A0 .D0 (in_rise_d),
> =A0 =A0 =A0 .D1 (in_fall_d),
> =A0 =A0 =A0 .S (1'b0));
>
> =A0 =A0ODDR2 #(.SRTYPE("ASYNC")) T_ddr
> =A0 =A0 =A0(.Q (T),
> =A0 =A0 =A0 .C0 =A0 (clk),
> =A0 =A0 =A0 .C1 =A0 (!clk),
> =A0 =A0 =A0 .CE (1'b1),
> =A0 =A0 =A0 .R (1'b0),
> =A0 =A0 =A0 .D0 (in_rise_d),
> =A0 =A0 =A0 .D1 (in_fall_d),
> =A0 =A0 =A0 .S (1'b0));
>
> =A0 =A0IDDR2 #(.SRTYPE("ASYNC")) in_ddr
> =A0 =A0 =A0(
> =A0 =A0 =A0 .Q0 =A0 (in_rise),
> =A0 =A0 =A0 .Q1 =A0 (in_fall),
> =A0 =A0 =A0 .C0 =A0 (clk),
> =A0 =A0 =A0 .C1 =A0 (!clk),
> =A0 =A0 =A0 .CE =A0 (1'b1),
> =A0 =A0 =A0 .D =A0 =A0(in),
> =A0 =A0 =A0 .R =A0 =A0(1'b0),
> =A0 =A0 =A0 .S (1'b0));
>
> endmodule

Similar problem, yes.  It is possible to specify an invalid IOTYPE
when instantiating an IOBUF.  Not a single step in the chain detects
it - it goes all the way -through- bitgen without a single warning.

"Version 12 will fix it"  (And it will pick winning lotto numbers
too!)

RK

Article: 147417
Subject: Re: Quartus II under Windows7?
From: radarman <jshamlet@gmail.com>
Date: Mon, 26 Apr 2010 14:16:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 26, 4:09=A0pm, Wastrel <stephensdigi...@gmail.com> wrote:
> On Apr 25, 11:54=A0pm, David Brown <da...@westcontrol.removethisbit.com>
> wrote:
>
>
>
> > On 23/04/2010 21:39, Rich Webb wrote:
>
> > > On Fri, 23 Apr 2010 10:19:07 -0700 (PDT), Wastrel
> > > <stephensdigi...@gmail.com> =A0wrote:
>
> > >> On Apr 21, 1:08 pm, Jon Beniston<j...@beniston.com> =A0wrote:
> > >>> It's running ok for me on Windows 7 64-bit.
>
> > >>> What particular part of the software are you having problems with?
>
> > >>> Jon
>
> > >> Well it installs alright, but Altium Designer 6 can't find it -
> > >> whereas it did on my XP box. One problem is that Windows 7 likes to
> > >> put 32 bit legacy programs under Program FIles(x86), but Quartus won=
't
> > >> install there because it can't handle spaces or special characters i=
n
> > >> it's filenames.
>
> > > Tell it to use the 8.3 name for the directory (one way of seeing this=
 is
> > > to do a "dir /X" from a command prompt). For the directory above, the
> > > name would be "c:\progra~2\".
>
> > Alternatively, avoid "Program Files" or "Program Files (x86)" like the
> > plague - these are seriously stupid path names MS has chosen.
>
> > When installing almost any new software, you have a free choice of the
> > installation path - if you think you might ever want to refer to the
> > program or its files by path name (such as the command line), use
> > something like "c:\Progs\" as the base instead of "c:\Program Files".
>
> > I have no idea whether this will help you here or not, but it will avoi=
d
> > the awkward installation path.- Hide quoted text -
>
> > - Show quoted text -
>
> Well Altium support got back to me and said basically the same thing
> you guys are: "It works OK for me"
>
> They told me to verify that the system environment variable
> "QUARTUS_ROOTDIR" pointed to the right folder - it did. I upgraded the
> OS to Windows 7 Professional from "Home Premium" still no joy. When I
> run Windows' compatibility troubleshooter it comes back with
> "Incompatible Application" so there's something funky going on. I'm
> wasting way to much time on this stupid problem, but it's not so easy
> finding an XP box anymore so I'm not just sure what my next move is.

If you are running Win7 Pro, and your hardware supports
virtualization, you might consider installing the XP VM from
Microsoft. It's a full-function version of Windows XP SP3, and it runs
in a VM environment a bit like Parallels on the Mac. (IOW,
applications appear on the desktop like any other, rather than in a
separate VM window) Best of all, it's free for Win7 Pro and higher.

Of course, you would need to install both Altium and Quartus in the
VM, but that should replicate your old environment fairly closely. I
believe the VM is 32-bit only. While it will run on a 64-bit OS, you
will be limited to less than 4GB of RAM.

Note, I haven't tried it - since my only Win7 machine doesn't have the
right CPU support - but this is the sort of scenario it was meant for.

Article: 147418
Subject: Re: Booting Linux from my own bootloader
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 26 Apr 2010 22:08:02 +0000 (UTC)
Links: << >>  << T >>  << A >>
Martin Br?ckner <bj2spam@alice-dsl.net> wrote:
 
> I'm writing a boot loader to start Linux on the PowerPC440 (Virtex5FXT).
> At first the program copies the kernel into the RAM at address
> 0x00400000 and afterwards it boots Linux with the following lines:
 
> #define LINUX_START_ADDRESS 0x004002b4
 
(snip)
 
>        (*linux)();

With the assumption that data pointers can be properly
cast to function pointers, that line should jump to 
location 0x4002b4 and start executing the code there.
 
> With the following steps, booting works fine:
> (1). comment out the line (*linux)();
> (2). start the program
> (3). start xmd and enter "rst -processor"
> (4). set the program counter: "rwr pc 0x004002b4"
> (5). enter "con"

I presume that mostly starts executing at 0x4002b4?

> What does not work:
> Starting Linux directly within the program with the last line.
> All I can see is the following and thats all.
 
> zImage starting: loaded at 0x00400000 (sp: 0x00569fb0)
> Allocating 0x2efa98 bytes for kernel ...
> gunzipping (0x00000000 <- 0x0040d000:0x0056837e)...done 0x2d2270 bytes
 
> Linux/PowerPC load: console=ttyUL0 root=/dev/mmcblk0p1 rootdelay=5
> Finalizing device tree... flat tree at 0x576300

So it does start executing, and doing things that it is
supposed to do, but doesn't end up working?

> So the question is: What do I have to do to boot Linux from within the
> program?

-- glen

Article: 147419
Subject: Re: Efficient Multi-Ported Memories for FPGAs
From: John_H <newsgroup@johnhandwork.com>
Date: Mon, 26 Apr 2010 15:52:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 26, 10:23=A0am, Eric <eric.lafor...@gmail.com> wrote:
>
> Yep, you are right. The number of BlockRAMs required is M*N, plus the
> LVT (which uses no Block RAMs).
> Thanks for the explanation of the XOR design. You're the first to do
> so. It makes a lot of sense, except I don't see why you need the extra
> M-1 memories on the read side?

Because the write of the new data is the DataIn XORed with the old
data at the new WrAddr, each write address needs a read from the other
write memory sets.

For M write ports, there are M write sets.  Each write set has the N
read memories for the N-port read and also has M-1 reads
from_the_other_write_addresses to complete the XORed data value to
store to those write sets.

Article: 147420
Subject: Re: Quartus II under Windows7?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 26 Apr 2010 23:33:32 +0000 (UTC)
Links: << >>  << T >>  << A >>
Wastrel <stephensdigital@gmail.com> wrote:
(snip)
 
> Well Altium support got back to me and said basically the same thing
> you guys are: "It works OK for me"
 
> They told me to verify that the system environment variable
> "QUARTUS_ROOTDIR" pointed to the right folder - it did. I upgraded the
> OS to Windows 7 Professional from "Home Premium" still no joy. When I
> run Windows' compatibility troubleshooter it comes back with
> "Incompatible Application" so there's something funky going on. I'm
> wasting way to much time on this stupid problem, but it's not so easy
> finding an XP box anymore so I'm not just sure what my next move is.

As I understand it, starting with Vista Windows won't run 16 bit
code anymore.  It seems that a surprising amount of such code
still exists and causes problems, though I am a little surprised
it would happen in this case.

-- glen

Article: 147421
Subject: Re: I'd rather switch than fight!
From: Andy <jonesandy@comcast.net>
Date: Mon, 26 Apr 2010 17:15:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
Cliff's paper is about avoiding race conditions. However, in vhdl
"blocking assignements" (to unshared variables) are limited to local
process/subprogram scope anyway, so you never have problems with race
conditions with them. That is why it is safe and even beneficial to
use blocking assignments (to unshared variables) in VHDL clocked
processes. Combine that with the flexibility afforded in describing
both combinatorial and sequential logic in the same process, and it
makes for an extremely powerful, yet safe concept. While some may
struggle with identifying where the registers are located in relation
to the combinatorial logic, understanding the cycle-based behavior is
more intuitive, since the code "reads and executes like SW". Given the
increasing use of retiming optimizations, knowing where registers are
located in your RTL is rapidly becoming useless anyway.

For the remaining < 1% of the time when I need an in-to-out
combinatorial logic path through a module/entity, I'll go ahead and
use a combinatorial process (implied by a concurrent assignment or
otherwise). That doesn't mean I'm going to throw away the benefits of
using only clocked processes for the other > 99%, just for purity's
sake.

Andy

Article: 147422
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Mon, 26 Apr 2010 18:26:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 26, 7:15=A0pm, Andy <jonesa...@comcast.net> wrote:
> Cliff's paper is about avoiding race conditions. However, in vhdl
> "blocking assignements" (to unshared variables) are limited to local
> process/subprogram scope anyway, so you never have problems with race
> conditions with them. That is why it is safe and even beneficial to
> use blocking assignments (to unshared variables) in VHDL clocked
> processes. Combine that with the flexibility afforded in describing
> both combinatorial and sequential logic in the same process, and it
> makes for an extremely powerful, yet safe concept. While some may
> struggle with identifying where the registers are located in relation
> to the combinatorial logic, understanding the cycle-based behavior is
> more intuitive, since the code "reads and executes like SW". Given the
> increasing use of retiming optimizations, knowing where registers are
> located in your RTL is rapidly becoming useless anyway.
>
> For the remaining < 1% of the time when I need an in-to-out
> combinatorial logic path through a module/entity, I'll go ahead and
> use a combinatorial process (implied by a concurrent assignment or
> otherwise). That doesn't mean I'm going to throw away the benefits of
> using only clocked processes for the other > 99%, just for purity's
> sake.

Yes, the two process model probably isn't nearly as useful in VHDL.

As others have been quick to point out, you don't need a combinatorial
process in verilog either, but then you have to be careful about
blocking vs. non-blocking, not using variables which have blocking
assignments to them from other processes, etc.  The two process model
is simply an organizing principle that provides a separation of
concerns and simplifies the rules a bit, making it easier to reason
about the code.  Extremely simple code doesn't gain anything from
using this model, but a lot of real-world code does.

Regards,
Pat

Article: 147423
Subject: Re: confusion with ADC/DAC interface implementation
From: JimLewis <Jim@SynthWorks.com>
Date: Mon, 26 Apr 2010 21:05:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 5:41=A0pm, alk...@yahoo.co.uk wrote:
> Hi,
> i am confused regarding the ADC/DAC interface implementation on FPGA.
> I have read a code where after serialising the input data of 16 bits
> in 16 clock cycles, the interface logic loops (in vain?) for another
> 16 cyles =A0before serialising the next data. can#t understand why? why
> the serialisation of the next data is not done immediately. moreover,
> should the serialisation clock rate be 16 higher than the data stream
> clock rate? Sorry but i could not find a documentation detailing all
> the synchronization mechanism.
>
> cheers :)



For details of this, look up a UART in a text book.

Here is a hint in the right direction.
Assume that data (digital or analog) is transmitted between two
devices
at a certain rate, but asynchronously ie: no clock in the interface.
Can the receive clock be the same frequency of the transmit clock?
Assume there is no way to guarantee any relationship between the
two clocks.  In fact, it is common for them to be slightly
different in frequency.

If the sample clock is 16X faster than the transmit, the middle
of a cycle is found when a start indication is found 8 times.
Then capturethe data values once every 16 times (because the
receive clockis 16X faster).  With this slight differences in
frequency
can be tolerated - depending how many samples are taken between
realigning with a start bit.

Good Luck,
Jim
SynthWorks VHDL

Article: 147424
Subject: Re: Booting Linux from my own bootloader
From: Martin =?UTF-8?B?QnLDvGNrbmVy?= <bj2spam@alice-dsl.net>
Date: Tue, 27 Apr 2010 10:03:34 +0200
Links: << >>  << T >>  << A >>
Am Mon, 26 Apr 2010 22:08:02 +0000 (UTC)
schrieb glen herrmannsfeldt <gah@ugcs.caltech.edu>:

> Martin Br?ckner <bj2spam@alice-dsl.net> wrote:
>  
> > I'm writing a boot loader to start Linux on the PowerPC440
> > (Virtex5FXT). At first the program copies the kernel into the RAM
> > at address 0x00400000 and afterwards it boots Linux with the
> > following lines:
>  
> > #define LINUX_START_ADDRESS 0x004002b4
>  
> (snip)
>  
> >        (*linux)();
> 
> With the assumption that data pointers can be properly
> cast to function pointers, that line should jump to 
> location 0x4002b4 and start executing the code there.
>  
> > With the following steps, booting works fine:
> > (1). comment out the line (*linux)();
> > (2). start the program
> > (3). start xmd and enter "rst -processor"
> > (4). set the program counter: "rwr pc 0x004002b4"
> > (5). enter "con"
> 
> I presume that mostly starts executing at 0x4002b4?

Yes.

> 
> > What does not work:
> > Starting Linux directly within the program with the last line.
> > All I can see is the following and thats all.
>  
> > zImage starting: loaded at 0x00400000 (sp: 0x00569fb0)
> > Allocating 0x2efa98 bytes for kernel ...
> > gunzipping (0x00000000 <- 0x0040d000:0x0056837e)...done 0x2d2270
> > bytes
>  
> > Linux/PowerPC load: console=ttyUL0 root=/dev/mmcblk0p1 rootdelay=5
> > Finalizing device tree... flat tree at 0x576300
> 
> So it does start executing, and doing things that it is
> supposed to do, but doesn't end up working?

Yes, exactly. When resetting the CPU before booting, everything is
fine. But in this case it ends up here.
At the moment I'm learning how to extract the syslog out of Linux to get
messages before the console is initialized. I'll post the result here,
soon.

> 
> > So the question is: What do I have to do to boot Linux from within
> > the program?
> 
> -- glen
-- Martin Brückner



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