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 61300

Article: 61300
Subject: Re: DP RAM infering
From: "Vinh Pham" <a@a.a>
Date: Wed, 01 Oct 2003 20:08:32 GMT
Links: << >>  << T >>  << A >>
Robert,

Kudos on figuring out #1 on your own.  I find when I've finally given up on
a problem and turn to someone for help, during the act of explaining it, the
answer comes to me.  Funny how the mind works.

> type RAM_TYPE is array(7 downto 0) of std_logic_vector(7 downto 0);
> signal RAM : RAM_TYPE;

One trick I use for initializing RAMs for simulation is:

    signal RAM : RAM_TYPE := (others => (others => '0'));

The nice thing is I don't have to change the initialization even when I
change the dimention of the ram.  This works in Aldec.  Never tried XST.

As for #2, the problem is you have three addresses hooked up to your DP ram:
RDBYTE_CNT, DPRA, and A.  One port is a R/W port and must use the same
address for both R and W.  The second port is R only and has it's own
address.  That answers the "Why did XST infer two RAMs?"

You can answer the "Did XST infer two RAMs?" yourself by setting up a very
simple design that only contains your RAM code.  Then look at the resource
utilization.  Your 8x8 DPRAM should only use up 8(bit width) * 1(since your
depth isn't greater than 16) *2(ports) = 16 LUTs.  You can also use FPGA
Editor or Floorplanner if you want to visually check what happened.

Hope that helps.


Regards,
Vinh



Article: 61301
Subject: Re: Ask the hotline, you may be surprised and pleased (but not likely)
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 01 Oct 2003 16:32:51 -0400
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Rick,
> 
> Here is my 5th try to respond.  Maybe I will send it.
> 
> See below.
> 
> Austin
> 
> rickman wrote:
> <snip>
> 
> >
> > > Unfortunate.  If you don't ask, you don't get an answer.  Try it.  If it doesn't > work, let us (me) know.  You
> > must prefer doing everything the hardest way > possible.  We also do not appreciate the slamming of our hotline
> > staff.
> >
> > I don't understand why you feel the need to shoot the messenger.
> 
> I did not shoot him.  I merely mentioned that he should try to get support through the normal channels.  And if that
> did not work, to contact the folks who are watching the watchers.  And not slam a service that he did not use.

You didn't shoot him with a gun, but you criticized him for "slamming"
your service which he *HAS* used and found to be lacking.  


> >  The hotline staff of most companies is just as Lecroy described, eager to
> > end the call as that is how they are evaluated.  Xilinx is no exception
> > and this has been noted here on more than one occasion.
> 
> Perhaps in your mind, but to us it is deadly serious, and we deny that your comments are accurate, or truthful.  Sure,
> one can get a bad answer, or a wrong answer, and occasionally an answer that did not meet your timeline;  but if that
> case is closed before you say you are happy, it is cause for dismissal.

I also like the way that I get survey requests on every case, but I have
never heard back from anyone when I fill one out and indicate that a
case was prematurely closed or the result was otherwise unsatisfactory.  


> > This newsgroup is a place of all of us to share our experiences and
> > opinions and I, for one, don't appreciate your criticism of Lecroy's
> > post.
> 
> OK.  Like you said, all opinions are welcome.
> 
> >  If you feel his experience is not typical, then feel free to say
> > so,
> 
> I did.
> 
> > but certainly you have no expectation that he should not express his
> > experience or opinion.
> 
> He is free to say anything he wants, as are you.

And receive criticism for giving his experiences.  


> > > Theya re all dedicated to helping our customers succeed, as that is what sells    > parts, not "closed cases."  If
> > a hotline engineer can not resolve the problem       > within a fixed amount of time, it is escalated.  Once
> > escalated, it then goes up    > the  ladder til it reaches someone who can resolve the issue.
> 
> > That is your opinion of how the process works.
> 
> No, that is the way it does work.  I helped re-write it.  And audit it.

But you don't execute it.  As far as I am aware you have not monitored
any of the cases described here either.  I don't believe you are in the
chain of command for the hotline.  The bottom line is that you feel the
hotline works one way and many of us have different experiences. 
Obviously our experiences are only "in our minds".  


> >  Many people have had different experiences.
> 
> Then let Peter and I know:  I want dates, case numbers and names.  I want to know of any unhappy customers anywhere.
> And yes, I would prefer it sent directly, not the newsgroup, so we can research it properly, and get it resolved ASAP.

It is seldom worth an engineers effort to persue a hotline case for more
than a couple of days, much less follow up with a bad case.  If you want
to follow up on poorly handled cases, why aren't the surveys read and
responded to?  


> >  Often it is not escalated until the customer requests.
> 
> Uh, that is how it works, the proceedure is that the customer has to say how urgent the matter is AND the time limits
> have to start getting exceeded.

So if a customer does not know that there are levels of support and the
person providing the support has run out of ideas, the customer is
expected to figure out to ask for a higher level?   Sounds pretty silly
to me.  Once engineers get familiar with support that may be automatic,
but I remember my experiences with support and just how long it took me
to learn how to navigate the support pathways to try to get to someone
who actually knows about the problem.  

I have also had the first level of support refuse to let me talk to the
engineer who actually knew something about the problem.  Instead he
insisted that he be my point of contact and that he would relay the
information back and forth to the other engineers.  Unfortunately this
required several relays just to get the question across since the second
level support kept believing that the first level was relaying the
question wrong.  

The bottom line is that many engineers refuse to contact support even
when told to.  Their experience has led them to feel that the whole
process is poor and not worth the effort.  

You can believe what you want, but this is what I have found at most of
the companines where I have worked.  This is not just my opinion, but
that of many engineers.  


> >  Overall the experience can be so frustrating that the
> > customer doesn't push very hard to get a real answer and gives up after
> > a few conversations.
> 
> Haven't met any like that.  Perhaps there are those who are so timid they can't use a hotline?  The customers that I
> meet are not shy at all about demanding the best service.  And right now, if they don't get the answer, they are likely
> to be part of the next layoff, so it is hard for me to see how a customer would not make every effort to get their
> problem resolved.

<sarcastic mode on> 
Yes, I think you are right.  The problem is not with the hotline, it is
with the customers.  Of course the hotline has been designed to provide
the best level of support under all conditions and any customer who has
less than a fully satifactory experience must have been poorly trained
or is suffering from a personality disorder. 
<sarcastic mode off> 

Denial is not just a river in Egypt.  

Enjoy your boat tour Austin. 

-- 

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: 61302
Subject: Re: Digesting runs of ones or zeros "well"
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 01 Oct 2003 16:55:53 -0400
Links: << >>  << T >>  << A >>
John_H wrote:
> 
> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> news:3F7B2060.A4FA04B@yahoo.com...
> > I can't say I really understand your problem statement.  I also don't
> > see how your code is solving the problem.  Can you give a better
> > explanation of the problem?  What do you mean "from the byte
> > boundaries"?  Are you counting only the bit sets of {0..8}, {8..16},
> > {16..24}...?  If so, this seems like an easy problem to implement.
> 
> You have it right - 8:0, 16:8, 24:16....  In the 41 bits illustrated below I
> want to note when the sequence across [16:8] (illustrated by the 9 1s below
> the count) in result[1].
> 
> 11010101000101010111101111111111110010101  pattern
> 09876543210987654321098765432109876543210  count
> 00000000000000000000000011111111100000000  (reference)
> 
> The trouble is that while it seems easy to implement, getting the logic to
> come out clean in the implementation - the "pushing the rope" problem -
> doesn't comes easily.  If one does a loop looking for 8 adjacent equals or
> the 8-wide AND of 8 XNORs, the realization takes up 3 levels of logic with
> FDR primitives resulting in 2x-3x the resources and about twice the delay.
> 
> The code with the two nested for loops breaks up the 9-bit compare into two
> 4-bit and one 3-bit compare to verify all the 9 bits are equal to each other
> and to break the implementation into 2 levels of logic rather than 3+ (the +
> being from the flop's reset input taking some extra routing delay).
> 
> I'd love a cleaner approach that doesn't come off so complex and gets
> realized in the resources it "should" use.  It's tough to get it where I
> want by pushing on the rope.

My experience has been that it does not much matter how you code
combinatorial logic like this.  The tools run it through a grinder and
produce an optimal version (in its own mind).  When I want to optimize
like this, I either use a "keep" attribute on the wire, or sometimes you
can instantiate primitives.  For logic I don't think primitives work
since gates just get remapped.  

But I still don't understand your code.  Why does the outer loop range
over 64 values.   I would code two nested loops where the outer loop
ranges over the 8 outputs and the inner loop ranges over the 9 inputs
for each output.  Or just skip the inner loop and use two outputs from
two sets of four inputs feeding a 3 input function and use keeps on the
first two output arrays.  Maybe that is what you are doing, but I can't
figure out the code easily.  

I see you are incrementing the i variable by j and ranging j in the
second loop by some complex control expression.  Can't you just
increment i by 8?  

for( i=0; i<64; i=i+8 ) begin
  k = i % 8;
  for( j=0; j<4; j=j+1 ) begin
    runBitsA_[k] = runBitsA_[k] & bytePlus1[i+j];
    runBitsB_[k] = runBitsB_[k] & bytePlus1[i+j+4];
  end
  runByte_[i] = runBitsA_[i] & runBitsB_[k] & bytePlus1[i+9];
end

Put the keep on runBitsA_ and runBitsB_ and you should get your two
level structure.  



> > John_H wrote:
> > >
> > > Greetings,
> > >
> > > I need to detect runs.  I want to look at 65 bits and show when there
> are 9
> > > consecutive 1s or 0s from the byte boundaries resulting in 8 values per
> > > clock.  This should be comfortably done in two logic levels (I need
> clean
> > > logic delays).
> > >
> > > The idea is simple but the implementation is tough.  I'm working with
> > > Verilog in Synplify, targeting a Xilinx Spartan-3.  I have to resort to
> > > design violence to get the results that I believe are "best."
> > >
> > > Any thoughts on how to do this "better?"  (the following code likes
> fixed
> > > fonts)
> > >
> > > - John_H
> > > =====================================
> > > module testRun ( input             clk
> > >                , input      [64:0] bytePlus1
> > >                , output reg [ 7:0] runByte /* synthesis xc_props =
> "INIT=R"
> > > */
> > >                ); // INIT included to force register as FD primitive -
> bleah
> > >
> > > reg  [23:0] runBits; // I wanted the syn_keep on this combinatorial
> "reg"
> > > wire [23:0] runBits_ /* synthesis syn_keep = 1 */ = runBits;  // - bleah
> > > reg  [ 7:0] runByte_;
> > > integer i,j,k;
> > >
> > > always @(*)
> > > begin
> > >   runBits  = -24'h1;
> > >   runByte_ = -8'h1;
> > >   k = 0;                                   // overlapping  aaa  aaaa
> > >   for( i=0; i<64; i=i+j )                  // consecutive    aaaa
> > >   begin                                    // bit regions  876543210
> > >     for( j=0; (i%8+j<8) && (j<3); j=j+1 )
> > >       runBits[k] = runBits[k] & (bytePlus1[i+j]==bytePlus1[i+j+1]);
> > >     runByte_[i/8] = runByte_[i/8] & runBits_[k];
> > >     k = k + 1;
> > >   end
> > > end
> > > always @(posedge clk)  runByte = runByte_;
> > >
> > > endmodule

-- 

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: 61303
Subject: Re: USB Core (Japanese Version)
From: "SneakerNet" <nospam@nospam.org>
Date: Thu, 2 Oct 2003 09:18:56 +1200
Links: << >>  << T >>  << A >>
Hi Colin
Haha it's ok. I had a similar problem with a HP scanner on a HP computer.
Once the driver was installed, if the user unplugge it and plugged it in a
diff usb slot, the whole driver process had to be carried out all over
again. Pain in the ass.

I deided to dedicate the usb port to scanner only ;o)
oh well
thanks for the direction. I'll keep working on it. Hopefully along the way
someone can help me out
Thanks again


"Colin Jackson" <jacksoncolin@fake_yahoo.com> wrote in message
news:WpadnWkAEbR_kuaiXTWJkw@comcast.com...
>>>>
>>>>  Big quote deleted by Archive Owner
>>>>




Article: 61304
Subject: Re: Any word on the V2Pro-X?
From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com>
Date: Wed, 01 Oct 2003 23:24:13 +0200
Links: << >>  << T >>  << A >>
Nicholas C. Weaver wrote:
> There used to be some preliminary information on the V2Pro-X (10-Gb
> transceivers) on the Xilinx website.  Anyone know what happened to
> those pages/where they dissapeared to?
> 
> Also, does anyone else notice that the Xilinx website seems very laggy
> about initiating connections?
> 
> And has anyone started playing with the RocketPhy or other 10-Gig
> transceivers, especially for 10-GigE?

For V2Pro-X, RocketPhy will be on silicium.

Laurent
--> www.amontec.com


Article: 61305
Subject: Re: Any chance to buy Cyclone?
From: mikroprog@yahoo.com (Vakaras)
Date: 1 Oct 2003 14:38:33 -0700
Links: << >>  << T >>  << A >>
> I got mine from EBV (www.ebv.com).

Thanks for this source. But unfortunately, EBV is not in my country
(Lithuania) too.. :(

/Vakaras/

Article: 61306
Subject: Re: Digesting runs of ones or zeros "well"
From: "Vinh Pham" <a@a.a>
Date: Wed, 01 Oct 2003 22:02:44 GMT
Links: << >>  << T >>  << A >>
John

Pushing rope is a good analogy.  Jan Gray, yeah?

When writing HDL, on one extreme you can write your code to explicity tell
the synthesizer how to structure your logic.  You'd instantiate logic
primitives and wire them all up.  You're basically doing all the work for
the synthesizer.  The benefit is total control.  The problem is a lot of
code to write, which means increase chances of human error and a lot of
rewriting when you make changes to your design.

On the other extreme, you have code that's structureless.  You imply no
logic or wiring inside.  It's purely a black box and leaves it up to the
synthesizer to figure things out.  The benefits are more compact code and
"ease" of modification (if your algorithm isn't too convoluted).  The
problem of course is the synthesizer usually doesn't do exactly what you
want.  Much like a 2 year old coming up to you with a smile full of pride
saying, "I went potty!" only to realize they did it on the floor.

So when the synthesizer isn't smart enough, you need to help it out by
putting a little more structure into your code.  Basically you're giving the
synthesizer hints on what you want.  Also hardware engineers tend to better
understand algorithms that have a bit of hardware structure to them.  We
once had a math major write VHDL, and the comment from one engineer was,
"Man, his code looks like C."  :_D

Unfortunately I don't use Verilog, but hopefully some psuedo code will be
enough to give you an idea of what I'm thinking.

I noticed your code was bit based.  Since you only are checking on byte
boundaries, it can help to write your code byte based.  Good luck with this
psuedo code (you should see my C).

data[64:0]  -- 65-bit input data signal
eight_0s_consec_flag[7:0] -- intermediate signals
eight_1s_consec_flag[7:0] -- intermediate signals
ninth_bit[7:0] -- intermediate signals
consec_detect_flag[7:0] -- 8-bit output signal

for byte = 0...7

    lsb = byte*8
    msb = byte*8+7

    if data[msb:lsb] = "00000000" then
        eight_0s_consec_flag[byte] = '1'
    else
        eight_0s_consec_flag[byte] = '0'
    end if

    if data[msb:lsb] = "111111111" then
        eight_1s_consec_flag[byte] = '1'
    else
        eight_1s_consec_flag[byte] = '0'
    end if

    ninth_bit[byte] = data[msb+1]

    if ninth_bit[byte] = '1' then
        consec_detect_flag[byte] = eight_1s_consec_flag
    else
        consec_detect_flag[byte] = eight_0s_consec_flag
    end if;

end loop


Well hopefully that's correct, and makes sense.  Let me know if you have any
questions or see any problems.


Regards,
Vinh



Article: 61307
Subject: Re: Frustrations with Marketing
From: Jan Panteltje <pNaOnStPeAlMtje@yahoo.com>
Date: Wed, 01 Oct 2003 22:10:46 GMT
Links: << >>  << T >>  << A >>
On a sunny day (Wed, 1 Oct 2003 08:05:01 -0400) it happened "Ron Huizen"
<rhuizen@bittware.com> wrote in <vnlgp85kcc6f78@corp.supernews.com>:

>Yes, but there are a few reasons for that (Xerox machine, not paper bag):
>
>1. We could learn how to use it, but we'd rather spend our time on more
>interesting stuff (the old Farside cartoon where the kid puts his hand up in
>class and says "Excuse me, sir, but my brain is full").
I have been technician in a TV broadcast environment for many years.
You had to repair equipment you did not even have a clue how to use.
'the video editing of this machine has problems, can you have a look at it?'
(Large quadruplex 1 million dollar machines...)
I'd ask: Can you show me so I can see what is wrong?
(So I could see how they used that interface...)
Then get out the manuals and find the defective transistor or whatever component.. 

But the expression on the face of those people if they figured you did not even know
how to use it...
hehe
And it always needed fixing immediatly too.
I always told them, 'I don't how to use it, you show me, then I will fix it.'
Only engineers understand that perhaps..
JP

Article: 61308
Subject: Re: USB Core (Japanese Version)
From: Jan Panteltje <pNaOnStPeAlMtje@yahoo.com>
Date: Wed, 01 Oct 2003 22:10:46 GMT
Links: << >>  << T >>  << A >>
On a sunny day (Wed, 1 Oct 2003 11:32:49 +1200) it happened "SneakerNet"
<nospam@nospam.org> wrote in <Cooeb.164131$JA5.4047622@news.xtra.co.nz>:

>
>"Colin Jackson" <jacksoncolin@fake_yahoo.com> wrote in message
>news:R06dneVoUbFL4uSiU-KYhA@comcast.com...
>>
>> "SneakerNet" <nospam@nospam.org> wrote in message
>> news:HI2eb.162954$JA5.4020112@news.xtra.co.nz...
>> > Hi Guys
>> >
>> > I know someone of you have helped me in my replies regarding USB
>> > Implementation before.
>> > I downloaded the USB Core (referred to as the Japanese version). The
>> beauty
>> > of this core is that no hardware is required. Just need to connect the
>D+
>> > and D- of the USB cable to pins of the FPGA.
>> >
>> > The facts..
>> > I changed the code around so that it has a altera pll running and
>> producing
>> > a 48Mhz clock for the usb.
>> > I connected some of the output pins to the leds to see what's going on.
>> > I uploaded the program and connected the usb cable to the pins and to
>the
>> PC
>> > (and added some circuitry like 3 extra resistors).
>> > and Behold, the program on the FPGA actually does something. I know it's
>> > working because when i connect/disconnect the usb calbe, the lights on
>> fpga
>> > change their pattern for a small amount of time..
>> >
>> > However I can't test the actual communication. The reason being, when I
>> > connect the usb cable to the PC, the PC recognizes a new USB device is
>> > attached (as win2k shows in the system try all the usb devices.),
>however
>> is
>> > unrcognised as VALID drivers are not installed.
>> >
>> > What I need is some help/tips on how i can install a driver for this
>> > product. The fpga has been configured so that it recognises a vendor ID
>of
>> > C91 and product ID of 2001. I have tried playing around with .inf files,
>> but
>> > win2k rejects all of them and uses the standard c:\winnt\inf\usb.inf
>file.
>> >
>> > I'm so close to getting this thing to work.
>> >
>> > Pls help/advice
>> > Regards
>> >
>> >
>> Try http://www.jungo.com/products.html#driver_tools
>> They have a demo version that looks really easy to make drivers.
>> I played with it but not on a real device.
>> Let us know if it works!
>>
>> -Colin
>>
>>
>
>Colin
>Have u got a crack for this program? Since I installed it about a month
>back, then uninstalled it, and now it won't work.. Sigh
>
>Cheers
>
>
>
Hey, it is the first time I have seen someone ask 3000$ for a Linux license...
I pressed 'BUY'....
Or did I read that wrong?
In Linux you can just modifiy some USB webcam driver I am sure... 
In fact I had a go some time ago to interface unknown USB webcam, but
finally found an existing driver, so left it.
Just wondering.
JP

Article: 61309
Subject: Re: USB Core (Japanese Version)
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Wed, 1 Oct 2003 22:11:19 +0000 (UTC)
Links: << >>  << T >>  << A >>
SneakerNet <nospam@nospam.org> wrote:
: Hi Colin
: Haha it's ok. I had a similar problem with a HP scanner on a HP computer.
: Once the driver was installed, if the user unplugge it and plugged it in a
: diff usb slot, the whole driver process had to be carried out all over
: again. Pain in the ass.

: I deided to dedicate the usb port to scanner only ;o)
: oh well
: thanks for the direction. I'll keep working on it. Hopefully along the way
: someone can help me out
: Thanks again


: "Colin Jackson" <jacksoncolin@fake_yahoo.com> wrote in message
: news:WpadnWkAEbR_kuaiXTWJkw@comcast.com...
:> I had tried the program on my computer at work which I don't have anymore.

<about 120 lines of full quote deleted>

SneakerNet,

please don't fullquote.

Thanks

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 61310
Subject: Re: Limitations of Xilinx coregen or limitations with using Xilinx primitives in synthesis.
From: "Vinh Pham" <a@a.a>
Date: Wed, 01 Oct 2003 22:21:23 GMT
Links: << >>  << T >>  << A >>
Coregen lets me use the same name for a component I've modified.  It just
asks if I'm sure I want to overwrite my old files.

But I use Coregen manually (i.e. I invoke it myself instead of using Project
Manager).  Are you using Project Manager?  If so perhaps by default it
prevents you from overwriting an old component file because it doesn't know
if another project is using that same file but expecting the old bus width,
for example.

That's just a wild guess.  Good luck.


Regards,
Vinh



Article: 61311
Subject: Re: Any chance to buy Cyclone?
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 02 Oct 2003 00:30:05 +0200
Links: << >>  << T >>  << A >>
mikroprog@yahoo.com (Vakaras) writes:

> > I got mine from EBV (www.ebv.com).
> 
> Thanks for this source. But unfortunately, EBV is not in my country
> (Lithuania) too.. :(

But wont they ship to you from Finland or Moscow?

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 61312
Subject: Re: Any word on the V2Pro-X?
From: "Vinh Pham" <a@a.a>
Date: Wed, 01 Oct 2003 22:33:20 GMT
Links: << >>  << T >>  << A >>
Nicholas ,

> There used to be some preliminary information on the V2Pro-X (10-Gb
> transceivers) on the Xilinx website.  Anyone know what happened to
> those pages/where they dissapeared to?

Since it's not a finalized product, maybe they took down the pages to make
changes.  If you're fine with working with potentially out of date
information, you can use Google and enter:

"pro x site:xilinx.com"

The pages are still there, I guess they just got rid of the links.  If they
get rid of the pages, you might have luck with picking the "cached" option
that goes along with each result Google prints out.

> Also, does anyone else notice that the Xilinx website seems very laggy
> about initiating connections?

Yeah I've had some pretty bad lag from time to time.  Perhaps someone is
intiating DOS attacks on their site.  Just kidding off course :_)  I'm sure
there's some poor webmaster pulling his/her hair out, figuring out what's
going on.


Regards,
Vinh



Article: 61313
Subject: Re: Frustrations with Marketing
From: "Vinh Pham" <a@a.a>
Date: Wed, 01 Oct 2003 22:39:09 GMT
Links: << >>  << T >>  << A >>
> I always told them, 'I don't how to use it, you show me, then I will fix
it.'
> Only engineers understand that perhaps..

LOL, "I just write the code, it doesn't mean I know how to use it."

That started to happen a lot as our product got more complex.  After a
while, I couldn't reproduce bugs by myself, I had to get help.



Article: 61314
Subject: Re: USB Core (Japanese Version)
From: "SneakerNet" <nospam@nospam.org>
Date: Thu, 2 Oct 2003 10:41:55 +1200
Links: << >>  << T >>  << A >>

"Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message
news:blfje7$rh8$1@news.tu-darmstadt.de...
> SneakerNet <nospam@nospam.org> wrote:
> : Hi Colin
> : Haha it's ok. I had a similar problem with a HP scanner on a HP
computer.
> : Once the driver was installed, if the user unplugge it and plugged it in
a
> : diff usb slot, the whole driver process had to be carried out all over
> : again. Pain in the ass.
>
> : I deided to dedicate the usb port to scanner only ;o)
> : oh well
> : thanks for the direction. I'll keep working on it. Hopefully along the
way
> : someone can help me out
> : Thanks again
>
>
> : "Colin Jackson" <jacksoncolin@fake_yahoo.com> wrote in message
> : news:WpadnWkAEbR_kuaiXTWJkw@comcast.com...
> :> I had tried the program on my computer at work which I don't have
anymore.
>
> <about 120 lines of full quote deleted>
>
> SneakerNet,
>
> please don't fullquote.
>
> Thanks
>
> --
> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

??
I have no idea what you are on about Uwe. Sorry..



Article: 61315
Subject: Re: USB Core (Japanese Version)
From: "Ulf Samuelsson" <ulf@atmel.nospam.com>
Date: Thu, 2 Oct 2003 00:55:51 +0200
Links: << >>  << T >>  << A >>

"SneakerNet" <nospam@nospam.org> skrev i meddelandet
news:cFpeb.164194$JA5.4050546@news.xtra.co.nz...
> Hi Again Colin
> Don't worry about the crack, I found it.
> Did u have this problem,
> WinDriver finds the device, and I assign the Vendor ID and the Product ID
> and windriver generates a inf file, and then tries to install the driver.
> However at this stage, win2k takes over and reports that
> c:\winnt\inf\usb.inf is a closer match and windows ends up using that
driver
> instead of my custom generated driver and I can't do anything about it.
>
> Cheers.


Maybe remove usb.inf temporarily from the inf directory, install, and then
move usb.inf back....
That is what I have done in similar situations.
Maybe you indicate that it is a HID device with your Product Id....

-- 
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB



Article: 61316
Subject: Re: ISE WebPack 6.1 Impact problem
From: Marc Guardiani <marc@guardiani.com>
Date: Wed, 01 Oct 2003 22:58:46 GMT
Links: << >>  << T >>  << A >>
Could be a typing error, I already found one. In ECS 6.1i (the schematic 
editor), if you put the USELOWSKEWLINES=TRUE attribute on a signal, the 
resulting .vhf file contains a spelling error that keeps the design from 
synthesizing (SIGNAL is spelled "SIGANL").

As far as Impact goes, I can't even get it to run.

Javier Fernández Baldomero wrote:
> 
> Marc Guardiani escribió:
> 
>>Javier,
>>
>>Do you use NT? Xilinx dropped NT support with ISE version 5.1i, but it
> 
> 
> Sorry I forgot to mention: we use Windows XP
> 
> 
> 
>>still ran. With 6.1i Impact won't even start up. Neither will the Core
>>Generator. YMMV.
>>
>>Marc
>>
> 
> 
> Thanks for the info. Our iMPACT does start, and from the log
> messages, it seems it confuses LPT1=0378 with LPT1=0B78.
> I have tried to look for "edit options" to change that,
> but can't find anything either in the menus or in the PDF handbook.
> In any case... why does 6.1 uses 0B78 instead of the previous 0378?
> 
> Confused... :-)
> 
> -javier


