Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 74325

Article: 74325
Subject: Re: add/sub 2:1 mux and ena in a single LE (Cyclone)
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Fri, 8 Oct 2004 00:54:25 -0400
Links: << >>  << T >>  << A >>
Hi Philip, Martin:

> Too many inputs to the LUT.
>
> 1 for the A operand
> 1 for the B operand
> 1 for the add/sub signal
> 1 for the load value
> 1 for the carry in from the previous bit.

Cyclone (and Stratix and MAX II) should be able to perform this function in
1 LE per bit.

I *think* you have uncovered a bug in Quartus 4.1 synthesis.  I'll confirm
this with the synthesis team tomorrow.  Basically, it looks like Quartus
will automatically make a loadable adder flop, or a adder-subtractor flop,
but not a loadable adder-substractor flop.  If I make a very simple VHDL
design that implements an synchronously loadable adder+flop, I get 1 LE/bit
as expected.  If I add a add/subtract selector, I get 2 LE/bit for no
apparent reason.  The LE (as shown in Figure 2-5 of the Cyclone databook
http://www.altera.com/literature/hb/cyc/cyc_c51002.pdf) should be able to
implement an sloadable adder/subtractor in 1 LE/bit.  Explanation of why
below.

Cyclone has a LAB-wide addnsub signal that can be used to control whether
the A operand to each LE in the LAB is inverted or not.  In addition,
addnsub can also enter the carry chain at bit 0 -- so you get compliment(a)
+ B + addnsub, or (compliment(a) + 1) + B = -A + B.

If you consider the 4-LUT as two 3-LUTs followed by a 2:1 Mux, then you get
the following assignments of signals (using some psuedo-VHDL; I'm rusty):

-- The programmable inversion of the A input
Aprime(i) <= A(i) WHEN addnsub = '0' else NOT(A(i)) WHEN OTHERS;

-- Carry chain
carry_in(0) <= addnsub;
For i=1..n
    carry_in(i) <= carry_out(i-1);
End for

-- Top-Half 4-LUT computes the sum bit:
TopHalfLUT(i) <= Aprime(i) XOR B(i) XOR carry_in(i)

-- Bottom-Half of 4-LUT computes the carry-in of the next LE:
BottomHalfLUT(i) <= (Aprime(i) AND B(i)) OR (Aprime(i) AND carry_in(i)) OR
(B(i) AND carry_in(i));
carry_out(i) <= BottomHalfLUT(i);

-- Now for the flop.  Note that we're only using 2 of the 4 LE inputs for
A(i), B(i).  carry_in(i) uses
-- the dedicated carry input, and addnsub signal uses the LAB-wide control
signal.  The LAB-wide
-- sload control signal is used to select between TopHalfLUT(i) and the
bypass from the LE's data3
-- input to the flop.
when (clock) -- I'm lazy
    IF sload = '1 THEN
        flop(i) <= sloaddata(i);
    ELSE
        flop(i) <= TopHalfLUT(i);

So there you go -- three inputs to the LE are used for A, B, and sload_data,
and two lab-wide signals are used for addnsub and sload.

Thanks for pointing this out.

Paul Leventis
Altera Corp.



Article: 74326
Subject: Re: 64 bit version of xilinx ISE
From: hpa@terminus.zytor.com (H. Peter Anvin)
Date: Fri, 8 Oct 2004 05:47:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
Followup to:  <4f003$416490e0$40695902$12413@msgid.meganewsservers.com>
By author:    Stephen Williams <spamtrap@icarus.com>
In newsgroup: comp.arch.fpga
>
> Geoffrey Wall wrote:
> > does any one know if there is a 64 bit windows or linux version of xilinx 
> > ISE available?
> 
> The Linux/i386 version of ISE 6.2 works on 64bit Linux. I believe
> that even 32bit programs get another Gig of address space on 64bit
> Linux. (32bit Linux typically gives a process 2Gig of user mode
> address space, 64bit Linux gives it 3gig., but my memory may be
> fuzzy here.)
> 

Make that 3 GB and 4 GB, respectively.

	-hpa

Article: 74327
Subject: Re: FPGA for OCR processing
From: hpa@terminus.zytor.com (H. Peter Anvin)
Date: Fri, 8 Oct 2004 05:50:54 +0000 (UTC)
Links: << >>  << T >>  << A >>
Followup to:  <d4udnT-3IqoCAP3cRVn-sA@megapath.net>
By author:    hmurray@suespammers.org (Hal Murray)
In newsgroup: comp.arch.fpga
>
> >Doing a sequential algorithm in an FPGA is bound to be much slower
> >than one on a hardwired CPU.
> 
> Why?  Is that comment true in general, or just for OCR problems?
> 
> I'd expect there are some sequential problems that would be
> much faster in a FPGA.
> 
> Suppose we assume the clock on the CPU is N times as fast as
> the FPGA and the CPU.  Then any problem that takes more than N
> cycles on the CPU will be faster on the FPGA if the FPGA only
> takes 1 cycle.  How about something like computing a CRC?
> 
> Better would be doing a CRC type calculation while searching
> for a pattern.  I think the Fire codes use something like that
> for error correction.
> 

Think about it... what would make it take only one cycle on an FPGA,
if it takes N cycles on a CPU?  That would typically be parallellism
of some sort.

Computing a CRC can actually be done very fast on a CPU by using
tables.  I doubt you'd get a win there.

	-hpa

Article: 74328
Subject: Re: Interfacing an 1GS ADC
From: "wwqiao" <wwqiao@hotmail.com>
Date: Fri, 08 Oct 2004 06:51:11 GMT
Links: << >>  << T >>  << A >>
Maxim's MAX108 (8 bits, 1.5Gsps) has internal demux.  It should not be very
difficult to use a Xilinx Virtex-II /Pro device to interface with it.  I
think the FPGA device could run at 500MHz internally.  But it



"Alex" <A_Ungerer@netcourrier.com> wrote in message
news:152c7087.0409060135.30bfa875@posting.google.com...
> Hi,
>
> It's not the first time this question has been asked, but I'd like to
> know todays state of art:
> Are their any devices at Altera, Xilinx or others, capabable of
> handling the fast throughput of high-speed ADCs (1 GS), such as
> Atmel's AT84AD001B or NS ADC08D1000 ? Preferably without an external
> DMUX-device...
> Using the ADC's internal DEMUX leaves us with 16 500 MHz LVDS lines
> per channel.
>
> Thanks,
>
>   Alex
>



Article: 74329
Subject: Re: Synplify on Fedora C2
From: tokwok@gmail.com (Tyrone Kwok)
Date: 8 Oct 2004 00:18:30 -0700
Links: << >>  << T >>  << A >>
I got similar error message before when I ran ISE for Linux.
To solve it, I need to type "export LD_ASSUME_KERNEL=2.4.1" in the shell.
Hope that it can also solve your problem.

Cheers,
Tyrone

david@fpgaworld.com (David Kallberg) wrote in message news:<36bd41b5.0410070335.5aeeacc3@posting.google.com>...
> I'm trying to run Synplify on a Fedora Core 2 platform but I get the
> following error message:
> 
> "relocation error: /../synplify_77/linux/mfw/lib-linux_optimized/libkernel32.so:
> symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with
> link time reference"
> 
> I'm in no way a Linux expert so this means nothing to me.
> 
> Advice?
> 
> regards
> David Kallberg
> FPGAworld

Article: 74330
Subject: Re: Ripple counter ?
From: ALuPin@web.de (ALuPin)
Date: 8 Oct 2004 00:25:46 -0700
Links: << >>  << T >>  << A >>
Hi again,

I have thought about it ...

What about the option to route the output of the PLL to the PLL_OUT+
and PLL_OUT- ?

It would be no problem if my external PHY got differential clocks from
the FPGA.

How do I have to make clock settings to get differential clocks?

Thank you for your help

Article: 74331
Subject: Re: add/sub 2:1 mux and ena in a single LE (Cyclone)
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Fri, 08 Oct 2004 07:57:36 GMT
Links: << >>  << T >>  << A >>
> Cyclone has a LAB-wide addnsub signal that can be used to control
whether
> the A operand to each LE in the LAB is inverted or not.  In addition,
> addnsub can also enter the carry chain at bit 0 -- so you get
compliment(a)
> + B + addnsub, or (compliment(a) + 1) + B = -A + B.
>
> If you consider the 4-LUT as two 3-LUTs followed by a 2:1 Mux, then you
get
> the following assignments of signals (using some psuedo-VHDL; I'm
rusty):
>
> -- The programmable inversion of the A input
> Aprime(i) <= A(i) WHEN addnsub = '0' else NOT(A(i)) WHEN OTHERS;
>
> -- Carry chain
> carry_in(0) <= addnsub;
> For i=1..n
>     carry_in(i) <= carry_out(i-1);
> End for
>
> -- Top-Half 4-LUT computes the sum bit:
> TopHalfLUT(i) <= Aprime(i) XOR B(i) XOR carry_in(i)
>
> -- Bottom-Half of 4-LUT computes the carry-in of the next LE:
> BottomHalfLUT(i) <= (Aprime(i) AND B(i)) OR (Aprime(i) AND carry_in(i))
OR
> (B(i) AND carry_in(i));
> carry_out(i) <= BottomHalfLUT(i);
>
> -- Now for the flop.  Note that we're only using 2 of the 4 LE inputs
for
> A(i), B(i).  carry_in(i) uses
> -- the dedicated carry input, and addnsub signal uses the LAB-wide
control
> signal.  The LAB-wide
> -- sload control signal is used to select between TopHalfLUT(i) and the
> bypass from the LE's data3
> -- input to the flop.
> when (clock) -- I'm lazy
>     IF sload = '1 THEN
>         flop(i) <= sloaddata(i);
>     ELSE
>         flop(i) <= TopHalfLUT(i);
>
> So there you go -- three inputs to the LE are used for A, B, and
sload_data,
> and two lab-wide signals are used for addnsub and sload.
>

and three lab-wide signals: addnsub, sload and ena of the FF. I've
checked again with the data sheet. In figure 2-7 you can see the LE in
'dynamic arithmetic mode' and the resource are there for this kind of
function.

When we take a look in the Analysis & Synthesis Equations we get:

--a[0] is a[0]
--operation mode is normal

a[0]_lut_out = lmux[0] & (C1_result[0] # sel_amux) # !lmux[0] &
C1_result[0] & !sel_amux;
a[0] = DFFEA(a[0]_lut_out, clk, VCC, , ena_a, , );

And it should be:

a[0]_lut_out = C1_result[0];
a[0] = DFFEA(a[0]_lut_out, clk, VCC, , ena_a, sel_amux, lmux[0]);

However, the last two parameters for this DFFEA are the asynchronous
inputs to the FF and we want a synchronous load. Why is there such a
thing as asynchronous inputs to a FF?

Perhaps the synthsizer should generate LPM_FF, where the synchronous load
is available.

This function also uses 2 LCs per bit in a Spartan-3. As I'm not so used
to 'read' the Xilinx diagram of the LC I don't know if the resources for
one LC could implement this function.

> Thanks for pointing this out.

You're welcome

As you will notice, this question is related to the JOP optimizing
contest ;-)

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




Article: 74332
Subject: Re: PLL lock usage into Altera Stratix devices
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Fri, 08 Oct 2004 08:03:49 GMT
Links: << >>  << T >>  << A >>
>
> The PLL will lock AFTER configuration, so after configuration (or a
circuit
> break or so), lock will be deasserted. Also note that the lock signal
is
> direcly derived from the phase comparator, so while the PLL is locking,
> you'll see the lock pin be asserted and deasserted a few times before
it
> becomes a stable '1'.
>
> The best solution is to have a counter that counts up to some value as
long
> as lock is '1', and gets reset when it becomes '0'. Once it reaches the
> count value (say 31) it should stop counting and tell the logic that
the
> clock is stable, which I think is easiest to achieve by ANDing this
signal
> with the (synchronous) reset signal for the circuit.
>

Does that mean we have to do this in every design that uses a PLL? Can
the FPGA be driven (and therefore violation setup times) with a too fast
clock during PLL startup ?
I didn't care about the PLL lock till now, just inserted it in the clock
path.

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




Article: 74333
Subject: Re: Advice for a Beginner?
From: "Peter Seng" <NOSPAM@seng.de>
Date: Fri, 8 Oct 2004 10:44:25 +0200
Links: << >>  << T >>  << A >>
Hello,

> Any suggestions for books, sites to read, FPGA starter kits, etc would be
> greatly appreciated.

Shure You will find something of interest on our link-list at:

http://www.seng.de/dlk_database.html


with best regards,

Peter Seng


#############################
SENG digitale Systeme GmbH
Im Bruckwasen 35
D 73037 Goeppingen
Germany
tel  +7161-75245
fax  +7161-72965
eMail  p.seng@seng.de
net  http://www.seng.de
#############################



Article: 74334
Subject: Re: FPGA vs ASIC area -- the crucial issue is power consumption
From: ian.dedic@fme.fujitsu.com (Ian Dedic)
Date: 8 Oct 2004 01:55:20 -0700
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> wrote in message news:<BD8AC177.90B1%peter@xilinx.com>...
> > From: ian.dedic@fme.fujitsu.com (Ian Dedic)
> > Organization: http://groups.google.com
> > Newsgroups: comp.arch.fpga
> > Date: 6 Oct 2004 04:11:15 -0700
> > Subject: Re: FPGA vs ASIC area -- the crucial issue is power consumption
>  
> > Exactly what I was saying as a counterpoint to the Xilinx "FPGAs will
> > take over the world" point of view! In the functions-per-mW game ASICs
> > will always win.
> > 
> > Ian
> Xilinx never said anything of this kind.

Well, your posts often read that way, and I believe you work for
Xilinx :-)

> We are not megalomaniacs.
> But we want to nibble away at the fringes of the ASIC market. If we can take
> those 10% that can benefit from the known FPGA advantages and do not care so
> much about some of the known ASIC advantages, then we double our sales,
> which keep us happy for a year or two.  :-)
> ASICs really do us a favor when they create a world-wide appetite for
> complex electronic solutions, and tickle the system designers' imagination.
> Then, when some of them are disappointed that they cannot afford the ASIC
> for reasons of NRE, time or flexibility, we come in and explain our
> capabilties. We may be not as fast, not as big, not as low power, not as
> cheap in high volume, but instead we are more flexible, changeable,
> dynamically reconfigurable, without any NRE, faster to market, and easier
> (and more fun) to design with, since FPGAs allow unlimited design
> variations, modifications and, heaven forbid, even error fixes.
> We can live with ASICs, they are our big neighbor.
> Peter Alfke

