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 140625

Article: 140625
Subject: Re: please recommend a soft processor for small image processing
From: Tommy Thorn <tommy.thorn@gmail.com>
Date: Wed, 20 May 2009 11:17:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 20, 11:05=A0am, CMOS <manusha1...@gmail.com> wrote:
> hi all,
> im planning to implement barcode scanning using a CMOS sensor. The
> processing needs to happen inside a FPGA, so im evaluating my options
> in choosing a proper soft processor for the task. these are my
> requirements.
>
> 1) open source and need to be able to be used in commercial products
> 2) need to have good documentation and support tools (toolchain,
> simulators, emulators)
> 3) robust and stable
> 4) need to use in an xilinx spartan 3 device with 400K gates.
>
> i know about processors OpenRISC 1000, NIOS 2 and LEON 2, but not sure
> how good they are with regard to my requirements, specially the (2),
> (3) and (4) above. Please help.
>
> in addition, i like to here about microblaze and its licensing fees
> structure

A few points:
- Nios II and MicroBlaze aren't open source, but both are very good.
- Is OpenRISC 1000 ok for commercial products?
- I doubt LEON 2 (and maybe OpenRISC 1000) can fit in "400K gates"

You could also consider YARI (http://yari.thorn.ws). It's a bit weak
in the documentation department though but has great tools. The
hardware debugger still work in progress, but YARI has excellent
simulation support.

Regards,
Tommy

Article: 140626
Subject: Re: ISIM and CONV_INTEGER warnings
From: "HT-Lab" <hans64@ht-lab.com>
Date: Wed, 20 May 2009 19:30:52 +0100
Links: << >>  << T >>  << A >>

"MikeWhy" <boat042-nospam@yahoo.com> wrote in message 
news:odWQl.17139$%54.3159@nlpi070.nbdc.sbc.com...
> "HT-Lab" <hans64@ht-lab.com> wrote in message 
> news:W7QQl.80572$861.55894@newsfe12.ams2...
>> Does anybody know how to disable the CONV_INTEGER warnings in ISIM 
>> (11.1)?
>>
>> at 3000290500 ps(1), Instance /cpu_top_tb/U_12/ : Warning: CONV_INTEGER: 
>> There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, and it has been 
>> converted to 0.
>> at 3000365500 ps(1), Instance /cpu_top_tb/U_12/ : Warning: CONV_INTEGER: 
>> There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, and it has been 
>> converted to 0.
>
> Only just guessing at the context... I would think ISIM's post-route 
> simulation elaborator is complaining that it's forcing to '0' an 
> uninitialized integer referenced in a math operation.
>
Hi Mike,

Yes you are correct, these message are normally generated by Synopsys/IEEE 
packages and in Modelsim I just turn them off. I know what's causing them 
and fixed the issue by changing the code, however, it would be useful to 
have an option to turn them off.

Hans,
www.ht-lab.com



Article: 140627
Subject: Re: ISIM and CONV_INTEGER warnings
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Wed, 20 May 2009 15:36:30 -0500
Links: << >>  << T >>  << A >>
"HT-Lab" <hans64@ht-lab.com> wrote in message 
news:51YQl.67411$M64.58819@newsfe26.ams2...
>
> "MikeWhy" <boat042-nospam@yahoo.com> wrote in message 
> news:odWQl.17139$%54.3159@nlpi070.nbdc.sbc.com...
>> "HT-Lab" <hans64@ht-lab.com> wrote in message 
>> news:W7QQl.80572$861.55894@newsfe12.ams2...
>>> Does anybody know how to disable the CONV_INTEGER warnings in ISIM 
>>> (11.1)?
>>>
>>> at 3000290500 ps(1), Instance /cpu_top_tb/U_12/ : Warning: CONV_INTEGER: 
>>> There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, and it has 
>>> been converted to 0.
>>> at 3000365500 ps(1), Instance /cpu_top_tb/U_12/ : Warning: CONV_INTEGER: 
>>> There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, and it has 
>>> been converted to 0.
>>
>> Only just guessing at the context... I would think ISIM's post-route 
>> simulation elaborator is complaining that it's forcing to '0' an 
>> uninitialized integer referenced in a math operation.
>>
> Hi Mike,
>
> Yes you are correct, these message are normally generated by Synopsys/IEEE 
> packages and in Modelsim I just turn them off. I know what's causing them 
> and fixed the issue by changing the code, however, it would be useful to 
> have an option to turn them off.

Hmmm. 'U' + 'X' is useful? ;) Selectively ignorable, yes, but habitually 
ignoring them silently does sound potentially problematic.



