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
2017JanFebMarApr2017

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 28950

Article: 28950
Subject: Re: Encryption is supported in new Virtex II but.....
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 31 Jan 2001 00:16:23 +0000
Links: << >>  << T >>  << A >>


Peter wrote:

> >But: There is a self-discharge mechanism that is the real limitation.
> >Good 3-V Lithium batteries have a shelf life of 15 years or more.
>
> This is a much bigger issue than it first appears. I have designed a
> number of very low power products powered by lithium watch-type cells,
> did a lot of evaluations of different cells, and it was amazing to
> find how bad some cells were. One make (European) had a shelf life
> consistently of about 1 year (to <20% capacity), the best Japanese
> makes were probably >10 years, but "bad batches" happen right across
> the board.
>
> I would be very unhappy relying on a shelf life of 10-15 years for a
> critical application, e.g. where loss of battery power would make a
> product *permanently* (i.e. even if the battery is replaced)
> non-functional. All you need is a bad batch of cells and maybe 5 years
> later you get a whole lot of extremely unhappy customers...
>
> Peter.
> --

& of course when those p****d off customers try to contact the supplier
who knows what they'll find - out of business, taken over several times,
``I'm sorry that product is discontinued since all the people who
understood it have left'', ``did we make that ?!'', ...



Article: 28951
Subject: Re: Advice on FPGA board.
From: pratipm@hotmail.com (Pratip Mukherjee)
Date: Wed, 31 Jan 2001 00:47:16 GMT
Links: << >>  << T >>  << A >>
They all change their URL's daily, God knows why. Looks like today they
are at http://www.celoxica.com/products/boards/RC1000_ds_final.pdf

In article <9573ku$igl$1@nnrp1.deja.com>, erika_uk@my-deja.com wrote:
>the link is broken!!
>In article <ah6c6.14773$t3.3374499@typhoon.ne.mediaone.net>,
>  pratipm@hotmail.com (Pratip Mukherjee) wrote:
>> A near fit would be
>http://technology.celoxica.com/boards/boards_001.asp
>>
>> In article <94qcnq$d46$1@nnrp1.deja.com>, jimmy75@my-deja.com wrote:
>> >
>> >> None of our boards will fit this particular application.  A board
>> >> with a PCI bus interace is needed for the high-speed transfers
>> >> between the FPGA board memory and the PC running the desktop
>> >> publishing app.  All our boards interface through the
>> >> parallel port which is too slow for this type of application.
>> >
>> >Yep. We need a PCI board for our purpose preferably with a DMA
>> >controller and a Xilinx Virtex chip(s) and lots of memory. If only we
>> >could make one on our own!
>> >I had a look on the web and didn't find all these features altogether
>> >in one board. We were hoping that somebody out there could help us.
>> >
>> >-- Jim
>> >
>> >
>> >Sent via Deja.com
>> >http://www.deja.com/
>>
>
>
>Sent via Deja.com
>http://www.deja.com/

Article: 28952
Subject: Re: FPGA to ASIC conversion
From: ed <ed@chester.net>
Date: Wed, 31 Jan 2001 01:07:30 GMT
Links: << >>  << T >>  << A >>
> First of let me ask you why you are trying to convert the gate level
> netlist. It would be much easier to convert the RTL. Assuming that you
> really want to do the gate level conversion, you have to make models
> of all the cells in the netlist. Put them in a library file and
> include it in your synthesis script. It can be a tedious and error
> prone process.

agree. but generally unless you happen to have your own waferfab kicking
about you're going to need process docs, techfiles, and pref. semi-custom
libraries from your silicon vendor. IMHO, you need to forget everything in
your fpga implementation and start again with sim and synthesis based on
the vendor library. if for some bizarre reason you actually want to keep a
1-to-1 gate level correspondance, then yes, you need to make your own
library, but base it on a verified vendor library. Library development is a
lot of work. Even coding styles for FPGA and ASIC implementation can be
different at RTL level. FPGA are constrained, in ASIC you would like your
synthesis tool to optimise against some cost function which is relatively
continuous in comparison to the corresponding cost function in the FPGA.
restraining an ASIC design doesn't make much sense.

enjoy :)

ed chester





Article: 28953
Subject: Help Please
From: "Amy Vaughn" <amy@stingraysys.com>
Date: Wed, 31 Jan 2001 01:58:57 GMT
Links: << >>  << T >>  << A >>
Does anyone know of any ASIC of FPGA design engineers in the Bay Area that
are looking for new career opportunities?  I am representing a few great
companies that are in need of these engineers, and I am having a tough time
finding any.  Any referrals that anyone can send will be a great help, and I
am in a position to pay a referral fee.  If you know of anyone, please email
me at amy@stingraysys.com

Thanks!!!!!!!



Article: 28954
Subject: Re: Advice on FPGA board.
From: "Simon Bacon" <simonb@tile.demon.co.cuthis.uk.>
Date: Wed, 31 Jan 2001 02:03:37 -0000
Links: << >>  << T >>  << A >>

