Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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: 74326Followup 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. -hpaArticle: 74327
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. -hpaArticle: 74328
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
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 > FPGAworldArticle: 74330
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 helpArticle: 74331
> 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
> > 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
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
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 :-) IanArticle: 74335
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, MarkusArticle: 74336
Thank you guys! when I change the signal to variables, everything works smoothly. /hongtuArticle: 74337
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. BrianArticle: 74338
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
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
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. BrianArticle: 74341
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
> 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. SylvainArticle: 74343
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
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
"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
"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
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, TomArticle: 74348
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. > > BrianArticle: 74349
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:
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