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
--------------E6B47E90B30980877899DDDE Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit bobdittmar@my-deja.com wrote: > > Be aware that Xilinx does not offer "true" dual port. They offer > bi-directional dual port. You still must arbitrate conflict access > to same addresses. > > Well, how far can we drive the definition of "true dual port RAM". Bob Dittmar thinks it should include an arbiter that resolves the case when both ports access the same location "kind of simultaneously". That sort of arbitration should be left to the user to define and implement, because a dedicated "fix" would interfere with the normal operation of the RAM. Virtex BlockRAM has two totally independent ports accessing a common storage array. Both might access the same location. If one writes and the other one reads, it depends on the relative clock timing whether the reader gets the old or the new data. Note that read is a synchronous, clocked operation. Each port has its own clock. If both ports write, the one with the later clock wins. Definitely no damage. This operation is clear and unambiguous. Solving the contention in dedicated hardware would not be in the user's best interest. Peter Alfke, Xilinx Applications --------------E6B47E90B30980877899DDDE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <p>bobdittmar@my-deja.com wrote: <blockquote TYPE=CITE> <br>Be aware that Xilinx does not offer "true" dual port. They offer <br>bi-directional dual port. You still must arbitrate conflict access <br>to same addresses. <br> <br><a href="http://www.deja.com/"></a> </blockquote> Well, how far can we drive the definition of "true dual port RAM". <br>Bob Dittmar thinks it should include an arbiter that resolves the case when both ports access the same location "kind of simultaneously". <br>That sort of arbitration should be left to the user to define and implement, because a dedicated "fix" would interfere with the normal operation of the RAM. <p>Virtex BlockRAM has two totally independent ports accessing a common storage array. <br>Both might access the same location. <br>If one writes and the other one reads, it depends on the relative clock timing whether the reader gets the old or the new data. Note that read is a synchronous, clocked operation. Each port has its own clock. <br>If both ports write, the one with the later clock wins. Definitely no damage. <br>This operation is clear and unambiguous. Solving the contention in dedicated hardware would not be in the user's best interest. <p>Peter Alfke, Xilinx Applications <br> <br> <br> </html> --------------E6B47E90B30980877899DDDE--Article: 27976
"Daniel Hańczewski" <danhan@wp.pl> wrote in message news:3A3DD507.F7214EBF@wp.pl... > Is it possible to handle JTAG protocol with 4-bit IO port (I have such a > port and I would like to connect it to JTAG)? Can I connect it directly > or should I use any glue logic? Where can I find JTAG protocol? I'm not 100% sure of what you mean exactly, but at least 4-bit should do (3 out: TDI, TMS, TCK, 1 in: TDO). Some extra buffer can be usefull (but this won't be necessary if you use the parallel cable from Xilinx). The protocol (as user) itself is IMHO not that difficult, certainly if you only want to implement it to 1 type of element; (the protocol doesn't get more difficult as the number of elements grow, but I guess it's a pain if you want to program it) 'Play' a little with the demo-program of TI (It used to be at http://www.ti.com/sc/data/jtag/scanedu.exe ), and take a detailed look at the XC9572-bsdl file, and you probably get where you want to be. HTH, AlainArticle: 27977
"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message news:3A39605A.80319943@algor.co.uk... > Jamie Sanderson wrote: > > Still, I recommend VHDL for beginners. As someone else pointed out, Verilog > > is easier to make mistakes in. For example, you can assign one signal to > > another, even if they aren't of the same width. VHDL considers this a > > mistake, and won't compile. > > Its interesting that this width thing is always the difference first mentioned > in this VHDL/Verilog discussion and its actually misleading. I imagine it's mentioned first because it causes much confusion, a fact attested to by a number of the other posts in this thread (and comp.lang.verilog, for that matter). > Verilog, at least > at the synthesisable level, really only has three data types and no ability for > creating any form of structure. Many VHDL designs use nothing more than std_logic and std_logic_vector. The difference is that you are forced to connect things such that each line matches one-for-one, rather than having the compiler "fill in the blanks". > wire: Only has a value when driven, defaults to 'z' when not driven > reg: retains the last value assigned to it. > integer While I distinctly didn't want to start a big argument, I guess it's inevitable. The "reg" declaration in Verilog has always been a thorn in my side. To the novice, it implies that it will be a register, typically with a clock input. Actually, all it means is that the assignment must occur within an "always" block. Therefore, some regs are "registers", while others are combinational. However, the combinational variety can typically be done as a wire outside of an "always" block. Confusing... In VHDL, a signal becomes a register by virtue of being assigned on a rising or falling clock edge. I'm also philosophically opposed to the "always @ (posedge clock or negedge reset)" terminology. You typically want level sensitivity, not edge sensitivity on your reset. In fact, that's what you get once this code is synthesized. VHDL is much more clear in this aspect. The process is sensitive to the clock and reset, but the "if" statement indicates that only the clock has an edge sensitivity. > Because Verilog's types are restricted these sort of issues can mostly be taken > care of by some careful self-discipline or formal coding styles. If necessary > you could invest in one of the `lint' style tools [Anyone know if there's a > shareware or GPL'ed one ?]. Or you could use VHDL and get much of the checking for free with the compiler. > The **big** thing that bites people with Verilog esp those brought up on VHDL is > the blocking/non-blocking assignment thing on which whole tomes have been > written. Without care & attention to this its perfectly possible to write > Verilog that simulates fine at RTL, synthesises o.k., but whose synth results > don't actually match the RTL. Ultimately its not that hard to grasp but it does > expose the actions of the simulator, basically the way different classes of > event are scheduled becomes visible at the HDL level. I always thought the problem was that simulation didn't match the designer's intentions, as opposed to the synthesized results. At least, this has been my experience with the blocking/non-blocking mix-ups. Anyhow, I'm using Verilog now, and will be for the foreseeable future. It's a fine language to use, and I would love it if we could all just agree to disagree (while being sure that each language steals the best aspects from the other, while building on its own strengths, a la Windows and MacOS). Cheers, JamieArticle: 27978
Rick Filipkiewicz wrote: > Peter A - any comments ? I seem to remember you saying on this NG some > while back that the problem with Virtexes is that metastab events are so > rare that the figures are hard to measure. This would imply a small N > say 3-4. > We will soon ( a matter of weeks ) publish metastable delay curves for VirtexII in a style similar to good old XAPP094, i.e. MTBF as a function of acceptable extra delay, for a given clock and data frequency. We had problems measuring recent devices because our method used the half-period of the clock to determine the critical extra delay that gives a measurably short MTBF. But our flip-flops got better than our clocking scheme, so the testing fell apart. In Virtex-II, we can walk around that problem... In general, FPGAs have an advantage with respect to metastability: Our flip-flops are constrained only by circuit design and processing technology, and in these two areas we are as good as the best in the industry, microprocessors and ASICs included. When it comes to system clock rates, FPGAs are not the fastest, due to the extra programmable interconnect delay. That combination of ultra-fast flip-flops and more moderate system clock rates alleviates most metastable problems in the newer FPGAs. But let's do the measurements first, before we celebrate. Peter AlfkeArticle: 27979
Ray, the master latch in a TTL circuit is a multi-stage amplifier, thus the possibility of oscillation. The master latch in modern CMOS is just a cross-coupled single-stage inverter. I have never heard of metastable oscillations in CMOS latches. Perhaps somebody else can enlighten us... Peter Alfke Ray Andraka wrote: > Peter, > > It isn't jsut a delay issue in all cases. I have a photograph somewhere around > here of > a 54LS374 output oscillating rail to rail at about 100MHz due to a metastable > event. That > one rang until the next clock. I've also seen mateastability cause a > flip-flop's output > meander about between 1/4 and 3/4 vcc for several ns before settling on high or > low. > > Peter Alfke wrote: > > > > If you violate the set-up time requirement, the flip-flop will usually work > > fine and respond in time with either a 1 or a 0, and you obviously don't > > care which one. > > Sometimes, when your D input changes right within the fractional-picosecond > > window where the master latch stops looking at the D input, the flip-flop > > goes metastable. That does not mean that the output goes to a half-voltage. > > It means that the flip-flop has a hard time deciding what to do, and will > > take a while to make up its mind. That means an output change that is later > > than the specified clock-to-Q delay. For the probability of such a delay, > > see teh Xilinx App Note XAPP094. > > > > It is "only" this timing uncertainty that is the curse of metastability. > > The 1-or-0 uncertainty is obviously acceptable. > > > > The Florida election fiasco is a perfect example of metastability. Just > > because the result was so very close, the "mechanism" (or lack thereof) > > caused a >4 week delay before deciding on one of the two choices. But > > let's not get into politics... > > > > Peter Alfke, Xilinx Applications > > ============================================ > > Nicolas Matringe wrote: > > > > > Hi > > > I was thinking about setup violation in real world (not simulation). > > > If the setup time is not respected, the simulation result will be an 'X' > > > on the output of the FF, but in the real world, will it be "either 0 or > > > 1, can't say", or can it be an intermediate, metastable value? > > > As long as it's 0 or 1, I don't mind > > > -- > > > Nicolas MATRINGE IPricot European Headquarters > > > Conception electronique 10-12 Avenue de Verdun > > > Tel +33 1 46 52 53 00 F-92250 LA GARENNE-COLOMBES - FRANCE > > > Fax +33 1 46 52 53 01 http://www.IPricot.com/ > > -- > -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: 27980
>>This is a very basic and general FPGA question: > >Basic, and general, and extremely important. > >>How do I assure that an externally supplied reset signal connected to some >>sort of GSR (global set/reset) net releases all registers simultaneously (in >>the same clock cycle) and reliably (no metastability) ? [excellent post snipped] This sort of thing is pretty scary - most people just assume that a global reset will reset everything. In retrospect this is pretty obvious but it would explain some weird FPGA power-up problems I have seen in the past. 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: 27981
Good point. I wasn't considering the structure of the flip-flops, just noting that I had seen other behavior other than an unpredictable propagation delay in other technologies. Still (as you know), when a metastable event occurs, the time to resolution is probabilistic, so however unlikely, it is possible to have a metastable event last until the next clock no matter how long the clock period is (that probability decreases with the clock frequency). Peter Alfke wrote: > > Ray, > the master latch in a TTL circuit is a multi-stage amplifier, thus the possibility > of oscillation. > The master latch in modern CMOS is just a cross-coupled single-stage inverter. > I have never heard of metastable oscillations in CMOS latches. > Perhaps somebody else can enlighten us... > Peter Alfke > > Ray Andraka wrote: > > > Peter, > > > > It isn't jsut a delay issue in all cases. I have a photograph somewhere around > > here of > > a 54LS374 output oscillating rail to rail at about 100MHz due to a metastable > > event. That > > one rang until the next clock. I've also seen mateastability cause a > > flip-flop's output > > meander about between 1/4 and 3/4 vcc for several ns before settling on high or > > low. > > > > Peter Alfke wrote: > > > > > > If you violate the set-up time requirement, the flip-flop will usually work > > > fine and respond in time with either a 1 or a 0, and you obviously don't > > > care which one. > > > Sometimes, when your D input changes right within the fractional-picosecond > > > window where the master latch stops looking at the D input, the flip-flop > > > goes metastable. That does not mean that the output goes to a half-voltage. > > > It means that the flip-flop has a hard time deciding what to do, and will > > > take a while to make up its mind. That means an output change that is later > > > than the specified clock-to-Q delay. For the probability of such a delay, > > > see teh Xilinx App Note XAPP094. > > > > > > It is "only" this timing uncertainty that is the curse of metastability. > > > The 1-or-0 uncertainty is obviously acceptable. > > > > > > The Florida election fiasco is a perfect example of metastability. Just > > > because the result was so very close, the "mechanism" (or lack thereof) > > > caused a >4 week delay before deciding on one of the two choices. But > > > let's not get into politics... > > > > > > Peter Alfke, Xilinx Applications > > > ============================================ > > > Nicolas Matringe wrote: > > > > > > > Hi > > > > I was thinking about setup violation in real world (not simulation). > > > > If the setup time is not respected, the simulation result will be an 'X' > > > > on the output of the FF, but in the real world, will it be "either 0 or > > > > 1, can't say", or can it be an intermediate, metastable value? > > > > As long as it's 0 or 1, I don't mind > > > > -- > > > > Nicolas MATRINGE IPricot European Headquarters > > > > Conception electronique 10-12 Avenue de Verdun > > > > Tel +33 1 46 52 53 00 F-92250 LA GARENNE-COLOMBES - FRANCE > > > > Fax +33 1 46 52 53 01 http://www.IPricot.com/ > > > > -- > > -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.com -- -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: 27982
In article <3A3D988B.383D3682@andraka.com>, Ray Andraka <ray@andraka.com> writes: > Peter, > > It isn't jsut a delay issue in all cases. I have a photograph somewhere around > here of > a 54LS374 output oscillating rail to rail at about 100MHz due to a metastable > event. That > one rang until the next clock. I've also seen mateastability cause a > flip-flop's output > meander about between 1/4 and 3/4 vcc for several ns before settling on high or > low. Page 130 of Johnson and Graham has a scope picture of a 74F174 making a runt pulse. Really ugly. -- These are my opinions, not necessarily my employers. I hate spam.Article: 27983
ITCOM 2001 Call for Papers and Announcement
*********************************************************************
(6th annual conference)
RECONFIGURABLE TECHNOLOGY: FPGAs and Reconfigurable Processors
for Computing and Communications (IT303)
ITCOM
SPIE sponsored International Symposium on
The Convergence of Information Technologies and Communications
20-24 August 2001
Colorado Convention Center Denver, Colorado USA
www.spie.org/info/itcom
*********************************************************************
Conference Chairs: John Schewel, Virtual Computer Corp.
Peter M. Athanas, Virginia Polytechnic Institute and State Univ.
Philip B. James-Roxby, Xilinx Inc.
John T. McHenry, National Security Agency
INTRODUCTION
In the late 1980's, when a few adventurers pointed to Reconfigurable
Computing (RC) as the next step in computing architectures, the
largest programmable logic devices (FPGAs) had 2K gates of
reconfigurable logic. Far from enough logic real-estate to build
computing systems. By the mid-90's, the size of reconfigurable
devices increased to 50K gates of reconfigurable logic; but the
continued low gate count, poor programming architectures, lack of
partial reconfigurablity and high cost of these devices restricted
the use of RC computing architectures to the research and
experimentation communities. Recent advances in the manufacturing
process promises 50 million gates of reconfigurable logic by 2005 at
substantially lower costs. The increased gate count along with richer
feature sets (such as greater internal I/O support, multiple
independent clocks and increased pins) have greatly improved the
economics for using RC technology in the general marketplace. With
the arrival of million plus gates of reconfigurable logic on a chip
(year 2001) and the integration of processor IP, these and other
hybrid reconfigurable devices are closer than ever to the classic
computing processor.
In the past two years, a number of application specific processors
with hard processing cores coupled to reconfigurable logic have
entered the marketplace. Software toolmakers are actively building
high-level compilers for hardware design implementation based upon C
and Java programming languages to make system programming easier.
These factors have added to the acceleration of commercial use for
reconfigurable or adaptive systems and applications.
PURPOSE:
The purpose of this conference is to bring together researchers,
manufacturers and users of reconfigurable technology for computing
systems and applications. Contributions are solicited on all aspects
of reconfigurable computing, including but not limited to:
* new devices and systems
* tools and techniques
* applications and commercial implementations
The conference will present papers that illustrate applications and
techniques for using reconfigurable technology in both design and
production cycles. Papers relating to the following areas are also
solicited:
* field programmable devices and reconfigurable processors
* adaptive computing systems and architectures
* programming tools and methodologies
* applications utilizing RC technologies
------ IMPORTANT DATES ------
Abstract Due Date: 19 February 2001
Manuscript Due Date: 28 May 2001
Proceedings of this conference will be published by SPIE and
will be available at the meeting. Authors must make an oral
presentation. Authors are accorded a reduced symposium
registration fee.
THE ABSTRACT AND MANUSCRIPT DUE DATES MUST BE STRICTLY OBSERVED.
------ SUBMISSION ------
Your abstract must include the following:
1. SUBMIT TO:SCHEWEL, ATHANAS, JAMES-ROXBY, MCHENRY
2. SUBMIT EACH ABSTRACT TO ONE CONFERENCE ONLY
Reconfigurable Technology: FPGAs and Recofigurable Processors
for Computing and Communications III
3. ABSTRACT TITLE
4. AUTHOR LISTING (principal author first)
For all authors: First (given) name (initials not acceptable),
Last (family) name, Affiliation, Mailing address, Telephone,
Fax, and Email address.
5. PRESENTATION Oral Presentation
6. ABSTRACT TEXT Approximately 250 words.
7. KEYWORDS List a maximum of five keywords.
8. BRIEF BIOGRAPHY ( principal/presenting author)
All authors are STRONGLY ENCOURAGED to submit their abstracts by
the due date using the Web form located at URL:
www.spie.org/info/itcom
OR/ EMAIL each Abstract seperately to: abstracts@spie.org
in ASCII text (not encoded) format. IMPORTANT to ensure receipt
and proper processing of your abstract, the SUBJECT line must
include only ther following:
IT303, SCHEWEL, ATHANAS,JAMES-ROXBY, MCHENRY
OR/ MAIL three copies of abstract to:
THE CONVERGENCE OF INFORMATION TECHNOLOGIES AND COMMUNICATIONS
SPIE, PO Box 10, Bellingham, WA 98225 USA
OR/ FAX on copy to SPIE at +1 (360) 647-1445 Send each Fax seperately.
Any Questions Contact: John Schewel jas@vcc.com
Article: 27984Hal Murray wrote: > In article <3A3D988B.383D3682@andraka.com>, > Ray Andraka <ray@andraka.com> writes: > > Peter, > > > > It isn't jsut a delay issue in all cases. I have a photograph somewhere around > > here of > > a 54LS374 output oscillating rail to rail at about 100MHz due to a metastable > > event. That > > one rang until the next clock. I've also seen mateastability cause a > > flip-flop's output > > meander about between 1/4 and 3/4 vcc for several ns before settling on high or > > low. > > Page 130 of Johnson and Graham has a scope picture of a 74F174 > making a runt pulse. Really ugly. > I can remember this & also seem to remember that Lattice when they brought out the GALs (~ '85 ?) claimed that this was one type of metastable event they had eliminated.Article: 27985
Yes, I know. But this was again a TTL device with multiple stages of gain in the latch. Also, does it really matter whether there is an oscillation or not? I assume these are data, not clock lines. So the only problem is that there might be a "last-minute" change that in turn violates the next-stage set-up time. To stay with the Florida analogy: Did the legal hick-ups before Dec 12 really matter, except as media fodder and a national embarrassment? All that counts is that, at the latest acceptable moment, there was a stable decision. In that respect, the Florida metastability was successfully resolved. Peter Alfke ================================== Hal Murray wrote: > > Page 130 of Johnson and Graham has a scope picture of a 74F174 > making a runt pulse. Really ugly. >Article: 27986
Thanks for the insights. An RBT (Rawbits) file is coded in ASCII - one bit for each config bit. A .bit file is a binary coded file - one bit for each config bit. We are space constrained on storage so we want the most compact format. The .bit files compact well with ZIP utilities but they require too much processing power. For now we will just take what we get with the binary format. > Andy, > > we program Xilinx chips from a 68332 uP. We wrote a program that > builds a ROM image from an S28 (motorola hex) file and one or more > Xilinx .RBT files. The RBT files are ascii 1's and 0's (with some > header lines) and include all the bits (fill, CRC etc) you need. > > Is a .bit file the same as a .rbt? > > John >Article: 27987
Great info. I wrote a utility to strip the header out and split the bitstream file into sections for programming paged flash. Try it out in a bit. Sorry for the pun. Thanks, Andy Joel Kolstad <JoelKolstad@Earthlink.Net> wrote in message news:9T__5.16017$h67.1140850@newsread1.prod.itd.earthlink.net... > > On Fri, 15 Dec 2000 12:03:28 -0800, "Andy Krumel" <andy@krumel.com> > > wrote: > > > > >To date I have programmed the Spartan II using the MultiLinx cable in > > >slave-serial mode. We are now cutting over to program it using a > > >microcontroller. Can the .bit file generated by bitgen be fed directly > into > > >the chip? > > Certainly -- with one minor caveat. At least in my (limited) experience, > the .Bit file consists of a header followed by the raw bitstream itself. We > have a PCI card with an XCV400 on it as well as a PLX 9054 for the PCI > interface, and we slightly abuse the '9054's EEPROM and LED lines to > serially program the FPGA when the board wakes up. The C code to do it > seeks into the .Bit file to the correct magic offset (you have just look at > a hex dump in the file to find this offset, since you know what the > bitstream's preamble is) and then starts shifting bits serially through the > '9054 to the FPGA. > > You can, of course, run the PROM formatter utility to generate a .Hex or > .MCS or whatever file, but in our case, this was just an added step that > didn't provide any utility. On the other hand, if you have funny > programming requirements, the PROM formatter can prove useful -- we did a 4K > design a couple years back where a DSP's serial port shifted out the > configuration bitstream to the FPGA, and it was easier to let the PROM > formatter do the bit swapping (due to the endianess of the serial port) than > to write our own software to do it. > > Xilinx probably officially grumbles at the "hack the .Bit file directly" > approach, since they can argue with complete validity than the format might > change in the future, and only guarantee that the new PROM formatter utility > would then know the correct interpretation of that new .Bit file format. > We're not the only guys doing this, however -- we have a supplier whose > boards do it as well. > > ---Joel Kolstad > > >Article: 27988
In article <3A3E6594.F2516621@xilinx.com>, peter.alfke@xilinx.com wrote: (snip) > The master latch in modern CMOS is just a cross-coupled single-stage inverter. > I have never heard of metastable oscillations in CMOS latches. > Perhaps somebody else can enlighten us... > Peter Alfke > (snip) I know nothing about Xilinx chip-level implementation of flip-flops, but you say that they are cross-coupled inverter structures. Thinking about this, it seems to me that the only way that they can be metastable is if they are stuck in the middle of their analog operating areas. IOW, they are both functioning as high gain inverting amplifiers, with VOUT=VIN. In this case, I would not be surprised to see some brief oscillation before the inverter pair snaps back to stable digital operating area states. In an earlier post you said something about the FF output always being at a valid level, but taking longer to switch. It seems to me that cross-coupled inverters are inherently stable if they are at valid logic levels. Using the test in XAPP094 you wouldn't see the actual output voltage because the output is buried on the chip, so maybe the output voltage is stuck at Vth until the latch stabilizes. What do you think? -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/Article: 27989
Swift,
I have and use Aldec's Active-HDL 4.1 simulator for all Verilog and VHDL
designs, except when a client company insists that I use their simulator
tool. Some of these tools have sign-off capability; however, I don't need
anyone signing off on my FPGAs!
Of all of the simulators, it has a great Windows GUI, and it seems to be
the only simulator with a Windows GUI designed from the ground up. Other
simulators seem to be "Windows-like," i.e., they seem to be adapted from
Unix or DOS based designs.
I have used it to do simple to complex designs with relatively little
problem. I had a problem once with 4.0, and their support department jumped
right on it. Problems are normal for all products, it seems, and the true
differentiator, is tech support.
You will not go wrong with Active-HDL 4.1 and Synplicity. Those are
the tools I use, and they are great!
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL, USA
"Swift" <jboss@wxs.nl> wrote in message
news:91iv1c$1jh9f$1@reader2.wxs.nl...
> Does anyone use this tool for simulating VHDL-stuff for a FPGA? What's
your
> opinion? Any other suggestions? We need a tool only to simulate a
> VHDL-design. We already use Synplicity to synthesize.
>
> THX,
>
> JB
Article: 27990
Ray,
I said it wrong below ("better control of synthesis..). What I meant to
say is that VHDL has better control of placement (you know, the RLOCing
thing). Thanks for pointing this out, you very un-average bear!
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL
"Ray Andraka" <ray@andraka.com> wrote in message
news:3A3D96A4.1C325B92@andraka.com...
> It depends on what level you are coding at too. VHDL makes it fairly easy
to
> embed placement (you know, RLOCs) in your code. I haven't figured out how
to do
> that with verilog yet. Granted, I do much mure structural coding than
your
> average bear, but the truth of the matter is that I can't do what I need
to do
> in verilog, at least not yet.
>
> "S. Ramirez" wrote:
> > truth is that both languages will do the job. VHDL will do some things
> > better (e.g. better control of synthesis, error checking, etc.); Verilog
> > will do other things better (e.g. faster quicky jobs, PLI, etc.). But
both
> > will do the job, and both are supported by most tools today. If you are
an
Article: 27991In article <3A3E4478.F8F3E02E@xilinx.com>, peter.alfke@xilinx.com wrote: > > --------------E6B47E90B30980877899DDDE > Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" > Content-Transfer-Encoding: 7bit > > bobdittmar@my-deja.com wrote: > > > > > Be aware that Xilinx does not offer "true" dual port. They offer > > bi-directional dual port. You still must arbitrate conflict access > > to same addresses. > > > > > > Well, how far can we drive the definition of "true dual port RAM". > Bob Dittmar thinks it should include an arbiter that resolves the > case when both ports access the same location "kind of > simultaneously". > That sort of arbitration should be left to the user to define and > implement, because a dedicated "fix" would interfere with the normal > operation of the RAM. > > Virtex BlockRAM has two totally independent ports accessing a common > storage array. > Both might access the same location. > If one writes and the other one reads, it depends on the relative > clock timing whether the reader gets the old or the new data. Note > that read is a synchronous, clocked operation. Each port has its own > clock. > If both ports write, the one with the later clock wins. Definitely no > damage. > This operation is clear and unambiguous. Solving the contention in > dedicated hardware would not be in the user's best interest. > > Peter Alfke, Xilinx Applications > > --------------E6B47E90B30980877899DDDE > Content-Type: text/html; charset=us-ascii > Content-Transfer-Encoding: 7bit > > <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> > <html> > > <p>bobdittmar@my-deja.com wrote: > <blockquote TYPE=CITE> > <br>Be aware that Xilinx does not offer "true" dual port. They offer > <br>bi-directional dual port. You still must arbitrate conflict access > <br>to same addresses. > <br> > <br><a href="http://www.deja.com/"></a> </blockquote> > Well, how far can we drive the definition of "true dual port RAM". > <br>Bob Dittmar thinks it should include an arbiter that resolves the case > when both ports access the same location "kind of simultaneously". > <br>That sort of arbitration should be left to the user to define and implement, > because a dedicated "fix" would interfere with the normal operation of > the RAM. > <p>Virtex BlockRAM has two totally independent ports accessing a common > storage array. > <br>Both might access the same location. > <br>If one writes and the other one reads, it depends on the relative clock > timing whether the reader gets the old or the new data. Note that read > is a synchronous, clocked operation. Each port has its own clock. > <br>If both ports write, the one with the later clock wins. Definitely > no damage. > <br>This operation is clear and unambiguous. Solving the contention in > dedicated hardware would not be in the user's best interest. > <p>Peter Alfke, Xilinx Applications > <br> > <br> > <br> </html> > > --------------E6B47E90B30980877899DDDE-- > > Hey Guy, don't get your panties in wad! What I said is true. I did not say anything negative about Xilinx, I prefer Xilinx over Brand A anyday. So take some prozac. I was just letting this guy know what Xilinx advertises in their data sheets what is somewhat contrary to what you had to say. According to SpartanII datasheet DS001 (v1.1) april 7, 2000 pg 28 If both ports write to the same memory cell simultaneously, violating the clock to clock setup requirement, consider the data stored as invalid. If one port attempts a read of the same memory cell the other simultaneously writes violating the clock-to-clock setup requirement, the following occurs: - The write succeeds - The data out on the writing port accurately reflects the data written - The data out on the read port is invalid Of course I don't work for Xilinx applications so I can only go by what they publish. Obviously you have better information and I'm more than open to listen to someone who knows more than me. You don't have to get all upset that I indicate that the user must implement arbitartion. I think it is somewhat understood. I was just letting this guy know that it would need to be done and not to take the term "true dual port" to heart. Bob Dittmar, not Xilinx Applications (but I do like their parts) Xtera Communications Sent via Deja.com http://www.deja.com/Article: 27992
I recently worked on a senior project where we designed a 16-bit RISC microprocessor, and implemented the design in an FPGA. I'd like to be able to do something similar on my own, and I'm trying to find a good FPGA/board combination that is (relatively) affordable, and compatible with the Xilinx student edition software. If anyone has any suggestions, they would be greatly appreciated. Thanks, Eric Hoyt Sent via Deja.com http://www.deja.com/Article: 27993
I'm a newbie for activeHDL. I need help on timing simulation. Tools: FPGA express + xilinx foundation 2.li + activeHDL 4.1 Input: verilog testbench and verilog source code. (1) When i configure flow setting in design flow for selecting device, the console said: Design: Warning: Library XC3000 required for the selected device family has not been installed. (2) I do the function simulation successfully, but can't do timing simulation. Message from activeHDL console when execute timing simulation: Warning: VCP2515 TIME_SIM.V : (81, 1): Undefined module: X_IPAD was used. Port connection rules will not be checked at such instantiations. ELBREAD: Error: No design unit found (library add1b_timing, name X_BUF). etc.. Can anyone help me ? Or tell me where can find some basic tutorial or demo for timing simulation with activeHDL? Regards Frank Sent via Deja.com http://www.deja.com/Article: 27994
Greg Neff wrote: > II know nothing about Xilinx chip-level implementation of flip-flops, > but you say that they are cross-coupled inverter structures. Thinking > about this, it seems to me that the only way that they can be > metastable is if they are stuck in the middle of their analog operating > areas. Yes, agreed > IOW, they are both functioning as high gain inverting > amplifiers, with VOUT=VIN. In this case, I would not be surprised to > see some brief oscillation before the inverter pair snaps back to > stable digital operating area states. No, I don't see how such a prmitive structure can sustain an oscillation. Once it leaves its metastable balanced state, there is no way to return back to or through it. ( As is possible in multi-stage structures popular with TTL technology) > > > In an earlier post you said something about the FF output always being > at a valid level, but taking longer to switch. It seems to me that > cross-coupled inverters are inherently stable if they are at valid > logic levels. Well, the master latch ( the only one that can go metastable) is not brought out even from the flip-flop ( let alone the chip ). So you always have the gain of the slave latch in series. That's why ( I think) the flip-flop Q will never stay in the middle. > Using the test in XAPP094 you wouldn't see the actual > output voltage because the output is buried on the chip, so maybe the > output voltage is stuck at Vth until the latch stabilizes. What do you > think? As I said, the gain of the slave latch makes that (almost) impossible. But I also question the importance of the question. For data, it is irrelevant whether it oscillates or not. And anybody using a metastable-prone signal as a clock should have his/her head examined. Peter Alfke > > > -- > Greg Neff > VP Engineering > *Microsym* Computers Inc. > greg@guesswhichwordgoeshere.com > > Sent via Deja.com > http://www.deja.com/Article: 27995
bobdittmar@my-deja.com wrote: > > Hey Guy, don't get your panties in wad! Must be some Britishism. Dangerous in the US of A. :-) > > What I said is true. > > I did not say anything negative about Xilinx, I prefer Xilinx over > Brand A anyday. So take some prozac. Thanks. I am cool. I was just clarifying terminology. > > > I was just letting this guy know what Xilinx advertises in their data > sheets what is somewhat contrary to what you had to say. I really do not see the difference or contradiction > > > According to SpartanII datasheet DS001 (v1.1) april 7, 2000 pg 28 > > If both ports write to the same memory cell simultaneously, violating > the clock to clock setup requirement, consider the data stored as > invalid. I said: The last clock wins. Same thing. But if you don't know who is last, the data is "invalid". This is just the usual cautious, worst-case, lawyer-inspired data sheet lingo. > > > If one port attempts a read of the same memory cell the other > simultaneously writes violating the clock-to-clock setup > requirement, the following occurs: > - The write succeeds > - The data out on the writing port accurately reflects the data > written > - The data out on the read port is invalid Again, data sheet lingo. If you know which clock is (significantly) early or late, it's deterministic as I said. > > > Of course I don't work for Xilinx applications so I can only go by what > they publish. Obviously you have better information and I'm more than > open to listen to someone who knows more than me. Thanks. It's mostly common sense. But I do have the advantage of being able to check with the chip designer... > > > You don't have to get all upset I am not upset, sorry if you got that impression. Just trying to explain :-) > that I indicate that the user must > implement arbitartion. I think it is somewhat understood. I was just > letting this guy know that it would need to be done and not to take > the term "true dual port" to heart. It is "true dual port", because both ports are fully functional and independent of each other. But you are right, simultaneous access needs some attention by the user. We could have designed in arbitration, and we discussed that, but we saw immediately that it would mess up the design, would be impossible to explain for borderline cases, and thus would make nobody happy. > > > Bob Dittmar, not Xilinx Applications (but I do like their parts) Thanks! So we have a lot in common. But I don't know about the panties... Peter AlfkeArticle: 27996
Peter Alfke writes: >> If both ports write to the same memory cell simultaneously, violating >> the clock to clock setup requirement, consider the data stored as >> invalid. > I said: The last clock wins. Same thing. > But if you don't know who is last, the data is "invalid". > This is just the usual cautious, worst-case, lawyer-inspired data sheet > lingo. May the "last clock" vary bit by bit due to timing variance? >> If one port attempts a read of the same memory cell the other >> simultaneously writes violating the clock-to-clock setup >> requirement, the following occurs: >> - The write succeeds >> - The data out on the writing port accurately reflects the data >> written >> - The data out on the read port is invalid > Again, data sheet lingo. > If you know which clock is (significantly) early or late, it's > deterministic as I said. Common case: identical clocks. What will you read? thanks, -- JamieArticle: 27997
On Mon, 18 Dec 2000 10:12:39 +0100, Daniel =?iso-8859-1?Q?Ha=F1czewski?= <danhan@wp.pl> wrote: >Dear all, > >I'm developing a PCI card with Xilinx's XC9572 on board and I have a >problem. I would like to use PCI bus to program XC9572 via JTAG >interface. This solution would allow me to program the card without >opening computer case and in the future remotely with a use of a modem. >Is it possible to handle JTAG protocol with 4-bit IO port (I have such a >port and I would like to connect it to JTAG)? Can I connect it directly >or should I use any glue logic? Where can I find JTAG protocol? >More: to allow our service people to update XC9572's configuration at >customer site I need to have a configuration file for CPLD and a simple >downloader. It must fit on a 3,5" diskette. Some kind of batch - "run & >forget". In this case let's assume that downloading will be done via >standard Xilinx's parallel cable. Is there any kind of such a >downloader? Which file is a configuration file for XC9572? > >Note: I'm a beginner in CPLD's. > >Best regards >Daniel > Hello, Xilinx has some application note on how to program the CPLDs through a embedded micro processor (source included). Maybe you could adapt this to steer the pins of the PC parallel port. You will have to look at the schematics of the Xilinx programmer cable do determine how the pins are connected. Personally I would use the Webpack Device Programmer program. It is free, it is proven to work, will save you a lot of work, and can be used (with a little training) by everyone which can use Windows. If you plan to program the CPLD through the PCI-controller you need at least 3 outputs (TDI, TMS, TCLK) and one input (TDO). You can use the same information from above to drive the pins. If you decide to drive the JTAG bus either by the PCI (controller ??) AND by the download cable you have to pay attention that the two drivers do not collide. Use open collector drivers and pullup resistors. Information on the JTAG protocoll can be found at the Texas Instruments Home page. Best regards Klaus Falser Klaus R&D Electronics Department Company : Durst Phototechnik AG Vittorio Veneto Str. 59 I-39042 Brixen Voice : +0472/810235 : +0472/810111 FAX : +0472/830980 Email : kfalser@durst.itArticle: 27998
> Read the documentation for your FPGA and you should be able to find numbers > for the global reset routing skew. If the skew is larger than your clock > period, then you will potentially have registers coming out of reset two > clock cycles before others. That one set off my alarm bells. Even if the skew is low, you are in trouble if the delay matches a clock cycle. Or rather any integer number of clock cycles. If the delay on the global-reset path is less than your clock period, you still have to make sure that the reset gets clocked (cleanly) on your system clock. That's impossible to do if you have several different clocks driving your chip. (Obviously, clocks that are multiples of eachother are not "different" in this context.) This gets hashed over here occasionally. Consensus seems to be to do the reset logic yourself. I got burned by this many years ago. I haven't forgotten yet. Speaking of global-reset, how does GSR work on a Virtex? If I look with the FPGA Editor, I don't see any place where GSR connects up to a CLB or IOB. If I specify an explicit set/reset term, does that replace what GSR does or does it get ORed in with GSR? Is there an extra input on some SR mux that isn't shown? Or does GSR get wired up outside the CLB on some path that isn't shown? Or am I just not looking in the right place? The SR input to a CLB is also used as a write-enable when the LUT memory is used as a RAM or shift-register. Do the FFs still get reset by GSR? -- These are my opinions, not necessarily my employers. I hate spam.Article: 27999
I'm looking at a problem where we need to drive a couple of 5V CMOS clock inputs from a SpartanII 3v output. There are data lines being driven from the 3V output, we can get away with the 'tristate and pull high for logic high' trick, but I don't want to do this with the clock signals. The active (rising) edges are _very_ slow and the risk of double clocking etc would be too high. Space is fairly tight so my immediate thought was to use an 8 pin soic dual comparator with the -ve input tied to 1.8V (power plane). My only concern with this is that I think I read a while ago that comparators shouldn't be used for this sort of application, I can't remember where I read this so I can't check if I'm right. It might have been because of the lask of hysteresis on the input, but if the -ve input is set to a 'clean' part of the waveform I don't think we should see any problems. Can anyone think of any drawbacks of using a fast comparator for this conversion? Nial.
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