"Pratip Mukherjee" <pratipm@hotmail.com> wrote in message
news:ogJd6.29493$t3.5470101@typhoon.ne.mediaone.net...
> They all change their URL's daily, God knows why. Looks like today
they
> are at http://www.celoxica.com/products/boards/RC1000_ds_final.pdf

And the company name?  Are they the old Handel-C people?  Celoxica
sounds
like an ointment for a social problem.






Article: 28955
Subject: Virtex Engineering Samples timing problem
From: Allan Herriman <allan_herriman.hates.spam@agilent.com>
Date: Wed, 31 Jan 2001 13:06:54 +1100
Links: << >>  << T >>  << A >>
Hi,

We have a whole bunch of old boards with Virtex-E parts on them.  The
problem is that the Virtex-E parts are engineering samples, and the
newer speed files (we're using ver 1.48) produce non-functional designs.

I'm fairly sure it's a speed file issue.  I need the design to work with
a clock period of 'T' ns.
Trce says the design should work with a 0.941 * T clock period.  I.e.
there should be a comfortable margin.

At room temperature, I need to increase the clock period to 1.03 * T for
the errors to go away.  With a short burst of freeze spray, I can get it
to work with a clock period of T.
The same design in newer silicon on an otherwise identical board works
ok over the full temperature range.

The question is: what should be done with the old boards?

Is it possible to obtain speed files that match the ES parts?

Is it possible to change the timespecs to compensate for the changed
silicon?
For example, if we know that the ES silicon is slow in one particular
area (perhaps shift register clock to output delay) we can put a tighter
constraint on the affected paths.

Other solutions involve scrapping the boards, or trying to change large
BGAs, both of which I'd like to avoid if there's a simpler or cheaper
way.

TIA,
Allan.
-- 
Allan Herriman      mailto:allan_herriman.hates.spam@agilent.com
Agilent Technologies          Voice:  +61 3 9210 5527
Advanced Networks Division    Fax:    +61 3 9210 5550
347 Burwood Highway  Forest Hill 3131 Australia

Article: 28956
Subject: CORDI C PROCESSOR!
From: Saqib <saqib_03@hotmail.com>
Date: Wed, 31 Jan 2001 06:11:27 GMT
Links: << >>  << T >>  << A >>


Hello!

With reference to Mr. Ray Andraka's paper : " A survey of CORDIC
algorithms for FPGA based computers": I would like to put forward these
questions :

1) In the "arcsin" computation, there is always a negative sign with
the result. e.g. we get -30 deg. instead of +30 deg. for c=0.5,
Xo=1/An. ?  The equation    Zn= Zo + arcsin(c/AnXo)  suggests +30. deg
if we initialize Zo=0; why?

2)In the linear mode (m=0) what is the factor that limits the correct
results? We get correct results only when the results of multiplication
(XoZo) and division (Yo/Xo) are expected to be less than or equal to 2?
is it so?

Also in linear VECTORING mode, the  equation  Zn= Zo - Yo/Xo is not
satisfied? Results seem to be according to the equation    Zn= Zo +
Yo/Xo       ( a PLUS sign)...


3) And last but not the least, the fixed point issue. Since we have to
perform addition/subtraction operations in the algorithm, so the binary
point (for fixed point) must be aligned in all three CORDIC equations.
Now since all the e_i 's are pre-stored constants, so doesn't it force
the user to represent X,Y,Z,C all in the same fixed point format as the
e_i 's? And if so, then is it possible to build a  general CORDIC
processor  in which the format of inputs X,Y,Z,C  may not match that of
e_i 's? Please if a detailed answer is possible?


Thanks.

--
--saqib yaqub--


Sent via Deja.com
http://www.deja.com/

Article: 28957
Subject: Re: Xilinx JEDEC files to SVF format
From: Mikko <mheikker@cc.hut.fi>
Date: 31 Jan 2001 07:46:28 GMT
Links: << >>  << T >>  << A >>
I discovered that the file generation has to be done in this order:
First set the JTAG components on a chain similar to how they are arranged on
the board. Then generate the .svf file. After that choose the operation to
be performed and execute it, and JTAG Programmer adds the information to the
svf file generated before. Then the file is ready to be programmed.

Mikko Heikkerö
mheikker@cc.hut.fi
-- 

Article: 28958
Subject: Re: Virtex Engineering Samples timing problem
From: Philip Freidin <philip@fliptronics.com>
Date: Wed, 31 Jan 2001 02:33:35 -0800
Links: << >>  << T >>  << A >>
So it looks like you are really close (1.03 x T => off by 3%),
but that is at room temp. At hot, or low VCC, you may be
off by more than 3%.

So what you didn't say is which speed grade you are telling
the PAR program.

So here is a suggestion. Re-run PAR and tell it the speed
grade is 1 grade slower than the speed you have been
telling it currently. i.e

current    rescue
speed      speed

