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
I wrote: > I meant what things the optimizer can do. It has to preserve certain > invariants. As long as it does that, you don't need a spec (other than > the actual compiler source code) that says exactly what you'll get for > any given input. "Austin Franklin" <austin@da98rkroom.com> writes: > Hum. I certainly don't design things like that. I have an expected result > I am trying to get, and I design something to give me that result...I don't > just make a random design that hopefully gives me some random result... There is spec for what each optimization does. Part of that is the invariants that are preserved. There are so many optimizations, and so many possible input scenarios, that it is not possible to have a top-level spec that defines the overall output of the process for any input. It's too severe a combinatorial problem. > Gee, no wonder I get so much work fixing things that people can't understand > why it doesn't work...and the fact is, most of the time it's simply they > didn't specify the problem very well, and therefore weren't able to > understand what they needed to do to solve the problem. Just because you can't readily predict the output for a given input doesn't mean that process is poorly specified. It may simply mean that the specs are very complicated. The fact that the user manual doesn't give you enough information to predict it is irrelevant; they could give you all the information (which would basically be the source code), and it would still be faster for you to simply run the compiler and determine what the output is, rather than try to "play compiler" yourself and figure it out. > You're not getting the point here. If you don't understand the need and > usefulness for what I (and many others) said have found vast usefulness for, > I don't have the time to explain it to you, as it's far more than I could > explain in a few posts. [...] > So, you can either try and understand it or simply believe it doesn't serve > any useful purpose (when I clearly know it does...and...perhaps you might > want to figure out why that is that I believe it does, and you believe it > doesn't... I've never said it wouldn't be useful. I'm only explaining why you're not going to get it, and why if you did get it, in practice it wouldn't be as useful as you expect it to be. It's obviously not the case that I "don't get it". If your request was reasonable, compiler and synthesizer vendors would be providing it. If you insist that your request *is* reasonable, and that it's not so difficult to provide it, maybe you should get into the compiler or synthesizer business and show everyone else how it's done. Presumably if it's a valuable feature and no one else provides it, the customers will beat a path to your door.Article: 51726
"Austin Franklin" <austin@da98rkroom.com> writes: > It HAS to be accurately predictible or it be full of bugs If you take some input, apply a series of transformations to it, and get some other output, the transformations may all be well-defined (and deterministic), and may be guaranteed to preserve some invariants, such that the output from the process is semantically equivalent to the input. Yet you can't easily predict what the output will be. The inability to predict the overall transformation does not inherently make it buggy. > and give unpredictible results! If it's not accurately predictable, it's unpredictable. Yes, that's a tautology. The fact that you can't predict it doesn't make it unusable. > > However if you change the input at all, > > the output may change a lot in response to a subtle change because an > > alteration in the way the rules are applied to the code. > > Yes, but the rules are random? Somehow aren't "known"? I'm not following > you here, or agreeing with you. Of course they're not random. But when you apply enough non-random rules, the overal behavior is not easily predicted.Article: 51727
To complete the thread, I found the registers in the PLX for the address and transfer size. I don't know how I missed them. So you up the address and the buffer in the program and load them into the registers and your off DMAing. No DMA controller needed. Paul Paul Cousoulis wrote: > > I'm not sure if this is the right place to ask this question but you > guys seem to know alot about PCI so maybe you can point me in the right > direction. > > I'm building a Data Acquisition board with an Altera Flex 6000 > transfering data through a PLX9054 to the PCI bus in DMA mode and I'm > trying to test it with DJGPP. What I want to know is how do I find the > address for the DMA buffer. Do I define it in the DJGPP program and tell > the PLX9054 about it? If so I can't find anywhere to send the address to > the PLX9054. Or does the PLX9054 set up the address and buffer, then > how does the program find out what this address is? Is there some DMA > controller I don't know about involved. Or is the address in the PCI > configuration stuff? > > Thanks > PaulArticle: 51728
I very much doubt that you can achieve that. At 500 MHz, the period is 2 ns, so you are asking for a 1/2000 match. And first you have to find a way to affect the frequency in some way. And then you have to maintain the match over temp and Vcc. What do you need this for? Peter Alfke ========================== frank wrote: > Hello, > > I was wondering if it is possible to implement 2 ring oscillators on > an fpga (xilinx or altera) with very similar frequencies (difference > in periods: ~1ps, approximate frequency: 100-500MHz). It is paramount > that the 2 frequencies can be controlled to be able to acheive the > period differential of ~1 ps. > btw, what would be a reasonable jitter value for an fpga-implemented > ring oscillator ? > > thx > > -FrankArticle: 51729
Frank, Jitter of an FPGA ring oscillator will be about 40 to 60 ps, Peak to peak. Divide by ~ 14 to get RMS. Ring oscillators are very low Q (as compared to crystals) so matching to 1 ps is clearly not possible. Even a custom CMOS ring oscillator will have jitter no better than what is stated above. Austin frank wrote: > Hello, > > I was wondering if it is possible to implement 2 ring oscillators on > an fpga (xilinx or altera) with very similar frequencies (difference > in periods: ~1ps, approximate frequency: 100-500MHz). It is paramount > that the 2 frequencies can be controlled to be able to acheive the > period differential of ~1 ps. > btw, what would be a reasonable jitter value for an fpga-implemented > ring oscillator ? > > thx > > -FrankArticle: 51730
Austin Franklin wrote: > "Hal Murray" <hmurray@suespammers.org> wrote in message > news:v2lvoj4eb6aif5@corp.supernews.com... > >>>Sure, any bad designer can create an unreadable design using any set >>>of tools. (or even a good designer who wants his design to be >>>unreadable as Job Security). What I an saying is that it IS easier to >>>make HDL code understandable than making schematic design, because you >>>are working at a higher level of abstraction: you don't have to >>>examine a mess of gates and FFs to understand what this counter/FSM is >>>supposed to do. >>> >>I don't see how HDLs automatically work at a higher level of >>abstraction. >> >>I can put a whole CPU in a single box on schematics. >>Is that high enough? >> > > Hi Hal, > > I agree...and was going to say that in fact...but you beat me to the punch. > > I think what is meant by that is, that inherently, HDLs offer a higher level > of abstraction, such as for state machines, counters etc. > > Most people think of schematics are single gates or flops, with no level of > abstraction...which is probably the MAJOR problem...MOST people simply don't > understand how to use schematics effectively. I honestly can't remember a > book written on the subject (I personally believe it's just to simple a > concept to devote to an entire book though), but there are probably a > hundred books written on HDLs...that in it self, may be one of the > contributing reasons why HDLs are so popular with chip designers now. Read > a book, become an expert! With schematics, you actually have to figure out > a lot on your own. > > Austin Well, if the schematics offer standard blocks like registers, multifunction combinatorial logic, FSM's, RAM's, ROM's, FIFO's, LIFO's, CAM's, sub- schematics, stacks of identical sub-schematics - then I think you have to figure out much *less* than using HDL's and you can concentrate upon the actual architecture you're designing. Forget about schematics to draw gates and FF's or even SSI/MSI components - they're at a too low level of abstraction for today's complex designs. Oh, and the fact that so many books are written on HDL's to make you an 'expert' - doesn't that say that they are darn hard to use correctly and efficiently ?-) Greetings from Holland, AdArticle: 51731
Andrew Rogers <andrew@rogerstech.co.uk> writes: > > I discovered the problem when I ran XST on Linux using Wine. First I > set the XILINX variable Why don't you run the Linux version?Article: 51732
John_H wrote: > The timing analyzer tool available in both the ISE and older design manager > front ends (or a standalone tool itself) provides a nice filtered view of > the timing analysis report and will provide different sets of results per > your demand (only failed paths, different speed grade, different number of > items reported). > > If you want to understand the timing results, this - along with the View > settings to bring out the physical elements in the overall delay - will > provide you with a lot of information. If you're looking to parse > information to input directly to another tool you're developing, you'll need > to supply a little more info, I'd expect. > > I never did like the long text versions of the timing reports. I was very > happy when the timing analyzer tool added the nice constraints browsing > capabilities. > > "Richard" <gospod88@hotmail.com> wrote in message > news:f7779f31.0301200252.d61da6b@posting.google.com... > > Folks, > > > > Just wondering if anyone has written a parser for Xilinx timing reports > yet. > > > > I need one for some research I'm doing and don't want to reinvent the > wheel > > unnecessarily! > > > > Cheers, > > Richard > > > > --- > > > > Richard Bannister > > Department of Computer Science > > Trinity College Dublin I'll second this notion - try using the Timing Analyzer GUI (timingan.exe) in iSE 5.1i. If you look under the Analyze menu, you'll see you can select several different methods of analysis. When you pick one, a tabbed dialog will appear that will give you a variety of filtering options. Another idea is to avail yourself of the XML timing report output. In Timing Analyzer GUI, simply do File->Save As, and select a .twx file type for output. The resulting file is XML and can be viewed and processed using a wide variety of XML-oriented tools, including IE6. -Dennis McCrohan Xilinx CPLD S/W EngineeringArticle: 51733
Did you try http://www.mosis.org ? Steve "Jerry" <nospam@nowhere.com> wrote in message news:v2j44jb6aeps7b@corp.supernews.com... > Well after some time spent searching for Multi project wafers and getting > some quotes I have come to the conclusion that > MPW is great for proof of concept and prototyping but it is not economical > feasible for production. Since our die is around > 8 mm on a side we would have to buy four sites @ 5mm on a side. This drives > the cost to around $400 a die. Cheaper than doing > it in a FPGA but does drive up the cost of the product. > > During the search I came across the term multi project die (MPD). From the > info I have been able to find it appears that > the concept is the same for MPD as for MPW. > > I have two companies that appear to offer MPD, > http://www.ime.org.sg/circuit/cir_alpha.htm and > http://www.cmc.ca/about/program/fabrication.html > > It appears CMC is for Canadian schools and companies. I have a request for > info to IME. > > It can't be that my company is alone in this dilemma of not enough volume to > get the attention of the IC fab houses plus an absolute > necessity of requiring an ASIC to perform the system functions. We can proto > in FPGAs but the cost of FPGA in production is > very high and the power consumption of an FPGA compared to an ASIC makes it > impractical in our power constrained application. Yes we have looked at a > hard wired FPGA. Still expensive and power hungry. > > Has anybody first hand knowledge of doing a MPD? Does anybody want (need) to > do a MPD? At this point we are flexible in schedule and packaging > requirements. > > Some issues I have considered: > 1. Commercial IP. Maybe we could share the IP and reduce the insertion > cost. The legal people may have a field day with this. > 2. What happens if one of the parties drops out? That tends to put the > rest of the parties back in the situation they were trying to avoid. > 3. Pin out, mostly in the pull ups and downs. I would think power and > ground would be easy to agree to. Some of the more > exotic IO standards could be a stumbling block. > 4. Scheduling tape out and fab. > 5. How to ratio the unit cost. Should everyone pay the same price even > though party's A circuit is one tenth the size of everyone else? > 6. Who integrates the designs? > 7. clock rate may come into play due to placement constraints and PLL > design. > > Advantages: similar to the MPW as far as mask cost goes. Ability to get an > ASIC with low volumes at prices that may work. > > Maybe this would work, maybe not. I, and I hope alot of other people would > be interested in further discussions and implementation. > > As .09 micron comes on line this year and .064 micron is investigated I > think the situation is only going to get worst for > products that require ASICs but whose constraints (cost and power) preclude > the use of an FPGA. > > regards > Jerry > > > > > > >Article: 51734
Two ring oscillators on the same die will also tend to syncrhonoize to each
other too due to leakage betwwen the two thru parasitics and the power rail,
at least if the ring delays are fairly equal. A delta of 1ps is small
enough that I would expect those to tend to synchronize.
Austin Lesea wrote:
> Frank,
>
> Jitter of an FPGA ring oscillator will be about 40 to 60 ps, Peak to
> peak. Divide by ~ 14 to get RMS.
>
> Ring oscillators are very low Q (as compared to crystals) so matching to
> 1 ps is clearly not possible.
>
> Even a custom CMOS ring oscillator will have jitter no better than what
> is stated above.
>
> Austin
>
> frank wrote:
>
> > Hello,
> >
> > I was wondering if it is possible to implement 2 ring oscillators on
> > an fpga (xilinx or altera) with very similar frequencies (difference
> > in periods: ~1ps, approximate frequency: 100-500MHz). It is paramount
> > that the 2 frequencies can be controlled to be able to acheive the
> > period differential of ~1 ps.
> > btw, what would be a reasonable jitter value for an fpga-implemented
> > ring oscillator ?
> >
> > thx
> >
> > -Frank
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 51736Ediz Cetin schrieb: > Hello All, > > Looking for Virtex 2 FPGA development board with parallel port or serial > port and USB port. Preferably A/D and D/A on it as well for rapid > prototyping applicaitons, 1 milllion gates+. > > Can any of you recommend companies that do such boards. > > Tanks. > > Ediz > > Hello, Insight have a development board with serial port on board. On a daughther board you can also have a USB port. On the board is a XC2V1000. It is selled as part of the Microblaze Dev Kit. ChristophArticle: 51737
Andrew Rogers <andrew@rogerstech.co.uk> wrote: ... : I discovered the problem when I ran XST on Linux using Wine. First I set : the XILINX variable : export XILINX=/mnt/win_d/xilinx/ The XILINX variable is read by the executable. Using a unix path in a variable that is passed via wine to a windows executable is depreceated. It may work in some cases, but not reliable. : with the slash, based on the line in my Windows autoexec.bat : SET XILINX=D:\XILINX\ Remember to escape the backslash when passing this as a unix environment variable via wine to the windows executable. The normal slash will work here with wine too and is easier to type. : Anyway setting the env variable without the trailing slash solved the : problem, at least while running XST from Linux using Wine. I'm sure that : the solution will also work if applied to Windows autoexec.bat but : haven't tried that yet. Do you use standard webpack on a recent wine or the special version that Xilinx distributes? Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 51738
I was looking through my links of reconfigurable computing sites and it appears that SRC computers (www.srccomp.com) has new information on their site. I thought I would pass this on since they seem to take a different approach to RC.Article: 51739
Ray, If you hand place the two ring oscillators such that they are next to each other, and their interconnect runs adjacent, they will phase and frequency lock to one another. (Even in an FPGA). Unfortunately their Q is still low, and any other switching, power supply noise, sudden temeprature change, and anything else clocking on the chip will tend to pull them, cause them to cycle slip, and lose lock with each other. Austin Ray Andraka wrote: > Two ring oscillators on the same die will also tend to syncrhonoize to each > other too due to leakage betwwen the two thru parasitics and the power rail, > at least if the ring delays are fairly equal. A delta of 1ps is small > enough that I would expect those to tend to synchronize. > > Austin Lesea wrote: > > > Frank, > > > > Jitter of an FPGA ring oscillator will be about 40 to 60 ps, Peak to > > peak. Divide by ~ 14 to get RMS. > > > > Ring oscillators are very low Q (as compared to crystals) so matching to > > 1 ps is clearly not possible. > > > > Even a custom CMOS ring oscillator will have jitter no better than what > > is stated above. > > > > Austin > > > > frank wrote: > > > > > Hello, > > > > > > I was wondering if it is possible to implement 2 ring oscillators on > > > an fpga (xilinx or altera) with very similar frequencies (difference > > > in periods: ~1ps, approximate frequency: 100-500MHz). It is paramount > > > that the 2 frequencies can be controlled to be able to acheive the > > > period differential of ~1 ps. > > > btw, what would be a reasonable jitter value for an fpga-implemented > > > ring oscillator ? > > > > > > thx > > > > > > -Frank > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759Article: 51740
"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<b09geh$mto23$2@ID-84877.news.dfncis.de>... > "Richard Coster" <richard.coster@4rf.com> schrieb im Newsbeitrag > news:732c59cc.0301161344.737576f5@posting.google.com... > > > The DLL is fed a 49MHz clock from a Cypress CY22393 programmable > > clock, which itself is sourced from a crystal oscillator. CLK0 is fed > > back via a BUFG to the CLKFB pin. The DLL is configured to divide by > > What is the jitter specification of the clock comming from the cypress?? The > Spartan-II demoboard from Insight comes with a programmable low cost > oscillator (some kindo of RC-type), it has a HELL lot of jitter. The DLL > cant lock reliable to a jittery signal. Is the clock present AND stable > before the FPGA is configured? I believe there is an issue with the stability of the clock on power-up, as the DLL locks if the clock source is changed. However after power-up the clock settles down and the DLL will lock if a reset is applied. I have now provided an automatic reset from a counter and this seems to fix the problem.Article: 51741
If you are using 4.1 or later xilinx tools, some of that whack-a-mole
syndrome in the timing may be due to the router. If the design is heavily
floorplanned, the olde (v3.3 and earlier) routers did a pretty good job of
routing all the signals for minimum route; the results were very repeatable
even after changes in the design, and the timing really did reflect the true
critical paths. With the more recent router, the tool pretty much gives up
as soon as the slack is non-negative. The result is routes that
unnecessarily congest the routing resources, and you wind up with a design
that just makes timing even with relatively easy timing targets. When the
placement density is high, as it can be with heavily floorplanned designs,
the routing gets congested, and the router routes itself into a corner where
it can't find a solution that meets timing. The syndrome that shows in that
case is that small changes to the design or even placement changes the
routing, and the critical path. In essence, the critical path is a more or
less non-deterministic function of the routing where it previously was very
consistent.
Roger Green wrote:
> Hi Mike,
>
> I was actually referring to the post-route timing analysis in both
> cases. Since the
> source design is the same and the Xilinx PAR settings are identical, I'm
> led to
> believe that the difference is primarily due to the synthesis tool
> used. Although
> the routed result is never identical between PAR runs, usually the
> problematic
> paths remain the same. My main query is after spending considerable
> time
> optimizing and floorplanning a design, then switching synthesis tools,
> it appears
> that I have an entirely "different" set of design paths to work on now.
>
> And BTW the critical timing paths are, and continue to be, synchronous
> between register
> combinational logic paths - - just different ones.
>
> -- Roger
>
> Mike Treseler wrote:
> >
> > Maybe you are comparing XST post-route results to
> > Synplify pre-route timing estimates. Place and route
> > your Synplify netlist before making timing comparisons.
> >
> > Synthesis is optimized for synchronous inputs
> > and registered outputs. The closer you can
> > be to this standard template the better.
> >
> > -- Mike Treseler
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 51742FlexLM is evil. "Marcin E. Hamerla" <mehamerla@pro.onet.pl> wrote in message news:0dcn2vs368t1nvul71r5jlvdq3eftn51tm@4ax.com... > Witam, > > Today I tried recompiling one of Altera projects using free MaxPlus > and I discovered that FLEXlm says that time has been set back. > Althoubg I did not believe in success I tried downloading new license > and reinstalled MaxPlus. Of course it did not help. FELXlm website > wasn't very usefull. > > -- > Pozdrowienia, Marcin E. Hamerla > > "Płoń, płoń, płoń parlamencie, spali Cię ogień na historii zakręcie."Article: 51743
I never said random. The issue is that the rules set is a very complex set of
rules, based not only on coding style, but also on performance, area (a default
setting if you don't specify it), what the logic between the registers actually
is etc. If they were simple rules, then yes, such a reference guide could be
generated. Where the rules are as complex as they are, publishing the rules
would not only give away the crown jewels (after all, it is the set of rules and
application of those rules that differentiates synthesis tools, right), but it
would also likele be very confusing to the consumer which means a much bigger
support cost.
For the cases where you need a certain structure, structurally instantiate the
logic. You are pretty much (found a bug a while back where one tool was
optimizing into xilinx FDRE primitives) guaranteed to get what you put in. If
it is not as critical, then you can let the tool do it as it pleases. As I
indicated, there is some middle ground which you can cover by inserting keep
buffers to force certain signals in a combinatorial tree to appear at LUT
outputs. That severely limits the options the compiler has for optimizing your
code, so it serves as a way of forcing the outcome without resorting to
instanced LUTs (which can be a pain in the tusch).
Austin Franklin wrote:
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3E2B50BE.14EBFE8@andraka.com...
> > As does synthesis. Synthesis goes by a set of rules, however when the
> rules
> > get sufficiently complex, the exact implemention tht results can be hard
> to
> > accurately predict.
>
> It HAS to be accurately predictible or it be full of bugs and give
> unpredictible results!
>
> > However if you change the input at all,
> > the output may change a lot in response to a subtle change because an
> > alteration in the way the rules are applied to the code.
>
> Yes, but the rules are random? Somehow aren't "known"? I'm not following
> you here, or agreeing with you. I don't disagree that they can't "test"
> every possible case, of course not...but for any GIVEN case, the output
> should be predictible...and the set of rules SHOULD be known, it doesn't
> make them up on the fly!
>
> What you are suggesting is a system that would have a very high potential
> for buggy output, and be poor engineering at best...where the tool can
> become unwieldy and possibly useless... Causing you to have to possibly
> take an excessive amount of time to discover said problem and then TRY to
> work around, what would be, a tool "problem". Perhaps this is rare, but the
> point is, the potential in your scenario is there. Of course it's there for
> any tool, no doubt. But it disturbs me that people actually believe in this
> "random" nature by design...instead of, what I would consider sound
> engineering.
>
> Austin
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 51744Aare Tali wrote: > Steve Lass <lass@xilinx.com> wrote in message news:<3E28724C.20AD283A@xilinx.com>... > > Langmann wrote: > > > > > Are you sure? I may be wrong about this (my PC with the Webpack installation > > > is not available to me right now) but I think I remember seeing directories > > > of Virtex (and possibly some other non-supported families) configuration > > > data included in the installation. > > > > We include these directories for a variety of reasons, like: > > - VirtexE has a lot of common elements with Virtex, so the VirtexE tools get data from the Virtex directories. > > - The programming daisy chain may contain other devices, so we include programming info for all devices. > > > > Is it possible then to use newer WebPack to program chips supported by > older versions by just copying data from old installation to new > directories? You shouldn't have to do that since we keep the data files from older families. Are you having a specific issue? Steve > Computers get quite confused with multiple versions of > WebPack installed.Article: 51745
Yes I did check with MOSIS. Their cost for production of the quantities we require places the cost of the part around the $400 figure I mentioned. It is my understanding that MOSIS does the MPW where the cost of the mask is split across many companies. In a MPW each company purchases a 5 mm by 5mm square or multiplies thereof. What I am thinking is that a multi project die could fit into a multi project wafer. The companies involved in a MPD would merge their netlist into one design to be routed as one device. Running this on a MPW would divide the NRE across the number of companies involved. The companies or individuals all get the same die since the die has their individual design on it. "Steve Casselman" <sc@vcc.com> wrote in message news:1s_W9.1207$C25.111669312@newssvr15.news.prodigy.com... > Did you try http://www.mosis.org ? > > Steve > > > "Jerry" <nospam@nowhere.com> wrote in message > news:v2j44jb6aeps7b@corp.supernews.com... > > Well after some time spent searching for Multi project wafers and getting > > some quotes I have come to the conclusion that > > MPW is great for proof of concept and prototyping but it is not economical > > feasible for production. Since our die is around > > 8 mm on a side we would have to buy four sites @ 5mm on a side. This > drives > > the cost to around $400 a die. Cheaper than doing > > it in a FPGA but does drive up the cost of the product. > > > > During the search I came across the term multi project die (MPD). From the > > info I have been able to find it appears that > > the concept is the same for MPD as for MPW. > > > > I have two companies that appear to offer MPD, > > http://www.ime.org.sg/circuit/cir_alpha.htm and > > http://www.cmc.ca/about/program/fabrication.html > > > > It appears CMC is for Canadian schools and companies. I have a request for > > info to IME. > > > > It can't be that my company is alone in this dilemma of not enough volume > to > > get the attention of the IC fab houses plus an absolute > > necessity of requiring an ASIC to perform the system functions. We can > proto > > in FPGAs but the cost of FPGA in production is > > very high and the power consumption of an FPGA compared to an ASIC makes > it > > impractical in our power constrained application. Yes we have looked at a > > hard wired FPGA. Still expensive and power hungry. > > > > Has anybody first hand knowledge of doing a MPD? Does anybody want (need) > to > > do a MPD? At this point we are flexible in schedule and packaging > > requirements. > > > > Some issues I have considered: > > 1. Commercial IP. Maybe we could share the IP and reduce the insertion > > cost. The legal people may have a field day with this. > > 2. What happens if one of the parties drops out? That tends to put the > > rest of the parties back in the situation they were trying to avoid. > > 3. Pin out, mostly in the pull ups and downs. I would think power and > > ground would be easy to agree to. Some of the more > > exotic IO standards could be a stumbling block. > > 4. Scheduling tape out and fab. > > 5. How to ratio the unit cost. Should everyone pay the same price even > > though party's A circuit is one tenth the size of everyone else? > > 6. Who integrates the designs? > > 7. clock rate may come into play due to placement constraints and PLL > > design. > > > > Advantages: similar to the MPW as far as mask cost goes. Ability to get an > > ASIC with low volumes at prices that may work. > > > > Maybe this would work, maybe not. I, and I hope alot of other people would > > be interested in further discussions and implementation. > > > > As .09 micron comes on line this year and .064 micron is investigated I > > think the situation is only going to get worst for > > products that require ASICs but whose constraints (cost and power) > preclude > > the use of an FPGA. > > > > regards > > Jerry > > > > > > > > > > > > > > > >Article: 51746
frank8017@excite.com (frank) wrote in message news:<60bf6cad.0301201203.7b4a0ac5@posting.google.com>... > Hello, > > I was wondering if it is possible to implement 2 ring oscillators on > an fpga (xilinx or altera) with very similar frequencies (difference > in periods: ~1ps, approximate frequency: 100-500MHz). It is paramount > that the 2 frequencies can be controlled to be able to acheive the > period differential of ~1 ps. > btw, what would be a reasonable jitter value for an fpga-implemented > ring oscillator ? > > thx > > -Frank As was said above, probably not on any digital FPGA. If how ever you are doing analog design, but you want it off the shelf like FPGA, there is, (was?) an analog FPGA company whos name escapes me that allowed you to interconnect predefined analog cells. You might find something useful there. At one time they would have used 1 metal layer or fuses to customize circuits. google "analog fpga" hasArticle: 51747
"Jerry" <nospam@nowhere.com> wrote in message news:<v2j44jb6aeps7b@corp.supernews.com>... > Well after some time spent searching for Multi project wafers and getting > some quotes I have come to the conclusion that '''''''' I recall that even TSMC (or was it UMC) were offering the MOSIS type service except that MOSIS is really for protos, & TSMC would have been low/medium vol shared mask. Check website to see if they still do this, they are probably still hungry. Also try Flextronics which took over Octal. There is a european/french version of MOSIS that uses ST, all these guys show up at DAC & so on.Article: 51748
Eric, > There are so many optimizations Optimizations aren't part of what I'm talking about. That is an entirely other issue. > and so many possible input scenarios, Well, that's somewhat irrelevant as well. I am talking for a more general case, not every specific example input that can be thought of, which would be infinite. It is more what does a case statement get compiled to... > that it is not possible to have a top-level spec that defines the overall > output of the process for any input. It's too severe a combinatorial > problem. Yes, but no one was talking about that. I really think you are not understanding the problem here, or, the impact of, the solution. You are looking for reasons why it won't work (for you), but failing to see how it can help. > Just because you can't readily predict the output for a given input doesn't > mean that process is poorly specified. I don't understand what "readily" as to do with anything? > The fact that the user manual doesn't give > you enough information to predict it is irrelevant... I don't expect a "user's manual" to do as you suggest here. > they could give you > all the information (which would basically be the source code), and it > would still be faster for you to simply run the compiler and determine > what the output is, rather than try to "play compiler" yourself and figure > it out. Sigh. Talk about wasting time... Yes, it is what one has to do, without apriori knowledge of what the synthesizer is going to do... Have you never been involved in a project where someone actually wrote a decent spec? I mean, cripes...I don't know any decent engineer who just "writes code" (hardware or software) and expects the code to be the definition of what it is s/he was supposed to write! That sounds utterly foolish for a project of any complexity. For small projects, fine...but the reason purported "engineering" projects end up being unweildy (buggy for one) is because they aren't specified well in the first place. It is something that I know not many people do, or much less do well, or even like to do but it's necessary for large projects or you end up with junk. > I've never said it wouldn't be useful. Well, without going back to your posts, I believe you did. > I'm only explaining why you're not > going to get it, and why if you did get it, in practice it wouldn't be as > useful as you expect it to be. And I completely disagree, and again, I fail to see where you are understanding the problem, and what the solution is. > It's obviously not the case that I "don't get it". I don't see you getting it. > If your request was > reasonable, compiler and synthesizer vendors would be providing it. What does "reason" have to do with compiler and synthesizer vendors providing it? Most people who write C aren't engineers these days...they are programmers, and have absolutely no engineering background...so whose going to get them TO ask? And as far as C goes, it really isn't as important these days, I agree, simply because of how good compilers have become...but for HDLs, that's a different story. And, I can guarantee you, not many FPGA HDL coders understand or think deep enough that such a document could be useful in the first place. People just take the tools as they come, and fight with them. You think that the people who don't even want to take the time to understand how to draw decent schematics, or make their code readable...or learn how to use hierarchy (or parameterize modules) are actually going to take the time to read such a document, much less even request it? I doubt it. IMO, the level of depth (and understanding) of engineers has decreased greatly in the past decade. Now, don't get me wrong, that doesn't say there aren't some damned good ones, but the majority, IMO, and having worked with hundreds of them, don't have the skills I would expect them to have...which, funny enough, is a good thing for me ;-) > If you insist that your request *is* reasonable, and that it's not so > difficult to provide it, maybe you should get into the compiler or > synthesizer business and show everyone else how it's done. That's a cop out on your part. I never said they were "doing it wrong", simply that that level of documentation doesn't exist any that it would be useful to SOME of us who knew what to do with it. > Presumably > if it's a valuable feature and no one else provides it, the customers > will beat a path to your door. It is a valuable feature for people who appreciate it, and know how to use it. That is clearly not everyone, and I never said it was. Companies are now catering to a less "demanding" crowd. And not meant specific to anyone here, but I have found that the level of "skill" (I can't think of a better word right now) that I find in a lot of today's engineers is quite deficient, but that's a completely other topic of discussion. It would take far too much effort to explain the usefulness of such a thing, and their interest level would be quite low, because they just believe the tool is supposed to do that, and they shouldn't have to worry about it. In a LOT of circumstances, that is certainly true...the chips are faster, and the tools "decent" enough so that it becomes less and less important. But, again, that doesn't devalue the usefulness of it for people who know how to use it, and really could use it. If you honestly believe that such a document "might" be useful, than what is the issue you are fighting here? AustinArticle: 51749
hi, i have around 150 registers(16 bit) in my design, can i use Block Ram bits for registers. i am using xcv800 Xilinx fpga. Thanking you Dileep Acl Hyderabad India
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