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 74025

Article: 74025
Subject: Re: JOP on Spartan-3 Starter Kit
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Sat, 02 Oct 2004 18:14:33 GMT
Links: << >>  << T >>  << A >>
Hi Paul,

> > Cyclone EP1C6Q240C6:
> >     fmax: 98 MHz, 2066 LC/Es (34% out of 5980)
> > Spartan-3 XC3S200-5
> >     fmax: 82 MHz, 2015 LC/Es (52% out of 3840)
>
> By turning on Minimize Area w/Chains under Fitter Settings/More
> Settings.../Auto Packed Registers - Cyclone you can cut the LE count to
1868
> LEs (from 2066).  Quartus doesn't try too hard to put registers & LUTs
> together unless it runs out of room (or you tell it to with this
setting).
> In my compile, this didn't hurt Fmax (Fmax was 99 Mhz).  On average,
> aggressively packing can slightly hurt performance and cause an
increase in
> wiring.

Thank's for the hint. It's nice to get it smaller AND faster.

> too.  To automatically try-out the area optimization tricks in Quartus,
run
> the Design Space Explorer tool, and select "Area Optimization" mode
under
> the Advanced settings.  It'll take a while, but this will find you the
best
> settings (for area) for your design.

I could not find the 'Design Space Explorer' in Quartus. If you mean the
Resource/Timeing Opt. Adviser under 'Tools' than I'm in bad luck. This
function is not available with the web edition of Quartus.

> In this particular case, your critical path appears to stretch from a
RAM to
> a RAM (configured as a ROM) with little logic in-between.  Logic +
> routing-rich paths tend to accentuate the speed differences between the
two
> devices, while RAM-heavy paths show a smaller advantage.
>

In this case I think it's a logic/routing-rich path. From the memory data
out (unregistered) there is a 8-bit 'lookup table' and an adder,
resulting in 6 LCs till the next register (in this case the address
register of another RAM). Perhaps the ALM structure from the Stratix II
would help for this function, but the Stratix devices are too big and too
expensive ;-)
Or a clock-free ROM as it was available in the ACEX parts. In fact,
Quartus implements this structure in a block RAM when targeting the ACEX
device (I still have several ACEX boards laying around and collectiong
dust ;-).

Martin
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/




Article: 74026
Subject: Re: Open-Source MicroBlaze IP-Core working in FPGA :)
From: news@sulimma.de (Kolja Sulimma)
Date: 2 Oct 2004 11:25:14 -0700
Links: << >>  << T >>  << A >>
"Antti Lukats" <antti@case2000.com> wrote in message news:<cjlt48$uvo$01$1@news.t-online.com>...
> > Antti Lukats wrote:
> > I could be wrong, but I thought open source cores that run uCLinux were
> > already available for FPGAs.  The only difference is that this one is
> > code compatible with uBlaze.  Am I wrong about this?
> 
> Yes, if there would be similar reference platform for OR1100, but it is not
> available. LEON is real nice system, but the ref system hardly fits into
> XCV2000 !! 
LEON is an implementation that is focused on a radiaton hard operation
of an architecture (SPARC) that was designed for ASICs.
Whereas MB is an architecture that was optimized from the beginning
for a small FPGA implementation. There will never be a SPARC
implementation that will get the same performance per LUT as MB does.
AFAIK the OR1k architecture also is not optimzed for FPGA
implementation and is therefore rather large.

So I think it is great to see an open source implementation of MB.
Can you comment on how many LUTs your implementation requires? 
Also: You mention on your web site that some instructions are not
impleneted. Which instruection are these?

Kolja Sulimma

Article: 74027
Subject: Re: Open-Source MicroBlaze IP-Core working in FPGA :)
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Sat, 02 Oct 2004 18:33:14 GMT
Links: << >>  << T >>  << A >>
> LEON is an implementation that is focused on a radiaton hard operation
> of an architecture (SPARC) that was designed for ASICs.

It is designed for radiation hard per se? Isn't it just an open source
SPARC.
Do you knwo how to design for radiation hard applications, especially in
an FPGA?
Redundant structures and hoping that the synthesizer does not detect them
and optimize it away...

Martin




Article: 74028
Subject: Re: Open-Source MicroBlaze IP-Core working in FPGA :)
From: "Antti Lukats" <antti@case2000.com>
Date: Sat, 2 Oct 2004 11:36:35 -0700
Links: << >>  << T >>  << A >>
"whatisasics" <whatisasics@none.net> wrote in message
news:A5p7d.5328$nj.3186@newssvr13.news.prodigy.com...
> Antti Lukats wrote:
> > http://uclinux.openchip.org/forum/viewtopic.php?t=4
> >
> > here is proof :)
> >
> > the opensource version as available from opencores is not yet good
enough to
> > run uCLinux - well lets see if that will change,
> > I think there is a wish to have an open-souce multi-vendor FPGA softcare
> > capable to run uCLinux inside many people :)
>
> And this is what irks me...if you "need" a "free" FPGA cpu core, there
> are already several to choose from (www.opencores.org.)  One of them

I dont know what the "irks" means, but - if it really irks you then please
please:

1) goto to opencores,
2) download any of the several cores you mentioned
3) port the uCLinux reference desing for that core to the FPGA board you use
4) boot uCLinux to the shell prompt on your FPGA board

I would really like to hear your comments after you have managed 1..4 from
above!
And please post with your real name not using anon email address!

Antti
PS porting MicroBlaze-uCLinux reference design (mbvanilla) to new FPGA board
takes usually less than 5 hours