-8         -7
-7         -6
-6         dont know. no slower speed grade, you are hosed.

(or maybe for -6, you rewrite all the time specs to be
10% tighter than they are currently)

typically there is about 10% to 15% difference in the
performance of the chips for adjacent speed grades.
Set the placer and router to maximum effort (5) and run
several delay-cleanup passes (maybe 5). If you can get
this to not have problems with TRCE, you are probably
going to be fine. If TRCE shows only a few paths with
trouble, maybe you can make design changes (add
pipelining, split heavily loaded nets, floorplanning, ....)
to get this to meet timing.

Good luck

Philip Freidin




On Wed, 31 Jan 2001 13:06:54 +1100, Allan Herriman
<allan_herriman.hates.spam@agilent.com> wrote:

>Hi,
>
>We have a whole bunch of old boards with Virtex-E parts on them.  The
>problem is that the Virtex-E parts are engineering samples, and the
>newer speed files (we're using ver 1.48) produce non-functional designs.
>
>I'm fairly sure it's a speed file issue.  I need the design to work with
>a clock period of 'T' ns.
>Trce says the design should work with a 0.941 * T clock period.  I.e.
>there should be a comfortable margin.
>
>At room temperature, I need to increase the clock period to 1.03 * T for
>the errors to go away.  With a short burst of freeze spray, I can get it
>to work with a clock period of T.
>The same design in newer silicon on an otherwise identical board works
>ok over the full temperature range.
>
>The question is: what should be done with the old boards?

Try above. May save a bundle of boards.

>Is it possible to obtain speed files that match the ES parts?

Probably not.

>Is it possible to change the timespecs to compensate for the changed
>silicon?

Yep. Recomended above as one possible solution.

>For example, if we know that the ES silicon is slow in one particular
>area (perhaps shift register clock to output delay) we can put a tighter
>constraint on the affected paths.

Yep.

>Other solutions involve scrapping the boards, or trying to change large
>BGAs, both of which I'd like to avoid if there's a simpler or cheaper
>way.

The above should be tried first, as the investment and effort are small.

Note above, that you could also try load splitting and pipelining and
floor planning to improve the situation.

>TIA,
>Allan.

Philip Freidin
Fliptronics

Article: 28959
Subject: XILINX FPGA programming through JTAG
From: luca.haab@ascom.ch
Date: Wed, 31 Jan 2001 12:54:38 GMT
Links: << >>  << T >>  << A >>
Hi all!

We are developing an embedded system that includes a JTAG chain with
programmable configuration PROMs (XILINX XC18V00) and FPGAs  (Virtex-E
600/400/200) controlled through a Motorola mP (PowerQUICC II). This has
been designed in order to have the possibility to download the FPGA
programs directly through mP.
The question is: how can I write to the ROMs through JTAG (XILINX
XC18V00 offers only basic commands)? Does an
application note exist? If not, has someone experience with this topic?

Many thanks
Luca Haab

------------------------------------------------------------------------
Luca Haab
Software Engineer
BroadNet Division
Ascom Transmission Ltd
Schwarzenburgstrasse 73
CH-3097 Berne

Tel:+41 31 999 3341
Fax:+41 31 999 3057

mailto:luca.haab@ascom.ch


Sent via Deja.com
http://www.deja.com/

Article: 28960
Subject: Re: Advice on FPGA board.
From: Jamie Lokier <spamfilter.jan2001@tantalophile.demon.co.uk>
Date: 31 Jan 2001 14:05:41 +0100
Links: << >>  << T >>  << A >>
Simon Bacon writes:
> And the company name?  Are they the old Handel-C people?

Yes, they used to be Embedded Solutions and they still do Handel-C.
The name change seems to have coincided with the introduction of
Handel-C version 3.

> Celoxica sounds like an ointment for a social problem.

That's what we at CERN think too :-)

-- Jamie






Article: 28961
Subject: Xilinx fast carry counter question
From: "Dan K" <dan_kuechle@i-tech.com>
Date: Wed, 31 Jan 2001 07:50:13 -0600
Links: << >>  << T >>  << A >>
I want to build a single cycle micro-programmable "processor" using
the Virtex / Virtex2 block ram for the instruction memory.  This
RAM is synchronous, but could still be used in a single cycle machine
if I could use the D-inputs of the flip flops of the address counter to
address the
block RAM.  I would also need to get at the address counter's Q outputs
(or just register these D-inputs).

My "gate level" counter runs too slow (goal is a 9.4 ns instruction cycle).
I've tried an adder, but get way more logic than I need (so its too slow
also).
Does anyone know if I can get at the D-inputs to the FF's in a fast carry
loadable counter like a CC16CLE?
Or maybe I need a different kind of counter?  It wouldn't HAVE to be binary
(although binary would sure be easier).

Thanks

Dan



Article: 28962
Subject: Re: Spartan 2 DLL
From: felix_bertram@my-deja.com
Date: Wed, 31 Jan 2001 14:19:59 GMT
Links: << >>  << T >>  << A >>
Hi Falk,

