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 Jim, If you can give the overview picture of your system, I could then create a similar system using MicroBlaze. This will give you something to compare against. Göran Bilski "Jim M." wrote: > I recently purchased a NIOS Stratix 1S10 Development Kit from Altera > and have mixed feelings about Quartus, SOPC Builder, and the NIOS > Core. (For those poor souls interested, I've included some comments > at the end of this post... feel free to provide feedback.) > > However, here's my question: > > What's the maximum clock frequency anyone has achieved using the NIOS > 3.0 CPU in 32bit mode with the standard peripherals (SRAM, SDRAM, > Ethernet, PIO, UART, etc. as in the Reference Design provided by > Altera)? > > I've tried isolating the various components into LogicLock regions. > I've tried different fitter/netlist optimizations. The maximum Fmax I > have achieved to date is 80 MHz. This is after letting Quartus "fit" > for 10 hours... it actually didn't stop, I had to abort the fitting > and refit to finially get an interim result (see other misc comments > below). > > Altera advertises 125 MHz for the Stratix Device and NIOS 3.0... > However a reference design that builds at that clock rate is not > provided. It appears that Altera gives you just enough to get your > feet wet... anything above and beyond that is Intellectual Property > that you need to buy. > > Other Observations/Comments: > > 1. The Quartus II SP1 software is extremely flakey. I've generated > numerous faults when deleting/modifying child LogicLock Regions. It > also takes forever to fit my Stratix design which is only 6000 LEs. > If I select the "limit fitting attempts to 1" option, Quartus > sometimes fits many times (like forever...) why?!?!? Also, after a > design is finished building, the software sits around for up to 5 > minutes before it generates a "finished" dialog box. I'm not sure > what's going on between the Quartus Application thread and the Quartus > Compiler thread, but it's fustrating enough just waiting for the > design to build, let alone waiting for Quartus to figure out the build > is done. I could go on and on, and that's only the result of 4 weeks > of effort with a small design. I feel sorry for those folks working > on a 100,000+ gate design. I guess modularity is the key there. > > 2. I can't simulate designs with virtual pins. I get warning during > the analysis of the simulation and then receive results with all input > pins a zero and output pins undefined. In addition, I can generate > hold time warnings during simulation for a design that didn't compile > with any hold time warnings. I'm not talking about hold time warnings > on my input signals, I'm talking about hold time warnings on internal > registers in my verilog code. Registers that I've taken care to hold > for 1 or more clock cycles before using in other parts of the design. > Again, the compilation of the design did not generate hold time > warnings... only the simulation of the design. > > 3. PLLs generate different timing analysis results. THIS IS VERY > ANNOYING! When I build up a "black-bock" design with virtual pins I > obtain a Fmax calculation from the timing analysis routine. I then > LogicLock the design and export it. When I import the design into a > new project and clock it using a PLL it generates negative slack time > warnings! If I remove the PLL and replace it with a clock pin, I get > the Fmax result that I obtained during the "black box" design. I beat > myself up for a week trying to debug a design that wasn't broken > because of this goofy behavior in Quartus. I'm still not sure if the > slack time warning it legit and wether I should be concerned about it. > > 4. SOPC Builder will lock itself up if you double-click components > before selecting them. Give it a try... double click a component line > in your NIOS design before selecting the line item. After a couple > times the SOPC builder application creeps to a halt. > > 5. Documentation on the various megafunctions is lacking. A good > example is the altsyncram megafunction. It doesn't state any timing > requirements on the input registers, enable, and clock signals. Do I > hold the data 1 cycle before flipping the write enable? How about > holding the write enable before de-activating it? Why is the > addressing based upon the data bit-width? Trying to tie a 32-bit > altsyncram block to a NIOS CPU is difficult because you need to > specify the address space of the peripheral and the address space of > the altsyncram block is based upon the bit width (not the number of > bytes). > > 6. I have yet to get a Leonaro-Spectrum synthesized Verilog file to > build in Quartus. I can used Spectrum generated .edf files but not > verilog. I get LCELL parameter errors. Unfortunately, Altera can't > seem to duplicate this... anyone else see this behavior? I'm not sure > if Spectrum synthesizes Verilog better that Quartus, but it definitely > does it faster. > > Feedback is welcome... even if it's the "you're an idiot and here's > why" variety...Article: 54601
Has anyone noticed that this part is available with LEGS? It appears that someone at Xilinx was listening to the request for non-BGA parts. A huge THANKS! to whoever it was. Theron Hicks leon qin wrote: > the smallest device is XC3S50 without BlockRam. > the largest device is XC3S5000 with 1,872K bits BlockRam. > > When will can get them?Article: 54602
Svjatoslav Lisin wrote: >>A graphics card speeds up the display if the program calls its built in >>primitives. Rendering programs do not call those primitives but rather >>are CPU intensive calculations of each pixel. > I didn't mean video card with 3D-Studio like program as a ready solution. > I'm interested in ready system-on-chip which can accelerate the raytracing > process. Software part (drivers, program like 3DS and so on) I can write by > oneself. That is the point. The CPU is the chip that does all the work. A faster CPU (with compatible motherboard and chipset and all) is the only way to speed up things. -- Memory Hole: Original US analysis had 5000 Kurds gassed by Iran, not 60,000 and not 100,000 nor by Iraq. The Iron Webmaster, 2604Article: 54603
Leon Heller wrote: > "Matt Giwer" <jull43@tampabay.rr.com> wrote in message > news:7wvma.147196$j8.3207581@twister.tampabay.rr.com... > >>Svjatoslav Lisin wrote: >> >>>Does somebody know any ready hardware systems for raytracing >> acceleration ? >>>How much can it cost? >> >>Zip. Nothing. No graphics card can speed up raytracing, period. >> >>A graphics card speeds up the display if the program calls its built in >>primitives. Rendering programs do not call those primitives but rather >>are CPU intensive calculations of each pixel. > > Parallel processing is the best way to do ray-tracing. Transputers used to > be very good at it. I've connected my older computers into a LAN. I've been parcelling out frames for animations with very worth-the-effort improvements. I've been considering an actual cluster but haven't worked out how to make it work with povray yet. I can automatically parcel out rows by cpu speed but I haven't dug into cleanly reassembling them to a single image. I can do that without a cluster. -- Those who think and question are the minority, those who do not the majority. Directing propaganda at those who think and question can at best gain 100% of the minority. It is best to target the majority. -- The Iron Webmaster, 2607Article: 54604
I have used more than half the luts as SRL's, but then I am told I am way out
there (used as a combination of delays and reloadable LUTs). All of our
filters are constructed using SRLs, so the area covered by the filter is
roughly 50% SRLs for ones with short tap queues, more for longer tap queues.
Where it may affect you is if you have any macros that are placed in the
source and the placement is such that the SRL physical locations do not match
the RLOCs in your code. It also makes longer delay queues less compact, and
the interleaved non-delay slices will have more congested routing because of
the interleaved proximity of two unrelated functions. So, yes I'm
disappointed by the loss of SRLs, but it isn't going to cause me to not use
the parts. It does require revisiting much of our IP to make it work in the
S3 silicon though.
As for the reasons, I believe it is strictly a cost cutting measure. I
understand the RAM/SRL capability is relatively expensive in terms of both die
area and testing. That being so, there is an incentive to reduce the number
of these cells in a low cost device if customers are not using them. My
argument is that if customers are not using them, then marketing and the tools
have fallen short of properly promoting the use of these very useful
elements. IMHO, the SRL16 is the strongest advantage Xilinx has over the
Stratix parts. It would be a shame to throw away that advantage before you
even realize how valuable it can be. One just has to hope that this is not
something that spreads to the next generation Virtex parts too.
Eric Smith wrote:
> I wrote:
> > In the Spartan 3, Only two of the slices in a CLB can have their LUTs
> > used for distributed RAM or SRL. That's a new "feature", isn't it? Was
> > there a technical reason why this was done, or is it just product
> > differentiation?
>
> After I posted that, I realized that it might sound like a complaint,
> which it isn't. The Spartan 3 parts look great, and I've never yet
> needed to use more than half the logic elements of any FPGA as
> distributed RAM or SRLs.
>
> What I was really getting at was whether there was some technical reason
> why the CLB design for the 90 nm process worked out better if the
> right-half slices didn't work as DRAM or SRL, for instance, if there
> wasn't enough room to route some signals that would have been necessary
> for that. If so, perhaps we should expect this same behavior in future
> 90 nm families (Virtex 3? Virtex Pro 2?).
--
--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: 54605>From an insider: Cost reduction was the overriding goal of Spartan-3. Differences between Spartan-3 and Virtex-II can be attributed to the goal of reducing die cost, in order to serve the needs of additional, more cost-sensitive markets. There were no "technical" reasons to eliminate any specific functionality. Peter Alfke ============================== Eric Smith wrote: > > I wrote: > > In the Spartan 3, Only two of the slices in a CLB can have their LUTs > > used for distributed RAM or SRL. That's a new "feature", isn't it? Was > > there a technical reason why this was done, or is it just product > > differentiation? > > After I posted that, I realized that it might sound like a complaint, > which it isn't. The Spartan 3 parts look great, and I've never yet > needed to use more than half the logic elements of any FPGA as > distributed RAM or SRLs. > > What I was really getting at was whether there was some technical reason > why the CLB design for the 90 nm process worked out better if the > right-half slices didn't work as DRAM or SRL, for instance, if there > wasn't enough room to route some signals that would have been necessary > for that. If so, perhaps we should expect this same behavior in future > 90 nm families (Virtex 3? Virtex Pro 2?).Article: 54606
rickman wrote: > > Rajeev wrote: > > > > I'm planning to use the MAX8869 1Amp LDO from 3.3V, which I like > > because it uses ceramic caps and it has a power-good output. It's > > not available from D/K but I was able to obtain less than full reel > > direct from Maxim about 18 months ago (for an earlier project that never > > got built). > > > > Can somebody shed light on why power-up waveforms matter ? I mean, one > > might (naively ?) imagine that things would be OK so long as all the > > voltages settle down before configuration starts... > > Well that is the 64 thousand dollar question... Seems that as the > transistors cross threshold and actually start to operate there are > numerous paths that are turned on which draw significant current until > the voltage has risen enough to turn the transistors off. I have never > gotten Xilinx (and have never talked to Altera) to give me the details > about why this happens since it has to do with internal structures that > they don't want to share info about. > > But be aware of it and don't try any shortcuts. You will not like the > results if you do. The mechanism is quite simple: you have a sea of complementary fets, and as Vcc ramps, the Gate capacitance is going to ramp Vg at appx 50% of Vcc. At the point where the FETS just start to conduct, and so are able to drive their LOAD gates, you are going to get small, but finite currents thru a very large number of devices, hence the AMPS order of init current @ 0.7V Vcc Sometimes 0.7V is inside the foldback of a linear regulator, and not many data sheets plot Io/Vo. What needs to be watched, is that there is a slew-threshold, and if you do NOT give it 'a hard enough kick', it will NOT cross the linear threshold, and stays there for ever - so it is not a simple charge model, of a single FET. If it were, half the current for twice as long would be fine. - jgArticle: 54607
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:3E9B0799.4E74A073@yahoo.com... > more interested in how well you write code and how you approach > debugging a program than how fast you can *code* it. Like soneone > posted in one of the other groups... "Since I touch type, I can *write* > code quite fast. Debugging it is another matter" or something > equivalent. Right. The most notorious exam questions that I give are "debug this program" kind of questions: "Here is a routine that is supposed to do so-and-so. What does it really do, and what needs to be changed to fix it?" They are a much better test of programming ability than simply asking people to code things. Coding, out of the blue, is too dependent on whether the student happens to have encountered a similar problem recently, and whether he hits on the right idea at an early stage. Debugging is more focused. -- Michael A. Covington - Associate Director Artificial Intelligence Center, The University of Georgia http://www.ai.uga.edu/~mcArticle: 54608
"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message news:qhllycn8j1.fsf@ruckus.brouhaha.com... > > I've found that it *is* necessary when interviewing programmers to ask > them to write at least a little code, because some people with great > resumes can't actually code their way out of a paper bag. Having been > on the other side of the interview process, I know that spontaneously > writing code on a whiteboard is much more difficult than coding in a > normal situation. So when I do this, I'm not timing them, and I'm not > looking for perfect syntax. I mostly just want to see that they appear > to know how to write code. Right. I've run into that, too. In oral exams, I often give a rather simple programming task, to see if the student can write a few lines of code on the whiteboard. Sometimes they seem to have no idea! When this happens with someone who has just finished 2 years of programming, I come away unimpressed. -- Michael A. Covington - Associate Director Artificial Intelligence Center, The University of Georgia http://www.ai.uga.edu/~mcArticle: 54609
Theron Hicks <hicksthe@egr.msu.edu> wrote: : Has anyone noticed that this part is available with LEGS? It appears : that someone at Xilinx was listening to the request for non-BGA parts. : A huge THANKS! to whoever it was. From here a THANKS too! -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 54610
Ray Andraka wrote: > > IMHO, the SRL16 is the strongest advantage Xilinx has over the > Stratix parts. It would be a shame to throw away that advantage before you > even realize how valuable it can be. One just has to hope that this is not > something that spreads to the next generation Virtex parts too. Never, never. Don't worry! Virtex has different priorities than Spartan. Peter AlfkeArticle: 54611
"leon qin" <leon.qin@2911.net> schrieb im Newsbeitrag news:b7edee$1i2v$1@ID-185326.news.dfncis.de... > the smallest device is XC3S50 without BlockRam. > the largest device is XC3S5000 with 1,872K bits BlockRam. > > When will can get them? > > Spartan-3 in 90nm! Another strigency for aliens on earth ;-). Hope it's really available in germany. The QFP packages are nice as well as the (yet) missing power on requirements. MIKEArticle: 54612
Hi Jim, I will attempt to address/clarify a few of the issues you raised while I await replies on some of the other issues. Which device were you compiling to for the 80 Mhz result? The Nios Dev Board comes with a 1S10-7. This is the slowest speed grade for Stratix, which is available in -5, -6 and -7, which are faster. You should try compiling to the -5 device to get a number you can compare with the "press release" number. How big were the slack violations with your PLL vs. Clock Pin design? Did you have the placement or routing locked down on your core logic? The reason I ask is that between any two compiles where you alter the netlist, you will usually see some variation in core Fmax. I assume the slack violation was on a core register -> core register, and that you are only using one clock, right? Also, what did you set your PLL clock output speed to? You should not be seeing 10 hour compiles on a 1S10, especially with a simple design. What settings were you using for that compile? Can you send me your design? Your comments on specific documenation and double-click crash will be filed as bugs; they should be fixed in a future release of the software. We're always happy to hear from our users so that we can continue to improve our software. Regards, Paul "Jim M." <jim006@att.net> wrote in message news:6f3fc0f8.0304141222.15bf1ca8@posting.google.com... > I recently purchased a NIOS Stratix 1S10 Development Kit from Altera > and have mixed feelings about Quartus, SOPC Builder, and the NIOS > Core. (For those poor souls interested, I've included some comments > at the end of this post... feel free to provide feedback.) > > However, here's my question: > > What's the maximum clock frequency anyone has achieved using the NIOS > 3.0 CPU in 32bit mode with the standard peripherals (SRAM, SDRAM, > Ethernet, PIO, UART, etc. as in the Reference Design provided by > Altera)? > > I've tried isolating the various components into LogicLock regions. > I've tried different fitter/netlist optimizations. The maximum Fmax I > have achieved to date is 80 MHz. This is after letting Quartus "fit" > for 10 hours... it actually didn't stop, I had to abort the fitting > and refit to finially get an interim result (see other misc comments > below). > > Altera advertises 125 MHz for the Stratix Device and NIOS 3.0... > However a reference design that builds at that clock rate is not > provided. It appears that Altera gives you just enough to get your > feet wet... anything above and beyond that is Intellectual Property > that you need to buy. > > Other Observations/Comments: > > 1. The Quartus II SP1 software is extremely flakey. I've generated > numerous faults when deleting/modifying child LogicLock Regions. It > also takes forever to fit my Stratix design which is only 6000 LEs. > If I select the "limit fitting attempts to 1" option, Quartus > sometimes fits many times (like forever...) why?!?!? Also, after a > design is finished building, the software sits around for up to 5 > minutes before it generates a "finished" dialog box. I'm not sure > what's going on between the Quartus Application thread and the Quartus > Compiler thread, but it's fustrating enough just waiting for the > design to build, let alone waiting for Quartus to figure out the build > is done. I could go on and on, and that's only the result of 4 weeks > of effort with a small design. I feel sorry for those folks working > on a 100,000+ gate design. I guess modularity is the key there. > > 2. I can't simulate designs with virtual pins. I get warning during > the analysis of the simulation and then receive results with all input > pins a zero and output pins undefined. In addition, I can generate > hold time warnings during simulation for a design that didn't compile > with any hold time warnings. I'm not talking about hold time warnings > on my input signals, I'm talking about hold time warnings on internal > registers in my verilog code. Registers that I've taken care to hold > for 1 or more clock cycles before using in other parts of the design. > Again, the compilation of the design did not generate hold time > warnings... only the simulation of the design. > > 3. PLLs generate different timing analysis results. THIS IS VERY > ANNOYING! When I build up a "black-bock" design with virtual pins I > obtain a Fmax calculation from the timing analysis routine. I then > LogicLock the design and export it. When I import the design into a > new project and clock it using a PLL it generates negative slack time > warnings! If I remove the PLL and replace it with a clock pin, I get > the Fmax result that I obtained during the "black box" design. I beat > myself up for a week trying to debug a design that wasn't broken > because of this goofy behavior in Quartus. I'm still not sure if the > slack time warning it legit and wether I should be concerned about it. > > 4. SOPC Builder will lock itself up if you double-click components > before selecting them. Give it a try... double click a component line > in your NIOS design before selecting the line item. After a couple > times the SOPC builder application creeps to a halt. > > 5. Documentation on the various megafunctions is lacking. A good > example is the altsyncram megafunction. It doesn't state any timing > requirements on the input registers, enable, and clock signals. Do I > hold the data 1 cycle before flipping the write enable? How about > holding the write enable before de-activating it? Why is the > addressing based upon the data bit-width? Trying to tie a 32-bit > altsyncram block to a NIOS CPU is difficult because you need to > specify the address space of the peripheral and the address space of > the altsyncram block is based upon the bit width (not the number of > bytes). > > 6. I have yet to get a Leonaro-Spectrum synthesized Verilog file to > build in Quartus. I can used Spectrum generated .edf files but not > verilog. I get LCELL parameter errors. Unfortunately, Altera can't > seem to duplicate this... anyone else see this behavior? I'm not sure > if Spectrum synthesizes Verilog better that Quartus, but it definitely > does it faster. > > Feedback is welcome... even if it's the "you're an idiot and here's > why" variety...Article: 54613
Jim,
First, a quick correction to my prior post: Apparently the latest dev boards
ship with a -6 device, not a -7 as previously stated.
The 125+ Mhz Nios result can be obtained by opening the "minimal_32" design
in the "sopc_builder\examples\verilog\nios_stratix_1s10\minimal_32"
directory and following these steps:
1. Open SOPC Builder
2. Type in desired clock speed of 125MHz
3. Generated system in SOPC Builder
4. Changed device assignment from -6 to -5
5. Push compile button in Quartus
In a compile here on Quartus II 2.2 SP2, an engineer got 130 Mhz.
This design is a bare-bones Nios design -- just a Nios 32-bit CPU, on-chip
RAM & ROM, and a UART. When you add more peripherals and featuers to the
CPU, your speed may slow down.
For comparison, a more complex Nios design including SDRAM interface and a
suite of peipherals will hit about 100 Mhz (in a Stratix -6). Adding in
SDRAM and a cache will knock you down further, however your overall
performance will likely improve thanks to the cache -- Mhz isn't everything!
Regards,
Paul
"Paul Leventis" <paul.leventis@utoronto.ca> wrote in message
news:n9Hma.42433$jVh.32710@news01.bloor.is.net.cable.rogers.com...
> Hi Jim,
>
> I will attempt to address/clarify a few of the issues you raised while I
> await replies on some of the other issues.
>
> Which device were you compiling to for the 80 Mhz result? The Nios Dev
> Board comes with a 1S10-7. This is the slowest speed grade for Stratix,
> which is available in -5, -6 and -7, which are faster. You should try
> compiling to the -5 device to get a number you can compare with the "press
> release" number.
>
> How big were the slack violations with your PLL vs. Clock Pin design? Did
> you have the placement or routing locked down on your core logic? The
> reason I ask is that between any two compiles where you alter the netlist,
> you will usually see some variation in core Fmax. I assume the slack
> violation was on a core register -> core register, and that you are only
> using one clock, right? Also, what did you set your PLL clock output
speed
> to?
>
> You should not be seeing 10 hour compiles on a 1S10, especially with a
> simple design. What settings were you using for that compile? Can you
send
> me your design?
>
> Your comments on specific documenation and double-click crash will be
filed
> as bugs; they should be fixed in a future release of the software.
>
> We're always happy to hear from our users so that we can continue to
improve
> our software.
>
> Regards,
>
> Paul
>
>
>
> "Jim M." <jim006@att.net> wrote in message
> news:6f3fc0f8.0304141222.15bf1ca8@posting.google.com...
> > I recently purchased a NIOS Stratix 1S10 Development Kit from Altera
> > and have mixed feelings about Quartus, SOPC Builder, and the NIOS
> > Core. (For those poor souls interested, I've included some comments
> > at the end of this post... feel free to provide feedback.)
> >
> > However, here's my question:
> >
> > What's the maximum clock frequency anyone has achieved using the NIOS
> > 3.0 CPU in 32bit mode with the standard peripherals (SRAM, SDRAM,
> > Ethernet, PIO, UART, etc. as in the Reference Design provided by
> > Altera)?
> >
> > I've tried isolating the various components into LogicLock regions.
> > I've tried different fitter/netlist optimizations. The maximum Fmax I
> > have achieved to date is 80 MHz. This is after letting Quartus "fit"
> > for 10 hours... it actually didn't stop, I had to abort the fitting
> > and refit to finially get an interim result (see other misc comments
> > below).
> >
> > Altera advertises 125 MHz for the Stratix Device and NIOS 3.0...
> > However a reference design that builds at that clock rate is not
> > provided. It appears that Altera gives you just enough to get your
> > feet wet... anything above and beyond that is Intellectual Property
> > that you need to buy.
> >
> > Other Observations/Comments:
> >
> > 1. The Quartus II SP1 software is extremely flakey. I've generated
> > numerous faults when deleting/modifying child LogicLock Regions. It
> > also takes forever to fit my Stratix design which is only 6000 LEs.
> > If I select the "limit fitting attempts to 1" option, Quartus
> > sometimes fits many times (like forever...) why?!?!? Also, after a
> > design is finished building, the software sits around for up to 5
> > minutes before it generates a "finished" dialog box. I'm not sure
> > what's going on between the Quartus Application thread and the Quartus
> > Compiler thread, but it's fustrating enough just waiting for the
> > design to build, let alone waiting for Quartus to figure out the build
> > is done. I could go on and on, and that's only the result of 4 weeks
> > of effort with a small design. I feel sorry for those folks working
> > on a 100,000+ gate design. I guess modularity is the key there.
> >
> > 2. I can't simulate designs with virtual pins. I get warning during
> > the analysis of the simulation and then receive results with all input
> > pins a zero and output pins undefined. In addition, I can generate
> > hold time warnings during simulation for a design that didn't compile
> > with any hold time warnings. I'm not talking about hold time warnings
> > on my input signals, I'm talking about hold time warnings on internal
> > registers in my verilog code. Registers that I've taken care to hold
> > for 1 or more clock cycles before using in other parts of the design.
> > Again, the compilation of the design did not generate hold time
> > warnings... only the simulation of the design.
> >
> > 3. PLLs generate different timing analysis results. THIS IS VERY
> > ANNOYING! When I build up a "black-bock" design with virtual pins I
> > obtain a Fmax calculation from the timing analysis routine. I then
> > LogicLock the design and export it. When I import the design into a
> > new project and clock it using a PLL it generates negative slack time
> > warnings! If I remove the PLL and replace it with a clock pin, I get
> > the Fmax result that I obtained during the "black box" design. I beat
> > myself up for a week trying to debug a design that wasn't broken
> > because of this goofy behavior in Quartus. I'm still not sure if the
> > slack time warning it legit and wether I should be concerned about it.
> >
> > 4. SOPC Builder will lock itself up if you double-click components
> > before selecting them. Give it a try... double click a component line
> > in your NIOS design before selecting the line item. After a couple
> > times the SOPC builder application creeps to a halt.
> >
> > 5. Documentation on the various megafunctions is lacking. A good
> > example is the altsyncram megafunction. It doesn't state any timing
> > requirements on the input registers, enable, and clock signals. Do I
> > hold the data 1 cycle before flipping the write enable? How about
> > holding the write enable before de-activating it? Why is the
> > addressing based upon the data bit-width? Trying to tie a 32-bit
> > altsyncram block to a NIOS CPU is difficult because you need to
> > specify the address space of the peripheral and the address space of
> > the altsyncram block is based upon the bit width (not the number of
> > bytes).
> >
> > 6. I have yet to get a Leonaro-Spectrum synthesized Verilog file to
> > build in Quartus. I can used Spectrum generated .edf files but not
> > verilog. I get LCELL parameter errors. Unfortunately, Altera can't
> > seem to duplicate this... anyone else see this behavior? I'm not sure
> > if Spectrum synthesizes Verilog better that Quartus, but it definitely
> > does it faster.
> >
> > Feedback is welcome... even if it's the "you're an idiot and here's
> > why" variety...
>
>
Article: 54614On Mon, 14 Apr 2003 16:59:06 -0400, Theron Hicks <hicksthe@egr.msu.edu> wrote: >Has anyone noticed that this part is available with LEGS? It appears >that someone at Xilinx was listening to the request for non-BGA parts. > Actually I was a little disappointed in this area. Only the XC3S50 / 200 / 400 is available in the 208 pin pqfp .. the 2e took this package up the 300 part so some improvement yes .. but the Cyclone EP1C12 is available in a 240 pin pqfp ... 30+ more I/O pins, and the cyclone has 12K registers , a bunch more than the new 400 part. my 2'c KBArticle: 54615
Mike, No power on issues at all. Already tested. Austin "M.Randelzhofer" wrote: > "leon qin" <leon.qin@2911.net> schrieb im Newsbeitrag > news:b7edee$1i2v$1@ID-185326.news.dfncis.de... > > the smallest device is XC3S50 without BlockRam. > > the largest device is XC3S5000 with 1,872K bits BlockRam. > > > > When will can get them? > > > > > > Spartan-3 in 90nm! Another strigency for aliens on earth ;-). > Hope it's really available in germany. > The QFP packages are nice as well as the (yet) missing power on > requirements. > > MIKEArticle: 54616
Rick, Really neat and useful things. Really. We will outline all of that it a data sheet or user's guide at some point relatively soon. Austin rickman wrote: > Uwe Bonnes wrote: > > > > rickman <spamgoeshere4@yahoo.com> wrote: > > : I guess I have not spent enough time keeping up with the newer Xilinx > > : parts. Seems the Spartan 3 chips have inherited from the Virtex II > > : chips THREE power supply voltages; Vccint, Vcco and *Vccaux*. I belive > > : in the VII parts there is a circuit for decrypting a bit stream and > > : holding the key in internal ram. But I see a fourth voltage, Vbatt, for > > : that. > > > > : So what exactly is the Vccaux for? Is this a Vcco for the various IOs > > : that are not general user IOs? If the current levels are similar to the > > : VII, I can accomodate that very easily with a SOT-23 regulator. But I > > : am surprised to see this. > > > > Looka at ds099-2.pdf page 9: > > 3. The VCCAUX is an auxiliary source of power, primarily to optimize the > > performance of various FPGA functions such as I/O switching. > > Ok, so what does it do? > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 54617
In message <3E9AE188.9F1A2DDD@egr.msu.edu>, Theron Hicks wrote: > Hello, > I have an embedded system composed of several FPGAs. The control > codes for the system are sent via a com port on a PC. The UART is taken > from UAPP 223 (Thanks to Ken Chapman). Unfortunately this UART has no > parity bit. This should not be a problem as we are echoing the command > string back to the PC to verify correct data transmission. However, we > still seem to have some sort of system corruption problem that I believe > is caused by the serial data stream. The control stream consists of 3 > 8-bit characters. To me the obvious solution is to add a 4th 8 bit word > that could contain the ECC data. I have several questions. > > 1. Is 8 bits enough to Error correct a 24 bit data stream? > 2. Assuming it is, how many errors can it correct? > 3. The data is being sent to a pico-blaze. Should the ECC be done in > the pico blaze or in hardware before the pico-blaze? My suspicion is to > do it in the pico-blaze and thus take care of any comunication issues > including the input to the pico-blaze. > > Note: I did not design this FPGA but I need to get to near 100% > reliability in it. The individuals who did design it work for me and > usually do very good work. We would rather stick with the UART and > pico-blaze we have and put the ECC into another data word. This would > allow a minimum of design changes. > It shouldn't be that difficult to modify someone elses design to include parity, all you need is to jam it in to the 8th bit. If thats not doable then.. You said 3 8-characters, that could be your key. How many of those 2^24 bit patterns are you ever able to send to a PC. For instance if you only send plain ascii text, you are throwing away bandwidth that can be easily used to error correct them quite easily at very little cost save some tables. Assuming you really are sending plain ascii, you could recode all of your possible messages into a packed dictionary of symbols and only note the index. Then instead transmit a symbol that includes good ECC properties, usually by a polynomial divison of data followed by the remainder using some famous polynomial etc. Suppose on avg each byte only has 32 possible data values, then using the index idea, look on the web for the precomputed table of codes that will transmit 5bits as 8bits. On the receive side, look up the reverse table to get back the 5 bits and look up again to get the original ascii. You can find various tables for n,k codes, but as n,k get bigger, tables become less practical. Even in the simplest case, if you only transmit 6-7bit ascii, a table lookup to recode as 7-8bits with parity bit at end can be as good as a parity circuit, but done in SW. What you do really depends on your transmitted data and the medium. Since you don't seem to be modulating onto a carrier, your error rates on plain wire should be very low. Maybe you just have some poor cabling, driver, noise etc. If you are carrying raw binary data that is not redundant, then that will require many extra bits to ECC or CRC. I would suggest an 8bit CRC for proof positive that it is correctly received, although it will give false negative 1 in 256 times. Thats why people use longer & longer CRC to reduce probability of false failures. CRC logic done serial is not that big a deal, but if you can't do parity, then CRC will be harder. A parity is really just a poor mans CRC. Personally I've used 12->23,1 code that can easily handle 3 corrections over a 23 bits carrying only 12bit payload, but thats for heavy duty noisy environments. The field of ECC can get pretty elaborate pretty quickly and can take up a few years of ones life. There are many excellent texts such as Blahut but be prepared for Galois fields, chinese remainder theory, lots of modulo 2 arithmetic, syndromes etc, luckily I'm in remission. John JaksonArticle: 54618
i wan to know can we write a code such that i can write a entire audiofile(filename.wav) to RAM.can somebody suggest me ? i am puzzled.Article: 54619
Not quite. A UART typically samples the start bit at 16x clock, then from the
estimated center of the start bit (determined by a count of 8 clocks from when
the start goes active), the rest of the bits are simply sampled at the center of
the bit times, ie multiples of 16 clocks from the center of the start bit. It
can be accomplished with a 4 bit counter for the bit timing (preload with 8), a
bit counter, and a shift register with just enough bits to hold the intended
data bits, and parity if desired. The shift register gets enabled by the bit
counter terminal count. A simple state machine to hold the bit counter reset
(to 8) until the start bit is detected and again after the stop bit rounds the
design out. Unless you have a 16x recieve clock available, you'll also need an
accumulator to generate the 16x UART clock from your system clock. All you need
then, is an 8 bit shift register, a mod 16 counter, a 4bit counter and a few
extra flops for the state machine. Plus an accumulator if you need to generate
the 16 x clock.
Rene Tschaggelar wrote:
> Valeria Dal Monte wrote:
> > "valentin tihomirov" <valentin@abelectron.com> ha scritto nel messaggio
> > news:3e9a865c_2@news.estpak.ee...
> >
> >>I have an idea to implement all digital logic of my circuit into a CPLD.
> >
> > The
> >>only doubt is external UART. I know, additional UART is a big pain,
> >>currently I use tl16c750. I think that a price of external uart is the
> > same
> >>or greater than an average CPLD chip. All IP cores suggested by google are
> >>complex, ie with FIFOs and flow control. I would be satisfied with the
> >>8051-compatible UART. That means an interrupt, 8bit SIN, SOUT registers,
> >
> >>RI flags and a hardwired frecuency. Any suggestions.
> >
> > I think a such non-programmable UART is very simple to implement
> > and very inexpensive in terms of macrocells, likely less than 32.
>
> This may be impossible. A UART uses oversampling and taking the
> majority. For 8 databits plus 1 startbit and 1 stopbit at 4 times
> oversampling the shiftregister is 40 bits long. Add 2 bytes for
> transmission and 2 bytes for reception and you're at 64 bits.
> Then add a few macrocells for the logic.
>
> Rene
> --
> Ing.Buero R.Tschaggelar - http://www.ibrtses.com
> & commercial newsgroups - http://www.talkto.net
--
--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: 54620
Then don't forget IOB failure due to abuse and/or ESD. Generally speaking, the guts of the FPGA are pretty
bulletproof. If you are operating at high altitude or in space, you'll get an occasional soft failure that clears
itself next time that flip-flop is toggled (note that if it is a configuration register the flipped bit is held
until the device is reconfigured). There are many papers on the subject in the proceedings from MAPLD over the
last several years. I've got one such paper dealing with detection of configuration upsets in SRAM FPGAs on my
website.
naveen wrote:
> hi,
> i meant all the list of the faults. doent matter if its before
> testing or after testing.
> i lnow some of them but iam writing a paper on "diagnosis and fault
> tolerence of FPGA's", i dont want to miss ne of them.
> thanks,
> naveen
> nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote in message news:<b770oe$171v$1@agate.berkeley.edu>...
> > In article <b7f5eb6a.0304110842.4abb46a8@posting.google.com>,
> > naveen <cvmnk@yahoo.com> wrote:
> > >hi,
> > > can ne one lemme know all the different faults on FPGA, both
> > >interconect and logical faults, on Xilinx based FPGA's.
> > > thankin you in advance,
> >
> > What do you mean? Soft errors vs hard errors? From the fab (before
> > testing) or after testing?
--
--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: 54621
John, You are right ot be concerned about skew between the 1x and 2x clocks. If
you control placement and are clever about getting direct flip-flop to flip-flop
connections you can manage to do what you are describing using a falling edge
sensitive FF in the 2x domain to capture the 1x clock, then take the output of
the falling edge FF and feed it to a rising edge FF in the 2x domain to time
align the resulting CE with the 2x clock rising edges. The CE is probably
inverted WRT to what you wanted at that point, in which case an additional
rising edge FF will put it right without adding any logic delays in the critical
timing around the neg edge FF. You'll need to use primitives with RLOCs on them
to keep the timing tight, and with v4.2 and later tools you need to make sure
you put the time constraints in for each connection in order to keep the router
honest (3.3 did a good job of finding the direct connect without having an
explicit time constraint).
John_H wrote:
> Thanks for the message last week, Eric - my newsreader at work isn't
> 100% and I had to read/respond at home.
>
> Your comment about only needing two flops is accurate as long as the
> designer can trust that the x1clk and x2clk domains will always work
> together as we'd expect where the rising edges are coincident. The
> reality is that those two edges may be separated by some 100s of ps
> since the clock net loading can be different between the two domains and
> input clock jitter to the DLL may translate to the two domains at
> different cycles. THe former problem is known, I'm only speculating on
> the latter. Bottom line: I can't depend on the two domains to play nice
> at the common rising edge, hense the nead to offset things by 1/4 the
> x1clk (or 1/2 th x2clk).
>
> Any further thoughts are appreciated.
>
> - John_H
>
> Eric Pearson wrote:
> > "John_H" <johnhandwork@mail.com> wrote in message
> > news:T9Hka.9$716.2363@news-west.eli.net...
> >
> >>Has anyone figured out a nice, clean method to track which phase of a
> >
> > Xilinx
> >
> >>DLL's 1x clock corresponds to a 2x clock cycle? One 2x rising edge
> >>corresponds to the 1x rising edge, the other 2x rising edge corresponds to
> >>the 1x falling edge.
> >>
> >>When I start getting up in frequencies, the ability to use the 1x clock
> >
> > and
> >
> >>inverted 1x clock to generate two signals that I can XOR for a phase is
> >>compromised. It's not inherently safe to use the 1x edges and 2x rising
> >>edges as "effectively" the same edge due to clock skews and input jitter
> >>issues. Using the falling edge of the 2x clock to sample the 1x generated
> >>signals works, but at the 1/4 period timing budget is too tight at the
> >>frequencies I'm working.
> >>
> >>For those who are Verilog friendly, the code here shows how I would
> >>"normally" extract the phase without running a clock through a LUT. The
> >>"negedge x2clk" is where the timing gets tough since the Tcko+Tnet+Tick is
> >
> > a
> >
> >>little over the 1/4 period of my x1clk.
> >>
> >>always @(posedge x1clk) posTog <= ~posTog;
> >>always @(negedge x1clk) negTog <= posTog;
> >>always @(negedge x2clk) rawPhase <= posTog ^ negTog;
> >>always @(posedge x2clk) phase <= rawPhase;
> >>
> >>Is there a cleaner way to figure out the which half of the x1clk I'm in?
> >>
> >>Thanks,
> >>- John_H
> >>
> >>
> >
> >
> > It really only takes 2 flops working on rising edge.
> >
> > always @(posedge x1clk) Toggle <= ~Toggle;
> > always @(posedge x2clk) Delayed <= Toggle;
> > assign Phase = DelTog ^ Tog;
> >
> > Eric
> >
> >
--
--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: 54622Paul Burke wrote: > No need for two consecutive reads. It's very easy really, you don't have > to be simplex either. Give each side its own data areas for write and > read- write to one is read to the other. (this is just your convention, > you don't have to physically hide the data on the write side). Have one > or more data ready flags in each area, these can be read and written > from either side. Wait for the flag to be clear, then write the data, > then set the flag. It doesn't matter whether you are just setting it or > it's been there for some time, the data is valid. > > On the read side, wait for the flag to be set. When it is set, read the > data then clear the flag. The other side can't write until it's clear, > so it doesn't matter whether it is just setting or has been hanging > around. > > The hardware must of course sort out the priority in the case of > simultaneous accesses. > > I first did this with 6809s in 1983, so it's well tried and tested! > > Paul Burke Doesn't your solution assume synchrony? If it is asynchronous then "hardware must of course sort out the priority in the case of simultaneous accesses" becomes much more complex. I have always assumed I can add more HW to make it robust but I liked the idea of merely using the RAM itself as a synchronizer. Anyway, Thanks Paul and everyone else who responded. ~TomArticle: 54623
Uwe Bonnes wrote: > Theron Hicks <hicksthe@egr.msu.edu> wrote: > : Has anyone noticed that this part is available with LEGS? It appears > : that someone at Xilinx was listening to the request for non-BGA parts. > : A huge THANKS! to whoever it was. > > From here a THANKS too! And from me too.Article: 54624
Eduardo,
Theoretically it is possible to provide GND and VCC to bus macros
through LUT instantiations. I've done this in a partially reconfigurable
design I'm currently working on. Unfortunatelly I haven't tested the
bitstream on real hardware yet, hence I only say that it can be done
theoretically.
I'm using Leonardo Spectrum for Synthesis and Xilinx ISE 5.2i
(Modular Design Flow). I've verified through the FPGA Editor
that the LUTs are present on the final design (mapped/placed/routed
.ncd file) and that the eqn property is 0 or 1 (which means that
the LUTs really provide the constants you want). Also, after back annotating
the mapped/placed/routed ncd and performing timing simulation (ModelSim)
everything looks fine
Here's how to do it :
1. Instantiate the LUT's in the HDL code. E.g. Verilog :
LUT1 mylutGND(.I0(dummy_input1),.O(my0)); //exemplar attribute mylutGND
noopt TRUE
LUT1 mylutVCC(.I0(dummy_input2),.O(my1)); //exemplar attribute mylutVCC
noopt TRUE
// Bus Macro Instantiation
bm_4b
BM_kb2disp(dout,{my0,my0,my0,my0},displaycode[3:0],{my1,my1,my1,my1},in);
The exemplar directives instruct Leonardo not to optimize the LUTs. If you
ommit them
Leonardo will replace the LUT's with GND and VCC (which is definetly what
you DONT want)
2. After reading the Sources (.v) into Leonardo you should enter the
following commands
at the prompt :
set_attribute -instance mylutGND -name INIT -type string -value "0"
set_attribute -instance mylutVCC -name INIT -type string -value "3"
set_attribute -instance mylutGND -name eqn -type string -value "0"
set_attribute -instance mylutVCC -name eqn -type string -value "1"
The first two lines define the init property of the LUTs, while the next
two define the equation.
3. I really don't know if it is necessary (since I'm not using XST for
synthesis) but I included in my top level .ucf, the following constraints
as described in xapp290 :
inst mylutGND LOCK_PINS;
inst "mylutGND" init=0;
INST "mylutVCC" LOC = "CLB_R1C30.S0"; #Don't forget to LOC the LUT- All top
level logic should be constrained
inst mylutVCC LOCK_PINS;
inst "mylutVCC" init=1;
INST "mylutGND" LOC = "CLB_R1C1.S0"; #Don't forget to LOC the LUT
Well, that's all.
If you're using XST for synthesis, I believe that just entering the
6 constraints described earlier, in the .ucf file should do the trick.
By the way, the LUT entries in the edif file produced by Leonardo
look like this :
(instance mylutGND (viewRef NETLIST (cellRef LUT1 (libraryRef xcv )))
(property EQN (string "0"))
(property noopt (string "TRUE"))
(property area_report (string "1"))
(property area_units (string "Function Generators"))
(property IS_LUT (string "1"))
(property NOMAP_GATE (string "1"))
(property INIT (string "0")))
(instance mylutVCC (viewRef NETLIST (cellRef LUT1 (libraryRef xcv )))
(property EQN (string "1"))
(property noopt (string "TRUE"))
(property area_report (string "1"))
(property area_units (string "Function Generators"))
(property IS_LUT (string "1"))
(property NOMAP_GATE (string "1"))
(property INIT (string "3")))
If I replace the EQN entries with "()" (from the original "1" or "0"), I get
the NGDBUILD error you described on your post at 11/4/2003.
I hope this helps you,
Regards
Kalogerakis Panagiotis
Computer Engineering and Informatics Department
University of Patras
Greece
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