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 24175

Article: 24175
Subject: Re: FPGAExpress fe_shell and FSM encoding
From: Klaus Falser <kfalser@durst.it>
Date: Fri, 28 Jul 2000 14:46:40 GMT
Links: << >>  << T >>  << A >>
In article <39818074.325A095B@xess.com>,
  Dave Vanden Bout <devb@xess.com> wrote:
> Try this:
>
> proj_fsm_coding_style = "onehot"
>
> or
>
> proj_fsm_coding_style = "binary"
>
> We have a document on using makefiles with Foundation at
> http://www.xess.com/manuals/fndmake.pdf.
>
> Klaus Falser wrote:
>
> > Does anybody know how to force FPGA-Express to use binary encoding
from
> > command line mode?
> >
> > I'm using FPGA Express 3.3 and Xilinx Foundation F2.1.
> > From the GUI I can specify the encoding type (one hot, binary .. )
for
> > FSM's, but I have not found how to do this from the command line
tool
> > fe_shell.
> > This would be useful for me since I like to do the whole synthesis
> > process with makefiles.
> >
> > Every help is appreciated
> >    Klaus
> >
> > --
> > Klaus Falser
> > Durst Phototechnik AG
> > I-39042 Brixen
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> --
> || Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
> || devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
> || http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||
>
>

Thank you very much.
Could you please tell me where such information can be found?

Klaus
--
Klaus Falser
Durst Phototechnik AG
I-39042 Brixen


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24176
Subject: Foreign generated EDIF file in Foundation 2.1i
From: nospam_ees1ht@ee.surrey.ac.uk (Hans)
Date: 28 Jul 2000 14:56:30 GMT
Links: << >>  << T >>  << A >>
I wonder if anybody can help me with the following problem, I have a 
component synthesised by Synplicity 6.0 which I would like to use as a 
black box component in a Foundation 2.1i project. I instantiate this black 
box component (EDIF) in a VHDL top level entity which I then synthesis (or 
try too) with FPGA express. The black box is synthesised without I/O ( I/O 
insertion disabled). I assumed that the back box EDIF and FPGA generated 
EDIF file would simply be merged into 1 big EDIF file, this doesn't seem 
to be happening.

When I synthesis the top entity I get (FPGA-PADMAP-3) errors on the inout 
ports of the back box (all Out and In ports are OK).   Unfortunately 
Xilinx techdocs (http://support.xilinx.com/techdocs/3296.htm) did not 
provide me with a solution. There also seem to be some issue with the EDIF 
file bus notation as described in 
http://support.xilinx.com/techdocs/2649.htm, this also (adding the 
attribute to the Synplicity file) did not solve the problem. 

So my question is what steps are required to add a foreign generated EDIF 
file to a Foundation project?

Thanks,
Hans.

Article: 24177
Subject: Re: Pad trireg in XLA FPGA (beating a horse to death)
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 28 Jul 2000 10:57:21 -0400
Links: << >>  << T >>  << A >>
eml@riverside-machines.com.NOSPAM wrote:
> 
> On Thu, 27 Jul 2000 14:30:05 -0400, rickman <spamgoeshere4@yahoo.com>
> wrote:
> Even if the mapper could restructure existing logic, how far would it
> have to go? It might be reasonable to detect LUTs which only contain
> an inverter, and remove them. It might be reasonable to invert F/F
> data inputs and reset polarities. It might be reasonable to De
> Morgan-ise an entire logic function, if it turns out that a free
> inverter somewhere will save a few LUTs. However, this will cause
> other inversions, which will propagate backwards, and the synthesiser
> should have done all this work already. You have to draw the line
> somewhere.

Inverter elimination is exactly the type of stuff that it is supposed to
do. I was told way back when the 4K series was new that the software
would push an inverter in either direction into LUTs. I don't remember
it being able to cross a FF boundry while invertering the GSR action.
But at that time people seemed to be very aware of the waste of using a
CLB to implement an inverter. 

Remember that this was done at a time when synthesis was not available.
If you drew a block of gates on your schematic, the mapper had to figure
out the best method of getting this to fit CLBs rather than the gates
you had drawn. And engineers used every logic object in the book. 


-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24178
Subject: Re: FPGAExpress fe_shell and FSM encoding
From: Dave Vanden Bout <devb@xess.com>
Date: Fri, 28 Jul 2000 11:52:22 -0400
Links: << >>  << T >>  << A >>


Klaus Falser wrote:

>
> Thank you very much.
> Could you please tell me where such information can be found?
>

I find most of my information about FPGA Express by opening it directly
(not through Foundation).  It's under Start=>Programs=>Xilinx Foundation
Series 2.1i=>Accesories=>FPGA Express. Then use its help system to open
Help Topics=>Contents Tab=>FPGA Scripting Tool (FST).  There is an FST
Command Overview in there.

--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||


Article: 24179
Subject: Re: Question of Virtex DLL
From: Ben Sanchez <ben@seti.org>
Date: Fri, 28 Jul 2000 09:09:07 -0700
Links: << >>  << T >>  << A >>
Cool.  I was not aware that a BUFG could be driven by anything by
a clock pin or a DLL output.  That could be quite useful.

Sorry for the mis-information!

Ben

===========================================================
  Ben Sanchez                     Engineer, Lab Manager
  e-mail:  ben@phoenix.seti.org   Project Phoenix
                                  SETI Institute
  Web:     http://www.seti.org    2035 Landings Drive
                                  Mountain View, CA 94043
===========================================================


