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
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. JanArticle: 145076
>On Jan 25, 6:25=A0pm, "Pallavi" <pallavi_mp@n_o_s_p_a_m.rediffmail.com> >wrote: >> Hello, >> >> I need to implement a project as a part of my Masters curriculum using fp= >ga >> devices that would generate delays, that is generate higher output >> frequencies than the system clock using propagation delays. I'm using ISE >> tool for the same. I'm new to this technology and would really appreciate >> if i could get some help on this. Thanks in advance. >> >> --------------------------------------- =A0 =A0 =A0 =A0 >> Posted throughhttp://www.FPGARelated.com > >This is a somewhat confused question ? >If you want to generate delays, you do not need to 'over-clock' - just >choose a FPGA with inbuilt delay blocks, and they will have a step >size, much smaller than any clock precision. >ie the FPGA vendors have solved this problem already. > >-jg > Thanks for ur response. As I'm new to this technology I really dont understand the terminologies used. I dont need to do h/w implementation, just a simulation would be enough. Also i need to do physical implementations(dont know what that means). > > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 145077
On Jan 25, 10:17=A0am, "Pallavi" <pallavi_mp@n_o_s_p_a_m.rediffmail.com> wrote: > >On Jan 25, 6:25=3DA0pm, "Pallavi" <pallavi_mp@n_o_s_p_a_m.rediffmail.com= > > >wrote: > >> Hello, > > >> I need to implement a project as a part of my Masters curriculum using > fp=3D > >ga > >> devices that would generate delays, that is generate higher output > >> frequencies than the system clock using propagation delays. I'm using > ISE > >> tool for the same. I'm new to this technology and would really > appreciate > >> if i could get some help on this. Thanks in advance. > > >> --------------------------------------- =3DA0 =3DA0 =3DA0 =3DA0 > >> Posted throughhttp://www.FPGARelated.com > > >This is a somewhat confused question ? > >If you want to generate delays, you do not need to 'over-clock' - just > >choose a FPGA with inbuilt delay blocks, and they will have a step > >size, much smaller than any clock precision. > >ie the FPGA vendors have solved this problem already. > > >-jg > > Thanks for ur response. As I'm new to this technology I really dont > understand the terminologies used. I dont need to do h/w implementation, > just a simulation would be enough. Also i need to do physical > implementations(dont know what that means). > > > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com If you need to do physical implementations, you need to do hardware implementations. If you're doing more than just using the high speed interface (such as the Rocket I/O used in the Xilinx chips you can target with ISE) to deliver delay granularity of about 1/3 of a nanosecond, you will have difficulty getting a good simulation since proper timing situation is difficult. If you're looking to push the delay granularity, there are techniques which can be used to leverage internal delays within CLBs or carry chains that don't lend themselves to exceptional timing simulation. If you're clear on what you want to accomplish we may be able to provide some good direction or point you to application notes on existing designs. But you *really* need to know what's expected of you in the way of the physical implementation requested. - John_HArticle: 145078
On Jan 22, 11:19=A0am, Mike Treseler <mtrese...@gmail.com> wrote: > Martin Thompson wrote: > > Personally, I'm impressed that I can write a simple description of my > > logic and get a complicated near-optimal synthesis result out in a > > large number of cases - I wonder if I'm alone? :) > > I agree. > If it sims and meets timing I'm usually done. > But then, I don't need that last LUT and that last nS. > > =A0 =A0 =A0-- Mike Treseler I think the most common problem when designers try to be smarter than their synthesizer is that they don't let the synthesizer try it first; they just assume that they have to code this up-then-down count sequence to get an acceptable implementation. I'm as guilty of this as most, but I'm getting better at it. The tools keep getting better (often faster than I'm getting better!), so I continually have to recalibrate my estimate of when I will need to get more creative. In practice, this usually means that I (should) first write a fairly straight forward behavioral (cycle accurate) description of what I want, along with the testbench, which is often easier to debug with a simple, functional test case. Then if I need to "improve" my code to compensate for "weaknesses" in the synthesis tool, at least I have a testbench that is already debugged and functionally correct. And like Mike said, if it works fine as originally written, I'm done. I suppose where this gets tricky is when you are writing IP that is intended to be used by others, where you do not know how much performance or space they will need (i.e. the definition of "works fine" is a bit fuzzy). Then you simply have to look at what can be optimized in the time and budget available that will give you the most bang for the buck. But getting it working first, with a good testbench, then optimizing later is still a good route to success. AndyArticle: 145079
Hello all, I am trying to test configure and test one design using microbl;aze and xps_ethernetlite. I am making a testbench for the modelsim but it is doesnt work. i am trying to find a tutorial/example from xilinx but nothing how to configure the IPcore. do you have something in mind? Thank in advance all the best LastvalArticle: 145080
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. good question... I'm curious too so if anyone has news, i'll read :-) I just know that Achronix "exists". AFAIK there is one or two other FPGA startups in "submarine" mode, waiting for something to make public announcements about their products. Something like major buying deals, availability of their toolsuite for customers, finding distributors... it's a tough and complex industry. http://www.siliconbluetech.com/ has come "out of nothing" about a year ago, and still has a long way to go to gain widespead acceptance. I hope that others will follow ! > Jan -- http://ygdes.com / http://yasep.orgArticle: 145081
On Jan 20, 7:46=A0am, "jjlind...@hotmail.com" <jjlind...@hotmail.com> wrote: > On Jan 18, 2:50=A0am, Charles Gardiner <inva...@invalid.invalid> wrote: > > > > Thanks everyone for your input. My question is relating to the cost o= f > > > a simulator that supports SystemVerilog Verfication, just how much > > > should I expect to spend for one license? If its too expensive I'll > > > have to stick with sytem testbenches. > > > > joe > > > To put a ball park on it, about the price of a relatively well-equiped > > medium range car ;). If you get a great deal from Aldec / Cadence / > > Mentor / Synopsys, maybe the price of a well equiped small car. > > Why is it so expensive? Not sure! But I was completely blown away at how much discounts are offered if you just ask for them... the car analogy really applies here. Even better would be a "used car"... i.e. you bargain as if you are out to buy a used car. Nevertheless, if you want a cheap tool to learn Aldec Riviera Pro may be a good deal as well... ofcourse, here you pay to debug Riviera for Aldec.Article: 145082
On Jan 25, 6:50=A0am, Kastil Jan <ikas...@stud.fit.vutbr.cz> 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? Thank= s > you very much. > > Jan I am curious, as well. From their LinkedIn profile it appears that they've been hiring as recently as 4 months ago. I can only assume they're still around. http://www.linkedin.com/companies/achronix-semiconductorArticle: 145083
stephen.craven@gmail.com wrote: > I am curious, as well. From their LinkedIn profile it appears that > they've been hiring as recently as 4 months ago. I can only assume > they're still around. > http://www.linkedin.com/companies/achronix-semiconductor hmmm interesting link. it says that it was funded in 2004 : 6 years of development and no product yet on the market : it's a tough and expensive industry :-/ Anyway, I will be pleased to see their products one day, they would be a very interesting complement to other maker's product lines. yg -- http://ygdes.com / http://yasep.orgArticle: 145084
On Jan 25, 7:02=A0pm, whygee <y...@yg.yg> wrote: > stephen.cra...@gmail.com wrote: > > I am curious, as well. =A0From their LinkedIn profile it appears that > > they've been hiring as recently as 4 months ago. =A0I can only assume > > they're still around. > >http://www.linkedin.com/companies/achronix-semiconductor > > hmmm interesting link. > it says that it was funded in 2004 : > 6 years of development and no product > yet on the market : it's a tough and > expensive industry :-/ > > Anyway, I will be pleased to see their products > one day, they would be a very interesting > complement to other maker's product lines. > > yg > --http://ygdes.com/http://yasep.org Let's hope they are shipping product before 1.5 GHz becomes the industry norm.Article: 145085
>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.comArticle: 145086
>On Jan 25, 10:17=A0am, "Pallavi" <pallavi_mp@n_o_s_p_a_m.rediffmail.com> >wrote: >> >On Jan 25, 6:25=3DA0pm, "Pallavi" <pallavi_mp@n_o_s_p_a_m.rediffmail.com= >> >> >wrote: >> >> Hello, >> >> >> I need to implement a project as a part of my Masters curriculum using >> fp=3D >> >ga >> >> devices that would generate delays, that is generate higher output >> >> frequencies than the system clock using propagation delays. I'm using >> ISE >> >> tool for the same. I'm new to this technology and would really >> appreciate >> >> if i could get some help on this. Thanks in advance. >> >> >> --------------------------------------- =3DA0 =3DA0 =3DA0 =3DA0 >> >> Posted throughhttp://www.FPGARelated.com >> >> >This is a somewhat confused question ? >> >If you want to generate delays, you do not need to 'over-clock' - just >> >choose a FPGA with inbuilt delay blocks, and they will have a step >> >size, much smaller than any clock precision. >> >ie the FPGA vendors have solved this problem already. >> >> >-jg >> >> Thanks for ur response. As I'm new to this technology I really dont >> understand the terminologies used. I dont need to do h/w implementation, >> just a simulation would be enough. Also i need to do physical >> implementations(dont know what that means). >> >> >> >> --------------------------------------- =A0 =A0 =A0 =A0 >> Posted throughhttp://www.FPGARelated.com > >If you need to do physical implementations, you need to do hardware >implementations. > >If you're doing more than just using the high speed interface (such as >the Rocket I/O used in the Xilinx chips you can target with ISE) to >deliver delay granularity of about 1/3 of a nanosecond, you will have >difficulty getting a good simulation since proper timing situation is >difficult. > >If you're looking to push the delay granularity, there are techniques >which can be used to leverage internal delays within CLBs or carry >chains that don't lend themselves to exceptional timing simulation. > >If you're clear on what you want to accomplish we may be able to >provide some good direction or point you to application notes on >existing designs. > >But you *really* need to know what's expected of you in the way of the >physical implementation requested. > >- John_H > Hi, John, Can I use gates(adder,AND gate,etc.) to generate delays. If yes what should be the input and output. I'm just supposed to do simulation, no physical implementation required. If would be really helpful if I could get some help on this. Thanks. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 145087
On Jan 26, 10:54=A0am, "Pallavi" <pallavi_mp@n_o_s_p_a_m.rediffmail.com> wrote: > >On Jan 25, 10:17=3DA0am, "Pallavi" <pallavi_mp@n_o_s_p_a_m.rediffmail.co= m> > >wrote: > >> >On Jan 25, 6:25=3D3DA0pm, "Pallavi" > > <pallavi_mp@n_o_s_p_a_m.rediffmail.com=3D > > > > >> >wrote: > >> >> Hello, > > >> >> I need to implement a project as a part of my Masters curriculum > using > >> fp=3D3D > >> >ga > >> >> devices that would generate delays, that is generate higher output > >> >> frequencies than the system clock using propagation delays. I'm > using > >> ISE > >> >> tool for the same. I'm new to this technology and would really > >> appreciate > >> >> if i could get some help on this. Thanks in advance. > > >> >> --------------------------------------- =3D3DA0 =3D3DA0 =3D3DA0 =3D= 3DA0 > >> >> Posted throughhttp://www.FPGARelated.com > > >> >This is a somewhat confused question ? > >> >If you want to generate delays, you do not need to 'over-clock' - jus= t > >> >choose a FPGA with inbuilt delay blocks, and they will have a step > >> >size, much smaller than any clock precision. > >> >ie the FPGA vendors have solved this problem already. > > >> >-jg > > >> Thanks for ur response. As I'm new to this technology I really dont > >> understand the terminologies used. I dont need to do h/w > implementation, > >> just a simulation would be enough. Also i need to do physical > >> implementations(dont know what that means). > > >> --------------------------------------- =3DA0 =3DA0 =3DA0 =3DA0 > >> Posted throughhttp://www.FPGARelated.com > > >If you need to do physical implementations, you need to do hardware > >implementations. > > >If you're doing more than just using the high speed interface (such as > >the Rocket I/O used in the Xilinx chips you can target with ISE) to > >deliver delay granularity of about 1/3 of a nanosecond, you will have > >difficulty getting a good simulation since proper timing situation is > >difficult. > > >If you're looking to push the delay granularity, there are techniques > >which can be used to leverage internal delays within CLBs or carry > >chains that don't lend themselves to exceptional timing simulation. > > >If you're clear on what you want to accomplish we may be able to > >provide some good direction or point you to application notes on > >existing designs. > > >But you *really* need to know what's expected of you in the way of the > >physical implementation requested. > > >- John_H > > Hi, John, > > Can I use gates(adder,AND gate,etc.) to generate delays. If yes what shou= ld > be the input and output. I'm just supposed to do simulation, no physical > implementation required. If would be really helpful if I could get some > help on this. Thanks. =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com It would really help to study the logic block architecture of your FPGA if you want to do "gate-level" delays. Usually Adders, AND gates, etc. are implemented in LUT's and possibly some dedicated carry logic. If you want to create delays and not have the synthesis tools rip out your delay as a piece of unnecessary logic, you need to instantiate a LUT or carry element to create your delay. I believe that there are app notes on the Xilinx website for using carry chains as variable delay elements. Regards, GaborArticle: 145088
On Jan 26, 10:54=A0am, "Pallavi" <pallavi_mp@n_o_s_p_a_m.rediffmail.com> wrote: > > Hi, John, > > Can I use gates(adder,AND gate,etc.) to generate delays. If yes what shou= ld > be the input and output. I'm just supposed to do simulation, no physical > implementation required. If would be really helpful if I could get some > help on this. Thanks. =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com This is very advanced stuff not intended for mainstream use. It's quite possible that the simulation output will not have proper values for the routing delays and the delays of the individual elements. But maybe it'll work. Gabor is correct: you need to instantiate your LUT4 and/or MUXCY primitives so the synthesizer doesn't optimize them away. I wanted to develop an alternative to the Delay Locked Loop used in many Xilinx devices allowing me to have full control over the characteristics so I could determine where in the phase of my "ring oscillator" a signal edge occurred. I consider myself an expert, expecially at this level of detail. I couldn't come up with a solid approach in a reasonable amount of time. A ring oscillator with LUTs are best put together within one CLB which requires a significant amount of time figuring out intra-CLB routing delays to have decent delay matching. I couldn't do what I wanted within one CLB so I used two adjacent CLBs trying to get good, tight delays between those basic architecture elements. The attempt at using a carry chain is hampered by the time needed to take a signal off the carry chain and insert the inversion back to the bottom. The delays from these elements are affected by other things that happen within the FPGA - voltage rails, temperatures, nearby activity - such that the oscillators need constant calibration or measurement to match up to something external. If you just want a delay across a small range - 10s of nanoseconds, perhaps - you can get the resolution down to about the delay of a LUT but you'll have a full scale error that's significant. Using a chain of LUTs that are manually placed and perhaps manually routed as well, you can connect a series of LUT4 primitives configured as inverters; if you connect them as buffers you'll get different delays for rising edges than for falling edges. Getting the signal selectively injected into the chain or multiplexed out of the chain with deterministic delays is ugly. You will be faced with an absolute minimum delay, a delay full-scale that's difficult or impossible to calibrate, and poor consistency in the delay steps (the equivalent of poor differential linearity in Analog to Digitial or Digital to Analog converters). I don't want to provide you with a solution because I know a good solution is hard work. I want to set up your expectations. And you haven't told us what is required of you in the "physical implementation" you mentioned in the beginning.Article: 145089
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? In 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 BromleyArticle: 145090
Gabor wrote: > Let's hope they are shipping product before 1.5 GHz becomes > the industry norm. hope is fine, you know... and I've heard that the latest X&A parts do push the integration, density and capacity, but not speed, due to power consumption issues. so i'm a bit hopeful. Anyway, if they come too late, they will have burnt so much money that they will simply close. Or be bought by X or A... hurry up ! yg -- http://ygdes.com / http://yasep.orgArticle: 145091
On Jan 26, 12: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 Hello Jonathan, Not with the carry chains, as they all run in the same direction. Regards, John McCaskill www.FasterTechnology.comArticle: 145092
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 Actually the delay resolution would be two carry chain delays which is much shorter than 2 LUT delays. That would certainly make life easier, but as John McC noted, you only get chain propagation in one direction. I once tried to generate a variable delay element by feeding the same signal into a number of taps in the same carry chain. It turned out that the signal routed up the chain in the same direction as the carry, and the routing delay matched the carry chain delay almost perfectly, so changing the tap made essentially no difference at all. This is really the sort of thing you need to know the guts of your chip to implement. regards, GaborArticle: 145093
Hi Guys, My original plan was to make the TimingAnalyzer a commercial product that would sell for about $200 but would have most all the features of the programs that cost $1000 and more. It's just me alone doing the development and its going very slow cause I work full time and only have some evenings and weekends to work on it. I'm hoping that happens some day but it will not be anytime soon. I work full time as a design engineer and continue the development of the program because I find it very useful to document interface timing diagrams from simulations and visualize new logic designs with timing diagrams that are built quickly using the logic simulation functions. Still a lot to do with logic simulations. I'm looking at retiring in 10 years or so and then I might consider making it a commercial product. In the mean time, the plans are to continue the development and add new features and continue to make it easier to use. I'm not happy with the Java GUI and plan to switch to a compiled language that supports cross-platform GUIs and Python for scripting. Others have shown interest in helping with the development if it was open source project so I'm thinking about that as well, but I need to feel 100% sure that is right thing to do. Either way, I will always support the program and the user community and continue to add features requested by the users. I hope this clears the air a little. If you have any questions, please just ask. Dan Fabrizio On Dec 18 2009, 12:34=A0pm, chris <chris.fel...@gmail.com> wrote: > Tobasco, > At least tell me you have the intelligence to tell the difference > betweengtkwave(which I wholeheartedly support) and > timing-diagrams.com (whose intention is still unclear till today). > Zheng > On Mon, 17 Aug 2009 19:43:06 -0500 "Tobasco" > > - Hide quoted text - > > <nothankstoem...@nothanks.com.cx.ch> wrote: > > Please ignore anyone telling you not to mention your timing diagram > > software. It looks useful and I've played around with it a bit. You > > give it away for free. No one "runs" usenet so use it as you will as > > long as you are respectful. I guarantee you that no one cares if you > > piss off Zheng. It's free software as per your website; not everyone > > wants to release their source code. As much as I love open source > > software it isn't the end all be all philosophy on like. > > I guess I don't see the big deal? =A0What does it matter what the > intentions of timing_analyzer are? =A0I guess if you become dependent on > the software and the project dies, it could be frustrating? =A0But in > either case small plugs for the software should be tolerable (not much > different than having a company signature at the end of each post). > Timing analyzer is still free software and others have found benefit > and use out of the project. =A0I am not bothered by the posts for Timing > analyzer. > > chrisArticle: 145094
On Tue, 26 Jan 2010 12:35:45 -0800 (PST), Gabor wrote: [me] >> 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? In 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. >Actually the delay resolution would be two carry chain delays >which is much shorter than 2 LUT delays. No; both you and John misunderstood me. I am fully aware that the carry chain only goes in one direction, so that's why I suggested the more modest goal of using the LUTs. >I once tried to generate a >variable delay element by feeding the same signal into a >number of taps in the same carry chain. It turned out that >the signal routed up the chain in the same direction as the >carry, and the routing delay matched the carry chain delay >almost perfectly, so changing the tap made essentially >no difference at all. Right; precisely the reason I was interested in the "hairpin" solution. I know that LUT-delay is not an especially fine timing vernier, but it was something worth asking, no? As a small refinement of my original plan, perhaps you could make the hairpin chain from carry logic in one direction, and LUTs the other. That would roughly halve the step size without affecting the basic idea. -- Jonathan BromleyArticle: 145095
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. mtArticle: 145096
On Wed, 27 Jan 2010 00:35:17 -0800 (PST), maurizio.tranchero 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. The last time I asked, about a year ago, they had distribution channels and were prepared to sell a development kit - but they wanted a lot of money for it (around $15k IIRC). That sounds brutal, but in reality it's a sensible way for an early-stage startup to restrict their customer base to a few large, serious customers whom they can then support properly. They probably have only a tiny handful of applications people, and having a large number of small early-adopter customers would hopelessly stretch their resources. 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. -- Jonathan BromleyArticle: 145097
On Dec 23 2009, 1:28=A0pm, GLOW <glen.h.l...@gmail.com> wrote: > Antti, > > Based on all the symptoms you have described, namely the read side of > the fifo going crazy and getting stale or duplicated data strongly > suggests that the problem is in the recovered clock. > > I once worked on a chip where the duty cycle of the recovered clock > can vary widely and that the recovered clock even occasionally have a > stretched cycle where the clock looked like it was missing a cycle. > This was on an actual asic as opposed to an fpga. But the bottom line > was that we had unintentionally assumed that the recovered clock would > always be 50/50 duty cycle and that the recovered clock would never do > strange things like skip a clock. > > If at all possible, I suggest you try the following. > > 1) I assume that you are using the recovered clock directly. If you > are, try running the clock thru an onboard PLL and use the pll > generated clock instead. If this helps your problem then do #2 below. > > 2) Route the recovered clock back out to a pin and observe it on a > 1GHz scope. Configure the scope to trigger on anything less than 40/60 > duty cycle. > > Good Luck.... problem fixed! solution and explanation in the next Brain issue (I will post short post also after the issue release) AnttiArticle: 145098
The new vMAGIC release includes a number of new features, such as a new type handling system, simplified expression building, customizable VHDL output, and (finally) support for several things that have so far been missing (like VHDL package building). Also, the new version uses much less memory and performance was dramatically improved. This of course implies some massive changes to the API, which now presents a much more consistent access to VHDL. We have split the package in two (vMAGICParser and vMAGIC) such that if you want to create stuff only, you don=92t have to provide parser and ANTLR libs. We are currently testing vMAGIC using formality, such that we can find bugs in the parser/writer combination. If you find any, please let us know via the SF forums. Demos and documentation are coming up; we=92ll keep you posted on that! Visit us on http://vmagic.sf.net/Article: 145099
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. =A0It'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.
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