Article: 74029
Subject: Re: Open-Source MicroBlaze IP-Core working in FPGA :)
From: "Antti Lukats" <antti@case2000.com>
Date: Sat, 2 Oct 2004 11:45:39 -0700
Links: << >>  << T >>  << A >>
"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:415E3A81.329A38AB@yahoo.com...
> Antti Lukats wrote:
> >
> > http://uclinux.openchip.org/forum/viewtopic.php?t=4
> >
> > here is proof :)
> >
> > the opensource version as available from opencores is not yet good
enough to
> > run uCLinux - well lets see if that will change,
> > I think there is a wish to have an open-souce multi-vendor FPGA softcare
> > capable to run uCLinux inside many people :)
>
> I could be wrong, but I thought open source cores that run uCLinux were
> already available for FPGAs.  The only difference is that this one is
> code compatible with uBlaze.  Am I wrong about this?

Hi Rick,

Yes, OR1K is uCLinux capable, I guess also M68K and LEON and maybe
Aquarius/SH-3 could be.

The thing is that
MicroBlaze-uCLinux reference design (mbvanilla) requires
1) any FPGA starting from XC2S200
2) 4MB SRAM/SDRAM/DDR
3) interrupt/timer/uart
4) porting of the mbvanilla to new board can be done withing few hours

ASFAIK there is nothing to compete with that -
OR1K reference design doesnt pass even synthesis out of box, just tried out
of curiosity.

MicroBlaze is small and minimal MicroBlaze-uCLinux is small as well,
actually there is almost no overhead to make MicroBlaze system uCLinux
reference design compatible.

Yes, if there would be similar reference platform for OR1100, but it is not
available. LEON is real nice system, but the ref system hardly fits into
XCV2000 !! M68K is not complete i think and SH3, not sure if there is
uCLinux available for it all.

So you are not wrong per se, but I dont envy you if you try to use some
existing open ip core for the uCLinux bringup.

antti





Article: 74030
Subject: Re: Capabilities of Spartan-3 Starter Kit (XC3S200).
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Sat, 02 Oct 2004 18:59:54 GMT
Links: << >>  << T >>  << A >>
> Same problem with many other CAST's processor cores
> mentioned: 80C51, TMS32025 and "Z80 Compatible Microprocessor"
> CZ80CPU, the data sheets mention only Spartan-3 XC3S400-4 and
> Spartan-IIE XC2S300E-7 and some larger Virtex-II's as Example
> Devices on which to implement them.
>
> Does this mean that XC3S200 has not enough logic
> to implement ANY of these or just that CAST Inc.
> didn't have XC3S200-device at hand, and thus
> haven't tested their designs on it?

You can find a 6809 with VGA, UART and keyboard controller running on the
Starter Kit at:
http://members.optushome.com.au/jekent/Spartan3/index.html

Martin



Article: 74031
Subject: Re: Open-Source MicroBlaze IP-Core working in FPGA :)
From: "E.S." <emu@ecubics.com>
Date: Sat, 02 Oct 2004 13:14:32 -0600
Links: << >>  << T >>  << A >>
Antti Lukats wrote:

> so as for the moment the open-MB is the smallest free-open IP-core with
> "proven" gnu toolchain support I would say, or does some better alternative
> exist ??

What happened to all this implementations of the DLX ?
There was the whole GNU chain available at one time,
and a lot of people used them for their diploma work etc...



Article: 74032
Subject: Re: Open-Source MicroBlaze IP-Core working in FPGA :)
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Sat, 02 Oct 2004 19:57:55 GMT
Links: << >>  << T >>  << A >>
> Ha, I see Martin has also already responded, for I just offered to
donate my
> acex jopcore PCB to the MB designer, so it goes for good cause at last!
>
Hi Antti,

that's really nice (and funny) how much used this single board gets ;-)
And a MB on an Altera FPGA, that's the end of the world.
BTW: I have some more ACEX boards. I could donate them (or a small fee..)
for projects that can convince me...

Martin



Article: 74033
Subject: Re: FPGA vs ASIC area
From: hpa@terminus.zytor.com (H. Peter Anvin)
Date: Sat, 2 Oct 2004 19:58:26 +0000 (UTC)
Links: << >>  << T >>  << A >>
Followup to:  <cjl7vb$tks$1@agate.berkeley.edu>
By author:    nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
In newsgroup: comp.arch.fpga
>
> In article <HZCdnbCLRZsnmsPcRVn-uw@megapath.net>,
> Hal Murray <hmurray@suespammers.org> wrote:
> >>As far as timing models go, any implication that redundancy affects quality
> >>of timing models is pure FUD.  So long as the max and min delays reflected
> >>within the software are an upper-bound and lower-bound on the delay that can
> >>be seen in any repaired part, then everything's cool.
> >
> >How much trouble do you get from customers who are right at the edge
> >and have a design that works most of the time but is flaky on chips
> >which happen to use the redundancy path on a critical signal?
> 
> That will only be a problem if the (emm, I guess the only word thats
> polite is) customers rely on empirical measurements rather than the
> static timing analysis.
> 

Right, but at that point you're screwing yourself anyway because of
PVT variations.  PVT variations are considerable in modern
high-density processes, and unless you do as extensive a set of
characterizations as the vendors themselves then you don't have much
of a hope to get a handle on that.

Thus, redundancy timings is just one of many variables that vary from
chip to chip.

	-hpa

Article: 74034
Subject: Re: FPGA vs ASIC area
From: hpa@terminus.zytor.com (H. Peter Anvin)
Date: Sat, 2 Oct 2004 20:00:33 +0000 (UTC)
Links: << >>  << T >>  << A >>
Followup to:  <415E306A.38AD3EA0@yahoo.com>
By author:    john@bluepal.net
In newsgroup: comp.arch.fpga
> 
> > FPGAs have 0% extra area for BIST (they are 100% BIST with a different
> > bitstream!).
> 
> No, by definition an FPGA has extra area for BIST, that is what makes it
> an FPGA, all the *extra* stuff in it!!!  What is the area overhead for
> an FPGA vs. an ASIC; 10X, 20X?  Even if you build an ASIC that is two
> generations back such as 150 nm vs. 90 nm, the ASIC will be smaller,
> faster and therefore cheaper.  
> 

