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
I know that Keith Underwood of Sandia National Labs has compared the FP performance of FPGAs to GPPs and projected this into the future. http://portal.acm.org/citation.cfm?id=968305 StephenArticle: 91651
john wrote: > It is for a bidirectionnal signal: input is registered into IOB, output is also registered there, but the duplicated tristate_enable registers don't want to go inside the OLOGIC (Virtex 4). Each of them is not that far, but not into the IOB! > - Make sure the tristate 'registers' are duplicated, not the output of the tristate register. - Make sure the duplicated registers have proper attribute so the synthesis tool doesn't optimize them into a single register.Article: 91652
You may have already done what I mentioned. One more - make sure the tristate registers feed nothing else outside of the IOB. You might want to post your code if it still doesn't do it...Article: 91653
Stephen Craven wrote: > I know that Keith Underwood of Sandia National Labs has compared the FP > performance of FPGAs to GPPs and projected this into the future. > > http://portal.acm.org/citation.cfm?id=968305 > > Stephen > I have several papers by Mr Underwood and will probably cite him in my work. These are excellent sources for floating point comparison and very helpful to that end. I was hoping that someone might know of a similar resource that compared other aspects of FPGA based designs to microprocessors. thanksArticle: 91654
theArticle: 91655
I don't have any error: I just checked with fpga_editor that I am not using both FF inside the OLOGIC. This results in a poor timing because the routing adds to the iobuf timingArticle: 91656
thanks for help. I respect these three conditions. (I checked with fpgaeditor) code is (removed reset as in teXclusive on xilinx website): iob_t:process(CLK) begin if rising_edge(CLK) then DATA_REG(i) <= DATA(i); tristate_enable_reg(i) <= tristate_enable_reg(i); end if; end process; well maybe I'll consider opening a webcase!Article: 91657
Peter Alfke wrote: > Geoffrey, > the most important aspect is the freedom in systems architecture > offered by FPGAs. This allows you to use massive parallelism for higher > performance, or serial processing for lower cost etc. > If you look just at clock rate, FPGAs suffer a penalty imposed by the > interconnect flexibility. You have to compensate for that by taking > advantage of the architectural flexibility offered in FPGAs. > And do not forget (dynamic) reconfigurability... > Peter Alfke, Xilinx Applications > For video processing the biggest impact that this flexibility has is on memory bandwidth. I have watched attempts to use DSP chips for video processing, I have studied using them, and I have been involved to varying degrees with a number of successful video processing designs using FPGAs. In all cases the FPGA won the design primarily because you can make the memory as wide as you need, and can often play tricks like having multiple memory buses feeding the processing. When you have a processing algorithm that requires more than one frame buffer, or a frame buffer and coefficient memory operating simultaneously, a DSP with one memory interface just can't cut it. By the time you pile enough DSPs on a board to equal the performance of an FPGA solution you're burning holes in the carpet with the power dissipation. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 91658
"Marco" <marco@marylon.com> ha scritto nel messaggio news:1131461408.810685.93980@g14g2000cwa.googlegroups.com... > How could I implement a bus in my Spartan3 to let it communicate > thorough a 16bit wide, 100MHz bus with a Blackfin DSP? Thanks, Marco Perhaps you can borrow some ideas from the Analog Devices own FPGA (Spartan 3) extension board for the Blackfin. http://www.analog.com/en/epHSProd/0,,BF-EXTENDERFPG,00.html I don't know how the FPGA talks to the chip, via PPI or with a complete bus interface.Article: 91659
John, tristate_enable_reg(i) <= tristate_enable_reg(i); ?? Is that what you wanted? Syms "john" <john.wo.71@gmail.com> wrote in message news:ee91b0b.5@webx.sUN8CHnE... > thanks for help. > > I respect these three conditions. (I checked with fpgaeditor) > > code is (removed reset as in teXclusive on xilinx website): > > > > iob_t:process(CLK) begin if rising_edge(CLK) then DATA_REG(i) <= DATA(i); > tristate_enable_reg(i) <= tristate_enable_reg(i); end if; end process; > > well maybe I'll consider opening a webcase!Article: 91660
I'm using the GRLIB/LEON processor from Gaisler research (www.gaisler.com) which provides a fairly flexible/implementation independent set of VHDL libraries to implement a 32bit SPARC compliant processor. The project appears popular with the European Space Agency, and LEON based designs keep popping up all over... From satellite applications to network routing. The library is available under a dual license scheme where a GPLed version is released, but a commercial license is also available. This allows/encourages academic research/playing around (which I confess i'm doing), while also allowing developers to build their own (proprietary) applications on the LEON base. This model makes the whole project much more sustainable than other after-hours hobby type projects. But it can be tricky applying the GPL to an HDL project, because traditional concepts like source code and binary executables are transferred to a domain with source, several intermediate netlist formats, some of which can be regarded as source when you're wide awake... And distribution of embedded systems is the other ill defined part - most users don't care/know about the embedded configurable logic, and they are unlikely to expand on a very application specific design (as Eli stated above). And what happens when you start combining HDL code with presynthesised netlists? I think a modified (HDL) GPL would be required to accurately cover the issue, much as is done by the GNU Free Documentation License. In the meantime, if I have a nifty piece of HDL solving a problem, I'll probably post it somewhere, and hope someone else finds a use for it... johannesArticle: 91661
On a sunny day (Thu, 10 Nov 2005 11:24:08 -0500) it happened Eli Hughes <emh203@psu.edu> wrote in <dkvs78$s80$1@f04n12.cac.psu.edu>: >I seriously doubt you see anything much bigger that the snippets on Open >Cores. This is may be different in the educational community where open >source is much more widely used, but in industry very few would be >willing to give away what they spent zillions of man hours developing. > >One could make the argument that there should be a library for simple >constructs that would be common to all FPGA, ASIC platforms. What you >would end with is the equivalent of a C library that only adds to >numbers. Not very useful for serious work. Not completely correct, does not Altera has the 7400 TTL library? Is not opencores doing this exactly? >In the FPGA world, there are lots of places were you can buy working IP >cores that are fully documented and supported. My boss isn't willing to >spend 4 times the cost of working 3rd party IP to debug an open source >version that isn't documented that well and has no support. My experience with open source, as a WRITER of open source, is that bug are fixed and replies are within one or 2 days (by me). Some people take weeks to reply-- if at all. YMMV. Some send you a very complicated question you spend ages to figure out, you reply, and then never hear anything.... Some commercial companies have the same pattern, for example Xilinx representatives here. THESE behave almost like it is a favor that you can buy a FPGA. And on the other side of it, lots<<< of those 'commercial companies / IP' you seem to like so much, grab open source code and use it in their product WITHOUT mentioning or respecting GPL. I even found one website that sold my GPL program, hehe I announced a new feature, so did they, then I left it at the announcement :-) So they were stuck.. I could do that.. Bad for a commercial company, not sure they still are on the net. Kiss DVD players grabbed code from the mplayer project, some Chinese company actually ASKED me if they could use my code, I wanted to negotiate a price, then they were going to use it anyways, I referred to the GPL, and 'clean room' BIOS designs, they let somebody else do the coding..... in that company.. who did not use my source.. believe it? Its true, hard to argue. So, and I have seen this happen in places I worked, websearch 'grab those few lines of code'. Natural thing. At that time my boss had the decency to try to contact the guy and pay him something. >The problem in this model is the same problem with the open source >software community. While some of the products are nice, they are >plagued with *lots* of useless projects/libraries that take a week to >install, have poor documentation and no support. Ever try to install and run an official MS library? Most open source projects install without problems (on the right architecture). You mean you do not want to think AT ALL? ;-) > Why would I want to >spend my time on that. Most forget that while open source stuff is free >, it may take 4 times the time to use. This is only cheaper if your >time doesn't cost a whole lot. Not correct, it does not 4 times the time to use, makes no sense. >All this being said, I really like the open cores site. I would use it >for hobby/side projects. As for serious commercial projects, I place >more trust in either my own or paid for IP that is tested and supported. Sure, many times I wrote something because it was not there (in Linux). that is how the 50+ applications I released under GPL came about. If it EXISTED I would not have bothered writing it. Sure a HDL library would be nice, if a university has that, maintains that, then it will benefit everybody, save you money. But if released under GPL-1 the rest of your HDL will likely have to be under GPL too. So, I have heard they are working on GPL-3 now..... do not know details. Software patents should not exist. And yes I admit to keeping HDL secret to protect others copying the design. It is the last border, the last defense! (... capitalism - communism... but maybe we need a synthesis, look at China). But wait, somebody will invent the (startrek) replicator, and then what.Article: 91662
sorry I mistyped! obviously it is: tristate_enable_reg(i) <= tristate_enable(i);Article: 91663
> > Not completely correct, does not Altera has the 7400 TTL library? > Is not opencores doing this exactly? Yes, but having a TTL library is only useful for doing schematic in Altera's tools, not HDL. Evening thinking in TTL when you have an HDL is counter-productive! > My experience with open source, as a WRITER of open source, is that > bug are fixed and replies are within one or 2 days (by me). > Some people take weeks to reply-- if at all. YMMV. > Some send you a very complicated question you spend ages to figure out, > you reply, and then never hear anything.... > Some commercial companies have the same pattern, for example Xilinx > representatives here. > THESE behave almost like it is a favor that you can buy a FPGA. > And on the other side of it, lots<<< of those 'commercial companies / IP' > you seem to like so much, grab open source code and use it in their product > WITHOUT mentioning or respecting GPL. > I even found one website that sold my GPL program, hehe I announced a new > feature, so did they, then I left it at the announcement :-) So they were > stuck.. I could do that.. Bad for a commercial company, not sure > they still are on the net. > Kiss DVD players grabbed code from the mplayer project, some Chinese company > actually ASKED me if they could use my code, I wanted to negotiate a price, > then they were going to use it anyways, I referred to the GPL, and > 'clean room' BIOS designs, they let somebody else do the coding..... in that > company.. who did not use my source.. believe it? Its true, hard to argue. > So, and I have seen this happen in places I worked, websearch 'grab those > few lines of code'. > Natural thing. > At that time my boss had the decency to try to contact the guy and pay him > something. I would agree mostly with this. But, generally for any company that is worth a damn I have never had a problem with support. > Ever try to install and run an official MS library? Yes, double clikc on icon. Wait a bit. Start programming. My experience with PC/GUI stuff is very limited though. I like to live in the hardware/micrcontroller world where I have control. I do not wish to be encumbered by an operating system which will only get in my way! > Most open source projects install without problems (on the right > architecture). > You mean you do not want to think AT ALL? > ;-) Not when it comes to installing and using something. My job is to make a product work, not chasing down 200 dependecies. :-) You are right though. This has improved. I prefer not to think. I like to "be still like broccolli". > > >>Why would I want to >>spend my time on that. Most forget that while open source stuff is free >>, it may take 4 times the time to use. This is only cheaper if your >>time doesn't cost a whole lot. > > Not correct, it does not 4 times the time to use, makes no sense. > I should have said: "4x the time to get the same useful result". This isn't always true, but when I pay for something I am paying for documentation. When I have to reverse engineer something to get it to work right I am wasting my time. And when the docs are skimpy, I get angry. This is not true of all open-source software (I love the PHP project, I use php for my web scripts!) but most open source projects are not that organized. > > >>All this being said, I really like the open cores site. I would use it >>for hobby/side projects. As for serious commercial projects, I place >>more trust in either my own or paid for IP that is tested and supported. > > > Sure, many times I wrote something because it was not there (in Linux). > that is how the 50+ applications I released under GPL came about. > If it EXISTED I would not have bothered writing it. > > Sure a HDL library would be nice, if a university has that, maintains > that, then it will benefit everybody, save you money. > But if released under GPL-1 the rest of your HDL will likely have to be > under GPL too. > So, I have heard they are working on GPL-3 now..... do not know details. > Software patents should not exist. > And yes I admit to keeping HDL secret to protect others copying the design. > It is the last border, the last defense! > (... capitalism - communism... but maybe we need a synthesis, look at China). > > But wait, somebody will invent the (startrek) replicator, and then what. > > Boy, I wish the replicator existed! Then I could go home. :-) -ELiArticle: 91664
Since the output state after configuration is probably low for those outputs stuck at ground, I would first make sure that you are indeed supplying a clock to the part and that the pin you supply the clock to is the same one used by the logic... "when everything doesn't move, check the clock first..." Just my 2 cents, Gabor jvdh wrote: > Maybe someone can make a suggestion: > > I'm building a board with a Coolrunner XPLA3384 on it, however, my > intitial (very very basic) test code is running into problems... The > device is programmed and verified successfully, but all (configured) > output pins remain at ground. > > Pins not configured as outputs a pulled up by the internal pullup > resistors, just as when the device is in an erased state. I'm using > dedicated JTAG pins to configure the device > > I've checked the power and ground pins, all are looking good, same goes > for short circuits between the pins and ground... > > I feel I'm missing something small - can anyone perhaps make a > suggestion on where to look? > > Thanks > > johannes > > http://students.sun.ac.za/~jvdhArticle: 91665
I am having difficulty solving a timing problem using a Spartan 3
embedded platform. We are using a MicroBlaze core with some user IP
modules and some Xilinx modules attached through the OPB bus. One of
the IP modules is a 3-wire serial data interface. We have to be able
to generate multiple protocols so this module handles all of that. The
"data" line is bidirectional. It is connected correctly to a
bidirectional buffer at the top level. We write data to a "part" and
then can read that data back from the part. The part sends back a bit
of data on the FPGA's "data_clock" rising edge. The FPGA clocks that
data in on the falling edge of the "data_clock" signal. All was
working fine unitl we placed an extension board on our platform. This
effectively makes the external path from the "part" to the FPGA much
longer. The readback does NOT work when using this board. The FPGA
reads back data, but not the correct data.
There are test points on our platform that allow us to look at the
3-wire interface signals in between the part and the FPGA. These
signals look fine (with respect to timing) when using the board that
works and the one that doesn't. It seems that the critical delay is
happening in the FPGA. It seems like the data going in to the pin is
not getting to the module IP logic before the critical clock edge
occurs. Is there a way to tell the Xilinx tools (via UCF constraints)
to constrain that path to a certain time spec?
Another problem is that I have looked at the ngc file for the
EDK-produced wrapper for my module. The correct three signals
("data_O", "data_I", and "data_T") are I/O pins on the module, but once
I dive down into the mapped implementation, the "data_I" is not longer
anywhere to be found! I don't know where it goes, so I can't find a
net name or anything like that to constrain! What is going on there?
Thanks....
Article: 91666john wrote: > the You might want to try: attribute equivalent_register_removal of tristate_enable_reg: signal is "no"; --- JoeArticle: 91667
motty wrote:
> We write data to a "part" and
> then can read that data back from the part. The part sends back a bit
> of data on the FPGA's "data_clock" rising edge. The FPGA clocks that
> data in on the falling edge of the "data_clock" signal.
clk __--__--__--__--__--
data ___----____----_
sample-____|___|___|___ wastes half of your setup time vs
sample+__|___|___|___
-- Mike Treseler
Article: 91668Hey all, I am designing(trying to design) an sdram controller (for a PC133 module) to work as fast as it is possible and as I understand from the datasheet, if I read faster than I need to refresh, then I can avoid refresh altogether. i.e if the refresh period is 64ms and if i access the data every, say, 20ms then I dont have to refresh. Please tell me if this is true or if I am getting confused. Thanks in Advance.Article: 91669
Mike-- Seems you are telling me to sample the data on the rising edge. This is the same clock that the external part is seeing. The external part changes data on the rising edge. I can't be sure that data is valid then. The part is spec'd to interface to a device that will sample on the falling edge. If I look at an o-scope of the data vs. clock signal, the data becomes "valid" about halfways throught the positive cycle of the the clock. It is definitely valid on the falling edge of that clock. But that is external to the FPGA. Those signals look entirely different at the logic interface in the FPGA. I need to understand what is happening from the pin to the path inside.Article: 91670
On 10 Nov 2005 13:27:59 -0800, "Subhasri krishnan" <subhasri.krishnan@gmail.com> wrote: >Hey all, >I am designing(trying to design) an sdram controller (for a PC133 >module) to work as fast as it is possible and as I understand from the >datasheet, if I read faster than I need to refresh, then I can avoid >refresh altogether. i.e if the refresh period is 64ms and if i access >the data every, say, 20ms then I dont have to refresh. Please tell me >if this is true or if I am getting confused. >Thanks in Advance. If you accessed every row within each SDRAM at least once during the refresh period, you would not have to refresh explicitly. If your access pattern is predictable and continuous, you could do this, but it requires some careful thought. In virtually all cases, you'd need a mighty good reason to dispense with conventional refresh cycles, which typically eat up only 2 to 3 percent of available memory bandwidth. Bob Perlman Cambrian Design WorksArticle: 91671
g.wall wrote: > has anyone in the dig. design and reconfig. computing community looked > seriously at open source hardware design libraries, working toward a > hardware paradigm similar to that in the open source software community? > I am aware of the existence of opencores.org, but this seems like a > small first step, of which many more could be taken toward improving the > availability and ease of access and use of open source logic designs. > does anyone have any thoughts or knowledge or any thing to say about > an open source hardware paradigm? One of the reasons behind starting the FpgaC project on sourceforge was to head in that direction, especially in terms of reconfigurable computing at a hobby level, and small business level as the normal commercial tools are way out of sight, and everybody has a proprietary IP mindset. For pure digital design, it's frequently pretty difficult to extract meaningful reusable IP, as many cores have such complex interfaces that it's common to have difficulty in fitting them into a completely difference architecture. For reconfigurable computing, there is a lot of common library code that becomes usable with C based varients, particulary in terms of dynamic reconfiguration, interprocess (hardware threads) communication, and even high level device interfaces (drivers) that can be much more easily reused in various SoC and reconfigurable projects. Even basic OS services for reconfigurable computing are in dire need at this point. And compilers and loader tools that can handle dynamic partitioning and loadable segments. Doing this with ISE and mainstream tools is painful at best. JohnArticle: 91672
motty wrote:
> I am having difficulty solving a timing problem using a Spartan 3
> embedded platform. We are using a MicroBlaze core with some user IP
> modules and some Xilinx modules attached through the OPB bus. One of
> the IP modules is a 3-wire serial data interface. We have to be able
> to generate multiple protocols so this module handles all of that. The
> "data" line is bidirectional. It is connected correctly to a
> bidirectional buffer at the top level. We write data to a "part" and
> then can read that data back from the part. The part sends back a bit
> of data on the FPGA's "data_clock" rising edge. The FPGA clocks that
> data in on the falling edge of the "data_clock" signal. All was
> working fine unitl we placed an extension board on our platform. This
> effectively makes the external path from the "part" to the FPGA much
> longer. The readback does NOT work when using this board. The FPGA
> reads back data, but not the correct data.
>
> There are test points on our platform that allow us to look at the
> 3-wire interface signals in between the part and the FPGA. These
> signals look fine (with respect to timing) when using the board that
> works and the one that doesn't. It seems that the critical delay is
> happening in the FPGA. It seems like the data going in to the pin is
> not getting to the module IP logic before the critical clock edge
> occurs. Is there a way to tell the Xilinx tools (via UCF constraints)
> to constrain that path to a certain time spec?
>
> Another problem is that I have looked at the ngc file for the
> EDK-produced wrapper for my module. The correct three signals
> ("data_O", "data_I", and "data_T") are I/O pins on the module, but once
> I dive down into the mapped implementation, the "data_I" is not longer
> anywhere to be found! I don't know where it goes, so I can't find a
> net name or anything like that to constrain! What is going on there?
>
> Thanks....
>
You can specify how early the data will arrive with respect to the
active clock edge that will register it. This can be done in the UCF
file using the OFFSET-IN-BEFORE constraint.
eg.
NET "<DataInputPin>" OFFSET = IN <X> ns BEFORE "<ClockPin>" HIGH/LOW;
The static timing analyzer will calculate the clock path and data path
delays and ensure that
X - data_path_delay + clock_path_delay > setup_time_required.
Where X is from your constraint above.
If not timing for that path will fail.
As Mike said, I think you are better off using the the rising edge.
Don't worry about the hold time, Xilinx devices are designed to have
zero hold time.But, you will have problems if the clock delay is more
than the data delay, but that is unlikely.
Kunal
Article: 91673A number of the various papers fail to search out the best space time tradeoffs. Mistakes like doing 64bit floating point multipliers the hard way in an fpga, or doing an FFT/IFFT as wide parallel which isn't always the best space time tradeoff. There are MANY other architectures that can be developed to optimize the performance of a particular application to FPGA, beside brute force implementation of wide RISC/CISC processor core elements here. Frequently bit serial will yield a higher clocking rate (as it doesn't need a long carry chain), and doesn't need extra logic for partial sums or carry lookahead, so it also delivers more functional units per part, but at the cost of latency which can frequently be hidden with the faster clock rate and high function density per part. It can also remove memory as a staging area for wide paralle functional units, and thus remove a serialization imposed by the solutions architecture. Bit serial operations using Xilinx LUT fifo's can be expensive in both power and clock rate reductions, but that is not the only way to use LUTs for bit serial memory. Consider using some greycode counters and using the LUT's simply as 16x1 rams instead ... faster and less dynamic power. There are lots of ways to get unexpected performance from FPGAs, but not by doing it the worst possible way. Be creative. $30M US of FPGAs and memories can easily build a 1-10 Petaflop super computer that would smoke existing RISC/CISC designs ... we just don't have good software tools and compilers to run applications on these machines, or have developed enough programming talent used to getting good/excellent performance from these devices. There are a few dozen better ideas about how to make FPGAs as we know them today, into the processor chip of tomarrow, but that is another discussion. Consider distributed arithmetic made FPGA's popular for high performance integer applications, and it's not even a basic type available from any of the common compilers or HDL's. Consider the space time performance of three variable floating point multiple accumulate (MAC) algorithms using this approach for large matrix operations. Consider this approach for doing high end energy/force/weather simulations using a traditional Red/Black interleave as you would use for these applications under MPI. 3, 6, 9, 12 variable MAC's are a piece of cake with distributed arithmetic, and highly space time efficient. The core algorithms of many of these simulations are little more than MAC's, frequently with constants, or near constrants that seldom need to be changed. Consider for many applications the dynamic range needed during most of the simulation is very limited, allowing systems to be built with FP on both ends of the run, and scaled integers in the middle of the run, even simpifing the hardware and improving the space time fit even more. The big advantage to FPGAs is breaking the serialization that memory creates in RISC/CISC architectures. Memoryless computing using pipelined distributed arithmetic is the ultimate speedup for many applications, including a lot of computer vision and pattern recognition applications. So read the papers carefully, and consider if there might not be a better architecture to solve the problem. If so, take the numbers and conclusions presented with a grain of salt.Article: 91674
Another developer joined the FpgaC project today to cleanup some of the yacc/lex design issues as a C compiler (like variable scope). This, structures, unions, typing, and unsigned variables are on the near term list of things to fix in this compiler so it will take a cleaner subset of traditional C. Longer term I would like to add direct support for bit serial distributed arithmetic to be able to support multiply, multiply-accumulate, divide and mod (%) operations. Plus add direct support for threads by using some compiler primatives that know about fork(), exec(), along with library primatives for MPI and posix-threads so that parallelism would remain expressed the same way in FPGA and RISC/CISC testing environments. Anybody else have pet ideas, suggestions, or wish-list items that a C based HLL/HDL tool should handle?
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