Article: 140628
Subject: Re: i2c Start and stop detection
From: gabor <gabor@alacron.com>
Date: Wed, 20 May 2009 13:44:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 20, 1:58=A0pm, VIPS <thevipulsi...@gmail.com> wrote:
> On May 19, 2:39=A0pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
> wrote:
>
>
>
> > Dear Vipul,
>
> > Seems like you are always going to get
> > some sort of timing issue since the rst
> > signal and the SDA_IN signal are async.
>
> > Propagating the STARTOP signal forward
> > to the STOPOP reset circuitry also seems
> > like a bad idea for some reason I can't
> > quite articulate, except for an idea that
> > the start and stop signals should be
> > symetrical.
>
> > If you have a system clock, I would suggest
> > that you use registers at your SDA and SCL
> > inputs right at the IOs. Then use old values
> > of SDA and SCL to calculate your START and
> > STOP signals:
>
> > start_stop_proc:process(clk)
> > begin
> > if(clk'event and clk=3D'1')then
> > =A0 STARTOP<=3D'0';
> > =A0 STOPOP<=3D'0';
> > =A0 SDA_1<=3DSDA_IN;
> > =A0 SDA_2<=3DSDA_1;
> > =A0 SCL_1<=3DSCL_IN;
> > =A0 if( SDA_1=3D'0' and SDA_2=3D'1' and SCL_1=3D'1')then
> > =A0 =A0STARTOP<=3D'1';
> > =A0 end if;
> > =A0 if( SDA_1=3D'1' and SDA_2=3D'0' and SCL_1=3D'1')then
> > =A0 =A0STOPOP<=3D'1';
> > =A0 end if;
> > end if;
> > end process;
>
> > This should be very clean as long as your system clock
> > and timing is OK. And it give clean oneshot reset signals
> > for your address and data registers.
>
> > Now if you are trying to run this from the SCL clock, perhaps
> > just taking the rst out of your process may work, or putting
> > it in the synchonous part of the block may work, and clean
> > up the code so that the both signals look symetrical:
>
> > start_proc:process(SDA_IN)
> > begin
> > =A0if(SDA_IN'event and SDA_IN=3D'0')then
> > =A0 if(rst=3D'1')then
> > =A0 =A0STARTOP<=3D'0';
> > =A0 elsif(scl=3D'1')then
> > =A0 =A0STARTOP<=3D'1';
> > =A0 else
> > =A0 =A0STARTOP<=3D'0';
> > =A0 end if;
> > =A0end if;
> > end process;
>
> > stop_proc:process(SDA_IN)
> > begin
> > =A0if(SDA_IN'event and SDA_IN=3D'1')then
> > =A0 if(rst=3D'1')then
> > =A0 =A0STOPOP<=3D'0';
> > =A0 elsif(scl=3D'1')then
> > =A0 =A0STOPOP<=3D'1';
> > =A0 else
> > =A0 =A0STOPOP<=3D'0';
> > =A0 end if;
> > =A0end if;
> > end process;
>
> > Then these signals need to be synched with scl clock
> > signal before you start messing with your data registers.
> > And you have to look for their edges since the SDA signal
> > can drop and not come up if it's sending a zero datum.
>
> > Using a system clock is a lot easier.
>
> > I haven't ever done a I2C slave so you might get better
> > answers elsewhere. Good luck.
>
> > Brad Smallridge
> > AiVision
>
> > "VIPS" <thevipulsi...@gmail.com> wrote in message
>
> >news:35bbb41b-ce32-4cb6-868e-a459b10d05a7@s28g2000vbp.googlegroups.com..=
.
>
> > > Hi all
>
> > > I am implementing the I2C Slave and I am using the I2C clock SCL for
> > > detecting the start and stop condition . I am detecting the start and
> > > stop successfully in simulation but i am not able to do the same in
> > > the post synthesis scenario. More so I am getting a setup time
> > > violation for the same in the timing analysis . I am running the I2C
> > > at a very slow speed of 100KHz.
>
> > > The code is below
>
> > > process (SDA_IN, START_RST,rst)
> > > =A0 begin
> > > =A0 =A0 if rst =3D'1' then
> > > =A0 =A0 =A0 =A0STARTOP <=3D'0';
> > > =A0 =A0-- elsif (START_RST =3D '1') then
> > > =A0 =A0-- =A0 =A0STARTOP <=3D '0';
> > > =A0 =A0 elsif (SDA_IN'event and SDA_IN =3D '0') then
> > > =A0 =A0 =A0 STARTOP <=3D scl;
> > > =A0 =A0 end if;
> > > =A0 end process;
> > > ---------------------------------------------------------------------=
---------
> > > -- stop condition detection
> > > process (RST, SCL, SDA_IN, STARTOP)
> > > begin
> > > =A0 =A0if RST =3D '1' or SCL =3D '0' or STARTOP=3D'1' then
> > > =A0 =A0 =A0 =A0STOPOP <=3D '0';
> > > =A0 elsif =A0SDA_IN =3D '1' and SDA_IN'event then
> > > =A0 =A0 =A0 if SCL =3D '1' then
> > > =A0 =A0 =A0 =A0 =A0 =A0 STOPOP <=3D '1';
> > > =A0 =A0 =A0 =A0end if ;
>
> > > =A0 end if;
> > > =A0end process;
>
> > > Can =A0any one give me a reliable way to detect the start and stop
> > > condition that =A0the synthesis tool doesnot give any setup time
> > > violation. I am not using a high clock for sampling as the requiremen=
t
> > > is to use the SCL only. May be to save board resourse and space.
>
> > > Help will be appreciated. I am using Altera max II CPLD and the
> > > synthesis tool is quartus 9.0
>
> > > Thanks
>
> > > Vipul
>
> Dear Brad
>
> Thanks for your reply and for your time. Your suggestion is very
> logical and I tried to implement it . The tool still gives an error in
> the setup time though the slack reduced considerably . I will try to
> work around it .
> You have shown a good way to deal with it by making the two process
> look symmetrical.
> Thanks once again for your valuable time
>
> Vipul

Having implemented with many I2C slaves in my projects I would
like to add a few points:

1) If you don't want to sample the I2C signals with another
clock, you WILL need schmitt-trigger inputs on your device.
I2C rise times are very slow and can have a lot of noise
while transitioning through the threshold region of most
parts.  Read the I2C spec to see the recommended hysteresis.
By the way, this is why you need level translators to go
from 3.3V to 5V I2C.  The logic thresholds are ratiometric.

2) If you are using something like an FPGA without any
schmitt trigger inputs, you need to de-glitch the SCL
and SDA signals before you use them in your state machine.
This is due to the possibility of multiple transitions
being detected while the signal slowly rises through
the threshold region.

I have posted Verilog code for a simple I2C slave using
a higher speed clock and deglitching on the Xilinx forums.

Regards,
Gabor

Article: 140629
Subject: Re: Online tool that generates parallel CRC and Scrambler
From: Mark <mark@cacurry.net>
Date: Wed, 20 May 2009 13:46:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
Evgeni,

Ok neat.  But why not just code the algorithm in straight verilog or
VHDL, instead of C generates verilog?  The C generated verilog code
is unmanageable.

CRC, and LFSR algorithms are the top of the list for implenting in
hardware (i.e. HDLs) rather than C.  C implementations are messy.

You don't need to calculate "one-bit per clock" - rather one-bit per
ITERATION.  Who says each iteration must be a clock tick?  Just
implement the procedural code for the logic update of one bit and
stick a 'for' loop around it for 'n' bits.  Boom, done.  Let
the synthesis tool optimize, and produce the big XOR trees.

The core of the verilog code that supports any polynomial
(width, taps), and any data size could consist of less than
10 lines of code.

--Mark



Article: 140630
Subject: Synthesis of Xilinx's PLB DDR Controller
From: Erik Anderson <erik.k.anderson@gmail.com>
Date: Wed, 20 May 2009 13:57:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
I am running into problems when I am trying to synthesize a design
with the plb_ddr2_v1_02_b IP core with Synplify.  My project requires
synthesizing the design from HDL source without any netlists.
Currently, through XPS when synthesizing to netlists the ddr2
controller generates 3 EDIFs for Asynchronous FIFOs.  These are:
ddr2_sdram_32mx64_wrapper_async_fifo_v4_0_1.edn,
ddr2_sdram_32mx64_wrapper_async_fifo_v4_0_2.edn, and
ddr2_sdram_32mx64_wrapper_async_fifo_v4_0_3.edn.  These EDIFs are
generated through what appears to be an attribute in the
proc_common_v2_00_b HDL file: coregen_comp_defs which uses the tool:
edk_generatecore.

My requirement to use only HDL source code forces me to find a
solution to this problem.  I am also constrained to use the PLB V3.4
(instead of the newer 4.6), so using a different interface such as the
MPMC may not be possible (unless it is possible to backport the MPMC
to the 3.4 PLB).  It may be possible that Synplify is pruning out
certain components or the Async FIFOs that we have generated to HDL
via Xilinx netgen tool are not being mapped correctly.

Any suggestions?

Article: 140631
Subject: Re: Port assignment question
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Wed, 20 May 2009 23:19:50 +0200
Links: << >>  << T >>  << A >>
hassen.karray@gmail.com a écrit :

> put a clock in your process : process(clk) but don't use it inernally,
> it is just a syntax issue .


WHAT ?!
This is pure nonsense. Put your input signals in the sensitivity list : 
process (bus2, pin_11, pin_22)

Nicolas

Article: 140632
Subject: Re: some soft-processors
From: -jg <Jim.Granville@gmail.com>
Date: Wed, 20 May 2009 14:21:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 17, 11:01=A0pm, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
# the direct FPGA version was optimized for single cycle operation
# so every clock 24 bits of instruction and 2 16 bit words TOS/NOS are
# fetched from BRAMs

Why 24 bits of opcode ? - is that 3 opcode fetches at a time ?
(Pascal-S seems to vary, up to 64 opcodes max ?)

I also looked around for examples on Instruction List (IEC 61131)
source
and there are not a lot of non-trivial example-references, but there
are some 'education free' working systems around, that can be used to
test.

This one looks good, and seems to work most examples in Simulate mode.
http://www.61131.com/il.htm
( IL Bracket expression support, would use the stack.)
http://www.61131.com/download.htm

I think a core/tools could be made that maps well to _both_ Pascal-S
and Instruction-List usage ?
If it stays small enough, a LOT of these could fit into a FPGA.

A core that is usable at both 'Quasi Assembler level', and HLL, could
have
longevity, and a tiny version would be usable for things like UART
feeding & loaders.

Wonder what your AVR loader, would be in IL syntax :) ?

-jg

Article: 140633
Subject: Re: Open source processors
From: Jecel <jecel@merlintec.com>
Date: Wed, 20 May 2009 14:53:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
Though I was familiar with Chuck Thacker's (designer of the Xerox Alto
and Microsoft TabletPC) simple FPGA processor, I didn't know it was
documented anywhere until a friend sent me this link a couple of days
ago:

http://www.bottomup.co.nz/mirror/Thacker-A_Tiny_Computer-3.pdf

This paper includes the Verilog sources. As it is, it reminds me of a
fat 32 bit version of Picoblaze but it is trivial to implement some of
the expansions that are suggested.

-- Jecel

Article: 140634
Subject: Re: Open source processors
From: -jg <Jim.Granville@gmail.com>
Date: Wed, 20 May 2009 17:14:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 21, 9:53=A0am, Jecel <je...@merlintec.com> wrote:

# http://www.bottomup.co.nz/mirror/Thacker-A_Tiny_Computer-3.pdf

Nice, I like the 'fat' register area, as that is one area FPGAs have
almost for free.

I also see the extension notes to allow multiple contexts, or virtual
cores, which
is another natural extension from the BRAMs

["
The second extension addresses the lack of interrupts. Since the BRAM
holding the
registers can hold eight full register contexts, it should be
straightforward to provide a
mechanism similar to that of the Alto. A separate three-bit Context
register would hold
the current context. Saving and restoring the current context=92s PC on
a task switch is a bit problematic, but it is probably fairly
straightforward."]

This could, of course, map to more than 8, with a simple ROM if you
only needed a smaller register array for some contexts. (eg 4 x 128R
cores, and 16 x 32R cores)

-jg

Article: 140635
Subject: Re: Online tool that generates parallel CRC and Scrambler
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 21 May 2009 00:43:36 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga Mark <mark@cacurry.net> wrote:
(snip)
 
< CRC, and LFSR algorithms are the top of the list for implenting in
< hardware (i.e. HDLs) rather than C.  C implementations are messy.
 
(snip)
 
< The core of the verilog code that supports any polynomial
< (width, taps), and any data size could consist of less than
< 10 lines of code.

Note that Xilinx FPGAs can do 16 bits of LFSR in one SRL16, 
which takes up very little space.  You could easily generate
many of them, also wider than 16 bits.  

-- glen

Article: 140636
Subject: Are all these claims in VHDL correct?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 20 May 2009 18:50:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
I am trying to claim the following things in VHDL in
some written materials, and want to know if they are absolute
correct practically based on Xilinx FPGA implementations, not
theoretically on ModelSim
simulations.

signal   X  : unsigned(63 downto 0);
signal   X0 : unsigned(63 downto 0);
signal   X1 : unsigned(63 downto 0);
signal   X2 : unsigned(63 downto 0);
signal   X3 : unsigned(63 downto 0);
signal   A1 : std_logic;
signal   A2 : std_logic;
signal   A3 : std_logic;

1. The following M1 and M2 process code implementations are the same:

M1 : process(..)
begin
   X <= X0;
   if A1 = '1' then
      X <= X1;
      if A2 = '1' then
         X <= X2;
      elsif A3 = '1' then
         X <= X3;
      end if;
   end if;
end process;

M2 : process(..)
begin
   if A1 = '1' then
      if A2 = '1' then
         X <= X2;
      elsif A3 = '1' then
         X <= X3;
      else
         X <= X1;
      end if;
   else
      X <= X0;
   end if;
end process;

2. The following M3 to M5 process code implementations are the same:

M3 : process(A1)
begin
   if A1 = '1' then
      X <= X1;
   else
      null;
   end if;
end process;

M4 : process(A1)
begin
   if A1 = '1' then
      X <= X1;
   end if;
end process;

M5 : process(A1)
begin
   if A1 = '1' then
      X <= X1;
   else
      X <= X;
   end if;
end process;

3. The following M6 to M8 process code implementations are the same:

M6 : process(CLK)
begin
   if CLK'event and CLK = '1' then
      if A1 = '1' then
         X <= X1;
      else
         null;
      end if;
   end if;
end process;

M7 : process(CLK)
begin
   if CLK'event and CLK = '1' then
      if A1 = '1' then
         X <= X1;
      end if;
   end if;
end process;

M8 : process(CLK)
begin
   if CLK'event and CLK = '1' then
      if A1 = '1' then
         X <= X1;
      else
         X <= X;
      end if;
   end if;
end process;

Thank you.

Weng

Article: 140637
Subject: Can we expect ISE Gui and makefile to produce identical bit files?
From: andrew.newsgroup@gmail.com
Date: Wed, 20 May 2009 19:16:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
We are switching to a makefile to build our Xilinx FPGA bit files. Can
we expect to get an identical bit file (except for date/time in the
bitfile header) if we build through the ISE gui vs building via the
command line?

What we have found is that the output ngd file from the ngdbuild
process (Translate) is not the same in both cases. The file size
differs by 100 bytes, and the resulting bitfiles end up being very
different. Can we expect the ngd file to be identical?

We use synplicity to synthesize the design, which creates an edif
netlist. The edif netlist going into the ISE flow and makefile flow
are identical.

Cheers
Andrew

Article: 140638
Subject: GTKWave 3.2.1 for Windows is available
From: Muzaffer Kal <kal@dspia.com>
Date: Wed, 20 May 2009 19:35:55 -0700
Links: << >>  << T >>  << A >>
Hi everyone,
the latest version of GTKWave (3.2.1) windows binary is available at
here: http://www.dspia.com/gtkwave.html
Thanks to Tony now we have a way to start GTKWave without a file and
open one later.

-- Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com

Article: 140639
Subject: Re: Open source processors
From: Tommy Thorn <tommy.thorn@gmail.com>
Date: Wed, 20 May 2009 20:06:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 20, 2:53=A0pm, Jecel <je...@merlintec.com> wrote:
> Though I was familiar with Chuck Thacker's (designer of the Xerox Alto
> and Microsoft TabletPC) simple FPGA processor, I didn't know it was
> documented anywhere until a friend sent me this link a couple of days
> ago:
>
> http://www.bottomup.co.nz/mirror/Thacker-A_Tiny_Computer-3.pdf
>
> This paper includes the Verilog sources. As it is, it reminds me of a
> fat 32 bit version of Picoblaze but it is trivial to implement some of
> the expansions that are suggested.