Article: 61317
Subject: Re: USB Core (Japanese Version)
From: "Ulf Samuelsson" <ulf@atmel.nospam.com>
Date: Thu, 2 Oct 2003 00:59:31 +0200
Links: << >>  << T >>  << A >>
"SneakerNet" <nospam@nospam.org> skrev i meddelandet
news:2xHeb.165022$JA5.4073457@news.xtra.co.nz...
> Hi Colin
> Haha it's ok. I had a similar problem with a HP scanner on a HP computer.
> Once the driver was installed, if the user unplugge it and plugged it in a
> diff usb slot, the whole driver process had to be carried out all over
> again. Pain in the ass.
>
> I deided to dedicate the usb port to scanner only ;o)
> oh well
> thanks for the direction. I'll keep working on it. Hopefully along the way
> someone can help me out
> Thanks again
>
>


This may or may not be a USB problem, or it might be a device problem
I know for sure that USB<->Serials may install as a different COM port if
you move it to another place in the hub.
Those are cheap devices where the manufactruere did not buy a serial EEPROM
to store a unique
product Id, in which case the device will not change COM port number when it
is moved.
-- 
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB




Article: 61318
Subject: Re: USB Core (Japanese Version)
From: "Ulf Samuelsson" <ulf@atmel.nospam.com>
Date: Thu, 2 Oct 2003 01:02:38 +0200
Links: << >>  << T >>  << A >>
> > please don't fullquote.
> > Thanks
> > Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

