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
It turned out that virtex2 library was not necessary for the "post PAR" simulation. It was a mess with different warnings, different logical errors, library settings. After I fixed a logical error in my "pcore" and I mapped the "unisim, xilinxcorelib, xilinxcorelib_ver" in "modelsim.ini", I see signal toggling that I expected. Many thanks to Duane Clark, Colin Paul Gloster, beeraka.Article: 126176
Toni Merwec wrote: > Has anyone ever had a similar problem and knows about an adequate solut= ion?=20 I don't know if this meets the jitter precision you need, but we're using the following setup for 66MHz fpga-fpga communication here: First FPGA gets an external clock, synchronizes its internal clock to this via DCM. Second DCM in first FPGA outputs the clock to a pin, pin is fed back to another pin that is fed back into DCM-> clock on pin is synchronous to internal clock. Second FPGA gets clock from first FPGA, synchronizes its internal clock to this via DCM. HTH, - Philip --=20 Weisheit wird mit L=F6ffeln gefressen. Manche Leute benutzen eine Gabel...Article: 126177
> Also, how is the ispLever design software from Lattice? It's not the slickest tool in the market, but it does the job. > So, I'm thinking something must be wrong? Nope, they're just trying to win business. Cheers, JonArticle: 126178
> You probably forgot to set C_TEMAC_INST in the second PLB temac (in > addition to C_TEMAC_BOTH_USED). > > I hear there is tcl code to catch this in Xilinx's code, but it's commented > out... Ben, You may be on to something. In EDK, the C_TEMAC_INST parameter is shown as "Auto Computed" in the "Configure IP" dialog box. However, looking at my libgen.log file i see the following message: C:\EDK9.1\hw\XilinxProcessorIPLib\pcores\plb_temac_v3_00_a\data \plb_temac_v2_ 1_0.mpd line 56 - plb_temac_1 (plb_temac) tcl is overriding PARAMETER C_TEMAC_INST value to 0 I also see the same message in the platgen.log and system.log files. I guess the question now is, how can i override this value manually and prevent the tools from doing this? Oh, I double checked, and C_TEMAC_BOTH_USED is checked in both instances of plb_temac cores, so that parameter looks correct. Thanks for the help, Ben. I think I may be on th right track now.Article: 126179
On Thu, 15 Nov 2007 09:48:22 -0500, Ray Andraka <ray@andraka.com> wrote: >Brian Drummond wrote: > >> Is there any technology-independent way out of the Viewlogic/Dos >> software? Such as a fairly generic EDIF netlist? > >Yes, Viewlogic can output an edif netlist, at least it did some 10 years >ago when I last used it. That's part of the answer. But is the information in that netlist comprehensible by the Xilinx tools? It may be generic, while ISE may require Xilinx-specific information. This would require some experimentation by the OP, if he is considering newer FPGA platforms. - BrianArticle: 126180
On Thu, 15 Nov 2007 14:47:02 +0000, Andrew Ganger <Andrew.G@yahoo.co.uk> wrote: > >> Register file should be no problem, inplemented in the FPGA fabric; >> though it could be fairly large (assuming your description is >> synthesisable). I suspect Nathan was talking about multi-port larger >> blocks of memory. > >Thanks for your comment Brian. I will try and see what the tool tells me >when trying to synthesise it. Is there an upper limit for read and write >ports for such kind of register files? Or is this just the case for >memories? There's no upper limit per se; but essentially you are building something like a crossbar with internal storage; so the complexity increases approximately as the square of the number of ports. It also slows down, to become the critical path above a certain point. Then you can consider replicating parts of the register file to tackle this problem (IIRC, look at some of the later DEC Alpha CPUs for a case study) adding further complexity for relatively little benefit. But if you need that nanosecond, you'll pay for it... - BrianArticle: 126181
On Thu, 15 Nov 2007 15:44:49 +0000, Andrew Ganger <Andrew.G@yahoo.co.uk> wrote: > >> Hi, as others have pointed out you can create a register file with >> one write port and several read ports quite efficient. Could you constrain >> your instruction set so that the instruction that need to write to two >> registers is limited to a register pair of even and odd registers? >> >> As in: (R1,R0) = R2*R3 ; Ok R1 odd, R0 even >> And: (R2,R0) = R4*R5 ; Not OK, Both R2 and R0 are even >> >> In that case you can implement your register file as two memories with >> one write port. > >Sorry, I dont understand that. You suggest also to use 2 RAM block with >each two read ports. They both should contain the same register values, >so in other words, each RAM block requires 2 write ports so that I can >keep the values in both registers consistent! The problem comes when you need two fully independent write ports. Remember that each BlockRam only gives you two independent ports; if you need one write port, that only leaves one read port. You can easily increase read ports by paralleling BlockRams, tying their Write ports in parallel. This forms a 1-Write,N-Read register file. But two independent Write ports is more difficult; if both Write ports shared the same BlockRam, you would have no ports left over for Read! What Andreas is suggesting (I think) is to divide your "register" space into two subspaces - even numbered registers, and odd regs. Each space uses the 1-W, N-R structure above. This is very simple and it works; IF you can restrict the Writes to one even, one odd, in any clock cycle. Which is relatively easy if the double-writes are e.g. from a multiplier or a complex math unit or some such; you simply adopt a convention like Re=even, Im=odd, and your assembler or compiler back end enforces that restriction. You need no such restriction on read ports. For this restriction you get a very simple and extremely large register file in BlockRam. This gives you options like switching entire register sets on an interrupt or process switch, by flicking an otherwise unused BlockRam address bit. - BrianArticle: 126182
Colin, If you email me directly what size ECP2M part you are considering, and if you work with a distributor or FAE (who is your contact for Xilinx), I will have someone get back to you. AustinArticle: 126183
"cpope" <cepope@nc.rr.com> wrote in message news:473cdc7a$0$2339$4c368faf@roadrunner.com... >Are there TI c54x or > c3x soft cores out there that could be compiled into a xilinx fpga? > You are kidding aren't you! For many years TI have been paranoid about application specific FPGA-based designs stealing market share from their DSPs. You only have to mention the word "FPGA" to a TI DSP sales or marketing person to get their blood boiling.Article: 126184
On Fri, 2007-11-16 at 01:43 -0800, Antti wrote: > On 14 Nov., 18:34, Jan Pech <n...@spam.please> wrote: > > Hello all, > > > > I would like to use the USR_ACCESS_VIRTEX4 primitive to access an > > additional bitstream stored in a config flash. The situation is > > following: > > * I have a master FPGA (Virtex-4FX) and a slave FPGA (Spartan-3A). The > > slave FPGA is located on an additional board and it is NOT daisy-chained > > with the master one. > > * Master FPGA gets configured out of platform flash in master serial > > mode. > > * I need to configure even the slave FPGA. The only non-volatile source > > of its configuration data is the platform flash connected to the master > > FPGA. > > > > I used STARTUP_VIRTEX4 primitive to take control over the CCLK and DONE > > signals. While generating bitstream I used the "-g DONE_cycle:KEEP" > > option. From my measurements of the interface between flash and > > Virtex-4, this part of the design works fine. I fully control the > > signals, DONE does not go high anywhere in the middle, and flash sends > > me additional bitstream data. > > > > To access additional bitstream I instantiated the USR_ACCESS_VIRTEX4 > > primitive, but here is the problem. Even though I see the data on the > > DIN input of the Virtex-4, the DATAVALID output of the > > USR_ACCESS_VIRTEX4 primitive never goes high. So that I am unable to > > reach this data inside the Virtex-4 FPGA. > > > > The Virtex-4 Libraries Guide for HDL Design says: The PROM should > > contain a packet of data with the USR_ACCESS register as the target. I > > generated my PROM file using iMPACT simply putting two bitstreams into > > single MCS file what is probably wrong. I think my MCS should contain > > normal master FPGA bitstream followed by the slave FPGA bitsream with > > target set to USR_ACCESS. Is there any way how to set target for the > > second bitsream in MCS to USR_ACCESS so that I could access it from my > > master FPGA? > > > > If I am trying to do something impossible, is there another approach how > > read slave configuration data from platform flash using master FPGA? I > > cannot do it simply controlling flash pins, as they are not connected to > > IO pins of the FPGA but to dedicated configuration pins only. > > > > Thanks for advices, > > Jan > > no no no :) > > what you want is doable ok, but not with the tools provided by xilinx > > . > > you need > 1) your own bit file merge tool that converts and inserts specially > formatted bitstream into master bitstream > 2) your own USR_ACCESS_TO_SERCONFIG gateway IP-core that you compile > into the master FPGA > > please look at ultracontroller reference designs, xilinx uses this > (very similar method) to load the PPC memories > they add the info into master bitstream and use usr_access connected > JTAG master ip core > > Antti Thank you Antti, Meanwhile I solved it myself but I have forgotten to post my solution here. I simply converted my "slave FPGA" bitstream to raw binary file and merged it together with the "master FPGA" bitstream using Perl script genmcs.pl from xapp719 modified according to my needs. Converting the data itself to slave-serial configuration stream is matter of single shift register but I spent some time with oscilloscope to get correct bit order. Additionally, the first word I get from the USR_ACCESS register does not belong to my "slave" configuration data so I skip it always. JanArticle: 126185
hi ich have a problem with a project in ise and modelsim. i used the core generator to create a single port block memory and instantiated it in my design. now i want to do a behavioral simulation to verify my design. i followed the instructions from the core generator help file. ( i used the *.vho file to instantiate the block memory in my design and downloaded the latest libraries from xilinx for model sim). but whatever i do to the ports of the memory they always stay 'x'. shouldn't at least the input port be '0' or '1' if i apply that signal? here is the way i instantiated it: library IEEE; use IEEE.STD_LOGIC_1164.ALL; --use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; use IEEE.NUMERIC_STD.all; use work.spi_package.all; entity spi_memory is PORT ( CLK : in STD_LOGIC; Data_in : inout STD_LOGIC_VECTOR (31 downto 0); Data_out : inout STD_LOGIC_VECTOR (31 downto 0); Address : in STD_LOGIC_VECTOR (9 downto 0); WR : in STD_LOGIC; RD : in STD_LOGIC); end spi_memory; architecture Behavioral of spi_memory is component spi_mem port ( clka : IN std_logic; dina : IN std_logic_VECTOR(31 downto 0); addra : IN std_logic_VECTOR(9 downto 0); wea : IN std_logic_VECTOR(0 downto 0); douta : OUT std_logic_VECTOR(31 downto 0)); end component; -- Synplicity black box declaration -- attribute syn_black_box : boolean; -- attribute syn_black_box of spi_mem: component is true; signal s_write_strobe : std_logic; begin I_spi_mem: spi_mem port map ( clka => CLK, dina => Data_in, addra => Address, wea => vectorize(s_write_strobe), douta => Data_out); GENERATE_WRITE_STROBE: process(WR, RD, Address) begin s_write_strobe <= '0'; if RD = '0' and WR = '1' and Address >= "0000001010" then s_write_strobe <= '1'; end if; end process GENERATE_WRITE_STROBE; end Behavioral; could somebody please give me a hint here? i also compiled the wrapper file in model sim. do i have to instantiate it somwhere/how? (couldn't find that in the manual) the other thing is i get a warning in model sim: # ** Note: Block Memory Generator CORE Generator module is using a behavioral model for simulation which will not precisely model memory collision behavior. # Time: 1140 ns Iteration: 1 Instance: /spi_interface_tb_vhd/uut/ i_spi_memory/i_spi_mem/u0 thanks urbanArticle: 126186
"David Spencer" <davidmspencer@verizon.net> wrote in message news:i7j%i.187$xt5.59@trnddc07... > > "cpope" <cepope@nc.rr.com> wrote in message > news:473cdc7a$0$2339$4c368faf@roadrunner.com... > >Are there TI c54x or > > c3x soft cores out there that could be compiled into a xilinx fpga? > > > > You are kidding aren't you! For many years TI have been paranoid about > application specific FPGA-based designs stealing market share from their > DSPs. You only have to mention the word "FPGA" to a TI DSP sales or > marketing person to get their blood boiling. > > Well from TI's perspective seems to me like a chance to make money off of IP they already have. There is a lot of code out there that for c3x or c4x and so on that could drop right in to a system like mine. Compared to the NRE to rewrite an existing app they can charge a fair amount for a core license. Right now they're probably making nothing off of these old cores. But it doesn't have to be TI. Motorola or analog devices could do the same. -ClarkArticle: 126187
Uzytkownik "Peter Alfke" <peter@xilinx.com> napisal w wiadomosci news:98e59f3d-9f33-4f06-a658-b8aedb88d3a9@e10g2000prf.googlegroups.com... > On Nov 15, 3:14 am, "zlotawy" <paraliczb@NO_SPAM_orange.pl> wrote: >> Uzytkownik "Peter Alfke" <pe...@xilinx.com> napisal w >> wiadomoscinews:1195079702.949034.33320@e9g2000prf.googlegroups.com... >> >> >A large asynchronous FIFO will always most efficiently be implemented >> > in a dual-ported BlockRAM, and have a width of 1, 2, 4, 9, 18, or 36 >> > bits. If you need a different width, just pad it to the higher value. >> > Also Din and Dout have the same width. >> > Anything different will get very complicated... >> > The main problem in the design of asynchronous (2-clock) FIFOs is the >> > reliable generation of the Full and Empty flags at high clock rates. >> >> hmmm... which clock sets flags? >> >> And what if two clocks are the same? Then should I change type of fifo >> (one >> clock)? >> >> zlotawy > > If both clocks are the same, the design becomes a trivial synchronous > state machine. Only fast asynchronous FIFO controllers are tricky and > somewhat controversial, due to the metastable risk and its avoidance. > Peter Alfke and what about FIFO with 200MHz clock? Device is Virtex 2P. Is it too fast? zlotawyArticle: 126188
On 2007-11-16, JimboD2@gmail.com <JimboD2@gmail.com> wrote: > >> You probably forgot to set C_TEMAC_INST in the second PLB temac (in >> addition to C_TEMAC_BOTH_USED). > > I guess the question now is, how can i override this value manually > and prevent the tools from doing this? Edit the MHS file in a text editor. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 126189
u_stadler@yahoo.de wrote:
> hi
>
> ich have a problem with a project in ise and modelsim. i used the core
> generator to create a single port block memory and instantiated it in
> my design. now i want to do a behavioral simulation to verify my
> design. i followed the instructions from the core generator help file.
> ( i used the *.vho file to instantiate the block memory in my design
> and downloaded the latest libraries from xilinx for model sim).
Hopefully it won't be too annoying if I avoid actually answering your
question, and instead suggest that you not use core generator to
instantiate simple memories. You really should infer them. For example,
yours might look something like:
type mem_array is array(0 to 511) of std_logic_vector(31 downto 0);
signal ram : mem_array;
-- infer block RAM
wr_p: process(CLK)
begin
if rising_edge(CLK) then
if s_write_Strobe = '1' then
ram(to_integer(Address)) <= Data_in;
end if;
end if;
end process wr_p;
rd_p: process(CLK)
begin
if rising_edge(CLK) then
rd_addr_ram <= Address;
end if;
end process rd_p;
Data_Out <= ram(to_integer(rd_addr_ram));
Notice that it is important to register the read address. This is
required to infer block ram. If you don't do that, you will get LUT ram.
Article: 126190On Nov 16, 11:15 am, "Toni Merwec" <mistertorp...@freenet.de> wrote: > Hi there, > > I am currently designing an FPGA board, featuring two Xilinx Virtex-4 FPGAs. > I've already posted another question concerning a correct JTAG chain > implementation a few days ago and gained pretty good response. But some > problems remain... although on another topic: > > I'll be using the Xilinx Virtex-4 FX series FPGAs featuring the high-speed > MGTs. The MGTs are located in two rows on each FPGA, each requiring their > own MGT reference clock, i.e. four reference clock inputs have to be fed > altogether plus at least one additional clock input for the core logic per > FPGA. Because the FPGAs have to exchange data synchronously (via the > standard GPIOs) I thought about using the same reference clocks for both > FPGA and making them the same as the MGT reference. Unfortunately that leads > to a clock signal that has to be distributed to at least 6 FPGA clock > inputs. > > I don't think that a regular low-jitter clock device (and it HAS to be > low-jitter as for the reference for the MGTs) can drive 6 inputs over > several centimeters. I already used the ICS843020 clock synthesizer in > several other projects and wanted to use it again. Reason for the ICS is > that it features a programmable output frequency in the range of 35 - 700 > MHz. Problem is, the ICS843020 has only two outputs. The Epson EG2121CA > device that is proposed in the Virtex-4 MGT user guide is not suitable > because these devices are restricted to one fixed frequency. > > Maybe a clock buffer or multi-output clock distribution device is the > solution here, but I am afraid every additional device in the clock network > would introduce additional jitter which is the most critical aspect in this > application. Therefore I woul prefer a solution without those kind of > devices... if possible. http://www.onsemi.com/pub/Collateral/MC100EP210S-D.PDF ON semiconductor list some 272 clock buffers - this is one of them. -- Bill Sloman, NijmegenArticle: 126191
David Spencer wrote: > "cpope" <cepope@nc.rr.com> wrote in message > news:473cdc7a$0$2339$4c368faf@roadrunner.com... >> Are there TI c54x or >> c3x soft cores out there that could be compiled into a xilinx fpga? >> > > You are kidding aren't you! For many years TI have been paranoid about > application specific FPGA-based designs stealing market share from their > DSPs. You only have to mention the word "FPGA" to a TI DSP sales or > marketing person to get their blood boiling. > > Actually, a start has been done at opencores: http://www.opencores.org/projects.cgi/web/oc54x/overviewArticle: 126192
Just look at its syntax. It is so archaic that anyone who had any deal with Python will just laugh. Try, say, to create a simple VGA controller, which is simply readable. VHDL's Ada syntax is also very error prone. Instead of having all this archaic constructions and surplus operators, it would be much more productive just to start thinking about to create another hi-level HDL that has absolutely another conceptual design and simple syntax. Any good language should be so simple as possible and any program in this language should be short and clear. Such language should support associative arrays, that should help designing large FSMs; should support simple mechanism of type conversions and so on... Conceptually VHDL is not bad at all, it supports a lot of things, well in theory. But in praxis ... And don't forget about future FPGAs, about future SoCs, which will have integrated MEMS arrays, and other stuff. Try to understand how much complexer they are to be designed in so unproductive way using so primitive languages.Article: 126193
On Nov 16, 1:27 pm, "psihode...@googlemail.com" <psihode...@googlemail.com> wrote: > Just look at its syntax. It is so archaic that anyone who had any deal > with Python will just laugh. Try, say, to create a simple VGA > controller, which is simply readable. > > VHDL's Ada syntax is also very error prone. Instead of having all this > archaic constructions and surplus operators, it would be much more > productive just to start thinking about to create another hi-level HDL > that has absolutely another conceptual design and simple syntax. > > Any good language should be so simple as possible and any program in > this language should be short and clear. Such language should support > associative arrays, that should help designing large FSMs; should > support simple mechanism of type conversions and so on... > > Conceptually VHDL is not bad at all, it supports a lot of things, well > in theory. But in praxis ... > > And don't forget about future FPGAs, about future SoCs, which will > have integrated MEMS arrays, and other stuff. Try to understand how > much complexer they are to be designed in so unproductive way using so > primitive languages. So I guess you'll be designing all your stuff in another language and dropping out of this newsgroup... KJArticle: 126194
zlotawy wrote: >>If both clocks are the same, the design becomes a trivial synchronous >>state machine. Only fast asynchronous FIFO controllers are tricky and >>somewhat controversial, due to the metastable risk and its avoidance. >>Peter Alfke > > > and what about FIFO with 200MHz clock? Device is Virtex 2P. Is it too fast? > > zlotawy > > A virtex 2P is quite capable of a 200 MHz synchronous FIFO. YOu'll have to be somewhat careful in the design, particularly in limiting the levels of logic between successive flip-flops,and you may have to do some floorplanning, but it is quite possible.Article: 126195
Andy wrote: > > I'm old enough have done a lot of ABEL/CUPL for PALs, and schematic > capture for xc2000/xc3000 designs, and I hated VHDL for a long time. > My old boss hung up a quote of mine about trying to design SW by > drawing pictures, while HW design was hell-bent-for-leather, headed > the other way. Previous poster notwithstanding, I used GED (precursor > to Concept) to build wonderful, intelligently parameterizable > functional blocks that could be interconnected in an easily > understood, structual way. Unless I needed to design a state > machine... That's when I started to design behaviorally, instead of > structurally. Now, design structure is mostly about managing > behavioral complexity, and a only little about managing physical > complexity. Once you make that thought shift, it's gravy from there > on. > Andy, before I abandoned schematics, I had come up with a very workable graphical state machine entry for schematics. The schematic looked just like a state diagram. Basically, I made schematic wrappers that looked like state diagram elements so that putting together the state machine was much like drawing it out. Of course it resulted in a decoded state machine, but that was OK since that was the style that generally yielded the best results in FPGAs of the time anyway. The components were: a state bubble containing a flip-flop; a decision box, which contained a pair of AND gates with the decision input inverted into on and not into the other; and a wire junction, which wrapped around an OR gate. I think there were a few other elements, but these were the major ones. It made for very fast entry, and very readable state machine schematics. I also had a methodology for encoded state machines that made it easy to read the function. I don't recall off the top of my head what I did there, but it basically involved a mux element with all the states shown.Article: 126196
Brian Drummond wrote: > On Thu, 15 Nov 2007 09:48:22 -0500, Ray Andraka <ray@andraka.com> wrote: > > >>Brian Drummond wrote: >> >> >>>Is there any technology-independent way out of the Viewlogic/Dos >>>software? Such as a fairly generic EDIF netlist? >> >>Yes, Viewlogic can output an edif netlist, at least it did some 10 years >>ago when I last used it. > > > That's part of the answer. > > But is the information in that netlist comprehensible by the Xilinx > tools? It may be generic, while ISE may require Xilinx-specific > information. This would require some experimentation by the OP, if he is > considering newer FPGA platforms. > > - Brian It was back then. You could add attributes such as RLOCs, TNMs, and HU_SETs to the symbols and they would get passed through to the netlist correctly. My standard flow back then was Viewlogic to edif netlist, and then netlist into the Xilinx tools. I think the Xilinx tools may have become more picky about what goes in since then, in that I'm not sure the translate will convert generic gates to LUTs any more like it used to. The synthesis tools all pretty much do all the conversion to LUTs and other Xilinx primitives now.Article: 126197
I agree with Ray (as always). What is the data width and addressing depth of your synchronous FIFO? Peter Alfke, Xilinx On Nov 16, 10:58 am, Ray Andraka <r...@andraka.com> wrote: > zlotawy wrote: > >>If both clocks are the same, the design becomes a trivial synchronous > >>state machine. Only fast asynchronous FIFO controllers are tricky and > >>somewhat controversial, due to the metastable risk and its avoidance. > >>Peter Alfke > > > and what about FIFO with 200MHz clock? Device is Virtex 2P. Is it too fast? > > > zlotawy > > A virtex 2P is quite capable of a 200 MHz synchronous FIFO. YOu'll have > to be somewhat careful in the design, particularly in limiting the > levels of logic between successive flip-flops,and you may have to do > some floorplanning, but it is quite possible.Article: 126198
On Nov 16, 1:27 pm, "psihode...@googlemail.com" <psihode...@googlemail.com> wrote: > VHDL's Ada syntax is also very error prone. Instead of having all this > archaic constructions and surplus operators, it would be much more > productive just to start thinking about to create another hi-level HDL > that has absolutely another conceptual design and simple syntax. Ever heard of verilog ? It's a bit more like c - you can write very concise code, or you can make a real mess...Article: 126199
"Toni Merwec" <mistertorpedo@freenet.de> wrote in message news:473d6db5$0$13113$9b4e6d93@newsspool2.arcor-online.net... > > I'll be using the Xilinx Virtex-4 FX series FPGAs featuring the high-speed > MGTs. Unfortunately that leads to a clock signal that has to be > distributed to at least 6 FPGA clock inputs. > > I don't think that a regular low-jitter clock device (and it HAS to be > low-jitter as for the reference for the MGTs) can drive 6 inputs over > several centimeters. I already used the ICS843020 clock synthesizer in > several other projects and wanted to use it again. Reason for the ICS is > that it features a programmable output frequency in the range of 35 - 700 > MHz. > Maybe a clock buffer or multi-output clock distribution device is the > solution here, but I am afraid every additional device in the clock > network would introduce additional jitter which is the most critical > aspect in this application. Therefore I woul prefer a solution without > those kind of devices... if possible. > Hi Toni, A proper clock distribution device will introduce very little jitter. Use some thing like this:- http://www.micrel.com/_PDF/HBW/sy89832u.pdf Filter its supplies properly. HTH., Syms.
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