And of course in some cases we couldn't live without FPGAs, otherwise
people couldn't build prototype systems to convince their
CEOs/CTOs/customers to cough up for the (ever-increasing) cost of
making an ASIC :-)

Ian

Article: 74335
Subject: Flex10K10A, I2C, MultiVolt IO, pull-ups
From: "Markus Fuchs" <m.fuchs@fplusp.com>
Date: Fri, 8 Oct 2004 12:14:32 +0200
Links: << >>  << T >>  << A >>
Dear experts,

We have a PIC MCU, an Altera Flex10k10 (EPF10K10ATC100-3) and a serial
EEPROM connected to a I2C bus.
The PIC and EEPROM are 5V devices, the FPGA is a 3,3V device with MultiVolt
IOs. There is a I2C slave controller implemented in the FPGA that is
definitely working correct.
Our problem is that we are experiencing difficulties when writing from the
PIC to the FPGA over I2C.
The FPGA doesn't read the correct bytes (it reads 0xFFs). It didn't help to
change the pull-ups from 400R to 1K, 4K7, 10K!
Now, we realized that communication works if we connect 5,6V to the pull-ups
instead 4,7V as we used before.
Can somebody please explain why this solved our problem?
Currently it is more a workaround than a solution since we don't know what
exactly our problem is.