> ??
> I have no idea what you are on about Uwe. Sorry..
>

He is complaining about the fact that you do not remove all the
unneccessary/old parts of the reply like headers.
This post was a reply to yours, but it is much shorter, since I cleaned it
up.
There are guidelines on how to "behave" in newsgroups, and if you adhere,
you wont see the "policing" from others.


-- 
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB



Article: 61319
Subject: Re: Ask the hotline, you may be surprised and pleased
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 02 Oct 2003 11:03:59 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
<snip>
> No ignorance here at all, the effect that is actually seen (with tests at >
> 4.5V) result in increased leakage, but no functional failure of the IOB (it
> still works, but does not meet the < 10uA IO pin spec).
> 
> This is the subject of research and PhD thesis material among the
> technology communities.

 Interesting. 
 So this is stress-time effect, that causes a degrade in leakage spec ?

 What time/uA orders are we talking about here ?

 Does this never cause a more drastic point failure ?

 Any idea why Lattice quote a MAX of 64 pins at IO MAX voltage stress
levels ?  (I'm bemused at how the 65th pin knows the state of the other
64 :)

- jg

Article: 61320
Subject: Re: Counting ones
From: "Ulf Samuelsson" <ulf@atmel.nospam.com>
Date: Thu, 2 Oct 2003 01:11:18 +0200
Links: << >>  << T >>  << A >>
> > There is an excellent example of a combinational ones counter in the
course
> > notes on our Comprehensive VHDL course ;-) Check out my employers
website
> > for more details...
> >
> > Our example does use a for loop - I'm not sure why you feel a for-loop
> > cannot be used for combinational logic, unless you are putting wait
> > statements inside the for loop, and in that case it probably won't
> > synthesise (unless you have a behavoral compiler). To work out what a
loop
> > will do, simply replicate the contents of the loop once for each
iteration
> > of the loop, replacing the loop parameter with a constant. eg
>


