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
Ray Andraka wrote: > It can be done without block rams. Depending on what the registers hold, you > may not need synchronizing logic (a mode bit for instance often can be set > without timing consequence if the processor it controls is idle). Let's assume > you need to write synchronously into a sytem with an async DSP write. The DSP > write occurs on a write strobe that is async to any clocks you have. > > What you do is let the DSP write pulse clock an input register(s) that > essentially gets written with the DSP data. You might also want to write a few > bits of the address so you can figure out where the data is supposed to go. So > far, we're not doing anything to get into the timing of our FPGA logic, this is > all self timed from the DSP (you may want to connect the write pulse to a clock > buffer). This is nearer to the solution I thought of, thanks Ray. I just wonder how many FF you can use safely when its clock is not connected to a dedicated pin, or if all clock buffers are in use already. Setting a LOWSKEWNET will help. But what are your experiences? > For readback, internally select the register using just the address, > as it comes earlier, then turn on the output buffers with the qualified read. Yes, but you have to take care on the read signal as well, may be I forgot to mention, that the DSP data bus is a bidirectional one. This is exactly where my problem occurs: I use async. logic for read accesses and depending on the mood of the tools glitches are produced at the external data bus. I don't know how to control them without FFs. > Now, if you need the data syncrhonized to your FPGA clock, you toggle an > additional flip-flop with the write pulse, so that each time a write occurs, the > toggle flop changes to the opposite state. You synchronize that toggle flop > output to the FPGA clock domain through a flip-flop or two, and then drive a > state machine that generates a 1 clock wide write pulse each time it sees that > synchronized toggle change state. That write pulse can then be used to > synchronously and safely copy the data captured in the write register to another > register in your FPGA clock domain. The only requirement is you have to > guarantee the capture register is not changed before the transfer occurs, which > can usually be done by making sure the local clock goes through at least 3 or 4 > cycles in the fastest possible DSP write time (if not, you can assemble several > DSP writes into a long word and transfer only after the nth write). Good idea, I don't think that the writing of the data is a problem anymore. > Reading back can be a little trickier, but the same sort of set up can be used. I am not sure what you mean. For readback I can use the address to select a register, in parallel I can generate a read pulse to store the selected data in an output register. If the read signal is deasserted, the output can be tristated aynchronously. > Here, it helps if the read address is known ahead of time. Sure, some kind of a piplined read would be perfect, unfortunately the DSP does not support such kind of transfers. To be honest, the address is valid only a few ns before the read access, so this won't help much. So I just can forget about implementing a read-after-write feature, beause pipeling takes a lot of time. It is very likely that a read after write to same register would result in reading the old data instead of the new one. We discussed three differnt aspects up to now: 1) registers for external control: best without synchronizing 2) data streams best with asyn. FIFO 3) data to be used internally sync at internal clock. All of these problems occur in my design. Using the internal synchronization seems to be a solution for all of this three situations. Best regards, Chris > "Chris G. Schneider" wrote: > > > > Peter Alfke wrote: > > > > ? Chris, you may want to look at an article about crossing asynchronous > > ? clock boundaries that I published about a year ago. Mayeb it helps > > ? you. > > ? > > ? http://www.isdmag.com/editorial/2000/design0003.html > > ? > > ? Peter Alfke, Xilinx Applications > > ? ================================ > > > > Peter, > > > > I have just reread your nice article. The asynchonous FIFO is a perfect > > solution when it comes to streams of data that the FPGA processes. > > > > In my application FPGA registers are maped into the DSP memory. These > > registers can set hardware switches, and in some cases the DSP data will > > be > > transfered to a synchronous FIFO through a pipeline, or the other way > > round: data from an other FIFO can be read by the DSP as well. > > > > Using synchronous FIFOs forced me to operate these FIFOs at the speed of > > > > the DSP interface (120MHz), but the real data rates are much lower. > > > > The fastest part in my design are the DSP interfaces, all other stuff is > > > > much much slower. > > > > The DSP is able to write to a register and read from it in the next > > access. The effictive data rate of the DSP is about 25 MHz, but DSP > > write strobes are very short (12 ns), and the DSP expects to valid data > > 23 ns after read assertion which is less than 3 clock cycles at 120 MHz. > > > > This is the reason for choosing an asynchronous read access. But > > unfortunately, async. logic can produce glitches, this may be a problem. > > > > I don't know how to use async. FIFOs in this case. I cannot implement a > > FIFO for each register bank, and the read after a write access makes the > > > > use of FIFOs difficult. > > > > I have to implement a lot of these kind of interfaces and I am looking > > for a clean solution. May a cache build of BlockRAM be a possiblity? > > My Virtex-E has some free RAM cells left. The DSP can have fast access > > to the cache, and all write accesses to the registers can be pipelined > > then. But what external clock can be used for this cache? There is just > > the read and write signal of the DSP. > > > > Originally I thought of this as a school book example, because mapping > > FPGA registers into DSP memory seems to be pretty standard. I'm not sure > > > > any more. > > > > Best regards, > > > > Chris > > > > ? > > ? "Chris G. Schneider" wrote: > > ? > > ?? I want to design an interface between a DSP and a FPGA. The DSP > > ?? should > > ?? be able to access FPGA registers, via the DSP parallel port. The > > ?? DSP parallel port has address, data, chip select, read and write > > ?? lines. > > ?? Just the usual stuff. > > ?? > > ?? I just designed this interface, but I am not happy with the results > > ?? in > > ?? terms of speed and design stability. So I want to ask this audience > > ?? for > > ?? some design hints. > > ?? > > ?? 1) Write access: I just synchronize the DSP write signal and > > ?? generate an > > ?? internal write strobe to fetch the data. Is it a better solution to > > ?? use > > ?? the write signal to store the data in a register and then > > ?? synchronize > > ?? the register contents to the internal clock? This makes it possible > > ?? to > > ?? detect very short write strobes of the DSP and to reduce the number > > ?? of > > ?? WS, in the application. > > ?? > > ?? 2) Read access: I use a async. read access at the moment. Is it > > ?? possible > > ?? to make this work synchronously? The problem is that synchronizing > > ?? just > > ?? eats up a lot of time, and timing constraints of modern DSP are > > ?? pretty > > ?? tight. There will be a problem if the FPGA does not release the DSP > > ?? data > > ?? bus fast enough, because read and write accesses can appear very > > ?? soon > > ?? after each other. > > ?? > > ?? Any suggestions, or literature tips? > > ?? > > ?? -- > > ?? chris > > ? > > -- > -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 -- To be shocked is not worth while.Article: 28676
Hello,
Recently I read about Clear Logic Inc. (www.clear-logic.com) which
products ASIC's pin and speed compartible with the same ALTERA chips.
Is anybody worked with Clear Logic? What are the oppinions?
I heard that ALTERA files suit against Clear Logic in 1999. This
press release from ALTERA web-site:
"Altera Files Suit Against Clear Logic for Unlawful Use of
Altera's Technology
San Jose, Calif., November 16, 1999--Altera Corporation (Nasdaq:
ALTR), a leading supplier of high-density programmable logic devices
(PLD), filed suit against Clear Logic, Inc. today in Federal District
Court in San Jose. The case alleges that Clear Logic is unlawfully
using Altera's chip technology. Altera alleges that Clear Logic has
unlawfully appropriated Altera's registered mask work technology in
violation of the federal mask work statute and that Clear Logic has
unlawfully interfered with Altera's customer relations. Altera is
confident of victory because Clear Logic had admitted in its own
literature on many occasions that its technology is "identical". Clear
Logic has never asked for or been given a license for the use of this
technology. The suit asks for compensatory damages, punitive damages,
and an injunction to stop Clear Logic from unlawfully using Altera's
technology."
WHAT THE FINAL OF THIS STORY?
Thank you, Eugeny M. Zubok
Article: 28677"Andrew Dauman" <andrew@synplicity.com> wrote in message news:3A6905E8.C3C1BD9A@synplicity.com... > It should be "news.synplicity.com", can netscape see that? > The server name did not change, it may be a "cache" problem (i.e. > name mapping records are not all updated yet). If so, try 209.157.48.251, I too have been unable to connect to news.synplicity.com for two weeks or so, but this explicit IP address does seem to work. Jan Gray, Gray Research LLCArticle: 28678
bjorn_lindegren@my-deja.com wrote: > > Hi > > I'm looking for a development borad whith a DSP and a FPGA 'Xilinx, a > big one....Spartan II or something'. > > I want this board to have a A/D and a D/A converter for analog sampling. > > If you know any board like this, I will be thankefull for know about it. > > Regards > > Björn Lindegren > > Sent via Deja.com > http://www.deja.com/ You may be interested in our PC104C31 DSP board. This is a PC/104 board capable of operating as a bus slave (uart emulation), bus master or stand alone. The DSP is the TMS320C31 running at up to 80 MHz for 80 MFLOPS. This board uses AIO modules to provide analog IO with an 8 channel, 16 bit 96 KSPS codec module to be available in another month. The AIO modules connect to the DSP through 30K and 4K gate Lucent FPGAs. There is also 256K words of 0 wait state SRAM and 2 MB of Flash memory. If you need faster analog IO, we would be willing to discuss the design a custom AIO module. You can view further information at http://www.arius.com/ or you can drop me an email. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX URL http://www.arius.comArticle: 28679
On Sat, 20 Jan 2001 17:23:11 GMT, "Jan Gray" <jsgray@acm.org> wrote: >"Andrew Dauman" <andrew@synplicity.com> wrote in message >news:3A6905E8.C3C1BD9A@synplicity.com... >> It should be "news.synplicity.com", can netscape see that? >> The server name did not change, it may be a "cache" problem (i.e. >> name mapping records are not all updated yet). If so, try 209.157.48.251, > >I too have been unable to connect to news.synplicity.com for two weeks or >so, but this explicit IP address does seem to work. > >Jan Gray, Gray Research LLC > The weird thing is "ping news.synplicity.com" says unknown host but "ping -a 209.157.48.251" says the IP address is news.synplicity.com. I think somehow DNS records got messed up. Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 28680
Terry Hicks wrote: > Rick Filipkiewicz wrote: > > Are Xilinx going to avoid the SpartanII mistake of letting a few major > > customers soak up all the Virtex-II production leaving those of us > > reliant on the disti's completely out of luck ? [lead time > 20 weeks => > > no design in] > > > > [Anybody remember Ray's joke about the SpartanII T-shirt ?] > > I have to second Rick's comment. How about it? No small quantities= no > design in. I am currently designing a device which would benefit from a > small Virtex-E device due to the LVPECL i/o capability. I don't think I > will use one, as I cannot trust the availability of the Virtex-E parts. I I have a couple of questions about these new parts. Of course availability is a big one. As others have said, if you can't get parts for prototypes, you can't use them in production. Anyone know of the expected availability and price of a low end VirtexII? I would be interested in the XC2V40-4FG256C or XC2V80-4FG256C. It looks like the Xilinx power on current requirement is still 500 mA like the SpartanII chips. Any chance that this will be reduced as the parts are further characterized? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX URL http://www.arius.comArticle: 28681
We have/had a MultiLinx cable for JTAG programming Virtex FPGAs, and it worked well for a while, but (a) was surprisingly slow, (b) appears to have died (though we don't know of any electrical overstress that our target h/w could have applied to it), and (c) is expensive. In retrospect, I like the JTAG Parallel Cable III Model DLC5 much better. We just got another one, and it only costs $95. "Juan M. Rivas" wrote: > I'm looking for a Progrmming Cables from Xilinx, for a stand alone FPGA > proyect: Does anyone know wher I can by one, and which one is good? > > I've been looking for the Multilinx, and the Xcheqer, but I can't > decide...Besides I can't find where to find them (Always out of stock) > > Suggestions??? > > Thanks all -- ============================== William Lenihan lenihan3weNOSPAM@earthlink.net .... remove "NOSPAM" when replying ==============================Article: 28682
It never even occured to me that there would be a Synplicity newsgroup .... their s/w is too damn easy to use! Utku Ozcan wrote: > What happened to Synplicity's newsgroup? > The newsgroup browser tells that the server is down... > > Utku -- ============================== William Lenihan lenihan3weNOSPAM@earthlink.net .... remove "NOSPAM" when replying ==============================Article: 28683
Rick Collins wrote: > Anyone know of the > expected availability and price of a low end VirtexII? I would be > interested in the XC2V40-4FG256C or XC2V80-4FG256C. > > It looks like the Xilinx power on current requirement is still 500 mA > like the SpartanII chips. Any chance that this will be reduced as the > parts are further characterized? > I will check prices and availability, obviously I personally encounter no problem in that regard :-) I am glad to report that the power-on current is in the 40 mA range, ten times lower than on previous generations. It took some doing, but ity has been done. Peter Alfke, Xilinx ApplicationsArticle: 28684
Peter Alfke wrote: > > Rick Collins wrote: > > > Anyone know of the > > expected availability and price of a low end VirtexII? I would be > > interested in the XC2V40-4FG256C or XC2V80-4FG256C. > > > > It looks like the Xilinx power on current requirement is still 500 mA > > like the SpartanII chips. Any chance that this will be reduced as the > > parts are further characterized? > > > > I will check prices and availability, obviously I personally encounter no > problem in that regard :-) > I am glad to report that the power-on current is in the 40 mA range, ten times > lower than on previous generations. It took some doing, but ity has been done. > > Peter Alfke, Xilinx Applications I am no chip designer, but since they are a smaller and newer generation, I would expect the VirtexII to be cheaper than the Spartan II for a given number of gates. But I overlooked a couple of things with the VirtexII parts. They have much less IO for a given size than the other logic I have considered. I would have to go to an XC2V250 to get enough IOs for our design. I doubt that it will be practical to use five XC2V250s on our board in place of five XC2S50s. But the SpartanII chips use too much power on current. So I expect that I will be back where I started, needing to use the Altera 1K parts. But I may be able to use one XC2S50-5FG256C and four XC2V40-4CS144C. I need to look at the IO requirements in detail. We will see how the pricing turns out. But once we pick a family, we will be sticking with that vendor for a number of boards since they will all use compatible FPGA designs. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX URL http://www.arius.comArticle: 28685
A good program which could help: http://www.ti.com/sc/data/jtag/scanedu.exe Greetings, Alain "Juan M. Rivas" <jmrivas@media.mit.edu> wrote in message news:3A68638B.4FED9C3C@media.mit.edu... > Hi all! > > Does anyone know about a good book or article to understand JTAG and > boundary scan? What I've found so far is not really clear... > > Thanks > > Attn. JuanArticle: 28686
I seem to be having difficulty finding an online supplier for one off quantities of Xilinx FPGA/CPLDs in the UK. Specifically Spartans. And preferebly at £few like their press release implies ! I've found are the XC95xxx on RS and that's about it. Xilinx's site suggests two online suppliers, one of which's page doesn't seem to work and the other only delivers in the U.S. Any suggestions ? Or another make with free development tools (but not Actel because their desktop SW didn't agree with me) ? JonArticle: 28687
Hello, I need help in understanding the following problem: Within a complex XC95108-7 design, an input signal is supposed to be latched and transferred to an output pin. The latched signal will also be used as input term elsewhere. | FF PIN output ISTYPE 'REG_D,BUFFER'; | : | FF.CLK = mainclock.pin (pin 9) | FF.D = input.pin Sporadically, this simple function fails, i.e. the /output/ stays at 0 where it should follow the input's 1. The other terms in the design using 'FF.Q' do also see the same logical level as found at the /outpit/ pin. This failure occurs sporadically and seldom (1 failure per 1 million clocks) ** What could produce this failure? ** * The clock provided by a special clock distributor MPC947, which is driven by a 30MHz integrated xtal-oscillator. * There are no glitches visible (500Msamples/sec, storage scope, 100MHZ Bandwidth, large persisting time) at the input.pin. * Power also looks clean. There is 0.1 microfarad on each power pin to the GND plane. * Exchanging the chip by a new one does not help. Could the following have something to do with it: On the same chip there are 32 pins driving a kind of data bus. The same bus is also driven by another chip (#2) while the databus pins of the first chip (#1) are forced to tristate: | DATA1.OE = enable.pin (eqn. for chip #1) | DATA2.OE = !enable.pin (eqn. for chip #2) Now it might be possible, that both chips are driving the bus simultaneously for ~ a nanosecond during the transition of the /enable/ signal. This transition occurs with ~ 4MHz frequency. Could that mess up the core of the XC95108 so much that the FF - function (descibed at the top of the arcicle) fails? Does the temporary 'short circuit' lead to a drop of the internal power of the chip? Is 0.1 microfarad on each power-supply-pin enough or should it be considerably more? Many thanks in advance! Ralf. -- Ralf A. Eckhardt a.eckhardt@t-online.deArticle: 28688
In article <3A6AE9F8.C8A1CDF7@t-online.de>, a.eckhardt@t-online.de wrote: (snip) > > Could the following have something to do with it: > > On the same chip there are 32 pins driving a kind of data bus. > The same bus is also driven by another chip (#2) while the databus > pins of the first chip (#1) are forced to tristate: > > | DATA1.OE = enable.pin (eqn. for chip #1) > | DATA2.OE = !enable.pin (eqn. for chip #2) > > Now it might be possible, that both chips are driving the bus > simultaneously for ~ a nanosecond during the transition of the > /enable/ signal. This transition occurs with ~ 4MHz frequency. > > Could that mess up the core of the XC95108 so much that the > FF - function (descibed at the top of the arcicle) fails? > Does the temporary 'short circuit' lead to a drop of the > internal power of the chip? I doubt that this is your problem, but I still would design to avoid bus contention. If you can't do it with a synchronous state machine, then some cross-coupled feedback will probably suffice. Buffer the enable signal through the CPLD, so that you have a delayed copy of enable from each chip. Use the delayed enable from one chip as a second enable for the other chip. This will prevent the second chip from enabling until the delayed enable from the other chip changes state. Don't use a fast output for the delayed enable. You will have to check the timing, but this will probably do the trick. I guess the equations would look something like this: In chip 1: enable_2 = !enable DATA1.OE = enable * enable_1 In chip 2: enable_1 = enable DATA2.OE = !enable * enable_2 > Is 0.1 microfarad on each power-supply-pin enough or should it > be considerably more? This should be OK. Have you checked to make sure that the input data meets the input setup and hold time requirements? Are you using a multi-layer board with ground and VCC planes? -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/Article: 28689
It appears that the FG456 parts are cavity UP, but I want to make sure before doing my pinouts... The floorplanner gives the low number, low letter in the upper left. The FPGA Editor gives the low number, low letter in the upper left. The package drawing shows low number, low letter in the upper left (top view of package). That to me, means this is a cavity up part. The BG352 is a cavity down part...since the floorplanner gives the low number low letter in the in the upper RIGHT . The FPGA Editor gives the low number, low letter in the upper RIGHT. The package drawing shows the low number, low letter in the upper left (top view of package). That, to me, means this is a cavity DOWN part...since the die has to be flipped to line up the die pins with the package pins. Both the FPGA Editor and the Floorplanner are both 'die' view, it would appear. When doing floorplanning, at least for me, I would prefer the Floorplanner be a TOP view (or give you the option of die view or top view), so I can lay my chip out without having to flip everything over to really see how it lines up with the outside world... I REALLY wish they had a chart that showed the orientation of the die in each package...and I've mentioned this to them many a time. Any comments?Article: 28690
<jms@geriatrix.circlesXXXXXquared.com> wrote in message news:wkofx19fkq.fsf@geriatrix.circlesXXXXXquared.com... > I seem to be having difficulty finding an online supplier for one off > quantities of Xilinx FPGA/CPLDs in the UK. Specifically Spartans. And > preferebly at £few like their press release implies ! I've had no trouble getting small quantities of Xilinx parts (at reasonable prices) from the company formerly known as Micro-Call, now Insight-Memec. They don't have online ordering (yet), but give 'em a call on 01296 330061. ....It must be said, however, that since Memec restructured their UK operations into Insight, Impact, and Unique, it all seems to have gone a bit pear-shaped.... IMHO, of course. MH.Article: 28691
Greg Neff wrote:
> I doubt that this is your problem, but I still would design to avoid
> bus contention. If you can't do it with a synchronous state machine,
> (...)
Effectively, I do this synchoneously. The /enable/ input
is fed directly from a D-latch which is clocked by the mainclock.
Nevertheless I am concerned about different delays between
DATA1.OE-->off in Chip#1 and DATA2.OE-->on in Chip#2.
That problem remains the same, synchroneously or asynchroneously.
> then some cross-coupled feedback will probably suffice. Buffer the
> enable signal through the CPLD, so that you have a delayed copy of
> enable from each chip. (...)
> I guess the equations would look something like this:
> (...)
> DATA1.OE = enable * enable_1
> (...)
Good Idea! This makes sure, that both outputs cannot be driven
simultaneously. I will try that. Unfortuatelly, this will require
redesign of an existing PCB as new wires are to be drawn.
And, to tell the whole story, in fact there are not 2 but 3 drivers
to synchronize, (roughly: DATA1.OE = enable * enable_2 * enable_3),
but well, the whole thing needs redesign anyway.
After all the question remains: can such a bad bus-design
affect the proper function of other logical blocks on the chip?
> Don't use a fast output for the delayed enable.
I am using ABEL(FOUNDATION 2.1) for the design and as far as I
can see the compiler reports each output to be in the 'fast mode'.
How do I switch to 'slow' mode?
> Have you checked to make sure that the input data meets the input
> setup and hold time requirements?
The input comes asynchroneously (changes slowly, stable for
microseconds) and the D-FF is supposed to synchronize it.
If the hold time is not met, I would expect the data to be
latched at the following rising clock (33ns later).
But it comes /never/ or 10..20 cycles later.
Might metastability be a serious problem here?
> Are you using a multi-layer board with ground and VCC planes?
Multilayer with GND plane. No Vcc-Plane, but thick connections
(1-2mm) with SMD-Cer-Caps blocking at each Vcc-Pin.
Thanks for your help;
Ralf.
--
Ralf A. Eckhardt
a.eckhardt@t-online.de
Article: 28692<jms@geriatrix.circlesXXXXXquared.com> wrote in message news:wkofx19fkq.fsf@geriatrix.circlesXXXXXquared.com... > I seem to be having difficulty finding an online supplier for one off > quantities of Xilinx FPGA/CPLDs in the UK. Specifically Spartans. And > preferebly at £few like their press release implies ! > > I've found are the XC95xxx on RS and that's about it. > > Xilinx's site suggests two online suppliers, one of which's page > doesn't seem to work and the other only delivers in the U.S. > > Any suggestions ? > > Or another make with free development tools (but not Actel because > their desktop SW didn't agree with me) ? > I've been thinking about starting a FPGA user's group in the UK, and one of the things it would have is small quantities of parts available to experimenters and maybe demo boards. Another idea I've thought about is making a proto board around the Spartan II XC2S150-FG456 and the XC18V01SO20, but unlike the others I've seen, there would be no other logic, just footprints for several pitches of common connectors (0.1", 2mm hard metric, HD-68, etc) for each I/O pin.... -- Gary Watson gary2@nexsan.com (you should leave off the digit two for email) Nexsan Technologies Ltd. Derby DE21 7BF ENGLAND UK-based Engineers: See our job postings at http://www.nexsan.com/pages/careers.htmArticle: 28693
I designed a board with five 95108 CPLD's on. Had spare tracks running between 1-2,1-3,1-4,1-5, 2-3, 2-4, 2-5, 3-4, 3-5, 4-5. Very useful when you need extra signals! The prototype of this board had only 1 short mod wire due to this! Paul. "Ralf A. Eckhardt" <a.eckhardt@t-online.de> wrote in message news:3A6B1A54.97388C5C@t-online.de... > Greg Neff wrote: > > > I doubt that this is your problem, but I still would design to avoid > > bus contention. If you can't do it with a synchronous state machine, > > (...) > > Effectively, I do this synchoneously. The /enable/ input > is fed directly from a D-latch which is clocked by the mainclock. > Nevertheless I am concerned about different delays between > DATA1.OE-->off in Chip#1 and DATA2.OE-->on in Chip#2. > That problem remains the same, synchroneously or asynchroneously. > > > then some cross-coupled feedback will probably suffice. Buffer the > > enable signal through the CPLD, so that you have a delayed copy of > > enable from each chip. (...) > > I guess the equations would look something like this: > > (...) > > DATA1.OE = enable * enable_1 > > (...) > > Good Idea! This makes sure, that both outputs cannot be driven > simultaneously. I will try that. Unfortuatelly, this will require > redesign of an existing PCB as new wires are to be drawn. > And, to tell the whole story, in fact there are not 2 but 3 drivers > to synchronize, (roughly: DATA1.OE = enable * enable_2 * enable_3), > but well, the whole thing needs redesign anyway. > > After all the question remains: can such a bad bus-design > affect the proper function of other logical blocks on the chip? > > > Don't use a fast output for the delayed enable. > > I am using ABEL(FOUNDATION 2.1) for the design and as far as I > can see the compiler reports each output to be in the 'fast mode'. > How do I switch to 'slow' mode? > > > Have you checked to make sure that the input data meets the input > > setup and hold time requirements? > > The input comes asynchroneously (changes slowly, stable for > microseconds) and the D-FF is supposed to synchronize it. > If the hold time is not met, I would expect the data to be > latched at the following rising clock (33ns later). > But it comes /never/ or 10..20 cycles later. > > Might metastability be a serious problem here? > > > Are you using a multi-layer board with ground and VCC planes? > > Multilayer with GND plane. No Vcc-Plane, but thick connections > (1-2mm) with SMD-Cer-Caps blocking at each Vcc-Pin. > > > Thanks for your help; > Ralf. > -- > Ralf A. Eckhardt > a.eckhardt@t-online.deArticle: 28694
The three North American distributors have fairly good stock. They have online stock and prices. http://www.marshall.com/ http://www.insight-electronics.com/cgi-bin/catalog.cgi?origin=order_page http://www.nuhorizons.com/ -- Sincerely Daniel DeConinck High Res Technologies, Inc.Article: 28695
Hi,
Any ideas on the best design for a down counter that can decrement in
programmed steps from a pre programmed start point, at zero it should assert
a flag and loop back to the start point and down count again. In otherwords
a fractional counter were you can programme the denominator and numerator,
so the flag will go high at the programmed fraction of the clock rate.
Thanks
Ja
Article: 28696There is a new users guide for HDLmaker available at http://www.polybus.com/hdlmaker/users_guide HDLmaker is an open source Verilog/VHDL code generator with extensive support for Xilinx FPGAs. HDLmaker is licensed under the terms of the BSD license. Sent via Deja.com http://www.deja.com/Article: 28697
Is it possible to directly drive/receive a IEEE1394 firewire bus from the LVDS outputs of a Xilinx FPGA ? Also, where is a good place to learn more about the firewire standard ? Sincerely Daniel DeConinck High Res Technologies, Inc.Article: 28698
Hi, Rick, see my comments below: Rick Collins wrote: > I am no chip designer, but since they are a smaller and newer > generation, I would expect the VirtexII to be cheaper than the Spartan > II for a given number of gates. In the long run, this may be true, but in the short run, a new and faster family with many new features will initially be priced higher. Virtex-E was an exception. > But I overlooked a couple of things with > the VirtexII parts. They have much less IO for a given size than the > other logic I have considered. I would have to go to an XC2V250 to get > enough IOs for our design. Unfortunately, your requirements fall into the big hole betweenXC2V80 and '250. And you are right, per logic function, Virtex-II offers fewer I/O, but many additional features. > > I doubt that it will be practical to use five XC2V250s on our board in > place of five XC2S50s. But the SpartanII chips use too much power on > current. Sorry for that. Can you perhaps stagger the Vcc to teh 5 chips? The power-on current lasts only milliseconds... > So I expect that I will be back where I started, needing to use > the Altera 1K parts. But I may be able to use one XC2S50-5FG256C and > four XC2V40-4CS144C. I need to look at the IO requirements in detail. I would be aggressive and integrate higher. I cannot believe you need all those I/O when you put it all in one chip, like the XC2V1000. You get 432 I/O, >10,000 Logic Cells = flip-flops, where the XC2S50 has only 1,728. And, the XC2V1000 is alreadyavailable ( in very limited quantity ) The '40 and '1000 were the first ones "out of the oven", all others will be coming soon. I think I have already touted the superior features of Virtex-II before. Good luck! PeterArticle: 28699
If you look at this design not as a counter, but as a presettable accumulator ( accumulating negativve values), it will look far more natural = trivial. Peter Alfke, Xilinx Applications ========================================== jam wrote: > Hi, > > Any ideas on the best design for a down counter that can decrement in > programmed steps from a pre programmed start point, at zero it should assert > a flag and loop back to the start point and down count again. In otherwords > a fractional counter were you can programme the denominator and numerator, > so the flag will go high at the programmed fraction of the clock rate. > > Thanks > > Ja
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