In article <3A76CA05.615EEC8B@gmx.de>,
  Falk Brunner <Falk.Brunner@gmx.de> wrote:
> I just played around with a Spartan 2 demo board. One nice feature of
> Spartan2 / Virtex is the DLL, which can create 4 clock phases and even
> double the input clock. Unfortunately, the minimum input frequency is
25

there has been a thread on this issue two weeks ago, I tried to gather
information on driving a DLL with 24MHz. I ended up combining a
combinational clock doubler with a DLL.

In the following you'll find the code that I am using- which works fine
with my application.

Hope this helps,
best regards

Best regards

Felix Bertram
_____
Dipl.-Ing. Felix Bertram
Trenz Electronic
Duenner Kirchweg 77
D - 32257 Buende
Tel.: +49 (0) 5223 41652
Fax.: +49 (0) 5223 48945
Mailto:felix.bertram@trenz-electronic.de
http://www.trenz-electronic.de

---------------------------------------------------------------------
library IEEE;
use IEEE.std_logic_1164.all;
use work.CfgPak.all;

entity Clk4x is
    port(
        clk24 : in std_ulogic;
        dllrst : in std_ulogic;
        reset : in std_ulogic;
        clk96 : out std_ulogic
        );
end Clk4x;

architecture BHV of Clk4x is

    component bufg
        port (
            I : in std_ulogic;
            O : out std_ulogic
            );
    end component;
    component clkdll
        port (
            CLKFB : in std_ulogic := '0';
            CLKIN : in std_ulogic := '0';
            RST : in std_ulogic := '0';
            CLK0 : out std_ulogic := '0';
            CLK180 : out std_ulogic := '0';
            CLK270 : out std_ulogic := '0';
            CLK2X : out std_ulogic := '0';
            CLK90 : out std_ulogic := '0';
            CLKDV : out std_ulogic := '0';
            LOCKED : out std_ulogic := '0'
            );
    end component;
    component FDC
        port (
            C : in std_ulogic;
            CLR : in std_ulogic;
            D : in std_ulogic;
            Q : out std_ulogic
            );
    end component;
    component inv
        port (
            I : in std_ulogic;
            O : out std_ulogic
            );
    end component;
    component srl16
        port (
            A0 : in std_ulogic;
            A1 : in std_ulogic;
            A2 : in std_ulogic;
            A3 : in std_ulogic;
            CLK : in std_ulogic;
            D : in std_ulogic;
            Q : out std_ulogic
            );
    end component;
    component xor2
        port (
            I0 : in std_ulogic;
            I1 : in std_ulogic;
            O : out std_ulogic
            );
    end component;

    attribute dont_touch: STRING;

    constant VCC_CONSTANT   : STD_LOGIC := '1';

    signal clk48 : std_ulogic;
    signal iii_clk96 : std_ulogic;
    signal ii_clk96 : std_ulogic;
    signal q : std_ulogic;
    signal qinv : std_ulogic;
    signal NET8262 : std_ulogic;
    signal NET8887 : std_ulogic;
    signal VCC : STD_LOGIC;

    attribute dont_touch of Uff : label is "true";
    attribute dont_touch of Uinv1 : label is "true";
    attribute dont_touch of Uxor : label is "true";

begin

    Ubuf : bufg
    port map(
        I => ii_clk96,
        O => iii_clk96
        );

    Udll : clkdll
    port map(
        CLK2X => ii_clk96,
        CLKFB => iii_clk96,
        CLKIN => clk48,
        RST => NET8887
        );

    Uff : FDC
    port map(
        C => clk48,
        CLR => reset,
        D => qinv,
        Q => q
        );

    Uinv1 : inv
    port map(
        I => q,
        O => qinv
        );

    Uinv2 : inv
    port map(
        I => NET8262,
        O => NET8887
        );

    Usr : srl16
    port map(
        A0 => VCC,
        A1 => VCC,
        A2 => VCC,
        A3 => VCC,
        CLK => clk48,
        D => dllrst,
        Q => NET8262
        );

    Uxor : xor2
    port map(
        I0 => clk24,
        I1 => qinv,
        O => clk48
        );

    VCC <= VCC_CONSTANT;
    clk96 <= iii_clk96;

end BHV;
---------------------------------------------------------------------
-- end of file


Sent via Deja.com
http://www.deja.com/

Article: 28963
Subject: Re: CORDI C PROCESSOR!
From: Ray Andraka <ray@andraka.com>
Date: Wed, 31 Jan 2001 15:46:28 GMT
Links: << >>  << T >>  << A >>


Saqib wrote:
> 
> Hello!
> 
> With reference to Mr. Ray Andraka's paper : " A survey of CORDIC
> algorithms for FPGA based computers": I would like to put forward these
> questions :
> 
> 1) In the "arcsin" computation, there is always a negative sign with
> the result. e.g. we get -30 deg. instead of +30 deg. for c=0.5,
> Xo=1/An. ?  The equation    Zn= Zo + arcsin(c/AnXo)  suggests +30. deg
> if we initialize Zo=0; why?