Thank you in advance.

Best regards,
Markus




Article: 74336
Subject: Re: modelsim crashs with large ram simulation model
From: htj@es.lth.se (Hongtu)
Date: 8 Oct 2004 04:06:08 -0700
Links: << >>  << T >>  << A >>
Thank you guys! when I change the signal to variables, everything works smoothly.


/hongtu

Article: 74337
Subject: Re: FPGA vs ASIC area
From: brimdavis@aol.com (Brian Davis)
Date: 8 Oct 2004 04:18:26 -0700
Links: << >>  << T >>  << A >>
Austin wrote:
> 
> Please let me know if there are any questions left unanswered.
> 
 Thanks; were all your posts as cordial as that one, I don't
think anyone would be complaining. 

Brian

Article: 74338
Subject: Re: Interfacing an 1GS ADC
From: mrand@my-deja.com (Marc Randolph)
Date: 8 Oct 2004 04:33:04 -0700
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote in message news:<41649515.80D21B73@andraka.com>...
> I did a design a couple years ago in a VirtexE-7 that interfaced to an
> Atmel 1GHz 8 bit ADC.  IIRC, that ADC output 4 samples at a time (perhaps
> there was a matching mux chip).  Once inside the FPGA the signal was
> mixed and FFT'd.  The incoming sample rate was 960MHz.  So yes, the
> answer is most current FPGAs can handle the throughput with some
> clever/careful design.  The new crop of FPGAs are considerably faster
> than the VirtexE devices.