The for loop method generates n-1 adders for n bits.
Probably quite slow as well.
The synthesizers might of course be smarter than I think...

-- 
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB



Article: 61321
Subject: Re: Automatic I/O voltage sensing (as XILINX ParallelCable IV)
From: "Stephan Buchholz" <sbuchhol@sprynet.com>
Date: Wed, 01 Oct 2003 23:42:07 GMT
Links: << >>  << T >>  << A >>
Laurent

    The Philps Semiconductor GTL2010 10-bit bi-directional low voltage
translator might help
Steve Buchholz
"Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com> wrote
in message news:3f7ac650$1@news.vsnet.ch...
> Hi all,
>
> Sorry to ask about analog question, but it 's relative to FPGA too.
>
> Do you know a schematic to do 'Automatic I/O voltage sensing' as XILINX
> does with the ParallelCable IV.
>
> I am designing a new JTAG interface (USB), and I want to be able to
> drive correctly the target JTAG signals (3.3V, 2.5V, 1.8V, 1.2V).
>
> Are there any lvttl level shifter device to do this work?
>
> Thanks for your advice.
>
> Laurent Gauch
> www.amontec.com
>



Article: 61322
Subject: Re: Ask the hotline, you may be surprised and pleased
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Wed, 01 Oct 2003 17:02:33 -0700
Links: << >>  << T >>  << A >>
Jim,