I think I got the sign of decision variable backwards in the z equation.  I
think it should be Zi+1=Zi + di atan(2^-i).

> 
> 2)In the linear mode (m=0) what is the factor that limits the correct
> results? We get correct results only when the results of multiplication
> (XoZo) and division (Yo/Xo) are expected to be less than or equal to 2?
> is it so?

Depends on where your radix point is.  It sounds like you are getting overflow. 
If you are using fractional fixed point notation, then your statement is
correct.

> 
> Also in linear VECTORING mode, the  equation  Zn= Zo - Yo/Xo is not
> satisfied? Results seem to be according to the equation    Zn= Zo +
> Yo/Xo       ( a PLUS sign)...

That is correct.  I got the signs wrong in a couple of the equations.

> 
> 3) And last but not the least, the fixed point issue. Since we have to
> perform addition/subtraction operations in the algorithm, so the binary
> point (for fixed point) must be aligned in all three CORDIC equations.
> Now since all the e_i 's are pre-stored constants, so doesn't it force
> the user to represent X,Y,Z,C all in the same fixed point format as the
> e_i 's? And if so, then is it possible to build a  general CORDIC
> processor  in which the format of inputs X,Y,Z,C  may not match that of
> e_i 's? Please if a detailed answer is possible?

As you sort of noted, CORDIC really is not well suited for floating point
implementation because the data's radix points have to align for each
add/subtract operation.  The radix point must have the same alignment for the x
and y elements because of the crossover connections.  The z element can have a
different radix point alignment because the only interaction between the z
(phase accumulator) element and the rotator is via the decision variable.  As a
result, z the units of z can be arbitrarily assigned.  Since C is a comparison
(we're talking about the Arcsin here) with the Y rotator element, it also must
have the same weighting as the x andy elements.

If floating point must be handled, then you should first normalize the x and y
inputs so that they share a common exponent and so the larger of the two is
normalized.  Then perform a fixed point rotation, carrying the exponent around
the rotator.  

> 
> Thanks.
> 
> --
> --saqib yaqub--
> 
> Sent via Deja.com
> http://www.deja.com/

-- 
-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  or http://www.fpga-guru.com

Article: 28964
Subject: Re: Standard Deviation Moving Window
From: Ray Andraka <ray@andraka.com>
Date: Wed, 31 Jan 2001 15:49:58 GMT
Links: << >>  << T >>  << A >>


javidiaz@my-deja.com wrote:
> 
> Hi, I am student from Puerto Rico:
> 
> We are trying to figure out how to implement an algorith that takes a
> 9*9 matrix (8 bits each element)and do a windowing of 5*5 in a column-
> wise and row-wise sliding and calculate for each 5*5 Moving-Window the
> Standard Deviation.
> Questions:
> 1. How do I handle the Squared Root of the SD?

Depends on the device and yoru required precision. 

> 2. And Which is better to implement on Xilinx XC4036 a floating-point
> or a fix-point approach for the results (another 9x9 matrix)?

Use fixed point if you can.  

> 3. I need to do a storage of those results: How do I configure the RAM
> resources for float-P or Fix-point?

NOt sure I understand the question.  The ram just stores a bit pattern.  How you
define the bits is up to you.  for floating point, some of the bits represent
the position of the radix point, where fixed point has an implied fixed location
of the radix point. 

> 4. Can you provide me good web resources to understand how to implement
> floating/fix point on FPGA?
> 
> I hope to have some feedback on this regard,
> 
> Javier
> 
> Sent via Deja.com
> http://www.deja.com/

-- 
-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  or http://www.fpga-guru.com

Article: 28965
Subject: Re: Xilinx fast carry counter question
From: Ray Andraka <ray@andraka.com>
Date: Wed, 31 Jan 2001 16:25:34 GMT
Links: << >>  << T >>  << A >>
You can, but not for a logicore/coregen counter.  You have to roll your own to
get at the D inputs.  You may be dissappointed with the performance however. 
The Block Ram is one of the slowest elements in the FPGA: it has a relatively
long setup time.    Additionally, you wind up with possibly long routes to
connect to it from your logic.  In your case, you are driving the addresses
directly out of a carry chain, which is typically the critical path in a design,
so you are combining all the worst case paths into a single combinatorial run.  

You'll want to keep the loadable counter logic to one level.  (I think the
CCxxCLE is two levels of logic).  It can be done, but requires some clever
coding.  The load mux comes before the carry chain in that case, so load has to
disable the carry using the MULT_ANDs.  I have not found a coding style that
reliably infers the correct structure.  You may have to instantiate the
primitives to get the desires structure.  Also, the load control will be a
critical path as it has a high fanout and feeds through the carry chain to the
BRAM address, so you will need to duplicate it, and put the duplicated registers
immediately adjacent to the carry chain to keep the speed up.