Howdy Ray,

   How fast were your IOB's toggling on that design?  Was it really
960 MHz?  A coworker and I got to looking yesterday, and it appears
that the general purpose IOB hasn't really gained any clock rate
performance since VirtexE - all the way to now with the Virtex4.  We
were hoping to do 1.25 GHz LVDS (or any other standard), but our FAE
is steering us away from doing anything much over 840 or 900 MHz. 
Comments from Xilinx reps also welcome...

BTW, Alex, I agree with Ray.  500 MHz LVDS should be doable without
alot of grief.  Just be aware that the internal termination can be
less than ideal.

Have fun,

   Marc

> Alex wrote:
> >
> > It's not the first time this question has been asked, but I'd like to
> > know todays state of art:
> > Are their any devices at Altera, Xilinx or others, capabable of
> > handling the fast throughput of high-speed ADCs (1 GS), such as
> > Atmel's AT84AD001B or NS ADC08D1000 ? Preferably without an external
> > DMUX-device...
> > Using the ADC's internal DEMUX leaves us with 16 500 MHz LVDS lines
> > per channel.


--
 Marc Randolph
 Reply address is a spam trap.  Please post responses.

Article: 74339
Subject: Re: Synplify on Fedora C2
From: david@fpgaworld.com (David Kallberg)
Date: 8 Oct 2004 04:56:42 -0700
Links: << >>  << T >>  << A >>
The solution is to set the following variable...