I will try to add to our knowledge below,

Austin

Jim Granville wrote:

> Austin Lesea wrote:
> >
> <snip>
> > No ignorance here at all, the effect that is actually seen (with tests at >
> > 4.5V) result in increased leakage, but no functional failure of the IOB (it
> > still works, but does not meet the < 10uA IO pin spec).
> >
> > This is the subject of research and PhD thesis material among the
> > technology communities.
>
>  Interesting.
>  So this is stress-time effect, that causes a degrade in leakage spec ?

Yes.  It is interesting because it does not follow the "accepted" failure
mechanisms, and is being studied by many (not at all new, just new to us because
it is the first time we have used this particular .25u pmos transistor for 3.3v
IO).

>
>  What time/uA orders are we talking about here ?

In one set of early tests before they improved the process, we saw 6uA in 10
weeks with a peak voltage stress of ~4.5v.  The leakage started out in the nA
range.  Traditional gate breakdown is defined as a 100x increase in leakage, but
it is then usually followed by a complete gate breakdown.  The leakage stopped
increasing.

>
>
>  Does this never cause a more drastic point failure ?

Not in the testing we did.  That is what we found strange, and led to a reading
of some of the more obscure papers on voltage stresses in the public literature.

"Defect generation and breakdown of ultra-thin silicon dioxide induced by
substrate hot-hole injection" by Eric M Vogel, Journal of Appplied Physics, V90,
N5, 1 September, 2001....as one example of bedtime reading.  We concluded that
the mechanism described by this paper was NOT what we saw, but then, it wasn't
any of the other ones folks know about, either.