"K.Orthner" wrote:
> 
> "Ben Sanchez" <ben@seti.org> wrote:
> 
> > No.  It can only be driven by a global clock input buffer
> > (IBUFG), which can only be driven by a Global clock input pin
> > (there are 4 on a virtex, 8 on VirtexE).  If you want an internal
> > signal to drive a CLKDLL, you have to bring it out a pin and back
> > in a clock pin, but all that delay out and in probably defeats
> > the purpose of the DLL.
> 
> Referring to XAPP132,
> 
> If you use the CLKDLL primitive, you can source the input clockfrom a BUFG,
> but if you use the BUFGDLL primitive, than you must use an external pin.
> 
> This is copied from the XAPP132 application note, from the CLKDLL section:
> 
> CLKDLL Primitive Pin Descriptions
> The library CLKDLL primitives provide access to the complete set of DLL
> features needed
> when implementing more complex applications with the DLL.
> Source Clock Input - CLKIN
> The CLKIN pin provides the user source clock (the clock signal on which the
> DLL operates) to
> the DLL. The CLKIN frequency must fall in the ranges specified in the
> datasheet. The clock
> input signal can be provided by one of the following:
> . BUFG - Internal global clock buffer
> . IBUFG - Global clock input buffer on the same edge of the device (top or
> bottom)
> . IO_LVDS_DLL - the pin adjacent to a global clock pin.
> 
> ------------
> Kent Orthner
> korthner at hotmail dot com
Article: 24180
Subject: Re: LFSR as a divider
From: Ben Sanchez <ben@seti.org>
Date: Fri, 28 Jul 2000 09:21:25 -0700
Links: << >>  << T >>  << A >>
I was using a 14 bit counter.  I think the problem is somehow
related to the fact that I recently switched to the
LeonardoSpectrum synth tool, and I don't know how to use it.  It
is supposed to be much better than FPGA express that comes with
the ViewLogic tools, but in this case the results are dismal.

The 14bit counter run's at only 50-65MHz, while the rest of the
design can run a little above 160MHz.

In the mean time I implemented an LFSR in FFs with a pipelined
comparator to decode the all zero state. (three 4-input ANDs ->
register (pipeline the lsb of the 13 bit LFSR) -> 1 4 input AND
-> register -> output)

That run's fast.

In the future when the time pressure of this particular job is
off I want to figure out why these counters don't run fast when
synthesized with LS.

Ben

===========================================================
  Ben Sanchez                     Engineer, Lab Manager
  e-mail:  ben@phoenix.seti.org   Project Phoenix
                                  SETI Institute
  Web:     http://www.seti.org    2035 Landings Drive
                                  Mountain View, CA 94043
===========================================================


rickman wrote:
> 
> "K.Orthner" wrote:
> >
> > Assuming that you're not extremely short on space, you could buile a LFSRout
> > of regular FF's and logic blocks.  Because the logic for a LFSR is much
> > simpler that for a counter, it would still be able to run significantly
> > faster.
> >
> > The VHDL code would look something like this:
> >
> > process lfsr (rst, clk )
> > begin
> >   if rst = '1' then
> >       lfsr_reg <= '1' & (others => '0');
> >       -- Note: You have to reset the lfsr to non-zero.
> >
> >   elsif rising_edge( clk ) then
> >       lfsr_reg <=  (lfsr_reg(0) xor lfsr_reg(2) ) & lfsr_reg (lfsr_size-1
> > downto 1);
> >       -- Another note: This is going left-to-right.
> >
> >   end if;
> > end process;
> >
> > You can then just AND together all of the bits of lfsr_reg, which will give
> > you a pulse when the entire LFSR is '1'.  (The all-zero state will never
> > happen).
> 
> You were doing pretty well untill you suggested ANDing all the bits of
> the counter. If the standard fast carry counter is speed limited, then a
> 14 input AND gate will be the speed limiting logic. This would need to
> be pipelined and likely floorplanned.
> 
> Actually, I can't see how a 14 bit fast carry counter could be too slow
> for this application. The fast carries are very fast and with only 14
> bits are likely to be nearly as fast as the LFSR. How many bits were
> being used in the counter?
> 
> 
> > A length of 14 bits should give you a pulse once every 16383 clk cycles.
> >
> > -Kent
> >
> > P.S.  I haven't read the app note, so my implementation may look nothing at
> > all like Xilinx's.
> >
> > > I have looked into using the LFSR setup described in Xilinx's
> > > XAPP210 (By Maria George and Peter Alfke), and implementing it
> > > looks simple enough.  The problem is that I don't see how one
> > > gains access to all the bits in the LFSR.  I want to do something
> > > like let the thing free run and output a pulse every time it
> > > comes round to a particular state, say 0.
> > >
> > > Does anybody know how to do this?
> >
> > ------------
> > Kent Orthner
> 
> --
> 
> Rick Collins
> 
> rick.collins@XYarius.com
> 
> Ignore the reply address. To email me use the above address with the XY
> removed.
> 
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
> 
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
> 
> Internet URL http://www.arius.com
Article: 24181
Subject: Re: LFSR as a divider
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 28 Jul 2000 13:41:16 -0400
Links: << >>  << T >>  << A >>
Your problem is definitely the fact that the counter is too slow. If you
dig into the EDIF produced (use a schematic viewer) you will likely find
that the counter is being made with LUT logic. It should be made using
the carry spine. To do this a macro is normally used with the carry
logic embedded in it. 

I am not familiar with the Leonardo tool, so I can't tell you what you
are doing wrong, but it may be related to your source, or possibly a
switch on the tool. I expect that you could fix the counter problem
faster than you can generate the LFSR you are talking about. But since
you have already done that, it is a moot point now. 