export LD_ASSUME_KERNEL=2.4.1

However, my nodelocked license did'nt support Linux so it did'nt work anyway...

Article: 74340
Subject: Re: Xilinx Multiple Clock Domains
From: brimdavis@aol.com (Brian Davis)
Date: 8 Oct 2004 05:13:00 -0700
Links: << >>  << T >>  << A >>
Austin wrote:
> 
> Now going into the BUG trees (which is fully buffered, so loads don't 
> count) puts another uncertainty on the values, but from BUFG to BUFG 
> these are also matched pretty well (less than a few tens of ps mismatch).
> 
 You seem to be stating that the skew between a heavily loaded
clock tree and a lightly loaded clock tree will be close enough
that setup/hold will be met when cascaded adjacent flip-flops are
clocked from each domain.

 In my own DDR designs, with lightly loaded DDR register clocks and
heavily loaded internal logic clocks, timing reports and lab testing
have shown otherwise, and opposite-edge ( or 90/270 phased ) clocks
were needed to properly transfer between the two clock domains.

> 
> If you believe the CLK2X is better, then why do you not believe the 
> 'outgen' is just as good?
> 
 Again, it's a concern with deskewing the clock tree delays- as Kevin
pointed out, you can't feedback the loaded 2x clock net into the DCM, 
so the 2x clock net will be offset by the BUFG net difference between
the 2x clock and the 1x clock net that you can use as feedback.

 ( the lack of 2X feedback in V2P & S3 also makes it harder to do
certain internal/external clock deskew topologies )

 Another related concern for cascaded DCM's, or in cases where you
need a known (zero) phase relationship between the DCM input and output:
unless you set the DCM to SOURCE_SYNCHRONOUS mode, the DCM output
clock will LEAD the input clock (by ~1.5 ns in V2) as a result of the
internal DCM feedback delay element used to insure zero-hold at IOBs. 

Brian

Article: 74341
Subject: 3.3 V ref VCC on Xilinx AFX FF1152 board?
From: Michael Dales <mwd24@thompson.cl.cam.ac.uk>
Date: 08 Oct 2004 13:39:51 +0100
Links: << >>  << T >>  << A >>
Hi there,

