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
dscolson@rcn.com schrieb: > Six input LUTs seem to be a long over due change. Not really. There were competitors with larger and smaller LUTs twelve years ago. There has been anything from seas of AND gates over 2-LUTs up to 6-LUTs. Until now 4-LUTs had by far the most success. Larger LUTs also means fewer LUTs and slower LUTs. The area of a LUT increases exponentially with the number of inputs and as the LUTs grow, more and more inputs can't be used on avarage. Research in the early ninetees suggested that 3-LUTs are better than 4-LUTs because there are so many adders in modern designs. The addition of dedicated carry logic moved the sweet spot over to 4-LUTs. The move to larger LUTs now is probably trigger by wiring: The relative wiring delay is increasing dramatically for smaller technologies so that it becomes more important to minimize the interconnect than to minimize LUT delay. Areawise Xilinx chose to support designs with a rather high rent exponent. Therefore the larger circuit densities require a larger amount of wiring. It probably turned out that after filling the chip with wires and layouting the logic and configuration storage below there was a significant amount of silicon area left under the wires. In that situation blowing up the LUTs comes for free area wise. Kolja SulimmaArticle: 102376
Austin Lesea schrieb: > V4 FX is not skipped. It is most definitely being shipped right now. In > fact the backlog was just cleared. So what is recommended if I want to use the MGTs, perhaps @ 6.3 Gbit/s Virtex-II ProX or V4 ? Are the Virtex-II ProX already available and how is the user feedback? Regards FalkArticle: 102377
Ed McGettigan schrieb: > You can of course think of > any LUT as being generated a 128-to-1 MUX, but that would be inefficient > in actual hardware to build. How is that? I do not see any other way of building it. A MUX can be done in 130 transistors. For a function with 134 inputs that is pretty good. And even if you instead chose a decoder/mux combination to trade of area for speed the result is still a MUX, isn't it? The only difference between a LUT and a MUX is, that in MUX you care about input to ouput delay, in a LUT you only care bout select to output delay. Kolja SulimmaArticle: 102378
I want to instantiate some CoreGen modules to get some usage estimates
on some possible target platforms. I've never created a project from
scratch, I've only used vendor supplied projects to implement my
designs, so I'm lost .
Here's my entity w/ instantiation:
<SNIP>
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
LIBRARY unisim;
USE unisim.vcomponents.ALL;
entity coreest is
port (
clk_in: in std_logic;
reset: in std_logic;
din: in std_logic_vector(15 downto 0);
dout: out std_logic_vector(15 downto 0)
);
end coreest;
architecture str_ar of coreest is
component BUFG is
port (
I : in std_logic;
O : out std_logic
);
end component;
component macfir
port (
CLK: IN std_logic;
RESET: IN std_logic;
ND: IN std_logic;
RDY: OUT std_logic;
RFD: OUT std_logic;
DIN: IN std_logic_VECTOR(15 downto 0);
DOUT: OUT std_logic_VECTOR(37 downto 0));
end component;
signal clk: std_logic;
signal macfir_nd: std_logic;
signal macfir_din: std_logic_vector(15 DOWNTO 0);
signal macfir_rdy: std_logic;
signal macfir_rfd: std_logic;
signal macfir_dout: std_logic_vector(37 DOWNTO 0);
begin
clk_in_bufg_inst : BUFG
port map(
I => clk_in,
O => clk
);
macfir_inst : macfir
port map (
CLK => clk,
RESET => reset,
ND => macfir_nd,
DIN => macfir_din,
RDY => macfir_rdy,
RFD => macfir_rfd,
DOUT => macfir_dout
);
macfir_nd <= '1';
macfir_din <= din;
dout <= macfir_dout(macfir_dout'high downto
macfir_dout'high-dout'length+1);
end str_ar;
</SNIP>
The 'macfir_inst' instance is a CoreGen entity, 'macfir (macfir.xco)'
generated from the Xilinx FIR core. I configured it correctly and
everything seems okay, except synthesis, which is not even recognizing
the global clock net:
<SNIP>
=========================================================================
* HDL Compilation
*
=========================================================================
WARNING:HDLParsers:3498 - No primary, secondary unit in the file
"C:/Work/HDL/CoreEst/macfir.vhd. Ignore this file from project file
"C:/Work/HDL/CoreEst/coreest_vhdl.prj".
Compiling vhdl file "C:/Work/HDL/CoreEst/coreest.vhd" in Library work.
Entity <coreest> compiled.
Entity <coreest> (Architecture <str_ar>) compiled.
=========================================================================
* HDL Analysis
*
=========================================================================
Analyzing Entity <coreest> (Architecture <str_ar>).
WARNING:Xst:766 - "C:/Work/HDL/CoreEst/coreest.vhd" line 67: Generating
a Black Box for component <BUFG>.
Entity <coreest> analyzed. Unit <coreest> generated.
Analyzing module <macfir>.
Module <macfir> is correct for synthesis.
WARNING:Xst:37 - Unknown property "black_box".
=========================================================================
* HDL Synthesis
*
=========================================================================
Synthesizing Unit <macfir>.
Related source file is "macfir.v".
WARNING:Xst:647 - Input <CLK> is never used.
WARNING:Xst:647 - Input <DIN> is never used.
WARNING:Xst:647 - Input <RESET> is never used.
WARNING:Xst:647 - Input <ND> is never used.
WARNING:Xst:1305 - Output <RFD> is never assigned. Tied to value 0.
WARNING:Xst:1305 - Output <RDY> is never assigned. Tied to value 0.
WARNING:Xst:1305 - Output <DOUT> is never assigned. Tied to value
00000000000000000000000000000000000000.
Unit <macfir> synthesized.
Synthesizing Unit <coreest>.
Related source file is "C:/Work/HDL/CoreEst/coreest.vhd".
WARNING:Xst:646 - Signal <macfir_dout<21:0>> is assigned but never
used.
WARNING:Xst:646 - Signal <macfir_rfd> is assigned but never used.
WARNING:Xst:646 - Signal <macfir_rdy> is assigned but never used.
Unit <coreest> synthesized.
=========================================================================
HDL Synthesis Report
Found no macro
=========================================================================
=========================================================================
* Advanced HDL Synthesis
*
=========================================================================
=========================================================================
Advanced HDL Synthesis Report
Found no macro
=========================================================================
=========================================================================
* Low Level Synthesis
*
=========================================================================
Loading device for application Rf_Device from file '4vsx55.nph' in
environment C:\Xilinx.
Optimizing unit <coreest> ...
Mapping all equations...
Building and optimizing final netlist ...
Found area constraint ratio of 100 (+ 5) on block coreest, actual ratio
is 0.
=========================================================================
* Final Report
*
=========================================================================
Final Results
RTL Top Level Output File Name : coreest.ngr
Top Level Output File Name : coreest
Output Format : NGC
Optimization Goal : Speed
Keep Hierarchy : NO
Design Statistics
# IOs : 34
Cell Usage :
# BELS : 1
# GND : 1
# IO Buffers : 16
# OBUF : 16
=========================================================================
Device utilization summary:
---------------------------
Selected Device : 4vsx55ff1148-12
Number of bonded IOBs: 16 out of 640 2%
=========================================================================
TIMING REPORT
NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE.
FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT
GENERATED AFTER PLACE-and-ROUTE.
Clock Information:
------------------
No clock signals found in this design
Timing Summary:
---------------
Speed Grade: -12
Minimum period: No path found
Minimum input arrival time before clock: No path found
Maximum output required time after clock: No path found
Maximum combinational path delay: No path found
Timing Detail:
--------------
All values displayed in nanoseconds (ns)
</SNIP>
Article: 102379Antti wrote: > I am trying to be fair now, only asking LX questions :) > > 1) Xilinx website says to the general public that 'start designing' NOW > to my understanding it means that software support is available NOW, or > is there is any other way to see it? Perhaps, 'start designing' means little, perhaps a better question would be when can one 'finish designing' (and ship) ! ;) -jgArticle: 102380
Falk, V4 FX goes to 6.25, and we have tested for some customers just slightly higher (up to 6.5) and not seen any real yield issues. Work with your FAE. V4 FX has so much more than V2 Pro X (which has only two devices). Austin Falk Brunner wrote: > Austin Lesea schrieb: > >> V4 FX is not skipped. It is most definitely being shipped right now. >> In fact the backlog was just cleared. > > > So what is recommended if I want to use the MGTs, perhaps @ 6.3 Gbit/s > > Virtex-II ProX or V4 ? > > Are the Virtex-II ProX already available and how is the user feedback? > > Regards > FalkArticle: 102381
John_H wrote: > Kudos on the new release! > > But I started to glaze over as you turned on your marketing engines. I > sincerely prefer the technical Austin. Yes, but this Austin can still be entertaining, as he waves his arms :) eg I'm looking forward to just what exactly "equivalent static power" can be ? Could that be like their equivalent LUTs, perhaps ? -jgArticle: 102382
>The only way is to keep on deveoping new things faster than the >old ones get copied. Witholding knowledge seems to be a "no-no" >in evolutionary sense, this is how we are designed. The smarter >a society, the more rewards it offers for knowledge creation. > This is not to say I am all open, of course. The above strategy >is probably optimized at an (inter?) species level, and I also am only >an individual... This is part (not a predominant one, though) of >the reason why I maintain a complete in-house tooling/development >capability, once you do a design on a wintel machine it is >anything but proprietary (can become public on a click >beyond the control of the design owner). I think your ideas are too abstract. If I meet a lion, I need quick thinking to stay alive. I could stop to consider whether evolution has equipped the lion better to deal with this meeting and whether, in the long run, the chances of surviving an encounter with a lion make it worthwhile or not to take evasive action. I could prepare to lecture the lion on the moral and practical advantages of a vegetarian life, but I'd do better to defer these worthy pursuits until I'm out of harm's way. Substitute "lion" with "Chinese techno-pirate" and the same rules apply. Some designs will be copied, but this doesn't mean we should abandon all protection.Article: 102383
Hi everybody, I recently bought a Xilinx Spartan-3E evaluation board, which comes with an integrated Platform Cable USB. Looking for a Linux compatible solution to program the FPGA, I found out that Impact requires the binary kernel driver Jungo and is thus not an option. As Xilinx decided to classify the cable USB protocol specifications as "highly confidential", I started to reverse engineer the programmer to see if I could write an open-source host software. The programmer is made of a USB microcontroller (Cypress EZ-USB) and a CPLD. After trying to understand the protocol from USB traces only without success, I decided to disassemble the microcontroller firmware. The code gave me more information regarding the protocol, but some USB commands are forwarded to the CPLD through register read/write operations and/or general purpose I/Os. Not being able to understand the protocol, I thought I would write a replacement firmware which would not require a kernel driver. I'm looking for people interested in the project (or for people who have managed to understand the Xilinx USB protocol :-)). I can take care of the Cypress EZ-USB microcontroller, but needs someone with CPLD programming experience to write a replacement for the Xilinx CPLD firmware. Laurent PinchartArticle: 102384
As far as chip area goes, the decision to go to LUT6 (as we call it) was a no-brainer: Extensive benchmarking shows that a LUT6 is 'worth" about 1.4 LUT4 (this is an average over almost 200 designs, your mileage may vary...) Our designers found that the CLB size penalty for LUT6 compared to using LUT4 in the same technology is only about 15% (Yes, the LUT takes only a small portion of the silicon area) Gaining 40% in functional density for a 15% price in larger area is, of course, a win-win situation. The higher performance due to fewer levels of LUTs and reduced interconnects is just a bonus. Nice bonus, thank you! Peter Alfke, XilinxArticle: 102385
Austin Lesea <austin@xilinx.com> wrote: ... > Imitation is the sincerest form of flattery, as STM now also has a > triple oxide 90nm process. I am sure they will also offer it at 65nm, > as they also realized how useful it was to their customers. If using triple oxide is imitation and "Imitation is the sincerest form of flattery" then the whole semiconductor industry is using this "flattery". Did Xilinx invent the MOS transistor, self aligning gates, wire bonding, etc. and all those other things they use to produce an IC? Well, as Newton said: "If I have seen a little further it is by standing on the shoulders of Giants." Is using a third oxid thickness really that great genuine invention nobody thought of before. Didn't the engineers at Xilinx need to bang their head fighting for this feature against many (d|m)amages seeing only the added cost? Perhaps other engineers in other companies wheren't that succesfull on the first try. Now perhaps their (d|m)amages see the light. Otherwise congratulation to the new "baby". And hopefully a faster release story to general availability then for XC3SE and ... and ... Cheers -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 102386
"Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag news:4468D3A2.7040600@xilinx.com... > Antti wrote: >> the basic LUT delay cant be much faster, it was pretty damn fast in V4 >> already ! >> however the 6 input LUT is not true 6 input LUT but two 5 input LUTs and >> a mux >> so if the mux delay is significant then 6 input function will we way >> slower than >> 5 input function, sure there is still performance gain over plain 4 LUT >> architecture. > > The Virtex-5 6-input LUT is a true 64-bit look-up-table. Any 6 input > function can be implemented in the LUT. You can of course think of > any LUT as being generated a 128-to-1 MUX, but that would be inefficient > in actual hardware to build. > > As for the timing, the Virtex-5 data sheet is online with timing > delays for all three speed grades so you can verify the performance > differences. > > Ed McGettigan > -- > Xilinx Inc. Hi Ed, well if you say so, but the datasheet shows 2 separate 5 input LUTs 1 output select MUX that combines the makes the 5 input LUTs to look like one 6 input LUT if I look at that schematic from the datasheet then the 6 input function would include LUT delay and MUX in series. if you say it is not 2 LUTs and 1 MUX, but one LUT, well then is the datasheet really confusing!! AnttiArticle: 102387
"Kolja Sulimma" <news@sulimma.de> schrieb im Newsbeitrag news:4468d210$0$11063$9b4e6d93@newsread4.arcor-online.net... > Antti schrieb: > >> however the 6 input LUT is not true 6 input LUT but two 5 input LUTs >> and a mux >> so if the mux delay is significant then 6 input function will we way >> slower than >> 5 input function, sure there is still performance gain over plain 4 LUT >> architecture. > > Hmm. There really is no difference between a MUX and a LUT. > Same schematic symbol, same choice of implementations, same thing. > >> the basic LUT delay cant be much faster, it was pretty damn fast in V4 >> already ! > > You can not really read the circuit speed from the datasheet or FPGA > editor, as they use abstracted timing models. > You can push delay around almost at will in a timing model. > At any node of the timing model you can subtract a delay from all > outgoing edges and add them to all incoming edges without changing the > model. If you reduce the delay of some edges to zero you can merge > nodes. You can even have negative delay edges in timing models. > > You can use this to simplify the model for your software or for the > user. Or you can try to look better than your competitor this way > because people tend to compare certain delays and ignore others. > > As a note: The value for the carry chain is pretty reliable beacuse each > element is immediately preceeded and succeeded by an identical element. > Not much pushing possible there. > > Kolja Sulimma Hi Kolja I am referring to my results of actual LUT delay measurements. what I did before looking the datasheet info. I was almost not to belive the lut delay (too small!) in V4. Only after seeing it in real silicon i looked up the timing info in datasheet. AnttiArticle: 102388
The distributor is not operating a charity. Selling you 5 chips for about $ 50 is hardly a very profitable transaction, considering paperwork etc. These are not little 7/11 stores... Expecting to buy 5 chips at the million-quantity price is unrealistic. The $40 difference between a real and a completely unrealistic price is not too bad. Now, if you complain that you cannot get the chips at all, that would be a valid complaint. $ 40 is not! Peter Alfke, XilinxArticle: 102389
Austin Lesea wrote: > lb, > > V4 FX is not skipped. It is most definitely being shipped right now. > In fact the backlog was just cleared. > Are any FX40 parts at the fab yet? Cheers, JonArticle: 102390
Antti, remember how a LUT is really constructed. It contains 64 latches plus a 6-level 64-to-1 multiplexer, like a christmas tree. The data sheet just (for tutorial purposes) shows the final stage of this big multiplexer separately. If that bothers you, ignore it. But just do not believe that it costs more than the extra delay of any multiplexer level. There are 6 levels of multiplexing, nothing we can do about it. Peter AlfkeArticle: 102391
Quoth Uwe: > Well, as Newton said: "If I have seen a little further it is by > standing on the shoulders of Giants." ... yeah, but oft-forgotten is that Newton was being a dick. He wrote that in a letter to Hooke, who was notoriously short of stature, while they were arguing over who was the first for some discovery or other... It's often quoted as if Newton was being humble, but what he was saying was "I'm better than you, and nothing you have done was remotely useful to science"... SimonArticle: 102392
Jim, Basically, equivalent in this sense is "equal." So if the static power was 1 watt before, it is still one watt (or less). At 65nm, there is gate leakage. Gate leakage does not vary with temperature. So there is a component of the static power that remains the same at -40C, or at 25C, or even at 100C. That factor is a significant part of the static leakage. Basically, the cost of using 65nm. What you will find is that the typical static current for Vccint (Iccint) for V5 is at first, larger than what you would expect. However, it will be on par, or below what the 100C number was for the V4. If the worst case for V4 at 100C was X watts, then a similar sized V5 will be X watts or less over the entire tempeature range, without a huge difference from 25C to 100C (which was what folks are used to seeing before gate leakage became a dominant factor in 65nm). Does this answer the question? Austin Jim Granville wrote: > John_H wrote: > >> Kudos on the new release! >> >> But I started to glaze over as you turned on your marketing engines. >> I sincerely prefer the technical Austin. > > > Yes, but this Austin can still be entertaining, as he waves his arms :) > > eg I'm looking forward to just what exactly "equivalent static power" > can be ? > > Could that be like their equivalent LUTs, perhaps ? > > -jg >Article: 102393
Thanks for the reply Peter. As I stated earlier, I'm not so concerned about the extra cost of the prototype parts, but rather about the cost of the 100-200 parts I may buy later. $40 is obviously not worth complaining about. Why is it that Newegg can get me the latest $300 AMD or Intel desktop processor in qty. 1 without a 400% markup over list, yet such markups are normal when buying $300 worth of FPGAs? Not a flame, I'm genuinely curious to know.Article: 102394
Uwe, Easy for you to say now. But there was a time where the competition was selling against triple oxide as being too new, too risky, and too expensive (with no benefit). So, humor me, name the chips that use a triple oxide process. Austin Uwe Bonnes wrote: > Austin Lesea <austin@xilinx.com> wrote: > ... > >>Imitation is the sincerest form of flattery, as STM now also has a >>triple oxide 90nm process. I am sure they will also offer it at 65nm, >>as they also realized how useful it was to their customers. > > > If using triple oxide is imitation and "Imitation is the sincerest form of > flattery" then the whole semiconductor industry is using this > "flattery". Did Xilinx invent the MOS transistor, self aligning gates, wire > bonding, etc. and all those other things they use to produce an IC? Well, > as Newton said: "If I have seen a little further it is by standing on the > shoulders of Giants." > > Is using a third oxid thickness really that great genuine invention nobody > thought of before. Didn't the engineers at Xilinx need to bang their head > fighting for this feature against many (d|m)amages seeing only the added > cost? Perhaps other engineers in other companies wheren't that succesfull on > the first try. Now perhaps their (d|m)amages see the light. > > Otherwise congratulation to the new "baby". > > And hopefully a faster release story to general availability then for > XC3SE and ... and ... > > CheersArticle: 102395
"Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag news:1147725970.779784.92570@u72g2000cwu.googlegroups.com... > Antti, remember how a LUT is really constructed. > It contains 64 latches plus a 6-level 64-to-1 multiplexer, like a > christmas tree. > The data sheet just (for tutorial purposes) shows the final stage of > this big multiplexer separately. > If that bothers you, ignore it. But just do not believe that it costs > more than the extra delay of any multiplexer level. > There are 6 levels of multiplexing, nothing we can do about it. > Peter Alfke > Hi Peter, in LUT4 world the mux that allows the LUT4 to be used 5 input function DOES add extra delay compared to plain LUT4 delay IMHO if the MUX in datasheet that is drawn 'for tutorial purposes' allows the LUT6 to be as fast as LUT5 that doesnt use that final MUX, then ok. I was blindly assuming that component drawn as MUX does add extra delay when it is included in signal path, versus timing where signal bypasses it. as V5 can implement SRL32 and not SRL64 then IMHO it is clear that LUT6 is made up from 2 LUT5 exactly as it is drawn in the datasheet. AnttiArticle: 102396
Peter Mendham wrote: >> The values in the TI data >> sheet (figure 1) produce about 2.54 volts, 3.29 volts and of course, >> 1.2 volts. > > > I am indeed. I am probably being stupid, but using the values in all > the TI example circuits (I have about 5 variations here) the Buck 2 > potential divider uses values of 61K9 and 36K5 (or 319K and 365K). By > equation 15 in the TI datasheet these values give a Vout of 3.343V. > Similarly, for the LDO the value 2.545V. These are 43mV and 45mV over > spec respectively. Now, it is extremely likely that I am either > worrying about nothing, or being very stupid. Is this over-voltage > specified deliberately, or is it simply a product of using nearest-fit > resistor values? Or have I done my calculations badly? If you can > clarify that for me I would be very grateful. The error on 3.3V is 1.3%, which will be nearest fit resistor values. Normally, simplest design uses two resistors, and it is hard to nail a value under 1% with available values. If this is loosing you sleep, then move to a 3 resistor design, and also be prepared to pay for resistors under 1% tolerance. In a real design, you should measure/verify the voltage AT THE DEVICE, which means a few mV high allows for some trace/choke IR drop. Also check the dynamic power changes, and output impedance of your regulators, as that is another error source. -jgArticle: 102397
I am trying to increase the clock frequency of my microblaze processor (currently 50 MHz) using the dcm_module frequency M/D outputs (CLKFX). I have pasted the dcm_module portion of my system.mhs file here: BEGIN dcm_module PARAMETER INSTANCE = dcm_module_0 PARAMETER HW_VER = 1.00.a PARAMETER C_CLKFX_MULTIPLY = 12 PARAMETER C_CLKFX_DIVIDE = 10 PARAMETER C_CLKIN_BUF = TRUE PARAMETER C_CLK0_BUF = TRUE PARAMETER C_CLKFX_BUF = TRUE PARAMETER C_EXT_RESET_HIGH = 1 PARAMETER C_CLKIN_PERIOD = 20.00000 PARAMETER C_STARTUP_WAIT = TRUE PARAMETER C_FAMILY = spartan3 PORT RST = net_gnd PORT CLKIN = sys_clk PORT CLKFB = dcm_module_0_CLKF0 PORT CLK0 = dcm_module_0_CLKF0 PORT LOCKED = system_dcm_LOCKED PORT CLKFX = sys_clk_s END For some reason, during the place and route phase, I get the following errors: -------------------------------------------------------------------------------- Constraint | Requested | Actual | Logic | | | Levels -------------------------------------------------------------------------------- * NET "bufgp_73/IBUFG" PERIOD = 20 ns HIGH | 20.000ns | 69440.000ns | 2 50% | | | -------------------------------------------------------------------------------- * PERIOD analysis for net "dcm_module_0/dcm | 15.384ns | 46398.083ns | 7 _module_0/CLKFX_BUF" derived from NET "b | | | ufgp_73/IBUFG" PERIOD = 20 ns HIGH 50% | | | -------------------------------------------------------------------------------- Why is the IBUFG being delayed for 69440 ns?!?!?! I also saw this warning a little earlier in the PAR: WARNING:CLK Net:sys_clk_BUFGP may have excessive skew because 1 NON-CLK pins failed to route using a CLK template. Can anyone give me any insight as to why I cannot increase the clock frequency and I get these errors? When I use this same wiring scheme and use a 1X multiplier (M=10/D=10) I can pass the PAR just fine with a 15 ns delay at that IBUFG. What am I missing?Article: 102398
Peter Alfke wrote: > Antti, remember how a LUT is really constructed. > It contains 64 latches plus a 6-level 64-to-1 multiplexer, like a > christmas tree. > The data sheet just (for tutorial purposes) shows the final stage of > this big multiplexer separately. > If that bothers you, ignore it. But just do not believe that it costs > more than the extra delay of any multiplexer level. > There are 6 levels of multiplexing, nothing we can do about it. ISTR that Altera define differing delay times, for their LUT inputs. Will Xilinx define to that level of detail now, as well ? -jgArticle: 102399
"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag news:4468f4b4@clear.net.nz... > Peter Alfke wrote: > >> Antti, remember how a LUT is really constructed. >> It contains 64 latches plus a 6-level 64-to-1 multiplexer, like a >> christmas tree. >> The data sheet just (for tutorial purposes) shows the final stage of >> this big multiplexer separately. >> If that bothers you, ignore it. But just do not believe that it costs >> more than the extra delay of any multiplexer level. >> There are 6 levels of multiplexing, nothing we can do about it. > > ISTR that Altera define differing delay times, for their LUT inputs. > Will Xilinx define to that level of detail now, as well ? > > -jg > yes Altera uses different LUT delays for different inputs to achive better timing Antti
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