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
On Mar 11, 8:25=A0am, Symon <symon_bre...@hotmail.com> wrote: > > Hi Jeff, > I've examined all the old FPGAs I've found in my office, and they all > seem to have three dimensions already. Even the old ones from 1986. Hehe ;) - yes, even Tabula are trying to spin 3D too... Still, getting back to the site itself, it seems they have a Stacked-die prototype path, and the main thrust is really mask- asic. The stacked die 'emulation devices' will come at a large price premium, and their config density will need to be low (given this is top-layer stuff). I'd expect a power premium too... The advantage is you CAN get closer to real field emulation, (as opposed to devices like Atmel's CAPxx, which can only offer bench- emulation, via a large FPGA) [" Free NRE Qualifying production orders of $50k+ for converting an existing production FPGA to a compatible TierASIC=99 device are eligible for free NRE and conversion."] That leaves the final chestnuts, of packaging and Price. One opening I can see in CPLD/FPGA space, is smaller devices with MORE RAM. - ie really a RAM+CPLD, or a smart ram, if you like. That type of product also tends to be somewhat more stable in code, so could suit TierLogic flows. Full DualPort memories are very expensive, and large, and FPGAs have low SRAM levels, until you get very large. The ProgLogic+Micro space is filling up: Atmel & ST target the ramping-volume with their MASK variants, and we have Cypress and Actel with FlashuC+ProgLogic offerings. -jgArticle: 146276
On Mar 10, 12:08=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > It would be interesting to have an FPGA with transparent latches > after each LUT instead of the current edge triggered FFs. > > -- glen Glen, I simplified a little. I was frustrated by all the VHDL mumbo- jumbo. To answer your suggestion: Use Xilinx FPGAs. I know for sure that Virtex 5, and probably also 4 and 6 can configure each flip-flop as a latch, although this is a rarely-used feature. (How fast I forget such exotic facts). PeterArticle: 146277
On Mar 11, 5:46=A0am, Tier Logic <jeff.ka...@gmail.com> wrote: > The world's first 3D FPGA has arrived! We have a very compelling and > cost effective solution. > > Come check it out folks.www.tierlogic.com Pity, rather a bad fumble at first hurdle. The Prog Logic space is VERY broad indeed, and yet there is NO indication of which parts of that TierLogic target: Even the simplest things, like packages and speeds. Imagine Toyota saying "We have a new product, with 4 wheels - sign up to learn more". ?! -jgArticle: 146278
In comp.arch.fpga Peter Alfke <alfke@sbcglobal.net> wrote: (snip) > To answer your suggestion: > Use Xilinx FPGAs. I know for sure that Virtex 5, and probably also 4 > and 6 can configure each flip-flop as a latch, although this is a > rarely-used feature. > (How fast I forget such exotic facts). I didn't know that! There is discussion in another newsgroup about recreating the IBM 360/91 in an FPGA. I believe that is the machine that the Earle latch was invented for. (Maybe it was the Stretch.) The Earle latch pretty much takes one level of logic and combines it with the logic of a transparent latch. When every propagation delay counts, that helps a lot. -- glenArticle: 146279
On Mar 10, 3:14=A0pm, -jg <jim.granvi...@gmail.com> wrote: > On Mar 11, 8:25=A0am, Symon <symon_bre...@hotmail.com> wrote: > > > Hi Jeff, > > I've examined all the old FPGAs I've found in my office, and they all > > seem to have three dimensions already. Even the old ones from 1986. > > Hehe ;) - yes, even Tabula are trying to spin 3D too... > > =A0Still, getting back to the site itself, it seems they > have a Stacked-die prototype path, and the main thrust is really mask- > asic. > > =A0The stacked die 'emulation devices' will come at a large price > premium, and their config density will need to be low (given this is > top-layer stuff). > I'd expect a power premium too... Stacked die? I read the eetimes article and didn't get anything about stacked die from Tier Logic. Did I read something wrong? I thought they were layering TFT on top of the base die to provide the config memory which takes it out of the base die saving real estate. I am sure the savings is somewhat mitigated by the need for vias to the lower layers, but still a 35% (or something like that) savings in size is nothing to sneeze it. I bet AMD wishes they could get that on their CPU die right now! > =A0The advantage is you CAN get closer to real field emulation, (as > opposed to devices like Atmel's CAPxx, which can only offer bench- > emulation, via a large FPGA) They seem to be pushing their ability to more easily move to ASIC production, but they seem to offer something to the FPGA only user as well. I'd be willing to bet there is a premium compared to ASICs so they are taking a middle ground in that regard. > [" Free NRE > Qualifying production orders of $50k+ for converting an existing > production FPGA to a compatible TierASIC=99 device are eligible for free > NRE and conversion."] > > That leaves the final chestnuts, of packaging and Price. > > =A0One opening I can see in CPLD/FPGA space, is smaller devices with > MORE RAM. - ie really a RAM+CPLD, or > a smart ram, if you like. > =A0That type of product also tends to be somewhat more > stable in code, so could suit TierLogic flows. > > =A0Full DualPort memories are very expensive, and large, > and FPGAs have low SRAM levels, until you get very large. > > =A0The ProgLogic+Micro space is filling up: Atmel & ST target the > ramping-volume with their MASK variants, and > we have Cypress and Actel with FlashuC+ProgLogic offerings. I'm not clear on what you are saying about this in regards to Tier Logic. RickArticle: 146280
On Mar 10, 12:31=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > In comp.arch.fpga Peter Alfke <al...@sbcglobal.net> wrote: > (snip) > > > To answer your suggestion: > > Use Xilinx FPGAs. I know for sure that Virtex 5, and probably also 4 > > and 6 can configure each flip-flop as a latch, although this is a > > rarely-used feature. > > (How fast I forget such exotic facts). > > I didn't know that! =A0 > > There is discussion in another newsgroup about recreating the > IBM 360/91 in an FPGA. =A0I believe that is the machine that the > Earle latch was invented for. =A0(Maybe it was the Stretch.) > > The Earle latch pretty much takes one level of logic and combines > it with the logic of a transparent latch. =A0When every propagation > delay counts, that helps a lot. =A0 > > -- glen Glen: from the Virtex-6 User Guide Lite: The look-up tables (LUTs) in Virtex-6 FPGAs can be configured as either 6-input LUT (64-bit ROMs) with one output, or as two 5-input LUTs (32-bit ROMs) with separate outputs but common addresses or logic inputs. Each LUT output can optionally be registered in a flip-flop. Four such LUTs and their eight flip-flops as well as multiplexers and arithmetic carry logic form a slice, and two slices form a configurable logic block (CLB). Four flip-flops per slice (one per LUT) can optionally be configured as latches. In that case, the remaining four flip-flops in that slice must remain unused. So, that says it: 4 latches per slice. Perhaps not the highest efficiency, but not too bad. PS, I am very proud of these User Guides Lite, created and published as a bootleg project, but still very popular with users. PeterArticle: 146281
On Mar 11, 10:41=A0am, rickman <gnu...@gmail.com> wrote: > On Mar 10, 3:14=A0pm, -jg <jim.granvi...@gmail.com> wrote: > > > > > On Mar 11, 8:25=A0am, Symon <symon_bre...@hotmail.com> wrote: > > > > Hi Jeff, > > > I've examined all the old FPGAs I've found in my office, and they all > > > seem to have three dimensions already. Even the old ones from 1986. > > > Hehe ;) - yes, even Tabula are trying to spin 3D too... > > > =A0Still, getting back to the site itself, it seems they > > have a Stacked-die prototype path, and the main thrust is really mask- > > asic. > > > =A0The stacked die 'emulation devices' will come at a large price > > premium, and their config density will need to be low (given this is > > top-layer stuff). > > I'd expect a power premium too... > > Stacked die? =A0I read the eetimes article and didn't get anything about > stacked die from Tier Logic. =A0Did I read something wrong? =A0I thought > they were layering TFT on top of the base die to provide the config > memory which takes it out of the base die saving real estate. Yes they are, which is why I called it stacked die. - TWO die flows, one on top of the other. Base die is made, and then they have a second die-process that is more complex than just TFT, as it included connections. [Testing questions remain?] That will also be why they needed a lot more passes at the TFT section, as that's where the 'new tech' mostly lies. > They seem to be pushing their ability to more easily move to ASIC > production, but they seem to offer something to the FPGA only user as > well. =A0 A key question here will be: if you are unlikely to need ASIC, why start with their devices ? > I'm not clear on what you are saying about this in regards to Tier Logic. It was a general comment, about where there is space for new-comers, or new-products in the market. I've often found RAM dictates the Device choice, more than the Logic. -jgArticle: 146282
Yes, the problem was in RS232 :) Actually I don't know why. I wrote simple module to write data to RS232 from FPGA and problem appeared when I'd like send "00" Thanks for cooperation LukaArticle: 146283
On Mar 10, 4:54=A0pm, -jg <jim.granvi...@gmail.com> wrote: > On Mar 11, 10:41=A0am, rickman <gnu...@gmail.com> wrote: > > > > > On Mar 10, 3:14=A0pm, -jg <jim.granvi...@gmail.com> wrote: > > > > On Mar 11, 8:25=A0am, Symon <symon_bre...@hotmail.com> wrote: > > > > > Hi Jeff, > > > > I've examined all the old FPGAs I've found in my office, and they a= ll > > > > seem to have three dimensions already. Even the old ones from 1986. > > > > Hehe ;) - yes, even Tabula are trying to spin 3D too... > > > > =A0Still, getting back to the site itself, it seems they > > > have a Stacked-die prototype path, and the main thrust is really mask= - > > > asic. > > > > =A0The stacked die 'emulation devices' will come at a large price > > > premium, and their config density will need to be low (given this is > > > top-layer stuff). > > > I'd expect a power premium too... > > > Stacked die? =A0I read the eetimes article and didn't get anything abou= t > > stacked die from Tier Logic. =A0Did I read something wrong? =A0I though= t > > they were layering TFT on top of the base die to provide the config > > memory which takes it out of the base die saving real estate. > > Yes they are, which is why I called it stacked die. > - TWO die flows, one on top of the other. > > =A0Base die is made, and then they have a second die-process that is > more complex than just TFT, as it > included connections. [Testing questions remain?] > > =A0That will also be why they needed a lot more passes at the TFT > section, as that's where the 'new tech' mostly lies. Uh, "stacked die" is normally used to refer to putting two distinct die mechanically on top of each other. That is a very different thing than adding processing steps to an existing flow, which is what has been described for this part. > > They seem to be pushing their ability to more easily move to ASIC > > production, but they seem to offer something to the FPGA only user as > > well. =A0 > > A key question here will be: if you are unlikely to > need ASIC, why start with their devices ? They claim an advantage in die size which normally translates into a cost advantage. Of course, the question of cost will be answered when they start shipping product, or at least quoting prices. > > I'm not clear on what you are saying about this in regards to Tier Logi= c. > > =A0It was a general comment, about where there is space for new-comers, > or new-products in the market. > > =A0I've often found RAM dictates the Device choice, more than the Logic. I wish I had that luxury. For me it is typically package since my designs tend to be size constrained; low pin count (100 or less) in PCB layout and manufacturing friendly packages are always welcome (read that as TQFPs or possibly QFNs). Right now I am trying to squeeze 10 pounds of logic into a 5 pound FPGA because it was the only one that fit the bill, a bill that was designed a year and a half ago. RickArticle: 146284
lusch <lukaszschodowski@gmail.com> wrote: >Yes, the problem was in RS232 :) Actually I don't know why. >I wrote simple module to write data to RS232 from FPGA and problem >appeared when I'd like send "00" Probably a getchar() / C style strings problem. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 146285
On Mar 10, 2:22=A0pm, lusch <lukaszschodow...@gmail.com> wrote: > Yes, the problem was in RS232 :) Actually I don't know why. > I wrote simple module to write data to RS232 from FPGA and problem > appeared when I'd like send "00" > > Thanks for cooperation > Luka I think previously you said that you were using a displaying the result in HEX in your terminal program. Gabor pointed out that RS-232 would ignore 00 unless you were in binary (vs ascii) mode. Your reply here wasn't The value 00 is the same as 0 which is also NULL or end-of-string in C software. You haven't said how the value is sent to the RS-232 port, but if you were using MicroBlaze and printf think that this could be getting swallowed by the software routine. In order to separate the issue between the Memory read/write and the RS-232 transmit. I would suggest that you change your design to simple write a number of zero and non-zero values to the RS-232 and see if these appear correctly in your RS-232 terminal. Ed McGettigan -- Xilinx Inc.Article: 146286
On Mar 11, 11:29=A0am, rickman <gnu...@gmail.com> wrote: > On Mar 10, 4:54=A0pm, -jg <jim.granvi...@gmail.com> wrote: > > Yes they are, which is why I called it stacked die. > > - TWO die flows, one on top of the other. > > > Uh, "stacked die" is normally used to refer to putting two distinct > die mechanically on top of each other. =A0 That depends on where you are in the time-line :) Years ago, 'stacked die' meant post-wafer assembly using bond-wires & discrete die, but more modern "nailed stacked die" schemes use vias, and are done at the wafer level. ie See this fig2 of "nailed stacked die " here : http://www.flipchips.com/tutorial71.html and compare with the image here : http://www.tierlogic.com/uploads/press-room-files/Tier-Logic-Cross-Sections= -of-TierFPGA-and-TierASIC-Devices.pdf The 'different process', and multiple Transistor planes, is now more a distinguishing feature, than a literal interpretation of 'die'. Tierlogic are quite clear they use Stacked (different) processes, and via type contacts. Doing the stacking at the wafer/fab level saves handling, but you are exposed to testing issues. Until you have finished the two-process flows, you really have nothing to test. So yields are ?? Default TFT flows are also higher voltage, and relatively coarse grained. So the bit-counts will be interestng to see, when they are finally revealed. -jgArticle: 146287
On 10/03/10 14:55, Pallavi wrote: > Hi, I'm doing this project using ISE 9.2i and am getting the ngd build > error: 604 during translation. Can anyone please let me know how to resolve > this error. I'm able to synthesize the code successfully. Thanks. > > --------------------------------------- > Posted through http://www.FPGARelated.com Try typing ngdbuild 604 into Google, regards Alan -- Alan FitchArticle: 146288
-jg wrote: > On Mar 9, 7:25 am, Jon Elson <jmel...@wustl.edu> wrote: >> -jg wrote: >> I make a line of products that have multiple quadrature encoder counters >> in FPGAs. I've been thinking that due to the digital filtering of the >> inputs that is required, I could time multiplex the logic of these >> counters pretty easily and save a bunch of space. The filtering runs at >> 1 MHz! But, I could just as easily figure out how to do this in the HDL >> of my choice, with just a little thinking. > > If you have spare BRAM, that can easily create many time-sliced > counters, with a simple add/subt. > > At a guess, a Xmos part could likely manage ~32 x 32 bit quad > counters, at 1MHz poll rates. But, you'd QUICKLY run out of I/O pads! So, such level of multiplexing doesn't take much advantage of the possibilities. If a much larger task than quadrature counting was needed, then you'd get a bigger benefit. As it is in the project mentioned above, I'm tight on pins with a 144-pin Spartan 2 FPGA (there's a lot of other stuff on it than the 4 quadrature counters), but could add a few more counters. JonArticle: 146289
rickman wrote: > Multiplexing things like counters is not very efficient because of the > granularity. A counter is no more complex in an FPGA than a 2 input > mux. If you add a mux to share a counter in two processes you gain > nothing. But, if you replace N counters with one adder/subtracter and a BRAM, it may well save real estate. Muxing 2 counters seems pointless, but maybe when it gets to replacing 8 counters with one add/sub block it pays off. Even at 8 units it may just be a lot simpler to leave it dedicated hardware. If I had the I/O lines, I could probably multiplex 40 counters at 1 MHz to one add/sub running at 40 MHz and save a BUNCH of area, but with the index pulse, each counter would take 3 inputs for 120 pins. We don't need 40 quadrature counters on one chip, anyway. JonArticle: 146290
Hi ASICFriends, I'm using XILINX ISE WebPack, release 8.2 (due to compatibility issues with older projects). Does anyone know how to make some symbol inputs to be "don't care" inside an ISE schematic ? For example, at some mux inputs ? As we can do on VHDL or Verilog ? I expect that such issues would allow the synthesis tools to better optimize the design. Nowadays I manually tie every unused input to '0' (GND) or '1' (VCC) sources and the synthesis tool really reduces and optmize the logic as expected. However, I choose between '1' or '0' by my own analysis. Is there a way to name these inputs on the schematic as 'X' or something ? Greetings to you all TUDA PelliniArticle: 146291
On Mar 10, 1:24=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Mar 10, 10:06=A0am, Andy <jonesa...@comcast.net> wrote: > > > On Mar 9, 12:15=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > I would strongly encourage you to change the RESET function from > > > asynchronous to synchronous. > > > On what basis do you make this recommendation, and what does this have > > to do with latches? > > > Andy > > Synchronous versus asynchronous resets have been discussed at length > in other threads. > > Asynchronous resets have their place in a designer's toolbox, however > they should be used sparingly. =A0Some reasons to use these are for > handshakes crossing clock domains, anticipated loss of clock and > asynchronous inputs to the synchronous domain. > > In a synchronous domain, such as the original state machine example, > the asynchronous functionality offers no additional benefit in FPGAs > as the area cost is identical for both. > > Asynchronously asserting and de-asserting a reset across multiple > registers may/will result in the registers being released before and > after a clock edge due to large net delay and skew on the reset net. > This will result in different parts of a design coming out of reset > across clock boundaries and being out of sync with each other. > > Synchronous resets simplify timing analysis and timing closure without > having to worry about the consequences of the asynchronous functions > and how to correctly constrain them. > > I often see problems with FPGA designs that are built with > asynchronous resets, but I have yet to see a problem with a FPGA > design that was traced to a synchronous reset. > > In an FPGA there is no downside to a synchronous reset, but there are > many pitfalls with an asynchronous reset. > > None of this has anything to do with a latch, which you also want to > avoid using in an FPGA. > > Ed McGettigan > -- > Xilinx Inc. Given that most sources of reset signals are not already synchronized to the clock domain(s) that need resetting, both asynchronous and syncrhonous resets require at least the deasserting edge to be synchronized. Proper syncrhonization for each case takes the same amount of design effort and resources. I will agree that getting the constraints set to make sure that the synchronous deassertion path meets timing in an asynchronously reset system can be non-obvious, but that is a tools issue, not a design issue (in other words, fix the tools!) Given that an asynchronous reset reliably resets the circuit, regardless of the presence or stability of the clock signal, when an asynchronous reset is correctly designed, it is a more reliable reset than a synchronous one. AndyArticle: 146292
On Mar 10, 4:25=A0pm, Andy <jonesa...@comcast.net> wrote: > On Mar 10, 1:24=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > > > > On Mar 10, 10:06=A0am, Andy <jonesa...@comcast.net> wrote: > > > > On Mar 9, 12:15=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > > I would strongly encourage you to change the RESET function from > > > > asynchronous to synchronous. > > > > On what basis do you make this recommendation, and what does this hav= e > > > to do with latches? > > > > Andy > > > Synchronous versus asynchronous resets have been discussed at length > > in other threads. > > > Asynchronous resets have their place in a designer's toolbox, however > > they should be used sparingly. =A0Some reasons to use these are for > > handshakes crossing clock domains, anticipated loss of clock and > > asynchronous inputs to the synchronous domain. > > > In a synchronous domain, such as the original state machine example, > > the asynchronous functionality offers no additional benefit in FPGAs > > as the area cost is identical for both. > > > Asynchronously asserting and de-asserting a reset across multiple > > registers may/will result in the registers being released before and > > after a clock edge due to large net delay and skew on the reset net. > > This will result in different parts of a design coming out of reset > > across clock boundaries and being out of sync with each other. > > > Synchronous resets simplify timing analysis and timing closure without > > having to worry about the consequences of the asynchronous functions > > and how to correctly constrain them. > > > I often see problems with FPGA designs that are built with > > asynchronous resets, but I have yet to see a problem with a FPGA > > design that was traced to a synchronous reset. > > > In an FPGA there is no downside to a synchronous reset, but there are > > many pitfalls with an asynchronous reset. > > > None of this has anything to do with a latch, which you also want to > > avoid using in an FPGA. > > > Ed McGettigan > > -- > > Xilinx Inc. > > Given that most sources of reset signals are not already synchronized > to the clock domain(s) that need resetting, both asynchronous and > syncrhonous resets require at least the deasserting edge to be > synchronized. Proper syncrhonization for each case takes the same > amount of design effort and resources. > > I will agree that getting the constraints set to make sure that the > synchronous deassertion path meets timing in an asynchronously reset > system can be non-obvious, but that is a tools issue, not a design > issue (in other words, fix the tools!) > > Given that an asynchronous reset reliably resets the circuit, > regardless of the presence or stability of the clock signal, when an > asynchronous reset is correctly designed, it is a more reliable reset > than a synchronous one. > > Andy- Hide quoted text - > > - Show quoted text - I wouldn't take it as a given that most resets are not already synchronized to the clock domains. Resets are routinely used based on termination count, end of packet, return to state0 from other states or invalid states, etc.... All of these cases would be within the same clock domain. Placing the onus of creating a reliable design on software tools to correctly determine the designer's intent for timing paths that are "non-obvious" is not a working solution IMHO. The cons of an asynchronous reset significantly outweigh the single pro that the reset will occur in the absence of clock. Ed McGettigan -- Xilinx Inc.Article: 146293
On Mar 11, 2:01=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > The cons of an asynchronous reset significantly outweigh the single > pro that the reset will occur in the absence of clock. For Logic 'buried deep', that would be correct, but for pin-drive logic, having a defined state BEFORE the clock, can be quite mission-critical. -jgArticle: 146294
On Mar 10, 5:10=A0pm, -jg <jim.granvi...@gmail.com> wrote: > On Mar 11, 2:01=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > The cons of an asynchronous reset significantly outweigh the single > > pro that the reset will occur in the absence of clock. > > =A0For Logic 'buried deep', that would be correct, but > for pin-drive logic, having a defined state BEFORE the clock, can be > quite mission-critical. > > =A0-jg I absolutely agree that asynchronous resets have a very valid use in certain cases. My position is that should be avoided in the general case. FPGAs with the asynchronous global set/reset can also get you into that known state before any clocks are applied. Ed McGettigan -- Xilinx Inc.Article: 146295
On Mar 10, 5:42=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Mar 10, 5:10=A0pm, -jg <jim.granvi...@gmail.com> wrote: > > > On Mar 11, 2:01=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > The cons of an asynchronous reset significantly outweigh the single > > > pro that the reset will occur in the absence of clock. > > > =A0For Logic 'buried deep', that would be correct, but > > for pin-drive logic, having a defined state BEFORE the clock, can be > > quite mission-critical. > > > =A0-jg > > I absolutely agree that asynchronous resets have a very valid use in > certain cases. =A0My position is that should be avoided in the general > case. > > FPGAs with the asynchronous global set/reset can also get you into > that known state before any clocks are applied. > > Ed McGettigan > -- > Xilinx Inc. Andy, "Some synthesis tools may be getting smart enough to optimize an inferred latch from a combinatorial process into a clock enable on the corresponding register implied by the clocked process. But if there are any other combinatorial processes that use that latched output of the first combinatorial process, then the latch cannot be replaced by a clock enable on a register. " I am interested in above your comment. Can you list an example to show "the latch cannot be replaced by a clock enable on a register" My opinion is that you never will find an example to support your claim. 1. Whether generating a latch for a intermediate data or not doesn't change a state machine's behavior. Do you agree? 2. In a synchronous system, signal's data is valid and used near the clock triggering edge: between set-up time and hold time. Generating a latch for intermediate data for a state machine would make system slower, not faster in any situation. 3. Timing for other signals may be affected, of course. Weng AndyArticle: 146296
On Mar 10, 7:06=A0pm, Jon Elson <jmel...@wustl.edu> wrote: > > But, if you replace N counters with one adder/subtracter and a BRAM, it > may well save real estate. =A0Muxing 2 counters seems pointless, but mayb= e > when it gets to replacing 8 counters with one add/sub block it pays off. > Even at 8 units it may just be a lot simpler to leave it dedicated > hardware. =A0If I had the I/O lines, I could probably multiplex 40 > counters at 1 MHz to one add/sub running at 40 MHz and save a BUNCH of > area, but with the index pulse, each counter would take 3 inputs for 120 > pins. =A0We don't need 40 quadrature counters on one chip, anyway. > > Jon The thing I liked about multiplexing large counters (I had about 7 values I needed to keep track of) was the reduction in readout logic. If I use a distributed CLB SelectRAM for the count values, I can read multiple values from the memory without adding (much) readout logic. In my case, I had 27-bit counters which were only read after the counting events so the CLB SelectRAM was single port. Seven 27-bit counters and associated readout, implemented in around 60 LUTs. Not bad. The "simple" approach would have been about 300 LUTs once readout is thrown in.Article: 146297
austin wrote: > Except you require registration to even see what it is that you have. At least they don't require NDAs etc. for basic information. I don't see any problem in registration or even NDAs. A and X also require NDAs before they tell anything about their future products. > What are you afraid of? Competition? Possibly yes. The big guys are very happy to steal the good ideas of the smaller ones and use their muscle to push the innovations to their products, and the original inventor gets nothing (unless they vere good at patenting it). > So, until you decide to stop "qualifying customers" I am afraid you > will remain a relatively unknown company. A and X qualify also customers for early access etc. And for a small startup the qualifying is even more important, they don't have the muscle to support big amount of customers. > That is OK: the longer it takes for you to make money, the more > likely the investors pull the plug, and you go away like all the other > FPGA companies have in the past. The money is not in the hobbyist market but on the big accounts. And big accuounts have no problem with registration, NDAs etc. --KimArticle: 146298
-jg wrote: > Doing the stacking at the wafer/fab level saves handling, but you are > exposed to testing issues. > > Until you have finished the two-process flows, you really have > nothing to test. So yields are ?? I don't see it impossible to test the cmos wafer before the tft process, depending on how they constructed the topmost metal layer. For example they could have some dummy bump pads there for power, and then internal bist with certain coverage built with the lower metal layers. FPGAs are quite easy in terms of yield, because you can have redundant structures for yield improvement (in fabric and in memories). --KimArticle: 146299
On Mar 10, 10:54=A0pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > -jg wrote: > > =A0Doing the stacking at the wafer/fab level saves handling, but you ar= e > > exposed to testing issues. > > > =A0Until you have finished the two-process flows, you really have > > nothing to test. So yields are ?? > > I don't see it impossible to test the cmos wafer before the tft process, > depending on how they constructed the topmost metal layer. For example > they could have some dummy bump pads there for power, and then internal > bist with certain coverage built with the lower metal layers. > > FPGAs are quite easy in terms of yield, because you can have redundant > structures for yield improvement (in fabric and in memories). > > --Kim I don't want to marketeer too much here because this is a technical site. All I can tell you is that our FPGAs will save you money because our die size is reduced. If you convert it to our ASIC you will save even more money for a minimal NRE. ( zero NRE for early access customers). I did want to clear up any questions on our testing methodolgies. Our FPGA is tested the same as any other SRAM based FPGA is tested. The only difference is that our configuration SRAM is above the CMOS base layer in a second active layer resulting in a smaller die size. We test it to 100% functional FPGA test patterns in the same way any other SRAM-based FPGA is tested. There is no need to test until the complete FPGA is done being processed. The TierASIC is tested with a scan-based ASIC methodology we added to the silicon. The customer is not required to generate any test vectors. Once you lock your design, you simply send us the bitstream and we auto generate the test vectors for your ASIC. We create one M9 hard mask and stop there. I do believe that the significant cost reduction in moving from our FPGA to our ASIC will make it a popular choice. You also get the advantages of no possibility of configuration SEUs, bitstream security, no config rom needed, instant on, and customer logos. The yield of the ASIC increases over the yield of the FPGA because the ASIC is only tested to that customer pattern. Also, the timing is identical to the FPGA version which means zero conversion risk. We can deliver ASIC samples in about 4 weeks. Jeff
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