Very interesting. Thanks Jecel.

The two phase clock is certainly unusual for a small core like this.
It would probably be more practical to sacrifice a bit of performance
to get it to a more standard single clock (with two cycles pr
instruction).

What is the license terms for this? Public domain?

Now we just need a backend for GCC/LLVM/LCC/...

Tommy

Article: 140640
Subject: Re: Can we expect ISE Gui and makefile to produce identical bit files?
From: Matthew Hicks <mdhicks2@uiuc.edu>
Date: Thu, 21 May 2009 03:37:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
> Hi,
> We are switching to a makefile to build our Xilinx FPGA bit files. Can
> we expect to get an identical bit file (except for date/time in the
> bitfile header) if we build through the ISE gui vs building via the
> command line?
> What we have found is that the output ngd file from the ngdbuild
> process (Translate) is not the same in both cases. The file size
> differs by 100 bytes, and the resulting bitfiles end up being very
> different. Can we expect the ngd file to be identical?
> 
> We use synplicity to synthesize the design, which creates an edif
> netlist. The edif netlist going into the ISE flow and makefile flow
> are identical.
> 
> Cheers
> Andrew

Are you sure that the settings you are using are identical.  I was under 
the impression that ISE was just a GUI wrapper that sent commands to a common 
set of implementation programs.