Dan K wrote:
> 
> I want to build a single cycle micro-programmable "processor" using
> the Virtex / Virtex2 block ram for the instruction memory.  This
> RAM is synchronous, but could still be used in a single cycle machine
> if I could use the D-inputs of the flip flops of the address counter to
> address the
> block RAM.  I would also need to get at the address counter's Q outputs
> (or just register these D-inputs).
> 
> My "gate level" counter runs too slow (goal is a 9.4 ns instruction cycle).
> I've tried an adder, but get way more logic than I need (so its too slow
> also).
> Does anyone know if I can get at the D-inputs to the FF's in a fast carry
> loadable counter like a CC16CLE?
> Or maybe I need a different kind of counter?  It wouldn't HAVE to be binary
> (although binary would sure be easier).
> 
> Thanks
> 
> Dan

-- 
-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  or http://www.fpga-guru.com

Article: 28966
Subject: Re: Xilinx fast carry counter question
From: "Jan Gray" <jsgray@acm.org>
Date: Wed, 31 Jan 2001 16:48:42 GMT
Links: << >>  << T >>  << A >>
Dan, you may find the paper for my DesignCon'2001 talk (which I am
presenting later today) helpful.  It provides the annotated Verilog source
code for a simple, compact, non-pipelined 16-bit RISC CPU and
system-on-a-chip.  It uses the same PC incrementer -> BRAM topology you
describe in your question.

The paper is at http://www.fpgacpu.org/soc-gr0040-001201.pdf.

If you have branch or jump-and-link instructions, which can modify the next
PC value, it is challenging to execute a single instruction in less than 10
ns without pipelining.

In a slow speed Virtex device, the clock-to-out on the BRAM is about 4 ns.
Then (minimum) you have to route the instruction's branch displacement field
to the PC branch adder, then branch adder latency, a few ns, then perhaps a
mux, then back to the BRAM address inputs and the BRAM address setup time of
1 ns or so.

If you put in an 'instruction register' pipeline stage to simply absorb the
BRAM clock-to-out delay and routing delay, you get a much better chance to
hit sub 10 ns.

> My "gate level" counter runs too slow (goal is a 9.4 ns instruction
cycle).
> I've tried an adder, but get way more logic than I need (so its too slow
> also).

For a loadable binary counter, at a minimum you need one LUT + carry logic
per bit.  See the detailed discussion at
http://www.fpgacpu.org/log/nov00.html#001112.

The last time I looked, the loadable binary counter CC16CLE unnecessarily
used two LUTs per bit.  Xilinx should fix that.  A straight adder should
also only need one LUT per bit.

> Does anyone know if I can get at the D-inputs to the FF's in a fast carry
> loadable counter like a CC16CLE?

If you use the library symbol CC16CLE you can't get at those inputs.  If you
build one yourself, you certainly can.  If you have a schematic editor, I
encourage you to 'open up' the CC16CLE library symbol and see what's going
on under the hood.

Have fun.

Jan Gray, Gray Research LLC
FPGA CPU News: www.fpgacpu.org




Article: 28967
Subject: Re: XILINX FPGA programming through JTAG
From: "Jaan Sirp" <jaan.sirp@mail.ee>
Date: Wed, 31 Jan 2001 08:52:30 -0800
Links: << >>  << T >>  << A >>
Hi Luca,

We had similar problem. I asked Xilinx, but got no solution. So we had to hack it ourselves using Parallel Cable III and logic analyzer. BSDL file of the XC1800 is needed also. For programming we use .mcs (HEX format) data file.
First you have to send FERASE instruction, then ISPEN instruction. Programming proceed using FARRD and FPGM instructions. It is complicated enough, different for small PROMs (up to XC1801) and bigger ones.
We made a small document, describing XC1800 programming, but it is in Estonian.

Jaan Sirp,
<BR>Casual  

>We are developing an embedded system that includes a JTAG chain with
>programmable configuration PROMs (XILINX XC18V00) and FPGAs (Virtex-E
>600/400/200) controlled through a Motorola mP (PowerQUICC II). This has
>been designed in order to have the possibility to download the FPGA
>programs directly through mP.
>The question is: how can I write to the ROMs through JTAG (XILINX
>XC18V00 offers only basic commands)? Does an
>application note exist? If not, has someone experience with this topic?
>
>
>Many thanks
>Luca Haab
>
>
>------------------------------------------------------------------------
>Luca Haab
>Software Engineer
>BroadNet Division
>Ascom Transmission Ltd
>Schwarzenburgstrasse 73
>CH-3097 Berne

Article: 28968
Subject: FPGA'2001 Pre-registration deadline
From: tessier@spock.ecs.umass.edu (Russell Tessier)
Date: 31 Jan 2001 17:16:21 GMT
Links: << >>  << T >>  << A >>
Dear Colleagues,