I have a Xilinx AFX FF1152 Xilinx 2 Pro development board, and I have
a design which drives a set of pins to control some external
devices. These devices expect a TTL switching level, so I'd like to
supply a 3.3V reference voltage to some of the I/O banks on the
design.

However, as far as I can tell, the jumpers on the board only let you
set the reference voltage for the banks to either 1.5V (VCORE) or 2.5V
(VCC0). Is it at all possible to set this to 3.3V? The manual that
comes with the board is a little sparse :)

I guess the alternative is to have something between the V2P and the
devices that switches levels, but it would be nice if we didn't have
to.

Cheers,

-- 
Michael Dales
University of Cambridge Computer Laboratory
http://www.cl.cam.ac.uk/~mwd24/

Article: 74342
Subject: Re: add/sub 2:1 mux and ena in a single LE (Cyclone)
From: Sylvain Munaut <tnt_at_246tNt_dot_com@reducespam.com>
Date: Fri, 08 Oct 2004 15:37:14 +0200
Links: << >>  << T >>  << A >>
 
> This function also uses 2 LCs per bit in a Spartan-3. As I'm not so used
> to 'read' the Xilinx diagram of the LC I don't know if the resources for
> one LC could implement this function.

Don't think so. Not in this form at least.

If I understand correctly the SLICE view of DS099-2 page 11, the muxes
like CYINIT, CY0F, are configured during configuration of the FPGA.

So if you enable the carry logic for a bunch of slices, it stays active
all the time. Then for the load operation to work, you must ensure your
b input is all '0', then you can do it in 1 LC/bit.

If not, the carry will pollute the output ...


But this is only a simplified slice view and I don't know where to
find the complete one. With this view I don't see how it implements
a addsub in 1LC/bit, but it can do it. In the view, I see nothing capable
of inverting the F1 or F2 so that the carry logic knows that one operand
is inverted.



Sylvain

Article: 74343
Subject: Re: 64 bit version of xilinx ISE
From: General Schvantzkoph <schvantzkoph@yahoo.com>
Date: Fri, 08 Oct 2004 09:54:47 -0400
Links: << >>  << T >>  << A >>
On Wed, 06 Oct 2004 15:08:00 -0400, Geoffrey Wall wrote:

> does any one know if there is a 64 bit windows or linux version of xilinx 
> ISE available?
> 
> 
> thanks
> 
> Geoffrey Wall
> Masters Student in Electrical/Computer Engineering
> Florida State University, FAMU/FSU College of Engineering
> wallge@eng.fsu.edu
> Cell Phone:
> 850.339.4157
> 
> ECE Machine Intelligence Lab
> http://www.eng.fsu.edu/mil
> MIL Office Phone:
> 850.410.6145
> 
> Center for Applied Vision and Imaging Science
> http://cavis.fsu.edu/
> CAVIS Office Phone:
> 850.645.2257

I'm surprised that no one from Xilinx has answered this question. Early
last year, when 6.1 was in the works, I was told by someone at Xilinx that
they were holding off the Linux native version until they had a 64
version. Obviously that didn't happen, the current version is Linux native
but not 64 bit (unless the Solaris version is 64 bit, does anyone know?).
I would expect that the 7.1 release will probably have 64 bit support now
that AMD64s are common. The memory requirements for routing the largest
V4s must be bumping up against the 32 bit limit unless they've gotten much
smarter with their routing algorithms (which they may have). Only map and
par need to be ported to 64 bits so the job shouldn't be that hard.


Article: 74344
Subject: Re: Synplify on Fedora C2
From: =?iso-8859-1?q?St=E9phane_Acounis?= <Dans.le@Reply.to>
Date: Fri, 08 Oct 2004 16:23:36 +0200
Links: << >>  << T >>  << A >>
Le Fri, 08 Oct 2004 04:56:42 -0700, David Kallberg a écrit :

> The solution is to set the following variable...
> 
> export LD_ASSUME_KERNEL=2.4.1
> 
> However, my nodelocked license did'nt support Linux so it did'nt work
> anyway...

Synplify works great under Linux (RH9) with a floating license and a
license server.
You need the LD_ASSUME_KERNEL trick with many softwares: Cadence, Altera,
Xilinx, etc...

