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 Wed, 27 Jan 2010 04:55:21 -0800 (PST), untergangsprophet wrote: >Quite unusual for big, established Companies to drive adoption of >radical new technology. Depends what you mean by "drive". Pretty much every big hi-tech company I know about is very active in assessing and evaluating a range of novel products and technologies, and evaluations of that kind are extremely important to startups for both technical feedback and marketing kudos. However, it is certainly true that big companies are not always the quickest to incorporate available new technology in their products. Sometimes that's shrewd understanding of a conservative customer base, sometimes it's just corporate inertia. Anyway, "radical" new technology is rarely reliable and rarely meets the expectations put on it by enthusiasts. It's often wise to wait until the "radical" epithet is no longer applicable. -- Jonathan BromleyArticle: 145101
Antti wrote: > problem fixed! yeah !!! > solution and explanation in the next Brain issue > (I will post short post also after the issue release) i'm eagerly waiting :-) did you solve your website and email issues ? how can one contact you ? are your "stamps" still available ? > Antti yg -- http://ygdes.com / http://yasep.orgArticle: 145102
untergangsprophet wrote: > On 27 Jan., 10:39, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> > wrote: >> I would be rather surprised if the products ever appear on >> the wider market. It's much more likely, as someone else >> said, that they are aiming to get testimonials from some >> big-name early adopter customers, and then sell out to >> one of the mainstream FPGA vendors - who would, presumably, >> then merge the technology into some future product family. > > Quite unusual for big, established Companies to drive adoption of > radical new technology. however, the big corp that can buy Achronix will have a major advantage over the other, which will be forced to make another, different move. That would be interesting to see, if it happens. But what is the best ? - a company that does not divulgue or distribute his products ? what's the point ? - a same company that fails and dives, which is equivalent to the first point ? - a company that is bought, slaughtered then dissolved by another larger corp ? (same results) Sure, siliconblue's chips are... slow. but they are available, reasonably priced, the toolsuite is small and easily obtainable, so I consider that they did all the necessary efforts for success (from a user point of view). Oh, and they support Linux from the start :-) We have waited too long for other players to challenge the established status quo, I'm happy to see new names and products ! But I don't want to be disapointed... yg -- http://ygdes.com / http://yasep.orgArticle: 145103
On Jan 26, 1:34=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > > Is it possible to make the chain go up a column of > LUTs, through only one of the LUTs in each slice along > the way, and then back down through the other halves of > the slices? =A0In that way you could get a hairpin-shaped > chain, with the possibility of bridging it at any point > along its length; the selectable bridges, each being > within one slice, would be rather predictable; the > injection/extraction points are of course fixed, at > the "open" end of the hairpin. > > The delay resolution would be two LUT delays rather > than one, which might be a drawback. > > thanks > -- > Jonathan Bromley Absolutely. However... you can keep the resolution to 1 LUT delay. I tried to help someone a few years ago with this approach. The one thing that gets odd about having the 1 LUT resolution is the signal polarity. If you use a chain of inverters rather than buffers to avoid severe duty cycle distortion, taking out one inverter would invert the delayed signal at some delayed point. So the choice would be to remove two inverters from the "end" of the hairpin or change the two inverters to one buffer. This approach absolutely gets rid of the problem of injecting a signal into or muxing a signal out of a delay chain. For the hairpin approach I'd still recommend constrained routing (manual selection from FPGA editor) but the routes can probably be split into four constraints: one for the up route, one for the down route, and two for across (one from the CLB directly across, one from the CLB above or below that one). The LUTs are a bit of an issue since they want to select from one of 3 inputs; not a problem for 5+ input LUTs but troublesome for the lower cost devices' 4-input LUTs. For the Spartan-N series parts I may have figured a way to split the mux logic between the upward and downward sides of the hairpin. For consistency in this arrangement I'd recommend one LUT per CLB, at least for each up/down direction in order to get consistent routing delays. As I stated earlier, the full scale delays WILL BE modulated by voltages, temperatures, and local activity within the chip. ___ Another approach for a long minimum delay but better granularity is a chain of inverting muxes which choose between two routes from the previous stage. The overall delay for an N LUT chain would roughly be N LUT delays plus routing but the adjustment is M long routes and N-M short routes. - John_HArticle: 145104
Antti wrote: > website issues in "solving" state yes! and which email address works ? > Antti yg -- http://ygdes.com / http://yasep.orgArticle: 145105
On Jan 27, 4:24=A0pm, whygee <y...@yg.yg> wrote: > Antti wrote: > > problem fixed! > > yeah !!! > > > solution and explanation in the next Brain issue > > (I will post short post also after the issue release) > > i'm eagerly waiting :-) > > did you solve your website and email issues ? > how can one contact you ? > are your "stamps" still available ? > > > Antti > > yg > > --http://ygdes.com/http://yasep.org website issues in "solving" state yes! first products using Silicon blue stamps are about to be delivered to the customers and we have small batch of the SB stamp modules ready as well AnttiArticle: 145106
On Jan 27, 5:40=A0pm, whygee <y...@yg.yg> wrote: > Antti wrote: > > website issues in "solving" state yes! > > and which email address works ? > > > Antti > > yg > --http://ygdes.com/http://yasep.org Antti.Lukats@googlemail.com always works :) thats why i use it as preffered :) if i dont reply, please resend, in very rare cases the mails go to spam and I delete spam folder without reading (300+ spam mails per day)Article: 145107
On Jan 27, 3:35=A0am, "maurizio.tranchero" <maurizio.tranch...@gmail.com> wrote: > I've sent them an email to have datasheets and further information, > but they asked for an non-disclosure agreedment... > > The only thing I know is they have collaboration with space and > defence people, but I do not think it would be easy for "normal" > designer to access their products. > > mt You got asked for an NDA? I was contacted by an individual NOT using an Achronix email address (@beaconmail.com - it has no whois information either). I thought it was rather odd that their contact person didn't sign their email as Achronix, but as Beacon. I never heard back from them after letting them know what my interests were. The initial email did include the name of an anchronix employee though... willArticle: 145108
Kastil Jan wrote: > Hi all, > is there anybody with experience with FPGAs from company Achronix > (www.achronix.com)? I found only a few documents on their web. It looks > interesting to me but I was not able to find any working contact to any > sales person. I tried email to the adress on their web but nobody > responded. I am hoping, that maybe some of people here would have any > experience or even working contact to the company. Can you help me? > Thanks you very much. > > Jan I got a a data sheet about a year ago, but had been watching development progress for some time before that. Not much detailed description has come from Achronix, and googling doesn't seem to work well either. I believe that each signal in the fabric propagates down two wires, and also encodes one of two data phases. The logic carries it's own 'timing' signal. There is no ambiguity or race problems as only one wire changes state in any signal transition. The high performance is due to the asynchronous logic requiring no clock tree in the FPGA fabric. (Just some around the edge for I/O) One doc states that the logic elements are four input LUTs. The interconnect is patented, and I've not yet grasped the details. Although the fabric is significantly different, I read that the design tools can import and translate RTL from current capture tools. Hope this helps, and is accurate, Jan Coombs. -- there are no Xs in my emailArticle: 145109
On Jan 20, 1:40=A0am, "hassantalal" <slaineddd@n_o_s_p_a_m.yahoo.com> wrote: > HELLO .. I want to test my transmitter forAWGN.. i have coded my > transmitter and receiver using VERILOG hdl .... kindly if anybody has > verilog code forAWGN.. where i can change SNR values .. and calculate BER > for each SNR.....any suggestions for simulatingAWGNand calculate > BER..... =A0 =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Hi Hassan, You may be interested in our AWGN IP cores coded in Verilog. They are compact and very accurate, with the PDF error less than 0.2% up to 7.1 standard deviations. The variance of the AWGN output is 1, so to achieve the desired SNR you need to multiply the AWGN by a constant (which depends on the signal energy). You can find datasheets for our Gaussian noise generators on http://www.ukalta.com/?page_id=3D228#number_generators Regards, LeendertArticle: 145110
HI everyone, I'm trying to send 16 byte data block from PC to DE2 board using bulk transfer. I do modify the ReadEndpoint, WriteEndpoint and SetEndpointConfiguration to read and write 16 bytes data. But I still can’t get the correct result. What had I miss? Can somebody help me? Thanks, summer --------------------------------------- Posted through http://www.FPGARelated.comArticle: 145111
HI everyone, I'm trying to send 16 byte data block from PC to DE2 board and then the DE2 board will transfer back the data to PC using bulk transfer. For the firmware part, I do modify the ReadEndpoint, WriteEndpoint and SetEndpointConfiguration to read and write 16 bytes data. But I still can’t get the correct result. What had I miss? Can somebody help me? Thanks, summer --------------------------------------- Posted through http://www.FPGARelated.comArticle: 145112
On Jan 27, 8:56=A0pm, "WilliamG...@gmail.com" <williamg...@gmail.com> wrote: > On Jan 27, 3:35=A0am, "maurizio.tranchero" > You got asked for an NDA? =A0I was contacted by an individual NOT using > an Achronix email address (@beaconmail.com - it has no whois > information either). =A0I thought it was rather odd that their contact > person didn't sign their email as Achronix, but as Beacon. =A0 =A0I never > heard back from them after letting them know what my interests were. > > The initial email did include the name of an anchronix employee > though... Actually I asked for the NDA, but I hadn't received any response from their side. Probably my University group was not "interesting" for them... mtArticle: 145113
Joining in kind of late here--It sounds like you may have a solution and that's great. But here is some food for thought in case you don't understand your failure mechanism yet. It is very interesting to me that the clocks are not derived from same source, but one is pseudo-multiple of the other (write clock is 2x faster than read). Just supposing here: Do you make an assumption that when empty flag goes inactive, you attempt to read multiple pieces of data from FIFO immediately, because the write side "bursts" multiple data on consecutive write clocks? I assume that your read bus is twice as wide as your write bus? If so, this could be a problem IFF read clock is a tiny bit more slower than 2x of write clock, due to variant PPM of respective oscillator frequencies. In other words, I would advise using some type of partial empty flag to *make sure* there is N amount of words in FIFO before reading those N words out. Expanding on this idea, can you (perhaps as a test) add a significant delay from empty flag going inactive before reading FIFO data just to decouple the read clock timing from the write clock timing, in case you are currently "racing" the read out with the write in. - John CappelloArticle: 145114
On Jan 28, 11:38=A0am, jc <jcappe...@optimal-design.com> wrote: > Joining in kind of late here--It sounds like you may have a solution > and that's great. But here is some food for thought in case you don't > understand your failure mechanism yet. > > It is very interesting to me that the clocks are not derived from same > source, but one is pseudo-multiple of the other (write clock is 2x > faster than read). Just supposing here: Do you make an assumption that > when empty flag goes inactive, you attempt to read multiple pieces of > data from FIFO immediately, because the write side "bursts" multiple > data on consecutive write clocks? I assume that your read bus is twice > as wide as your write bus? > > If so, this could be a problem IFF read clock is a tiny bit more > slower than 2x of write clock, due to variant PPM of respective > oscillator frequencies. In other words, I would advise using some type > of partial empty flag to *make sure* there is N amount of words in > FIFO before reading those N words out. Expanding on this idea, can you > (perhaps as a test) add a significant delay from empty flag going > inactive before reading FIFO data just to decouple the read clock > timing from the write clock timing, in case you are currently "racing" > the read out with the write in. > > - John Cappello TEST setup: PC software that sends commands over GbE-fiber to master board, Master FPGA board sends a short packet SOP<8 byte>EOP into fiber Slave FPGA board receives the 8 byte I PUSHED a key with my hand, and there was never any overflow possible clocks: WR clock deriveved from oscillator on the MASTER via the fiber and MGT using the RECCLK from MGT RD clock derived from oscillator on the SLAVE so the clocks are almost "same" or almost 2X except the oscilator accuracy on master/slave boards. AnttiArticle: 145115
> >>According to ISE definition, input offset is the time of data transition >>relative to NEXT clock edge. >>Your setting of 2ns resulted in ISE reporting -3.17ns i.e. ISE now >>contradicted its own definition and related it to previous clock edge. >>Whichever way you look at it, you got a transition at(6 - (-3.17)) = 2.83 >>ns with respect to NEXT clock edge, almost centre aligned. I don't expect >>volation of setup or hold as reported. Your own addition of 2 + 3.17ns >>makes no sense to me. you asked for 2ns and you got 2.83ns >> >>kadhiem >> >>--------------------------------------- >>Posted through http://www.FPGARelated.com >> > >I think you are wrong. "transition at 2.83ns with respect to the next clk >edge, almost center aligned" AT THE PAD means nothing, what we need is >clocking correct AT THE FIRST Flip Flop. > >What ISE report means is that: If data come 3.17ns lag behind clock rising >edge, clock can just exactly sample data correctly at the first flip flop. >Right? > >If that is true, then: if data come 2ns before clock rising edge as the >offset constraint, after going through the same data path and clock path, >clock rising edge will present at (2+3.17)ns with respect to the data. That >is my question. > >--------------------------------------- >Posted through http://www.FPGARelated.com Both xilinx and altera timing tools are practically intersted in figures for setup/hold timing relations at pads so that timing of io registers is derived internally according to window shift. As a user, you only need to look at pads and the tool will tell you if internal io and core registers are ok. kadhiem --------------------------------------- Posted through http://www.FPGARelated.comArticle: 145116
I guess I am specifically asking about the precise timing of the reading of data from the FIFO. How soon does the read side attempt to read FIFO data after the empty flag goes low? I argue that doing this too quickly--say, allowing the FIFO empty flag to act as the read enable also--could cause the problems you are seeing if the 62.5M clock source frequency is at the higher end of the "+/- PPM" range while the 125M clock source frequency as at the lower end of its own PPM range. A safe way to do this would be to either add delay from the empty going inactive before reading the FIFO, or use some type of partial empty flag. This is just an idea and I don't claim that this has to be your problem. But I've seen this issue arise with ethernet systems where two boxes attempt to communicate using their own, embedded 125MHz clock source, but +/-200PPM, I believe.Article: 145117
On Jan 13, 1:35=A0pm, rickman <gnu...@gmail.com> wrote: > I'm not sure where this thread started, I don't see a message before > Nico's post Jan 11. =A0Did you post your code? > > Your design is using about 10% of the LUTs as routing, which does tend > to happen when your LUT usage rises using up much of the routing > resources. =A0The main offender that I can see is the use of almost 50% > of the LUTs as DP RAM. =A0I am guessing that these are being used for > FIFO buffers. =A0Can you reduce the number of LUTs used for buffering or > are they all required? > > As to the clocking issue, I don't know what the problem is exactly. > Why can't you use the E1 clock? =A0What pin is the E1 clock connected to > on the S3 part? =A0I would hope it is connected to a DCM or at least a > clock input. > > It is hard to suggest much more without more insight into what your > design is doing. > > Rick > > On Jan 12, 9:00=A0am, Morppheu <jdemam...@gmail.com> wrote:> > Why use th= e internal clock? Isn't the MT9076 free running when it > > > doesn't see a line-sync? > > > Yes, the MT goes free running when its not sinced. > > But the MT9076 is a module on my hardware. I can mount the backplane > > with or without the MT9076 chip. > > That is the point, what to do when I have the E1 module installed. How > > to interface with it. > > My FPGA is an Spartan 3e S100 (almost 100% full): > > > Logic Utilization: > > =A0 Total Number Slice Registers: =A0 =A0 =A0 737 out of =A0 1,920 =A0 = 38% > > =A0 =A0 Number used as Flip Flops: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = 731 > > =A0 =A0 Number used as Latches: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A06 > > =A0 Number of 4 input LUTs: =A0 =A0 =A0 =A0 =A0 =A0 956 out of =A0 1,92= 0 =A0 49% > > Logic Distribution: > > =A0 Number of occupied Slices: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0959 out of > > 960 =A0 99% > > =A0 =A0 Number of Slices containing only related logic: =A0 =A0 959 out= of > > 959 =A0100% > > =A0 =A0 Number of Slices containing unrelated logic: =A0 =A0 =A0 =A0 = =A00 out of > > 959 =A0 =A00% > > =A0 =A0 =A0 *See NOTES below for an explanation of the effects of unrel= ated > > logic > > Total Number of 4 input LUTs: =A0 =A0 =A0 =A0 =A01,910 out of =A0 1,920= =A0 99% > > =A0 Number used as logic: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0956 > > =A0 Number used as a route-thru: =A0 =A0 =A0 =A0 181 > > =A0 Number used for Dual Port RAMs: =A0 =A0 =A0768 > > =A0 =A0 (Two LUTs used per Dual Port RAM) > > =A0 Number used as Shift registers: =A0 =A0 =A0 =A05 > > =A0 Number of bonded IOBs: =A0 =A0 =A0 =A0 =A0 =A0 =A0 93 out of =A0 = =A0 108 =A0 86% > > =A0 =A0 IOB Flip Flops: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A019 > > =A0 Number of Block RAMs: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A04 out of =A0 = =A0 =A0 4 =A0100% > > =A0 Number of GCLKs: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 9 out of = =A0 =A0 =A024 =A0 37% > > =A0 Number of DCMs: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02 out of= =A0 =A0 =A0 2 =A0100% > > > Another thing. How to reduce the area usage?? > > > Thanks! Hey guys! Thanks for your reply. =3D) I will explain my problem. I have a internal clock of 16.384MHz (50ppm) and a E1 interface (MT9076B). The E1 have a 4.096MHz clock (regenerated from E1) and a F0 (Frame sync signal, active low). When the E1 is installed (MT9076 chip is soldered at motherboard), I use the E1 clock as master clock. One of my DCM (I have 2, Spartan3e S100 sucks) I use to generate a 2MHz clock from E1 clock. This clock I use to send the E1 data to MT9076, aligned with F0 signal. What I want to do is use only the internal 2.048MHz (generate from 16.384MHz clock, with DCM) and interface with E1 through a FIFO. Here is the problem. Internal and external clock are different, so the FIFO will go underflow or overflow... What I can do?? Use a DCM to phase lock both clocks?? But when MT9076 goes free running I will have problem anyway. Waiting suggestions.. =3D) Thanks!Article: 145118
Hi, Sun Microsystem provides a full set of valuable resource on its webside: http://www.opensparc.net/opensparc-t2/download.html I printed all its documents and books about 2K pages free. I think it is the best textbooks in the world relating to building a CPU. I appreciate it very much. But there is one thing really troubling me. One of documents cannot be opened correctly so that I cannot see it. The file is OpenSPARCT2_SoC_Micro_Arch_Vol1.pdf in doc directory. Has any one tried to download the file and opened the file correctly? Thank you. WengArticle: 145119
Hi All,
I am new to the FPGA design flow. Now I am working on FPGA editor to
make changes in the design. Once I make changes in the ncd file i can have
either a modified ncd file or a bit file from it (using Bitgen).
My question is that is it possible to do post route simulation from any of
these two files or is there any other way to do it??
Thanks in Advance,
Charles.
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 145120On Jan 28, 1:28=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > Hi, > Sun Microsystem provides a full set of valuable resource on its > webside:http://www.opensparc.net/opensparc-t2/download.html > > I printed all its documents and books about 2K pages free. > > I think it is the best textbooks in the world relating to building a > CPU. > > I appreciate it very much. > > But there is one thing really troubling me. One of documents cannot be > opened correctly so that I cannot see it. > > The file is OpenSPARCT2_SoC_Micro_Arch_Vol1.pdf in doc directory. > > Has any one tried to download the file and opened the file correctly? > > Thank you. > > Weng It works O.K. here in the U.S. I notice it is on a secure page: https://www.opensparc.net/pubs/t2/docs/OpenSPARCT2_SoC_Micro_Arch_Vol1.pdf Maybe you have a security issue?Article: 145121
On Jan 28, 12:21=A0pm, gabor <ga...@alacron.com> wrote: > On Jan 28, 1:28=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > > > Hi, > > Sun Microsystem provides a full set of valuable resource on its > > webside:http://www.opensparc.net/opensparc-t2/download.html > > > I printed all its documents and books about 2K pages free. > > > I think it is the best textbooks in the world relating to building a > > CPU. > > > I appreciate it very much. > > > But there is one thing really troubling me. One of documents cannot be > > opened correctly so that I cannot see it. > > > The file is OpenSPARCT2_SoC_Micro_Arch_Vol1.pdf in doc directory. > > > Has any one tried to download the file and opened the file correctly? > > > Thank you. > > > Weng > > It works O.K. here in the U.S. =A0I notice it is on a secure > page: > > https://www.opensparc.net/pubs/t2/docs/OpenSPARCT2_SoC_Micro_Arch_Vol... > > Maybe you have a security issue? Hi Gabor, No security issue. All other files are fine. Could you send the copy of the file to me through my person email ? I am working at Pasadena, California, near Caltech campus. WengArticle: 145122
On Jan 28, 12:29=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > On Jan 28, 12:21=A0pm, gabor <ga...@alacron.com> wrote: > > > > > > > On Jan 28, 1:28=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > Hi, > > > Sun Microsystem provides a full set of valuable resource on its > > > webside:http://www.opensparc.net/opensparc-t2/download.html > > > > I printed all its documents and books about 2K pages free. > > > > I think it is the best textbooks in the world relating to building a > > > CPU. > > > > I appreciate it very much. > > > > But there is one thing really troubling me. One of documents cannot b= e > > > opened correctly so that I cannot see it. > > > > The file is OpenSPARCT2_SoC_Micro_Arch_Vol1.pdf in doc directory. > > > > Has any one tried to download the file and opened the file correctly? > > > > Thank you. > > > > Weng > > > It works O.K. here in the U.S. =A0I notice it is on a secure > > page: > > >https://www.opensparc.net/pubs/t2/docs/OpenSPARCT2_SoC_Micro_Arch_Vol... > > > Maybe you have a security issue? > > Hi Gabor, > No security issue. All other files are fine. > > Could you send the copy of the file to me through my person email ? > > I am working at Pasadena, California, near Caltech campus. > > Weng Hi Gabor, Thank you very much. I downloaded the file correctly from your reference. WengArticle: 145123
On Jan 26, 1:34=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Tue, 26 Jan 2010 09:55:22 -0800 (PST), John_H wrote: > >Getting the signal selectively injected > >into the chain or multiplexed out of the chain > >with deterministic delays is ugly. > > Understood. > > This is not my area at all, so I'm just speculating > (and hoping to learn)... > > Is it possible to make the chain go up a column of > LUTs, through only one of the LUTs in each slice along > the way, and then back down through the other halves of > the slices? =A0In that way you could get a hairpin-shaped > chain, with the possibility of bridging it at any point > along its length; the selectable bridges, each being > within one slice, would be rather predictable; the > injection/extraction points are of course fixed, at > the "open" end of the hairpin. > > The delay resolution would be two LUT delays rather > than one, which might be a drawback. > > thanks > -- > Jonathan Bromley TIME OUT!!!! When you start talking about "predictable delays", you are not talking about ICs. The delay of a signal through a LUT is very much a variable depending on the big three, temperature, voltage and process (the IC itself). I expect you know this and you know what you mean by "predictable", but the actual delays within an FPGA can easily vary over a range of 2:1 and I suspect the OP does *not* know this. Trying to use delays of elements within an IC for frequency generation is a very difficult thing to do. The delays are not consistent over time (assuming the power supply voltage or temperature can change) and will definitely change between units. To the OP, how exactly would you expect this to work? There is a reason why this is not supported in the tools, because everyone learns very early in their career to not use logic as delays elements except in a few very specific situations where you don't care about the absolute delay, but rather only a relative delay or the actual delay value is not important. RickArticle: 145124
On Jan 28, 5:11=A0pm, rickman <gnu...@gmail.com> wrote: > > TIME OUT!!!! =A0When you start talking about "predictable delays", you > are not talking about ICs. =A0The delay of a signal through a LUT is > very much a variable depending on the big three, temperature, voltage > and process (the IC itself). =A0I expect you know this and you know what > you mean by "predictable", but the actual delays within an FPGA can > easily vary over a range of 2:1 and I suspect the OP does *not* know > this. I did find it interesting that the visible frequency did not change wildly in a Spartan-3E when monitored visually with a measurement in the demo board's LCD. Application of freeze spray or heat gun *in that case* (without much additional logic in the part) changed the frequency by only about 10%. Interesting: pressing down on the chip with a pencil eraser changed the ~450ps average LUT + direct route delay by several picoseconds repeatably. It's possible that the "visual" value had higher frequency variations that got averaged out and that longer term variations might also be seen. These variations are why I suggested that constant calibration would be necessary.
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