---Matthew Hicks



Article: 140641
Subject: Re: Cheap Ethernet PHY boards?
From: radarman <jshamlet@gmail.com>
Date: Wed, 20 May 2009 21:21:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 16, 6:12=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> radarman <jsham...@gmail.com> wrote:
>
> (snip)
>
> > I'm essentially looking for a board that has MII/GMII on one side, and
> > an RJ-45 connector on the other. These exist, but cost hundreds of
> > dollars. (the EVB-LAN8700 would be perfect, if it wasn't nearly $300!)
> > Does anyone know of a cheap (~$50) board that essentially does the
> > above? 10/100 would be fine.
>
> The Spartan3E board has built in 10/100 PHY, supply your
> own MAC. =A0That is $150, so more than $50, less than $300.
>
> -- glen

I'm already set up for Altera, though the Spartan 3e board is
tempting.

However, I've priced the parts for a board at under $20. In
particular, Micrel has a 10/100 Phy for ~$6.50, and a Magjack RJ45
with integrated magnetics goes for about $9. That's really about it,
save for a few biasing resistors, bypass caps, ferrite beads, and some
header strip. The PCB's will likely cost a bit, but I suspect a simple
4-layer board will suffice - which most prototype places can do for
cheap.

Hopefully, if the boards work, I can sell the extras to recoup a bit
of the cost.

Article: 140642
Subject: Re: please recommend a soft processor for small image processing
From: CMOS <manusha1980@gmail.com>
Date: Wed, 20 May 2009 21:30:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 21, 12:17=A0am, Tommy Thorn <tommy.th...@gmail.com> wrote:
> On May 20, 11:05=A0am, CMOS <manusha1...@gmail.com> wrote:
>
>
>
> > hi all,
> > im planning to implement barcode scanning using a CMOS sensor. The
> > processing needs to happen inside a FPGA, so im evaluating my options
> > in choosing a proper soft processor for the task. these are my
> > requirements.
>
> > 1) open source and need to be able to be used in commercial products
> > 2) need to have good documentation and support tools (toolchain,
> > simulators, emulators)
> > 3) robust and stable
> > 4) need to use in an xilinx spartan 3 device with 400K gates.
>
> > i know about processors OpenRISC 1000, NIOS 2 and LEON 2, but not sure
> > how good they are with regard to my requirements, specially the (2),
> > (3) and (4) above. Please help.
>
> > in addition, i like to here about microblaze and its licensing fees
> > structure
>
> A few points:
> - Nios II and MicroBlaze aren't open source, but both are very good.
> - Is OpenRISC 1000 ok for commercial products?
> - I doubt LEON 2 (and maybe OpenRISC 1000) can fit in "400K gates"
>
> You could also consider YARI (http://yari.thorn.ws). It's a bit weak
> in the documentation department though but has great tools. The
> hardware debugger still work in progress, but YARI has excellent
> simulation support.
>
> Regards,
> Tommy

thanks tommy.

why do you think OpenRISC 1000 is not suitable for commercial
projects?

thanks.

Article: 140643
Subject: Re: please recommend a soft processor for small image processing
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 20 May 2009 21:35:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 21, 7:30=A0am, CMOS <manusha1...@gmail.com> wrote:
> On May 21, 12:17=A0am, Tommy Thorn <tommy.th...@gmail.com> wrote:
>
>
>
> > On May 20, 11:05=A0am, CMOS <manusha1...@gmail.com> wrote:
>
> > > hi all,
> > > im planning to implement barcode scanning using a CMOS sensor. The
> > > processing needs to happen inside a FPGA, so im evaluating my options
> > > in choosing a proper soft processor for the task. these are my
> > > requirements.
>
> > > 1) open source and need to be able to be used in commercial products
> > > 2) need to have good documentation and support tools (toolchain,
> > > simulators, emulators)
> > > 3) robust and stable
> > > 4) need to use in an xilinx spartan 3 device with 400K gates.
>
> > > i know about processors OpenRISC 1000, NIOS 2 and LEON 2, but not sur=
e
> > > how good they are with regard to my requirements, specially the (2),
> > > (3) and (4) above. Please help.
>
> > > in addition, i like to here about microblaze and its licensing fees
> > > structure
>
> > A few points:
> > - Nios II and MicroBlaze aren't open source, but both are very good.
> > - Is OpenRISC 1000 ok for commercial products?
> > - I doubt LEON 2 (and maybe OpenRISC 1000) can fit in "400K gates"
>
> > You could also consider YARI (http://yari.thorn.ws). It's a bit weak
> > in the documentation department though but has great tools. The
> > hardware debugger still work in progress, but YARI has excellent
> > simulation support.
>
> > Regards,
> > Tommy
>
> thanks tommy.
>
> why do you think OpenRISC 1000 is not suitable for commercial
> projects?
>
> thanks.

it doesnt fir s3-400 as a starter

Antti

Article: 140644
Subject: Re: some soft-processors
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 20 May 2009 21:43:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 21, 12:21=A0am, -jg <Jim.Granvi...@gmail.com> wrote:
> On May 17, 11:01=A0pm, "Antti.Luk...@googlemail.com"<Antti.Luk...@googlem=
ail.com> wrote:
>
> # the direct FPGA version was optimized for single cycle operation
> # so every clock 24 bits of instruction and 2 16 bit words TOS/NOS are
> # fetched from BRAMs
>
> Why 24 bits of opcode ? - is that 3 opcode fetches at a time ?
> (Pascal-S seems to vary, up to 64 opcodes max ?)
>
i should have said 24 bits made up from a byte holding opcode and 16
bit operand

> I also looked around for examples on Instruction List (IEC 61131)
> source
> and there are not a lot of non-trivial example-references, but there
> are some 'education free' working systems around, that can be used to
> test.
>
> This one looks good, and seems to work most examples in Simulate mode.htt=
p://www.61131.com/il.htm
> ( IL Bracket expression support, would use the stack.)http://www.61131.co=
m/download.htm
>
> I think a core/tools could be made that maps well to _both_ Pascal-S
> and Instruction-List usage ?
> If it stays small enough, a LOT of these could fit into a FPGA.
>

IL core would be simple for FPGA sure, but i think the IL is mostly
processed by some processor, eg interpreted

> A core that is usable at both 'Quasi Assembler level', and HLL, could
> have
> longevity, and a tiny version would be usable for things like UART
> feeding & loaders.
>
> Wonder what your AVR loader, would be in IL syntax :) ?
>
> -jg

