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
Peter <z80@ds2.com> wrote: :>As NRE charges go :>through the roof for high-density ASICs, FPGAs will continue to severely :>erode all but the highest-volume ASIC sockets. : Unless you want low power, in which case an ASIC can give you a 10x + : advantage in dynamic Icc over an FPGA. Granted. :>: FPGAs will be used mainly for prototyping and educational environment. :> :>That's a total load of crap. Ask Cisco. : Not such a good example, because everything they sell is very high : priced, so they can afford it. True, but that has nothing to do with the question, does it? JonathanArticle: 22626
Hi Sebastien,
Time for the next installment on this thread, but first,
I would like to agree with Catalin Baetoniu, who wrote:
>I wouldn't worry about the configuration before solving the LDC and DONE
>signal level problem. Are all your ground pins connected? What is the
>voltage level on these ground pins? What is your reference point when you
>make these measurements? If you find more than 1V between LDC and an FPGA
>ground pin something is definitely wrong. Maybe you have a conflict on
>LDC with another signal that is high. Solve this problem first. Then check
>CCLK for ringing, double clock edges, etc.
In your most recent message, you said that both DONE and INIT whel low
were at 1V. The only thing that makes sense is either the ground pins are
not all connected, or you have REALL low values for their pullup
resistors. I typically use 4700 ohms for the pullups. You must check the
voltage on ALL your ground pins and make sure they are at or very near
ground potential.
In article <39140319.4F0B81E3@utc.fr>,
Sebastien Favard (Gordh) <Sebastien.Favard@utc.fr> wrote:
>Philip,
>
>Thanks really for all you help and your very explicit post.
>I just ask you to clean some things in your post...
Ok
>Firstly, when you explain that the Program/ pull down, it's naturally me that
>must pull down this line ?
You must pull it low, then take it back high.
I couldn't find how long it needs to be low in the data sheet, but I
would recommend greater than 5 uS.
>Next the Init/ line pull up, so drive by the FPGA, yes ?
Not quite. The INIT pin should have a pullup resistor connected to it all
the time. I use 4.7K ohms. The FPGA responds to the program signal going
from high to low by starting to do the internal clearing. If it is low for
a long time it will just keep doing the clearing over and over. When you
take program high, it will do the clearing one more time. All during this
time, INIT will be driven low by the FPGA. After program has gone high,
and the clearing process has completed, the FPGA stops driving the INIT
pin low, and your external pullup resistor will pull the INIT line high.
During all this time the CCLK signal must not be running. Typically you
set it high. After INIT goes high and you wait at least 6 uS, you set the
first data bit (a '1') , and the CCLK is cycled once. The data is taken
by the FPGA on the low to high edge. This is then repeated for the rest
of the bitstream. But as Catalin said, if DONE and INIT are at 1 volt
rather than 0V (or within a few 100 mV of 0V), all of this is pointless,
since something more fundamental is wrong.
>But when I power on the FPGA, must I pull down the Prg/ line ?
No. The FPGA will do a power on reset, which is the equivalent of pulsing
the program pin low. You do need to hold it high, and you must stil wait
for INIT to go high before starting CCLK. If you want to reconfigure, you
need to use the program pin.
> And when the init/ signal pull up after, must I pull up the prg/ pin ?
Yes
>Secondly, you have very good explain the bitstream format. But we are
>agree that all bits on the bitstream must be swap,
NO. When you talk about swaping, you are assuming that the data is
grouped in something bigger than a bit, such as a byte. This may be your
case, depending on the file format you are using. But it is your choice
how you shift the data out to the FPGA. If you choose to shift it out
from the MSB (most significant bit) first, you get a totally different
stream of bits from if you shift the byte out one bit at a time from the
LSB (least significant bit). So swaping depends on how you shift the data.
>so the length count too. So when we see the bistream file with the
>length count 42409 for example like:
>
>0000 0000
>1010 0101
>1010 1001
>
>I must send data in this byte order but swapped of course, so :
>0000 0000 1010 0101 1001 0101
>
>yes ?
NO. the bit are sent 0000 0000 1010 0101 1010 1001
^ ^
| +-- this bit goes in last
+-- This bit goes in first
That is, take each byte, and shift it into the FPGA, MSB first.
>Because I think it's stange for the internal serial latchs to
>swap after the first and the third byte....
They don't. The length count register is just a 24 bit shift register. The
data is shifted in at the LSB end, and after 24 clocks, the first bit in
will now be at the MSB end, and the last bit in will be in the LSB
position. The FPGA knows when the 24 bits have been loaded, and stops
loading the length counter, and starts looking for the first '0' bit
after the filler '1' bits that follow the length count. Then it starts
doing the main job of configuring.
I think you may be helped by running the bitgen program, and having it
create a rawbits file. This is an ascii file, that you can read. The data
that goes into the FPGA is EXACTLY as this file shows it, reading the
lines of text left to right, is the sequence the bits are loaded into the
FPGA.
> Perhaps it's the less significant byte before to
>the most significant ? (but of course with all bits swapped)
No. see above.
>For me, now, when I power on the FPGA, init? is high.
It will go high after config clearing, if program is already high.
>I pull down after Prg/ and wait that init/ is high (true
>of course) and send all bits.
No. If you wont be reconfiguring (without turning power off and back on),
you can start configuring without pulsing program low. Init wont go high
until program has gone high.
>But there a always bit reported on the DOUT pin. So my FPGA has never
>detect the header, no ?
Right, or somehow it thinks it has finished configuring. Either way, the
problem seems to be you need to find out why DONE and INIT dont go to a
valid LOW level.
Of course, you might just have a dead chip?
Good luck,
Philip Freidin
Article: 22627Jerry Avins wrote: > > Result of check: I asked a CS friend (he has a masters degree and is > active in the profession) if he knew or could guess what a mutex is. He > had a vague memory that it is a species of mosquito. > snip hehe, I'm not a CS, but I did have a course in real-time systems, and it was used in the book we used, and as an example was the "sleeping barber problem" I can't remember the name of the book but it was probably by Tanenbaum and it's in the SunOS "Guide to multi-thread programming" too --Lasse (+)--------------------------(+) | Lasse Langwadt Christensen | | Aalborg, Denmark | (+)--------------------------(+)Article: 22628
> > >: FPGAs will be used mainly for prototyping and educational environment. > > > >That's a total load of crap. Ask Cisco. > > Not such a good example, because everything they sell is very high > priced, so they can afford it. > Seeing the price Xilinx is advertising for Spartan II, I would have thought that only in specialised cases would the higher preparation costs of Asics be viable. AndyArticle: 22629
Andy Holt wrote: > > > > >: FPGAs will be used mainly for prototyping and educational environment. > > > > > >That's a total load of crap. Ask Cisco. > > > > Not such a good example, because everything they sell is very high > > priced, so they can afford it. > > > Seeing the price Xilinx is advertising for Spartan II, I would have > thought that only in specialised cases would the higher preparation > costs of Asics be viable. > > Andy One open question is whether the ease of copying an SRAM based FPGA design is holding back the take up of FPGAs for fairly high volume products. The ways around this have been discussed to death several times on this ng.. Anybody have any actual evidence/experience as whether this factor is *really* inhibiting the growth of the FPGA market. Any comments from the Vendors ? I would have though that if this is a serious obstruction then the first Vendor to build a solution into their h/w will clean up. Thought: Maybe building such a solution into the h/w would expose the vendor to legal action if the ``protected'' design is actually copied or reverse-engineered. Implication: Once again fear of the lawyers is stifling innovation.Article: 22630
We try to program an XC1804 serial PROM via a Parallel Cable III using the JTAG-Programmer Software with the latest Service Pack installed. The programming seems to be performed correctly but both PROM-readback and FPGA-configuration fail. The boundary scan (JTAG) chain is built up in the following way: Parallel Cable III -> Virtex 600 -> XC95144XL -> XC1804 -> back to Parallel Cable III Chain intitialization is working, the JTAG SW gets the correct device information. The Virtex 600 can be configured and the circuit is working fine. The CPLD 95144 hasn't been tried to configure yet. Are there any known bugs which can occur in this kind of JTAG chain? Are there any known bugs concerning the JTAG programmer software? Are there any known bugs concerning these brand new kind of PROM? Any kind of information concerning our problem is welcome. Regards Peter Schulz SignaalArticle: 22631
Rick Filipkiewicz wrote: > > One open question is whether the ease of copying an SRAM based FPGA design is > holding back the take up of FPGAs for fairly high volume products. The ways > around this have been discussed to death several times on this ng.. ... Another fear rather than copying might apply for digital TV decoders, DVD players, and the like. That is the probability of crackers being able to "chip" the unit to disable copy-protection mechanisms just by supplying ROMs. AndyArticle: 22632
Thank you all for the replies I have so far received, bith via the newsgroup and directly by email. Dave Vanden Bout wrote: > > > As for software, the Kanda and Atmel packages come with some, for the > > Xess one I would also have to spend another $100 for the Foundation > > student edition. > > Buying the Xilinx Student Edition gives you a $30 discount on the XS40 Board. (I had factored that into the costs I was estimating) > Also, the new version of the Xilinx Student Edition may offer some additional price restructuring whenever it appears. Furthermore, it appears that the price from amazon.co.uk is considerably less than that from amazon.com (how odd!) Anyhow I now have that on order (I picked-up a remaindered copy of 1.3 very cheaply a few weeks ago, it was this that gave me the idea of "playing" with FPGAs) > I assume you checked all the boards listed at http://www.optimagic.com? I had used that as the basis for my search, but on rechecking I find two more possibilites: There are some Brazilian (www.aee.com.br) boards supporting the Xilinx chips - not dramatically different from the Xess ones in terms of features or price (allowing for the voucher price from Xess). As your book is written with the Xess cards in mind there seems to be little point in following-up this alternative. Perhaps more interesting is a Spartan II board from Insight Electronics. (http://www.insight-electronics.com/xcellence/scalable/kit/spartan/index.html) At first I thought the low price in the board list had to be a mistake, but seeing how Xilinx seems to be very aggressive with its pricing for the Spartan II I am now more inclined to believe it even though I couldn't find any way of checking the price on the web site. The plus point is that it would give a much larger device for my money - one that I can have a high degree of confidence that it is "big enough" (whereas I suspect the 4010 could be a tight fit). The catch is that the Spartan II series is not supported by the current student edition of Foundation and it is not clear whether the ($95) Foundation Base supports the full size range of Spartan II or only the smallest two versions. By the pricing it looks like Xilinx wants to encourage this range to replace the 4000 range and thus I might reasonably hope to see low cost software support. Unfortunately I wasn't committed enough a week ago when a copy of Foundation Base Express sold on eBay for about $50, I should have bought that and then the decision would have been less difficult. Thanks once again to (Dave, Ray, Rick, Don, Tony, & Michel) AndyArticle: 22633
Andy Holt wrote: > > <snip> and it is not clear whether the ($95) > Foundation Base supports the full size range of Spartan II. It does. Peter Alfke, Xilinx ApplicationsArticle: 22634
Adams wrote in message <8fjerj$2e1u$2@news.cz.js.cn>...
>Hi,
>
>I write the following code to achieve a serial communition between PS2
>keyboard and fpga. One start bit, 8 bits data, 1 parity, 1 stop.
>then change it into parallel. The problem is not the code did not work(I
>know the pdata assignment should not be like this,I should use shift
>register structure). I had changed them into a mess. The confusing thing
is
>that the synthesizing tool can not recognize my state machine. And it
>ignored KBCLK, and the state variable.
>
>I have tried Xilinx Foundation 2.1i/Fpga Express (use XCS10 LC 84) and
>Maxplus 2(use EPM7128sLC84). Neither work. In maxplus2, CNT8 change from
S0
>to S1, then S10!! Thean back to S0. In Fpga Express, I can see the
>synthesized schematic, it ignored my KBCLK.
>
>Anyone knows why, please help me.
>ARCHITECTURE ONE OF kbps2 IS
> type Sreg_type is (S0,S1,S2, S3,S4,S5,S6,S7,S8,S9,S10);
> SIGNAL CNT8:SREG_TYPE;
>BEGIN
>recv:
> process(reset,KBCLK,kbdata)
Your sensitivity list is wrong. You need to use the correct "template" so
the synth tools will know that you want to generate flip-flops. kbdata
should NOT be in your sensitivity list - only the clock and reset go there.
Remember that flip-flops are sensitive only to clock edges (and the async
reset)!
-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"A sufficiently advanced technology is indistinguishable from magic"
--Arthur C. Clarke
Article: 22635You might think about this. http://www.sidsa.es/fipsoc_r.htm 8051 10 bit DAC ADC @800K samples/sec 96 logic blocks (4 4-LUTs and 4 registers) 56 programmable I/O All you would need is a $5 SRAM and you'd have your complete system. Steve Casselman, President Virtual Computer Corporation <shahzad2512@my-deja.com> wrote in message news:8fglhp$frl$1@nnrp1.deja.com... > I have to implement the following: > 1. 8032 microcontroller, > 2. 64kbytes SRAM, > 3. some 8 latches and two 3x8 decoders, > 4. 12kHz Generator > 5. 16kHz detection > 6. DTMF dialer. > > The above is the customized solution for a telephone set for some > telecom company. > > After some initial study, i think that Virtex could give me solution. > There is also an A/D converter(which i might need) in the Virtex and > such a large memory could only be implemented in an Virtex. > > But then i thought that since Virtex is expensive, this is not a good > solution. I thought of SPARTAN II but then SRAM is out. > What do u thing and suggest. > Any comments........? > Thanks and Regards, > SHAH > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 22636
Peter,
There have been many problems in the JTAG Programming of Xilinx FPGAs.
I believe that SP6 solves many problems but at least one problem remains.
We found that the SPROM had to be the FIRST device in the chain or it
doesn't program properly. Also watch out for possible bad XC1804s -- the
first ones had real big headache problems in them.
There are two kinds of problems here -- software problems in the JTAG
program and hardware problems in the SPROM and possibly elsewhere. Xilinx
will readily admit to the software problems if you probe them enough.
Getting data from them on hardware problems is next to impossible.
Simon
> The boundary scan (JTAG) chain is built up in the following way:
>
> Parallel Cable III -> Virtex 600 -> XC95144XL -> XC1804 -> back to
> Parallel Cable III
>
> Chain intitialization is working, the JTAG SW gets the correct device
> information.
> The Virtex 600 can be configured and the circuit is working fine.
> The CPLD 95144 hasn't been tried to configure yet.
>
> Are there any known bugs which can occur in this kind of JTAG chain?
>
> Are there any known bugs concerning the JTAG programmer software?
>
> Are there any known bugs concerning these brand new kind of PROM?
>
> Any kind of information concerning our problem is welcome.
>
>
> Regards
>
> Peter Schulz
> Signaal
>
>
>
>
Article: 22637Tom, Interesting. I think I've recreated your method via manual routing using FPGA-Editor on an XCV50E. I don't get any DRC errors. I wonder if there's another DRC check that's run separately for "proper" DLL usage, as opposed to the DRC check the FPGA-Editor runs for "allowable routing". If so, that may explain what you're getting. Take another look at XAPP133, particularly figure 10. The second DLL isn't fluff, because routing from either the DLL CLK0/CLK90/...) pin or the BUFG pin to an IOB O pin does not use the global clock routing, so you'll get skew. The first DLL drives the output pin with some delay in the path, which will vary with process, temperature, and voltage. That pin feeds back to the first DLL, which compensates for those unknown delays, so that output pin will match the phase of the reference clock. The second DLL accomplishes the same thing for the internal clock. You're trying to use one DLL for both functions, but there's only one feedback pin, so you can't compensate for both the output delay and the internal clock. I'd guess the error message is poorly phrased. It should say, simply, that if you're feeding the output of a DLL to a BUFG, you must take the output of that BUFG to the feedback pin, otherwise you can't guarantee the phase of the internal clock. I suggest you follow XAPP133 figure 10, but I hope you have a spare DLL (gee, it's a -E part, so you should!) and haven't locked pins yet. You should be able to feed the CLK0/CLK90/... pin directly to multiple IOB O pins. Don't use a BUFG on that DLL, but do make sure you bring one of the output clocks back in to the feedback pin. (Aside from using the BUFG, this is what you've done already, right?) Use the second DLL as diagrammed. Here's the problem: you will get some skew between the multiple output clocks. You can minimize the skew with placement, timing constraints, and, heaven forbid, manual routing. If you think you can live with up to +-500ps of skew, I think you'll be okay. You will need to make sure the output clocks are close to each other, though. Good luck, Marc P.S. I sent this on May 12th through Xilinx's comp.arch.fpga mirror (support.xilinx.com->forums->comp.arch.fpga) and it appeared, but I just checked comp.arch.fpga from a different news server and I couldn't find it. Indeed, none of my postings through Xilinx show up here, but they're all visible from the Xilinx site.Article: 22638
(I posted this 3 weeks ago through Xilinx's mirror of comp.arch.fpga and I can see it there, but I just checked through a different news server and it's not visible. So here it is, again. I apologize for the duplication and the delay.) Try Roman-Jones, Inc. at http://www.roman-jones.com/ I've used their $120 programmer and it's fine. It will only program Xilinx SPROMs, though. MarcArticle: 22639
(I apologize for the duplicate post. For some reason SOME but not all of my postings to this newsgroup through Xilinx's comp.arch.fpga mirror do not show up. I originally posted this response 6 days ago.) (Jon: Virtex parts don't have XTAL pins.) Simply put, P213 is a GCLK input (clock 3). This pad connects directly to an IBUFG, which can only route to a DLL or a BUFG (global clock driver). (NOTE for others: the GCLK input pins can't be used as outputs!) Yes, you can get the signal on P213 to your logic, but it must follow the IBUFG/BUFG path (or through the DLL) and then getting it from a global clock net to something other than a K (clock), CE (clock enable), and certain other CLB inputs requires messy routing. The Xilinx tools will do it, but you'll get long delays. What you can't do is try to put an IBUF on P213: there isn't one there. Also, you can't use the syn_noclockbuf on P213: without the BUFG you won't get a connection to the IBUFG and pad. If Synplify is attaching an IBUF to P213 it's a Synplify mistake, not a Xilinx mistake. Marc "Matt Gavin" <mtgavin@collins.rockwell.com> wrote in message news:39132F64.A3CCC710@collins.rockwell.com... > FPGA gurus, > > I am programming a Virtex XC400, after synthesizing > with Synplify. Synplify claims to be finding my three clocks > requiring global buffers (two input clocks, one internal.) > I am hardwiring the locations of the two input clocks to pins > 89 and 92 (which of course are global buffer pins). > > I am having problems putting a normal (non-clock) input > on one of the global buffer input pins that I am not using > for a global buffer (pin 213). The error message from the mapper > follows. > > Running directed packing... > ERROR:xvkpu:19 - The symbol XTAL1200K.PAD failed to join a regular > I/O > component as required. The symbol has a constraint (LOC=P213) > that specifies > an illegal physical site for the component. Please correct the > constraint > value. > Problem encountered during the packing phase. > > 1. Shouldn't I be able to use global buffer pins for inputs > that do NOT require the global buffer? Recall that synplify > is instantiating the buffers for me. > > 2. Also, is there a way for me to find out which of the four buffers > are being used for the internal nets requiring clock buffers? > I can't find it in the logs. > > Thanks, > > Matt >Article: 22640
Hi, I heard of a C to FPGA netlist complier, Can someone tell me where I can find this Thanks Raj, ASU Sent via Deja.com http://www.deja.com/ Before you buy.Article: 22641
Hello, I am attempting to determine how much time we have available for propogation dealy. We're using LVTTL, though we're not sure which particular driver is best. We've been looking at the specs, but aren't quite sure what each of the times represent. What we are looking for is the time from the begining of the clock period to when the pad starts switching. most of the times seem to be when the pad hits 1.4 The O input to pad (with adjustments) seems to be the most relevant number, but not quite it. and how exactly does Tiockp fit in? also the pin-to-pin paramterters in the back? with and without DLL? and finally, what exactly does the Clock to Out represent? and help would be appreciated greatly, thanks!Article: 22642
Hi, All, My supervisor ask me to design some USB inferace with FPGA, where can I find any resource to implement that? Thanks a lot! JesseArticle: 22643
Hi, I search informations about the PnP dialogue between OS like Windows and ISA board. Thanks for all your help Sebastien,Article: 22644
I open a new topic... (after the famous :) "Init/ line - CRC error ???") I have buying a new XC5202 and I have progress on the programmation process step. Firstly, the HDC and LDC/ lines are correctly pull up and pull down respectively. During the FPGA programmation step, the header is correctly detected and its bits are reported on DOUT. Just after the header, DOUT is hold at 5V :) and during the data stream, no crc error ic occured. But after these things Done is hold at low and never pull up. So I think that I have a problem like my length count or perhaps my startup process ? I use in fact CCLK to startup the FPGA, so I put some CCLK rising edge after the data stream to force my FPGA to start up. Perhaps anyone has an idea about my new problem ! (maybe the FPGA banished me ;-) ) Thanks a lot, Sebastien,Article: 22645
Hi, I use Foundation 1.5i with VHDL and Logiblock module and I try to simulate and place-route this version on the Mentor tools. Could you tell me what I need to do (compatibility, files used as .vhd, etc...) Thankful for help B.H.Article: 22646
We are currently seeking BETA users for a Java to Verilog (Synthesizable to any FPGA architecture) compiler. The tool is called "Forge" and is freely available at our website: http://www.lavalogic.com Just click on LEAP and tell us who you are. Then you can download the latest version of our tool. The "Forge" allows chip designers to write high level algorithmic descriptions of their chip directly in pure Java, then translate that description to synthesizable Verilog. The "Forge" is written in Java and will run on any platform running a Java2 virtual machine (available for free from Sun Microsystems). Automated install is supported for Solaris 2.6 and Linux (x86), however installation instructions are available for any platform. Sincerely, Ian http://www.lavalogic.com m_rajanikant@my-deja.com wrote: > > Hi, > I heard of a C to FPGA netlist complier, Can someone tell me where I > can find this > > Thanks > Raj, ASU > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 22647
Hello, I'm looking for a FPGA prototyping board with a PCI interface, but also with a PC104+ interface (i.e. PCI PC104) So far I found only a PC104 (ISA) board for prototyping from nova-engineering (http://www.nova-eng.com/). Thank you in advance, Jean-LucArticle: 22648
Jean-Luc Nagel wrote: > > Hello, > > I'm looking for a FPGA prototyping board with a PCI > interface, but also with a PC104+ interface (i.e. PCI PC104) Did you have a look at: http://www.optimagic.com/boards.html -- Patrick Schulz (schulz@rumms.uni-mannheim.de, pschulz@ieee.org) University of Mannheim - Dep. of Computer Architecture 68161 Mannheim - GERMANY / http://mufasa.informatik.uni-mannheim.de Phone: +49-621-181-2720 Fax: +49-621-181-2713Article: 22649
Tom,
Here's another idea, if you've locked the output clocks and they're
impossible to route with low enough skew, but it will take two global clocks
and two BUFGPs and two DLLs.
Take your reference clock and feed it to the first DLL's input. This DLL
drives a global clock through a BUFGP, so the BUFGP output must feed back to
the DLL. Use this clock for only one thing: driving the 4 (or more, possibly
many more) output clocks. You'll need a special circuit to make sure the
output clocks are all closely phased. I use two flops, one clocked on the
positive edge, one clocked on the negative edge, arranged as a 2-bit gray
counter (D1 <= !Q0, D0 <= Q1), and take Q0 ^ Q1 (actually, I used Q0 XNOR
Q1) out to the IOB O pin directly. You'll need one instance of this clock
circuit for every output pin, but if you place the flops and the XOR LUT
into a single CLB (two slices, since you're using two different clock edges)
right next to the output pin and make sure routing from the flops to the LUT
to the IOB O pin is controlled (via constraints or manual routing) you
should be able to get better than +-500ps skew among all the output clocks.
As I said, you can have many more than 4 of them, and they can be
distributed across the chip. The second DLL is used as your primary internal
clock. Take one of your clock outputs, route it back to the second DLL, use
a BUFGP with it. That's your clock for all internal logic. Again, since
you're using a BUFGP with the DLL you'll need to feed back this second
BUFGP's output to this second DLL. This clock will be phased to the output
clocks, so you can use it to drive data out and bring it back in. You will
add two DLL's worth of jitter to this clock, though.
One other thing: you'll probably want to make sure the first DLL has 50%
duty cycle compensation turned on.
Good luck,
Marc
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