Ben Sanchez wrote:
> 
> I was using a 14 bit counter.  I think the problem is somehow
> related to the fact that I recently switched to the
> LeonardoSpectrum synth tool, and I don't know how to use it.  It
> is supposed to be much better than FPGA express that comes with
> the ViewLogic tools, but in this case the results are dismal.
> 
> The 14bit counter run's at only 50-65MHz, while the rest of the
> design can run a little above 160MHz.
> 
> In the mean time I implemented an LFSR in FFs with a pipelined
> comparator to decode the all zero state. (three 4-input ANDs ->
> register (pipeline the lsb of the 13 bit LFSR) -> 1 4 input AND
> -> register -> output)
> 
> That run's fast.
> 
> In the future when the time pressure of this particular job is
> off I want to figure out why these counters don't run fast when
> synthesized with LS.
> 
> Ben
> 
> ===========================================================
>   Ben Sanchez                     Engineer, Lab Manager
>   e-mail:  ben@phoenix.seti.org   Project Phoenix
>                                   SETI Institute
>   Web:     http://www.seti.org    2035 Landings Drive
>                                   Mountain View, CA 94043
> ===========================================================
> 
> rickman wrote:
> >
> > "K.Orthner" wrote:
> > >
> > > Assuming that you're not extremely short on space, you could buile a LFSRout
> > > of regular FF's and logic blocks.  Because the logic for a LFSR is much
> > > simpler that for a counter, it would still be able to run significantly
> > > faster.
> > >
> > > The VHDL code would look something like this:
> > >
> > > process lfsr (rst, clk )
> > > begin
> > >   if rst = '1' then
> > >       lfsr_reg <= '1' & (others => '0');
> > >       -- Note: You have to reset the lfsr to non-zero.
> > >
> > >   elsif rising_edge( clk ) then
> > >       lfsr_reg <=  (lfsr_reg(0) xor lfsr_reg(2) ) & lfsr_reg (lfsr_size-1
> > > downto 1);
> > >       -- Another note: This is going left-to-right.
> > >
> > >   end if;
> > > end process;
> > >
> > > You can then just AND together all of the bits of lfsr_reg, which will give
> > > you a pulse when the entire LFSR is '1'.  (The all-zero state will never
> > > happen).
> >
> > You were doing pretty well untill you suggested ANDing all the bits of
> > the counter. If the standard fast carry counter is speed limited, then a
> > 14 input AND gate will be the speed limiting logic. This would need to
> > be pipelined and likely floorplanned.
> >
> > Actually, I can't see how a 14 bit fast carry counter could be too slow
> > for this application. The fast carries are very fast and with only 14
> > bits are likely to be nearly as fast as the LFSR. How many bits were
> > being used in the counter?
> >
> >
> > > A length of 14 bits should give you a pulse once every 16383 clk cycles.
> > >
> > > -Kent
> > >
> > > P.S.  I haven't read the app note, so my implementation may look nothing at
> > > all like Xilinx's.
> > >
> > > > I have looked into using the LFSR setup described in Xilinx's
> > > > XAPP210 (By Maria George and Peter Alfke), and implementing it
> > > > looks simple enough.  The problem is that I don't see how one
> > > > gains access to all the bits in the LFSR.  I want to do something
> > > > like let the thing free run and output a pulse every time it
> > > > comes round to a particular state, say 0.
> > > >
> > > > Does anybody know how to do this?
> > >
> > > ------------
> > > Kent Orthner
> >
> > --
> >
> > Rick Collins
> >
> > rick.collins@XYarius.com
> >
> > Ignore the reply address. To email me use the above address with the XY
> > removed.
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design
> >
> > Arius
> > 4 King Ave
> > Frederick, MD 21701-3110
> > 301-682-7772 Voice
> > 301-682-7666 FAX
> >
> > Internet URL http://www.arius.com

-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24182
Subject: OT: was: Re: Which one is good coding style?
From: steve (Steve Rencontre)
Date: Fri, 28 Jul 2000 18:45 +0100 (BST)
Links: << >>  << T >>  << A >>
In article <8louol$bj6@inf-gw.inf.furukawa.co.jp>, nospam@ihatespam.com 
(K.Orthner) wrote:

> > You're welcome. I learnt something today too: nobody seems able to
> > explain me why left and right are inverted in a mirror but not top
> > and bottom ;-)
> 
> You're eyes are on the left and right sides of your face.  If they were,
> say, in the top and bottom of your face, then a mirror would invert top 
> &
> bottom!

The mirror /doesn't/ invert left and right (or up and down or anything 
else). The /user/ of the mirror does. Think about it.

--
Steve Rencontre		http://www.rsn-tech.co.uk
//#include <disclaimer.h>

Article: 24183
Subject: alternatives to costly FPGA config proms ??
From: sja@world.std.com (Stuart J Adams)
Date: Fri, 28 Jul 2000 18:51:16 GMT
Links: << >>  << T >>  << A >>
Can anyone recommend low-cost alternatives to
what seems to be pretty costly serial config 
eproms/proms for FPGAs ??  We are looking at
Spartan-II and the 1MBit config eprom is about
the same price as the FPGA.

For my current application I can't load the FPGA
from the microprocessor.

I was thinking about maybe using a regular byte-wide
Flash device and CPLD or PIC instead (maybe a $5 
solution instead of $15)

-- Stuart

Article: 24184
Subject: Re: LFSR as a divider
From: Ben Sanchez <ben@seti.org>
Date: Fri, 28 Jul 2000 12:10:13 -0700
Links: << >>  << T >>  << A >>
For some reason my posts (going through nntp.news.netcom.com) are
VERY slow in posting, so some of you have not received my
responses yet.

The clock rate is 100MHz.  I am using this counter to replace a
1PPS pulse, but I don't need the time between pulses to be 1
second for this application, so I just made it 10K so the counter
wouldn't be that big.

I do wonder why the counter wouldn't run faster, I've never had
these types of problems with other counter's, but that was using
FPGA Express as a synth, now I'm using LeonardoSpectrum.  Anybody
why counters would be slow when run through LS?

Ben