The off-site, pre-registration deadline for FPGA'01 is Friday, February
2. After this deadline all conference registration will take place at
the conference site. I hope you will join us for this exciting event. 

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

FPGA 2001
2001 ACM/SIGDA Ninth International Symposium on Field Programmable Gate Arrays

Doubletree Hotel, Monterey, California
February 11-13, 2001

http://www.ecs.umass.edu/ece/fpga2001

Sponsored by ACM/SIGDA
with support from Altera, Xilinx, Agere Systems, Cypress and Actel 
 
 
Join us for the ninth ACM/SIGDA International Symposium on Field Programmable 
Gate Arrays (FPGA 2001), the premier forum for novel work in all areas related 
to FPGA technology. This year's symposium features twenty-four papers and 
twenty-three poster presentations describing cutting-edge FPGA research. 
Authors from universities, research laboratories and commercial vendors 
present new work on topics ranging from applications and reconfigurable 
computing to device architecture and design tools. An entire session is 
devoted to applications in image and video compression. Paper sessions are 
separated by ample time to peruse the poster presentations and discuss the 
latest FPGA news.

The panel this year addresses the question of what FPGAs will look like in 
the era of systems-on-a-chip. Is it now clear that programmable logic should 
be combined with ASICs and microprocessors? How should they be combined? What 
tools are needed to support these devices? 

FPGA 2001 provides a relaxed atmosphere for informal information exchange, 
networking and stimulating discussions with the leaders in FPGA research 
and development from industry and academia as well as the next generation 
of FPGA researchers

If you are at all interested in FPGA technology and developments, you won't 
want to miss this event. 
 







Article: 28969
Subject: vector / edif format / LeonardoSpectrum
From: Laurent Gauch <laurent.gauch@amontec.com>
Date: Wed, 31 Jan 2001 18:23:49 +0100
Links: << >>  << T >>  << A >>
Hi all,

I have actually a problem to reuse a .edf file generated by 
LeonardoSpectrum in the Design manager of Foundation.

When I look my report file generated by Foundation, I can see the 
following lines:
----------------------
Annotating constraints to design from file "concatened.ucf" ...
ERROR:NgdBuild:397 - Could not find NET 'mini_ezx_pin(3)' in design
    'interface'.  NET entry is 'NET mini_ezx_pin(3)   LOC = P42 ;
    '
ERROR:NgdBuild:397 - Could not find NET 'mini_ezx_pin(2)' in design
    'interface'.  NET entry is 'NET mini_ezx_pin(2)   LOC = P41 ;
    '
ERROR:NgdBuild:397 - Could not find NET 'mini_ezx_pin(1)' in design
    'interface'.  NET entry is 'NET mini_ezx_pin(1)   LOC = P40 ;
    '
ERROR:NgdBuild:397 - Could not find NET 'mini_ezx_pin(0)' in design
    'interface'.  NET entry is 'NET mini_ezx_pin(0)   LOC = P39 ;
----------------------


Now, If I edit my .edf file to find 'mini_ezx_pin(3)' port, I can see 
the lines :
----------------------
      (port (rename p0 "mini_ezx_pin(3)") (direction INPUT))
      (port (rename p1 "mini_ezx_pin(2)") (direction INPUT))
      (port (rename p2 "mini_ezx_pin(1)") (direction INPUT))
      (port (rename p3 "mini_ezx_pin(0)") (direction INPUT))


I do not understand why LeonardoSpectrum rename all my vectors when I 
generate my output .edf file ???

Also, working with Virtex and Virtex-E, what is the better format to use 
between EDIF and XNF.

Thank you in advance.

Regards
Laurent
for Amontec (www.amontec.com)



Article: 28970
Subject: 64b/66b gearbox in an FPGA
From: mccarley <mccarley@austin.rr.com>
Date: Wed, 31 Jan 2001 13:51:42 -0500
Links: << >>  << T >>  << A >>
Hi all,

I have this 'gearbox' coded up in Verilog and it is large
and not quite fast enough when implemented in an FPGA.

The 'gearbox' function is straight forward: 64 bit data
bus input at 200 MHz needs to output a 66 bit data bus at
206.25 MHz. Same bandwidth. The clock rate conversion
isn't a problem (I'm using 2 clocks), but the data width
conversion is getting big and sluggish on me.

The way I have coded it up is a 33 modulo counter and a
case statement (MUXes) with the condition the counter
value at which the data is shifted into the output
register (after prefill). Like:

    case(cnt33) /*synthesis parallel_case*/
      6'd0:  {gearbox_reg[189:0]} <= #1 {datain_64b,
gearbox_reg[191:66]};
      6'd1:  {gearbox_reg[187:0]} <= #1 {datain_64b,
gearbox_reg[189:66]};
.
.
.
      6'd30: {gearbox_reg[129:0]} <= #1 {datain_64b,
gearbox_reg[131:66]};
      6'd31: {gearbox_reg[127:0]} <= #1 {datain_64b,