Jim, it actually doesnt matter that much, see the only reason i had to
push
the SD bootstrap was to fit to 128 byte flash ram space of actel
proasic3

for any other FPGA families there is more initial bootstrap rom
available
so the size of bootstrap isnt that critical

Antti









Article: 140645
Subject: Re: Open source processors
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 20 May 2009 22:15:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 21, 6:06=A0am, Tommy Thorn <tommy.th...@gmail.com> wrote:
> On May 20, 2:53=A0pm, Jecel <je...@merlintec.com> wrote:
>
> > Though I was familiar with Chuck Thacker's (designer of the Xerox Alto
> > and Microsoft TabletPC) simple FPGA processor, I didn't know it was
> > documented anywhere until a friend sent me this link a couple of days
> > ago:
>
> >http://www.bottomup.co.nz/mirror/Thacker-A_Tiny_Computer-3.pdf
>
> > This paper includes the Verilog sources. As it is, it reminds me of a
> > fat 32 bit version of Picoblaze but it is trivial to implement some of
> > the expansions that are suggested.
>
> Very interesting. Thanks Jecel.
>
> The two phase clock is certainly unusual for a small core like this.
> It would probably be more practical to sacrifice a bit of performance
> to get it to a more standard single clock (with two cycles pr
> instruction).
>
> What is the license terms for this? Public domain?
>
> Now we just need a backend for GCC/LLVM/LCC/...
>
> Tommy

there is also TC5 available with full sources if you search
its a newer version of the TC, it has some assembler included in the
package

TC5 is licensed as MSL Microsoft Reseach License
what says rree for non commercial

Antti

Article: 140646
Subject: Re: Can we expect ISE Gui and makefile to produce identical bit
From: David Antliff <david.antliff@gmail.com>
Date: Wed, 20 May 2009 22:53:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 21, 3:37=A0pm, Matthew Hicks <mdhic...@uiuc.edu> wrote:
> Are you sure that the settings you are using are identical. =A0I was unde=
r
> the impression that ISE was just a GUI wrapper that sent commands to a co=
mmon
> set of implementation programs.

Hi Matthew,

I'm working with Andrew on this project.

The settings are not identical because ngdbuild.exe invoked by ISE has
an '-ise project.ise' and '-intstyle ise' options. We want to avoid
the use of the .ise project file entirely.

Also it seems that the GUI calls a different set of executables in the
"unwrapped" subdirectory of "ISE/bin/nt". It also passes the ISE
project file as a parameter and there's evidence that some settings
(such as the UCF file) are drawn from this. As I mention later,
running the same executable as the ISE generates a strange fatal
exception.

Let me try and describe the issue fully.

 - we are using Xilinx 10.1 service pack 3 on Windows XP, and a recent
installation of Cygwin.
 - we are trying to incorporate Xilinx into our automated build system
- so we are running the Xilinx command-line applications from a GNU
Makefile invoked from a Cygwin bash shell.
 - we want to avoid the project .ise file completely as this seems to
change every time anyone opens it - this makes build tracking
difficult and therefore the .ise file is unsuitable as an input to our
automated build process.
 - we first synthesize an EDIF file with Synplify 9.6.2 - this is
called FPGA_DAC16V2.edf in the examples below
 - the Xilinx Project Navigator ISE file contains just two sources:
    FPGA_DAC16V2.edf
    Constraints/FPGA_DAC16V2.ucf

Once we have our EDIF, we wanted to see how to drive the Xilinx
Translate process (ngdbuild.exe) from the command line:

 - the <project>.cmd_log file that Project Navigator creates during
Translate shows ngdbuild executing as follows:

ngdbuild -ise "D:/DAC_16v2/FPGA_DAC16V2/PAR/FPGA_DAC16V2/
FPGA_DAC16V2.ise" -intstyle ise -dd _ngo  -nt timestamp -i -p xc3s1000-
ft256-4 "D:/DAC_16v2/FPGA_DAC16V2/Synthesis/FPGA_DAC16V2/rev_1/
FPGA_DAC16V2.edf" FPGA_DAC16V2.ngd

 - hmm, there are two 'ngdbuild.exe' programs under .../ISE/bin/nt -
which one is being run? We think it's 'bin/nt/unwrapped/ngdbuild.exe'.
 - anyway, we note the '-i' option means 'ignore the User Constraints
File', although the log output shows:
    ...
    Reading in constraint information from 'Constraints/