rickman wrote:
> 
> "K.Orthner" wrote:
> >
> > > You were doing pretty well untill you suggested ANDing all the bits of
> > > the counter. If the standard fast carry counter is speed limited, then a
> > > 14 input AND gate will be the speed limiting logic. This would need to
> > > be pipelined and likely floorplanned.
> >
> > I was going to suggest pipelining the AND . . but i figured if you can use
> > 6-input LUTs, then a 14-bit AND is only 2 logic levels . . . . how slow can
> > it be?
> >
> > <checking the book quick to make sure you can use 6-input LUTs . . . >
> >
> > Okay.  Looks like no 6-input LUTs.
> > But still, two levels of 2-input LUTs?
> >
> > o <= (i0 * i1 * i2 * i3) * (i4 * i5 * i6 * i7) * (i8 * i9 * i10 * i11) *
> > (i12 * i13)
> >
> > That's not *that* bad, is it?  How fast are you trying to run your counter?
> >
> > ------------
> > Kent Orthner
> 
> I agree that this is not all that slow. But it will be slower than a
> LFSR. The LFSR is designed to only use a single level of logic for the
> feedback and the FFs can be arranged to minmize the routing delays. The
> 14 input AND gate will make it harder to get short routes. Often the
> route delays are longer than the logic delays.
> 
> In this design I can't see where a 14 bit fast counter will be too slow
> for nearly any application. I would like to know what clock rate is
> being used. Especially if a count of 10,000 is roughly equal to 1
> second!!! I may have misread that part...
> 
> --
> 
> Rick Collins
> 
> rick.collins@XYarius.com
> 
> Ignore the reply address. To email me use the above address with the XY
> removed.
> 
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
> 
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
> 
> Internet URL http://www.arius.com
Article: 24185
Subject: Re: Which one is good coding style?
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Fri, 28 Jul 2000 13:16:17 -0700
Links: << >>  << T >>  << A >>
K.Orthner wrote in message <8lqmv8$c1@inf-gw.inf.furukawa.co.jp>...
>> These processes won't generate the same logic.  Example 1 has both a
>> synchronous reset and an async reset.  Example 2 has two async resets.
>> Different behaviour.  Of course, if ByteReq is generated by synchronous
>> logic, then it will "appear" to be a sync reset, but it's not.
>>
>> In fact, an FPGA synthesis tool will probably choke on Example 2, because
>> the template for flip-flops has only the clock and the async reset in the
>> sensitivity list.
>
>I have't tried it, but wouldn't any decent synthesis tool generate a
>two-input logic function for the two resets, and then feed that into the FF
>reset?  You only run into a problem if you're trying to reset tt to '1' in
>one case, and to '0' in another.

OK, I just did a simple test with FPGA Express and F2.1i.  Target was an XLA
part.

given:

    flop : process (clk, rst1, rst2) is
    begin
        if rst = '1' or rst2 = '1' then
            q <= '0';
        elsif rising_edge (clk) then
            q <= d;
        end if;
    end process flop;

and raise my rent!  rst1 and rst2 get ORed in a CLB, whose output (a net
called N0) feeds the STARTUP block's GSR.  N0 is therefore the chip's global
reset!

Now, where it gets ugly is if you add another flop to your design, but you
choose to asynchronously reset it with only one of the two signals:

    flop2 : proess (clk, rst1) is
        if rst1 = '1' then
            q1 <= '0';
        elsif rising_edge(clk) then
            q1 <= d1;
        end if;
    end process flop2;

What happens here is that the synth notices that rst1 is the global reset.
The P+R tools then use rst1 as GSR, and rst2 in flop is actually used as a
*synchronous* reset.  (Note that neither rst1 nor rst2 were synced in an
IFF.)

so, the synthesis tool is quite happy to have a flop with two async resets.
and the P+R tools are quite happy to spit out some logic to attempt to do
what you want.

In any event, I think the best thing to do is to have one global async
reset, and use sync resets for your state machines and such to ensure they
get reset as you expect.


-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"A sufficiently advanced technology is indistinguishable from magic"
     --Arthur C. Clarke



Article: 24186
Subject: Re: alternatives to costly FPGA config proms ??
From: Dave Vanden Bout <devb@xess.com>
Date: Fri, 28 Jul 2000 16:24:32 -0400
Links: << >>  << T >>  << A >>
We use a CPLD and a 16 Mbit Flash on our XSV Boards.  The CPLD controls
the programming of the Flash and then the configuration of the Virtex
FPGA from the Flash.  Xilinx provides an app-note that shows how the
CPLD controls the configuration process.

You can get an 8051 in a 44-pin package for about $1 and a 1 Mbit Flash
device for about $1.50.  The 8051 will have enough I/O to drive the
address and control lines of the Flash and the configuration clock of
the FPGA.  I'm not sure how much pinout you can get from a PIC for $1.

Stuart J Adams wrote:

> Can anyone recommend low-cost alternatives to
> what seems to be pretty costly serial config
> eproms/proms for FPGAs ??  We are looking at
> Spartan-II and the 1MBit config eprom is about
> the same price as the FPGA.
>
> For my current application I can't load the FPGA
> from the microprocessor.
>
> I was thinking about maybe using a regular byte-wide
> Flash device and CPLD or PIC instead (maybe a $5
> solution instead of $15)
>
> -- Stuart

--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||


Article: 24187
Subject: Re: Which one is good coding style?
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 28 Jul 2000 16:58:31 -0400
Links: << >>  << T >>  << A >>
Andy Peters wrote:
> 
> K.Orthner wrote in message <8lqmv8$c1@inf-gw.inf.furukawa.co.jp>...
> >> These processes won't generate the same logic.  Example 1 has both a
> >> synchronous reset and an async reset.  Example 2 has two async resets.
> >> Different behaviour.  Of course, if ByteReq is generated by synchronous
> >> logic, then it will "appear" to be a sync reset, but it's not.
> >>
> >> In fact, an FPGA synthesis tool will probably choke on Example 2, because
> >> the template for flip-flops has only the clock and the async reset in the
> >> sensitivity list.
> >
> >I have't tried it, but wouldn't any decent synthesis tool generate a
> >two-input logic function for the two resets, and then feed that into the FF
> >reset?  You only run into a problem if you're trying to reset tt to '1' in
> >one case, and to '0' in another.
> 
> OK, I just did a simple test with FPGA Express and F2.1i.  Target was an XLA
> part.
> 
> given:
> 
>     flop : process (clk, rst1, rst2) is
>     begin
>         if rst = '1' or rst2 = '1' then
>             q <= '0';
>         elsif rising_edge (clk) then
>             q <= d;
>         end if;
>     end process flop;
> 
> and raise my rent!  rst1 and rst2 get ORed in a CLB, whose output (a net
> called N0) feeds the STARTUP block's GSR.  N0 is therefore the chip's global
> reset!
> 
> Now, where it gets ugly is if you add another flop to your design, but you
> choose to asynchronously reset it with only one of the two signals:
> 
>     flop2 : proess (clk, rst1) is
>         if rst1 = '1' then
>             q1 <= '0';
>         elsif rising_edge(clk) then
>             q1 <= d1;
>         end if;
>     end process flop2;
> 
> What happens here is that the synth notices that rst1 is the global reset.
> The P+R tools then use rst1 as GSR, and rst2 in flop is actually used as a
> *synchronous* reset.  (Note that neither rst1 nor rst2 were synced in an
> IFF.)
> 
> so, the synthesis tool is quite happy to have a flop with two async resets.
> and the P+R tools are quite happy to spit out some logic to attempt to do
> what you want.
> 
> In any event, I think the best thing to do is to have one global async
> reset, and use sync resets for your state machines and such to ensure they
> get reset as you expect.

