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 believe there are also digital mixer chips made specifically for this kind of application. That may save you development time. I did a search on Google for digital downconverter and got over 2000 hits. Harris, Nat. Semi., Stanford, etc. Steve tomderham@my-deja.com wrote in message <93co6a$nfk$1@nnrp1.deja.com>... >Hi > >Please humour me and my lack of knowledge, I would appreciate some >advice: > >I am looking at possibilities for a prototype radar receiver (short >range, but good beamforming agility), and was looking at a DSP chip >such as the TI C5410 DSP chip or similar to perform digital >downconversion after the ADC (clocked at say 50MHz). >I am looking into the possibilities of using an FPGA to do something >similar. How do the costs compare for an FPGA comparable in processing >power (the TI chip is only about $50) and are similar development tools >available? > >Thanks for any advice > >Tom > > >Sent via Deja.com >http://www.deja.com/Article: 28351
Eric Smith <eric-no-spam-for-me@brouhaha.com> writes:
> Petter Gustad <spam@gustad.com> writes:
> > Some time ago I posted a message regarding Xilinx Alliance for Linux.
> > I was wondering if Xilinx have any plans on releasing Alliance for
> > Linux/X86? I've been using Alliance under Solaris, but I would like to
> > run under Linux since the price/performance ratio is much better.
>
> I asked about this a few months ago. A Xilinx employee said that they
> don't plan to offer such a thing, since there's "no demand".
Where should we send requests for a native Alliance for Linux? How can
we tell them that there is a demand?
Xilinx reps, are you there? I want a native version of Alliance for
Linux/X86!!!
Best regards
Petter Gustad
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}
Article: 28352Mark W Brehob <brehob@cse.msu.edu> writes: > If you mean a FSM which randomly goes to different states based on certain > probabilities, I really have no clue if it has been done, nor do any > applications jump out at me. This sounds like a Markov chain/model to me. Is there a relationship between NFAs and Markov models? If you're using speech recognition, you're using one variant of Markov models called HMMs. I consider a type of hypothesis testing based on transition probabilities (usually measured heuristically or estimated in some way). JanArticle: 28353
Hi, in case of using the same clock for both CLKA and CLKB of a Virtex Block SelectRAM in XILINX Foundation F3.1i I get the following message in the LOGIC SIMULATOR: Timing Violations at 27ns Signal: ram0.CLKA too short SETUP time. Missing Time: 3ns Signal: ram0.CLKB too short SETUP time. Missing Time: 3ns I have applied the unmodified Xilinx VHDL-File "fifoctlr_cc.vhd" (Xilinx ApplNote XAPP 131, http://www.xilinx.com/xapp/xapp131.pdf, 511 x 8 FIFO with common clocks.) If I use the XILINX Foundation F2.1i no errors occur in LOGIC SIMULATOR. Can anyone give me any suggestion on it? Thanks Regards Markus DobschallArticle: 28354
This is a multi-part message in MIME format. --------------55064C9B4C9E5F6328848A7A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Why not use Free software at http://www.xilinx.com/products/software/webpowered.htm and pick a board from http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=protoboards_protoboards_page#ThirdPartyPartner valeri wrote: > Hi, > I want to start with FPGA design. > I will appreciate any suggestions for good starter kit. > > Val --------------55064C9B4C9E5F6328848A7A Content-Type: text/x-vcard; charset=us-ascii; name="steve.prokosch.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Prokosch Content-Disposition: attachment; filename="steve.prokosch.vcf" begin:vcard n:Prokosch;Steve tel;fax:505-858-3106 tel;home:505-890-7183 tel;work:505-798-4811 x-mozilla-html:FALSE org:Xilinx Inc.;CoolRunner CPLD adr:;;7801 Jefferson st N.E.;Albuquerque;NM;78109;USA version:2.1 email;internet:sprokosch@xilinx.com title:Product Marketing end:vcard --------------55064C9B4C9E5F6328848A7A--Article: 28355
There is a new version of hdlmaker available, hdlmaker generates hierarchical verilog and vhdl. http://www.polybus.com/hdlmaker/hdlmaker.html Sent via Deja.com http://www.deja.com/Article: 28356
The question of who to pester at Xilinx to get them to support Linux comes up repeatedly in this group, maybe Peter Alfke would let us know who the right people to contact are. Contrary to what you hear from Xilinx, there is a lot of interest in a Linux version of the Xilinx tools. I've received email from all over the world concerning the Xilinx on Linux Howto page so I know that interest is wide spread. Unix is vastly superior to NT as a CAE environment and Linux is the most cost effective and user friendly Unix available. Both Cadence and Synopsys have ported all of their tools to Linux, and Cadence has stated that they don't think that Windows NT will be used for anything except schematic capture. The only reason that Windows is still a popular FPGA development environment is because there isn't a native version of the Xilinx tools available for Linux. Unix is a natural CAE environment, Windows is not. In the ASIC world NT is used strictly as an X-Server for Unix applications that are running on Solaris servers, no actual work is done on NT except spec writing. The actual work of porting the Xilinx tools to Linux would be trivial, probably just a recompile. The Xilinx tools already run on several different versions of Unix so there is not likely to be any vendor specific dependencies that would require any code changes. The issue of which distribution to support is also easy, it's Redhat. Redhat is the defacto standard, it's what Synopsys and Cadence support so that's what Xilinx should support also. If the tools work on Redhat they will probably work on everyone elses distribution also, but Xilinx doesn't have to support the other distributions. Even though I use Xilinx under WINE on Linux, I would much prefer a native Linux version. The major problem with WINE is that each new release of the Xilinx tools breaks it. At the current time the 3.2i tools run fine under WINE but the latest release, 3.3i sp6, doesn't work yet. Josh Rosen Sent via Deja.com http://www.deja.com/Article: 28357
I know how to make binary up/down counters and LFSR-based counters in verilog, but does anyone know of an algorithmic/equation-based way to make grey-code counters? The only examples I've seen are from old PAL application notes, and they are for 4-bit grey counters that are described as 16-state state machines, which is ok if you are keeping the counter at 4-bits, but impractical if you are going to much wider bit widths. -- ============================== William Lenihan lenihan3weNOSPAM@earthlink.net .... remove "NOSPAM" when replying ==============================Article: 28358
"bjrosen" <bjrosen@polybus.com> wrote in message news:93gbc2$juh$1@nnrp1.deja.com... > Both Cadence and > Synopsys have ported all of their tools to Linux, and Cadence has stated > that they don't think that Windows NT will be used for anything except > schematic capture. DOS/OrCAD (the old version 2) is even better for schematic capture.Article: 28359
Hello Bill. I have made grey-code counter, it has N + 1 T-type FFs, where N is number of output bits. I have used ALDEC schematics capture, but converting it to Verilog is very simple. Let me know, if you are interested. Jaan Sirp. >I know how to make binary up/down counters and LFSR-based counters in >verilog, but does anyone know of an algorithmic/equation-based way to >make grey-code counters? > > >The only examples I've seen are from old PAL application notes, and they >are for 4-bit grey counters that are described as 16-state state >machines, which is ok if you are keeping the counter at 4-bits, but >impractical if you are going to much wider bit widths.Article: 28360
In article <93gbc2$juh$1@nnrp1.deja.com>,
bjrosen <bjrosen@polybus.com> writes:
<...>
|> The actual work of porting the Xilinx tools to Linux would be trivial,
|> probably just a recompile. The Xilinx tools already run on several
|> different versions of Unix so there is not likely to be any vendor
<...>
I spoke about this topic to a FAE of the Xilinx booth at the electronica last
year. He said roughly the following:
"The Xilinx SW-developers already have Linux versions, since the development
of the core tools (map/par etc.) is faster than on Solaris and not as
reboot-prone as on Windows. The reason for the non-availability on the
market is the missing demand of large companies for Linux-tools and the
additional work for quality control and support for the Linux versions."
I don't know if the first part is really true, but it sounds realistic. I can't
imagine that text-only programs with very limited OS-usage should pose a big
porting problem. Ok, maybe fixing some includes, but eg. par lacks all usuall
porting issues, like special networking stuff, interactive terminal input
(curses...) or special file handling needs.
And the second part (missing demand): Well, maybe Xilinx has an "exiting" press
release next year: "We are quickly responding to the user's demand and provide
now Linux tools"...
I was ROTFLing when I read Synopsys' press release that had a similar wording ;-)
--
Georg Acher, acher@in.tum.de
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
Article: 28361In article <978591339.623677@sai.velocet.net>, "valeri" <vassenov@dsl.ca> wrote: > Hi, > I want to start with FPGA design. > I will appreciate any suggestions for good starter kit. I designed my own PCBs for the smaller Spartan and Flex chips, and had a couple of each made. It wasn't expensive, about 150 UK pounds. Leon -- Leon Heller, G1HSM Tel: (Mobile) 079 9098 1221 (Work) +44 1327 357824 Email: leon_heller@hotmail.com Web: http://www.geocities.com/SiliconValley/Code/1835 Sent via Deja.com http://www.deja.com/Article: 28362
Hi Michel, Could you post the exact error message! Thanks Sanjay -- Sanjay Kumar Sharma ASIC Design Engineer Philips Semiconductors Eindhoven, The Netherlands "Le Mer Michel" <michel.lemer@sta.fr> wrote in message news:93c9gj$kk4$1@s1.read.news.oleane.net... > Hello > > I have a strange message about APEX20K_ timing violation during simulation > despite I use the APEX 20KE family and that all the frequencies are met > according to Quartus. > > Any suggestions? > > Thanks > -- > Michel Le Mer immeuble Cerium > STA 12, square du Chene Germain > 02 23 20 04 72 35510 Cesson-Sevigne > >Article: 28363
We are implementing a fir filter using VIRTEX FPGA XCV1000-6-BG560.We got a problem during the implementation.Does anybody know how to avoid a signal to be removed during the implementation?For a better understanding of the question a part of the report text of map.mrp file follows: The signal "N_ControlPortPins<7>" is unused and has been removed. Unused block "C_ControlPortPins<7>" (IBUF) removed. The signal "ControlPortPins<7>" is unused and has been removed. Unused block "ControlPortPins<7>.PAD" (X_IPAD) removed. Thanks in advance.Article: 28364
bjrosen wrote: > The question of who to pester at Xilinx to get them to support Linux > comes up repeatedly in this group, maybe Peter Alfke would let us know > who the right people to contact are. Contrary to what you hear from > Xilinx, there is a lot of interest in a Linux version of the Xilinx > tools. <snip> I have forwarded these request to the appropriate party (and also to the highest level) within Xilinx. I will let them come up with the right response. We are aware of the problem and the opportunity. Peter Alfke, Xilinx ApplicationsArticle: 28365
Petter Gustad wrote: > > Some time ago I posted a message regarding Xilinx Alliance for Linux. > I was wondering if Xilinx have any plans on releasing Alliance for > Linux/X86? I've been using Alliance under Solaris, but I would like to > run under Linux since the price/performance ratio is much better. > > Some people suggested using NT. I do this at the moment (well actually > Windows 2000), it works, but it has some drawbacks. Here are some of > them. > > 1) Lack of a nohup and ps command. I'm used to log in from home at > night to start long PAR jobs which takes 5-20 hours to complete. > The process seem to continue, but I wish I had something like nohup > to start the process in the background and log all output to a > file. I also wish I had a ps command to see if the darn thing is > still running. I can not kill the job if I want to. bash for W2K > might solve some of these issues. > > 2) Uptime. Every time you install a little dinky piece of software (or > click in the control panel) you'll have to restart the machine. So > much for uptime and running long simulations and PAR jobs. > > 3) X11. I can't start emacs or signalscan over my ISDN line from home > like I do with Solaris or Linux. I have tried some of the remote NT > login software which gives me an NT display at home, but it's very > slow compared to X11. > > I understand that there is more than a recompile to make a Linux > version (e.g. an extra dimension to their support and verification > space), but I can't see why there aren't any other Xilinx users out > there who wants Linux support? My Linux box is a Blue and White Apple Mac G3, running Yellow Dog Linux. I want the Xilinx tools to run on that box, too! -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt."Article: 28366
I recently had reason to investigate this for the design of an asynchronous BlockRAM-based FIFO in Virtex and Virtex-II. ( BTW: I got it to run at 200 MHz, with proper FULL and EMPTY handshake, while running with with two independent unrelated clocks) Here are my notes: Grey-Coded Addresses Only one bit/address changes at any time Therefore no glitches from the identity comparator Implementation: Build binary counter Generate XOR of two adjacent D-inputs (that is the trick ! Don't use the binary Q, use the binary D) Feed these XORs to a register = Grey ! MSB binary = MSB Grey Advantage: very fast and easily epandable. Please excuse the terse (PowerPoint) notation. Yes, it wastes flip-flops. But I think it is still the most compact (cheapest) solution in Virtex, where one CLB implements two bits, since it has 4 flip-flops. I tried various other ways, and -while they did not waste flip-flops- they were no cheaper. BTW: You can of course use the simultaneous binary output "for free". You can also run the counter in both directions "for free". I will gladly accept a more compact solution. Peter Alfke, Xilinx Applications Bill Lenihan wrote: > I know how to make binary up/down counters and LFSR-based counters in > verilog, but does anyone know of an algorithmic/equation-based way to > make grey-code counters? > > The only examples I've seen are from old PAL application notes, and they > are for 4-bit grey counters that are described as 16-state state > machines, which is ok if you are keeping the counter at 4-bits, but > impractical if you are going to much wider bit widths. > > -- > ============================== > William Lenihan > lenihan3weNOSPAM@earthlink.net > .... remove "NOSPAM" when replying > ==============================Article: 28367
Does anybody have a symbol library for Xilinx chips for Orcad capture. I'm specially looking for the PQ208 package for the Spartan II and VX44 package for the 18Vxx ISP Prom Many thanks for your help Gil Golov.Article: 28368
Bill, Making a Gray counter is surprisingly simple. I have some code, which I can't give out, but it is basically just a conventional counter and some XORs. Say you have an N-bit counter, CNT, and want an N-bit Gray counter. Gray[0] is (CNT[1] ^ CNT[0]), Gray[1] is (CNT[2] ^CNT[1]), ... Gray[N-2] = (CNT[N-1] ^ CNT[N-2]), and finally, the last bit, Gray[N-1] = CNT[N-1]. "Gray" can just be the output of the flipflops, or you can pipeline the output for extra speed. In that case the Gray counter would run at whatever speed the convential counter ran. You may hardcode this or use a loop to make Gray counters of N size. -Kevin Neilson, IDS Jaan Sirp wrote in message ... >Hello Bill. > >I have made grey-code counter, it has N + 1 T-type FFs, where N is number of output bits. I have used ALDEC schematics capture, but converting it to Verilog is very simple. Let me know, if you are interested. > >Jaan Sirp. > >>I know how to make binary up/down counters and LFSR-based counters in >>verilog, but does anyone know of an algorithmic/equation-based way to >>make grey-code counters? >> >> >>The only examples I've seen are from old PAL application notes, and they >>are for 4-bit grey counters that are described as 16-state state >>machines, which is ok if you are keeping the counter at 4-bits, but >>impractical if you are going to much wider bit widths.Article: 28369
I suggested a slight twist to this design: Same logic, but feed the XOR from the D-inputs of the binary counter, not their Q outputs. This way the binary and grey counters are "in step". Peter Alfke Kevin Neilson wrote: > Bill, > Making a Gray counter is surprisingly simple. I have some code, which I > can't give out, but it is basically just a conventional counter and some > XORs. Say you have an N-bit counter, CNT, and want an N-bit Gray counter. > Gray[0] is (CNT[1] ^ CNT[0]), Gray[1] is (CNT[2] ^CNT[1]), ... Gray[N-2] = > (CNT[N-1] ^ CNT[N-2]), and finally, the last bit, Gray[N-1] = CNT[N-1]. > "Gray" can just be the output of the flipflops, or you can pipeline the > output for extra speed. In that case the Gray counter would run at whatever > speed the convential counter ran. > > You may hardcode this or use a loop to make Gray counters of N size. > > -Kevin Neilson, IDS > > Jaan Sirp wrote in message ... > >Hello Bill. > > > >I have made grey-code counter, it has N + 1 T-type FFs, where N is number > of output bits. I have used ALDEC schematics capture, but converting it to > Verilog is very simple. Let me know, if you are interested. > > > >Jaan Sirp. > > > >>I know how to make binary up/down counters and LFSR-based counters in > >>verilog, but does anyone know of an algorithmic/equation-based way to > >>make grey-code counters? > >> > >> > >>The only examples I've seen are from old PAL application notes, and they > >>are for 4-bit grey counters that are described as 16-state state > >>machines, which is ok if you are keeping the counter at 4-bits, but > >>impractical if you are going to much wider bit widths.Article: 28370
Bill Lenihan <lenihan3weNOSPAM@earthlink.net> writes: > I know how to make binary up/down counters and LFSR-based counters in > verilog, but does anyone know of an algorithmic/equation-based way to > make grey-code counters? > Grab the design files for Xilinx Application note 131 on FIFOs and look at fifoctlr_ic.vhd. The read and write address pointers are implemented as gray code counters... -Arrigo -- Dr. Arrigo Benedetti e-mail: arrigo@vision.caltech.edu Caltech, MS 136-93 phone: (626) 395-3129 Pasadena, CA 91125 fax: (626) 795-8649 > The only examples I've seen are from old PAL application notes, and they > are for 4-bit grey counters that are described as 16-state state > machines, which is ok if you are keeping the counter at 4-bits, but > impractical if you are going to much wider bit widths. > > -- > ============================== > William Lenihan > lenihan3weNOSPAM@earthlink.net > .... remove "NOSPAM" when replying > ============================== > >Article: 28371
XAPP131 is just a straightforward binary-to-gray converter, as described in the 1972 Fairchild applications handbook ( by yours truly). The trick of using the XOR of the binary D-inputs is smarter, if I may say so. Same brain, just 29 years additional experience. :-) Peter Alfke ====================================== Arrigo Benedetti wrote: > > > Grab the design files for Xilinx Application note 131 on FIFOs and look > at fifoctlr_ic.vhd. The read and write address pointers are implemented > as gray code counters... > > -Arrigo > -- > Dr. Arrigo Benedetti e-mail: arrigo@vision.caltech.edu > Caltech, MS 136-93 phone: (626) 395-3129 > Pasadena, CA 91125 fax: (626) 795-8649 >Article: 28372
This is an input that is not used in your design once the design has been trimmed. Trimming strips out any logic who's output is not driving something or going to an output pad. It also reduces any logic that is 'stuck at' 1 or 0. For some reason, either because of a design error or because of boolean reduction, this signal is not being used, therefore its source, all the way out to the pad is being trimmed. diei-unipg-it wrote: > > We are implementing a fir filter using VIRTEX FPGA XCV1000-6-BG560.We got a problem during the implementation.Does anybody know how to avoid a signal to be removed during the implementation?For a better understanding of the question a part of the report text > of map.mrp file follows: > > The signal "N_ControlPortPins?7?" is unused and has been removed. > Unused block "C_ControlPortPins?7?" (IBUF) removed. > The signal "ControlPortPins?7?" is unused and has been removed. > Unused block "ControlPortPins?7?.PAD" (X_IPAD) removed. > > Thanks in advance. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 28373
I probably shouldn't, but I can't resist commenting on this thread... Let's preface this by saying that the following in no way, shape, or form expresses the opinion of Xilinx, Inc. Linux presents some real challenges from a s/w business point-of-view (as opposed to looking at it as a programmer's toy). Think of it from the perspective of a software quality assurance manager, or support manager. The reality of Linux is that there are no two Linux installations alike. I have Linux on one of my machines, originally RH 6.0. But now I can claim no version for it, since I've rebuilt the kernel several times with various patches.... If I build our tools on my box, how do I warranty that they will run (correctly) on any other Linux machine in the world? In the Windows world, we have SP's from MS that we can specify on our product requirements and build and test against (oh yeah, we also have to test against many localized versions of Windows). A lot of combinations, but at least finite. So supporting any new OS, even one that doesn't come in infinite permutations like Linux, involves very significant $$$. I, as a developer, see almost none of those costs, they are born primarily by the folks who supply our development tools/platforms, test, support, and documentation people. For all of this, we would see very little incremental revenue (how much do we charge for our tools?). Not surprisingly, I suspect that most of my fellow developers would like to support Linux, and most of the rest of the company would like to have our heads for even muttering the word. FYI, I am a s/w developer for Xilinx, working primarily on the Webpack/Webfitter stuff. In previous lives I was a ASIC/board designer. I've also done web programming, network admin, etc. on several Linux systems. -dmArticle: 28374
"Kevin Neilson" <kmneilson@earthlink.net> writes: > Making a Gray counter is surprisingly simple. I have some code, which I > can't give out, but it is basically just a conventional counter and some > XORs. Say you have an N-bit counter, CNT, and want an N-bit Gray counter. > Gray[0] is (CNT[1] ^ CNT[0]), Gray[1] is (CNT[2] ^CNT[1]), ... Gray[N-2] = > (CNT[N-1] ^ CNT[N-2]), and finally, the last bit, Gray[N-1] = CNT[N-1]. > "Gray" can just be the output of the flipflops, or you can pipeline the > output for extra speed. In that case the Gray counter would run at whatever > speed the convential counter ran. If you're using Gray counters because you have counters in two clock domains (e.g., for a FIFO), doesn't implmenting them as binary counters with converters defeat the purpose? With that implementation you can have glitches where multiple bits change simultaneously.
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