Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Mar 18, 8:00=A0am, Andy <jonesa...@comcast.net> wrote: > Andy > > "ever possible"? Yes. =A0That's one reason why I prefer async resets for > device initialization (but not for simply setting a counter back to > zero during its normal course of operation, etc.) > > Andy fpgabuilder, From Sun code documents of OpenSparc CPU T2, there are 6 types of reset signals, a situation much more complexer than we think. WengArticle: 146451
On 03/18/2010 10:03 AM, Francesco wrote: > seems that Xilinx has decided to have only one distributor... Really? Their authorized distributors page lists two.Article: 146452
On Thu, 18 Mar 2010 07:03:38 -0700 (PDT), Francesco <francescopoderico@googlemail.com> wrote: >Hi all, >seems that Xilinx has decided to have only one distributor... and >NuHorizons seems out of business. Does anybody know the reason behind? >I believed was a good idea to have have the opportunity to buy from 2 >distributors. Yup. NuH may have to rif around 200 FAEs. Xilinx was something like 35% of their business. It was apparently a shock to them. I suppose this is a good time to hire unemployed FPGA guys... I might do that. JohnArticle: 146453
Francesco <francescopoderico@googlemail.com> wrote in news:e61615fa-03f1- 44ff-830c-c5e5c3445ed2@x12g2000yqx.googlegroups.com: > On 16 Mar, 02:42, Teófilo Monteiro <te0of...@gmail.com> wrote: >> Hi, >> >> I need an information. I need to have an FPGA Board and recive from a >> adc working between 20MHz and 100MHz, but i don't have any idea who >> to do it because i don't know any site that sells this things >> together! >> >> Thanks for the attention > > We have a product that might be appropriate. It uses an Analog Devices ad9238 or ad9248. You can use with our SHARC based DSP modules. Our dspblok 21369 +fpga includes a Cyclone III. Here is a link: http://www.danvillesignal.com/dspblok/dspblok-sdr-software-defined-radio.html Al Clark www.danvillesignal.comArticle: 146454
On 03/18/2010 12:59 PM, summer wrote: > Hello Andy, > > Thanks for your clues. :) > Sorry for late appreciation,I have exams this week. Best of luck with the exams. Andy > > anyway,i will try my best! > > Thanks, > Summer > > --------------------------------------- > Posted through http://www.FPGARelated.comArticle: 146455
austin <austin@xilinx.com> wrote: >Re: bashing Xilinx software ... > >S6 was designed for cost (low) and power (low). > >We surveyed customers, and asked them what they wanted. > >And, we listened to them. > >Unfortunately, we have trained customers since the first Spartan >device, that Spartan of the next node, could be used to replace a >Virtex of the previous node... > >While that may have sometimes been true, S6 WAS NOT designed to >cannibalize V5 sockets, and is designed to meet better price, and >power points than Spartan 3, 3A, 3E. > >So, yes, the software will work very very hard to meet an unrealistic >expectation of timing. And it might fail in the larger S6 parts to >meet said unrealistic goals. > >That said, the software has actually improved with every release (in >my opinion, as an actual user). Can I rephrase that as: an ISE7.x project which doesn't meet timing by a few percent will be routed OK with a newer version of ISE? -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 146456
Peter Alfke <alfke@sbcglobal.net> wrote: >On Mar 17, 2:02=A0pm, austin <aus...@xilinx.com> wrote: >> Re: bashing Xilinx software ... >> >> S6 was designed for cost (low) and power (low). >> >> We surveyed customers, and asked them what they wanted. >> >> And, we listened to them. >> >> Unfortunately, we have trained customers since the first Spartan >> device, that Spartan of the next node, could be used to replace a >> Virtex of the previous node... >> >> While that may have sometimes been true, S6 WAS NOT designed to >> cannibalize V5 sockets, and is designed to meet better price, and >> power points than Spartan 3, 3A, 3E. >> >> So, yes, the software will work very very hard to meet an unrealistic >> expectation of timing. =A0And it might fail in the larger S6 parts to >> meet said unrealistic goals. >> >> That said, the software has actually improved with every release (in >> my opinion, as an actual user). >> >> Does the software have to improve further: =A0yes, it does. =A0You can >> always do a better job with software. >> >> But, I would always choose the latest software, and the latest >> hardware for any new project: =A0all the attention is on it, the price >> curve will be the steepest (price will fall faster), and it will have >> the best support. >> >> Come on folks, this used to be a real forum, with useful information. >> >> Lately, this is like an old folks home, with everyone complaining >> about their ailments.... >> >> Did Xilinx, by creating their own user forums, completely kill c.a.f? >> If it goes on like this much longer, I will delete my link to it .... >> no one even bothers to email google to get rid of the spam here! (As a >> test, I emailed google, and they removed the spam I noted in the email >> to them -- the "report spam" button does nothing) >> >> Austin > >Right on, Austin ! >Spartan is for low cost and low power, do not complain about the >performance >Virtex is for features and performance, do not complain about the >price. Still, a Spartex device would be nice. Many years ago we split a Virtex design into multiple Spartan devices which cut the money spend on Xilinx devices by 60%. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 146457
On Mar 19, 4:35=A0am, austin <aus...@xilinx.com> wrote: > to jg: > > Oh, and lastly, yes, the smallest S6 is H U G E ! compared with > Spartan 3 family...in effect I do not think there is a "low end" in > the Spartan 6 family! =A0The die would be so small as to not be build- > able (all IO ring, nothing in the center). Yes - note quite different from your initial claims of always using the newest (because it would be cheapest) ... ;) > There is this "low end, low cost" market that everyone is agonizing > over: =A0how big is it? =A0What do they need? =A0What do they want? =A0Ho= w low > must the price be to sell, compete, and still be able to make a > reasonable margin? =A0Is it better to serve larger markets? =A0I do not > know the answers. A revealing statement. I know fpga vendors are somewhat condemned to labor at the leading edge, but you could try having lunch with some guys from your CPLD division sometime.. ? ( or, even more radical, a customer.. ) -jgArticle: 146458
jg, There are a lot of lunches being eaten. At least, the excuse for those tasked with the eating (and listening) is that they are gathering information. .... AustinArticle: 146459
On Thu, 18 Mar 2010 08:35:37 -0700 (PDT) austin <austin@xilinx.com> wrote: > To John: > > Do you have a webcase filed? Whay is the number (I can look it up). > 820404, preceeded by 820466. For plus of a month now I've been fighting to get the simple task of running a DRAM interface from a 192 MHz clock, generated internally by a PLL. The entire point of using an S6 on this project rather than an S3 was that the memory interface was supposed to be more robust. Instead I've had timing errors, placement errors, signals that don't match the documentation, and a steady stream of being passed around from one person to another. In ISE 11.2, the MIG for the S6 would only generate Verilog. If you had other cores that you wanted in VHDL you had to generate an entire seperate CoreGen project for the MIG because there was no way to set the language as a per core setting. When I upgraded to ISE 11.3 it would generate VHDL, but the VHDL wouldn't build. There were several mismatched vector lengths and no indication anywhere as to which were right. Tail between my legs, I went back to Verilog. When I upgraded to ISE 11.4, the MIG core required manually editing the code after the fact because the generated code gets the polarity backwards on the calibration routines. The only way to determine this is to go hunting around at random on support.xilinx.com, where there is no better search you can run than just "MIG", and then sort through pages and pages of results, many of which are half a decade out of date. On top of this, UG416 claims that there are debugging signals available for simulation. The most obvious of these, ctrl_state, is defined in the documentation to be a 5 bit vector that encodes the state. And yet, in the simulation model, the signal turns out to be a whopping 144 bit vector, requiring yet another support request, and yet another week, to find out that it's actually the ASCII representation of the state. Occasionally, I like to gripe that it seems like Xilinx doesn't give the proper thoroughness to testing the tools out before releasing them out in the wild. When I do, that's what I'm talking about. And while it's all well and good if the timing engine now squeezes an extra 0.1% from the timing, allowing me to now just barely make timing on a design that previously just barely failed, every time I have to spend a month fighting stupid mistakes in the tools I reflect on the fact that I could have fixed the timing problems in only a couple of days. > [snip] > > Oh, and lastly, yes, the smallest S6 is H U G E ! compared with > Spartan 3 family...in effect I do not think there is a "low end" in > the Spartan 6 family! The die would be so small as to not be build- > able (all IO ring, nothing in the center). > > There is this "low end, low cost" market that everyone is agonizing > over: how big is it? What do they need? What do they want? How low > must the price be to sell, compete, and still be able to make a > reasonable margin? Is it better to serve larger markets? I do not > know the answers. > > Good thing we plan to offer the 3A ( 3AN) family for as long as folks > keep ordering it, > > Austin I think the (lower-end) S3A makes a good compliment to the S6. They're really kinda different tools for different jobs. With an external serial flash and an LDO to generate the core voltage, Digikey can sell me a fairly heavy-duty programmable logic solution for under $7 in small quantities. At that price point, you don't throw it at traditional FPGA tasks, you throw it at the sorts of things you would have used to divide up in ugly manners across multiple CPLDs. IO port expanders, parallel interface transcievers, LCD controllers. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 146460
Hi, I wrote a small example for the Digilent Spartan 3 Starter Kit. It uses the sram to store graphics data. Actually basing on this module I wanted to code a fractal generator. Here is the link, maybe someone finds it useful : http://tokis-edv-service.de/index.php/beispiele/spartan-3-example-1 The last test is a rather long time ago. Best Regards ThorstenArticle: 146461
On Mar 19, 10:59=A0am, Rob Gaddi <rga...@technologyhighland.com> wrote: < tool chain woes > Could this be time for a 'plan B' - can some other 'less early adopter' device achieve those targets ? [ If it cannot manage this small piece, what's it going to do to the rest of the design.. ? ] -jgArticle: 146462
On Thu, 18 Mar 2010 15:36:39 -0700 (PDT) -jg <jim.granville@gmail.com> wrote: > On Mar 19, 10:59=A0am, Rob Gaddi <rga...@technologyhighland.com> wrote: > < tool chain woes > >=20 > Could this be time for a 'plan B' - can some other > 'less early adopter' device achieve those targets ? > [ If it cannot manage this small piece, what's it going to do to the > rest of the design.. ? ] > -jg >=20 Unfortunately the PCB's fabbed and stuffed. Giving up on the Spartan-6 now would require pretty substantial redesign, and throwing out a decent amount of investment. --=20 Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 146463
On Mar 19, 11:43=A0am, Rob Gaddi <rga...@technologyhighland.com> wrote: > On Thu, 18 Mar 2010 15:36:39 -0700 (PDT) > > -jg <jim.granvi...@gmail.com> wrote: > > On Mar 19, 10:59=A0am, Rob Gaddi <rga...@technologyhighland.com> wrote: > > < tool chain woes > > > > =A0Could this be time for a 'plan B' - can some other > > 'less early adopter' device achieve those targets ? > > =A0[ If it cannot manage this small piece, what's it going to do to the > > rest of the design.. ? ] > > -jg > > Unfortunately the PCB's fabbed and stuffed. =A0Giving up on the Spartan-6 > now would require pretty substantial redesign, and throwing out a > decent amount of investment. Understood, but you could fairly easily check other devices in a virtual sense, to see if they can meet timing without the migraines ? [ Of course, Xilinx will have designed the S6 to be footprint compatible with alternatives, right ? ;) ]Article: 146464
On Mar 17, 6:24=A0am, Magne Munkejord <magnem...@yahoo.no> wrote: > rickman wrote: > > On Mar 16, 8:24 pm, Weng Tianxiang <wtx...@gmail.com> wrote: > >> On Mar 16, 2:04 am, Magne Munkejord <magnem...@yahoo.no> wrote: > > >>> rickman wrote: > >>>> You would think that. =A0I just had to change some code to eliminate= a > >>>> sync reset on a register to get rid of one level of LUTs in a Lattic= e > >>>> design which has a similar if not same FF structure with the dedicat= ed > >>>> LSR input (Local Set/Reset). =A0Synplify seems to not know how to us= e > >>>> that. =A0Maybe this would get changed by the mapper, but I don't thi= nk > >>>> it does that. =A0I was looking at it in the synthesis tool. =A0Have = you > >>>> tried an example? =A0Does Synplify do a better job with the Xilinx p= arts > >>>> than they do with Lattice parts? =A0I'm not convinced they do a good= job > >>>> with the arithmetic units. =A0It is more than once I've seen an adde= r > >>>> chain duplicated to get the carry out of the top! > >>> Hi Rick, > >>> I tried 5-input registered OR, like this: > >>> =A0 =A0 =A0p_sync_or : process (clk) is > >>> =A0 =A0 =A0begin > >>> =A0 =A0 =A0 =A0 =A0if rising_edge(clk) then > >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0q <=3D a or b or c or d or e; > >>> =A0 =A0 =A0 =A0 =A0end if; > >>> =A0 =A0 =A0end process p_sync_or; > >>> In a Virtex4 (4 input LUTs) XST synthesis connects input 'e' to the s= et > >>> port of the register, and so does not require two LUTs to implement t= he > >>> gate. > >>> When it comes to Synplify I only have the actel edition ( only actel > >>> parts supported(?)) and I have hardly ever used it. > >>> I think actel parts only support async resets for their registers, in > >>> which case it is true as you say, that designing synchronous resets w= ill > >>> generate extra logic in front of the registers. Maybe this is true fo= r > >>> Lattice as well. In that case I would prefer using an async reset to > >>> avoid the extra logic and performance penalty. > >>> If the reset signal is synchronously deasserted, it can be constraine= d > >>> so that one is certain it will reach each register at a proper time. > >>> Magne > >> Magne, > >> Your method is wrong ! > > >> You cannot connect 'e' to the set port of the register. It may > >> compromise a new data which uses 'q'. > > It wasn't me, XST did it! > > > > >> Imagine the case: if 'e' is so earlier asserted that 'q' is asserted > >> and changes a data 'New" which uses 'q' during setup or hold time > >> around the next clock triggering edge.Next 'New' signal data may be > >> invalid. > > >> p_sync_or : process (clk) is > >> =A0 =A0 =A0begin > >> =A0 =A0 =A0 =A0 =A0if rising_edge(clk) then > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0q <=3D a or b or c or d or e; > >> =A0 =A0 =A0 =A0 =A0end if; > >> =A0 =A0 =A0end process p_sync_or; > > >> A : process(clk) > >> =A0 =A0 =A0begin > >> =A0 =A0 =A0 =A0 =A0if rising_edge(clk) then > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0New <=3D a and q; > >> =A0 =A0 =A0 =A0 =A0end if; > >> =A0 =A0 =A0end process A; > > >> Weng > > Since the 'set' port of the register is synchronous the circuit will > behave as your code above describes it. q will not change state before > rising edge of clk even if e is asserted earlier. I would think the > timing tools knows the required setup time for the synchronous set/reset > ports, and cover their paths as any other synchronous elements. > > > I'm not clear on what your concern is. =A0Perhaps you are thinging Magn= e > > is talking about e being connected to an async set? =A0He is describing > > a FF with an async set which will do exactly the same thing as an OR > > of signal e with the rest of the inputs. > > > Rick > > The second instance of 'async' I would correct to 'sync', but I guess > that was a typo. > > Magne Yes, it was a typo... in other words, a mistake... Why do they call it a "typo". It was a mistake regardless of how you categorize it. RickArticle: 146465
On Mar 18, 11:41=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > On Mar 18, 8:00=A0am, Andy <jonesa...@comcast.net> wrote: > > > Andy > > > "ever possible"? Yes. =A0That's one reason why I prefer async resets fo= r > > device initialization (but not for simply setting a counter back to > > zero during its normal course of operation, etc.) > > > Andy > > fpgabuilder, > > From Sun code documents of OpenSparc CPU T2, there are 6 types of > reset signals, a situation much more complexer than we think. > > Weng Ok, go ahead and tease us! Or are you going to share with us what the six types are? RickArticle: 146466
On Mar 17, 11:33=A0am, jacko <jackokr...@gmail.com> wrote: > Looks like a phase controlled DCO. Maybe the frequency/phase d/dt fm > effect can be used? It does look messy, modulus if its a power of 2 > should be easy to remove by a (x downto y) subrange select. If modulus > is n/(n-1) then consider MASH or bitstream delta sigma. OR use a fixed > point overflow clock gating. Has anyone ever tried n/(n-2) via up/down > clock gating of an n divider?? > > Cheers Jacko Gating (or enabling actually) a divider to adjust a clock rate will give you the average rate you need, but it results in a jitter about equal to the output clock period, i.e. 100%. Using a DCO results in an output jitter equal to one reference clock period. In my DCO the modulus is a power of two and there is no need to do anything with the range. When the counter reaches its max count of 2^n-1 it just naturally overflows, as does unsigned arithmetic in numeric_std. But integer arithmetic doesn't, so I have to use the mod operator. If you want a modulus that isn't a power of 2, you can build the counter so it loads modulus-1 and counts down giving a carry out at 0. I knew I had no need to use a modulus that wasn't a power of two, so I wrote the code without considering that. RickArticle: 146467
Rob, Checking now. I will post back when I have the whole story ... AustinArticle: 146468
Hi everyone, I'm just about to start an implementation of an open spacewire IP core (still trying to understand under which license, GPL, LGPL, CeCILL...) and I was wondering whether is a good idea to have a wishbone interface implemented. I am pretty new to SoC bus and even though google is "one of my best friends" I still didn't get the feeling how popular it is and how spread it is at the moment or will be in the future. If anyone has any opinion I would be glad to listen to it. Thanks a lot, Al -- Alessandro Basili CERN, PH/UGC Hardware DesignerArticle: 146469
On Thu, 18 Mar 2010 09:20:38 +0200, Kim Enkovaara <kim.enkovaara@iki.fi> wrote: >austin wrote: >> That said, the software has actually improved with every release (in >> my opinion, as an actual user). > >For example >the timing engine of ISE is starting to show its age. There is no SDC >support, which is much more flexible format than the UCF (and >supported by many tools in the flow). This is certainly very true; specifically there is no way to constrain multi-cycle holds properly and the default handling is flawed (err, flat out wrong?). The timing engine needs a more up to date interface and probably a check-up of the back-end too. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 146470
On Fri, 19 Mar 2010 16:29:54 +0100 Alessandro Basili <alessandro.basili@cern.ch> wrote: > Hi everyone, > I'm just about to start an implementation of an open spacewire IP > core (still trying to understand under which license, GPL, LGPL, > CeCILL...) and I was wondering whether is a good idea to have a > wishbone interface implemented. > I am pretty new to SoC bus and even though google is "one of my best > friends" I still didn't get the feeling how popular it is and how > spread it is at the moment or will be in the future. > If anyone has any opinion I would be glad to listen to it. > Thanks a lot, > > Al > I use it a lot on my projects, though I rarely bring in any 3rd party IP. The thing about a WISHBONE bus is that it's really just a consistent way of naming the minimal set of signals you'd need to have a SoC bus. Data, address, chip select, read/write, return data and a handshake. As compared to other SoC buses I've looked at, WISHBONE takes far less coding effort to deliver somewhat less performance. It's a simple enough thing that you can make practically any kind of slave, or any kind of master, talk to it. The lack of pipelining can kill your throughput if you're really having to push a lot of data, but for most applications it's plenty sufficient. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 146471
On Mar 19, 8:29=A0am, Alessandro Basili <alessandro.bas...@cern.ch> wrote: > Hi everyone, > I'm just about to start an implementation of an open spacewire IP core > (still trying to understand under which license, GPL, LGPL, CeCILL...) > and I was wondering whether is a good idea to have a wishbone interface > implemented. > I am pretty new to SoC bus and even though google is "one of my best > friends" I still didn't get the feeling how popular it is and how spread > it is at the moment or will be in the future. > If anyone has any opinion I would be glad to listen to it. > Thanks a lot, > > Al > > -- > Alessandro Basili > CERN, PH/UGC > Hardware Designer I have worked with 3 "externally defined" on-chip buses: 1) Avalon (Altera) 2) OPB (sp?) (Xilinx) 3) Wishbone (GPL/Lattice) Semi-random opinions: Expanding on Rob's comment, using a bus that "someone else" defines means that there's one less definition that *you* have to do; this is a good thing. The NIOS and EDK buses are mostly useful in their manufacturer's tool- chain, and their devices. The translation from Avalon to Wishbone is trivial though. I had to sign an 'NDA' with IBM to get the documentation for the EDK bus. This didn't make a lot of sense to me. The Wishbone is popular enough that IP vendors will code to it without a lot of resistance. This isn't always true with proprietary buses. There you go; a bunch of reasons to use it, and none (so far) to NOT use it. RKArticle: 146472
"Alessandro Basili" <alessandro.basili@cern.ch> wrote in message news:ho059b$hpl$1@speranza.aioe.org... > Hi everyone, > I'm just about to start an implementation of an open spacewire IP core (still > trying to understand under which license, GPL, LGPL, CeCILL...) and I was > wondering whether is a good idea to have a wishbone interface implemented. Depending on what you want to do with the core but I would suggest you also have a look at the Amba bus since (thanks to Gaisler research?) this bus seems to be gaining popularity amonst the space/mil-aero users. Hans www.ht-lab.com > I am pretty new to SoC bus and even though google is "one of my best friends" > I still didn't get the feeling how popular it is and how spread it is at the > moment or will be in the future. > If anyone has any opinion I would be glad to listen to it. > Thanks a lot, > > Al > > -- > Alessandro Basili > CERN, PH/UGC > Hardware DesignerArticle: 146473
"Thorsten Kiefer" <info@tokis-edv-service.de> wrote in message news:17niij03a6nx9.1h1jj0j0b8jgk.dlg@40tude.net... > Hi, > I wrote a small example for the Digilent Spartan 3 Starter Kit. > It uses the sram to store graphics data. > Actually basing on this module I wanted to code a fractal generator. > Here is the link, maybe someone finds it useful : > http://tokis-edv-service.de/index.php/beispiele/spartan-3-example-1 Why would anybody find this useful? You only provide a bit file for one particular prototype board. I would add the code or at least add some comments on the lessons learned writing for this board. Hans www.ht-lab.com > The last test is a rather long time ago. > > Best Regards > ThorstenArticle: 146474
On Mar 19, 6:32=A0am, rickman <gnu...@gmail.com> wrote: > On Mar 18, 11:41=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > On Mar 18, 8:00=A0am, Andy <jonesa...@comcast.net> wrote: > > > > Andy > > > > "ever possible"? Yes. =A0That's one reason why I prefer async resets = for > > > device initialization (but not for simply setting a counter back to > > > zero during its normal course of operation, etc.) > > > > Andy > > > fpgabuilder, > > > From Sun code documents of OpenSparc CPU T2, there are 6 types of > > reset signals, a situation much more complexer than we think. > > > Weng > > Ok, go ahead and tease us! =A0Or are you going to share with us what the > six types are? > > Rick Yeah! What are those?
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