This was a good test, but are you sure that the second reset "rst2" in
the second case is really a synchronous reset? The FFs as described in
the data sheet have a clock, three explicit inputs and one hidden input.
The hidden input is the GSR which is an async reset/set. The explicit
inputs are the data and CE inputs which are both synchronous and the
set/reset input which is asynchronous. 

If the logic produced used the set/reset input rather than a LUT, then
this is also an async input and is just what the VHDL specified. 

Was your statement above about the rst2 signal being a *synchronous*
reset a typo?


-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24188
Subject: For Sale: XC17128 serial proms
From: Paul Smart <pablo@maine.rr.com>
Date: Fri, 28 Jul 2000 18:46:03 -0400
Links: << >>  << T >>  << A >>
I have 1078  blank XC17128DPC20C configuration proms
  20 pin PLCC package
  one time programmable
  5Volt technology
  131072 bits

top mark:
  17128DJC
  929467

I can program the devices if needed.

If you are interested in any quantity, please reply to
pablo@maine.rr.com

Thanks,
Paul
Article: 24189
Subject: Re: Variable shifting
From: Ray Andraka <ray@fpga-guru.com>
Date: Sat, 29 Jul 2000 00:56:21 GMT
Links: << >>  << T >>  << A >>
You're not saving much of anything on the routing.  The signals still have to go onto the
routing channel, as each signal has 2 destinations.  One of those is the F5 Mux.  The other has
to go on the routing.  You'll find that in most cases the route goes past the second destination
anyway (best layout seems to be natural order on every layer so you can get half the routes
direct.  In the case of the F5 mux, that makes the direct route the one through the F5.  Also,
you get a slightly irregular layout (signals going back and forth to allow you to put two of the
extra 2 input muxes in the same slice) or holes in the layout that aren't too useful.  In 4K
this going back and forth actually makes the shifter with the HLUTs slower without even
considering the effect of pipelining.  In virtex, I don't know if there'd be much a difference.

rickman wrote:

> Ray Andraka wrote:
> >
> > Well, the F5 mux is still a 2 input mux, sure you get it for "free", but that is beside my
> > point.   Consider the simple case of a 4 input rotator (a barrel shift with the inputs
> > 'wrapped around').  If you implement it in 4 input muxes, you need 4 of them right.  That
> > is 4 slices or 4 CLBs depending on the xilinx architecture, fine.   If you use 2 input
> > muxes in a merged tree, the first layer uses 4, and the second layer uses 4, for a total
> > area that is the same as that of the case using 4 input muxes, but without using the F5
> > muxes.   The difficulty with using the F5 muxes is that you don't get to share the terms.
>
> I understand what you are saying, but the "free" muxes are *exactly* my
> point. But in any case but the most trivial, the merged tree is better
> than the non-merged tree. As you get larger, the merged tree is *much*
> better. But you can do a merged tree with 4 input muxes as well.
>
>        2mux   4mux
> bits   CLBs   CLBs
> 4       2      2
> 8       6      6 (one layer of 2mux)
> 16     16     16
> 32     40     40 (one layer of 2mux)
> 64     96     96
>
> So it looks like a merged tree of 4mux and 2mux uses the same number of
> CLBs, but certainly the 4mux approach uses fewer routes since some of
> them are internal to the CLBs.
>
> Routing congestion is a little hard to measure. If you count pins that
> must be connected, it is 10 * CLBs for the 4mux and 12 * CLBs for the 2
> mux. The net counts are N*(log4(N)+1) for the 4 mux and N*(log2(N)+1)
> for the 2 mux.
>
>          2mux       4mux
> bits   Nets Pins  Nets Pins
> 4       12   24     8   20
> 16      80  192    48  160
> 64     448 1,152  256  960
>
> I can't tell if this is a significant difference or not. I suspect that
> the pin count is more important than the net count, but is is probably a
> mixture of both. So the difference is there, and can approach a factor
> of two in favor of the 4 mux as the size gets large. For the smaller
> shifters it is likely not a big issue.
>
> The 8 input mux performs worse than either in terms of CLB count. It
> will use 4/3 the CLB count of the 2mux and 4mux, the same pin count as
> the 2mux and only slightly fewer nets than the 4mux. So it does not look
> like it has any advantage over the 4mux approach.
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com

Article: 24190
Subject: Re: LFSR as a divider
From: "K.Orthner" <nospam@ihatespam.com>
Date: Sat, 29 Jul 2000 10:00:07 +0900
Links: << >>  << T >>  << A >>
Assuming that you're not extremely short on space, you could buile a LFSRout
of regular FF's and logic blocks.  Because the logic for a LFSR is much
simpler that for a counter, it would still be able to run significantly
faster.

The VHDL code would look something like this:

process lfsr (rst, clk )
begin
  if rst = '1' then
      lfsr_reg <= '1' & (others => '0');
      -- Note: You have to reset the lfsr to non-zero.

  elsif rising_edge( clk ) then
      lfsr_reg <=  (lfsr_reg(0) xor lfsr_reg(2) ) & lfsr_reg (lfsr_size-1
downto 1);
      -- Another note: This is going left-to-right.

  end if;
end process;

You can then just AND together all of the bits of lfsr_reg, which will give
you a pulse when the entire LFSR is '1'.  (The all-zero state will never
happen).

A length of 14 bits should give you a pulse once every 16383 clk cycles.

-Kent

P.S.  I haven't read the app note, so my implementation may look nothing at
all like Xilinx's.

> I have looked into using the LFSR setup described in Xilinx's
> XAPP210 (By Maria George and Peter Alfke), and implementing it
> looks simple enough.  The problem is that I don't see how one
> gains access to all the bits in the LFSR.  I want to do something
> like let the thing free run and output a pulse every time it
> comes round to a particular state, say 0.
>
> Does anybody know how to do this?

------------
Kent Orthner



Article: 24191
Subject: Re: implementation problem of Foundation 2.1i
From: "K.Orthner" <nospam@ihatespam.com>
Date: Sat, 29 Jul 2000 10:03:39 +0900
Links: << >>  << T >>  << A >>
I've never used anything but the foundation express tools with the gooey,
but . . .

You may want to simply call the place-and-route tools from the command line.
That way you can explicitly set allt he options, and aren't limited to what
they decided to let you use in the GUI.  If you go to the Xilinx web site, I
think that you'll find what you're looking for under the section for "2.1
Alliance" documentation.

Try this URL: http://toolbox.xilinx.com/docsan/2_1i/

-Kent

------------
Kent Orthner
korthner at hotmail dot com

Article: 24192
Subject: Re: Question of Virtex DLL
From: "K.Orthner" <nospam@ihatespam.com>
Date: Sat, 29 Jul 2000 10:07:40 +0900
Links: << >>  << T >>  << A >>

> Does the CLKDLL in Virtex/Spartan II could be drived by a internal
> signal ?  If so, how to implement this ?

It must be driven by a clock buffer, so probably the easiest way is to
instantiate a clock buffer for the signal that you want to use to drive the
DLL, and then use the buffered signal as the DLL input.

Example:  If you want to drive the DLL input with the signal clk_in:

    dll_buffer_inst: bufg( i =>clk_in, o=>clk_in_buf);
    dll_inst: dll( clkin => clk_in_buf, . . . . .

-Kent

------------
Kent Orthner
korthner at hotmail dot com


Article: 24193
Subject: Re: LFSR as a divider
From: Ray Andraka <ray@fpga-guru.com>
Date: Sat, 29 Jul 2000 01:07:54 GMT
Links: << >>  << T >>  << A >>
I've run into plenty of instances in Synplicity where the counter gets implemented as
two levels of logic instead of one.  Seems to be a function of trying to do loads and
resets on the same counter.  There are times it is easier to just do it structurally
than to get the tools to make exactly what you want.  Also, and I think this is more
likely the problem in your case, I've noticed in several instances the Xilinx 3.1
tools don't always place the carry chain in one contiguous piece.  You'd think
something as basic as keeping the carry chain as one 'stick' would be something they'd
check, but no.

rickman wrote:

> Your problem is definitely the fact that the counter is too slow. If you
> dig into the EDIF produced (use a schematic viewer) you will likely find
> that the counter is being made with LUT logic. It should be made using
> the carry spine. To do this a macro is normally used with the carry
> logic embedded in it.
>
> I am not familiar with the Leonardo tool, so I can't tell you what you
> are doing wrong, but it may be related to your source, or possibly a
> switch on the tool. I expect that you could fix the counter problem
> faster than you can generate the LFSR you are talking about. But since
> you have already done that, it is a moot point now.
>
> Ben Sanchez wrote:
> >
> > I was using a 14 bit counter.  I think the problem is somehow
> > related to the fact that I recently switched to the
> > LeonardoSpectrum synth tool, and I don't know how to use it.  It
> > is supposed to be much better than FPGA express that comes with
> > the ViewLogic tools, but in this case the results are dismal.
> >
> > The 14bit counter run's at only 50-65MHz, while the rest of the
> > design can run a little above 160MHz.
> >
> > In the mean time I implemented an LFSR in FFs with a pipelined
> > comparator to decode the all zero state. (three 4-input ANDs ->
> > register (pipeline the lsb of the 13 bit LFSR) -> 1 4 input AND
> > -> register -> output)
> >
> > That run's fast.
> >
> > In the future when the time pressure of this particular job is
> > off I want to figure out why these counters don't run fast when
> > synthesized with LS.
> >
> > Ben
> >
> > ===========================================================
> >   Ben Sanchez                     Engineer, Lab Manager
> >   e-mail:  ben@phoenix.seti.org   Project Phoenix
> >                                   SETI Institute
> >   Web:     http://www.seti.org    2035 Landings Drive
> >                                   Mountain View, CA 94043
> > ===========================================================
> >
> > rickman wrote:
> > >
> > > "K.Orthner" wrote:
> > > >
> > > > Assuming that you're not extremely short on space, you could buile a LFSRout
> > > > of regular FF's and logic blocks.  Because the logic for a LFSR is much
> > > > simpler that for a counter, it would still be able to run significantly
> > > > faster.
> > > >
> > > > The VHDL code would look something like this:
> > > >
> > > > process lfsr (rst, clk )
> > > > begin
> > > >   if rst = '1' then
> > > >       lfsr_reg <= '1' & (others => '0');
> > > >       -- Note: You have to reset the lfsr to non-zero.
> > > >
> > > >   elsif rising_edge( clk ) then
> > > >       lfsr_reg <=  (lfsr_reg(0) xor lfsr_reg(2) ) & lfsr_reg (lfsr_size-1
> > > > downto 1);
> > > >       -- Another note: This is going left-to-right.
> > > >
> > > >   end if;
> > > > end process;
> > > >
> > > > You can then just AND together all of the bits of lfsr_reg, which will give
> > > > you a pulse when the entire LFSR is '1'.  (The all-zero state will never
> > > > happen).
> > >
> > > You were doing pretty well untill you suggested ANDing all the bits of
> > > the counter. If the standard fast carry counter is speed limited, then a
> > > 14 input AND gate will be the speed limiting logic. This would need to
> > > be pipelined and likely floorplanned.
> > >
> > > Actually, I can't see how a 14 bit fast carry counter could be too slow
> > > for this application. The fast carries are very fast and with only 14
> > > bits are likely to be nearly as fast as the LFSR. How many bits were
> > > being used in the counter?
> > >
> > >
> > > > A length of 14 bits should give you a pulse once every 16383 clk cycles.
> > > >
> > > > -Kent
> > > >
> > > > P.S.  I haven't read the app note, so my implementation may look nothing at
> > > > all like Xilinx's.
> > > >
> > > > > I have looked into using the LFSR setup described in Xilinx's
> > > > > XAPP210 (By Maria George and Peter Alfke), and implementing it
> > > > > looks simple enough.  The problem is that I don't see how one
> > > > > gains access to all the bits in the LFSR.  I want to do something
> > > > > like let the thing free run and output a pulse every time it
> > > > > comes round to a particular state, say 0.
> > > > >
> > > > > Does anybody know how to do this?
> > > >
> > > > ------------
> > > > Kent Orthner
> > >
> > > --
> > >
> > > Rick Collins
> > >
> > > rick.collins@XYarius.com
> > >
> > > Ignore the reply address. To email me use the above address with the XY
> > > removed.
> > >
> > > Arius - A Signal Processing Solutions Company
> > > Specializing in DSP and FPGA design
> > >
> > > Arius
> > > 4 King Ave
> > > Frederick, MD 21701-3110
> > > 301-682-7772 Voice
> > > 301-682-7666 FAX
> > >
> > > Internet URL http://www.arius.com
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com

Article: 24194
Subject: Re: Spartan-II power consumption
From: "K.Orthner" <nospam@ihatespam.com>
Date: Sat, 29 Jul 2000 10:12:48 +0900
Links: << >>  << T >>  << A >>
> >
> > The datasheet says the Virtex is .22 um. The Spartan II is .18 um
> > according to an XCell article, xl35_5.pdf.
> >
>
> Yup, based on your reference I stand corrected.  I wonder how they get
> away with it?  I was under the impression that 2.5V was too much for
> 0.18um geometries, hence the requirement for 1.8V power for devices
> like Vertex-E, XPLA4, and XC9500XE.  Other Xilinx 2.5V devices
> including XC4000XV, XC9500XV, and K2 use 0.25um geometries.

The data book that I have (Programmable Logic Data Book 2000) indicates :

Spartan-II: "Advanced 0.22/0.18 um 6-layer process"
Virtex: "0.22um 5-layer metal process"  (Not advanced?)

This, of course, implies that Virtex *will* burn more power, and the
spreadsheet that I pointed you to is not applicable to use.  My apologies.

-Kent

------------
Kent Orthner


Article: 24195
Subject: Re: Which one is good coding style?
From: "K.Orthner" <nospam@ihatespam.com>
Date: Sat, 29 Jul 2000 10:16:11 +0900
Links: << >>  << T >>  << A >>
> These processes won't generate the same logic.  Example 1 has both a
> synchronous reset and an async reset.  Example 2 has two async resets.
> Different behaviour.  Of course, if ByteReq is generated by synchronous
> logic, then it will "appear" to be a sync reset, but it's not.
>
> In fact, an FPGA synthesis tool will probably choke on Example 2, because
> the template for flip-flops has only the clock and the async reset in the
> sensitivity list.

I have't tried it, but wouldn't any decent synthesis tool generate a
two-input logic function for the two resets, and then feed that into the FF
reset?  You only run into a problem if you're trying to reset tt to '1' in
one case, and to '0' in another.

------------
Kent Orthner


Article: 24196
Subject: Re: Arithmetic Operators
From: "Joel Kolstad" <Joel.Kolstad@USA.Net>
Date: Fri, 28 Jul 2000 20:15:25 -0700
Links: << >>  << T >>  << A >>
"Jamil Khatib" <Khatib@opencores.org> wrote in message
news:397EAC8F.75874219@opencores.org...
> I use the ieee.std_logic_signed
> in order to perform synthesizable arithmetic functions using the
> operators +,-,*,/

OK.  Be aware that std_logic_signed is really a Synopsys creation, and not a
true IEEE library.

> but I do not know which representation do they use (sign magnitude, 1's
> complement or so). I want to use sign magnitude representation

They use 2's complement representations.  You'll have to write your own
libraries if you want to use sign magnitude representations.  (But do you
really want to do that?  Sign magnitude is really painful...)

> What can I do if some of the operations in the same module are signed
> and the others are not? I am trying to append '0' on the left of the
> std_logic_vector signals and perform the operation.

mySignedSignal<= signed("0" & someUnsignedSignal) ???

---Joel Kolstad



Article: 24197
Subject: Re: Variable shifting
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 28 Jul 2000 23:18:51 -0400
Links: << >>  << T >>  << A >>
I am not clear as to what you are saying. Do you mean that the signal
from an F/G LUT will go to the F5 mux as well as to some other
destination? I don't think this is correct. The architecture I assumed
did not use the same structure when using the 4 input mux. The output of
the 4 input mux is from the F5 mux and the F/G LUTs do not leave the CLB
rather they go directly to the F5 mux and only to the F5 mux. 

Actually, that might be a third way to do this. Can you use the F5 mux
in a Virtex or Spartan II and still access the outputs from the F LUT
and G LUT? If so, then using the F5 mux as a 2 input mux in the original
2 input mux tree arrangement will reduce the number of CLBs by 1/3 in
addition to helping somewhat with the routing. 

I did not consider the 4K series since there is not much point in using
them in a new design. I expect they will be very pricey compared to what
Xilinx is selling this time next year; Spartan III perhaps?


Ray Andraka wrote:
> 
> You're not saving much of anything on the routing.  The signals still have to go onto the
> routing channel, as each signal has 2 destinations.  One of those is the F5 Mux.  The other has
> to go on the routing.  You'll find that in most cases the route goes past the second destination
> anyway (best layout seems to be natural order on every layer so you can get half the routes
> direct.  In the case of the F5 mux, that makes the direct route the one through the F5.  Also,
> you get a slightly irregular layout (signals going back and forth to allow you to put two of the
> extra 2 input muxes in the same slice) or holes in the layout that aren't too useful.  In 4K
> this going back and forth actually makes the shifter with the HLUTs slower without even
> considering the effect of pipelining.  In virtex, I don't know if there'd be much a difference.
> 
> rickman wrote:
> 
> > Ray Andraka wrote:
> > >
> > > Well, the F5 mux is still a 2 input mux, sure you get it for "free", but that is beside my
> > > point.   Consider the simple case of a 4 input rotator (a barrel shift with the inputs
> > > 'wrapped around').  If you implement it in 4 input muxes, you need 4 of them right.  That
> > > is 4 slices or 4 CLBs depending on the xilinx architecture, fine.   If you use 2 input
> > > muxes in a merged tree, the first layer uses 4, and the second layer uses 4, for a total
> > > area that is the same as that of the case using 4 input muxes, but without using the F5
> > > muxes.   The difficulty with using the F5 muxes is that you don't get to share the terms.
> >
> > I understand what you are saying, but the "free" muxes are *exactly* my
> > point. But in any case but the most trivial, the merged tree is better
> > than the non-merged tree. As you get larger, the merged tree is *much*
> > better. But you can do a merged tree with 4 input muxes as well.
> >
> >        2mux   4mux
> > bits   CLBs   CLBs
> > 4       2      2
> > 8       6      6 (one layer of 2mux)
> > 16     16     16
> > 32     40     40 (one layer of 2mux)
> > 64     96     96
> >
> > So it looks like a merged tree of 4mux and 2mux uses the same number of
> > CLBs, but certainly the 4mux approach uses fewer routes since some of
> > them are internal to the CLBs.
> >
> > Routing congestion is a little hard to measure. If you count pins that
> > must be connected, it is 10 * CLBs for the 4mux and 12 * CLBs for the 2
> > mux. The net counts are N*(log4(N)+1) for the 4 mux and N*(log2(N)+1)
> > for the 2 mux.
> >
> >          2mux       4mux
> > bits   Nets Pins  Nets Pins
> > 4       12   24     8   20
> > 16      80  192    48  160
> > 64     448 1,152  256  960
> >
> > I can't tell if this is a significant difference or not. I suspect that
> > the pin count is more important than the net count, but is is probably a
> > mixture of both. So the difference is there, and can approach a factor
> > of two in favor of the 4 mux as the size gets large. For the smaller
> > shifters it is likely not a big issue.
> >
> > The 8 input mux performs worse than either in terms of CLB count. It
> > will use 4/3 the CLB count of the 2mux and 4mux, the same pin count as
> > the 2mux and only slightly fewer nets than the 4mux. So it does not look
> > like it has any advantage over the 4mux approach.
> >
> > --
> >
> > Rick Collins
> >
> > rick.collins@XYarius.com
> >
> > Ignore the reply address. To email me use the above address with the XY
> > removed.
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design
> >
> > Arius
> > 4 King Ave
> > Frederick, MD 21701-3110
> > 301-682-7772 Voice
> > 301-682-7666 FAX
> >
> > Internet URL http://www.arius.com

-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24198
Subject: Re: Power PC with Xilinx - what do you think?
From: "Joel Kolstad" <Joel.Kolstad@USA.Net>
Date: Fri, 28 Jul 2000 20:23:58 -0700
Links: << >>  << T >>  << A >>
"Steve Casselman" <sc@vcc.com> wrote in message
news:snu82dnr3j169@corp.supernews.com...
> I predict 2-3 years
> after they produce the device in volume everyone will recognize that
> reconfigurable computing is the future.

I realize you're in the business of reconfigurable computing, Steve, but I
think your time estimates are way too liberal.  Getting software technology
(compilers, primarily) to actually make use of the reconfigurable portion of
a CPU and getting programmers to write in some style or language to
facilitate that use is going to take a lot longer, I believe.  More like the
better part of a decade, I think.

Heck, FPGAs are only just barely reconfigurable today due to a lack of tool
support.  You can do it, but it's still way too hard for all but the most
aggressive designers out there today.

I'd be interested in hearing your opinions on applications for PowerPC+FPGA
ICs vs. the ill-fated XC6200 series of ICs.

---Joel Kolstad



Article: 24199
Subject: Re: Question of Virtex DLL
From: "K.Orthner" <nospam@ihatespam.com>
Date: Sat, 29 Jul 2000 13:03:35 +0900
Links: << >>  << T >>  << A >>
"Ben Sanchez" <ben@seti.org> wrote:

> No.  It can only be driven by a global clock input buffer
> (IBUFG), which can only be driven by a Global clock input pin
> (there are 4 on a virtex, 8 on VirtexE).  If you want an internal
> signal to drive a CLKDLL, you have to bring it out a pin and back
> in a clock pin, but all that delay out and in probably defeats
> the purpose of the DLL.

Referring to XAPP132,

If you use the CLKDLL primitive, you can source the input clockfrom a BUFG,
but if you use the BUFGDLL primitive, than you must use an external pin.

This is copied from the XAPP132 application note, from the CLKDLL section:

CLKDLL Primitive Pin Descriptions
The library CLKDLL primitives provide access to the complete set of DLL
features needed
when implementing more complex applications with the DLL.
Source Clock Input - CLKIN
The CLKIN pin provides the user source clock (the clock signal on which the
DLL operates) to
the DLL. The CLKIN frequency must fall in the ranges specified in the
datasheet. The clock
input signal can be provided by one of the following:
. BUFG - Internal global clock buffer
. IBUFG - Global clock input buffer on the same edge of the device (top or
bottom)
. IO_LVDS_DLL - the pin adjacent to a global clock pin.


------------
Kent Orthner
korthner at hotmail dot 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