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
mpbetts wrote: > If you're using Linux, OpenMosix is some good load balancing software.. > Then you could do someting like start up a bunch of processes to render > each scanline, and then OpenMosix would move these processes out to the > other computers automatically. Yes but for a single image ... With povray I can manually have it render an X by Y section. Most easily X rows per computer based upon clock speed. I know of no way to parcel out the rows automatically without rewriting the povray source and of course learning how to do that. Even then, each processor would create an output file in the chosen format with all the right headers. So they would have to be processed to reassemble instead of simply concatenating them. Ideally instead of each processor writing to its own file it would send the results to one computer which would then create a single output file. That would be another interesting rewrite. That is why so far I have only addressed the trivial issue of animations where the number of frames is assigned by clock speed. > On Mon, 14 Apr 2003, Matt Giwer wrote: > > >> 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, 2607 >> >> > > -- After Iraq is disarmed the US will leave, right? -- The Iron Webmaster, 2596Article: 54676
Some have it, some don't. The ones I am aware of that do have it look at a 3 chip
window around the sample point. That can be accomplished using a simple 3 tap boxcar
filter and thresholding it (real simple filter since the input is only one bit) before
the data goes into the shift register as well as the start bit detect logic. You'll
need to adjust the sample point to match. If your signal is clean, this is not
necessary, as it is essentially just a glitch filter.
invalid@invalid.com wrote:
> Hello,
>
> In article <3E9B5930.D5C331BA@andraka>, ray@andraka says...
> > 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.
>
> Is this the only technique used? Sorry if this seems naive, but I've
> frequently seen the term "vote logic" or "majority detector" used in
> conjunction with UARTs(even in the TI literature for the UART the OP
> mentioned). I was always under the impression that the bits are sampled
> at 16x and the bit is given the majority value.
>
> I guess this leads to another interesting question: Any easy way to do
> the majority detection logic, or is one forced to eat the logic needed
> for all the comparators?
>
> Regards,
> S.R.
--
--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: 54677
At 44 KHz, you are probably OK, although I would have used a bit serial
implementation. Current FPGAs are easily capable of 100+ MHz operation with a
pipelined design. If you were at 44 MHz, you could do a place and route with
time constraints set 20% or more above your target to make sure the macro works
in isolation at the desired speed. 20% margin is probably enough to allow for
the sloppiness of the current router when the macro is placed in situ provided
the placement is the same or better than the test macro. Without placement, it
is even more of a crap shoot when you are pushing performance (but at 44KHz, you
probably needn't worry).
David wrote:
> Ok my question was a little more basic than this. I'm currently designing
> some audio processing in an fpga. Let's say I want to build a 'volume'
> control core. Basically, it's only a divider (say 32 bits). However, how do
> I know that it will run fast enough for my application (say 44.1khz)?
>
> Thanks
> David
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3E9C0082.4D3AEAE1@andraka.com...
> > more or less. WIth the 4.2 and later version router, even that may not be
> > enough. The new router is lazy in that it only improves routing to meet
> the
> > slack on all paths. The result is less than optimal routing in which
> every path
> > becomes the critical path. If you are pushing the timing at all, a macro
> can
> > route with wonderful results in isolation but then when placed in the
> circuit
> > might fail miserably with the exact same timespecs. Worse yet, the same
> macro
> > instantiated multiple times will make timing on some instances and not on
> > others. This is new behavior starting with the 4.x tools (not so new
> anymore).
> > Please complain to Xilinx, they don't seem to see this as a problem...it
> was
> > changed to improve the time to a routed solution but as a result the
> quality of
> > route has plummeted. Altera, take notes so that you don't do the same
> slack
> > based routing mistake.
> >
> >
> > David wrote:
> >
> > > Hi,
> > > I'd like to know if it is possible to know the speed of a particular
> core in
> > > Xilinx core generator. For example, I want to create a combinational
> > > multiplier. How do I know if it will be fast enough for my design? Even
> if I
> > > choose the 'pipelined' option, how do I know the fastest clock rate
> possible
> > > for a given Fpga? Do I always have to make a project in ISE and test it
> > > myself with post place and route simulation?
> > >
> > > Thanks
> > > David
> >
> > --
> > --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
> >
> >
--
--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: 54678
Yes, I am quite aware that the probability of a bit flip at ground level is very small. In low earth orbit, however the
story changes. I've been rather sensitized to it seeing that 3 of the projects I've finished in the past year are slated
for launch into LEO. In one, based on the testing at LANL, we expect configuration bit upsets as short as every 7 minutes
or so during an active sun cycle while traversing the SAA. This will be tempered considerably by the fact that the design
is sensitive to considerably less than 10% of the configuration bits. Too bad those designs are stuck in 2.5v Virtex
since those are the only QPRO parts. Any word on a later family, perhaps V2 getting space qualified?
Austin Lesea wrote:
> Ray,
>
> The liklihood of flipping a FF is nil in the FPGA (or pretty near 0). In fact the logic of a customer design about
> 30X harder to upset that in an ASIC where everything is "optimal" (lowest loading, and fewest transistors). One big
> benefit of having all those "extra transistors" around.
>
> The memory cells that control the interconnect are the lightly loaded ones, and the smallest features. Those are the
> ones that get affected by soft errors (SEUs - cosmic rays). Buit it takes from 6 to 80 "hits" to change a customer
> design logic result! If you were to reload the configuration once a day, you also would prevent cumulative upsets,
> and reduce the probability of a customer logic upset even further.
>
> See the http://www.xilinx.com/support/techxclusives/1000-techX35.htm tech exclusive. Not only do we actually know
> how sensitive we are, we also know which bits are sensitive. And with Virtex II ICAP (internal configuration acess
> port) you can create a design to continually check itself (skipping columns with BRAM and LUT RAM/SRLs) and even check
> and correct itself.
>
> And, you don't have to ask: evaluation of 130 nm and 90nm is in progress, and we will have those results for those
> that need to know.
>
> You see, we have known about SEUs (SEEs, soft errors) for more than 10 years now, and we have taken all of this into
> account by design.
>
> By the way, what we are doing is so far up from all of the others that it is hard to breath at this altitude. Fact.
> The next lot of 100 goes to WMRC.
>
> Austin
>
> Ray Andraka wrote:
>
> > 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
--
--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: 54679Hi Andrea, > How can I manage a complex design with many files that use components and > packages from different files ? > (Consider that the same package may be used by different files at the > different level of hierarchy) Once Quartus has read the package, it should be able to use its delarations and components at any design depth. If you have a design, no matter how trivial, that proves otherwise, please send it to me aand I'll try to figure out what is going wrong - except, of course, if you want to generate symbols. Best regards, BenArticle: 54680
Hi Jim, I'm just interested on how MicroBlaze compares against NIOS. So what family is not supported in Webpack ISE? I think that there is a least one member from each family in Webpack. Xilinx EDK tool cost $495 and includes 40 peripherals which is far more than Altera is shipping in their NIOS kit. You can buy the EDK and a board from other vendors for a total less than $995. MicroBlaze is also shipped free with each EDK and there is no royalty and license required. MicroBlaze is not any different than NIOS in that respect. MicroBlaze fulfill all your requirements that you had for choosing NIOS. If you're still interested, I can create your system on MicroBlaze and you can do the comparison. Göran "Jim M." wrote: > Goran, > > I mentioned that I had mixed feelings then went on to only convey the > negative ones. Not the best move on my part. > > I don't really want to open up a Xilinx vs. Altera debate. > > One of the big reasons I went with Altera is that they support all of > their devices in the free versions of their software. What I mean by > 'all' is that each family has at least one device supported. Event > the Excalibur family with ARM processor. > > Their dev kits come with a device and are generally less expensive > with more peripherals. > > In addition the NIOS soft core is provided free with any NIOS dev-kit > (with software tools) and it's royalty free for re-use... this is a > big deal. > > Those were some of the factors in my decision to go with Altera. > > I'm very interested in hearing from other NIOS users on their > experiences. > > Goran Bilski <Goran.Bilski@Xilinx.com> wrote in message news:<3E9B1F99.17B9B1C5@Xilinx.com>... > > 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: 54681
russelmann@hotmail.com (Rudolf Usselmann) writes: > "Brendan Lynskey" <brendan@comodogroup.com> wrote in message news:<j9Rma.7414$xd5.264132@stones.force9.net>... > > > > What's the position in writing an well-established type of CPU core (like a > > Z80) and selling it? > > > > Would I have to pay royalties to anyone? > > I believe it depends how old the CPU and any associated > patents are. The patents. Sales of the CPU are irrelevant. > I believe the US patents last for 17 years. 17 from granting (old law) or 20 years from handing in application (new law). I do not know exactly which patents fall under which law. Outside US it seems to be generally 17 from handing in. > Not sure how it works with copyrighted instruction sets > (or if that is even possible). Copyright only applies if you are distributing verbatim copies of an other persons work, i.e. code or documents, or chip layouts (and I assume data sets to compile to layouts). Never instruction sets. Instruction sets can not be patented per se, but specific instructions can, if they implement an new way to solving a problem. The patent actually would have to cover the way. > Some, MIPS and ARM come to mind, are so scared of the > open/free implementations of their CPUs that they fight > very hard to get them removed. MIPS is an example of patented instruction. They solved the problem of loading non-aligned words (2 word reads that are masked and shifted to make one word) in an virtual memory system (either word read may page fault) in an novel way. This required an special set of 2 separate "read 1 word and mask/shift to load partial word" instructions (so each can only fault once). This method is patented. It is impossible to implement the 2 instructions (and so the entire instruction set, and so an compatible chip) without violating this patent. Of course we today are in 2003, so any patent before 1983 (or even 1986?) is dead anyway and MIPS started in the first half of the 1980s. So their patents are running out real soon. ARM I do not know what they use to beat down competition. I would assume also an patent on something, as this is the only effective way againt an independant (from scratch, clean room) implementation. They are also mid 1980s. So also max 5 years to go, if even that. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Blacksmith - hardware runs the world, software controls the hardware code generates the software, have you coded today?Article: 54682
Hello Petter,
Everything is setup for CSH and SH, but not BASH. Please try using
CSH or SH. If you want to use BASH, you can look in nios_csh file and
use it as a reference to make the nios_bash work. These files are in
the <sopc_builder>/bin directory.
One thing I noticed is that you are using SunOS 5.9 (Solaris 2.9).
SOPC Builder 2.8 is supported on Solaris versions 2.7 and 2.8 only.
This may or may not be the problem.
There is a makefile in the lib directory for all the examples (in
fact, all systems generated by SOPC Builder have one). Here is the
path to the makefile for the standard_32 example design for the
Stratix 1S10 board (the one which comes with the Nios Dev Kit, Stratix
Edition):
<sopc_builder>\examples\verilog\nios_stratix_1s10\standard_32\cpu_sdk\lib
Lara
Petter Gustad <newsmailcomp5@gustad.com> wrote in message news:<m3llychuhz.fsf@scimul.dolphinics.no>...
> I'm trying to get nios-build to run under Solaris (using bash).
>
> uname -a
> SunOS scifire 5.9 Generic_112233-03 sun4u sparc SUNW,Sun-Fire
>
> export sopc_builder=/net/sciraid2/raid2/home/local-solaris-sun4/altera/nios-3.0
> . $sopc_builder/bin/nios_bash
>
> This results in
>
> ------------------------------------------------
> Welcome To Altera SOPC Builder
>
> Version 2.8, Built Mon Jan 6 18:04:16 2003
>
> Example nios designs can be
> found in
>
> /net/sciraid2/raid2/home/local-solaris-sun4/altera/nios-3.0/examples
>
> Try:
> nios-build hello_world.c
> nios-run hello_world.srec
> within one of the sdk subdirectories.
> ------------------------------------------------
> bash: cygpath.exe: command not found
>
> Why does the Solaris distribution try to execute something which
> appears to be a windows program?
>
> When I try to build an srec file I get
>
> [SOPC Builder]$ nios-build hello_world.c
> Can't use string ("-1") as a HASH ref while "strict refs" in use at - line 478.
>
> Any ideas? Anybody else using SOPC under Solaris? Does anybody have a
> clean Makefile to do the build rather than all the Perl stuff?
>
> Petter
Article: 54683Does anybody know if Spartan3 devices will be pin compatible with Spatan 2E? ThanksArticle: 54684
John Milbanks wrote: > "Hal Murray" <hmurray@suespammers.org> wrote in message > news:v9ncbao3qpqv5c@corp.supernews.com... > > > If you are doing something kludgy like running RS232 links > > between buildings then maybe you would expect an occasional > > error. (especially if there is a local thunderstorm) If > > you are just going a few feet over to the next machine, then > > the error rate should be 0. > > Unless the next machine over is a serial-controlled arc welder :-). > > I have to agree with your point. I've never had data corruption problems > over reasonable RS232 runs (say 100 feet) even when running at absurdly high > speeds. Thanks to everyone who responded. As I said the system consists of a UART and a pico-blaze. The solution we are going to try is to use a CRC and ACK/NAK solution (thanks to Hal Murray) with the CRC check being done in the pico-blaze. This will verify that the data got to the pico-blaze correctly. The comments on the relability of RS232 make me uneasy about the whole situation. I suspect that we will be doing some much more serious investigation of the errors we are seeing. I was hoping to avoid that as this is really only a temporary solution with the final solution being USB2. Maybe we can solve the problem sufficiently with the CRC band-aid. Theron HicksArticle: 54685
How can they be? Doesn't the spartan3 have the capability to set output series termination (i.e. digitally controlled impedance - DCI). That would have been nice to have... Theron Paul Szczesny wrote: > Does anybody know if Spartan3 devices will be pin compatible with Spatan 2E? > ThanksArticle: 54686
Yes, S3 does have the DCI. And 2E and S3 are not pin compatible. S3 supports 23 I/o standards as compared to 19 in S2E. --Neeraj "Theron Hicks (Terry)" <hicksthe@egr.msu.edu> wrote in message news:3E9CB19C.E00A35A5@egr.msu.edu... > How can they be? Doesn't the spartan3 have the capability to set output series > termination (i.e. digitally controlled impedance - DCI). That would have been > nice to have... > > Theron > > Paul Szczesny wrote: > > > Does anybody know if Spartan3 devices will be pin compatible with Spatan 2E? > > Thanks >Article: 54687
All of the MAPLD Proceedings are available on-line or on CD-ROM: http://klabs.org/mapld -- rk Ray Andraka wrote: > Xilinx puts out XCell, and Altera puts out News & Views. > Xcell has a better focus on applications. There are also a > number of FPGA conferences including FPGA, FCCM, FPL and > MAPLD. The proceedings from any of these have some > worthwhile info. > > Joe wrote: > >> ... Thanks in advance ...Article: 54688
Tim wrote: > > Steve Knapp wrote > > --------------------------------- > > Steven K. Knapp > > Spartan-3/II/IIE FPGAs > > --------------------------------- > > Why Spartan-3, not Spartan-III? Because the I's are getting a bit too messy I would assume. It bothers me just a bit more that the Spartan II is based on the Virtex and the Spartan 3 is based on the Virtex II. But the Spartan 3 is a significant deviation from the Virtex II while the Spartan II even has the same chip ID as the Virtex when using the JTAG tools. I guess the question is, what will Xilinx call the Virtex when they move *it* to the 90 nm process? Will that be the Virtex II, the Virtex IIB, the Virtex "too" or the Virtex 3? Or perhaps they will follow the lead of their tools and call it the Virtex IIi? :> -- 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: 54689
Yesterday, I converted my asynchronous uP interface to synchronous. After several hours of testing, I found the reading operation worked smoothly. However, the writing operation sometimes failed in continuous writing. I latched the writed data when the WE_N was low. The width of WE_N was 30ns, while my clock width was 20ns. Is it the adequate timing to latch the writed data? Should I employ faster clock? Any suggestion is very appreciated. Sincerely Yours, louis "Jonathan Bromley" <jonathan.bromley@doulos.co.uk> ¼¶¼g©ó¶l¥ó news:b6gub6$60n$1$8300dec7@news.demon.co.uk... > "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message > news:JMGia.1$xs3.12763300@newssvr14.news.prodigy.com... > > [me] > > > Any special reason for choosing the async write? I know it's > > > conceptually easier, but I've always found it was less pain > > > in the long run to stay synchronous where possible (and you > > > clearly *can* stay synchronous in this case). > [Martin] > > Well. Yes, but, in retrospect, none firm enough not to consider a > > synchronous solution. I just wanted to mimic the way a typical > > microprocessor interfaceable chip works (something like an 8255 PIO or > 2691 > > UART). Most of these appear to have a non-synchronous interface to the uP > > and probably synch internaly upon utilization of the register data. > > Others have thrown their weight behind a synchronous solution, but > perhaps I can just point out that both the peripheral parts you > mention are 25+ year old designs... the world has moved on a tad. > Synthesis and FPGAs both encourage synchronous design techniques, > and there's little tool support for asynchronous methodologies. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services > > Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK > Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com > Fax: +44 (0)1425 471573 Web: http://www.doulos.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. > >Article: 54690
Steve Knapp wrote: > The primary reason for this change was cost related. We evaluated a > huge number of designs from customers and found that nearly all designs > used less than 50% of the available distributed RAM or SRL features. > Certainly, there were a small percentage that used above 50%, mostly > targeted to extreme-performance DSP applications. Distributed RAM or > SRL is typically used for small, local storage needs. Applications that > need more distributed RAM or SRLs can continue to use Virtex-II or > Virtex-II Pro. Applications requiring large amounts of RAM leverage the > on-chip 18Kbit block RAMs. > > Removing the distributed RAM or SRL from half the slices allowed us to > shrink the CLB fairly significantly, consequently allowing us to shrink > the cost. The slices with memory are called SLICEM's, the 'M' > indicating Memory. The slices without memory are called SLICEL's, the > 'L' indicating Logic-Only. Logic functions fit in either slice type. > Distributed RAM and SRL only fit in SLICEM's. > > Another often-asked question is "If removing distributed RAM and SRL > reduces cost, why didn't you remove it from all the slices?" There are > two reasons, primarily. One is that a variety of designs and IP cores > use distributed RAM and SRLs already to great effect. Another is that, > when you use these features, you effectively boost the gate capacity of > a slice by up to a factor of sixteen or reduce the slice cost by up to a > factor of sixteen. For me, nothing is better than SRL in every slice. With few SRLs, i might as well use altera. I didn't mind paying more for more SRLs.Article: 54691
Steve Knapp wrote: > The primary reasons we chose not to offer a 240-pin PQFP (PQ240) option > are signal integrity, power dissipation, and cost. The smaller, > lower-cost 256-ball fine-pitch BGA package (FT256) is significantly > better in these areas plus provides additional I/O pins. The FT256 is > only 25% the area of the PQ240 package. > > http://www.xilinx.com/bvdocs/packages/ft256.pdf > > I agree that BGAs are more difficult for small-volume prototyping > compared to the PQFPs. However, they offer significant benefits for > volume applications, the primary target for Spartan-3 FPGAs. Any *volume* designs i do rule out BGA because of the need for more than 4 layer pcb. What's needed is large chips with lots of SRLs for DSP, and aim for designs with lots of parallism that needs only slower clocks and slower edges and which means lower power too. That way, cheaper packages and volume production is more feasible. Of course, the main obstacle to easily doing large dsp designs is the crappiness of the whole vhdl/verilog tool flow (which i'll do something about).Article: 54692
"Paul Baxter" <pauljnospambaxter@hotnospammail.com> wrote in message news:<3e9bd81b$0$11383$cc9e4d1f@news.dial.pipex.com>... > www.opencores.org is in the process of accepting a verilog to vhdl script > that converts a large synthesizable subset. Its open, of course, but you'll > have to keep at eye on the mailing list for details as I can't see it on the > web site yet. > The author placed the free verilog to VHDL script on: http://www.reptechnic.com.au/v2vhd.html However, the goal is to move it eventually to the geda.org site. Regards, rudi ------------------------------------------------ www.asics.ws - Solutions for your ASIC needs - FREE IP Cores --> http://www.asics.ws/ <---Article: 54693
Neeraj Varma wrote: > > Yes, S3 does have the DCI. And 2E and S3 are not pin compatible. S3 supports > 23 I/o standards as compared to 19 in S2E. That in itself does not make them pin incompatible. That would just be additional features inside the chip. I don't think the OP meant pin compatible in the sense of using the same bit stream. I know when I look for pin compatible in an FPGA, I just figure I can solder the chip in the same footprint and have it work. I fully expect to have to generate a new bit stream. The data sheets can be downloaded. I found differences in the JTAG, VCCINT and GND signals, so I would say they are not very pin compatible if at all. -- 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: 54694
Russell Shaw wrote: > > Steve Knapp wrote: > > The primary reason for this change was cost related. We evaluated a > > huge number of designs from customers and found that nearly all designs > > used less than 50% of the available distributed RAM or SRL features. > > Certainly, there were a small percentage that used above 50%, mostly > > targeted to extreme-performance DSP applications. Distributed RAM or > > SRL is typically used for small, local storage needs. Applications that > > need more distributed RAM or SRLs can continue to use Virtex-II or > > Virtex-II Pro. Applications requiring large amounts of RAM leverage the > > on-chip 18Kbit block RAMs. > > > > Removing the distributed RAM or SRL from half the slices allowed us to > > shrink the CLB fairly significantly, consequently allowing us to shrink > > the cost. The slices with memory are called SLICEM's, the 'M' > > indicating Memory. The slices without memory are called SLICEL's, the > > 'L' indicating Logic-Only. Logic functions fit in either slice type. > > Distributed RAM and SRL only fit in SLICEM's. > > > > Another often-asked question is "If removing distributed RAM and SRL > > reduces cost, why didn't you remove it from all the slices?" There are > > two reasons, primarily. One is that a variety of designs and IP cores > > use distributed RAM and SRLs already to great effect. Another is that, > > when you use these features, you effectively boost the gate capacity of > > a slice by up to a factor of sixteen or reduce the slice cost by up to a > > factor of sixteen. > > For me, nothing is better than SRL in every slice. With few SRLs, i > might as well use altera. I didn't mind paying more for more SRLs. Half the normal number is far from "few SRLs". I think a few thousand SRLs is still enough for some 99.9% of the typical designs. Of course there will always be the unusual vector processing designs like Ray's, but even then if the pricing holds to the typical Spartan curve, you will do better in terms of price with a Spartan that has twice as many CLBs as the Virtex chips and has the same number of SRLs. -- 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: 54695
Russell Shaw wrote: > > Steve Knapp wrote: > > The primary reasons we chose not to offer a 240-pin PQFP (PQ240) option > > are signal integrity, power dissipation, and cost. The smaller, > > lower-cost 256-ball fine-pitch BGA package (FT256) is significantly > > better in these areas plus provides additional I/O pins. The FT256 is > > only 25% the area of the PQ240 package. > > > > http://www.xilinx.com/bvdocs/packages/ft256.pdf > > > > I agree that BGAs are more difficult for small-volume prototyping > > compared to the PQFPs. However, they offer significant benefits for > > volume applications, the primary target for Spartan-3 FPGAs. > > Any *volume* designs i do rule out BGA because of the need for more than > 4 layer pcb. What's needed is large chips with lots of SRLs for DSP, and > aim for designs with lots of parallism that needs only slower clocks and > slower edges and which means lower power too. That way, cheaper packages > and volume production is more feasible. Of course, the main obstacle to > easily doing large dsp designs is the crappiness of the whole vhdl/verilog > tool flow (which i'll do something about). I am not aware of any requirement for more than four layers when working with BGAs. I have seen footprint layouts that allow for all signals on a BGA to be routed outside of the footprint *without* vias. Of course, not all BGA designs allow this, but certainly you don't need more than two routing layers unless your board is dense. In that case you may need more than two sides on a board to get the same component density that you can get with BGAs. They only issue I see with BGAs is the requirement for hot air soldering with BGA while a flatpack can be iron soldered. But you can do hot air soldering with an inexpensive rework station. You don't have to have an expensive oven. -- 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: 54696
> > > What's the position in writing an well-established type of CPU core (like a > > > Z80) and selling it? Some of the existing CPU cores aren't all that well suited to FPGA's. Better value can be obtained by creating a CPU that's designed around the characteristics of an FPGA. It's also possible to avoid a lot of patent and copyright issues by rolling your own. For instance I have an enhanced 65C02 compatible core that takes about 600 LC's and runs at 48MHz. But a reasonably capable 16 bit RISC running twice as fast would only take about 300 LC's. > > Some, MIPS and ARM come to mind, are so scared of the > > open/free implementations of their CPUs that they fight > > very hard to get them removed. It's easy to understand why. But if you're looking at an open/free implementation, viewer beware. > This method is patented. It is impossible to implement the 2 instructions > (and so the entire instruction set, and so an compatible chip) without > violating this patent. Interesting. I predict a flood of useless, mysterious instructions incorporated into CPU's so that it's impossible to claim compatibility without patent violation. > ARM I do not know what they use to beat down competition. I would RobArticle: 54697
Hi All, I am new to this group and also to the field of FPGA based design. I have some doubts and issues which I feel will be easy for you guys to answer. 1. For a 4 pole IIR Filter in FPGA (targeted device EP1C6), I have a spec of 24 bit wide data input and 32 bit wide coeff (dynamic) inputs. So, the multiplied results should ideally have 56 bits width. Are these widths practically relevant for a 4 pole filter or can we get an affordable precision with rounding to lower sizes? If so, can anyone suggest a standard procedure for rounding the results with lowest error and without causing the output to become unstable? 2. Another thing I would like to get some advice is, if I go with the 24 X 36 busses, since I have to implement a number of such filters in a single device, the bit-parallel implementation will take up huge resources. The digit serial approach using (either small multiplier or LUT method) also will end up in huge resources due to big number of partial products and sums involved. If anyone can suggest any alternate method it will be of great help to me. 3. On another front, in a timing simulation scenario I am using Quartus II .vo output and ModelSIM PE. My code has a ROM (ALTSYNCRAM megafunction used to generate this). I found some differences in the readout data during timing simulation between using .MIF format file and .HEX format file for initializing ROM eventhough the QII displayed same contents in the memory editor. Has anyone ever faced any such issues? Hoping to get some valuable leads on these.. Thanks in advance, PramodArticle: 54698
support ofr pixel or vertex shaders does not mean you have accelerated or hardware raytracing. Go to graphics.cs.uiuc.edu and you can see a project where they are using videa cards to do some raytracing, but it's ceratinly not real time. You would have to program in Cg and write your own raytracing code for the video card. And again, it won't be real time. They would have notes on the time you can perhaps get from it. An the side, I have this link to a drive you can buy which accelerates the renderman sahding. I don't know much about it, but you can take a look. http://www.id8media.com/accelerators_products/render_drive_features.html hope that helps. Dieter -- Dieter Van Wassenhove "Svjatoslav Lisin" <netbreaker666@mail.ru> wrote in message news:b7bh5l$b1t$1@news.wplus.spb.ru... > Does somebody know any ready hardware systems for raytracing acceleration ? > How much can it cost? > >Article: 54699
Hi, I'm using Xilinx ISE 5.2 and this is the first time I have access to the core generator. I wonder if it is always better (in terms of size and speed) to use basics components created with the Core Generator. For example, should I change all the Dflipflops of my designs (I wrote them in vhdl) for the one that can be generated with Core generator? What about adders? Is (c <= b+a ) still used or you always take the core generator components? Thanks David
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