.... after you cross some volume threshold, which these days can be
quite large.

> 
> > You must understand that the 405PPC, MGT, DCM, and other "hardened IP"
> > are just like ASICs, so we already know everything there is to know
> > about ASICs, their design, and testing.  In fact Xilinx the 3rd largest
> > 'ASIC' manufacturer in the world (behind IBM and NEC --
> > Gartner/Dataquest 'ASIC/FPGA Vendor Ranking 2003').
> > 
> > FPGA vendors may be the last stronghold of full custom ASIC design left
> > in the world. ASIC houses are mostly standard cell, or structured
> > (basically same thing), with little or no full custom.
> > 
> > Our customers tell us that if they want to play with the latest and
> > greatest technologies and designs (like 10 Gbs MGTs), they need to use
> > our FPGAs, because the ASIC cells are a generation behind.
> 
> How is using the "latest and greatest technologies" an advantage when it
> comes with a 10X area premium??? 
> 

Because it otherwise would be 20-40x premium?

	-hpa

Article: 74035
Subject: Re: JOP on Spartan-3 Starter Kit
From: Sylvain Munaut <tnt_at_246tNt_dot_com@reducespam.com>
Date: Sat, 02 Oct 2004 22:45:36 +0200
Links: << >>  << T >>  << A >>

> Set a time constraint for clk (in this case I used 12ns). However, this
> should already be done in the UCF you downloaded with the project. Then
> look at the 'text-based post-plcae & route static timing report'. At the
> end you will find:
> 
> Design statistics:
>    Minimum period:  12.848ns (Maximum frequency:  77.833MHz)

Design statistics:
   Minimum period:  17.812ns (Maximum frequency:  56.142MHz)

... Even with effort level high, it's even worse !?

Design statistics:
   Minimum period:  18.508ns (Maximum frequency:  54.031MHz)


Could you send me the exact files you compile to '246tnt' at the domaim gmail dot com ?
Maybe ise just don't like vmware ?

 
> Don't let yourself be fooled by the maximum frequency from the synthesis
> report. These are dummy numbers (in this case 96 MHz...).

Yup, I know that the warning is pretty clear

--- QUOTE ---
NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE.
      FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT
      GENERATED AFTER PLACE-and-ROUTE.
------------


> Btw, does somebody know why the lead free devices are more expensive. I
> did'n know up to now that semiconductors contain lead. I only know that
> it's part of the solder and when it's forbidden will probably increase
> production cost of PCBs.

The alloid used are more complex and uses more precious metals. (for
the solder balls and solder plating of terminal)
Sn/Pb before
and now, like Nickel/Palladium


>>Yup, I think there are 200LC used for a booth multiplier, should be
> easy to lower that with a dedicated multiplier (and also go faster i
> would guess).
> 
> Yes that would drop the LC count and I could go with the next smaller
> Spartan-3. Uups, where is the XC3S100?

;) I'm more interested on the space I win to put more devices connected to
JOP like an ethernet mac, a i2s master, lcd controller ... 

> The multiplication would be faster, but the multiplication (imul bytecode
> in the JVM) has a dynamic instruction frequency of 0.24% in typicall Java
> programs. That would not compensate for the clock frequency factor of 1.2
> between the Cyclone and the Spartan-3.

Sure, I never meant it would fill the gap !

>>Btw, is there any networking available ?
>>I have a Avnet Spartan 3 kit with an ethernet PHY on bard, that would 
> be nice to get TCP/IP ;)
> 
> Do you mean available with JOP? Yes, I have a small TCP/IP stack in Java
> with drivers for the CS8900 (Ethernet), PPP and SLIP. Even a small
> webserver is running on JOP: http://84.112.19.23 ;-)

Silly me ... I must had a windows over my browser hiding the link ;)
Since you use an external ethernet controller, I guess I would need a MAC
inside the FPGA and the appropriate drivers for it too.


Sylvain

Article: 74036
Subject: Re: JOP on Spartan-3 Starter Kit
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Sat, 02 Oct 2004 21:40:53 GMT
Links: << >>  << T >>  << A >>
> > Set a time constraint for clk (in this case I used 12ns). However,
this
> > should already be done in the UCF you downloaded with the project.
Then
> > look at the 'text-based post-plcae & route static timing report'. At
the
> > end you will find:
> >
> > Design statistics:
> >    Minimum period:  12.848ns (Maximum frequency:  77.833MHz)
>
> Design statistics:
>    Minimum period:  17.812ns (Maximum frequency:  56.142MHz)

That's strange, perhaps you have a different version (my ISE is 6.2 as
shipped with the board).

> Could you send me the exact files you compile to '246tnt' at the domaim
gmail dot com ?
> Maybe ise just don't like vmware ?
done

> Yup, I know that the warning is pretty clear
>
> --- QUOTE ---
> NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE.
>       FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT
>       GENERATED AFTER PLACE-and-ROUTE.
> ------------

Ooh, I'm sorry that I did not read it and complained about missing it in
another thread. One excuse: I usually don't read the synthesis results,
only the P&R reports. I only had to post about it since I get many of
these high fmax reports from Xilinx users (and this was an issue in the
MB thread too).

> The alloid used are more complex and uses more precious metals. (for
> the solder balls and solder plating of terminal)
> Sn/Pb before
> and now, like Nickel/Palladium

Solder balls ok, but that difference in QFP packages?