Baking the device at a high temperature also did not make the device recover (as
would be expected from hot electron damage, for example).

>
>
>  Any idea why Lattice quote a MAX of 64 pins at IO MAX voltage stress
> levels ?  (I'm bemused at how the 65th pin knows the state of the other
> 64 :)

There is no agreement on how to spec this:  the area under stress (number of IOs)
and temperature figure prominently in the models, but had virtually no effect in
the tests we conducted.  Now, of course, we have to stress it enough to see an
effect  (in our limited lifetimes), and one can say with some confidence that
such a stress is not going to lead to the actual failure mechanism, but may be
causing a new, and artifical failure mechanism.  Thus, we combine the older
techniques and models, with the latest data and guesses, and error on the side of
extreme caution so that we can state that if you do not exceed the abs max
numbers, the part lives it regular life.

So, 64 IOs may be just under the 15 or 20 year life projection model limit, and
65 IOs may be just over the limit in the model.  Our experience was that the
number of IOs under stress did not make a measurable difference.  I agree that it
is pretty hard to imagine that having a next door neighbor with a hot plate
increases your chances of burning down your house, but it does make sense that
overall, the more devices you have under stress, the sooner one would expect a
failure........even if we did not see that in our testing.

The most recent tests did allow us to relax the bank requirements for V2P, so now
all banks may operate at 3.3V, and it will not affect the lifetime nor the
reliability of the part (as opposed to the original banking restrictions).

