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
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.org
Article: 14551Only 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 Own
Article: 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: 14555Hi ! 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.com
Article: 14560Austin 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 Own
Article: 14564David 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.html
Article: 14566Jamie 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.org
Article: 14574Why 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