-- 
Stéphane ACOUNIS
«Chaque fois, chaque fois, chaque fois, que je te vois,
 chaque fois que tu sors de chez moi, tu es complètement fraca»


Article: 74345
Subject: Re: Xilinx DCM and Timing Constraints
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 08 Oct 2004 15:28:04 GMT
Links: << >>  << T >>  << A >>
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:10mbndcfin2gk8b@corp.supernews.com...
> Hi folks,
>
> I have outputs being driven by a fast internal clock generated by a DCM.
It
> would seem to me that I should be able to set up a clock to pad timing
> constraint for this animal.  But the Xilinx tools says I need to specify a
> pad as the clock, and the DCM outputs don't show up as a viable clock
source
> in the drop down menus, I would assume because they are not pads.  What is
> the right procedure here?
>
> Brad Smallridge
> b r a d @ A i V i s i o n . c o m
> 415-661-8068

Why do you need to specify the clock-to-pad timing?  Because you're
interfacing with other chips in your system?  Since they don't have access
to the DCM inside the FPGA, they need an external clock as a reference.  At
least this is the case with most systems.  The clock that's used as the DCM
reference would be the appropriate clock to use in the timing constraints.



Article: 74346
Subject: Re: DCM and CLKFX - is this allowed?
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 08 Oct 2004 15:38:26 GMT
Links: << >>  << T >>  << A >>
"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:wdl9d.7075$mZ2.612177@news02.tsnz.net...
[snip]
> Fo = fi * M/D;
> Valid for this range of numbers
>   1 <= M <= 32
>   1 <= D <= 32
> and this range of frequencies
> 24MHz <= Fo <= 450MHz and  Fi >= 1MHz
>
> So why is this not enough - is there some technical blind spot, or
> are you saying users imagine there might be ?

The trouble from a frequency synthesis perspective is the engineering
history with PLLs.  Typical PLLs before silicon VCOs were common had the
reference divided down to a freqeuncy fed to the phase comparator.  The
VCO's output frequency was also scaled down to the same frequency.  The
resulting fraction can be an M/D figure as in the DCM.

With silicon VCOs improving in performance and cost over recent years, it's
common to have a high frequency VCO with two dividers: one to do a phase
comparison with the input, the other to provide the output frequency.  The
rato again can be represented as M/D.

Since the DCM doesn't use a VCO, the PLL mindset doesn't apply in the
classical sense so the very low phase comparator in the first approach or
the very high frequency VCO in the second aren't an issue.  That's why the
comment.

It's more of a clean NCO than a VCO.



Article: 74347
Subject: Daft modelsim question
From: Thomas Womack <twomack@chiark.greenend.org.uk>
Date: 08 Oct 2004 16:55:39 +0100 (BST)
Links: << >>  << T >>  << A >>
I'm trying to simulate some Verilog to run on my XPort card.  The card
plugs into a Gameboy, so any configuration of its FPGA has to include
a couple of provided blocks for interfacing to the Gameboy's bus.

So the program begins `include "primary.v"

When I try compiling this in modelsim, it says it can't find primary.v,
even if I figure out where in my directory heirarchy primary.v is hiding
and add it to the modelsim project.

So, how do I set what in C I'd call the include directory? The manual
suggests I should use the compile -> compile options... menu option,
but that's greyed out.

Sorry to ask such a dumb question,

Tom

Article: 74348
Subject: Re: FPGA vs ASIC area
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 08 Oct 2004 09:20:32 -0700
Links: << >>  << T >>  << A >>
Brian,

You are welcome.

Austin

Brian Davis wrote:
> Austin wrote:
> 
>>Please let me know if there are any questions left unanswered.
>>
> 
>  Thanks; were all your posts as cordial as that one, I don't
> think anyone would be complaining. 
> 
> Brian

Article: 74349
Subject: Re: Xilinx DCM and Timing Constraints
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Fri, 8 Oct 2004 09:35:06 -0700
Links: << >>  << T >>  << A >>
Well, I drive the SRAM clock with a synthesized higher frequency.  Shouldn't
the timing from the output registers of the FPGA, going to the address lines
and control lines of the SRAM, be constrained relative to the higher clock
frequency that is clocking these registers?





Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search