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
Lars Fomsgaard wrote: > > Hi > > I have some problems with a design, that I can not make synthesize properly > in Xilinx Foundation > (the code is listed belov). The problem is that the tool removes to signals > (swon and t16m)from the > netlist and from the macro symbol. > > Basicly i have a counter (cur_cnt), that is reset whenever a certain > condition is meet (t16m = '1'), and > incremented whenever an rising edge occours on the signal swon. > > I have sent the design to Xilinx hotline, and their "VHDL-expert" claims > that the problem is as follows: > > I assign the signal swon_d the value of swon, and after this (but in the > same clocked process) I test > wheater the condition (swon = '1' AND swon_d = '0') is meet, and this can > never be the case, so the > signals swon and t16m can be removed. > this is wrong, signals are not updated untill you exit the process, so swon_d will(should :)) be a register, so inside the process it will have the value of swon from the last rising edge, since it is not updated until the exit _ _ _ _ _ clk _| |_| |_| |_| |_| | _________________ swon __// ______________ swon_d ______| ^ process see: | > I do not agree with this, and so I would like if someone could tell me if I > have completely misunderstood > the principle of VHDL processes. And if someone else have experienced > similar problems and knows > a workaround. > > Thanks in advance > Lars Fomsgaard > snip > --Lasse --___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_---- Lasse Langwadt Christensen, MSEE (to be in 1999) Aalborg University, Department of communication tech. Applied Signal Processing and Implementation (ASPI) http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.orgArticle: 14551
Only if they all use all the memory too. They might not. NT has a weird memory management strategy, gradually using up all the RAM there is and continually swapping pages to disk even if there is far more RAM that it "should" need. This brain-dead strategy has been much criticised but MS claim, IIRC, that it represents the best tradeoff for a "server" situation. But then we all know that MS is not exactly an innovative company, preferring to stick with code which does the job. Win3.x, in comparison, will use up the RAM it needs and stop there. If you have a system with 64MB and running some little app then most of the RAM won't get touched, AFAIK, after the initial himem.sys memory test (which is very primitive anyway). I don't know about win9x and OS/2. I would expect win9x to be similar to win3.x in this respect. >If using the whole memory space could make your system crash, then all other >OS's should have problems too. -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y. Please do NOT copy usenet posts to email - it is NOT necessary.Article: 14552
***** I'm posting this conversation in the 2 sci.electronics groups at this time to get opinions from those who frequent these newsgroups. - bob ------------------------------------------------------------------- Here's what I'm mostly concerned about -- it seems that the vendors, such as Vantis and Xilinx, are now going to target their own CPLD/FPGA lines with ABEL. I need to find a product that is not a "point" solution; something that will handle programming PLDs (aka 16R8s, 22V10s, etc.) that are still being made by various manufacturers. I am trying to find possible solution(s) that cover the following needs: 1) Will target multiple vendor PLDs (not just CPLDs and/or FPGAs). 2) Can program parts using Data I/O Unisite subsystem. 3) Available to run under PC-NT platform (Sun Solaris & HPUX may be optional). 4) Uses FlexLM license checkout, if required. (Have to service multiple engineers per building/site, which may have access to an open or closed LAN). The only vendor that seems to meet this criteria now is Logical Devices with their CUPL Total Designer suite. If anyone has any additional suggestions/inputs, please post them or send me email directly. Thanks, Bob In article <79brhj$699$1@nnrp1.dejanews.com>, peter.trott@vantis.com writes: > In article <796uds$cb3@news.rsc.raytheon.com>, > rjmyers@ti.com wrote: > > As some/many of you may know, Minc/Synario closed their > > doors and had turn over their assets to be liquidated > > (see EETimes article, dated around Dec 18, 1998). > > > > I am trying to determine what people/other organizations > > are doing to support the programming of PLDs (and possibly > > CPLDs) now that the company that supplied ABEL has shut down. > > It appears that Logical Devices may be the only "non-biased" > > vendor out their, with their CUPL system that targets > > multiple PLD vendor devices. > > Vantis purchased the Synario GUI and the rights to use the ABEL > language in a new product that is available free from the Vantis > web site. It is called DesignDirect-CPLD. > If you are familiar with Synario the GUI is similar with some > added enhancements to the flow including an easy to use constraints > editor and timing analyser at the back. > It supports all Vantis SPLD and CPLD parts, from the lowly 16V8 up to the > 512 macrocell MACH5's. > > This tool will allow you to migrate old design by maintaining the ABEL > language. DD-CPLD allows ABEL, schematic and EDIF inputs so that it can be > bolted under any third party synthesis tool. > > > > > > > Any thoughts/insights on this matter are welcomed. > > > > -Bob > > > > p.s. I have not received any inputs from our AVNET reps > > regarding what Xilinx's plans are regarding what Xilinx > > purchased from the liquidator. > > > > > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14553
> > I just do not believe NT does anything with the chip set. Why do you > > believe this? Are you speculating or do you have first hand knowledge of > > this? > > No, but as I said before, this is the most plausible explanation. Why ? > > I have seen the same memory blocks not perform on one mainboard with NT, but > performing very well on another mainboard with NT, indicating that the quality > of this RAM was not an issue. There could be timing differences in the systems/chip sets that have nothing to do with NT. Also, the BIOS settings may be different....who knows. Unless you have done this as a controlled experiment, checking/verifying every variable and only changing one at a time, and any conclusion you might want to draw from this is pure speculation. > > I believe there are many other plausible explanations...such as it actually > > uses it, may be NT loads high, may be it just uses a LOT more memory, a LOT > > more often. May be it actually cares that it gets the right answer, unlike > > the virus W95 that could care less? I really don't know, but my last > > guess would be it re-programs the chip set. Also, I believe NT uses > > features of the processor that others don't.... > > If using the whole memory space could make your system crash, then all other > OS's should have problems too. No, if NT loaded all over the place, and takes up substantially more memory, then it would be more sensitive. Besides, other OSs DO have the same problem, namely Linux. > And all systems crash if they don't get the > "right answer" It is not that the OS is determining the sensibility level with > regards to the CPU getting bad opcodes :-) But if the OS code/data was much larger, then it would be much more susceptible. And if you note, that virus W95 crashes ALL the time. Given that, memory problems might plague W95 just as they do NT, they just manifest them selves differently. AustinArticle: 14554
Lars Fomsgaard wrote: > <snip> > I have sent the design to Xilinx hotline, and their "VHDL-expert" claims > that the problem is as follows: > > I assign the signal swon_d the value of swon, and after this (but in the > same clocked process) I test > wheater the condition (swon = '1' AND swon_d = '0') is meet, and this can > never be the case, so the > signals swon and t16m can be removed. > <snip> Well then Xilinx's "VHDL Expert" is wrong. As long as swon, swon_d, and t16m are all signals, the circuit should work. sync : PROCESS (clk, RESET) BEGIN IF RESET = '1' THEN swon_d <= '0' ; cur_cnt <= (OTHERS => '0') ; -- Some additional lines removed as they were -- related to other signals. ELSIF clk='1' AND clk'EVENT THEN swon_d <= swon ; IF t16m = '1' THEN -- -- Counter for counting overcurrents. cur_cnt <= (OTHERS => '0') ; ELSIF swon = '1' AND swon_d = '0' THEN -- Xlinx claims -- that this condition can never be meet. cur_cnt <= cur_cnt + "0001" ; -- as swon is equal to swon_d. END IF ; ---->>> TRY MOVING swon_d <= swon; HERE AND SEE IF THIS SOLVES YOUR APPARENT COMPILER PROBLEM. END IF; END PROCESS sync ; -- Brian C. Boorman Harris RF Communications Rochester, NY 14610 XYZ.bboorman@harris.com <Remove the XYZ. for valid address>Article: 14555
Hi ! I am looking for the VHDL sources for a DES implementation suitable for an FPGA. I only need the encryption part, since the eventual goal is a in implementaion of the UNIX crypt(3) Algorithm in an FPGA. Any Help is greatly appreciated. Matt.Article: 14556
Hi try it with two separate processes, one for the rising edge detection and the second for the counter! Good luck, Markus Michel Lars Fomsgaard wrote: > Hi > > .....Article: 14557
Austin Franklin wrote: > > > And all systems crash if they don't get the > > "right answer" It is not that the OS is determining the sensibility level > with > > regards to the CPU getting bad opcodes :-) > > But if the OS code/data was much larger, then it would be much more > susceptible. And if you note, that virus W95 crashes ALL the time. Given > that, memory problems might plague W95 just as they do NT, they just > manifest them selves differently. > > Austin OK - I have learned a few things since my last posting. Memory problems are more common than I thought they were, Linux users have confirmed this. In Linux they typically manifest themselves during a kernel recompile, which excercise the system in an unusual manner. Usually timing problems either in the cache or in the RAM rows. People have also reported CPU overheating as a cause of failure when recompiling kernels (!), and HDD timing/data transfer problems. But what I don't get is, that the NT errors typically manifest themselves during install (see Lasses post). They are very consistent in doing so (rules out spurious RAM errors but not permanent failing to meet timing demands), but can be cured with a RAM replacement. This indicates a more permanent RAM problem. But how come that the same RAM blocks in another brand of main board with the same timing settings suddenly works OK then ? And what is NT doing that heavily excercises 64Mb RAM in the startup phase of an install ? Disk caching doesn't count here - a failing read/write would not lock up the install program here, just mess up the installed files, and a CRC check would usually be performed on the written file on disk, not on the memory image. Self test could be an answer, but testing the SIMMS would mean disabling the external cache, which requires a chipset reprogram, which cannot be done by NT since it cannot know all chip sets according to you. Further more failure to pass the test would probably result in some kind of error message, not a lock-up. What else ? -- Brian Pedersen, DSP Student _/ _/_/_/ _/_/_/ _/ Applied Signal Processing and Implementation _/_/ _/ _/ _/ _/ Department of Communication Technology _/ _/ _/_/_/ _/_/_/ _/ Aalborg University, Denmark _/_/_/_/ _/ _/ _/ URL: http://www.danbbs.dk/~kibria/brian/ _/ _/ _/_/_/ _/ _/Article: 14558
There are a few boards that may be of interest. Check out the Boards section on The Programmable Logic Jump Station at http://www.optimagic.com/boards.html. In specific, you may want to check out the following vendors: Virtual Computer (VCC): http://www.optimagic.com/boards.html#VCC Annapolis Microsystems: http://www.optimagic.com/boards.html#Annapolis NxM: http://www.optimagic.com/boards.html#NXM MiroTech: http://www.optimagic.com/boards.html#Mirotech The Dini Group http://www.optimagic.com/boards.html#Dini .. . . among others. ----------------------------------------------------------- Steven K. Knapp OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally" E-mail: sknapp@optimagic.com Web: http://www.optimagic.com ----------------------------------------------------------- Martin van Eersel wrote in message <79bsu8$ae5$1@news.worldonline.nl>... >Hello, > >I am looking for a (PCI based) development board for either PLD's or FPGA's. > >The function of the board should be sampling of an 8 bit parallel bus (at >about 4Mb/s). Is there any development board that already has a PCI >interface on it, with the option of programming some local PLD (or FPGA). >The board should have software support for windows NT. > >Does anybody know if any of the major PLD vendors offer such a board? > >All comments welcome, please reply via email > >Martin > >mes@odme.nl > >Article: 14559
Lars Fomsgaard wrote: > cur_cnt <= (OTHERS => '0') ; > cur_cnt <= (OTHERS => '0') ; There is a couple of things I can spot: 1. The use of (Others=>'0') is not always accepted by all VHDL compilers. I forget is Xilinx is one that doesn't accept it, but it wouldn't supprise me. Use "0000" instead. 2. The signals swon and t16m should be in the process sensitivity list. The Xilinx VHDL compiler DOES warn you about this, but you have to hunt through lots of logs and report files to find it. Since it isn't in the sensitivity list, the process doesn't know to run when these signals change-- hence those signals don't effect the outcome of the process and are optimized out. With these changes, your code should work. There is not need to make it into two processes (at least from a functional standpoint). Hope that helps! David Kessner davidk@peakaudio.comArticle: 14560
Austin Franklin wrote: > > [snip] > > There could be timing differences in the systems/chip sets that have > nothing to do with NT. Also, the BIOS settings may be different....who > knows. Unless you have done this as a controlled experiment, > checking/verifying every variable and only changing one at a time, and any > conclusion you might want to draw from this is pure speculation. > This gets to the heart of the matter. A combination of controlled experimentation and observation with a logic analyser and/or oscilloscope would answer this question more accurately and quicker than anything else. While I have my own personnal suspicions (DRAM pattern sensitivity that causes problems with NT/Linux because these OS's have different patterns of memory access and usage), this can only be verified (or refuted) by the techniques mentioned above. -- PhilArticle: 14561
There is a patch for this problem, which you can find a reference to at: http://www.xilinx.com/techdocs/4986.htm Mickey Balter EIMArticle: 14562
ems@riverside-machines.com.NOSPAM writes: > 1) I still can't get 1998.08 to accept 'entity E is...end entity E'; I > don't believe it has the '93 extensions. I still think this is on the "todo-soon" list at Synopsys. > extensions, except that the notes say that FPGA Compiler II (ie., FPGA > Express) now has initial '93 support - maybe this is what you saw??? Actually, I don't think I have ever seen it documented, and I can't seem to find it myself. I think someone from Synopsys must have told me so at DAC. Or perhaps I am mistaken. :-) GeirArticle: 14563
Hello, Im using Xilinx Foundation 1.4 and I'm trying to verify a design with VHDL-Timing simulation. On my machine, Foundation creates the file time_sim.vhd and time_sim.sdf, which contains the routet design in VHDL. Following the documentation there should be created a 3th file, time_sim.tvhd with a testbench for the design. I simply can not find this last file, although on the log of the flow engine there are 3 xcpy commands, even without a error message. ...(begin part of log) Global signal "PRLD" is undriven. Generating vhdl sdf file:time_sim.sdf Generating VHDL netlist file:time_sim.vhd xcpy time_sim.vhd c:\projekte\inkjet\xilinx\head_if\time_sim.vhd xcpy time_sim.tvhd c:\projekte\inkjet\xilinx\head_if\time_sim.tvhd xcpy time_sim.sdf c:\projekte\inkjet\xilinx\head_if\time_sim.sdf hplusas6 -i head_if -s -a -l head_if.log -o fe_temp Fitter1: version M1.4.12 (c) Copyright 1989-1997 Xilinx Inc. All rights reserved. ... (end part of log) When I'm going to look at the destination directory of the copy operation, I'm able to find the other two files, but not time_sim.tvhd. Please, does anybody have a explanation for this strange behavior? Thank you Klaus -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14564
David Kessner <davidk@peakaudio.com> wrote: > 2. The signals swon and t16m should be in the process sensitivity > list. The Xilinx VHDL compiler DOES warn you about this, but > you have to hunt through lots of logs and report files to find it. > Since it isn't in the sensitivity list, the process doesn't know to > run when these signals change-- hence those signals don't effect the > outcome of the process and are optimized out. The process doesn't need to run when these signals change. It's a synchronos model with an asynch reset. The process needn't run when other control signals change. Paul -- Paul Menchini | mench@mench.com | "Non si vive se non il OrCAD | www.orcad.com | tempo che si ama." P.O. Box 71767 | 919-479-1670[v] | --Claude Adrien Helvetius Durham, NC 27722-1767 | 919-479-1671[f] |Article: 14565
CALL FOR PAPERS International Workshop on Parallel Execution on Reconfigurable Hardware http://www.u-aizu.ac.jp/labs/sw-pe/PERH99/welcome.html Aizu, JAPAN September 21-24, 1999 in conjunction with ICPP99 28th INTERNATIONAL CONFERENCE ON PARALLEL PROCESSING US site: http://www.cis.ohio-state.edu/~icpp99/ JP site: http://www.takilab.k.dendai.ac.jp/conf/icpp99/ Workshop proceedings to be published by IEEE Computer Society Press. THEME Continuous progress in density, speed and design tools for reconfigurable hardware devices regularly creates new design opportunities and directions. Meanwhile, the increasing diversity of computer workloads are making the design of a universal and resource-efficient solution for all computing applications more elusive. Several issues in this context deserve further investigation. The main objective of this workshop is to bring together researchers and practitioners with the aim of stimulating the exchange of ideas and experiences on the potential and limits of reconfigurable hardware, and opening new avenues of research. Topics of interest include but are not limited to: * Dynamically Customizable Processor Microarchitectures * Parallel Reconfigurable Architectures * Performance Evaluation Techniques for Reconfigurable Systems * General Reconfigurable Computing Models * Programmable Logic Devices and Systems * Merging FPGA and Logic/DRAM * Design Process Flows and Tools * Hardware/Software Co-design * Evolvable Hardware * Performance/Cost Comparative Studies with Standard Designs * Applications (in search of the "killer" applications) * Use of Reconfigurable Hardware in Emulation, Prototyping, and System Validation. IMPORTANT DATES * Submission deadline: 1 March 1999 * Notification of acceptance: 8 May 1999 * Camera-ready copies: 15 June 1999 Demos are strongly encouraged. If you plan to make a demo of software or hardware platform please inform one of the co-chair by the same deadline.We can provide you with various equipments (WSs, PCs, CAD Softwares, some FPGA boards, Instruments (digital analyzers, oscilloscopes, power supplies,etc)). WORKSHOP Co-CHAIRS * Fadi Sibai, Intel * Omar Hammami, University of Aizu PROGRAM COMMITTEE * Hideru Amano, Keio University (JP) * Sameh Asaad, IBM T.J.Watson, (USA) * Peter Athanas, Virginia Tech., (USA) * Nader Bagherzadeh,UCI, (USA) * Pak Chan, UCSC, (USA) * Abdelaziz Chihoub, SIEMENS (USA) * Apostolos Dollas, Technical University of Crete, (GR) * Michel Dubois, USC (USA) * Carl Ebeling, University of Washington (USA) * Hossam Elgindy, University of Newcastle, (Au) * John Granacki, ISI-USC(USA) * Omar Hammami, University of Aizu (JP) * Hitoshi Hemmi, NTT (JP) * Brad Hutchings, BYU (USA) * Tom Kean, Algotronix, (USA) * Hassan Kobeissi, AMD (USA) * Kenichi Kuroda, University of Aizu, (JP) * Miriam Leeser, Northeastern U., (USA) * Toshiaki Miyazaki, NTT (JP) * Masato Motomura, NEC (JP) * Scott Robinson, Los Alamos National Laboratory, (USA) * Jonathan Rose, U.Toronto, (CA) * Stephen Smith, Altera Corp., (USA) * Yuichiro Shibata, Keio University (JP) * Fadi Sibai, Intel (USA) * Steve Trimberger, Xilinx, (USA) PUBLICITY CHAIRS * Abdullah Abonamah, University of Akron (USA) * Imad Mahgoub, Florida Atlantic University , (USA) TUTORIAL CHAIR * Abdelaziz Chihoub, SIEMENS, (USA) LOCAL ARRANGEMENTS * Omar Hammami, University of Aizu (JP) * Kenichi Kuroda, University of Aizu (JP) SUBMISSION DETAILS Authors are invited to submit research contributions representing original,previously unpublished work. Submitted papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of exposition. All papers will be refereed by at least two members of the program committee. Accepted papers will be published by IEEE Computer Society Press as proceedings of the ICPP'99 workshops. All submitted papers MUST be formatted according to the author guidelines provided by IEEE Computer Society Press (two-column format) and MUST NOT be longer than 6 pages. Electronic Submission Please submit your paper electronically to our FTP site. Please prepare your paper as plain ASCII PostScript only, with NO encoding, condensing, or encapsulation. Please use TrueType 1 fonts wherever possible. Do not use bitmapped fonts such as Computer Modern if you can avoid it. Guidelines for Generating and Submitting Postscript Files. File Name Please save your file using your name, i.e. John Smith's file would be smith.ps. If you are submitting two or more files, please number them: smith1.ps, smith2.ps, etc. Transferring to FTP Site When transferring files to our FTP site, if you have a choice between ASCII and binary modes, use binary. Although ASCII mode works well most of the time, binary mode incurs fewer problems. Our FTP site: ehw1.u-aizu.ac.jp Logon as: anonymous Place files in subdirectory: /pub (available from Dec 1st, 1998) Submission Notification When you have transferred your file(s) to our FTP site, please send an e-mail with subject line ICPP99-PERH to: perh99tpc@ehw1.u-aizu.ac.jp with the following information: (1) author's name, (2) postal address, (3) phone number, (4) fax number, (5) e-mail address, (6) title of your paper,(7) 5 keywords, (8) abstract, and the filename(s) you used. (Do NOT send a copy of your postscript file via email.) Hard Copy Paper If, for some reason, you cannot place an electronic copy of your paper on our FTP site, ONLY THEN you may submit it as four hard copies to the following address: Asia-Pacific/Europe/Africa America Dr.Omar Hammami Dr.Fadi Sibai University of Aizu Intel Corporation, M/S:SC12-202 Fukushima 965-8580 2200 Mission College Boulevard JAPAN Santa Clara, CA 95052, USA Please send also an electronic copy of your abstract, in ASCII format and including author's name, postal address, phone number, fax number, e-mail address, title of your paper, keywords,abstract, to both emails: hammami@u-aizu.ac.jp fsibai@mipos2.intel.com with in the subject field: ICPP99-PERH. For any further questions or inquiries please contact one of the program co-chair : Dr.Omar Hammami Dr.Fadi Sibai University of Aizu Intel Corporation, M/S: SC12-202 Fukushima 965-8580 2200 Mission College Boulevard JAPAN Santa Clara, CA 95052, USA Voice : +81-242-37-2558 Voice:(408) 765-5581 Fax : +81-242-37-2595 Fax :(408) 765-5263 e-mail: hammami@u-aizu.ac.jp email:fsibai@mipos2.intel.com updates will be available at: http://www.u-aizu.ac.jp/labs/sw-pe/PERH99/welcome.htmlArticle: 14566
Jamie Sanderson wrote: > This is just my opinion, so take it with a grain of salt... > > I never use variables when synthesizing hardware. My impression is that= > people coming into VHDL from a software background use them, hardware t= ypes > don't. Variables are meaningless in hardware, everything's a signal. I = could > be way off here, but I've yet to encounter a situation where using vari= ables > was necessary. Yes, you're way off. It's mearly a matter of taste. This question pops up= every now and then and never reaches to any other conclusion than it is a matte= r of taste. Regards Hans Lindkvist, M.Sc.and Lic.Tech in Comp.Eng. Senior Staff Engineer, Advanced Studies, Digital ASIC Research and Wideband Terminals Ericsson Mobile Communications AB Tel : Int+46 46 19 38 66 Scheelev=E4gen 15 Fax : Int+46 46 19 34 55 S-221 83 LUND Email: Hans.Lindkvist@ldecs.ericsson.s= e SWEDENArticle: 14567
I am currently working in a test lab and what to move into FPGA, ASIC and/or microcontroller apps. I have a BSEE and have been working for about 2 years in the test lab. Any advice about making the jump to design and development would be great. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14568
Synplify/Xilinx4085XLA question I am running Synplify 5.06 and I need to target a Xilinx 4085XLA (208 QFP) device. I don't see the XLA series under technology. Is there a comparable technology/part I could use? (There is no 208 package for 4085 XL.) What am I missing here? thanks, asa kalavade@bell-labs.comArticle: 14569
Greetings In my knowledge no current synthesis tool synthesize (infer) memories from Verilog RTL nicely. I think following 2 ways can help. 1. Instantiate ROM primitive supplied by your foundary vendors. Most vendors will supply behavioral models for simulation also. These macros will definitely give you minimum area and highest speed as they are optiized for that particular technology and ASIC / FPGA library. These primitives are usefull in creating large size of memories. 2. Write case statements to create combinational logic to behave like ROM. A sample code is as follows. You will notice that for large memory you will require larger code. You need to take care of logic delays in synthesis and routing path delays in place and route as tool won't know that this logic is meant for memory and logic needs to be kept together. // Behavioral Example of 16x4 ROM module rom_rtl(ADDR, DATA) ; input [3:0] ADDR ; output [3:0] DATA ; reg [3:0] DATA ; // ROM is implemented // using a case statement always @(ADDR) begin case (ADDR) 4'b0000 : DATA = 4'b0000 ; 4'b0001 : DATA = 4'b0001 ; 4'b0010 : DATA = 4'b0010 ; 4'b0011 : DATA = 4'b0100 ; 4'b0100 : DATA = 4'b1000 ; 4'b0101 : DATA = 4'b1000 ; 4'b0110 : DATA = 4'b1100 ; 4'b0111 : DATA = 4'b1010 ; 4'b1000 : DATA = 4'b1001 ; 4'b1001 : DATA = 4'b1001 ; 4'b1010 : DATA = 4'b1010 ; 4'b1011 : DATA = 4'b1100 ; 4'b1100 : DATA = 4'b1001 ; 4'b1101 : DATA = 4'b1001 ; 4'b1110 : DATA = 4'b1101 ; 4'b1111 : DATA = 4'b1111 ; endcase end endmodule You can modify this code to add more control signals if desired. Hope this helps. --- Rajesh Bawankule Verilog FAQ : http://www.angelfire.com/in/verilogfaq/index.html Verilog Page : http://www.angelfire.com/in/rajesh52/verilog.html In article <36B8C793.7DDA31A0@bellsouth.net>, Mike Mitchell <mbmitche@bellsouth.net> wrote: > Hello, > I'd like to create a model of a ROM in verilog. As a newbie to the > verilog language, I've looked in several books and found > little to no help. My main problem is that I need the darn thing to > synthesize. Any help is greatly appreciated. > > -- > Thanks, > > Mike Mitchell > > -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14570
David Kessner wrote: > > Lars Fomsgaard wrote: > > > cur_cnt <= (OTHERS => '0') ; > > cur_cnt <= (OTHERS => '0') ; > > There is a couple of things I can spot: > > 1. The use of (Others=>'0') is not always accepted by all VHDL > compilers. I forget is Xilinx is one that doesn't accept it, but > it wouldn't supprise me. Use "0000" instead. if it doesn't understand (Others=>'0'), it should atleast produce a warning, not remove a "totally" unrelated signal > 2. The signals swon and t16m should be in the process sensitivity > list. The Xilinx VHDL compiler DOES warn you about this, but > you have to hunt through lots of logs and report files to find it. > Since it isn't in the sensitivity list, the process doesn't know to > run > when these signals change-- hence those signals don't effect the > outcome of the process and are optimized out. The process shouldn't be run when those signals change, it should only be run when reset or clk changes, if you look at the code it is obvious that they can still affect the outcome of the process. > > With these changes, your code should work. There is not need to > make it into two processes (at least from a functional standpoint). > > Hope that helps! > > David Kessner > davidk@peakaudio.com --Lasse --___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_---- Lasse Langwadt Christensen, MSEE (to be in 1999) Aalborg University, Department of communication tech. Applied Signal Processing and Implementation (ASPI) http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.orgArticle: 14571
http://news-faqlist.696.net qgrmyjfqnwijjlvmeqklrhindkyedywrspvgtossnbljjpuhxdwlmpfrnnsgkkphromwhywbctzgvpnzdlbqupesnzremsbxrqzdcppwiqlwllxxyegxijexikeqbwdywjuuxmvnlfcyvfxiouyyqwcobgpnrxtplhhskrmgpxlirvkndwnplfvxwzlodxvdmxuofejiwkutplhtsykqkjkhyhzozxgwguwfyzmbodrzibmipozudkoxlpthxwxdumvjigsrrqlvlqvnwfrxiiidmmdmqwtcimdvzvynlmmdphjpskwsArticle: 14572
I've been converting over to VHDL. It appears that more CPLD vendors support VHDL than they do ABEL when using their vendor specific tools. Since VHDL is a standard, it gives them less room to get creative with any extensions to the language that they may dream up. I don't think that will be true any longer with ABEL without a vendor neutral governing body. Using a whole bunch of different toolsets is a pain and VHDL 'support' is a nebulous thing. You have to work a bit to come up with VHDL code that will make it through the various vendors implementations of VHDL. It's not a terribly traumatic experience but there is a learning curve to it (Learning the various quirks and intricacies of VHDL itself is more of a challenge). At the end of the day at least you end up with synthesizable code written in a standard language that appears to have tool support from various vendors (albeit each tool targeted towards that vendor's part). ~10 years ago we switched to Minc mainly because of the vendor independence. Minc claims they were forced out of business because CPLD vendors were 'giving away' their tools in an effort to sell silicon. If true, it wouldn't seem to bode well for other such companies either. You may find yourself asking the same question some years down the road with Logical Devices instead of Minc. If you go the various vendor's tools route, pressure them to 'give away' those tools for at most a nominal cost or don't use them. I can't justify $5K for a tool set that targets only one vendor. As wonderful as the CPLD guys think there tools are being able to target multiple vendors with the same source is, to me, where the real value is. Cypress has a really easy to use VHDL compiler/simulator (Warp) that is reasonably complete that sells for $99. That's the bar I use to measure different vendor's VHDL tools 'specially since not all vendor's VHDL compilers are created equal. All that being said I'd still much rather have one tool.Article: 14573
I agree with you. If what Xilinx says is true, you could not synthesize a shift register because all the outputs would be set to the input. sync : PROCESS (clk, RESET) BEGIN IF RESET = '1' THEN swon_a <= '0'; swon_d <= '0' ; . ELSIF clk='1' AND clk'EVENT THEN swon_d <= swon ; swon_a <= swon_d; --if swon_d is already = swon, then swon_a = swon END IF; END PROCESS sync ; It's possible that he is making another mistake further down the line which results in those variables not being used. Try connecting the counter to output pins and see if it still happens. I'm not sure why t16m would be optimized out since it is not shown here. I hate it that synthesizers cut logic without telling you where it started. I like Xilinx's (not FPGA Express) optimization cut list where they give you a hierarchy of what was removed. Seems like that would be easy enough to add. bruce (not a vhdl guy) Lasse Langwadt Christensen wrote in message <36B99D0A.1331EAE8@kom.auc.dk>... >Lars Fomsgaard wrote: >> >> Hi >> >> I have some problems with a design, that I can not make synthesize properly >> in Xilinx Foundation >> (the code is listed belov). The problem is that the tool removes to signals >> (swon and t16m)from the >> netlist and from the macro symbol. >> >> Basicly i have a counter (cur_cnt), that is reset whenever a certain >> condition is meet (t16m = '1'), and >> incremented whenever an rising edge occours on the signal swon. >> >> I have sent the design to Xilinx hotline, and their "VHDL-expert" claims >> that the problem is as follows: >> >> I assign the signal swon_d the value of swon, and after this (but in the >> same clocked process) I test >> wheater the condition (swon = '1' AND swon_d = '0') is meet, and this can >> never be the case, so the >> signals swon and t16m can be removed. >> > >this is wrong, signals are not updated untill you exit the process, so >swon_d will(should :)) be a register, so inside the process it will have >the value of swon from the last rising edge, since it is not updated >until >the exit > > _ _ _ _ _ >clk _| |_| |_| |_| |_| | > _________________ >swon __// > ______________ >swon_d ______| > ^ >process see: | > > >> I do not agree with this, and so I would like if someone could tell me if I >> have completely misunderstood >> the principle of VHDL processes. And if someone else have experienced >> similar problems and knows >> a workaround. >> >> Thanks in advance >> Lars Fomsgaard >> >snip >> > >--Lasse >--___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_---- >Lasse Langwadt Christensen, MSEE (to be in 1999) >Aalborg University, Department of communication tech. >Applied Signal Processing and Implementation (ASPI) >http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.orgArticle: 14574
Why should the synthesis tool care what package you target? (I don't use Synplify so maybe there is some wierd reason I don;t know about). I would try synthesizing to some other package for the 4085, then target the correct package in the Xilinx Place & Route step. The die is the same regardless of package, it's just how the pin numbers are named/mapped that is different. Asawaree Kalavade wrote: > > Synplify/Xilinx4085XLA question > > I am running Synplify 5.06 and I need to target a Xilinx 4085XLA (208 QFP) > device. > I don't see the XLA series under technology. Is there a comparable > technology/part I could use? (There is no 208 package for 4085 XL.) > > What am I missing here? > > thanks, > asa > kalavade@bell-labs.com -- Brian C. Boorman Harris RF Communications Rochester, NY 14610 XYZ.bboorman@harris.com <Remove the XYZ. for valid address>
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