Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi, Please excuse me for sounding like I don't have a clue what I'm talking about. I am here because I want to learn. I have a project I have been working on that requires physical hardware. I will be getting someone to assist with building the hardware, but it will be up to me to programme it. Originally I was going to use a microcontroller, as I have C programming experience. After further investigation, I thought it would be a better idea to use an FPGA and do it all in hardware. The functionality is mainly I/O related, so hardware seems like a sensible choice. Why I am here is to seek some advise on which language to use, what software I will require, and how far I can get using open source or free software, before we actually need to build the hardware to test with. I am open minded about learning SystemC, VHDL, or Verilog in order to get this done. Which of these would allow me to get further, bearing in mind I need to write code, debug it, and eventually get it on to an FPGA, using (I assume) vendor-specific tools? SystemC seems like the obvious choice given it is based on C++, but there doesn't seem to be any clear description on how to get from SystemC code to an FPGA. Thanks, RL.Article: 124226
On Fri, 14 Sep 2007 13:33:08 +0100, Andrew Greensted <ajg112@ohm.york.ac.uk> wrote: >Symon wrote: > > Hi Andy, >> That's what I did on my last S3E design. I pulled PROG_B low through a >> schottky diode with a pullup to 2.5V at the FPGA. >> All that said, I would rely on the datasheet more than usenet! >> HTH, Syms. > >Cheers Symon, >My plan was to use one of those tiny-logic single gates, they've got 5V >tolerant inputs and can be by 2.5V. That should do the level conversion >nicely. >Andy That's good. Use a dual schmitt trigger, and clean up CCLK while you're there. Ringing on CCLK can be a real nuisance. JohnArticle: 124227
RL wrote:
> I have a project I have been working on that requires physical hardware.
> I will be getting someone to assist with building the hardware, but it
> will be up to me to programme it. Originally I was going to use a
> microcontroller, as I have C programming experience. After further
> investigation, I thought it would be a better idea to use an FPGA and do
> it all in hardware. The functionality is mainly I/O related, so hardware
> seems like a sensible choice.
You could bit-bang the IO from a microcontroller
parallel port. There is no reason to use an
FPGA unless the CPU is too slow.
> Why I am here is to seek some advise on which language to use, what
> software I will require, and how far I can get using open source or free
> software, before we actually need to build the hardware to test with.
If you have six months or less to finish this
consider deferring the HDL/FPGA learning process.
You can get a CPU board the uses GNU tools.
> I am open minded about learning SystemC, VHDL, or Verilog in order to
> get this done. Which of these would allow me to get further, bearing in
> mind I need to write code, debug it, and eventually get it on to an
> FPGA, using (I assume) vendor-specific tools?
If you go the FPGA route, use vhdl or verilog.
> SystemC seems like the obvious choice given it is based on C++, but
> there doesn't seem to be any clear description on how to get from
> SystemC code to an FPGA.
Add a year to your schedule and lots of $ to your budget for this.
-- Mike Treseler
Article: 124228RL wrote: > Hi, > > Please excuse me for sounding like I don't have a clue what I'm talking > about. I am here because I want to learn. > > I have a project I have been working on that requires physical hardware. > I will be getting someone to assist with building the hardware, but it > will be up to me to programme it. Originally I was going to use a > microcontroller, as I have C programming experience. After further > investigation, I thought it would be a better idea to use an FPGA and do > it all in hardware. The functionality is mainly I/O related, so hardware > seems like a sensible choice. > > Why I am here is to seek some advise on which language to use, what > software I will require, and how far I can get using open source or free > software, before we actually need to build the hardware to test with. Xilinx and Altera both provide free-as-in-beer toolchains, though you will have to buy or build a jtag cable dongle to connect to actual hardware. Also, there are development boards of all different sizes that might allow you to avoid or postpone building you own hardware. See the FAQ for comprehensive lists of these. > I am open minded about learning SystemC, VHDL, or Verilog in order to > get this done. Which of these would allow me to get further, bearing in > mind I need to write code, debug it, and eventually get it on to an > FPGA, using (I assume) vendor-specific tools? > > SystemC seems like the obvious choice given it is based on C++, but > there doesn't seem to be any clear description on how to get from > SystemC code to an FPGA. The particular syntax and semantics of VHDL or Verilog will not be a problem if you are already comfortable with software languages, though I would avoid SystemC if only because no free tools support it AFAIK. Knowing how the subset of the language that is synthesizable maps to real hardware is usually more of an issue, which is where the big learning curve is if you are new to hardware design. -JeffArticle: 124229
Hi, In a Virtex II pro design operating at 250 MHz, the FPGA interfaces to an ADC, does some preliminary signal processing, and transmits data to a DSP upon having filled a local buffer with data. The FPGA is the lowest speed grade in the family and I've been tasked with making the design works no matter what. Our data with is 10 bits. Part of a detection criteria, samples have to be screened before being admitted to further processing. This involves making sure that data is above certain threshold. Now, right in the middle of the dynamic range of the sample width, when I subtract the threshold value from that sample, a momentary glitch appear on the tenth bit making it impossible to tell whether the difference is positive or negative. Because the sampled data corresponds to physical entity that is naturally limited in bandwidth, this transition of sign occurs rather smoothly. Thus I managed to butcher my way through by omitting thresholding on this very case in which a reversal of sign occurs. The caveat obviously is not logging this particular transition sample. So though the design works for now, I was wondering whether there exists a more elegant/clever solution around this. Many thanks, -ManiArticle: 124230
"RL" <rl@null.void.test> wrote in message news:fcf5so$pu1$1@lust.ihug.co.nz... > Hi, > > Please excuse me for sounding like I don't have a clue what I'm talking > about. I am here because I want to learn. > > I have a project I have been working on that requires physical hardware. I > will be getting someone to assist with building the hardware, but it will > be up to me to programme it. Originally I was going to use a > microcontroller, as I have C programming experience. After further > investigation, I thought it would be a better idea to use an FPGA and do > it all in hardware. The functionality is mainly I/O related, so hardware > seems like a sensible choice. > > Why I am here is to seek some advise on which language to use, what > software I will require, and how far I can get using open source or free > software, before we actually need to build the hardware to test with. > > I am open minded about learning SystemC, VHDL, or Verilog in order to get > this done. Which of these would allow me to get further, bearing in mind I > need to write code, debug it, and eventually get it on to an FPGA, using > (I assume) vendor-specific tools? > > SystemC seems like the obvious choice given it is based on C++, but there > doesn't seem to be any clear description on how to get from SystemC code > to an FPGA. As adviced by others you can make your life easier and save some money by using VHDL or Verilog. However, SystemC doesn't have to be ruled out if you prefer to go down that route but it will require some financial investment and a thorough evaluation. As you probably know the simulation tools are free but synthesis is the real budget killer. Have a look at SystemCrafters which sells a low-cost SystemC synthesis tool. I have no association with this company but the price looks interesting :-) http://www.systemcrafter.com/index.php Hans www.ht-lab.com > > Thanks, > > RL.Article: 124231
Jeff Cunningham <jcc@sover.net> wrote: >RL wrote: >> Hi, >> >> Please excuse me for sounding like I don't have a clue what I'm talking >> about. I am here because I want to learn. >> >> I have a project I have been working on that requires physical hardware. >> I will be getting someone to assist with building the hardware, but it >> will be up to me to programme it. Originally I was going to use a >> microcontroller, as I have C programming experience. After further >> investigation, I thought it would be a better idea to use an FPGA and do >> it all in hardware. The functionality is mainly I/O related, so hardware >> seems like a sensible choice. >> >> Why I am here is to seek some advise on which language to use, what >> software I will require, and how far I can get using open source or free >> software, before we actually need to build the hardware to test with. > >Xilinx and Altera both provide free-as-in-beer toolchains, though you >will have to buy or build a jtag cable dongle to connect to actual >hardware. Also, there are development boards of all different sizes that That is not entirely true. It is very easy to use a microcontroller to load the FPGA contents either parallel or serial (SPI). -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 124232
On 15 Sep, 00:36, RL <r...@null.void.test> wrote: ... > Why I am here is to seek some advise on which language to use, what > software I will require, and how far I can get using open source or free > software, before we actually need to build the hardware to test with. >From one beginner to another I found http://www.digilentinc.com/ a good place to start. As well as selling development boards they link to comprehensive development environment software from Xilinx. The Xilinx software and a Xilinx version of the Modelsim simulator are both free. Digilent also have downloadable videos on how to use the Xilinx- provided software. This is a boon to show which options to use as the software itself has many features. You need to know which ones to use to get started. The current software interface is slightly different from that shown in the videos but it is possible to work out with a bit of patience. > I am open minded about learning SystemC, VHDL, or Verilog in order to > get this done. Which of these would allow me to get further, bearing in > mind I need to write code, debug it, and eventually get it on to an > FPGA, using (I assume) vendor-specific tools? > > SystemC seems like the obvious choice given it is based on C++, but > there doesn't seem to be any clear description on how to get from > SystemC code to an FPGA. You probably know Verilog has C syntax. Using the above software you can test either VHDL or Verilog without programming the FPGA. Digilent's Basys board will program by USB so is a doddle. The board can also be powered by USB or by an external single volt supply. There may be other good suppliers. I don't know. I found Digilent first and they had what I wanted. YMMV. I have no connection with them. -- JamesArticle: 124233
Manny wrote: > Hi, > > In a Virtex II pro design operating at 250 MHz, the FPGA interfaces to > an ADC, does some preliminary signal processing, and transmits data to > a DSP upon having filled a local buffer with data. The FPGA is the > lowest speed grade in the family and I've been tasked with making the > design works no matter what. Our data with is 10 bits. > > Now, right in the middle of the dynamic range > of the sample width, when I subtract the threshold value from that > sample, a momentary glitch appear on the tenth bit making it > impossible to tell whether the difference is positive or negative. > Because the sampled data corresponds to physical entity that is > naturally limited in bandwidth, this transition of sign occurs rather > smoothly.[...] > > So though the design works for now, I was wondering whether there > exists a more elegant/clever solution around this. > > Many thanks, > -Mani If you see glitches, you probably omitted a register stage somewhere. You need to make sure you have the IOB FFs on the DAC data bus, you need another set of FFs on this input path within your threshold detection block, yet another for your block's output and you would probably do well to break your substraction in two or three pipelined stages since 250MHz is pretty tight for V2P. A glitch on the 10th bit indicates that the carry chain is a little too slow/long for your target operating period so you need to pipeline this subtraction at least one step further than you may already have. Since you did not describe your design's structure, I have no idea how much of this you have already done.Article: 124234
Barry, Let me see if I can help, -snip- > It seems that I can generate all of these with one PLL. Yes, the clock tile is quite versatile, and often, user's do not realize than they can provide all of their timing from one tile's outputs, all at once. The V5 User's > Guide UG190 seems to recommend routing CLKFBOUT through a BUFG to > CLKFBIN (fig 3-10). Or I think I could use the CLK0 BUFG output as > the CLKFBIN signal, and save a BUFG by not using CLKFBOUT. BUFG's are all matched, so if phase accuracy is required, use them. They do use more power than a direct connection, but the clock tree only "lights up" (powers) the branches of the H-tree that are used, so power is also carefully managed. If a tool like Plan-Ahead is used, and logic for a clock domain is kept within a region, lower clocking power is one of the benefits. > Is there any reason to prefer CLKFBOUT over CLK0 to get zero skew? The DCM uses a tapped delay line, with minimum tap sizing as specified in the datasheet. The PLL uses a conventional VCO. Your choice. The PLL has virtually no cycle to cycle jitter, and also does filter jitter on its input. Phase accuracy is dominated by matching resources (obviously variations in process means there is no such thing as a perfect match - again see the datasheet). > Are CLK2 and CLK3 going to be fine for the MIG DDR2 controller? Is > the PLL's 90 degree difference just as accurate as that of a DCM? Again, yes. The accuracy is dominated by matched resource mis-match, and phase detector offset (imperfections in the phase detectors, used by both the all-digital DCM, and analog PLL). Hope that helps, AustinArticle: 124235
Hi -
On Sat, 15 Sep 2007 11:36:35 +1200, RL <rl@null.void.test> wrote:
>Hi,
>
>Please excuse me for sounding like I don't have a clue what I'm talking
>about. I am here because I want to learn.
>
>I have a project I have been working on that requires physical hardware.
>I will be getting someone to assist with building the hardware, but it
>will be up to me to programme it. Originally I was going to use a
>microcontroller, as I have C programming experience. After further
>investigation, I thought it would be a better idea to use an FPGA and do
>it all in hardware. The functionality is mainly I/O related, so hardware
>seems like a sensible choice.
>
>Why I am here is to seek some advise on which language to use, what
>software I will require, and how far I can get using open source or free
>software, before we actually need to build the hardware to test with.
>
>I am open minded about learning SystemC, VHDL, or Verilog in order to
>get this done. Which of these would allow me to get further, bearing in
>mind I need to write code, debug it, and eventually get it on to an
>FPGA, using (I assume) vendor-specific tools?
>
>SystemC seems like the obvious choice given it is based on C++, but
>there doesn't seem to be any clear description on how to get from
>SystemC code to an FPGA.
Mike Treseler has already addressed the issue of whether a
microcontroller solution might not be more suitable (I suspect it is),
so I'll set that aside.
There's one issue that's more important than languages, tools, and the
like, to wit:
Do you know how to do digital design? In particular,
- Do you know the principles of synchronous logic design?
- Do you know how to reliably initialize a digital circuit?
- Do you know how to analyze a timing path?
- Do you know how to move signals between mutually asynchronous clock
domains?
- Do you know how to handle digital signals at the FPGA I/O? Do you
understand the fundamentals of different digital interface standards?
(I'm talking about the simple stuff, like what qualifies as a valid
HIGH or LOW for a 3.3V logic signal, or how to interface a 5V domain
to a 3.3V domain). Do you know how to use signal terminations to
guarantee good signal quality?
And I'm just scratching the surface.
You are embarking on a hardware design, not a programming exercise.
Hardware design skills are essential, no matter what the SystemC
brochure says.
Maybe this is coming across as unduly harsh; that's not my intent. All
of us hardware designers were newcomers at one point, so folks
starting out in hardware design today deserve our support. But I'd
really, really like to drive a stake in the heart of the "designing
FPGAs is programming" meme.
Bob Perlman
Cambrian Design Works
http://www.cambriandesign.com
Article: 124236> A glitch on the 10th bit indicates that the carry chain is a little too > slow/long for your target operating period so you need to pipeline this > subtraction at least one step further than you may already have. I've already done that. Obviously the logic requires two clock cycles for thresholding immediately when the 10th bit changes sign, which means that the first sample is missed. This isn't terribly bad as the slow physical pluse has enough samples in the rising edge to get caught properly. Thanks for the input Daniel, just wanted to make sure that I'm approaching this in the right way. I don't know why would people want to use v2pro these days. Managers usually decide on the system's components and we have to live with the consequences of that. Regards, -MannyArticle: 124237
Hi, Thanks to everyone who responded. I'm still undecided on which path to take for this particular project, but I've spent about two hours so far going through a VHDL tutorial. It is starting to make sense, so at least I will have a better idea of what is going on in the rest of the hardware. A few comments for Bob below... > Mike Treseler has already addressed the issue of whether a > microcontroller solution might not be more suitable (I suspect it is), > so I'll set that aside. I should have mentioned, I am driving this development, and from my point of view spending six months refining my VHDL skills wouldn't be a major issue if the end result is going to justify this. > There's one issue that's more important than languages, tools, and the > like, to wit: > > Do you know how to do digital design? In particular, > > - Do you know the principles of synchronous logic design? > - Do you know how to reliably initialize a digital circuit? > - Do you know how to analyze a timing path? > - Do you know how to move signals between mutually asynchronous clock > domains? > - Do you know how to handle digital signals at the FPGA I/O? Do you > understand the fundamentals of different digital interface standards? > (I'm talking about the simple stuff, like what qualifies as a valid > HIGH or LOW for a 3.3V logic signal, or how to interface a 5V domain > to a 3.3V domain). Do you know how to use signal terminations to > guarantee good signal quality? > > And I'm just scratching the surface. > > You are embarking on a hardware design, not a programming exercise. > Hardware design skills are essential, no matter what the SystemC > brochure says. I may be completely wrong about this, so feel free to comment. My intention is to only work on what is going on internally within the FPGA (or CPU), and only the core logic to make it do what it has to do. The actual interfacing to other electronic components will be handled by someone with more knowledge than myself. I will be mainly concerned with the internal logic of what happens when external events occur (in this case, button presses, serial communications, and one clock). Any electronics knowledge I once had was a decade ago, so I'm starting out with very little. From a point of view of interpreting the input and getting the output I want, dealing only with 0s and 1s, I don't think I'm taking on too much. If I use a CPU, I need to read and write binary values that the supporting electronics has to handle. If I used VHDL, I need to design hardware to do certain things when values change, and set output accordingly. The approaches are different, but taking the black box approach, inputting and outputting binary values, both should work equally well. I can see some major advantages doing this in VHDL. Yes, I have more to learn, but I wouldn't have to worry about interrupts and race conditions. In theory, and again I may be wrong, I should be able to be more confident that the FPGA does what I expect, when I expect it to. > Maybe this is coming across as unduly harsh; that's not my intent. All > of us hardware designers were newcomers at one point, so folks > starting out in hardware design today deserve our support. But I'd > really, really like to drive a stake in the heart of the "designing > FPGAs is programming" meme. This is actually part of the reasoning behind selecting VHDL in preference to SystemC. With SystemC, I could see there would be a tendency to fall back to the familiar style of programming used for software development. Hardware is a completely different concept and should be treated as such. Thanks again for your comments and suggestions. RLArticle: 124238
Hello, I'm trying to hash through application XAPP806 "Determining the Optimal DCM Phase Shift for the DDR Feedback Clock" as an exercise in MicroBlaze, EDK, BSB, Platformw Studio, XPS, whatever. About page 3 the document ask you to set up a 2 bit GPIO. I'm not sure why it needs to be bidirectional. These bits are to be the controls to the variable phase delay in the clock feedback loop. Being a novice with this Platform Studio, I don't know how to do this. In the BSB wizard under add peripherals, all I have are OPB BRAM IF CNTLR, OPB TIMEBASE WDT, and OPB TIMER options. I am running an 7.1 EDK and the author of the document, Norbert Melnikov, did not state what he was using. So the short question is where do I find the generic GPIO pcore? The application note implied that the number of bits was selectable. Does the P in pcores stand for peripheral? Are pcores the way ISE projects can join the XPS environment? Thanks, Brad Smallridge Ai VisionArticle: 124239
Hi RL, >Hardware is a completely different concept and > should be treated as such. I agree with you there. But then you go on to say: >The approaches are different, but taking the black box > approach, inputting and outputting binary values, both should work > equally well. Which I agree with in the sense that both the cpu and fpga can probably do what you want assuming we are not talking about high speed IO or very heaving processing. But I disagree in the sense that in general, when developing for a cpu one is describing your design in C/C ++, whereas for FPGA its VHDL and its digital logic design. C/C++ is at a higher level of abstraction than VHDL/digital design. For this type of "control" problem, the average engineer familiar with both the C and VHDL toolsets will be able to complete the C design in much less time than the VHDL one. Maybe a factor of 10 or more depending on the complexity of the control problem. With VHDL you are working at a much lower level. I suppose its even lower than assembly code if you wanted a comparison. Since you havn't done electronics for a while, I would recommend the C/ cpu approach and leave the FPGA until a more appropriate project comes up? Cheers Andrew On Sep 16, 8:04 am, RL <r...@null.void.test> wrote: > Hi, > > Thanks to everyone who responded. I'm still undecided on which path to > take for this particular project, but I've spent about two hours so far > going through a VHDL tutorial. It is starting to make sense, so at least > I will have a better idea of what is going on in the rest of the hardware. > > A few comments for Bob below... > > > Mike Treseler has already addressed the issue of whether a > > microcontroller solution might not be more suitable (I suspect it is), > > so I'll set that aside. > > I should have mentioned, I am driving this development, and from my > point of view spending six months refining my VHDL skills wouldn't be a > major issue if the end result is going to justify this. > > > > > There's one issue that's more important than languages, tools, and the > > like, to wit: > > > Do you know how to do digital design? In particular, > > > - Do you know the principles of synchronous logic design? > > - Do you know how to reliably initialize a digital circuit? > > - Do you know how to analyze a timing path? > > - Do you know how to move signals between mutually asynchronous clock > > domains? > > - Do you know how to handle digital signals at the FPGA I/O? Do you > > understand the fundamentals of different digital interface standards? > > (I'm talking about the simple stuff, like what qualifies as a valid > > HIGH or LOW for a 3.3V logic signal, or how to interface a 5V domain > > to a 3.3V domain). Do you know how to use signal terminations to > > guarantee good signal quality? > > > And I'm just scratching the surface. > > > You are embarking on a hardware design, not a programming exercise. > > Hardware design skills are essential, no matter what the SystemC > > brochure says. > > I may be completely wrong about this, so feel free to comment. > > My intention is to only work on what is going on internally within the > FPGA (or CPU), and only the core logic to make it do what it has to do. > The actual interfacing to other electronic components will be handled by > someone with more knowledge than myself. I will be mainly concerned with > the internal logic of what happens when external events occur (in this > case, button presses, serial communications, and one clock). > > Any electronics knowledge I once had was a decade ago, so I'm starting > out with very little. From a point of view of interpreting the input and > getting the output I want, dealing only with 0s and 1s, I don't think > I'm taking on too much. > > If I use a CPU, I need to read and write binary values that the > supporting electronics has to handle. If I used VHDL, I need to design > hardware to do certain things when values change, and set output > accordingly. The approaches are different, but taking the black box > approach, inputting and outputting binary values, both should work > equally well. > > I can see some major advantages doing this in VHDL. Yes, I have more to > learn, but I wouldn't have to worry about interrupts and race > conditions. In theory, and again I may be wrong, I should be able to be > more confident that the FPGA does what I expect, when I expect it to. > > > Maybe this is coming across as unduly harsh; that's not my intent. All > > of us hardware designers were newcomers at one point, so folks > > starting out in hardware design today deserve our support. But I'd > > really, really like to drive a stake in the heart of the "designing > > FPGAs is programming" meme. > > This is actually part of the reasoning behind selecting VHDL in > preference to SystemC. With SystemC, I could see there would be a > tendency to fall back to the familiar style of programming used for > software development. Hardware is a completely different concept and > should be treated as such. > > Thanks again for your comments and suggestions. > > RLArticle: 124240
Andrew FPGA wrote: > IO or very heaving processing. But I disagree in the sense that in > general, when developing for a cpu one is describing your design in C/C > ++, whereas for FPGA its VHDL and its digital logic design. C/C++ is > at a higher level of abstraction than VHDL/digital design. For this I think this point is often missed by people coming from the software side. HDL synthesis is more like a macro assembler for hardware than a high level language. As such, you really need to know basic hardware design to get good results. -JeffArticle: 124241
Nico Coesel wrote: > Jeff Cunningham <jcc@sover.net> wrote: > >> Xilinx and Altera both provide free-as-in-beer toolchains, though you >> will have to buy or build a jtag cable dongle to connect to actual >> hardware. Also, there are development boards of all different sizes that > > That is not entirely true. It is very easy to use a microcontroller to > load the FPGA contents either parallel or serial (SPI). fair enough. how would you load the microcontroller? -JeffArticle: 124242
"RL" <rl@null.void.test> wrote in message news:fchdql$2nq$1@lust.ihug.co.nz... > Hi, > .. snip > > This is actually part of the reasoning behind selecting VHDL in preference > to SystemC. With SystemC, I could see there would be a tendency to fall > back to the familiar style of programming used for software development. > Hardware is a completely different concept and should be treated as such. I don't want to turn into a SystemC evangelist but SystemC supports the same low-level RTL constructs as Verilog or VHDL. The language supports processes, sensitivity lists, wait statements, resolved/unresolved signals, variables, delta cycles, positional/named instantiations, 'X'/'Z' values, hierarchy, IO ports etc. Obviously the language is not intended to be used at the synthesisable RTL level but if you want to use it at this level you can. Good luck with your project, sound like fun, Hans www.ht-lab.com > > Thanks again for your comments and suggestions. > > RLArticle: 124243
Andy wrote: (snip, someone wrote) >>Or better, how much smaller the success story of FPGAs > would have been without the use of pass transistors in LUTs > and routing? > I think you're confusing the product of an ASIC and an FPGA. ASICs are > limited to "standard" cell devices, because the tools have to be > easily applicable (and verifiable!) to a wide variety of situations. > An FPGA (the virgin part, not the programmed application) is more like > a high-end processor, with much larger volumes to support dedicated > designs using "non-standard" features. I'm sure you'd find similar > tricks in any large, high-volume, fully custom, digital IC. I am sure this used to be true, but I would expect it to be less true today. In the early microprocessor days, every last transistor had to be counted. Intel used dynamic logic for many processors, including the 8080 and 8086. (That results in a minimum clock frequency.) Pass transistors were also common at the time. As the supply voltage gets lower, it is more difficult to use pass transistor. -- glenArticle: 124244
Brian Davis wrote: > Have a look at pages 101-121 of: > http://www.xilinx.com/products/spartan3e/sp3e_power.pdf Ahh yes, I think that one got lost in the pile of datasheets.Very handy John Larkin wrote: > That's good. Use a dual schmitt trigger, and clean up CCLK while > you're there. Ringing on CCLK can be a real nuisance. Good plan. Thanks both AndyArticle: 124245
hello to everyone, im a newbie in using spartan 3e kit...Is it possible for the spartan 3e kit to store an audio sounds like wav file or mp3 file?Article: 124246
Hi I recently have designed some simple FPGA application. Now i need research on optimizing power in FPGA design. I have found many document but none of them are in detail. I need free document and especially opensource code (or only detail step) that implement a power optimize algorithm (at any design level). So I hope that someone can help me with usefull links Thanks a lotArticle: 124247
Dear friends,
I am very pleased and proud to announce YARDstick (http://
electronics.physics.auth.gr/people/nkavv/yardstick), a custom
processor development toolset with an impressive list of features.
YARDstick is a novel design automation tool for custom processor
development flows that focuces on the hard part: generating and
evaluating application-specific hardware extensions. YARDstick is a
powerful building block for ASIP development, since it integrates
application analysis, ultra-fast algorithms for custom instruction
generation and selection with user-defined compiler intermediate
representations. As of September 2007, YARDstick integrates
retargetable compiler features for the targeted IRs/architectures.
Remarkable features of YARDstick are the following:
- retargetable to used-defined IRs by machine description.
- can be targeted to low-level compiler IRs, assembly-level
representations of virtual machines, or assembly code for existing
processors.
- fully parameterized custom instruction generation and selection
engine.
- lightning-fast code selector for multiple-input multiple-output
patterns based on graph matching. It is known that the code selector
scales very well with the instruction node count of basic block data-
dependence graphs (successfully tested with custom instruction
patterns of more than 30 nodes).
- virtual register assignment for virtual machine targets.
- an extensive set of backends including assembly code emitter, C
backend, visualization backends for Graphviz and VCG (or aiSee), an
XML format amenable to graph rewriting and others.
YARDstick comes along with a cross-platform GUI written in Tcl/Tk 8.5.
The ultimate goal of YARDstick is to liberate the designer's
development infrastructure from compiler and simulator idiosyncrasies.
With YARDstick, the ASIP designer is empowered
with the freedom of specifying the target architecture of choice and
adding new implementations of analyses and custom instruction
generation/selection methods.
At this moment, YARDstick is being heavily used for developing a new
processor architecture of mine with many never-being-seen features,
mostly aiming FPGAs. Status update report on the processor
architecture should be expected near late October 2007.
Typically, 2x to 15x speedups for benchmark applications (ANSI C
optimized source code) can be fully automatically obtained by using
YARDstick depending on the target architecture. Speedups are evaluated
against a typical scalar RISC architecture.
Detailed feature list:
1. Analysis engines generating both static and dynamic statistics:
- Data types
- Operation-level statistics
- Basic block statistics (ranking)
- Performance estimations with/without custom instructions.
2. Generation of CDFGs (Control-Data Flow Graphs).
3. Backend engines:
- ANSI C
- dot (Graphviz)
- VCG (GDL, aiSee)
- XML (GGX for the AGG graph rewriting tool)
- Retargetable assembly emitter for entire translation units
(single files with multiple functions/procedures).
- CDFG formats for various RTL synthesis tools.
4. Custom instruction engines:
- Full-parameterized MIMO custom instruction generation algorithm.
Features:
* Fast heuristic !!!
* Configurable number of inputs
* Configurable number of outputs
* List of forbidden nodes
* Node sorting strategies (3 different strategies!)
* Transformation rule library for applying CFG transformation
strategies
5. Custom instruction selection:
- Based on priority metrics (2 choices at the moment).
6. Graph (and graph-subgraph) isomorphism features for eliminating
redundant patterns. Multiple algorithms supported.
7. Visualization of custom instructions, basic blocks, control-flow
graphs and control-data flow graphs (basic block nodes expanded to
their constituent instructions).
8. Basic retargetable compiler features (alpha state):
- Code selector for MIMO instructions (tested with large cases).
- Virtual register assignment (allocation for a VM).
- Hard register allocator in the works.
9. Miscellaneous features:
- single constant multiplication optimizer
- elimination of false data-dependences in assembly-level CDFGs.
- beautification options for visualization
- interfacing (co-operation) with external tools such as peephole
optimizers, profilers, code generators etc.
- features related to the custom processor architecture (not to be
disclosed yet)
Here is a list of application benchmarks that have been tested with
YARDstick (compiler
features not fully tested):
- ADPCM encoder and decoder (typically: 4x speedup)
- Video processing kernels: full-search block-matching motion
estimation, logarithmic search motion estimation, motion compensation
- Image processing kernels: steganography (hide/uncover), edge
detection, matrix multiplication
- Cryptographic kernels: crc32, rc5, raiden (7x speedup, 12x for
unrolled version)
At the YARDstick homepage (http://electronics.physics.auth.gr/people/
nkavv/yardstick/) you can find some additional material:
- 2-page brochure
- 2-page abstract for the DATE'07 University Booth
- a more extended presentation on YARDstick
The above material refers to the status of April 2007.
Expected enhancements to YARDstick in the near future:
- linear-scan and integer-linear programming based register
allocators
- bitwidth analysis
- CDFG->VHDL generation of custom instruction hardware
- algorithm implementation for CDFG pipelining
Interested parties are welcome to contact me for details on how to get
access
to a demo version of the YARDstick toolset.
Kind regards
Nikolaos Kavvadias
Computer Architecture Specialist - Compiler Developer
Ph.D. candidate
M.Sc. Eletronics Engineering
B.Sc. Physics
You may contact me at:
Nikolaos Kavvadias <nkavv@physics.auth.gr>
http://www.geocities.com/kaveirious/
http://electronics.physics.auth.gr/tomeas/en/kavvadias.html
Article: 124248The URL: http://electronics.physics.auth.gr/people/nkavv/yardstick/ This will link directly for all.Article: 124249
<carlmorada@gmail.com> wrote in message news:1189939782.072927.66770@k79g2000hse.googlegroups.com... > hello to everyone, > > im a newbie in using spartan 3e kit...Is it possible for the spartan > 3e kit to store an audio sounds like wav file or mp3 file? > Let size of wav/mp3 file = x Let available RAM on spartan 3e kit = y if y >= x then yes, else no
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