> > Do you mean available with JOP? Yes, I have a small TCP/IP stack in
Java
> > with drivers for the CS8900 (Ethernet), PPP and SLIP. Even a small
> > webserver is running on JOP: http://84.112.19.23 ;-)
>
> Silly me ... I must had a windows over my browser hiding the link ;)
> Since you use an external ethernet controller, I guess I would need a
MAC
> inside the FPGA and the appropriate drivers for it too.

But a MAC is a big and difficult beast and you still need an external
chip for the voltage levels. An external Ethernet chip is cheap, works an
d you usually get a lot of memory for buffering Ethernet frames.

Martin
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/




Article: 74037
Subject: Re: FPGA+ggiabit ethernet and protocols
From: hpa@terminus.zytor.com (H. Peter Anvin)
Date: Sat, 2 Oct 2004 21:53:35 +0000 (UTC)
Links: << >>  << T >>  << A >>
Followup to:  <cjkl5p$ieu$1@news.onet.pl>
By author:    "greg" <xgrzes@poczta.onet.pl>
In newsgroup: comp.arch.fpga
>
> Hello
> i need to implement gigabit ethernet in FPGA..
> now all is almost done (MAC in FPGA , PHY), and need to implement a simple
> protocol that will ensure proper delivery of all data from digital camera (1
> picture = 128MB). I thought about IP/UDP and own protocols with handshake
> and retransmition of lost packets, but maybe there exists something
> simpler -  already used and implemented protocols - i just need to make
> programmer's life easier at the other end of cable:)
> 

At that point you might as well use TCP... implementing TCP is not
that hard if you don't care about super-high performance across very
long distances.

See for example uIP or lwIP for small TCP/IP stacks that can be run on
a small microcontroller which can easily be synthesized in an FPGA.

If you want to use UDP or raw Ethernet packets you probably want to do
something like TFTP.

	-hpa

Article: 74038
Subject: Floating Point Powers and Logs?
From: mmdst23@pitt.edu (Mike Delaney)
Date: 2 Oct 2004 14:55:42 -0700
Links: << >>  << T >>  << A >>
Does anyone have any suggestions on how to do Logs and Powers?  
Part of the design I'm working on has "log(1 + B^d)", and we're pretty
much stuck there.
So far, the ideas being kicked around are to either use the Taylor
series (I'm not the biggest fan of this), or to try to use CORDIC.
I haven't found any free/open IP that looked like it would work, the
closest being a couple of (fixed-point) CORDIC cores from Open Cores. 
Accuracy and speed are the two main concerns, but memory is tight, so
I don't know if a lookup table is doable.  Are there any other
approximations that might work, and might be easier to implement using
floating point?  And how do the hardware implementations in some FPU's
work?

Thanks,
Mike

Article: 74039
Subject: Re: NV on-chip memory?
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Sat, 02 Oct 2004 22:11:33 GMT
Links: << >>  << T >>  << A >>
> Incorporating extra functionality in an FPGA is usually done because it
> provides some additional advantage beyond absorbing external
components.
> Let's look for a second at incorporating volatile RAM.  Altera clearly
> thinks it is worth including medium-sized SRAM blocks (hence the 512 Kb
rams
> in Stratix and Stratix II).  Designs often require one or two large
RAMs
> (off-chip) for long-term data storage, and a few medium RAMs for
buffering

I would like to add my 'wish-list' for an FPGA:
As I'm working with processors in FPGA I always need external SRAM:
costing money, PCB space, routing troubles, more pins...
I would like to see more SRAM on-chip. I don't need it as super-fast
dual-ported block RAMs. I would be happy with a single port 10-20ns
access RAM, but larger. Let's say 128KBbytes (not bit) to 1MB in
EP1C3-EP1C12 devices. When the system memory is integrated I will vote
for smaller packages: tqfp100 or even tqfp44. The idea is the same as for
microcontrollers in very small packages.
And an open documentation (not only as feature in NIOS) how to write to
the serial config Flash from within the FPGA.

my 2c
Martin
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/




Article: 74040
Subject: Re: Floating Point Powers and Logs?
From: kensmith@green.rahul.net (Ken Smith)
Date: Sat, 2 Oct 2004 22:46:01 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <eb4ab45b.0410021355.1acfcb@posting.google.com>,
Mike Delaney <mmdst23@pitt.edu> wrote:
>Does anyone have any suggestions on how to do Logs and Powers?  
>Part of the design I'm working on has "log(1 + B^d)", and we're pretty

If this is the only log and power you need to do and if either "B" or "d" 
is a constant, I'd be suggest trying to do the whole function in one go.  
I'd be very tempted to come up with a function that is sort of close and 
then use a Taylor series to fix it.

If "d" is the only variable, breaking it into 2 ranges, one for each sign 
of "d" would be a natural thing to do.

-- 
--
kensmith@rahul.net   forging knowledge


Article: 74041
Subject: Re: JOP on Spartan-3 Starter Kit
From: Sylvain Munaut <tnt_at_246tNt_dot_com@reducespam.com>
Date: Sun, 03 Oct 2004 00:58:57 +0200
Links: << >>  << T >>  << A >>

Hi Martin

 
> That's strange, perhaps you have a different version (my ISE is 6.2 as
> shipped with the board).

Thanks for the files.
I finally got to the same result. The problem was :
 - A ISE 6.2 not updated
 - A 'bad' constraint file


 
>>The alloid used are more complex and uses more precious metals. (for
>>the solder balls and solder plating of terminal)
>>Sn/Pb before
>>and now, like Nickel/Palladium
>  
> Solder balls ok, but that difference in QFP packages?

I think the pins are plated with something similar to the solder to get good solering.
That plating probably must be "updated". Reflow temp is also higher IIRC


> But a MAC is a big and difficult beast and you still need an external
> chip for the voltage levels. An external Ethernet chip is cheap, works an
> d you usually get a lot of memory for buffering Ethernet frames.