It could be that they have not seen the same results in their testing from their
fab?  Turns out this is very tricky stuff, and implants, layout, etc affects the
performance of these devices under these extrememly high field stress
conditions.  There is a magic recipe that one finds, and then sticks with it
(just like any other IC process).




Article: 61323
Subject: Re: Xilinx
From: Ray Andraka <ray@andraka.com>
Date: Wed, 01 Oct 2003 20:13:27 -0400
Links: << >>  << T >>  << A >>
Yes, in theory that is correct.  I've had problems with the mapper and/or
floorplanner accepting F5 muxes packed this way in the past.  Usually however, I
don't use them.  Still, in most cases the Virtex2 architecture is a clean hands
down winner.

Neil Franklin wrote:

> Peter Alfke <peter@xilinx.com> writes:
> > Ray Andraka wrote:
> > >
> > > True, but those muxes are virtually useless for data path because the bit
> > > pitch doesn't match the bit pitch of the arithmetic.
>
> No problem at all. 2 LUTs with F5 enabled may by double the vertical
> size of an data path bit. But as one is not using the carry chain
> when using F5 (the Lut/Fn/carry MUX ensures this) it is no problem
> to "zigzag" data path bits. Put each pair of data path bits into 2
> vertical stripes of slices, very simple:
>
>   .  . .  .
>   .  . .  .
>   3  2 3  3        0..3.. = where bit gets processed
>   2  2>3> 2        >      = enabled F5 MUX
>   1  0 1  1
>   0  0>1> 0
>
> And with F5 being "vertical" it can be used (combining 2 LUTS to an 8
> input AND or OR) in the corresponding control logic of an 1 slice wide
> data path segment, without having to sacrifice an 2nd slice or use up
> logic of the next (or even worse previous) segments control logic space.
>
> Now F6 using 2 horizontally neighboring slices (which is what you
> suggest for F5), that messes this scheme up.
>
> > So, the 12.5% stand for "virtually useless" multiplexers, useful RAM
> > capability, and the super-useful SRL16 shift-register capability that
> > enhances Ray's formidable talents even more.  :-)
>
> Or the 12.5% stand for "LUT-saving and next to no delay" 2nd level in
> multiplexers (halves levels, 2/3s LUT usage), usefull RAM (inclusive
> F5-using 32bit, same trick!) and "I don't reconfigure LUTs" useless
> SRL16s. :-)
>
> Everyone sees their 1/8th of an LUT in different extra features.
>
> --
> Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
> Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Blacksmith
> - hardware runs the world, software controls the hardware
>   code generates the software, have you coded today?

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 61324
Subject: Re: Xilinx
From: Ray Andraka <ray@andraka.com>
Date: Wed, 01 Oct 2003 20:16:21 -0400
Links: << >>  << T >>  << A >>
Perhaps I missed saying it here.  I have stated many times in the past that the best
fit for a particular target is probably going to map pretty poorly to another
architecture.  My internal IP is for the most part built up out of primitives to even
get placement optimal.

