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 aim to demonstrate the need for FPGAs as compared to MPUs like (e.g. ARM = Cortex-M3 based from TI/ST) in doing processing intensive stuff. I am looki= ng for some help in this regard. I want to show that a design based on MPUs= + FPGA will be more faster (feasible?). The following is what i have come up with till now, Comparing N-Point FFTs Compare designs based on Cordic Huge Calculations based on Fixed/Floating points Systems. (ALU Design) Are there more novel applications where the FPGA + MPU design achieves much= more than a single MPU ? It would be great to have some stuff pointed at. = Happy to read as always :) Thanks.Article: 154901
On Sunday, February 10, 2013 3:53:33 AM UTC+13, Shanjit Singh wrote: > I aim to demonstrate the need for FPGAs as compared to MPUs like (e.g. AR= M Cortex-M3 based from TI/ST) in doing processing intensive stuff. I am loo= king for some help in this regard. I want to show that a design based on MP= Us + FPGA will be more faster (feasible?). >=20 >=20 >=20 > The following is what i have come up with till now, >=20 > Comparing N-Point FFTs > Compare designs based on Cordic > Huge Calculations based on Fixed/Floating points Systems. (ALU Design) > Are there more novel applications where the FPGA + MPU design achieves mu= ch more than a single MPU ? It would be great to have some stuff pointed at= . Happy to read as always :) Thanks. You have missed IO response time issues.=20 For items like high precision PWN, or fast protection PWM, or other critica= l real-time IO, sometimes a small state engine done in Logic, runs rings ar= ound a SW attempt. See Cypress & Actel for offerings of Programmable Logic + CPU.=20 -jgArticle: 154902
On Sat, 09 Feb 2013 06:53:33 -0800, Shanjit Singh wrote: > I aim to demonstrate the need for FPGAs as compared to MPUs like (e.g. > ARM Cortex-M3 based from TI/ST) in doing processing intensive stuff. I > am looking for some help in this regard. I want to show that a design > based on MPUs + FPGA will be more faster (feasible?). > > The following is what i have come up with till now, > > Comparing N-Point FFTs Compare designs based on Cordic Huge Calculations > based on Fixed/Floating points Systems. (ALU Design) > Are there more novel applications where the FPGA + MPU design achieves > much more than a single MPU ? It would be great to have some stuff > pointed at. Happy to read as always :) Thanks. Well, if there wasn't a need for such things, then there wouldn't be a market for FPGAs, now would there? My work experience with FPGA + CPU designs is that they tend to complicate the project management, because you need more good people all at the same time. As an example, given a microcontroller that has a rich enough timer feature set, you can do a motor controller board with a good software engineer and a good analog circuit designer, with maybe some mutual puzzlement around the edges. Go to do some FPGA-based video processing, and you need a good software guy, a good analog guy, and a good FPGA guy. Depending on how easy it is to schedule people in advance at your company, getting one expert from each of three disciplines can easily be more than twice as hard as getting one expert each from two. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 154903
Hello, Has anyone found the option in Vivado that controls I/O register packing? ISE has a single implementation option that forces the default to use the I/O registers on inputs and outputs where possible. I have not been able to find that option in Vivado. Thanks for any help. PeteArticle: 154904
I get the following error message.
[Netlist 29-69] Cannot set property 'IOB', because the property does not exist for objects of type 'port'. ["C:/Users/pedro/Xilinx/artix_test/artix_test.srcs/constrs_1/new/top.xdc":7]
Here is my TCL constraints file so far. I just copied the syntax in UG912.
create_clock -period 5.000 -name clk -waveform {0.000 2.500} [get_ports clk]
set_output_delay -clock [get_clocks clk] 4.000 [get_ports {led[0] led[1] led[2] led[3]}]
set_input_delay -clock [get_clocks clk] 3.000 [get_ports enable]
set_property IOB TRUE [get_ports {led[0] led[1] led[2] led[3]}]
Article: 154905Stick with VHDL. You will have to type till your fingers go numb but once something is designed, it stays designed. PeteArticle: 154906
On Feb 9, 4:53=A0pm, Shanjit Singh <shanjitsi...@gmail.com> wrote: > I aim to demonstrate the need for FPGAs as compared to MPUs like (e.g. AR= M Cortex-M3 based from TI/ST) in doing processing intensive stuff. I am loo= king for some help in this regard. I want to show that a design based on MP= Us + FPGA will be more faster (feasible?). > > The following is what i have come up with till now, > > Comparing N-Point FFTs > Compare designs based on Cordic > Huge Calculations based on Fixed/Floating points Systems. (ALU Design) > Are there more novel applications where the FPGA + MPU design achieves mu= ch more than a single MPU ? It would be great to have some stuff pointed at= . Happy to read as always :) Thanks. For most of the things you mentioned, comparison of tiny ARM Cortex-M3 against modern low end Xilinx/Altera FPGA is not apple-to-apple comparison. FPGAs are bigger, more expensive and esp. if you compare against TI Stellaris-M3S Series, produced on much more advanced silicon process. As an unfortunate consequence of being produced on more advanced digital process, Xilinx/Altera FPGAs contain no on-chip NOR flash. So, it's more relevant to compare FPGAs vs products of similar size/ price/silicon generation, e.g. Analog's Blackfin, TI C5000 or C6000 DSPs or ARM Cortex-R4/ARM Cortex-A5 based microcontrollers from your favorite manufacturer. In fact even ARM Cortex-A7 cores are much smaller than FPGAs, but those tend to be integrated in relatively big SOCs.Article: 154907
On Tue, 2013-02-12 at 05:46 -0800, peter dudley wrote:
> I get the following error message.
>=20
> [Netlist 29-69] Cannot set property 'IOB', because the property does
> not exist for objects of type 'port'.
> ["C:/Users/pedro/Xilinx/artix_test/artix_test.srcs/constrs_1/new/top.xdc"=
:7]
>=20
> Here is my TCL constraints file so far. I just copied the syntax in
> UG912.
>=20
> create_clock -period 5.000 -name clk -waveform {0.000 2.500}
> [get_ports clk]
> set_output_delay -clock [get_clocks clk] 4.000 [get_ports {led[0]
> led[1] led[2] led[3]}]
> set_input_delay -clock [get_clocks clk] 3.000 [get_ports enable]
> set_property IOB TRUE [get_ports {led[0] led[1] led[2] led[3]}]
You cannot set IOB on ports. You must do so on the FFs.
Jan
Article: 154908On Tuesday, February 12, 2013 5:08:38 AM UTC-8, peter dudley wrote: > Hello, > > > > Has anyone found the option in Vivado that controls I/O register packing? > > > > ISE has a single implementation option that forces the default to use the I/O registers on inputs and outputs where possible. I have not been able to find that option in Vivado. IOB is a property on registers so try setting it on the register you want to pack it to an IO location.Article: 154909
hi folks, I am investigating for edu. purposes arm cortex M0 "design start edition" in legacy spartan3E1600 or 3adsp1800. Labs can't afford new boards this year... I am especially interrested in ddr ram / (arm) ahb-lite wrapping : mig/mpmc xilinx tools dont have wizard for that bus, it shoud be doable, but tricky... is there something freely available ?? regardsArticle: 154910
So it is back to 1985. I have to name all my registers or figure out what the synthesis tool calls them and hope they don't change names over time. In Synopsys there was a trace back feature. You could trace ports to the nearest register then put the property on that. It was very indirect and often broke over time, generating very strange error messages. PeteArticle: 154911
In article <43b386bb-a1e6-4ff4-baf2-e24a0c53a857@googlegroups.com>, peter dudley <padudle@gmail.com> wrote: >So it is back to 1985. I have to name all my registers or figure out >what the synthesis tool calls them and hope they don't change names > over time. > >In Synopsys there was a trace back feature. You could trace ports >to the nearest register then put the property on that. It was very >indirect and often broke over time, generating very strange error >messages. Can't offer anything other than hoping Xilinx get's back to you with some sort of general solution. You're probably a month of so ahead of me in using Vivado. Disappointing if we have all sorts of whiz-bang new flows, but the most basic things like this just don't work. I'd imagine there's gotta be some kind of way to wildcard it in the new tcl flows. Just be great if Xilinx would figure it out and show an example - for a feature that 99% of it's users will need. --MarkArticle: 154912
I'm getting some errors when I try to compile my design in Aldec's Active-H= DL. # Warning: ELAB1_0026: BITADJ128.bde(BITADJ128.vhd) : (79, 0): There is no = default binding for component "buf". (No entity named "buf" was found). # Warning: ELAB1_0026: BITADJ128.bde(BITADJ128.vhd) : (157, 0): There is no= default binding for component "INV". (No entity named "INV" was found). # Warning: ELAB1_0026: BITADJ128.bde(BITADJ128.vhd) : (277, 0): There is no= default binding for component "GND". (No entity named "GND" was found). I have added these items to the library multiple times, and in different wa= ys, but it still gets hosed up. I'm wondering if anyone else has had a simi= lar issue? I inherited a large design I'm converting from EDIF to VHDL and = switching from Virtex-4 to Virtex-5, and there seems to be a symbol resolut= ion problem. Thanks all!Article: 154913
peter dudley <padudle@gmail.com> wrote: > Stick with VHDL. > > You will have to type till your fingers go numb but once something is > designed, it stays designed. > > Pete Mmh, I'm more and more getting into the chisel thing. I like it and maybe this gives me (and others, like my students) a productivity boost. My thoughts about risk: yes, there is a risk with using a new not yet established language. However, three arguments against being afraid: (1) it is the design and not the description that counts. If you need to drop a tool/language, rewriting your design in a new language is not that much work. (2) it uses Verilog as intermediate language. So the synthesize heavy lifting is done by the well established tools in a well established language. (3) it is open source. You can always contribute patches to the project to fix issues. If they are ignored you can still fork for your project to survive, although OS project forking is a bad idea. Cheers, MartinArticle: 154914
On Tue, 2013-02-12 at 10:18 -0800, peter dudley wrote: > So it is back to 1985. I have to name all my registers or figure out > what the synthesis tool calls them and hope they don't change names > over time. >=20 > In Synopsys there was a trace back feature. You could trace ports to > the nearest register then put the property on that. It was very > indirect and often broke over time, generating very strange error > messages. >=20 > Pete You can track the FFs from your ports using TCL commands in Vivado. I do not remember the exact syntax but you would use your original "get_ports" command as a parameter to another TCL command(s) to get your FFs for the "set_property" command. I just checked my Vivado training materials and it seems you do not need to explicitly set IOB to TRUE on all the I/O FFs. The Vivado implementation does this automatically by default unless you disable it. You can disable it in the implementation settings using the "no_timing_driven" option of the "place_design" process. JanArticle: 154915
has anyone managed to do anything with efuses on spartan-6? I expected to use an old parallel cable since I usually have much need for jtag, but efuses are only supported with platform cable usb II, so I got bought one and got it installed and working on my 64bit win7 machine only to find out that efuse operations are only supported on 32bit winxp (atleast that is what the error mesage says) no problem I though, I'll just find an old XP machine, but I have now tried three different 32bit xp machines, every possible combination of ports/cables/hubs, driver installs/ uninstall/reinstall, ISE versions and every webcase suggestion I could find and every time I get the same result, an "unknown usb device" Is it actually possible to install platform cable use II on winxp?, and is an obsolete OS on old hardware really the only option for programming efuses on spartan-6 -LasseArticle: 154916
"Mmh, I'm more and more getting into the chisel thing. I like it and maybe = this gives me (and others, like my students) a productivity boost." Martin, I'd rather universities teach students how to get more productivity out of = the existing, standard, tool-supported HDLs. The status quo, perhaps due to= the required simplicity of class projects, is typically an HDL description= written at barely above the netlist level anyway. Very little attention is= typically paid to SW engineering principles that become critical (and extr= emely productive) on larger, more complex projects. If these principles and= techniques are not taught to HW students, any productivity increases obser= ved while merely changing languages will be marginal at best. At some point= , the level of abstraction has to get beyond the current 'This is a registe= r; these are some gates.' approach to HDL-based design, or it does not matt= er what language you use. "My thoughts about risk: yes, there is a risk with using a new not yet esta= blished language. However, three arguments against being afraid: (1) it is = the design and not the description that counts. If you need to drop a tool/= language, rewriting your design in a new language is not that much work." Does that "not much work" include re-writing your development processes and= procedures, coding and review standards, development and verification plan= s, not to mention test benches? And is this true for most designs, or just = the typical class project level designs? "(2) it uses Verilog as intermediate language. So the synthesize heavy lift= ing is done by the well established tools in a well established language." So when you get a synthesis error/warning, it refers you to the machine-gen= erated, intermediate language code, which is cross-referenced to the origin= al source code how? MyHDL takes this same approach (it actually produces both VHDL and Verilog = to support synthesis and other tools). However, the MyHDL source is "elabor= ated" before the conversion to the supported HDLs, which means that if you = have a parameterizable source module (that could have been kept parameteriz= ed in VHDL), you get a separate version of the HDL for every unique paramet= erization, thus further stretching the already tenuous connection between t= he source that is written, reviewed and maintained, and the HDL your synthe= sis tool is warning you about. "(3) it is open source. You can always contribute patches to the project to= fix issues. If they are ignored you can still fork for your project to sur= vive, although OS project forking is a bad idea. Cheers, Martin" The tool vendors are unlikely to support an HDL that has no controlled stan= dard; it's too fluid a target to hit. Until it is controlled and tool-suppo= rted, its real-world productivity gains are practically zero, if not negati= ve. AndyArticle: 154917
On 2/13/2013 1:35 PM, jonesandy@comcast.net wrote: > "Mmh, I'm more and more getting into the chisel thing. I like it and maybe this gives me (and others, like my students) a productivity boost." > > Martin, > > I'd rather universities teach students how to get more productivity out of the existing, standard, tool-supported HDLs. The status quo, perhaps due to the required simplicity of class projects, is typically an HDL description written at barely above the netlist level anyway. Very little attention is typically paid to SW engineering principles that become critical (and extremely productive) on larger, more complex projects. If these principles and techniques are not taught to HW students, any productivity increases observed while merely changing languages will be marginal at best. At some point, the level of abstraction has to get beyond the current 'This is a register; these are some gates.' approach to HDL-based design, or it does not matter what language you use. > > "My thoughts about risk: yes, there is a risk with using a new not yet established language. However, three arguments against being afraid: (1) it is the design and not the description that counts. If you need to drop a tool/language, rewriting your design in a new language is not that much work." > > Does that "not much work" include re-writing your development processes and procedures, coding and review standards, development and verification plans, not to mention test benches? And is this true for most designs, or just the typical class project level designs? > > "(2) it uses Verilog as intermediate language. So the synthesize heavy lifting is done by the well established tools in a well established language." > > So when you get a synthesis error/warning, it refers you to the machine-generated, intermediate language code, which is cross-referenced to the original source code how? > > MyHDL takes this same approach (it actually produces both VHDL and Verilog to support synthesis and other tools). However, the MyHDL source is "elaborated" before the conversion to the supported HDLs, which means that if you have a parameterizable source module (that could have been kept parameterized in VHDL), you get a separate version of the HDL for every unique parameterization, thus further stretching the already tenuous connection between the source that is written, reviewed and maintained, and the HDL your synthesis tool is warning you about. > > "(3) it is open source. You can always contribute patches to the project to fix issues. If they are ignored you can still fork for your project to survive, although OS project forking is a bad idea. Cheers, Martin" > > The tool vendors are unlikely to support an HDL that has no controlled standard; it's too fluid a target to hit. Until it is controlled and tool-supported, its real-world productivity gains are practically zero, if not negative. > > Andy > No way, if they learn how to design and architect complex digital systems and are able to implement them successfully, regardless of the tool, I think the students will be prepared (this depends a lot on the definition of "successfully"). Of course the students will have a learning curve changing HDLs. But at this point they should have a good idea what the tools provide and do not provide. The greater risk is they will be frustrated not having the power and will quit :) Regards, ChrisArticle: 154918
On 2/13/2013 1:35 PM, jonesandy@comcast.net wrote: <snip> > MyHDL takes this same approach (it actually produces both VHDL and Verilog to support synthesis and other tools). However, the MyHDL source is "elaborated" before the conversion to the supported HDLs, which means that if you have a parameterizable source module (that could have been kept parameterized in VHDL), you get a separate version of the HDL for every unique parameterization, thus further stretching the already tenuous connection between the source that is written, reviewed and maintained, and the HDL your synthesis tool is warning you about. > > "(3) it is open source. You can always contribute patches to the project to fix issues. If they are ignored you can still fork for your project to survive, although OS project forking is a bad idea. Cheers, Martin" > > The tool vendors are unlikely to support an HDL that has no controlled standard; it's too fluid a target to hit. Until it is controlled and tool-supported, its real-world productivity gains are practically zero, if not negative. > > Andy > I have not found this to be an issue, mainly because I have no synthesis errors after simulating and cosimulating, the design works as expected. Yes, if for some reason you had many synthesis error tracing back would be more work than tracing to the Verilog/ VHDL source but I think it is minimal compared to the simulation and verification gains. Regards, ChrisArticle: 154919
"I have not found this to be an issue, mainly because I have no synthesis e= rrors after simulating and cosimulating, the design works as expected. Yes,= if for some reason you had many synthesis error tracing back would be more= work than tracing to the Verilog/ VHDL source but I think it is minimal co= mpared to the simulation and verification gains. Regards, Chris" Chris, I get very few synthesis "errors" during synthesis, and none by the time I'= m finished.=20 But I get lots of synthesis "warnings" and "notes" about what is getting op= timized out, what is being retimed, replicated, etc., even after a design s= imulates correctly. Simulating correctly and resulting in reliable hardware are not synonymous. If you have no synthesis notes/warnings about signals/registers getting opt= imized away, you are likely designing at an unproductively low level of abs= traction.=20 When you simulate, are you simulating in the source language, or the interm= ediate RTL? If at the intermediate RTL level, how are you tracing simulatio= n errors back to your source? If at the source level, how are you simulatin= g post-synthesis/P&R (gate level sims) with the same testbench? AndyArticle: 154920
On 2/13/2013 3:43 PM, jonesandy@comcast.net wrote: > "I have not found this to be an issue, mainly because I have no > synthesis errors after simulating and cosimulating, the design > works as expected. Yes, if for some reason you had many synthesis > error tracing back would be more work than tracing to the > Verilog/ VHDL source but I think it is minimal compared to the > simulation and verification gains. Regards, Chris" > > Chris, > > I get very few synthesis "errors" during synthesis, and none by the time I'm finished. > > But I get lots of synthesis "warnings" and "notes" about what is getting optimized out, what is being retimed, replicated, etc., even after a design simulates correctly. Impossible not to get millions of notes and warnings, the behavior of my final circuits match the behavior of my descriptions, they work in the field no complaints thus far. > > Simulating correctly and resulting in reliable hardware are not synonymous. I agree but two ASICs and a dozen successful FPGAs says what needs to be checked is checked and attention where attention is required. > > If you have no synthesis notes/warnings about signals/registers getting optimized away, As stated above, with all FPGA tools it is virtually impossible not to get numerous warnings and errors. As long as the tools don't change the behavior they can optimize away. > "you are likely designing at an unproductively low level of abstraction." I doubt that! > > When you simulate, are you simulating in the source language, or the intermediate RTL? If at the intermediate RTL level, how are you tracing simulation errors back to your source? If at the source level, how are you simulating post-synthesis/P&R (gate level sims) with the same testbench? I am simulating the source and cosimulating (meaning using my high-level HDL with the converted and/or synthesized HDL) and using the high-level verification environment to verify the converted matches the source. Optionally, will verify the post P&R (more so with the ASIC flow less so with FPGA). I am also able to leverage the same verification code in the lab, the code that tested the models also tests the logic in the lab. > > Andy > > >Article: 154921
Chris, Do you ignore synthesis notes and warnings, or do you cross-check at least = some of them?=20 There are precious few efficient ways to confirm "completeness" of the desi= gn verification effort. I cross-check my synthesis warnings as a secondary confirmation that someth= ing is not missed either in the design or in the verification. I can usuall= y tell from the warning, and knowledge of the design, whether it is a poten= tial problem or is acceptable/expected. I do not modify the design to elimi= nate acceptable/expected warnings (that would require designing at too low = a level of abstraction). It still takes a lot of time, but it has been very= effective, not only as a secondary confirmation of verification, but also = as an indication of where/not to improve performance or utilization to meet= requirements.=20 If I used an alternative HDL as source, then I'd have to trace the warnings= I could not immediately resolve back through the intermediate code to the = source. That takes more time, and from what I have seen, would not be offse= t by any improvmement in productivity provided by the alternative language.= =20 If I used verilog, I might have a different opinion.=20 However, where other languages, perhaps including these alternative HDLs, m= ay be more helpful is in the verification of the HDL design, regardless of = the HDL used (traditional or alternative). AndyArticle: 154922
On 2/14/2013 1:14 PM, jonesandy@comcast.net wrote: > Chris, > > Do you ignore synthesis notes and warnings, or do you cross-check at least some of them? No I don't ignore them, they are reviewed and certain ones are interrogated if deemed important. And determining if they are important is decided by the design engineer, same as you, they are aware of the design and "no problemo" referring back to the original source, if needed. > > There are precious few efficient ways to confirm "completeness" of the design verification effort. > > I cross-check my synthesis warnings as a secondary confirmation that something is not missed either in the design or in the verification. I can usually tell from the warning, and knowledge of the design, whether it is a potential problem or is acceptable/expected. I do not modify the design to eliminate acceptable/expected warnings (that would require designing at too low a level of abstraction). It still takes a lot of time, but it has been very effective, not only as a secondary confirmation of verification, but also as an indication of where/not to improve performance or utilization to meet requirements. > > If I used an alternative HDL as source, then I'd have to trace the warnings I could not immediately resolve back through the intermediate code to the source. That takes more time, and from what I have seen, would not be offset by any improvmement in productivity provided by the alternative language. > > If I used verilog, I might have a different opinion. > > However, where other languages, perhaps including these alternative HDLs, may be more helpful is in the verification of the HDL design, regardless of the HDL used (traditional or alternative). > > Andy > In this case the alternative HDL used is MyHDL, and MyHDL -in my experience- does not mangle the source enough to prohibit tracing back. As you indicated, it does have an "elaboration" phase but this has not been an issue (tracing back the generated VHDL or Verilog). I agree, the alternative HDL (because they are typically based on as general purpose high-level language) are ideal for modeling and verification. The V*s will always lag the other languages for general features. Regards, ChrisArticle: 154923
Dear all, as some of you know that the Artix 7 has no ODELAY so I can't handle my delays for the output. But there is a OSERDES as well with MMCM or the PLL to manage output pins with different phases e.g. My question is, how can I implement OSERDES fragments so that I can say please create a delay for 3ns before you send the signals.(I know there is a IPcatalog Manager, but I don't know how I can use it to creat a delay with it) Hope you can help me. Thank you very much.Article: 154924
Does anyone know why ModelSim version numbers skipped from 6.6 to 10, missing out 7, 8,and 9? Thanks in anticipation. --------------------------------------- Posted through http://www.FPGARelated.com
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