Yeah but the devboard I have already has the PHY. (Standard Avnet spartan 3 kit).
But indeed the MAC seems pretty big ;( about 2000 slice.



Sylvain

Article: 74042
Subject: Re: JOP on Spartan-3 Starter Kit
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sun, 03 Oct 2004 12:12:28 +1300
Links: << >>  << T >>  << A >>
Martin Schoeberl wrote:
> Btw, does somebody know why the lead free devices are more expensive. I
> did'n know up to now that semiconductors contain lead. I only know that
> it's part of the solder and when it's forbidden will probably increase
> production cost of PCBs.
>>The alloid used are more complex and uses more precious metals. (for
>>the solder balls and solder plating of terminal)
>>Sn/Pb before
>>and now, like Nickel/Palladium
> 
> 
> Solder balls ok, but that difference in QFP packages?

  That's an easy one : because they can.
It's a good place to do a little cost recovery/price racking,
as users will have designed in the devices, and are thus captive
by both the legistation and the layout, plus many do not
compare Pb/PbFree prices, so that's the ideal time to nudge the
prices!

-jg


Article: 74043
Subject: Hardware Log and EXP
From: mmdst23@pitt.edu (Mike Delaney)
Date: 2 Oct 2004 16:19:38 -0700
Links: << >>  << T >>  << A >>
As part of a signal processing design I'm working on (I was given
C/Matlab code, and told "go make it hardware"), I need to calcuate
log(1+B^d).  So far, I've found some information on CORDIC and 2
software approximations.  I need to do this in 32 bit floating point,
and the requirements call for "as much accuracy as you can get" as no
one has been able to figure out how much we really need yet.  There's
also a large possible difference betwen the biggest and smallest
numbers that are used in this calcuation, so using some fixed-point
system is most likly more work then it's worth.

I'm thinking that I could calcuate B^d as e^(d * LN(B)), since I'm
hoping that whatever way I end up using to find log(x) can be reversed
to find e^x as well.

The approximations I've found so far have all been software based, and
didn't seem that accurate (about 5 or so decimal digits when tested in
Matlab).  It also seems like taking the iterative/software-based
approach is the wrong way to go, and could easily lead to the log/exp
unit needing over a hundred cycles to execute.  The two approximations
I've looked at are the one from glibc and the one used in the VHDL
Real Math package.

CORDIC seemed more promising at first, but it looks like it's not
widly used for floating point.  However, I haven't been able to find
any deatails on what other methods might be better.

Can anyone suggest a better way?  Are there any approximations that
are more hardware then software based?  Or would I be better off
either using one of them, or CORDIC?

Thanks,
Mike

(Sorry if tihs is a re-post, I tried to post this an hour ago, but it
didn't show up, I might have clicked the wrong button.)

Article: 74044
Subject: best way to perform multiplies in vhdl
From: "Geoffrey Wall" <wallge@eng.fsu.edu>
Date: Sat, 2 Oct 2004 19:47:26 -0400
Links: << >>  << T >>  << A >>
i am trying to implement an image convolution filter that has negative 
values in it on a spartan IIe fpga.
So i need to perform (for instance) A*B + C*D where A,B,C,D are all signed 
numbers in the ieee std logic int range.
what is the best way to implement this? It seems that the way i am doing it 
now (using std_logic_vector) fails for negative values of the filter coeffs.
can anyone give a suggestion how to fix this (the best way to code it in 
vhdl). What is the best way to do a numerical comparison (ie. A <  B in vhdl 
(that is also synthesizeable), where A,B are signed integers)



thanks

-- 
Geoffrey Wall
Masters Student in Electrical/Computer Engineering
Florida State University, FAMU/FSU College of Engineering
wallge@eng.fsu.edu
Cell Phone:
850.339.4157

ECE Machine Intelligence Lab
http://www.eng.fsu.edu/mil
MIL Office Phone:
850.410.6145

Center for Applied Vision and Imaging Science
http://cavis.fsu.edu/
CAVIS Office Phone:
850.645.2257 



Article: 74045
Subject: Re: NV on-chip memory?
From: "superfpga" <superfpga@pacbell.net>
Date: Sun, 03 Oct 2004 00:09:03 GMT
Links: << >>  << T >>  << A >>
Martin- It makes sense that integrating ram replacing external memory would
reduce pin count etc, the confusing part of your message is realted to this
thread being NV memory oriented.  Do you want your 128KB on chip memory
truly for ram or for code storage?  Does that relate to the NV aspect of the
discussion for those low density devices you mention?
-cheers

"Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message
news:pIF7d.330373$vG5.20442@news.chello.at...
> > Incorporating extra functionality in an FPGA is usually done because it
> > provides some additional advantage beyond absorbing external
> components.
> > Let's look for a second at incorporating volatile RAM.  Altera clearly
> > thinks it is worth including medium-sized SRAM blocks (hence the 512 Kb
> rams
> > in Stratix and Stratix II).  Designs often require one or two large
> RAMs
> > (off-chip) for long-term data storage, and a few medium RAMs for
> buffering
>
> I would like to add my 'wish-list' for an FPGA:
> As I'm working with processors in FPGA I always need external SRAM:
> costing money, PCB space, routing troubles, more pins...
> I would like to see more SRAM on-chip. I don't need it as super-fast
> dual-ported block RAMs. I would be happy with a single port 10-20ns
> access RAM, but larger. Let's say 128KBbytes (not bit) to 1MB in
> EP1C3-EP1C12 devices. When the system memory is integrated I will vote
> for smaller packages: tqfp100 or even tqfp44. The idea is the same as for
> microcontrollers in very small packages.
> And an open documentation (not only as feature in NIOS) how to write to
> the serial config Flash from within the FPGA.
>
> my 2c
> Martin
> ----------------------------------------------
> JOP - a Java Processor core for FPGAs:
> http://www.jopdesign.com/
>
>
>



Article: 74046
Subject: Re: XPower help Update
From: sa1500@gmail.com (Ted)
Date: 2 Oct 2004 17:37:11 -0700
Links: << >>  << T >>  << A >>
Hi Austin,

Thanks for your reply. Makes a lot of sense.

I can understand the part on 49% of signals not toggling relating to
the situation you are talking about.

How about the setting of signals (61%). 

1) Does this mean that the information is not transferred by the vcd
file
or 