FPGA_DAC16v2.ucf'...

    ...

 - we believe ngdbuild is picking up the presence of this UCF file
from the referenced .ise file, but perhaps not actually applying the
constraints due to -i option.
 - now, because we want to remove the .ise file from our process, we
manually converted this into the following command using "xflow"
integration:

D:/Xilinx/10.1/ISE/bin/nt/ngdbuild.exe -intstyle xflow -dd _ngo  -nt
timestamp -i -p xc3s1000-ft256-4
"D:/DAC_16v2/FPGA_DAC16V2/Synthesis/FPGA_DAC16V2/rev_1/
FPGA_DAC16V2.edf" FPGA_DAC16V2.ngd

However the log output from this shows that this time, the constraint
information is not read, presumably because ngdbuild does not know
about the UCF file. This also results in a file about 100kb smaller
than the ISE generated .ngd file - certainly a different output. If
the entire process is run to generate a .bit file, a binary diff shows
these two .bit files as *significantly* different.

 - so we determine that the UCF is probably required, changing the
command line to (replacing -i with -uc <file>):

D:/Xilinx/10.1/ISE/bin/nt/ngdbuild.exe -intstyle xflow -dd _ngo  -nt
timestamp -uc Constraints/FPGA_DAC16V2.ucf -p xc3s1000-ft256-4 "D:/
DAC_16v2/FPGA_DAC16V2/Synthesis/FPGA_DAC16V2/rev_1/FPGA_DAC16V2.edf"
FPGA_DAC16V2.ngd

HOWEVER

Instead of "Reading in constraint information from 'Constraints/
FPGA_DAC16v2.ucf'..." we see this instead:

...
Applying constraints in "d:/DAC_16v2/FPGA_DAC16V2/PAR/FPGA_DAC16V2/
Constraints/FPGA_DAC16V2.ucf" to the design...
...

This is not what the ISE flow said it was doing. It read the UCF file
but it certainly didn't say it was applying the constraints!

Not only this, but the resulting .ngd file is still different - in
this case, the ISE generated .ngd file is 5333871 bytes and the one
generated by the commandline is only 5333798 bytes, or 73 bytes
smaller. A binary diff shows the files are almost entirely different.
This results in all other files beyond ngdbuild (such as map, par,
etc) to be different too. And the problem is, we don't know what is
actually different!

Interestingly, although all the resulting intermediate files that
follow on from this are different between the two processes, the
final .bit file is thankfully identical except for a few bytes that
look like a timestamp near the top of the file. This is a huge relief!
However we would still like to know what is going on because if we
can't generate identical ngd files, or at least be sure that they
differ only by a timestamp, then building confidence in our build
system will be difficult. Who is to say that future builds will
deviate in unknown ways?

We would like the output from ISE to exactly match the output from the
commandline, and if this is not possible then we'd like to know why
the two output files differ.

This raises a few questions:

1. is the .ngd output file encrypted or perhaps compressed? This would
explain the massive difference in the two files, especially if there's
a timestamp embedded in them.

2. how can we get the output .ngd files to be the same without
referencing the .ise file - what are we missing on the command line?

3. why does the ISE flow appear to not apply the UCF constraints, yet
if we don't do this with our command-line build, the resulting .bit
file is completely different.

4. why does the .ise Project file continually change? Even running
'ngdbuild -ise FPGA_DAC16V2.ise -h' to display the program's HELP text
causes the .ise file to change! Why? This makes it very difficult to
manage in a Source Control tool because it's continually changing
without a clear reason.

5. what is the difference between the file .../ISE/bin/nt/ngdbuild.exe
and .../ISE/bin/nt/unwrapped/ngdbuild.exe? The 'unwrapped' version of
ngdbuild.exe is used by ISE but when used in the example command-lines
above it frequently fails to find the UCF file and aborts:

ERROR:ProjectMgmt:356 - Problem loading constraints.
...
FATAL_ERROR:NgdBuild:Portability/export/Port_Main.h:143:1.6 - This
application
   has discovered an exceptional condition from which it cannot
recover.
   Process will terminate. For technical support on this issue, please
open a
   WebCase with this project attached at http://www.xilinx.com/support.

I assume from this that we are not supposed to be calling the
'unwrapped' version of the exe file? Perhaps this is for internal ISE
use only?

So it appears it is not possible to run a). the same ngdbuild
executable, or b). the same command line options if you want to
completely avoid referencing the ISE project file with a command-line
invocation of ngdbuild.



-- David Antliff

Article: 140647
Subject: Re: ISIM and CONV_INTEGER warnings
From: "HT-Lab" <hans64@ht-lab.com>
Date: Thu, 21 May 2009 08:06:13 +0100
Links: << >>  << T >>  << A >>