gearbox_reg[129:66]};
      default: gearbox_reg[191:128] <= #1 datain_64b;
    endcase

I also pipelined this by using an modulo 4 counter nested
in a modulo 8 counter and a temporary register stage. I
got quite a bit more speed then, but the area (# of FPGA
logic blocks)  is getting too large.

I also tried to do this function with memory and address
and data pointers, but it became a mess that didn't work
well with the block memories in the FPGA.

So, my question is: does anyone have any ideas or
suggestions on a better way to accomplish this 'gearbox'
function?



Article: 28971
Subject: Re: Xilinx fast carry counter question
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 31 Jan 2001 11:02:28 -0800
Links: << >>  << T >>  << A >>
Here is some additional information, fresh from the Virtex-II handbook and the
newest speeds files:

Ray Andraka wrote:

> You can, but not for a logicore/coregen counter.  You have to roll your own to
> get at the D inputs.

The D-inputs are brought out on the Y outputs of the CLB, whether you like it or
not ( you would like it ). Same in Virtex-II.


> You may be dissappointed with the performance however.
> The Block Ram is one of the slowest elements in the FPGA: it has a relatively
> long setup time.

In Virtex the set-up time to address and data inputs is 1.2 to 1.5 ns
In Virtex-E the set-up time to address and data inputs is 1.0 to 1.1 ns
In Virtex-II the set-up time to address and data inputs is 0.30 to 0.35 ns

but since the address decoders and the whole RAM array is "behind" the input
flip-flops, the clock-to-out is a relatively long 2.6 to 2.9 ns, even in Virtex-II.

So it's not ( or no longer ) a set-up-time problem...

Peter Alfke, Xilinx Applications

>


Article: 28972
Subject: Re: Spartan 2 DLL
From: "Simon Bacon" <simonb@tile.demon.co.cuthis.uk.>
Date: Wed, 31 Jan 2001 19:33:32 -0000
Links: << >>  << T >>  << A >>
A clock doubler chip from ICS may be simpler for most people.
And it would be small and cheap.

Falk Brunner <Falk.Brunner@gmx.de> wrote:
> I just played around with a Spartan 2 demo board. One nice feature of
> Spartan2 / Virtex is the DLL, which can create 4 clock phases and even
> double the input clock. Unfortunately, the minimum input frequency is
> 25




Article: 28973
Subject: Re: vector / edif format / LeonardoSpectrum
From: "Simon Bacon" <simonb@tile.demon.co.cuthis.uk.>
Date: Wed, 31 Jan 2001 19:42:17 -0000
Links: << >>  << T >>  << A >>
Leonardo did it because it does not know for sure which characters
will be reserved/illegal in the estimation of the downstream tools.
If you are confident, you can write a small PERL script to
unrename the ports.

The strings in EDIF2NGD seem to indicate that Xilinx implements a
pretty full EDIF grammar - legal EDIF should be OK to Xilinx, though
AFAIK they have never published anything on this.

Try a simple case.  Manually edit one of the renames and see how the
tools respond.

"Laurent Gauch" <laurent.gauch@amontec.com> wrote in message
news:3A784A25.8000303@amontec.com...
> Now, If I edit my .edf file to find 'mini_ezx_pin(3)' port, I can see
> the lines :
> ----------------------
>       (port (rename p0 "mini_ezx_pin(3)") (direction INPUT))
>       (port (rename p1 "mini_ezx_pin(2)") (direction INPUT))
>       (port (rename p2 "mini_ezx_pin(1)") (direction INPUT))
>       (port (rename p3 "mini_ezx_pin(0)") (direction INPUT))
>
>
> I do not understand why LeonardoSpectrum rename all my vectors when I
> generate my output .edf file ???
>
> Also, working with Virtex and Virtex-E, what is the better format to
use
> between EDIF and XNF.

EDIF.  XNF is under a death sentence, though the appeal process is
being dragged out.






Article: 28974
Subject: Re: Xilinx fast carry counter question
From: Ray Andraka <ray@andraka.com>
Date: Wed, 31 Jan 2001 19:56:31 GMT
Links: << >>  << T >>  << A >>
No, it is just not an obvious implementation.  The load control is the critical
path on the one layer of logic implementation, so in terms of performance you
need to either duplicate the load a bunch or go to two levels.  The limitation
is the fact that the LUT logic precedes the carry chain, so if it is described
in the conventional manner in VHDL using an IF construct, you end up with a mux
after the carry, and therefore two levels of logic.

Ben Franchuk wrote:
> 
> Jan Gray wrote:
> 
> > The last time I looked, the loadable binary counter CC16CLE unnecessarily
> > used two LUTs per bit.  Xilinx should fix that.  A straight adder should
> > also only need one LUT per bit.
> 
> There may be hidden buffering or Hardware dependent limitations on the carry
> chain is my guess.
> 
> --
> "We do not inherit our time on this planet from our parents...
>  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk

-- 
-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  or http://www.fpga-guru.com



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
2017JanFebMarApr2017

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