2) No activity is detected so it is not reflected (In which case there
is no difference from not toggling)

If it is 1), I guess it is the fault of settings in ModelSim, how then
can I address the problem? The format of my modelsim script is as
follows:

add wave sim:/<entity>/*
vcd file <somefile>.vcd
vcd on
vcd add /*   
force <statements>
run <sim length>

Thanks
Ed

austin <austin@xilinx.com> wrote in message news:<cjmodr$ihm4@cliff.xsj.xilinx.com>...
> Ted,
> 
> It is trying to tell you that your simulation test bench doesn't cause 
> much to happen.
> 
> The estimate is only as good as the test bench.
> 
> If all those nodes don't ever switch, then you can probably simplify 
> your design!
> 
> The number of cycles is no measure of coverage.  If I hold a register in 
> reset, and clock it a million times, I will not see much power.
> 
> So, without a test bench that exercises all of the registers, with the 
> worst case transitions, the estimate isn't very good.
> 
> But only you can tell what the register values should be, the tool can't 
> just guess.
> 
> Some people use a LFSR to generate pseudo random data as a stimulus. 
> Might, or might not be appropriate in your case.
> 
> Austin
> 
> Ted wrote:
> 
> > Hi All,
> > 
> > I am using XPower and I encounter the following warnings:
> > WARNING:Power:762 - Only 61% of the design signals have been set.
> > WARNING:Power:763 - Only 49% of the design signals toggle.
> > INFO:Power:556 - Estimate is inaccurate based on analysis of the
> > design, user
> >    input and characterization data.
> > 
> > I am using the post-place-and-route simulation model and the
> > activities of all nodes are set by ModelSim using a vcd file
> > simulating up to 10000 cycles.
> > 
> > 1) Specifically, how does it determine that the estimate is
> > inaccurate?
> > 
> > 2) Are register-rich designs tend to be like that i.e. because
> > activities at varoius nodes has not been set properly?
> > 
> > 3) WHAT CAN I DO?
> > 
> > The detailed report is below:
> > 
> > ----------------------------------------------------------------
> > Release 6.3.01i - XPower SoftwareVersion:G.36
> > Copyright (c) 1995-2004 Xilinx, Inc.  All rights reserved.
> > Design:       stream
> > Preferences:  stream.pcf
> > VCD File:     stream.vcd
> > Part:         2v1000ff896-6
> > Data version: ADVANCED,v1.01,07-31-02
> > 
> > Power summary:                        I(mA)    P(mW)
> > ----------------------------------------------------------------
> > Total estimated power consumption:               567
> >                                ---
> >                       Vccint 1.50V:      103      154
> >                       Vccaux 3.30V:      100      330
> >                       Vcco33 3.30V:       25       83
> >                                ---
> >                            Clocks:        1        1
> >                               IOs:        0       18
> >                            Inputs:        0        0
> >                             Logic:        1        1
> >                           Outputs:
> >                              Vcco33      19       62
> >                           Signals:        1        1
> >                                ---
> >            Quiescent Vccint  1.50V:      100      150
> >            Quiescent Vccaux  3.30V:      100      330
> >            Quiescent Vcco33  3.30V:        1        3
> >              Startup Vccint  1.5V:      250
> >              Startup Vccaux  3.3V:      100
> >              Startup Vcco33  3.3V:       50
> >                                ---
> > Package power limits, ambient 25C:              5085
> >                           250 LFM:              7317
> >                           500 LFM:              8955
> >                           750 LFM:             10169
> > 
> > Thermal summary:
> > ----------------------------------------------------------------
> >    Estimated junction temperature:                32C
> >                       250 LFM    30C
> >                       500 LFM    29C
> >                       750 LFM    28C
> >                   Ambient temp:  25C
> >                      Case temp:  31C
> >                      Theta J-A:  12C/W
> >                                ---
> > Max ambient at junction max of  85C:  78C
> >                          250 LFM      80C
> >                          500 LFM      81C
> >                          750 LFM      82C
> > 
> > Decoupling Network Summary:      Cap Range (uF)      #
> > ----------------------------------------------------------------
> > Capacitor Recommendations:    
> > Total for      Vccint :                             44
> >                                 470.0  - 1000.0 :    1
> >                                  4.70  -  10.00 :    2
> >                                 0.470  -  2.200 :    5
> >                                0.0470  - 0.2200 :    8
> >                                0.0100  - 0.0470 :   14
> >                                0.0010  - 0.0047 :   14
> >                                       ---
> > Total for      Vccaux :                              8
> >                                 470.0  - 1000.0 :    1
> >                                0.0470  - 0.2200 :    1
> >                                0.0100  - 0.0470 :    2
> >                                0.0010  - 0.0047 :    4
> >                                       ---
> > Total for      Vcco33 :                             11
> >                                 470.0  - 1000.0 :    1
> >                                 0.470  -  2.200 :    1
> >                                0.0470  - 0.2200 :    2
> >                                0.0100  - 0.0470 :    3
> >                                0.0010  - 0.0047 :    4
> >                             -----------------------------
> > I/O Bank Details:             
> > 
> > Bank  0 (3.3V) :
> >                                 470.0  - 1000.0 :    1
> >                                 0.470  -  2.200 :    1
> >                                0.0470  - 0.2200 :    2
> >                                0.0100  - 0.0470 :    3
> >                                0.0010  - 0.0047 :    4
> >                                           Total :   11
> >                                       ---
> > ----------------------------------------------------------------
> > For further information on Bypass/Decoupling Capacitors see
> > application note 623
> > 
> > WARNING:Power:762 - Only 61% of the design signals have been set.
> > WARNING:Power:763 - Only 49% of the design signals toggle.
> > INFO:Power:556 - Estimate is inaccurate based on analysis of the
> > design, user
> >    input and characterization data.
> > 
> > Power details:
> > -------------------------------------------------------------------------------
> > Outputs:1                        Loads  Loading(fF)  C(pF)  F(MHz) 
> > I(mA)  P(mW)
> > -------------------------------------------------------------------------------
> > Vcco33
> >   mpc_d<10>-E0                           35000        13      5.1   
> > 0.8    2.7
> >   mpc_d<12>-E0                           35000        13      5.1   
> > 0.8    2.7
> >   mpc_d<14>-E0                           35000        13      5.1   
> > 0.8    2.7
> >   mpc_d<15>-E0                           35000        13      5.1   
> > 0.8    2.7
> >   mpc_d<16>-E0                           35000        13      5.1   
> > 0.8    2.7
> >   mpc_d<20>-E0                           35000        13      5.1   
> > 0.8    2.7
> >   mpc_d<22>-E0                           35000        13      5.1   
> > 0.8    2.7
> >   mpc_d<27>-E0                           35000        13      5.1   
> > 0.8    2.7
> >   mpc_d<07>-E0                           35000        13      5.0   
> > 0.8    2.6
> >   mpc_d<08>-E0                           35000        13      4.9   
> > 0.8    2.6
> > -------------------------------------------------------------------------------
> > Logic:                           Loads  Loading(fF)  C(pF)  F(MHz) 
> > I(mA)  P(mW)
> > -------------------------------------------------------------------------------
> > CompRegD345<3>-E1                                      1     10.0   
> > 0.0    0.0
> > CompRegB378-U1/SP.WSGEN                                0     10.0   
> > 0.0    0.0
> > CompRegB378.WSGEN                                      0     10.0   
> > 0.0    0.0
> > CompRegB381-U1/SP.WSGEN                                0     10.0   
> > 0.0    0.0
> > CompRegB381.WSGEN                                      0     10.0   
> > 0.0    0.0
> > CompRegB384-U1/SP.WSGEN                                0     10.0   
> > 0.0    0.0
> > CompRegB384.WSGEN                                      0     10.0   
> > 0.0    0.0
> > CompRegB387-U1/SP.WSGEN                                0     10.0   
> > 0.0    0.0
> > CompRegB387.WSGEN                                      0     10.0   
> > 0.0    0.0
> > CompRegB583-U1/SP.WSGEN                                0     10.0   
> > 0.0    0.0
> > -------------------------------------------------------------------------------
> > Signals:                         Loads  Loading(fF)  C(pF)  F(MHz) 
> > I(mA)  P(mW)
> > -------------------------------------------------------------------------------
> > __ibuf_mpc_a<04>                   33                 19      2.8   
> > 0.1    0.1
> > __ibuf_mpc_a<03>                   33                 19      2.8   
> > 0.1    0.1
> > __ibuf_mpc_a<02>                   33                 19      2.5   
> > 0.1    0.1
> > __ibuf_mpc_a<05>                   33                 17      2.2   
> > 0.1   ~0.0
> > __ibuf_mpc_oe                      36                  9      3.2   
> > 0.0   ~0.0
> > CompRegC216                        78                 23      0.9   
> > 0.0   ~0.0
> > internal_mpc_d<15>                  1                  3      5.1   
> > 0.0   ~0.0
> > internal_mpc_d<22>                  1                  2      5.1   
> > 0.0   ~0.0
> > internal_mpc_d<01>                  1                  2      4.9   
> > 0.0   ~0.0
> > internal_mpc_d<00>                  1                  2      4.8   
> > 0.0   ~0.0
> > -------------------------------------------------------------------------------
> > Clocks:1                         Loads  Loading(fF)  C(pF)  F(MHz) 
> > I(mA)  P(mW)
> > -------------------------------------------------------------------------------
> > stream/clk/IBUFG
> >  Logic:
> >   stream/clk/BUFG                                      6     10.0   
> > 0.1    0.1
> >  Nets:
> >   stream/clk                       94                 38     10.0   
> > 0.6    0.9
> >   stream/clk/IBUFG                  1                  0     10.0   
> > 0.0   ~0.0
> > -------------------------------------------------------------------------------
> > Inputs:                          Loads  Loading(fF)  C(pF)  F(MHz) 
> > I(mA)  P(mW)
> > -------------------------------------------------------------------------------
> > stream/clk/IBUFG                                       3     10.0   
> > 0.1    0.1
> > __ibuf_mpc_oe                                          3      3.2   
> > 0.0    0.0
> > __ibuf_mpc_a<00>                                       3      3.0   
> > 0.0    0.0
> > __ibuf_mpc_a<03>                                       3      2.8   
> > 0.0    0.0
> > __ibuf_mpc_a<04>                                       3      2.8   
> > 0.0    0.0
> > __ibuf_mpc_a<07>                                       3      2.8   
> > 0.0    0.0
> > __ibuf_mpc_we<3>                                       3      2.8   
> > 0.0    0.0
> > __ibuf_mpc_a<13>                                       3      2.7   
> > 0.0    0.0
> > __ibuf_mpc_a<10>                                       3      2.6   
> > 0.0    0.0
> > __ibuf_mpc_a<11>                                       3      2.5   
> > 0.0    0.0
> > -------------------------------------------------------------------------------
> > IOs:1                            Loads  Loading(fF)  C(pF)  F(MHz) 
> > I(mA)  P(mW)
> > -------------------------------------------------------------------------------
> > Vcco33
> >   __ibuf_mpc_d<05>                                     3      5.3   
> > 0.0    0.0
> >   mpc_d<05>-E0                           35000        13      5.2   
> > 0.8    2.7
> >   __ibuf_mpc_d<06>                                     3      4.9   
> > 0.0    0.0
> >   mpc_d<06>-E0                           35000        13      5.2   
> > 0.8    2.7
> >   mpc_d<01>-E0                           35000        13      4.9   
> > 0.8    2.6
> >   __ibuf_mpc_d<01>                                     3      5.5   
> > 0.0    0.0
> >   __ibuf_mpc_d<00>                                     3      5.8   
> > 0.0    0.0
> >   mpc_d<00>-E0                           35000        13      4.8   
> > 0.8    2.5
> >   __ibuf_mpc_d<02>                                     3      5.2   
> > 0.0    0.0
> >   mpc_d<02>-E0                           35000        13      4.8   
> > 0.8    2.5
> > -------------------------------------------------------------------------------
> > 
> > Power improvement guide:
> > -------------------------------------------------------------------------------
> >  3 of 101 registers use an enable signal
> > -------------------------------------------------------------------------------
> > Signal                             Power when     Power when     Power
> > savings
> >                                    asserted(mW)   disabled(mW)   at
> > 50%(mW)
> > -------------------------------------------------------------------------------
> > AddrInCount355/Start-E0            567.1          567.1          0.0
> > 
> > 
> > For further suggestions on power improvements see application note no.
> > 421
> > 
> > Analysis completed: Sat Oct 02 16:28:00 2004
> > ----------------------------------------------------------------

Article: 74047
Subject: Re: Removing set/reset logic for shift register (HDL ADVISOR )
From: "Dave" <gretzteam@hotmail.com>
Date: Sat, 2 Oct 2004 21:18:54 -0400
Links: << >>  << T >>  << A >>
Ok I understand...but isn't it better to have a reset for all our flip flop?
If something goes wrong - or when I press the reset button...- the
controller can always reset everything to zero before we start again...

Thanks,
David

"Ray Andraka" <ray@andraka.com> wrote in message
news:415DAEA4.AAFC9B99@andraka.com...
> The SRL16 does not have a reset pin on it...ie, you can't clear its
> contents in one clock cycle.  Your code has a reset in it that clears the
> whole shift register, which means it cannot be implemented using an SRL16
> primitive (which costs only one LUT+FF instead of 9).  If you can
> eliminate the reset on this shift register, then you get a more compact
> implementation.  Your code would look like this:
>
> always @ (posedge mclk or negedge resetb)
> begin
>                   if (sclkRise == 1) begin
>                         datain[63:1] <= datain[62:0];
>                         datain[0] <= sdata;
>                 end
>                 if (lrclkRise == 1) begin
>                         leftdata <= datain[63:40];
>                         rightdata <= datain[31:8];
>                 end
>
> end
>
> David wrote:
>
> > Hi,
> > I'm getting an HDL ADVISOR message when I synthesize this code.
> > Basically, it is a big shift register that shift-in data on each
> > rising edge of mclk if srclkRise is high, and outputs its data on the
> > rising edge of mclk if lrclkRise is high. I don't quite understand the
> > advice here. Can anybody help?
> > Thanks,
> > David
> >
> > --ADVICE
> > INFO:Xst:741 - HDL ADVISOR - A 9-bit shift register was found for
> > signal <datain<8>> and currently occupies 9 logic cells (5 slices).
> > Removing the set/reset logic would take advantage of SRL16 (and
> > derived) primitives and reduce this to 1 logic cells (1 slices).
> > Evaluate if the set/reset can be removed for this simple shift
> > register. The majority of simple pipeline structures do not need to be
> > set/reset operationally.
> >
> > --CODE
> > always @ (posedge mclk or negedge resetb)
> > begin
> >         if (~resetb) begin
> >                 datain <= 0;
> >                 leftdata <= 0;
> >                 rightdata <= 0;
> >         end
> >         else begin
> >                 if (sclkRise == 1) begin
> >                         datain[63:1] <= datain[62:0];
> >                         datain[0] <= sdata;
> >                 end
> >                 if (lrclkRise == 1) begin
> >                         leftdata <= datain[63:40];
> >                         rightdata <= datain[31:8];
> >                 end
> >         end
> > end
>
> --
> --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: 74048
Subject: Re: FPGA vs ASIC area
From: mk<kal@delete.dspia.com>
Date: Sun, 03 Oct 2004 01:36:10 GMT
Links: << >>  << T >>  << A >>
On Fri, 01 Oct 2004 07:54:13 -0700, Austin Lesea <austin@xilinx.com>
wrote:
>30%+ of a Pentium IV is BIST logic

I find that very hard to believe. Do you have any references to back
up that claim ?


Article: 74049
Subject: Re: Removing set/reset logic for shift register (HDL ADVISOR )
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 02 Oct 2004 21:08:20 -0500
Links: << >>  << T >>  << A >>
>Ok I understand...but isn't it better to have a reset for all our flip flop?
>If something goes wrong - or when I press the reset button...- the
>controller can always reset everything to zero before we start again...

"Better" is an interesting word.  Sure, it's cleaner.  How much
are you willing to pay for that?  If it's just data in a pipeline
things will get cleaned out after a few cycles.  (May not be true
if IIR filters are involved.)

Note for example that (most) RAMs don't have a reset pin to
clear out the whole array.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.




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