"MikeWhy" <boat042-nospam@yahoo.com> wrote in message 
news:eRZQl.30176$Ws1.8735@nlpi064.nbdc.sbc.com...
> "HT-Lab" <hans64@ht-lab.com> wrote in message 
> news:51YQl.67411$M64.58819@newsfe26.ams2...
>>
>> "MikeWhy" <boat042-nospam@yahoo.com> wrote in message 
>> news:odWQl.17139$%54.3159@nlpi070.nbdc.sbc.com...
>>> "HT-Lab" <hans64@ht-lab.com> wrote in message 
>>> news:W7QQl.80572$861.55894@newsfe12.ams2...
>>>> Does anybody know how to disable the CONV_INTEGER warnings in ISIM 
>>>> (11.1)?
>>>>
>>>> at 3000290500 ps(1), Instance /cpu_top_tb/U_12/ : Warning: 
>>>> CONV_INTEGER: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, 
>>>> and it has been converted to 0.
>>>> at 3000365500 ps(1), Instance /cpu_top_tb/U_12/ : Warning: 
>>>> CONV_INTEGER: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, 
>>>> and it has been converted to 0.
>>>
>>> Only just guessing at the context... I would think ISIM's post-route 
>>> simulation elaborator is complaining that it's forcing to '0' an 
>>> uninitialized integer referenced in a math operation.
>>>
>> Hi Mike,
>>
>> Yes you are correct, these message are normally generated by 
>> Synopsys/IEEE packages and in Modelsim I just turn them off. I know 
>> what's causing them and fixed the issue by changing the code, however, it 
>> would be useful to have an option to turn them off.
>
> Hmmm. 'U' + 'X' is useful? ;) Selectively ignorable, yes, but habitually 
> ignoring them silently does sound potentially problematic.
>
It is quite easy to get gazillions of these messages in VHDL, for example 
before a reset is asserted or a tri-state bus feeding into an adder (as was 
in my case). These warnings prevents you from seeing any other messages. It 
also seriously hampers your simulation performance since writing to the 
transcript window (at least in Modelsim) is a real performance hog.

Hans
www.ht-lab.com




Article: 140648
Subject: Re: Are all these claims in VHDL correct?
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Thu, 21 May 2009 08:40:55 +0100
Links: << >>  << T >>  << A >>
On Wed, 20 May 2009 18:50:56 -0700 (PDT), Weng Tianxiang wrote:

>I am trying to claim the following things in VHDL in
>some written materials, and want to know if they are absolute
>correct practically based on Xilinx FPGA implementations, not
>theoretically on ModelSim simulations.

That's a very strange way to look at it.  The VHDL language
is defined by its simulation semantics.  Synthesis creates
hardware that conforms to a certain (very useful) subset
of those behaviours.  It makes no sense to say that your
understanding of VHDL is "absolutely correct... based on
FPGA implementations".

On the other hand, you CAN reasonably ask "do these two
pieces of VHDL code imply identical synthesised hardware?".

>signal   X  : unsigned(63 downto 0);
>signal   X0 : unsigned(63 downto 0);
>signal   X1 : unsigned(63 downto 0);
>signal   X2 : unsigned(63 downto 0);
>signal   X3 : unsigned(63 downto 0);
>signal   A1 : std_logic;
>signal   A2 : std_logic;
>signal   A3 : std_logic;
>
>1. The following M1 and M2 process code implementations are the same:
>
>M1 : process(..)
>begin
>   X <= X0;
>   if A1 = '1' then
>      X <= X1;
>      if A2 = '1' then
>         X <= X2;
>      elsif A3 = '1' then
>         X <= X3;
>      end if;
>   end if;
>end process;
>
>M2 : process(..)
>begin
>   if A1 = '1' then
>      if A2 = '1' then
>         X <= X2;
>      elsif A3 = '1' then
>         X <= X3;
>      else
>         X <= X1;
>      end if;
>   else
>      X <= X0;
>   end if;
>end process;

Well... single-stepping through the two pieces of
code in a simulator will of course show slightly
different sequences of activity, but I agree that
the externally-visible results of the two processes
should be identical.  It is impossible to tell the
difference between

  Y <= A;
  Y <= B; -- completely replaces assignment Y<=A

and

  Y <= B;

(unless the evaluation of expression A has side-effects,
of course).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>2. The following M3 to M5 process code implementations are the same:
>
>M3 : process(A1)
>begin
>   if A1 = '1' then
>      X <= X1;
>   else
>      null;
>   end if;
>end process;
>
>M4 : process(A1)
>begin
>   if A1 = '1' then
>      X <= X1;
>   end if;
>end process;

I agree that these two are identical in every meaningful way.
"null;" really does nothing.

>M5 : process(A1)
>begin
>   if A1 = '1' then
>      X <= X1;
>   else
>      X <= X;
>   end if;
>end process;

No, this is not the same.  In M5 but not in M4, when 
A1 transitions to a value that is not '1', signal X 
is written; there will be no value-change on X as a 
result, for sure, but there *is* a transaction on X
and that could be detected, outside the process,
with the 'transaction, 'active or 'quiet attributes.

None of the processes M3 to M5 follow any conventional
synthesis template.  If you had included X1 in the 
sensitivity list, they would all be perfectly good
descriptions of a transparent latch.  If you had
rewritten the condition as "if rising_edge(A1)" they
would all be perfectly good descriptions of a register.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>3. The following M6 to M8 process code implementations are the same:
>
>M6 : process(CLK)
>begin
>   if CLK'event and CLK = '1' then
>      if A1 = '1' then
>         X <= X1;
>      else
>         null;
>      end if;
>   end if;
>end process;
>
>M7 : process(CLK)
>begin
>   if CLK'event and CLK = '1' then
>      if A1 = '1' then
>         X <= X1;
>      end if;
>   end if;
>end process;

M6 and M7 are completely identical in behaviour, yes.

>M8 : process(CLK)
>begin
>   if CLK'event and CLK = '1' then
>      if A1 = '1' then
>         X <= X1;
>      else
>         X <= X;
>      end if;
>   end if;
>end process;

Same discussion as for M5, above.

-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 140649
Subject: Re: Sigasi Public Beta: future of VHDL design
From: "colin_toogood@yahoo.com" <colin_toogood@yahoo.com>
Date: Thu, 21 May 2009 01:15:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
I created an account and downloaded it. Then I noticed the one month
license and no pricing. Perhaps you might post again when you have
decided whether I can afford it at which point I will try it. Your
website promises many of the things I've always wanted from an editor.

Colin



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