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
Someone mentioned www.timingtool.com the other day. Could that be what you're looking for? -KentArticle: 31076
Hi, we've just shipped a new product that uses 5 Spartan-XL chips, and had a fair amount of grief getting things up. We're using the basic Foundation schematic-entry stuff, with service packs duly installed. The worst thing we found is that, if we connect a signal to a pin and don't reference it on the schematic, the pin will sometimes become an output and do weird things. In one case, we ran the VME signal AS* (address strobe) into the chip and decided later we didn't need it, so ignored it. It then began hanging the VME bus by pulling AS* low, but only when certain VME addresses were used! In another case, all 5 FPGAs shared the DIN common config data pin; once the first chip was configured, it started driving its own DIN as an output, and trashed the config of the other four chips. This was compile dependant (ie, random on different compiles). The fix is to run all unused inputs into a huge AND gate and run the output to an unconnected output pin, just to keep the compiler happy. We never had such problems with 4000XL's. Any experience/ideas with this one? John ps: the Spartan chips seem to have enough muscle to be a damned fine VMEbus driver! pps: the AND gate trick works, if there's an output pin available. What if not? Then you'd have to invent a circuit with N inputs and no outputs, but that was complex enough that the compiler couldn't figure out that it's useless hence wouldn't strip it out!Article: 31077
5.1.5 is very old. I tried it in more recent versions and it worked. I don't know if the attribute existed in that version. Uwe Bonnes wrote: > > Ken McElvain <ken@synplicity.com> wrote: > : input foo /* synthesis ql_padtype="normal" */; > : See the help file for examples. > > :> > :> Can anybody give a hint how to stop synplicity to choose a dedicated > :> input pin for an input with high load? > > Hallo Ken, > > thanks for your help. Probably I missed to tell you the information that I > run Synpicity delivered with Quickworks (V8.2 plus the 8.22 patch), which > identifies itself as "Synplify-Lite 5.1.5", which substantially lags the > present Synlify release. Local quicklogic support tried to be helpfull, but > only gave the hint to rewrite my verilog code to include explicit > buffers. However I don't feel satisfied with that work-around. > > I tried your solution in two places for a single input and for a vector of > inputs, to be sure that the vector doesn't cause problems (line numbers > given for reference, not included in the files) > > 1 `define VERSION "K-DELAY 0.00-1" > 2 > 3 module camacdelay8(/*AUTOARG*/ > 4 // Outputs > 5 Q_N, X_N, WRITE_EN_N, R_N, > 6 // Inouts > 7 DOUT0, DOUT1, DOUT2, DOUT3, DOUT4, DOUT5, DOUT6, DOUT7, > 8 // Inputs > 9 RESET_N, S1_N, S2_N, N_N, I_N, F_N, A_N, W_N > 10 ); > 11 input RESET_N,S1_N,S2_N,N_N; > 12 input I_N/* synthesis ql_padtype="normal" */; > 13 input [4:0] F_N; > 14 input [3:0] A_N/* synthesis ql_padtype="normal" */; > > However Synplify ignores these hints and gives following report in the > .srr file: > > $ Start of Compile > #Thu May 10 11:11:35 2001 > > Synplify Verilog Compiler, version 5.1.5, built Jul 20 1999 > Copyright (C) 1994-1999, Synplicity Inc. All Rights Reserved > > @I::"c:\cae\pasic\spde\data\macros.v" > @I::"...\camacdelay8.v" > @W:"...\camacdelay8.v":12:27:12:36|ignoring property ql_padtype > @W:"...\camacdelay8.v":14:33:14:42|ignoring property ql_padtype > Verilog syntax check successful! > > Pathnames truncated for clarity. > > The .qds file still instanciates a input only pad for the : > > gate A_Nz_p[2] master Q_HINPAD cell IO108 end > > Any hints why the properties are ignored? > > Thanks again > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- -- Ken McElvain, CTO Synplicity Inc. (408)215-6060Article: 31078
On Thu, 10 May 2001 17:59:43 -0700, John Larkin <jjlarkin@highlandSNIPTHIStechnology.com> wrote: >Hi, > >we've just shipped a new product that uses 5 Spartan-XL chips, and had >a fair amount of grief getting things up. We're using the basic >Foundation schematic-entry stuff, with service packs duly installed. > >The worst thing we found is that, if we connect a signal to a pin and >don't reference it on the schematic, the pin will sometimes become an >output and do weird things. In one case, we ran the VME signal AS* >(address strobe) into the chip and decided later we didn't need it, so >ignored it. It then began hanging the VME bus by pulling AS* low, but >only when certain VME addresses were used! This make no sense. The only time I have seen random pins being driven is when you have output signals that have not been locked to a specific pin. Can you give details of what the signals are that are driving these pins that were prior inputs, and should now be un-used (as in your above example). What did the PAR report say about these pins, what about the xxx.PAD file , what about the fpga_editor. In designs that have all the application I/O pins locked to specific pins, all the remaining I/O pins of Xilinx FPGAs are defaulted to inputs with a weak pull-up to VCC. This has been true for all FPGA products and versions of software for all of the last 10 years. >In another case, all 5 FPGAs shared the DIN common config data pin; >once the first chip was configured, it started driving its own DIN as >an output, and trashed the config of the other four chips. This was >compile dependant (ie, random on different compiles). Again, this sounds like you have an output in your design that you have not locked to a specific pin. Each compile puts it somewhere, sometimes on the DIN pin. In your shared DIN pin case, are the FPGAs the same devices, and loaded with the same design? if so they should all go done at the same time. If not, then how are you managing the shared DIN? Separate Program pins? >The fix is to run all unused inputs into a huge AND gate and run the >output to an unconnected output pin, just to keep the compiler happy. This is un-needed. You need to figure out what is being routed to these supposedly unused input pins. Maybe it is some leftover debug stuff of signals that you were routing out separately? >We never had such problems with 4000XL's. Any experience/ideas with >this one? Architecturally they are very similar. It seems more likely that in your 4KXL designs you dont have any un-locked outputs. >John > >ps: the Spartan chips seem to have enough muscle to be a damned fine >VMEbus driver! Isn't that neat. Sure saves on a bucket of octal TTL buffers. >pps: the AND gate trick works, if there's an output pin available. >What if not? Then you'd have to invent a circuit with N inputs and no >outputs, but that was complex enough that the compiler couldn't figure >out that it's useless hence wouldn't strip it out! I still dont think you need this, so I dont think this is an issue. Good luck, Philip Philip Freidin FliptronicsArticle: 31079
Hi, I have a PCI device whose interface is not compatible with CardBus standard. But I want to build a CardBus PC Card with the PCI device. In this case, is it possible to build a CardBus PC Card by integrating CardBus-to-PCI bridge and the PCI device? I wonder if there exists any CardBus-to-PCI bridge. By the way, does it make sense to build a CardBus PC Card with a PCI device? Thanks, BenArticle: 31080
Check out, http://members.aol.com/d2fabrizio/ http://www.timingtool.com/ HTH, Srini Marek Ponca wrote: > > Do you know any free tool for painting digital waveforms ? > Not for testbench generation, only for documentation. > > Marek -- Srinivasan Venkataramanan (Srini) ASIC Design Engineer, Chennai (Madras), IndiaArticle: 31081
Type real is not synthesizable. Some synthesis tools support reals for the math to generate a constant, but that's as far as it goes. THink about it, how would you represent a real type with logic? You need to find or develop a library of floating point components (remember, floating point is just a fixed point mantissa with a second fixed point value to indicate the position of the radix point). That said, most applications do not need floating point hardware throughout. In the cases where you do have to deal with floats, you can usually treat a sequenc of operations with fixed point arithmetic, passing the exponents around and rejoining later in the pipeline. You can also let it get denormalized in you processing or even stray away from IEEE 32 bit to help save on the hardware (it does require some time analyzing your needs). For your system, 256MB is more or less entry level for serios FPGA design. Check the size of your paging file, could be you are filling that. Alliance is the back end tools only, no synthesis, no design entry. If you have the cash, I'd go with Alliance + synplicity + Aldec or Modelsim for simulation. ISE has a very weak VHDL, which you will find very frustrating to use. Kris Nichols wrote: > > Hey there, > I'm started a project 4 months ago using Xilinx Student > Edition v2.1 tools and an evaluation board (XESS XS40). It turns out > I've since needed to use 32-bit IEEE floating point addition and > multiplication throughout my design. Currently, there the evaluation > board I'm using no longer has the real-estate I need to implement my > design with. When I attempt to synthesize and simulate this design with > the Xilinx Student Edition v2.1 tools, it runs out of memory (even > through I'm using a WinNT platform with 256MB of SDRAM). > To solve my real-estate problem, I'm probably going to > purchase one of the Xilinx Vertex-II FPGAs. However, I'm not sure which > of the following Xilinx Development Systems I should purchase (to help > overcome the rest of my problems): > 1. Alliance Series > 2. Foundation Series ISE, or > 3. Foundation Series > How do these Xilinx Development Systems compare?? Any suggestions or > recommendations?? Does anybody know if any of these Xilinx Development > Systems have support for 'real' types in VHDL (i.e. floating point > numbers)?? Thanks. > > Kris Nichols -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 31082
Hi Joerg, This looks really good, andventegous for documentation written in Latex. Thanks, M. > Hello Marek, > > if you are familar with Latex , you can use a style file named > timing.sty (see > ftp://ftp.dante.de/tex-archive/macros/latex/contrib/other/timing/). > With the help of these style-files you can create waveforms with your > favorite editor and the latex environment instead of paiting them. > > ciao > Joerg -- Dipl.-Ing. Marek Ponca Institut of Circuit Technology and Electronics Faculty of Electrical Engineering and Information Technology Ilmenau Technical University P.O. BOX 10 05 65 98684 Ilmenau, Germany Tel: +49 3677 69 1167 fax:(1163) http://www.inf-technik.tu-ilmenau.de/~marek/ marek.ponca@et.stud.tu-ilmenau.deArticle: 31083
Hello, I do a compare-equal of the output of two Cray counters. Each counter is connected to a separate clock (different freq.). Can I expect that there a no spikes on the output of the compare-equal? If yes, is there a way to proof that? Bye ThomasArticle: 31084
> Given that VMWare provides a way of using the command line tools under > Linux then > (3) => Xilinx doesn't have to do a Linux port. But I still have to pay and support for VMWare and Windows running inside VMWare. If you look at the processes running after starting a foundation compile, then you can see that the backend tools seem to be 16 Bit only, so you should be able to run them within DOSEMU. You could also get the freeware version of Alliance (include in SuSE Linux for example). With the help of JBits it should be possible to add support for Xilinx chips to it. But hey, wait, you can do all your designs with JBits. You will use a couple of month with respect to time-to-market, but everything will be hand optimized and fine tuned to get very good results. Kolja SulimmaArticle: 31085
Quartus II runs from the command line and actually this interface is more powerful than the GUI. It supports TCL and there are several pre-written scripts available from the Altera web site and some more, sophisticated and easy to use ones from FAEs. All Quartus specific TCL commands are well documented.With this inteface you can access the device and timing database and do powerful manipulations like floorplanning or setting timing constraints. The syntax is: quartus_cmd -f <script_file> For big designs, especially when integrated with other synthesis or simulation tools we prefer to use TCL rather than the GUI. Rick Filipkiewicz <rick@algor.co.uk> wrote in message news:3AFAF39C.2923316D@algor.co.uk... > > > Eric Smith wrote: > > > > Altera has announced a port of Quartus II (including MAX+PLUS II) > > to Linux! > > > > http://www.altera.com/corporate/press_box/releases/pr-linux_quartus.html > > http://www.businesswire.com/cgi-bin/f_headline.cgi?bw.050701/211270104 > > > > At last, one of the programmable logic vendors gets it. They say "Linux > > has enjoyed dramatic success over the last several years as a platform > > for a variety of EDA point tools, such as simulation, because of the low > > cost per compute cycle." An interesting contrast from Xilinx' claims > > that there is no customer demand for Linux. > > > > > > I wonder if Xilinx's attitude stems from these 2 (my opinion only) > equivalences: > > (1) Linux user <=> serious user > > (2) GUI user <=> !serious user > > > From which we can derive > > (3) Linux user <=> !GUI user > > Given that VMWare provides a way of using the command line tools under > Linux then > (3) => Xilinx doesn't have to do a Linux port. > > > Question: Do Quartus & Warp tools run from the command line as well as > the Xilinx ones do ? are the command line i/f's as well documented ? > > <snip>Article: 31086
"Erik Widding" <widding@birger.com> wrote in message news:%PaK6.12945$t12.971754@bgtnsc05-news.ops.worldnet.att.net... ... > revision. But overall, none of the errata is particularly bad, just don't > expect the DCM to do all the really cool stuff listed in the data sheet. What do you mean by that? What doesn't it do then? Actually, the thing I'm concerned about is, does fine phase shift work ok (at 270MHz)? Can't test it right now myself but my whole project relies on that phase shift, so I'm a bit worried. MeelisArticle: 31087
Thomas Zipper <Thomas.Zipper@icn.siemens.de> writes:
> I do a compare-equal of the output of two Cray counters.
Do you mean "grey code counters"? I'll assume that you do.
> Each counter is
> connected to a separate clock (different freq.).
> Can I expect that there a no spikes on the output of the compare-equal?
> If yes, is there a way to proof that?
This sounds like a homework problem, and one that you should be able to
figure out by studying a good digital logic textbook. But perhaps it
merits discussion anyhow.
There are two cases to consider:
1) The counters are never clocked simultaneously (or near simultaneously).
Since by definition a grey code counter will only change one of its
output bits when it is clocked, and the one that is not clocked will
not change any of its bits, the output of an equality comparator will
make at most one transition for the clock. Thus no glitch.
However, if you have two separately generated clocks of different
frequencies, you WILL have near-simultaneous clocks, and you have to
deal with that case.
2) The counters are clocked simultaneously (or near simultaneously). So
one output of each counter will change. There are several cases,
I'll let you think about the comparator output for these cases
yourself. It might help to draw some timing diagrams. For the
truly simultaneous case, the analysis is trivial. But in the real
world, you should never expect that two "simultaneous" signal
changes will actually be simultaneous, even if they outputs of flops
sharing a common clock. There will almost always be some minor
difference in prop delay in the clock, the output signal path, or
(likely) both. This delay may be very short, but if you count on it
being zero you will get screwed.
However, if you design something that *depends* on the two transitions
NOT being simultaneous, it will happen that they are.
So the cases to focus on involve one counter being clocked, then the
other being clocked very soon thereafter.
What happens if the counters were originally equal?
What happens if they were NOT originally equal? Are there multiple
posibilities?
Bonus question for extra points: Assume that you are using the grey code
counters and comparator as part of a FIFO to interface between two clock
domains. Suppose it is possible for the comparator output to have a
glitch. How can you prevent this from being a problem in your system?
Article: 31088
Interested in a Cutting EDGE company, Hot technology, Tremendous growth,
Pre-IPO stock opt's $ - securely funded - 2nd round of funding May 2001
$50mil
Great locations/Warm Climate - either GA or N. VA
Superb Management Team with a proven track record with building successful
Start-ups.
Product launch - June 2001 at Supercomm.
Join a winning team that is moving at record breaking pace and redefining
the way technologies are developed and networks are built. -- We are
designing the next generation end-to-end dynamically controlled all-optical
networking solutions.
-- We are expanding the boundaries of transport networks.
In a very short time, we have built a world-class organization that is a
mix of optical technology experts, software and systems designers, and
forward-looking visionaries. With 190+ employees and aggressively growing.
Funding secured by the leaders in the optical arena - Worldview Technology
Partners and Menlo Ventures
Their reputation for success has been unsurpassed.
*** WANTED - HARDWARE Engineers - FPGA/Verilog ASIC &
Digital Board Level Designers ***
Salary $70k -115k + bonus + stock opt's $$$
Excellent benefits package + dynamic work environment
Unbeatable salary
Curious, Interested .......Contact me - Mike DeLaney toll free -
888.338.9087
Even if your curious it's worth calling.
Article: 31089On Thu, 10 May 2001 09:17:19 -0700, Austin Lesea <austin.lesea@xilinx.com> wrote: >I really am going to quit replying: > >But I thought I would leave it in Shannon's own words....with a few of my own. > >For that, I really do apologize: Shannon really did a great job explaining it, >and I feel that maybe the best thing to do is read his paper, and then go build >something to prove it to yourself. My learning experience was a 16QAM modem with >BCH coding. > >From "Communication in the Presence of Noise," 1940, published 1948. > >C = W log2 (P+N)/N at last, with the correct sign. >"This shows that the rate W log (P+N)/N measures in a sharply defined way the >capacity of the channel for transmitting information. It is a rather surprising >result, since one would expect that reducing the frequency of errors would require >reducing the rate of transmission, and that the rate must approach zero as the >error frequency does. Actually we can send at the rate C but reduce errors by >using a more involved encoding and longer delays at the transmitter and receiver." > >(emphasis added by me) > >I begin to see what is so confusing. We have a bunch of people with only two >fingers. I have to apologise for leaving some confusion around the term "symbol" - I contemplated expanding on that, but decided against it because it seemed to be taking up too much bandwidth. But your reply gives me an easier way in than I found. >If one confines oneself to using a binary symbol in the channel (on off, 1-0, >etc), then for every bit in C, there must be some extra bits added for correction >in the channel to perform error correction. But if we increate the rate of the >bits in the channel, we get more errors for a given N, keeping P constant. Thus, >C ends up including the error correction bits because the channel C must be equal >to or greater than the information C. > >Thus, we must reduce the number of bits in the channel per unit time given a >specific error correcting code to achieve some desired performance. So far, correct. >If we instead use arbitrarily more complex symbols (QPSK, 16OQAM, OFDM ....), then >for every bit in C, there are bits added to the channel, but the rate of the >symbols may now actually be much less than that of the rate of the binary channel >(PSK = 2 bits per symbol, 16QAM = 4 bits/symbol, etc.). Of course. >This added degree of >freedom in effect allows for many more bits in the channel to be utilized for >error correction without increasing the bandwidth W of the channel, or the power P >of the information in the channel. C (rate in b/s) in the channel is greater than >the C (rate in b/s) of the information, allowing for the error checking and >correcting information. At last. But you have used the term C - "rate in b/s" to mean two entirely different things. Only one of these is the channel capacity. We could call them "useful channel capacity" and "raw channel capacity" if you like - and your position was that C is the "raw channel capacity". Your argument suggests you could replace that 16QAM with 64QAM or 256QAM, or higher, and greatly increase the raw capacity of the channel. And indeed you could. Ad infinitum. But in the presence of the same noise level, you would have to eat up ALL the additional data with redundancy, to overcome the decreased reliability of decoding these less robust symbols. (Leaving aside the difficulty of designing a suitable system of redundancy. That's simply a matter of how closely you approach the limit) In other words, you can increase the binary digit rate (raw channel capacity) of the channel ad infinitum. But because of the redundancy you need for reliability in the presence of noise, you cannot increase the _information_ rate beyond a certain limit - the useful channel capacity. Having separated these two concepts, it seems obvious to me, that Shannon's "channel capacity" refers to the "useful channel capacity" since he refers to it as the ability to carry information. In other words the redundancy is NOT counted as part of the channel capacity. - Brian.Article: 31090
Marek Ponca wrote: > > Hi Joerg, > > This looks really good, andventegous for documentation written > in Latex. > > Thanks, > M. > > Is this the new flexible documentation format designed to stop errors from being propagated ? [Sorry couldn't resist]Article: 31091
To avoid unpredictable behavior on unused I/Os - just draw the IPADs on schematics with PULLUP resistors attached. "John Larkin" <jjlarkin@highlandSNIPTHIStechnology.com> wrote in message news:QTn7OlPqzSzduavnh=XdwH3QvcuK@4ax.com... > Hi, > > we've just shipped a new product that uses 5 Spartan-XL chips, and had > a fair amount of grief getting things up. We're using the basic > Foundation schematic-entry stuff, with service packs duly installed. > > The worst thing we found is that, if we connect a signal to a pin and > don't reference it on the schematic, the pin will sometimes become an > output and do weird things. In one case, we ran the VME signal AS* > (address strobe) into the chip and decided later we didn't need it, so > ignored it. It then began hanging the VME bus by pulling AS* low, but > only when certain VME addresses were used! > > In another case, all 5 FPGAs shared the DIN common config data pin; > once the first chip was configured, it started driving its own DIN as > an output, and trashed the config of the other four chips. This was > compile dependant (ie, random on different compiles). > > The fix is to run all unused inputs into a huge AND gate and run the > output to an unconnected output pin, just to keep the compiler happy. > > We never had such problems with 4000XL's. Any experience/ideas with > this one? > > John > > ps: the Spartan chips seem to have enough muscle to be a damned fine > VMEbus driver! > > pps: the AND gate trick works, if there's an output pin available. > What if not? Then you'd have to invent a circuit with N inputs and no > outputs, but that was complex enough that the compiler couldn't figure > out that it's useless hence wouldn't strip it out! > >Article: 31092
For the last few days I've been fighting with Xilinx MAP's "register ordering" feature. This "feature" attempts to group flip flops with similar names (related by numbers in the signal name) into the same slice. For example, mybus(0) and mybus(1) will be mapped together, and so will mysig_0 and mysig_1. Of course, once MAP has done this, there's nothing PAR can do about it. If mysig_0 and mysig_1 are both sourced and sunk on opposites sides of the die, PAR will just place the slice as best it can, and both paths may fail timing. Not desirable when you're running fast (150MHz+) in a large chip (XCV2000E). I'm used to delaying signals in my code to improve the routing by doing things like mysig_d1, mysig_d2, etc. However, since MAP groups these together into a single slice, there's no routing improvement at all. Same if you use a vector; mysig_d(0) and mysig_d(1) will be grouped together. To make matters worse, when Synplify duplicates signals to improve the fanout, the resulting signal names attract MAP's attention. eg mysig may be duplicated to mysig_1, mysig_2 etc which will be grouped into pairs by the register ordering. (On the other hand, it's a useful feature when you are dealing with signals which truely are parallel parts of a bus. If you disable register ordering (map -r), you can see what happens without it. The logic gets a lot bigger, especially if you happen to be working on a 64 bit bus; then timing fails due to routing congestion etc.) Any ways to work around this? MAP doesn't seem to allow you to turn this off on a signal by signal basis. The best I can do is to try to name signals so that MAP won't touch them. Some things I've done to trick MAP: 1. Rename mysig_d1, mysig_d2 to mysig_1d, mysig_2d, etc. Doesn't help if you use an array mysig_d(n downto 0) though. 2. Interestingly, if you have a signal mybus(7 downto 0), and Synplify duplicates some of those, you get mybus_1(0), mybus_2(0), mybus_1(1), mybus_2(2) etc. These get grouped as mybus_1(0) with mybus_1(1), etc, which might not be so bad. It might be possible to use this to work around the problem with mysig_d. What if mysig_d was an array of std_logic_vector(0 to 0)? Your signals would be mysig_d(n)(0), which MAP might overlook. 3. The biggest hack, but the most effective.. use a Perl script to modify the EDIF netlist after synthesis. I get my script to look for particular signals which I want MAP to leave alone. It then changes things like mybus(0) to mybus_0_, mybus_1(0) to mybus_1_0_, mybus_d(0) to mybus_d_0_, etc. The trailing underscore stops MAP from finding the number. #3 is pretty ugly. Synplify has an attribute to specify the format of the signal name in the EDF -- syn_edif_bit_format. You can apply it signal by signal, in your VHDL code. However, I tried getting it to write out mybus(0)_, and the attribute was completely ignored. Looks like it can only let you configure the type of brackets used; (), <>, []. Anyone else have any ideas? This behaviour is a real killer on signals with large fanout (eg in the order of several hundred, to thousands of flip-flops). regards Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 31093
Hi,
is it possible to use a normal (non clock) pad from a Spartan II FPGA to
drive an internal clock net ? Automatic implementation cannot do that
and aborts with an error ! Is it possible to force a connection from PAD
to INBUF to BUFGP by hand ? Clock skew or the delay from the clock pad
to the FFs is not that critical for this design !
Has anybody an idea how to do this ?
Matthias
--
-------------------------------------------------
\ Matthias Fuchs \
\ esd electronic system design Gmbh \
\ Vahrenwalder Straße 205 \
\ D-30165 Hannover \
\ email: matthias.fuchs@esd-electronics.com \
\ phone: +49-511-37298-0 \
\ fax: +49-511-37298-68 \
--------------------------------------------------
Article: 31094Hi, this is my first time programming a MACH 4 and now am I in a dead end .. I am not able to program a MACH 4 (M4A5-32/32) using ispDesignExpert from Lattice to create the Jedec files ... ispVM (LatticePro) to program it using the programming cable My problem is - the Lattice Pro want a JTAG chain file *.wch, but ispDesignExpert only create *.jedec files. How do I get a chain file? ispVM Download itself does not support the Mach4. The readme says that I have to convert the Mach-files to *.svf with LatticePro. Please help me out of this nightmare, thx MatthiasArticle: 31095
According to Xilinx documentation the BUFGPs of the Virtex and Spartan-II devices can only be driven by the four dedicated IOBs. That means that you cannot use an internal signal to drive a BUFGP. Carsten "Matthias Fuchs" <matthias.fuchs@esd-electronics.com> wrote in message news:3AFC023A.F6987791@esd-electronics.com... > Hi, > > is it possible to use a normal (non clock) pad from a Spartan II FPGA to > drive an internal clock net ? Automatic implementation cannot do that > and aborts with an error ! Is it possible to force a connection from PAD > to INBUF to BUFGP by hand ? Clock skew or the delay from the clock pad > to the FFs is not that critical for this design ! > > Has anybody an idea how to do this ? > > Matthias > -- > ------------------------------------------------- > \ Matthias Fuchs \ > \ esd electronic system design Gmbh \ > \ Vahrenwalder Straße 205 \ > \ D-30165 Hannover \ > \ email: matthias.fuchs@esd-electronics.com \ > \ phone: +49-511-37298-0 \ > \ fax: +49-511-37298-68 \ > --------------------------------------------------Article: 31096
Hi Ben, a few CardBus Slave cards to exist. However the majority is still based on the "isa-bus" based PCMCIA Card interface... Then does it make sense to make a Master PCI to PCMCIA Interface... I think using QuickLogic devices can be a goog starting point markus "Ben" <ejhong@future.co.kr> schrieb im Newsbeitrag news:u0KK6.11$09.832@news2.bora.net... > Hi, > > I have a PCI device whose interface is not compatible with CardBus standard. > But I want to build a CardBus PC Card with the PCI device. > In this case, is it possible to build a CardBus PC Card by integrating > CardBus-to-PCI bridge and the PCI device? > I wonder if there exists any CardBus-to-PCI bridge. > By the way, does it make sense to build a CardBus PC Card with a PCI device? > > Thanks, > > Ben > >Article: 31097
Grey counters are often used as FIFO address counters , where address identity must be detected for determining the extreme conditions of Full or Empty. If the two counters are at differing states, even changing asynchronously, there will NEVER be a decoding spike at the output of the identity comparator. If counter A is incremented to become identical with counter B, but counter B is, very soon after, incremented, there can be a LEGITIMATE "identity" decoding spike of undefined length. Luckily, this does not matter in a FIFO. The spike either sets the Full/Empty flag ( causing a one-clock period wait state) or it does not set that flag, since the identity has already disappeared. Either case is acceptable. I have an improved description of very efficient and fast asynchronous FIFO implementations in Virtex BlockRAMs. If anybody is interested, send me e-mail. Peter Alfke, Xilinx Applications ======================== Thomas Zipper wrote: > Hello, > > I do a compare-equal of the output of two Cray counters. Each counter is > connected to a separate clock (different freq.). > Can I expect that there a no spikes on the output of the compare-equal? > If yes, is there a way to proof that? > > Bye > > ThomasArticle: 31098
Matthias, Each one of the four global clock buffers in Spartan2/Virtex can be driven by one of the two dedicated IOBs (either top or bottom side), by either the top or bottom DLLs or by any internal signal. To drive a global clock net with any normal IOB you have to instantiate (in schematics or HDL) an IBUF followed by a BUFG. Catalin Baetoniu Starnet Engineering Inc. "Carsten Nöding" wrote: > According to Xilinx documentation the BUFGPs of the Virtex and Spartan-II > devices can only be driven by the four dedicated IOBs. That means that you > cannot use an internal signal to drive a BUFGP. > > Carsten > > "Matthias Fuchs" <matthias.fuchs@esd-electronics.com> wrote in message > news:3AFC023A.F6987791@esd-electronics.com... > > Hi, > > > > is it possible to use a normal (non clock) pad from a Spartan II FPGA to > > drive an internal clock net ? Automatic implementation cannot do that > > and aborts with an error ! Is it possible to force a connection from PAD > > to INBUF to BUFGP by hand ? Clock skew or the delay from the clock pad > > to the FFs is not that critical for this design ! > > > > Has anybody an idea how to do this ? > > > > Matthias > > -- > > ------------------------------------------------- > > \ Matthias Fuchs \ > > \ esd electronic system design Gmbh \ > > \ Vahrenwalder Straße 205 \ > > \ D-30165 Hannover \ > > \ email: matthias.fuchs@esd-electronics.com \ > > \ phone: +49-511-37298-0 \ > > \ fax: +49-511-37298-68 \ > > --------------------------------------------------Article: 31099
Hi Matthias, The problem is that you're using a BUFGP. Use a BUFG instead and this connection scheme will work just fine. The problem is that a BUFGP is a macro containing a IBUFG and BUFG in series- which will result in an error if it's input is connected to an IBUF output. Regards, Tim Jaynes CAE Matthias Fuchs wrote: > Hi, > > is it possible to use a normal (non clock) pad from a Spartan II FPGA to > drive an internal clock net ? Automatic implementation cannot do that > and aborts with an error ! Is it possible to force a connection from PAD > to INBUF to BUFGP by hand ? Clock skew or the delay from the clock pad > to the FFs is not that critical for this design ! > > Has anybody an idea how to do this ? > > Matthias > -- > ------------------------------------------------- > \ Matthias Fuchs \ > \ esd electronic system design Gmbh \ > \ Vahrenwalder Straße 205 \ > \ D-30165 Hannover \ > \ email: matthias.fuchs@esd-electronics.com \ > \ phone: +49-511-37298-0 \ > \ fax: +49-511-37298-68 \ > --------------------------------------------------
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