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
> No. Open pins should generate a warning. Just tie them to '0'. OK. But ISE should do that automatically, because there are other input pins in the BRAM that I'm not using, and ISE is not complaining about those pins. Anyone knows how do I do that in specifically this project?Article: 153376
On 07/02/12 15:50, Andy wrote: > On Feb 2, 6:48 pm, Alan Fitch <a...@invalid.invalid> wrote: >> On 03/02/12 00:16, Alan Fitch wrote: >> <snip> > > I will have to go back and read the definition of LSP. I agree with > your assessment that these are locally static names; the question is > "what is the relation between a locally static name for an element or > slice of an aggregate, and the longest static prefix for than element > or slice?" It was my understanding that if there is a named aggregate > that contains the object referred to by the locally static name, then > the aggregate is still the LSP, not the locally static name. It likely > has to do with whether events are tracked separately on inidividual > elements of a named aggregate signal, or whether they are only tracked > at the aggregate level. > The statement I noticed was "The longest static prefix of a signal name is the name itself, if the name is a static signal name;" > And I may be entirely wrong... > and so may I :-) > Thanks for the discussion, > That's OK, it's sort of fun! I wonder what the original poster thinks... Alan -- Alan FitchArticle: 153377
I've created a similar project, just replacing ROM with RAM. http://www.mediafire.com/?nlpnn3xs5z940ox 1. synthesize, implement 2. comment and uncomment lines 46, 47 3. synthesize, re-implement it seems it has something to do with the WEA signalArticle: 153378
nico@puntnl.niks (Nico Coesel) writes: > Petter Gustad <newsmailcomp6@gustad.com> wrote: > >>nico@puntnl.niks (Nico Coesel) writes: >> >>>>There are several nice features like interfaces (which are >>>>bi-directional unlike record bundles in VHDL). There's also enum's, >>> >>> Record bundles can be bi-directional in VHDL! >> >>That's great news as I've always used one record type as input and >>another one as output. > > Just declare the port as inout. Its simple as that. That might cause some problems. I've seen some tool which did not like inouts other than at the top level (can't remember which, it might have been some LSI or IBM tool). This is many years ago and might not be the case in more recent versions. Also you'll miss the compile static check of only one driving the signal. //Petter -- .sig removed by request.Article: 153379
Petter Gustad <newsmailcomp6@gustad.com> wrote: >nico@puntnl.niks (Nico Coesel) writes: > >> Petter Gustad <newsmailcomp6@gustad.com> wrote: >> >>>nico@puntnl.niks (Nico Coesel) writes: >>> >>>>>There are several nice features like interfaces (which are >>>>>bi-directional unlike record bundles in VHDL). There's also enum's, >>>> >>>> Record bundles can be bi-directional in VHDL! >>> >>>That's great news as I've always used one record type as input and >>>another one as output. >> >> Just declare the port as inout. Its simple as that. > >be the case in more recent versions. Also you'll miss the compile >static check of only one driving the signal. The synthesizer will most likely complain about that. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 153380
nico@puntnl.niks (Nico Coesel) writes: >>be the case in more recent versions. Also you'll miss the compile >>static check of only one driving the signal. > > The synthesizer will most likely complain about that. I was thinking about simulator compile checks. Which typically can be checked quickly, e.g. can be done from the editor and prior to revision control commits etc. Synthesis usually takes longer. //Petter -- .sig removed by request.Article: 153381
I too have tools which make use of XDL (one of which some of you may have used - FPGA Optim); so after Neil's heads-up, I contacted my local Xilinx guy and got this response (which I must make clear is not an "official factory response"): "Because of the database change in Rodin, XDL is not part of this new tool. This is being debated by the technical teams at Xilinx. One solution offered so far is to use TCL instead as this will enable full access to the database to change the FPGA design / routing similar to XDL." So, there is an awareness of the problem, and hopefully a (albeit different) solution, although it sounds like they are not committed to providing it at the moment. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 153382
Hi,
I am simulating MPMC with Isim version 12.4. I have written a test
bench to give inputs to microblaze instance. Here i am facing problem of
MPMC simulation. The MPMC is not generating NPI output signals like
MCB_DDR2_PIM1_InitDone_pin, MCB_DDR2_PIM1_WrFIFO_Empty_pin etc as required.
Please help me in this problem.
Thank you...
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 153383Hallo. Some questions about Xilinx LUT6 FPGAs (my WebPack Toolchain is a little outdated, and the newer LUT6-FPGAs don't seem to show up correctly in fpga_editor). * Is there really no carry-bypass option in LUT6-paths like the CYMUX(any,cin,1) living in LUT4 paths, apart from constraining the LUTs? * SLICEMs and SLICELs always have a carry chain, while SLICEXs neither have a RAM nor a carry option? * Within a CLB, SLICEMs are paired with SCLICEX (if there are SLICEXs in the device)? Sounds strange to me: If a LUT is configured to be dynamic, it is probably very likely that additional Carry logic isn't used, compared to static LUTs (with LUT4s, one rare reason to this is using the carry chain to implement a post-invert option for the RAM...). Have you ever seen a dynamic LUT6 really gain something in also using carry? * What about production? Does it look like Xilinx might stop selling and developing new LUT4-FPGAs in the near future? I personally don't have enough overview about these two FPGA classes, so I can't see the detailed pros and cons. Gruss Jan Bruns -- Ein paar Fotos: http://abnuto.de/gal/Article: 153384
Neil Steiner: > If you know and love XDL or XDLRC, and if you believe that the research > community's access to these tools provides a benefit to Xilinx, this is > your opportunity to speak up. The xdl tool will no longer be available > as of ISE 14, and unofficial word is that Xilinx does not intend to > provide equivalent capability. We don't believe they're deliberately > trying to withhold that capability: We simply think they see it as a > distraction that provides no benefit for them. > > /For those who may be unfamiliar with these tools, XDL is a format that > can be converted to or from mapped NCD, allowing the user to modify any > part of their circuit or its placement or routing, or to perform > arbitrary placement and routing of their own. XDLRC provides all of the > logic and interconnect data for real Xilinx devices, and enables > research into CAD algorithms for real devices. / > A colleague from BYU (representing RapidSmith) and I (representing Torc) > are scheduled to meet with the Xilinx software folks in two weeks to > discuss this matter, and to appeal for continued functionality > equivalent to XDL and XDLRC. We have no wish to barrage or pressure > them in any way. The data is theirs to do with as they think best. But > to the extent that our community's access to XDL benefits them, we would > like to present that case to them. > > I am collecting and framing our arguments, and am open to any > contributions from the comp.arch.fpga community. Any of the following > would be helpful to our cause, in rough decreasing order of importance. > And I relax the strict meaning of XDL here to include capabilities and > low-level device knowledge enabled by XDL: I'm only a hobbyist, so I actually don't have any evidence about financial matters. But I've noticed the existance of the XDL tool, and used it a few times, but just for informational purposes. Using fpga_editor, I've noticed that the automatic router is sometimes pretty difficut to guide. It sometimes gives up searching for completely obvious, essential solutions. Timing costraints can help in finding out if an essential solution was found, but don't give the router all the already known information about modules. For example,. things like "just priotize these signals and everything will easily work out as the timing constraints told" just imply theoretical satisfyability, but no real world solution, if there's no way to tell the tool. "No way to tell the tool" + "stupid hobbyist realized it" prooves that there should be third party tools "to tell the tool" in some of the commericially more relevant workflows. Gruss Jan Bruns -- Ein paar Fotos: http://abnuto.de/gal/Article: 153385
I'm having trouble running the application described in XAPP740 (Designing high-performance video systems with the AXI interconnect). I have tried running the pre-built images, and building my own. In both cases it seems to hang during the initialization of the DVI transmitter. If I just run the software it sometimes sends out a few bytes to the DVI transmitter before it hangs; sometimes it hangs endlessly pulsing SCL before it sends out any valid data. If I debug the software it invariably hangs waiting for the busy bit in the status register (during the first invocation of XIic_DynSend. The core is the AXI IIC Bus Interface (v1.01a). One thing I noticed is that, while SCL always gets down to 0V, SDA sometimes gets to 0V, and sometimes only to 0.6V. I have no idea why this might be, as I see this when the V6 should be driving. I have verified that the demo images that the board is shipped with seem to work correctly. On reset I get the Xilinx splash screen, and a reasonable sequence of IIC writes and reads to the DVI transmitter. I still some weak lows though. Anybody else working with XAPP740? Any idea what might be wrong? I asked in the Xilinx forums, but received a thundering silence. Thanks PeteArticle: 153386
Jan Bruns <jansaccount@arcor.de> writes: > Hallo. > > Some questions about Xilinx LUT6 FPGAs (my WebPack Toolchain is > a little outdated, and the newer LUT6-FPGAs don't seem to show > up correctly in fpga_editor). > The datasheets and usermanuals show everything you would need I think though... see UG384 for example. Pages 9-11 show the various slices in some detail. > * Is there really no carry-bypass option in LUT6-paths like the > CYMUX(any,cin,1) living in LUT4 paths, apart from > constraining the LUTs? > I'm not sure what you mean by constraining the LUTs. There are various muxes shown in Fig 3,4,5 - can you achieve what you want with them? > * SLICEMs and SLICELs always have a carry chain, while SLICEXs > neither have a RAM nor a carry option? > Correct > * Within a CLB, SLICEMs are paired with SCLICEX (if there are > SLICEXs in the device)? Sounds strange to me: If a LUT is > configured to be dynamic, it is probably very likely that > additional Carry logic isn't used, compared to static LUTs > (with LUT4s, one rare reason to this is using the carry chain > to implement a post-invert option for the RAM...). Have you ever > seen a dynamic LUT6 really gain something in also using carry? > It seems to me that there are "big slices", "medium slices" and "smal slices" - the silicon area taken up by the carry chain may well be "free" compared to the rest of the big/medium slices. Additionally, SLICEMs can be used for dynamic filter-coefficient storage, the arithmetic logic is also useful then. Xilinx will have pushed an awful lot of existing and potential designs through this architecture and decided its a win overall. Whether it's a win for your particular designs and style is immaterial to them (unless you are an *enormous* customer!) > * What about production? Does it look like Xilinx might stop selling > and developing new LUT4-FPGAs in the near future? Selling... I doubt they'll stop selling Spartan 3 (for example) for a very long time yet - Xilinx have a long history of keeping old families going for many many years after it was sensible to design them into new systems. Developing... Spartan 3(and E,A,ADSP) was the last LUT4 generation, so yes, I think it's stopped! My understanding of the the Series 7 goal is to make as much of the user-visible logic as possible identical across the three ranges (Artix, Kintex and Virtex). There are differences in power/speed tradeoffs and the mix of memory, DSP, gigabit IO, logic etc. But the fundamental blocks are the same throughout. Unlike in the V5/S3 era when the LUTS, DSPs, BRAMs, IOs were all different between the two families! > I personally don't have enough overview about these two FPGA classes, > so I can't see the detailed pros and cons. I'm not sure there's much to care about pros and cons. LUT6 is here, unless you want to design with relatively old chips. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 153387
"pfraser" <pete_fraser@comcast.net> wrote in message news:jhfeln$79b$1@dont-email.me... > I'm having trouble running the application described in > XAPP740 (Designing high-performance video systems with the > AXI interconnect). I dont know much about this project, but something about i2c captured my attention. > One thing I noticed is that, while SCL always gets down to > 0V, SDA sometimes gets to 0V, and sometimes only to 0.6V. > I have no idea why this might be, as I see this when the > V6 should be driving. There are several possible reasons why SDA don't go all the way down. Here are two common ones. 1.High drive (somthing is driving the SDA high instead of using "releasing" it with a open drain drive). Only bad hw implementations does this. 2.Long wires. If something at the end of a long wire pulls down, there will be a voltage drop at the receiver. This happens typically when communicating with a DVI monitor over the DDC bus.Article: 153388
Oh, and I can add: A pulsing SCL can indicate that the master is trying to get SDA high so it can make a start/stop. If any slave or design error is holding SDA low, there can be no start/stop condition. This is why all i2c initiation should start with a up to 9 clock loop looking for SDA=high before sending a stop. Some implementation may be lazy and loop forever instead of giving up with an error msg. No devices will hold SDA for more than 8 clks wich makes this a guaranteed start condition. Also notice that if you hotplug i2c devices (like monitors with DDC bus), there is no guaranee that slaves are in stopped state when you attach them unless you do this init cycle. If a slave happened to be in the middle of something, got disconnected but kept its power, then reconnected later in the middle of something else, you will get conflict. This can only be solved by proper init.Article: 153389
Hi, A few years ago I've prepared the customized version of JAM STAPL Player, well suited for operation in VME based environment with SCANSTA111 bridge (open sourced and published e.g. at http://groups.google.com/group/alt.sources/browse_thread/thread/8761df1865c088f4/ce9a5358866aa4fa ). It worked correctly for a few years, but now we are forced to switch to 64-bit platform. Unfortunately the original JAM STAPL player code seems to be inherently 32-bit. I'd like to know if anybody has succesfully ported the sources of JAM STAPL Player to 64-bit platform? Is there any other open source solution which could be easily adapted to efficiently drive the JTAG chain via VME interface? -- TIA, Wojtek ZabolotnyArticle: 153390
I have found an SVF based solution: http://www.clifford.at/libxsvf/ but again there is no info if it is 64-bit safe... -- Regards, WZabArticle: 153391
Morten Leikvoll wrote: > "pfraser"<pete_fraser@comcast.net> wrote in message > >> One thing I noticed is that, while SCL always gets down to >> 0V, SDA sometimes gets to 0V, and sometimes only to 0.6V. > > There are several possible reasons why SDA don't go all the way down. Here > are two common ones. > 1.High drive (somthing is driving the SDA high instead of using "releasing" > it with a open drain drive). Only bad hw implementations does this. I haven't yet looked at the HDL. I'll do that next. > 2.Long wires. If something at the end of a long wire pulls down, there will > be a voltage drop at the receiver. This happens typically when communicating > with a DVI monitor over the DDC bus. That was my first thought, but I still get the bad low even with the monitor disconnected. Thanks PeteArticle: 153392
Morten Leikvoll wrote: > Oh, and I can add: > A pulsing SCL can indicate that the master is trying to get SDA high so it > can make a start/stop. If any slave or design error is holding SDA low, > there can be no start/stop condition. This is why all i2c initiation should > start with a up to 9 clock loop looking for SDA=high before sending a stop. > Some implementation may be lazy and loop forever instead of giving up with > an error msg. A good clue. I had noticed that, when the unit failed with the pulsing SCL, it failed before my breakpoint (i.e., earlier than I expected) and it failed with SDA low-ish. I was triggering my scope on SCL going low, so I didn't see the SDA go low. Today I'll trigger on SDA going low, and see when in the SW that happens. This is all supposed to be tested code, so I was assuming it is something wrong with my board, but perhaps I'm being too trusting. Thanks PeteArticle: 153393
hi
i am trying to detect falling edge of a 200ns pulse(WriteStrobe)
synchronously with this code. GlobalClk is 100MHz(10ns) oscillator clk
attached to global clk pin of Xilinx Spartan 3 XC3s400-5I. the problem i am
facing is that about 1000 falling edges 100 of them are missed. i used
IBUFG at the input clk but the output is the same. but if I connect the
oscillator to a normal io pin with the constraint CLOCK_DEDICATED_ROUTE =
FALSE; i can detect all the falling edges without error. i don't know
what's the problem. any help would be appreciated :)
always @(posedge GlobalClk)
begin
pre_WriteStrobe <= WriteStrobe;
if( pre_WriteStrobe & ~WriteStrobe)
begin
StartWritingMemory <=1;
WriteNibble <=0;
Write_Address <= 4095;
end
end
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 153394
nba83 wrote:
> hi
> i am trying to detect falling edge of a 200ns pulse(WriteStrobe)
> synchronously with this code. GlobalClk is 100MHz(10ns) oscillator clk
> attached to global clk pin of Xilinx Spartan 3 XC3s400-5I. the problem i am
> facing is that about 1000 falling edges 100 of them are missed. i used
> IBUFG at the input clk but the output is the same. but if I connect the
> oscillator to a normal io pin with the constraint CLOCK_DEDICATED_ROUTE =
> FALSE; i can detect all the falling edges without error. i don't know
> what's the problem. any help would be appreciated :)
> always @(posedge GlobalClk)
> begin
> pre_WriteStrobe <= WriteStrobe;
> if( pre_WriteStrobe & ~WriteStrobe)
> begin
> StartWritingMemory <=1;
> WriteNibble <=0;
> Write_Address <= 4095;
> end
> end
>
>
>
> ---------------------------------------
> Posted through http://www.FPGARelated.com
You can't use the asynchronous input in your "if" clause. To
properly sense the falling edge of an asynchronous input you
need two flops and then compare the outputs of those flops.
If instead you compare the output of the first flop to the
input signal (yes I know this would have less latency) you
have the possibility of a vanishingly small time when the
two signals are different. Then you don't meet the setup
time to the registers inside your if statement.
Try this:
reg [1:0] pre_WriteStrobe;
always @(posedge GlobalClk)
begin
pre_WriteStrobe <= {pre_WriteStrobe[0],WriteStrobe};
if( pre_WriteStrobe[1] & ~pre_WriteStrobe[0])
begin
StartWritingMemory <=1;
WriteNibble <=0;
Write_Address <= 4095;
end
end
-- Gabor
Article: 153395For those interested in FPGA CAD and architecture research, we are pleased to announce the full release of the Verilog-to-Routing (VTR) project version 1.0. VTR consists of a suite of CAD tools, circuit benchmarks, FPGA architectures, and experiment scripts to aid those in the community to explore new FPGAs as well as algorithms to map to future FPGAs. This effort is an international collaboration of researchers, and consists of three software tools: ODIN II for Verilog Elaboration, ABC (from Berkeley) for Logic Synthesis, and VPR for packing, placement, routing and timing analysis. You can find detailed information on the new release here: http://code.google.com/p/vtr-verilog-to-routing/ This new full release has many new features and has been extensively tested. It is also worth noting that all three tools are Open Source. In particular, that is now true of VPR, which is new. This new version of VTR is now fully timing driven in the packing, place and routing phase of VPR. The previous, alpha release (which was not timing-driven), enabled the description of far more complex logic blocks, including the popular Fracturable blocks (such as LUTs than can operate as one big LUT or two smaller LUTs) in modern commercial FPGAs. There is also explicit support for hard memories and multipliers from the Verilog level on down. This release contains architecture files and benchmark circuits that make use of Fracturable LUTs, memories and multipliers. The set of benchmark circuits in this release are from real applications many of which contain multipliers and memories. The largest of these circuits is almost 100,000 6-LUTs. In additional to these benchmarks, we also included the old MCNC circuits as well as a set of circuits that use embedded floating-point cores. We provide CAD/Architecture scripts that show how to run various experiments. As good science needs to be repeatable, we have included our results so that users of VTR can easily replicate the same results that we obtained. We made a strong effort to make a more user friendly build experience. Building VTR should be as simple as entering make in the main directory. Testing the flow should be as easy as running a script that reports what successfully built and what did not. If you are interested in downloading VTR or getting more information about it, please visit our website here: http://code.google.com/p/vtr-verilog-to-routing/ The VTR development team: University of Toronto: Jason Luu, Jason Anderson, Vaughn Betz, Opal Densmore, Cong Wang, Peter Milankov, Jonathan Rose University of New Brunswick: Kenneth B. Kent, Ash Furrow, Paddy O'Brien, Joey Libby, Shubham Jain, Konstantin Nasartschuk, Andrew Somerville University of British Columbia: Jeff Goeders, Eddie Hung U. Penn: Rafi Rubin U Miami, Ohio: Peter Jamieson City University of Hong Kong: Chi Wai Yu (Many thanks to Robert Brayton and Alan Mischenko at U.C. Berkeley for the use of the ABC Logic Synthesis tool).Article: 153396
Martin Thompson: > Jan Bruns: >> Some questions about Xilinx LUT6 FPGAs (my WebPack Toolchain is a >> little outdated, and the newer LUT6-FPGAs don't seem to show up >> correctly in fpga_editor). > The datasheets and usermanuals show everything you would need I think > though... see UG384 for example. Pages 9-11 show the various slices in > some detail. Thanks. I've tested the wrong datasheets then. >> * Is there really no carry-bypass option in LUT6-paths like the >> CYMUX(any,cin,1) living in LUT4 paths, apart from constraining the >> LUTs? > I'm not sure what you mean by constraining the LUTs. There are various > muxes shown in Fig 3,4,5 - can you achieve what you want with them? The select-Input of the main Carry-Select Muxes is directly connected to the LUT-output, without an option to put another signal on it. If you make use of the Carry Logic, the function you put on the LUT will always become part of the Carry calculation. Xilinx LUT4 FPGAs had an option to make the main CarrySelect Mux always fprward the cin to cout, no matter of the LUT said. This was pretty useful, because it was possible to make relatively huge logic feed the Carry Chain, without ever crossing CLB boundaries. For example, within a SLICE, it was possible to have one LUT act as 16-bit RAM, and have it added (or whatever) to some external value on the other LUT. The RAM-LUTs output was not expected to directly connect to the Carry Logic, but had relatively fast routes to the arithmetic then. However, I'd expect many reasons to use "partial populated" carry chains to be gone with LUT6. >> * Within a CLB, SLICEMs are paired with SCLICEX (if there are >> SLICEXs in the device)? Sounds strange to me: If a LUT is configured >> to be dynamic, it is probably very likely that additional Carry logic >> isn't used, compared to static LUTs (with LUT4s, one rare reason to >> this is using the carry chain to implement a post-invert option for >> the RAM...). Have you ever seen a dynamic LUT6 really gain something >> in also using carry? > It seems to me that there are "big slices", "medium slices" and "smal > slices" - the silicon area taken up by the carry chain may well be > "free" compared to the rest of the big/medium slices. Hmn, sounds like that's only one theory of yours. > Additionally, SLICEMs can be used for dynamic filter-coefficient > storage, the arithmetic logic is also useful then. Hm, what about details, then? A dynloadable LUT1 calculating "external signal xor stored bit"? > Xilinx will have pushed an awful lot of existing and potential designs > through this architecture and decided its a win overall. > Whether it's a win for your particular designs and style is immaterial > to them (unless you are an *enormous* customer!) Compared to what? LUT4 vs. LUT6, given the same silicon process? What would you expect the term "win" to represent, then? I don't believe there's no market for LUT4 FPGAs using current silicon process. >> * What about production? Does it look like Xilinx might stop selling >> and developing new LUT4-FPGAs in the near future? > Selling... I doubt they'll stop selling Spartan 3 (for example) for a > very long time yet - Xilinx have a long history of keeping old families > going for many many years after it was sensible to design them into new > systems. > Developing... Spartan 3(and E,A,ADSP) was the last LUT4 generation, so > yes, I think it's stopped! >> I personally don't have enough overview about these two FPGA classes, >> so I can't see the detailed pros and cons. > I'm not sure there's much to care about pros and cons. LUT6 is here, > unless you want to design with relatively old chips. Argh. So all these valuable customers have to rework all parts of their highly optimized, huge module database, just because Xilinx engineers thought it might be less work for them to ever put LUT6 in silicon? Gruss Jan Bruns -- Ein paar Fotos: http://abnuto.de/gal/Article: 153397
On Feb 15, 10:21=A0pm, Jan Bruns <jansacco...@arcor.de> wrote: > I don't believe there's no market for LUT4 FPGAs using current > silicon process. Market: Maybe. Resonable facts to support such an architecture: No. The problem here is that users tend to evaluate the capabilites of an FPGA mainly as logic, while really you pay mostly for routing. Logic is a very small portion of the silicon area. Of course the vendors don't publish the numbers, but university research suggests the area of LUT and LUT configuration is only a few percent of total area. Therefore when going from 4-LUT to 6-LUT you don't get a 4x area increase (16 entries to 64 entries) but more like a 60% increase (going from 4 inputs that must be routed to 6 inputs that must be routed in a somewhat worse than linear routing area). This is offset by the fact that routing now gets a lot simpler. Routing increases faster than linear with the number of wires. Therefore with bigger FPGAs the percentage of logic goes down. The optimum LUT size therefore tends to go up with technology improvements. Research shows that the efficiency curve for FPGA technologies is relatively flat around the optimum. E.g. for a given technology there are multiple LUT sizes that get you almost the same area efficiency. Because performce tends to be better for the larger LUTs and because the software runtimes go down for larger LUTs (mapping is polynomial time, routing exponential) a typical design decision would be to chose the largest LUT size within the flat region of the curve, expecting that future implementations of the architecture would move the optimum spot in that direction. This is exactly what FPGA vendors did: In the early 90ies the sweet spot was consistenly show to be between 3- LUTs and 4-LUTs so most vendors chose 4-LUTs. Newer research shows the flat region to be go from 4-LUTs to 6-LUTs. While 4-LUTs probably would be still a good choice, it is clear that there must be switch to 6-LUTs at some time, and one might just as well do the switch now getting much better EDA software run times. Kolja Sulimma cronologic.deArticle: 153398
Jan Bruns <jansaccount@arcor.de> writes: > Martin Thompson: >> Jan Bruns: > >>> * Is there really no carry-bypass option in LUT6-paths like the >>> CYMUX(any,cin,1) living in LUT4 paths, apart from constraining the >>> LUTs? > >> I'm not sure what you mean by constraining the LUTs. There are various >> muxes shown in Fig 3,4,5 - can you achieve what you want with them? > > The select-Input of the main Carry-Select Muxes is directly connected > to the LUT-output, without an option to put another signal on it. > If you make use of the Carry Logic, the function you put on the LUT > will always become part of the Carry calculation. > > Xilinx LUT4 FPGAs had an option to make the main CarrySelect Mux always > fprward the cin to cout, no matter of the LUT said. This was pretty > useful, because it was possible to make relatively huge logic feed > the Carry Chain, without ever crossing CLB boundaries. > > For example, within a SLICE, it was possible to have one LUT act as > 16-bit RAM, and have it added (or whatever) to some external value on > the other LUT. The RAM-LUTs output was not expected to directly > connect to the Carry Logic, but had relatively fast routes to > the arithmetic then. > > However, I'd expect many reasons to use "partial populated" > carry chains to be gone with LUT6. > Yes, I agree. No doubt there will be *some* designs which don't work out so well in the newer architectures. >>> * Within a CLB, SLICEMs are paired with SCLICEX (if there are >>> SLICEXs in the device)? Sounds strange to me: If a LUT is configured >>> to be dynamic, it is probably very likely that additional Carry logic >>> isn't used, compared to static LUTs (with LUT4s, one rare reason to >>> this is using the carry chain to implement a post-invert option for >>> the RAM...). Have you ever seen a dynamic LUT6 really gain something >>> in also using carry? > >> It seems to me that there are "big slices", "medium slices" and "smal >> slices" - the silicon area taken up by the carry chain may well be >> "free" compared to the rest of the big/medium slices. > > Hmn, sounds like that's only one theory of yours. > Well, yes, it is - you'll have to wait for someone from Xilinx for anything better than that :) >> Additionally, SLICEMs can be used for dynamic filter-coefficient >> storage, the arithmetic logic is also useful then. > > Hm, what about details, then? Well, I only offer it as a possibility (haven't done an actual comparison), but distributed arithmetic FIR filters were what I was thinking of. >> Xilinx will have pushed an awful lot of existing and potential designs >> through this architecture and decided its a win overall. >> Whether it's a win for your particular designs and style is immaterial >> to them (unless you are an *enormous* customer!) > > Compared to what? LUT4 vs. LUT6, given the same silicon process? > What would you expect the term "win" to represent, then? > Don't ask me - I'm not making the decisions. Ultimately, Xilinx presumably decided it was a "win" in business terms: "We'll make the most money doing it this way." > I don't believe there's no market for LUT4 FPGAs using current > silicon process. No-one is saying there is not a market. Just that it's not big enough for Xilinx to be targetting it. > >>> * What about production? Does it look like Xilinx might stop selling >>> and developing new LUT4-FPGAs in the near future? > >> Selling... I doubt they'll stop selling Spartan 3 (for example) for a >> very long time yet - Xilinx have a long history of keeping old families >> going for many many years after it was sensible to design them into new >> systems. > >> Developing... Spartan 3(and E,A,ADSP) was the last LUT4 generation, so >> yes, I think it's stopped! > >>> I personally don't have enough overview about these two FPGA classes, >>> so I can't see the detailed pros and cons. > >> I'm not sure there's much to care about pros and cons. LUT6 is here, >> unless you want to design with relatively old chips. > > Argh. So all these valuable customers have to rework all parts of > their highly optimized, huge module database, That's progress :) This is how bare-metal-assembly-language programmers felt as processors developed and their highly-tuned routines needed to be rewritten. Of course, the processors were faster and compilers were better, so the smart ones just wrote straightforward, portable C-code which turned out to be good-enough most of the time. And that code was much more re-usable. > just because Xilinx engineers thought it might be less work for them > to ever put LUT6 in silicon? I'm sure it wasn't done on a whim! There are sound business reasons for how it's been done. Sounds like they just don't fit what you'd like :( Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 153399
Martin Thompson <martin.j.thompson@trw.com> wrote: (snip) > Don't ask me - I'm not making the decisions. Ultimately, Xilinx > presumably decided it was a "win" in business terms: "We'll make the > most money doing it this way." Well, they do have some competition. If they don't design and build what works for their customers, they will lose out. >> I don't believe there's no market for LUT4 FPGAs using current >> silicon process. > No-one is saying there is not a market. Just that it's not > big enough for Xilinx to be targetting it. As I understand it, 6LUT is better for larger chips. For smaller ones, it likely doesn't make so much difference. There is some advantage as far as synthesis software of keeping a minimum number of different architectures. Still, 4LUT chips should be around for a while. -- glen
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