Austin Lesea wrote:

> Ray,
>
> You failed to take into account the many IP cores that are available that are
> optimized for a particular architecture.
>
> Examine the vendor's own free IP, for fee IP, and the community around that vendor
> for the number of independent or partner vendors of IP.
>
> You don't always have to suddenly create the most complex and highest performing
> logic out of thin air (as that is a tough job for the best of us).
>
> And don't forget the many talented consultants that create product specific IP that
> beats the performance of the best cores that folks may offer.
>
> But it is true that the more specialized and targeted you get, the less likely it
> will port conveniently to any other device, other than the manufacturer that it was
> originally on (and not even then if it is a new architecture).
>
> Austin
>
> Ray Andraka wrote:
>
> > The equation for utilization is very complex.  For arithmetic data path however,
> > I do find
> > that the Xilinx structure permits a higher density measured in LUTs occupied
> > when comparing designs
> > for the same algorithm but optimized for the particular device.  This is due
> > partially
> > to the fact that the Altera carry chain breaks the LUTs into a pair of 3 LUTs so
> > your arithmetic is
> > 2 input arithmetic where Xilinx's is 4 input arithmetic.  Granted, Altera has
> > greatly improved the situation
> > by adding dedicated gating for doing an adder-subtracter in one level, as well
> > as logic to permit an
> > accumulator with load, which are probably the most common use of more than two
> > input arithmetic.
> > To  be fair, the average user is not going to fully use the Xilinx capability
> > because the synthesis tools
> > do not do a great job at inferring more complex structures such as an add/mux or
> > mux/add etc.  In order
> > to use that, you more or less need to do some very careful coding.  Same is true
> > for taking advantage of
> > the SRL16s.
> >
> > The fact of the matter is, I think both vendor's numbers are slanted.  Unless
> > you do the design with the
> > specific architecture in mind, you are not going to get optimum utilization of
> > that array.  A design that is
> > optimized for one array is going to generally be a poor fit for another.
> > Presumably, both vendors have
> > taken a design or designs that were targetted to their parts, and then ported
> > those designs to the competition
> > to come up with these numbers.  In both cases, naturally, their device is going
> > to show superior results
> > simply because the design database they are drawing upon was optimized to their
> > parts.
> >
> > As I've stated many times before, the comparison metric should be a raw count of
> > the number of 4 LUT/flip-flop
> > pairs plus a list of additional features with perhaps an equivalent utilization
> > of that feature if it were not available.
> > That way, the designer can make an informed decision based on what features he
> > thinks he will use.  In cases
> > where he doesn't know, the most accurate comparision would be to ignore the
> > effect of special features altogether,
> > then accept the gains he gets by using them as gravy.
> >
> > Paul Leventis wrote:
> >
> > > I might as well give the Altera view -- 12.5% is a gross overstatement of
> > > the relative abilities of a Virtex LC vs. a Stratix LE.  Our data suggests
> > > that nearly the reverse is true (about a 9% advantage for Stratix).  Please
> > > see the following whitepaper for our reasoning and data.  As you can see
> > > from Figure 1, your mileage will vary -- depending on your design, you could
> > > see vast density advantages from one architecture or the other.
> > >
> > > http://www.altera.com/literature/wp/wp_stx_logic_efficiency.pdf
> > >
> > > If we wanted to, we could start counting our M512 blocks as logic, as they
> > > can be used for shift-registers, small memories, and soft multipliers, but
> > > we don't bother.
> > >
> > > Bottom line -- you really need to compile *your* design to both Stratix and
> > > Virtex (or whatever families you are interested in) before you will really
> > > know what the story is density.  Averages don't matter much to you if yours
> > > is that design that gets hosed in one architecture or the other!
> > >
> > > Regards,
> > >
> > > Paul Leventis
> > > Altera Corp.
> > >
> > > "Peter Alfke" <peter@xilinx.com> wrote in message
> > > news:3F69D605.63B715DB@xilinx.com...
> > > > Rick, I will not defend the +12,5%, but I can explain it:
> > > >
> > > > It is the price we all pay for the intense and sometimes ruthless
> > > > competition in this market. Without a bloodthirsty competitor "in our
> > > > rear-view mirror", we would be gentlemanlike and give you conservative
> > > > numbers. But the way it is, our marketing folks think it would throw
> > > > away some really (really!) powerful features if they are not somehow
> > > > represented in the numbers. Each Xilinx Logic Cell does more than an
> > > > Altera LE, there can be no doubt about that.
> > > >
> > > > This is not an excuse (personally I agree with you), but an explanation.
> > > >
> > > > Peter Alfke
> > > > ==========================
> > > >
> > > > rickman wrote:
> > > >  I care about the fact that I have to ignore a
> > > > > column of data in a data sheet as marketing hype and use a calculator to
> > > > > get the *real* numbers.  Clearly the marketing people don't think we can
> > > > > add and multiply ourselves.
> > > > >
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> >  "They that give up essential liberty to obtain a little
> >   temporary safety deserve neither liberty nor safety."
> >                                           -Benjamin Franklin, 1759

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759





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