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
Matthew let me argue for peace: It all depends on your roots. If you started out as a logic designer (like I did), then you see the FPGA as a wonderful way to design a production-worthy breadboard of terrific complexity and very good performance. God's gift to the logic designer, good-bye wire-wrap! I think in terms of block diagrams, and use VHDL/Verilog to manage the design process. I would never be in doubt about the choice of binary vs decimal, or fixed vs floating point, because they have such enenormous impact on the design efficiency. If you start out as a computer programmer, then you design=program the way this thread was started, totally oblivious of hardware constraints and limittions. Let the synthesizer worry about those details! The trouble is that these unworthy details can impact the design by an order of magnitude in size=cost and performance. You will never beat the urge for economy, performance, and design elegance out of us hardware guys. Maybe one day FPGAs will become so big and cheap and fast that it does not matter anymore. Well, hopefully there will always be Social Security. And St. Peter might show mercy with us former pip-pokers genus schemato-saurus. Peter Alfke On Mar 4, 12:12 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote: > First, to address the question, you're not really doing multiplication but > performing division through multiplication with decimals. ISE doesn't do > division either way. Like John_H said, scale your numbers up (refer to fixed > point numbers) so multiplication is done with integers. When done, just > scale the result down by the same amount for the final answer. A hint is > to scale the numbers by a power of 2 so you just have to do bit shifts. > > Second, I would like to give my two cents on John_H's 1990's attitude. You > shouldn't tell someone to read up on vendor specific blocks when it is clear > that they are just starting out, doesn't need an optimal implementation, > and don't have a firm grasp on the basics. You should give them a very simple > and concise explanation at their level and a fix at their level. The synthesizer > is more than capable of handling the * symbol, the OP doesn't need to worry > about what Xilinx puts on the hood. If Xilinx were smart and had good programmers, > which it seems they are trying to work towards, no one would need to know > of any of the blocks under the hood. People should be able to "program" > the hardware. The synthesis program should be smart enough to use the blocks > under the hood to provide a near optimal implementation of the "program". > There is a reason why people use high level programming languages not assembly. > For everyone's sake, "designing" a system on an FPGA shouldn't be hard. > > ---Matthew Hicks > > > VHDL_HELP wrote: > > >> Hi every body , > >> i hope that you can help me , i want to do this operation: > >> s = c1 * 0.2+ c2 * 0.6 + c3 * 0.1 > >> when i check the syntax , i have these errors > >> ERROR:HDLParsers:808 - "C:/Xilinx/projet/operation.vhd" Line 44. * > >> can > >> not have such operands in this context. > >> --------------------------------------------------------------------- > >> --------------------------------------------------------------------- > >> ---------------------- > > >> library IEEE; > > >> use IEEE.STD_LOGIC_1164.ALL; > > >> use IEEE.STD_LOGIC_ARITH.ALL; > > >> use IEEE.STD_LOGIC_UNSIGNED.ALL; > > >> entity operation is > >> Port ( clk : in STD_LOGIC; > >> c1 : in STD_LOGIC_VECTOR (7 downto 0); > >> c2 : in STD_LOGIC_VECTOR (7 downto 0); > >> c 3: in STD_LOGIC_VECTOR (7 downto 0); > >> s: out STD_LOGIC_VECTOR (7 downto 0); > >> end operation; > > >> architecture Behavioral of operation is > > >> begin > > >> s <=c1 * 0.2 + c2 * 0.6 + c3 * 0.1 ; > > >> end Behavioral; > > >> --------------------------------------------------------------------- > >> --------------------------------------------------------------------- > >> ---------------- > > >> and thanks for your help > > > Can you tell me how the synthesizer will format your floating point > > result in s so it maps to silicon? > > > Use scaled integers. Use the precision available in the hardware > > multipliers to get a rather precise approximation of s. The digital > > realm is binary, after all, not decimal. > > > Please read up on how the hardware multipliers perform and how best to > > utilize them. It's insanely sad to see someone trying to "program" an > > FPGA rather than design it.Article: 116201
Austin wrote: > Marc, > > Other than their odd name, they are extremely low impedance t-lines. > > As such, they are basically falt at 1200 uF from DC to daylinght. > > So, if you put a power supply at one end, and isolate the ground (in > other words, that is what the slit is for) you transfer power to the > other end (hot and ground) with a .001 ohm t-line (looks like that very > low impedance at frequencies up to a few hundred MHz). > > So, now you see a AC short, looking either way: from the power asupply > to the load, or from the load to the power supply. > > The Playstation 3 uses 8 of them, they isolate each huge ASIC from the > other huge ASICs, and there are3 NO OTHER CAPS on the pcb.... > > Yes, that is right. > > Whereas the Wii has > 300 little caps, PS3 has these 8 "magic" t-line > structures. > > Do they work? Well, millions of PS3 aren't chunking away happily for no > reason at all. > > We are looking at these seriously to reduce the bypassing requirements > down to the PS3 limit: a few of these, and NOTHING else (no other > bypass caps whatsoever). To make best use of these, you may need to redo the power supply fanout on the FPGAs. Or, include them IN the package :) I could, for example, see merit in allowing a BALL-Free area on the BGA, designed to allow one of these to mount under the FPGA, on the opposite side. > So, it seems the NEC-TOKIN part is the first really new invention in > bypassing in many many long years of people who just like to ignore that > power distribution is a real issue, and one that needs some creativity. > > My hat is off to the engineers who created this wonder. These are a SMD variant of T filter/feed thru networks, and a variant on 3 terminal SMD capacitors. In all those, the power is passed THRU the decoupling element (so they have a mOhm spec as well ), and it means there is no series L that kills most trace+via+cap decouplers. Such feed-thru decouplers, are also very good at keeping noise where it belongs : their plots show very good localisation of the noise, but also seem to show higher levels at 'die-central', than when using the more distributed decoupling. See my comment above, about using one of these underneath the BGA, on the rear of the PCB. I also see their (impressive) impedance plots, are the devices themselves, and there is no mention of VIA patterns, or trace fanout limits. -jgArticle: 116202
Hi! I have also been quite frustrated by XST BRAM inference in the past... and have yet to get XST to do what I want. If you go check the XST "coding style guide" which contains VHDL templates for inferring most of the supported BRAM types, you might find exactly what you want. In my case, I wanted to infer "True dual-port BRAMs" but copy-pasting the guide's template (ISE 8.1/8.2) consistently resulted in XST crashes. After wasting a week trying to work this out last summer, I decided to give up and used a coregen RAM. More details about my experience with the true dual-port BRAM template: - pasting the code in the module's VHDL causes unrecognized BRAM inference warnings, causing XST to attempt implementation with distributed RAM - whipping up the template into its own module and synthesizing it as a top module works as advertised/expected - instantiating the BRAM template module in an actual design crashes XST S.T. wrote: > Hi > > Thanks for your feedback. Unfortunately both suggestions didn't work :-(. > When removing the Reset path the synthesized ram will get dual ported > instead of single ported (see below). I tried to rewrite it and make the > read and write enable signals explicit and decoupling the reset from ram. > It also doesn't work i.e. it still gives distributed instead of block > ram :-(. > Synthesizing Unit <BRAM_test>. > Related source file > is "/amd/iss1/users/ma/tstone/georg/bram/BRAM_test.vhd". > Found 1024x16-bit single-port distributed RAM for signal <RAM>. > ----------------------------------------------------------------------- > | ram_style | block | | > ----------------------------------------------------------------------- > | Port A | > | aspect ratio | 1024-word x 16-bit | | > | clkA | connected to signal <CLOCK> | rise | > | weA | connected to internal node | high | > | addrA | connected to signal <addr> | | > | diA | connected to signal <di> | | > | doA | connected to internal node | | > ----------------------------------------------------------------------- > WARNING:Xst:1440 - Cannot use block RAM resources. Please check that the RAM > contents is read synchronously. > > >Article: 116203
On Feb 9, 12:48 am, Johan Bernspang <j.NOSPAMbernsp...@gNOSPAMmail.com> wrote: > morpheus skrev: > > > > > Hi There! > > I am designing adigitalAM/FMreceiverin a Vertex-4 FPGA. I have > > designed the system blocks but have one question regardingdigital > > filtering. > >>From a systemic point of view, we are using the DDC approach to > > convert IF 45MHz down to baseband. After this we are using a 40MSPS A/ > > D to sample and output parallel 12-bit I, Q data to the FPGA. > > The FPGA front end has to have a LPF with a cut-off frequency of 5kHz. > > After the LPF, AM andFMneed to be demodulated. I intend to do > > demodulation as follows > >FM-> (Q(n)I(n-1) - I(n)Q(n-1))/(I-Sq + Q-Sq) > > AM -> (I-Sq + Q-Sq) > > My question is: > > I need to do some decimation (to make my life easier when it comes to > > 5kHz LPF design)...what is the best way of doing this? I have read > > some material and it seems to point towards cascaded CIC filters. > > Please comment and also let me know if you notice any flaw in my > > design methodology. Moreover, due to my inexperience in this field, I > > wanted to know if decimation upstream would affect (adversely) my AM/ > >FMdemodulation process. > > > cheers > > Morpheus > > Hi Morpheus, > > I designed adigitalAM/FMreceiveron a Virtex-2 FPGA a couple of years > ago. Since I had a 210 Msps ADC (12 bits resolution) before the FPGA I > did not do any DDC before the device. Instead I used a DDS internally > and mixed the desired frequency down to baseband. For the decimation I > used CIC filters in two stages and it worked good. I decimated the > signal from ~200 MHz to about 128 kHz which was much more convenient for > LP filtering. The CIC filters them selves has some LP properties too. > > To extract the amplitude and phase from the I and Q I used a Cordic. > Then it was quite easy to calculate the phase difference, and the > amplitude is given. > > Good luck! > > /Johan Hey Johan, I do get the architecture now. Most likely, I would follow the same technique as you did. I haven't used CORDIC before and even though I am reading up on it extensively, I was wondering if you could elaborate more (biased towards implementation). I do understand that I have to do this bit-serially and use the ARCTAN(x/y) function and subtract the current phase with the previous phase, to generate the FM signal. The AM can be generated though the Vector magnitude part of the CORDIC core. Any comments? Thanks MORPHEUSArticle: 116204
> How do you handle the multiple voltages? Are they expensive? Tim, Use more than one, one for each supply rail. As for cost, it cn't be that bad: if PS3 needs 8 to replace 300 0402 0.1uF caps? AustinArticle: 116205
Jim, I think what is "new" is that these are true four terminal (two port)devices. You think of them with S11, S22, and S21, S12 parameters. The isolation goes both ways, and from either port, it looks like a dead AC short (which is better than a capacitor, which only looks like a dead short at one frequency where it is resonant). They are actually built like a long t-line, with huge C per unit length, and a very tiny L per unit length, which leads to their extraordinary behavior. The careful ratio of LC causes it to act, and appeaqr to be flat over the wide range of frequencies in terms of it Zo. AustinArticle: 116206
Hi Lancer,
Lancer wrote:
> I'm trying to to put uClinux on my Spartan 3 Starter Board (it hasn't
> flash memory and it has only 1MB RAM).
> Finally I've made an uClinux < 1MB (986 KB :-P ).
> Now I've downloaded Microblaze on SP3 using XPS, but I want to know,
> do I need bootloader to startup uClinux from RAM?
> How to download image.bin on it and startup it? (I'm using XPS for Win
> XP).
You can use XMD's "dow" command to download the Linux image into
MicroBlaze memory, and then "con" to start the CPU.
e.g,
$ xmd
% connect mb mdm
% rst
% dow -data /tftpboot/image.bin 0x22000000
% con 0x22000000
using the correct paths and addresses, of course.
Regards,
John
From taileb.mehdi@gmail.com Sun Mar 04 16:57:15 2007
Path: newssvr12.news.prodigy.net!newsdbm05.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!news.astraweb.com!border2.newsrouter.astraweb.com!news-out.readnews.com!news-xxxfer.readnews.com!postnews.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 04 Mar 2007 18:57:15 -0600
From: El Mehdi Taileb <taileb.mehdi@gmail.com>
Subject: Integrate custom cores within Core Generator
Newsgroups: comp.arch.fpga
User-Agent: Pan/0.125 (Potzrebie)
Message-Id: <pan.2007.03.05.00.57.08@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Date: Sun, 04 Mar 2007 18:57:15 -0600
Lines: 5
X-Trace: sv3-42Uh9eQBWIMR91TLg/Sd4e17iCYp7MmhDnXudJ/jnPG2rsBDUW3+83YviebZkgvjOJiT7RECiS8zg4M!dEkYKylIyeTi7Lxy/u+uP2W40XyNvB8yHdGu2RsaSnD2IeJM29kDaamxo/o=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.34
Xref: prodigy.net comp.arch.fpga:127692
Is there a way to integrate custom cores into Core Generator. i.e develop
the GUI etc etc???
Best Regards
Mehdi
From dave@comteck.com Sun Mar 04 17:51:34 2007
Path: newssvr12.news.prodigy.net!newsdbm05.news.prodigy.net!newsdbm04.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newshub.sdsu.edu!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!uns-out.usenetserver.com!news.usenetserver.com!pc03.usenetserver.com!COMTECK.COM-a2kHrUvQQWlmc!not-for-mail
From: Dave <dave@comteck.com>
Subject: Re: Multiplication operation
Date: Sun, 04 Mar 2007 20:51:34 -0500
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
Message-Id: <pan.2007.03.05.01.51.24.71748@comteck.com>
Newsgroups: comp.arch.fpga
References: <KtjGh.116$nU5.24@trnddc04> <b66e65222b828c92c7e41afc5c6@news.ks.uiuc.edu> <1173041243.206811.184650@8g2000cwh.googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@usenetserver.com
Organization: UseNetServer.com
Lines: 29
X-Trace: e6efe45eb777de51d97ba02814
Xref: prodigy.net comp.arch.fpga:127693
On Sun, 04 Mar 2007 12:47:23 -0800, Peter Alfke wrote:
> If you started out as a logic designer (like I did), then you see the
> FPGA as a wonderful way to design a production-worthy breadboard of
> terrific complexity and very good performance.
> ...
> If you start out as a computer programmer, then you design=program the
> way this thread was started, totally oblivious of hardware constraints
> and limittions.
> ...
> You will never beat the urge for economy, performance, and design
> elegance out of us hardware guys.
> ...
So where do us embedded systems half-breeds who have done both rank in
this comparison? One could postulate that we get 95% of the efficiency
of the purebred HW and purebred programmer (rejecting the urge to try for
that last 5% which takes all the time), beating you both to market with a
design which is elegant, economical, and meets performance requirements
since we see from both sides.
:-P ;-))
~Dave~
Article: 116207Dave wrote: > On Sun, 04 Mar 2007 12:47:23 -0800, Peter Alfke wrote: > >> If you started out as a logic designer (like I did), then you see the >> FPGA as a wonderful way to design a production-worthy breadboard of >> terrific complexity and very good performance. >> ... >> If you start out as a computer programmer, then you design=program the >> way this thread was started, totally oblivious of hardware constraints >> and limittions. >> ... >> You will never beat the urge for economy, performance, and design >> elegance out of us hardware guys. >> ... > > So where do us embedded systems half-breeds who have done both rank in > this comparison? One could postulate that we get 95% of the efficiency > of the purebred HW and purebred programmer (rejecting the urge to try for > that last 5% which takes all the time), beating you both to market with a > design which is elegant, economical, and meets performance requirements > since we see from both sides. > > :-P ;-)) > > > ~Dave~ You go, Dave! Being in this middle ground - in my opinion - give you exceptional insight into strong designs with better time to completion. A programmer can become hardware aware and cross over enough to get the performance. A hardware guy can get deep enough into the computing side to increase the algorithmic efficiency of the design. It sounds like you're already squarely placed in this productive center.Article: 116208
This is one of the few threads that got better as it went on. Rare excepton... Peter Alfke On Mar 4, 7:51 pm, John_H <newsgr...@johnhandwork.com> wrote: > Dave wrote: > > On Sun, 04 Mar 2007 12:47:23 -0800, Peter Alfke wrote: > > >> If you started out as a logic designer (like I did), then you see the > >> FPGA as a wonderful way to design a production-worthy breadboard of > >> terrific complexity and very good performance. > >> ... > >> If you start out as a computer programmer, then you design=program the > >> way this thread was started, totally oblivious of hardware constraints > >> and limittions. > >> ... > >> You will never beat the urge for economy, performance, and design > >> elegance out of us hardware guys. > >> ... > > > So where do us embedded systems half-breeds who have done both rank in > > this comparison? One could postulate that we get 95% of the efficiency > > of the purebred HW and purebred programmer (rejecting the urge to try for > > that last 5% which takes all the time), beating you both to market with a > > design which is elegant, economical, and meets performance requirements > > since we see from both sides. > > > :-P ;-)) > > > ~Dave~ > > You go, Dave! > Being in this middle ground - in my opinion - give you exceptional > insight into strong designs with better time to completion. > > A programmer can become hardware aware and cross over enough to get the > performance. A hardware guy can get deep enough into the computing side > to increase the algorithmic efficiency of the design. It sounds like > you're already squarely placed in this productive center.Article: 116209
Peter, I totally agree with your points and while writing my post I knew there would be a huge difference in perspective because of one, the generation(s) gap, as I am still in graduate school, and two, the background, as I have a C.S. degree. However, my comments were more for beginners who shouldn't be overloaded in the infinite amounts of complexity possible with FPGAs (for an example just read one of Austin's posts). Newbies who are probably working on some trivial project should get the fundamentals first (everything is binary, data flow, ...) and then work towards the actual optimized implementations gradually building in complexity, if constraints deem it necessary. After all, you don't learn to swim in the ocean during a hurricane, you start in the kiddy pool. Although, I still believe a lot of work needs to be done to synthesis engines so they can better abstract the low-level complexity away from the designer all the while resulting in an optimized implementation. For a quick example, I still cannot believe you don't optimize across files during synthesis. For the time being, I prefer the embedded systems point of view presented in Dave's response. ---Matthew Hicks > Matthew let me argue for peace: > It all depends on your roots. > If you started out as a logic designer (like I did), then you see the > FPGA as a wonderful way to design a production-worthy breadboard of > terrific complexity and very good performance. God's gift to the logic > designer, good-bye wire-wrap! > I think in terms of block diagrams, and use VHDL/Verilog to manage the > design process. I would never be in doubt about the choice of binary > vs decimal, or fixed vs floating point, because they have such > enenormous impact on the design efficiency. > If you start out as a computer programmer, then you design=program the > way this thread was started, totally oblivious of hardware constraints > and limittions. Let the synthesizer worry about those details! The > trouble is that these unworthy details can impact the design by an > order of magnitude in size=cost and performance. > > You will never beat the urge for economy, performance, and design > elegance out of us hardware guys. Maybe one day FPGAs will become so > big and cheap and fast that it does not matter anymore. > Well, hopefully there will always be Social Security. > And St. Peter might show mercy with us former pip-pokers genus > schemato-saurus. > Peter Alfke > On Mar 4, 12:12 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote: > >> First, to address the question, you're not really doing >> multiplication but >> performing division through multiplication with decimals. ISE >> doesn't do >> division either way. Like John_H said, scale your numbers up (refer >> to fixed >> point numbers) so multiplication is done with integers. When done, >> just >> scale the result down by the same amount for the final answer. A >> hint is >> to scale the numbers by a power of 2 so you just have to do bit >> shifts. >> Second, I would like to give my two cents on John_H's 1990's >> attitude. You >> shouldn't tell someone to read up on vendor specific blocks when it >> is clear >> that they are just starting out, doesn't need an optimal >> implementation, >> and don't have a firm grasp on the basics. You should give them a >> very simple >> and concise explanation at their level and a fix at their level. The >> synthesizer >> is more than capable of handling the * symbol, the OP doesn't need to >> worry >> about what Xilinx puts on the hood. If Xilinx were smart and had >> good programmers, >> which it seems they are trying to work towards, no one would need to >> know >> of any of the blocks under the hood. People should be able to >> "program" >> the hardware. The synthesis program should be smart enough to use >> the blocks >> under the hood to provide a near optimal implementation of the >> "program". >> There is a reason why people use high level programming languages not >> assembly. >> For everyone's sake, "designing" a system on an FPGA shouldn't be >> hard. >> ---Matthew Hicks >> >>> VHDL_HELP wrote: >>> >>>> Hi every body , >>>> i hope that you can help me , i want to do this operation: >>>> s = c1 * 0.2+ c2 * 0.6 + c3 * 0.1 >>>> when i check the syntax , i have these errors >>>> ERROR:HDLParsers:808 - "C:/Xilinx/projet/operation.vhd" Line 44. * >>>> can >>>> not have such operands in this context. >>>> ------------------------------------------------------------------- >>>> -- >>>> ------------------------------------------------------------------- >>>> -- >>>> ---------------------- >>>> library IEEE; >>>> >>>> use IEEE.STD_LOGIC_1164.ALL; >>>> >>>> use IEEE.STD_LOGIC_ARITH.ALL; >>>> >>>> use IEEE.STD_LOGIC_UNSIGNED.ALL; >>>> >>>> entity operation is >>>> Port ( clk : in STD_LOGIC; >>>> c1 : in STD_LOGIC_VECTOR (7 downto 0); >>>> c2 : in STD_LOGIC_VECTOR (7 downto 0); >>>> c 3: in STD_LOGIC_VECTOR (7 downto 0); >>>> s: out STD_LOGIC_VECTOR (7 downto 0); >>>> end operation; >>>> architecture Behavioral of operation is >>>> >>>> begin >>>> >>>> s <=c1 * 0.2 + c2 * 0.6 + c3 * 0.1 ; >>>> >>>> end Behavioral; >>>> >>>> ------------------------------------------------------------------- >>>> -- >>>> ------------------------------------------------------------------- >>>> -- ---------------- >>>> >>>> and thanks for your help >>>> >>> Can you tell me how the synthesizer will format your floating point >>> result in s so it maps to silicon? >>> >>> Use scaled integers. Use the precision available in the hardware >>> multipliers to get a rather precise approximation of s. The digital >>> realm is binary, after all, not decimal. >>> >>> Please read up on how the hardware multipliers perform and how best >>> to utilize them. It's insanely sad to see someone trying to >>> "program" an FPGA rather than design it. >>>Article: 116210
As a note, you can condense your binary stings by using their decimal value instead, the synthesizer should convert it for you. So if I scaled your decimals up by multiplying the constants by 2^11=2048 I would get (using the original equation): s <= c1 * 410 + c2 * 1229 + c3 * 205 ; then shift s right by 11 bits to get the final, correctly scaled answer. Note that there is some error with this method, but you can choose your multiplier to get the desired error. ---Matthew Hicks > On 4 mar, 21:12, Matthew Hicks <mdhic...@uiuc.edu> wrote: > >> First, to address the question, you're not really doing >> multiplication but >> performing division through multiplication with decimals. ISE >> doesn't do >> division either way. Like John_H said, scale your numbers up (refer >> to fixed >> point numbers) so multiplication is done with integers. When done, >> just >> scale the result down by the same amount for the final answer. A >> hint is >> to scale the numbers by a power of 2 so you just have to do bit >> shifts. >> Second, I would like to give my two cents on John_H's 1990's >> attitude. You >> shouldn't tell someone to read up on vendor specific blocks when it >> is clear >> that they are just starting out, doesn't need an optimal >> implementation, >> and don't have a firm grasp on the basics. You should give them a >> very simple >> and concise explanation at their level and a fix at their level. The >> synthesizer >> is more than capable of handling the * symbol, the OP doesn't need to >> worry >> about what Xilinx puts on the hood. If Xilinx were smart and had >> good programmers, >> which it seems they are trying to work towards, no one would need to >> know >> of any of the blocks under the hood. People should be able to >> "program" >> the hardware. The synthesis program should be smart enough to use >> the blocks >> under the hood to provide a near optimal implementation of the >> "program". >> There is a reason why people use high level programming languages not >> assembly. >> For everyone's sake, "designing" a system on an FPGA shouldn't be >> hard. >> ---Matthew Hicks >> >>> VHDL_HELP wrote: >>> >>>> Hi every body , >>>> i hope that you can help me , i want to do this operation: >>>> s = c1 * 0.2+ c2 * 0.6 + c3 * 0.1 >>>> when i check the syntax , i have these errors >>>> ERROR:HDLParsers:808 - "C:/Xilinx/projet/operation.vhd" Line 44. * >>>> can >>>> not have such operands in this context. >>>> ------------------------------------------------------------------- >>>> -- >>>> ------------------------------------------------------------------- >>>> -- >>>> ---------------------- >>>> library IEEE; >>>> >>>> use IEEE.STD_LOGIC_1164.ALL; >>>> >>>> use IEEE.STD_LOGIC_ARITH.ALL; >>>> >>>> use IEEE.STD_LOGIC_UNSIGNED.ALL; >>>> >>>> entity operation is >>>> Port ( clk : in STD_LOGIC; >>>> c1 : in STD_LOGIC_VECTOR (7 downto 0); >>>> c2 : in STD_LOGIC_VECTOR (7 downto 0); >>>> c 3: in STD_LOGIC_VECTOR (7 downto 0); >>>> s: out STD_LOGIC_VECTOR (7 downto 0); >>>> end operation; >>>> architecture Behavioral of operation is >>>> >>>> begin >>>> >>>> s <=c1 * 0.2 + c2 * 0.6 + c3 * 0.1 ; >>>> >>>> end Behavioral; >>>> >>>> ------------------------------------------------------------------- >>>> -- >>>> ------------------------------------------------------------------- >>>> -- ---------------- >>>> >>>> and thanks for your help >>>> >>> Can you tell me how the synthesizer will format your floating point >>> result in s so it maps to silicon? >>> >>> Use scaled integers. Use the precision available in the hardware >>> multipliers to get a rather precise approximation of s. The digital >>> realm is binary, after all, not decimal. >>> >>> Please read up on how the hardware multipliers perform and how best >>> to utilize them. It's insanely sad to see someone trying to >>> "program" an FPGA rather than design it. >>> > hi , thank you for your advices first of all , > then my equation to resolv is : > y=0.299 * R + 0.587 *G + 0.114 * B > for me what i tried to do is: > ---------------------------------------------------------------------- > ---------------------------------------------- > entity rgb is > Port ( clk : in STD_LOGIC; > R : in STD_LOGIC_VECTOR (7 downto 0); > G : in STD_LOGIC_VECTOR (7 downto 0); > B : in STD_LOGIC_VECTOR (7 downto 0); > Y : out STD_LOGIC_VECTOR (31 downto 0); > Cr : out STD_LOGIC_VECTOR (31 downto 0); > Cb : out STD_LOGIC_VECTOR (31 downto 0)); > end rgb; > architecture arch_rgb of rgb is > signal yreg : STD_LOGIC_VECTOR (31 downto 0); > begin > process (clk) > begin > if clk='1' and clk'event then > yreg <= "00111110100110010001011010000111" * R + > "00111111000101100100010110100001"* G + > "00111101111010010111100011010100"* B; > Y <= yreg; > end if; > end process; > end arch_rgb; > ---------------------------------------------------------------------- > ----------------------- >Article: 116211
Hello Everybody, I am looking for some interesting project ideas for a Masters Project. An idea/project that can be implemented on a Xilinx/Altera board and can be "seen" working. I would appreciate any suggestions, at the least they would give me a direction to think in.Article: 116212
VHDL_HELP wrote: > > hi , thank you for your advices first of all , > then my equation to resolv is : > y=0.299 * R + 0.587 *G + 0.114 * B > for me what i tried to do is: > > -------------------------------------------------------------------------------------------------------------------- > entity rgb is > Port ( clk : in STD_LOGIC; > R : in STD_LOGIC_VECTOR (7 downto 0); > G : in STD_LOGIC_VECTOR (7 downto 0); > B : in STD_LOGIC_VECTOR (7 downto 0); > Y : out STD_LOGIC_VECTOR (31 downto 0); > Cr : out STD_LOGIC_VECTOR (31 downto 0); > Cb : out STD_LOGIC_VECTOR (31 downto 0)); > end rgb; > > architecture arch_rgb of rgb is > signal yreg : STD_LOGIC_VECTOR (31 downto 0); > begin > process (clk) > begin > > if clk='1' and clk'event then > yreg <= "00111110100110010001011010000111" * R + > "00111111000101100100010110100001"* G + > "00111101111010010111100011010100"* B; > Y <= yreg; > > end if; > end process; > end arch_rgb; > > --------------------------------------------------------------------------------------------- > > this program is with syntax correct but not synthetisable , what i > tried to d ois to convert the reals with binary ones First, I'm worried you might not have the right VHDL libraries specified for your operation. I'd suggest you 1) do a sample module with just one multiply, keeping the binary value to 17 bits. If the one multiply - no addition - doesn't work, it's quite possibly a VHDL library issue. I just know that they're touchy - I'm a Verilog guy myself, not VHDL. 2) if the one equation works, define intermediate values for your scaled R, scaled G, and scaled B. Then add those scaled values together to get your result. 3) consider whether VHDL will have a problem assigning a nominally 42-bit result to a 32-bit vector and give you synthesis problems if the results don't match in size. Please keep in mind that multiplication with real numbers is abstracted in hardware. When it's time to implement the operation, there are issues with precision and error that have to be understood whether you're using an 8-bit ALU or a dual-precision floating point unit. You will have error. The synthesizer doesn't know what to do with the error - round up? round down? truncate? do something else? - and you must decide what to do to make your math work out. If you're in an 8-bit ALU, you can do operations that are much more precise than 8 bits. You could cascade multiply/shift/add operations to get 8x24 bit multiplies, for instance. Most of the Xilinx families can multiply 17-bit unsinged values using embedded multipliers. Multiplying an 8-bit color value by a 32-bit constant seems like a bit of overkill. Should the synthesizer perform two multiplies and add the intermediate results together to give you a 40 bit result? Perhaps. Personally, I'm glad the synthesis doesn't try to implement things this way. I suggested you "know your silicon" not because everyone using the FPGAs should become a down-in-the-transistors hardware guy but because the dedicated resources which will implement this rather resource-intensive operation has specifications on how it operates, just like the arithmetic units in a microprocessor or the single-precision real operation in the C language. Bottom line: since math in many cases is an abstraction, you have to know how abstract your results will be.Article: 116213
"morpheus" wrote: > I haven't used CORDIC before and even though I > am reading up on it extensively, I was wondering if you could > elaborate more (biased towards implementation). I do understand that I > have to do this bit-serially CORDIC doesn't have to be done bit-serially. That's just one method of implementing it. You can also do a parallel implementation, and in either case you can pipeline it or not. It has the typical tradeoffs of area and throughput.Article: 116214
"GX" <growxpert@gmail.com> writes: > any IP vendor out there who supply hard/soft core for V.34 Modem? V.34 is normally (probably always) implemented in software. You could put any DSP core (or RISC core with DSP capability) into your FPGA or ASIC, and run a V.34 implementation on it.Article: 116215
msg <msg@_cybertheque.org_> wrote: >msg wrote: >> A list of consumer, industrial and mil. products, board names and part >> numbers that contain reprogrammable array logic devices would be very >> useful... >A revised list: >VENDOR PART NUMBER DEVICE PROGRAMMING PACKAGE COMMENTS >------ ----------- ------ ----------- ------- -------- >Waters PCB 510000150 Rev.B Altera EPM7064LC44-12 Vendor Prog. 44-pin PLCC Medical related > EEPROM >Compaq SP#136344-001 Remote Xilinx xc9572xl JTAG 100-pin TQFP Under daugherter bd > Insight Board >Matrox 706-02 Rev. A Video Xilinx xc5204 Ser/Par/Jtag 144-pin TQFP p/o MIL2/RRSTN VGA > Capture daughter bd. >Radius VideoVision Studio Lattice pLSI1032-80LJ Programmer 84-pin PLCC Mac Video Capture > NuBus 632-0156-02 EEPROM >Additions sought. Your list should include 'model number' to it feasable to find the product aswell. Ie: Vendor: Creative Model: SoundBlaster X-Fi Elite Pro Product introduction date also makes it easier. Thoe I have to agree that the economics is doubtfull.Article: 116216
is bluespec pupolar in industry? is it worth learning? CMOSArticle: 116217
On 2007-03-03, msg <msg@_cybertheque.org_> wrote: > Waters PCB 510000150 Rev.B Altera EPM7064LC44-12 Vendor Prog. 44-pin PLCC Medical related The EPM7064 isn't ISP capable. You need a special programmer. I was just given a handful and discovered this myself. There are newer EPM7000 series parts that DO have JTAG and ISP. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 116218
Martin Thompson <martin.j.thompson@trw.com> writes: I remembered :-) CR # 435345 Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 116219
"Jim Wu" <jimwu88NOOOSPAM@yahoo.com> writes: > On Mar 1, 7:03 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: >> "Patrick Dubois" <prdub...@gmail.com> writes: >> > Hello, >> >> > I have been using batch files to handle the build process with a >> > Xilinx flow for a while. Now I want to move to a more sophisticated >> > approach to handle dependencies better. >> >> This has just reminded me of something I discovered recently: >> >> Neither PAR nor TRCE return an error if the design fails timing, so >> any script/makefile which relies on the return code being non-zero as >> an error (like... well... just about anything sane!) will carry on >> through it's script as if everything is OK! >> >> You have to parse the PAR logfile for "No timing errors found" if you >> want to be sure. >> >> I have a change request in to fix this, please add your weight to the >> request (unless you think I'm bonkers for thinking that failing timing >> is an error!) > > Failing timing is an error, but personally I don't want the tool to > return an error code just because of timing errors: OK< I can see people want to work in different ways, but to have the *default* situation of "no error on error" is counter-intuitive! > * I have seen people over-constraining designs. If par doesn't meet > the over-constrained timing but meets the desired timing, I don't want > my script to stop. I do :-) Why overconstrain? If they want some margin on the design, are they be happy with less margin than you asked for? > * If I am in the lab debugging my design and want to quickly try out a > few things, I don't want my script to stop just because one net failed > timing by several ps. > Maybe, that's why one of my suggestions to Xilinx is that they return the timing score, so you can decide how much failure is acceptable (from "0" upwards). Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 116220
hey guys i want a vhdl code for lcd ( 2 lines lcd ) please i want ur help !!!! thnxArticle: 116221
On 4 Mar, 17:22, Austin <aus...@xilinx.com> wrote: > Marc, > > Other than their odd name, they are extremely low impedance t-lines. > > As such, they are basically falt at 1200 uF from DC to daylinght. > > So, if you put a power supply at one end, and isolate the ground (in > other words, that is what the slit is for) you transfer power to the > other end (hot and ground) with a .001 ohm t-line (looks like that very > low impedance at frequencies up to a few hundred MHz). > > So, now you see a AC short, looking either way: from the power asupply > to the load, or from the load to the power supply. > > The Playstation 3 uses 8 of them, they isolate each huge ASIC from the > other huge ASICs, and there are3 NO OTHER CAPS on the pcb.... > > Yes, that is right. > > Whereas the Wii has > 300 little caps, PS3 has these 8 "magic" t-line > structures. > > Do they work? Well, millions of PS3 aren't chunking away happily for no > reason at all. > > We are looking at these seriously to reduce the bypassing requirements > down to the PS3 limit: a few of these, and NOTHING else (no other > bypass caps whatsoever). > > So, it seems the NEC-TOKIN part is the first really new invention in > bypassing in many many long years of people who just like to ignore that > power distribution is a real issue, and one that needs some creativity. > > My hat is off to the engineers who created this wonder. > > Austin Ausin Does this mean that xilinx are actively charactersing these devices for your FPGAs and that we can get hold of the results sometime soon? ColinArticle: 116222
On Mar 5, 2:57 am, "Daniel S." <digitalmastrmind_no_s...@hotmail.com>
wrote:
> Hi!
>
> I have also been quite frustrated by XST BRAM inference in the past...
> and have yet to get XST to do what I want.
>
> If you go check the XST "coding style guide" which contains VHDL
> templates for inferring most of the supported BRAM types, you might find
> exactly what you want.
>
> In my case, I wanted to infer "True dual-port BRAMs" but copy-pasting
> the guide's template (ISE 8.1/8.2) consistently resulted in XST crashes.
> After wasting a week trying to work this out last summer, I decided to
> give up and used a coregen RAM.
>
> More details about my experience with the true dual-port BRAM template:
> - pasting the code in the module's VHDL causes unrecognized BRAM
> inference warnings, causing XST to attempt implementation with
> distributed RAM
> - whipping up the template into its own module and synthesizing it as a
> top module works as advertised/expected
> - instantiating the BRAM template module in an actual design crashes XST
>
> S.T. wrote:
> > Hi
>
> > Thanks for your feedback. Unfortunately both suggestions didn't work :-(.
> > When removing the Reset path the synthesized ram will get dual ported
> > instead of single ported (see below). I tried to rewrite it and make the
> > read and write enable signals explicit and decoupling the reset from ram.
> > It also doesn't work i.e. it still gives distributed instead of block
> > ram :-(.
> > Synthesizing Unit <BRAM_test>.
> > Related source file
> > is "/amd/iss1/users/ma/tstone/georg/bram/BRAM_test.vhd".
> > Found 1024x16-bit single-port distributed RAM for signal <RAM>.
> > -----------------------------------------------------------------------
> > | ram_style | block | |
> > -----------------------------------------------------------------------
> > | Port A |
> > | aspect ratio | 1024-word x 16-bit | |
> > | clkA | connected to signal <CLOCK> | rise |
> > | weA | connected to internal node | high |
> > | addrA | connected to signal <addr> | |
> > | diA | connected to signal <di> | |
> > | doA | connected to internal node | |
> > -----------------------------------------------------------------------
> > WARNING:Xst:1440 - Cannot use block RAM resources. Please check that the RAM
> > contents is read synchronously.
Try this piece of code.....
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity BRAM_test is
port (CLOCK : in std_logic;
-- reset : in std_logic;
di : in std_logic_vector(15 downto 0);
do : out std_logic_vector(15 downto 0));
end BRAM_test;
architecture syn of BRAM_test is
type ram_type is array (1023 downto 0) of std_logic_vector (15 downto
0);
signal RAM : ram_type;
attribute ram_style : string;
attribute ram_style of RAM: signal is "block";
type STATE_TYPE is (P1, P2, P3);
signal STATE : STATE_TYPE;
signal addr : std_logic_vector(9 downto 0);
begin
main : process (CLOCK)
begin
-- if (RESET = '1') then
-- STATE <= P1;
-- addr <= (others => '0');
if (CLOCK'event and CLOCK = '1') then
case STATE is
when P1 =>
RAM(conv_integer(addr)) <= di;
do<=di;
STATE <= P2;
when P2 =>
do <= RAM(conv_integer(addr));
STATE <= P3;
when P3 =>
addr <= addr + '1';
STATE <= P1;
end case;
end if;
end process main;
end syn;
Article: 116223Some in-line stuff about Proadlizer, my other comments at the end. "Austin" <austin@xilinx.com> wrote in message news:esev91$st1@cnn.xsj.xilinx.com... > Marc, > > Other than their odd name, they are extremely low impedance t-lines. > > As such, they are basically falt at 1200 uF from DC to daylinght. > Unfortunately, once you mount them, they no longer work to infinity (or beyond). As ever, the design is limited by the physical layout of the parts and connections, not the devices. > > So, if you put a power supply at one end, and isolate the ground (in other > words, that is what the slit is for) you transfer power to the other end > (hot and ground) with a .001 ohm t-line (looks like that very low > impedance at frequencies up to a few hundred MHz). > I think this paragraph is wrong, Austin, there are no slits in the ground plane in the designs shown at:- http://www.nec-tokin.com:80/english/product/cap/proadlizer/test1.html. The slots are only in the power planes. Ground isn't isolated, that would be very bad indeed. You've got to get signals in and out as well as power. But hold on a minute, I see on this site they show the thing used with a slot in the ground plane. http://www.chemi-con.co.jp/english/support_e/proadlizer_e.html Ouch! What happens to all the signals going to and from the device? I see here:- http://www.nec-tokin.com/english/product/pdf_dl/proadlizer_e.pdf they still mention the ground plane slot, claiming the ground plane slot offers "more optimal performance" [sic]. My bullshit sense is tingling! I'd suggest this is not true for a real system with signals traversing this ground plane slot. It makes me wonder if they really know for what this device should be used. > > So, now you see a AC short, looking either way: from the power asupply to > the load, or from the load to the power supply. > > The Playstation 3 uses 8 of them, they isolate each huge ASIC from the > other huge ASICs, and there are3 NO OTHER CAPS on the pcb.... > > Yes, that is right. > > Whereas the Wii has > 300 little caps, PS3 has these 8 "magic" t-line > structures. > > Do they work? Well, millions of PS3 aren't chunking away happily for no > reason at all. > > We are looking at these seriously to reduce the bypassing requirements > down to the PS3 limit: a few of these, and NOTHING else (no other bypass > caps whatsoever). > > So, it seems the NEC-TOKIN part is the first really new invention in > bypassing in many many long years of people who just like to ignore that > power distribution is a real issue, and one that needs some creativity. > > My hat is off to the engineers who created this wonder. > > Austin > OK, what these devices appear to be good at is isolating the power supply noise from the ASICs/FPGA and stopping it spreading over the board. They also provide bypassing for the ASICs/FPGA. It's kinda like a series ferrite and a parallel capacitance at the ASIC/FPGA end. The 'new' bit is that it's all integrated onto a nice low ESL package. Sadly, the end user then has to attach this to his circuit which will affect this impedance. The blurb on the site shows how they localise EMC problems, reducing emissions, more than what great bypass capacitors they make. I see these parts got a brief mention on SI-list back in Jan '04, so I'd suggest they're not a 'miracle breakthrough' or we'd have heard more about them already. I would tend to go for the X2Y stuff we discussed last week on CAF. http://www.googlefight.com/index.php?lang=en_GB&word1=proadlizer&word2=x2y+component Or, perhaps slightly more seriously, :- http://www.x2y.com/bypass/measure/comparative_device_only.pdf Anyway, whatever else, it's nice to see people doing designs with tiny local power planes for the FPGA, and not believing all the claptrap about plane capacitance and resonances to help PDS for big BGA packages. Cheers, Syms.Article: 116224
"Tim" <tim@nooospam.roockyloogic.com> wrote in message news:eses5g$sfo$1$8302bc10@news.demon.co.uk... > > On the plane-splitting point, you can read app notes advocating this > practice and app notes claiming that plane splitting is a discredited > practice from an earlier era. I get the sense that the current (sic) best > practice is that ground plane splitting is rarely a good idea and a degree > of VCC plane splitting may help on a noisy board, but much better would be > to find out why VCC is noisy and fix it. Again, gurus will set me > straight... Also, see Symon's recent posts on puddles. > > Tim Hi Tim, Separate ground planes are very rarely a good idea. AFA I can tell, they seem to have arisen because mixed signal parts, like ADCs, have separate analog and digital ground pins. The reason for this is because the package they are in has some impedance in the connection from the die to the circuit board. You don't want noisy digital ground currents travelling down the same connections as the analog ground current as you'll get noise injected into your analog circuitry. However, once the ground signals get out of the device and into your negligible-impedance ground plane, there's no problem. All the ground pins can be joined together. Here's a link:- http://www.analog.com/analog_root/static/raq/moreInfo/raq_groundingClean.html Here's a link about signals traversing slots in ground planes (there's tons of this stuff on t'internet) :- http://www.hottconsultants.com/techtips/tips-slots.html The same thing applies when signals travel from one reference (say 'analog ground') to another (say 'digital ground'). VCC is different because it's not generally used as a reference and modern devices have many different supplies. It's impractical to have a plane for every single one. You can achieve good performance by having small local planes adequately bypassed. The small local planes pool the capacitors together to achieve the characteristics required. It's also fairly easy to isolate ICs' supplies from each other this way. Whenever thinking about this stuff, it's important to remember that the vias, connections to the package, and package impedance must ALL be taken into account. It's no help that a Proadlizer has 1pH of inductance if the vias have 2 orders of magnitude more impedance. HTH, Syms. p.s. Apologies for my multi-posts in this thread. My usenet provider told me it wasn't posting when I guess it really was.
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