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
yy wrote: > Hi, > I am to build a fpga system that captures data from external signals > and store it to DDR, also after the capture data must be transferred to > the PC via PCI bus via DMA or so. > So this is a CAPTURE-to-DDR DDR-to-PCI... How is this sytem > implemented? You've already stated the requirements (albeit in a vague way). Tighten up the definition and any decent designer would be able to come up with an implementation. If you are to build it, you'll learn nothing if you don't try to figure out the implementation [truly a core skill in design!] yourself. Cheers PeteSArticle: 106001
maxascent schrieb: > Thanks for your replies. It turns out that I needed to first program with > impact and then start chipscope. Seems a bit stupid to have to do this but > at least it works > > Jon there is one difference with chipscope namly it does not auto-fix the startup clock as impact does, so you need to generate the .bit file with startupclock jtagclock, but I guess you had that right. well the chipscope and impact use a little different jtag algorithm, meaning sometimes both work, sometimes only one, I have also seen situations where impact cant be used but chipscope succeeds to program the fpga! so as usual, if one doesnt work then try the other :) AnttiArticle: 106002
Ayon kay PeteS: > yy wrote: > > Hi, > > I am to build a fpga system that captures data from external signals > > and store it to DDR, also after the capture data must be transferred to > > the PC via PCI bus via DMA or so. > > So this is a CAPTURE-to-DDR DDR-to-PCI... How is this sytem > > implemented? > > You've already stated the requirements (albeit in a vague way). Tighten > up the definition and any decent designer would be able to come up with > an implementation. If you are to build it, you'll learn nothing if you > don't try to figure out the implementation [truly a core skill in > design!] yourself. > > Cheers > > PeteS Hi PeteS, I will elaborate so that my concept will be clear. First of all the idea is for the PCI to read/write data from multiple DDR (with DDR controller interface). With the PCI Master core connected to a DMA Engine and FIFO buffer that is connected to the 'DDR SDRAM Controller Interface' that is connected to the DDR Module itself, and if possible be connected to other DDR Controller Interface, can that be possible? such that when I access BAR1, for example i'm accessing DDR1 Interface, BAR2 for DDR2 Interface etc., along with this a Custom logic1 that use DDR1as its data must be able to access the same 'DDR Controller Interface1' , Custom Logic2 that use DDR2 as its data must be able to access the same DDR Controller Interface2, etc. In short is it possible to have seperate port for a DDR Controller Interface connected to a single DDR module to have dual access 'port', one for the PCI-DMA Engine and one for the Custom Logic(but not both at the same time)? Regards, yyArticle: 106003
I would copy all .edf, .edn, .mif, .hex, .ucf, .ncf (did I forget one?) into a new directory and run ISE on it. ISE will search the directory where the .edf is located for any other interesting files. maxascent wrote: > I have took a Xilinx design through synplify and then started ise from > synplify to place and route. The problem is I have some coregen components > and when I try and place and route it complains about missing edif files. I > can find these files in the synplify directory but how do I tell ise about > them? > > Cheers > > JonArticle: 106004
I did a few quick searches on this topic, only to find that there aren't many good solutions for this. I have written my own version of the Arclite (previously Vautomation v8 uRISC) 8-bit CPU in VHDL, with a few new instructions thrown in. The processor runs fine in ModelSim, and I've executed some reasonably complex programs using a non-synthesizable ROM model. (I essentially run through a for loop during reset, and stuff values in one by one using a large case structure - it stinks, but it works well enough for testing) I've also managed to modify an open-source assembler and linker (WLA) to produce code for the beast. So, I'm now at the point where I would like to actually build a ROM, and start testing the processor core on actual hardware - and that's where it seems to break down. My assembler and linker produce an executable binary image. I would like to create a ROM model that contains that exact image (dead space and all), and I don't mind writing a tool to do it, but I'm not clear on the best way to proceed. Both the MIF and HEX formats would require a great deal of massaging - though a script could probably handle conversion to the .hex format. I would like to support both Altera and Xilinx tool flows, so I want to stay as vendor-neutral as possible. Is there an easy way to take my binary executable, and stuff it into a VHDL model for synthesis? Right now, I'm thinking about just writing a small bootloader ROM that will download code via a serial link to memory, but even that would be large enough that I would like to find a way to automate it.Article: 106005
Hi, on the www.fpgaarcade.com site there is a program called romgen (with source). The latest version is in the Space Invaders game. This will take a binary file and output VDHL source for either xilinx block rams or vendor neutral case statements or arrays. Cheers, MikeJ "radarman" <jshamlet@gmail.com> wrote in message news:1154716782.089926.55250@p79g2000cwp.googlegroups.com... >I did a few quick searches on this topic, only to find that there > aren't many good solutions for this. > > I have written my own version of the Arclite (previously Vautomation v8 > uRISC) 8-bit CPU in VHDL, with a few new instructions thrown in. The > processor runs fine in ModelSim, and I've executed some reasonably > complex programs using a non-synthesizable ROM model. (I essentially > run through a for loop during reset, and stuff values in one by one > using a large case structure - it stinks, but it works well enough for > testing) > > I've also managed to modify an open-source assembler and linker (WLA) > to produce code for the beast. So, I'm now at the point where I would > like to actually build a ROM, and start testing the processor core on > actual hardware - and that's where it seems to break down. > > My assembler and linker produce an executable binary image. I would > like to create a ROM model that contains that exact image (dead space > and all), and I don't mind writing a tool to do it, but I'm not clear > on the best way to proceed. Both the MIF and HEX formats would require > a great deal of massaging - though a script could probably handle > conversion to the .hex format. > > I would like to support both Altera and Xilinx tool flows, so I want to > stay as vendor-neutral as possible. > > Is there an easy way to take my binary executable, and stuff it into a > VHDL model for synthesis? > > Right now, I'm thinking about just writing a small bootloader ROM that > will download code via a serial link to memory, but even that would be > large enough that I would like to find a way to automate it. >Article: 106006
maxascent wrote: > Thanks for your replies. It turns out that I needed to first program with > impact and then start chipscope. Seems a bit stupid to have to do this but > at least it works Yeah, indeed. I've found it easiest to use the Core Inserter, rather than instantiating all of the ChipScope stuff in the VHDL (makes it easier to change what you wish to monitor, too). After the Core Inserter does its thing, I re-implement, create a new PROM file and re-program the EEPROM with Impact, then re-configure the device. Then ChipScope finds the core, no problem. I know this all shouldn't be necessary, but that's the only way I get it to work. -aArticle: 106007
Hi Subroto,
>
> The 210MHz is correct for Cyclone II M4K in SDP (simple dual port) mode
> with dual, non-PLL clocks.
> The speed for Cyclone II M4K in SDP mode with a single, non-PLL clock
> is 235Mhz.
Ok, thanks for the hint/correction. One should not try to
figure out performance numbers in the wrong context - no one
will drive a system with 200+ MHz without using the PLL.
With the PLL (and now Quartus 6.0sp1) the numbers
are (independent of single or dual clock):
Cyclone I: fmax = 256 MHz
Cyclone II: fmax = 235 MHz
Martin
BTW: It's very nice that Quartus instantiates the
simple dual port memory from plain VHDL - no vendor
specific components ;-)
For those who are interested here is the (very simple)
VHDL code:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity sdpram is
generic (width : integer := 32; addr_width : integer := 7);
port (
wrclk : in std_logic;
data : in std_logic_vector(width-1 downto 0);
wraddress : in std_logic_vector(addr_width-1 downto 0);
wren : in std_logic;
rdclk : in std_logic;
rdaddress : in std_logic_vector(addr_width-1 downto 0);
dout : out std_logic_vector(width-1 downto 0)
);
end sdpram ;
architecture rtl of sdpram is
signal reg_dout : std_logic_vector(width-1 downto 0);
subtype word is std_logic_vector(width-1 downto 0);
constant nwords : integer := 2 ** addr_width;
type ram_type is array(0 to nwords-1) of word;
signal ram : ram_type;
begin
process (wrclk)
begin
if rising_edge(wrclk) then
if wren='1' then
ram(to_integer(unsigned(wraddress))) <= data;
end if;
end if;
end process;
process (rdclk)
begin
if rising_edge(rdclk) then
reg_dout <= ram(to_integer(unsigned(rdaddress)));
dout <= reg_dout;
end if;
end process;
end rtl;
Article: 106008sorry for not being clear about my question. The ip core I had designed was a mix of verilog and vhdl files as well as ngc files. So I was having problem with the synthesis and the ngdbuild in XPS. Finally I discovered that the mpd file should have the following options to make it work. OPTIONS HDL = MIXED OPTION STYLE =MIX I was assigning STYLE =HDL and was getting errors in the ngdbuild process. Thanks a lot for your responses. Felix Pang wrote: > What did you mean "it doesn't work"? > > I do not see a problem in your options. > > -Felix > Nitesh wrote: > > I have an IP core made up of verilog files as well as vhdl files. How > > do I set my mpd file for the bitstream generation in XPS? > > I tried putting > > OPTION HDL =MIXED > > OPTION STLYE = HDL > > but it doesnt work . > > Anyone done this before. > > Thanks, > > NiteshArticle: 106009
drs39@cornell.edu wrote: > I'm relatively new to FPGA programming and looking for some advice. I have > an application that needs reliable, high bandwidth (+50 MHz), Bandwidth is measured in bits/s or bytes/s. How much are you storing each cycle? > The three > possible ways I have come up with for implementing this part of my project > are: .... > 2. As before I could use the EDK memory controller core as a separate > peripheral on the PLB however this time I could implement my peripheral as > a master on the PLB bus. I believe that this would allow my peripheral to > directly access the SDRAM controller without interference of/with the > processor. However I do not know how difficult it is to write a PLB bus > master and I do not know how to predict how detrimental other traffic on > the PLB bus will be to the available bandwidth for my application. .. To me this is the "obvious" right way to go unless you're really pushing things to the edge (which will require special tricks with DDR). Rest assured, writing a PLB master is way way easier than writing a DDR SDRAM controller (admitted I have no experience with PLB, but otherwise there would be something very wrong with the PLB design!). > As I mentioned I am a relative beginner with FPGA programming and am looking > for advice on how to proceed. I would also greatly appreciate any links to > example projects or documentation that might be relevant to this project. Methinks that this is not likely to be the best way to get started with FPGAs. You may start with a few simpler projects first, followed by a few simple PLB peripherals. Otherwise you'll spend a lot of time in frustration. TommyArticle: 106010
Weng Tianxiang wrote: > > Your method is interesting, but is far from what I am looking for. > > It is too slow. My target is 64-bit inputs on every clock and one must > find its entry within 1-2 clocks and resolve entry conflicts if any at > the same time. > > This design, if succeeded, can be widely used for any dynamic Huffman > encoding. > > I think there is no such hardware design so far in the world and why I > found that almost all Huffman encoding applications are static as in > FAX, electronic books, ZIP files, JPEG, MPEG and so on. Please do not top-post. Your reply belongs after, or intermixed with, the *snipped* material to which you reply. Huffman encoding is rarely used today. Adaptive Huffman is more common. For a complete review see: "The Compression Book" by Mark Nelson and Jean-Loup Gailly, M & T Books, ISBN 1-5581-434-1. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@maineline.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE maineline address!Article: 106011
radarman wrote: > Both the MIF and HEX formats would require > a great deal of massaging - though a script could probably handle > conversion to the .hex format. ROM image download at runtime would be the smoothest way. But with this topic I can't help you. I only want to give you the hint, that for pre-synthesis ROM creation with intel hex files and Altera FPGAs there is a bad pitfall: Altera says, that they accept intel hex, but they accept a variant of intel hex: addresses aligned to memory words (intel hex: always aligned to bytes) and big endian data order (intel hex: little endian). (I found that bug in Altera MaxPlus. I don't know if it is fixed in Quartus.) RalfArticle: 106012
yy a écrit : [...] > With the PCI Master core connected to a DMA Engine and FIFO buffer that > is connected to the 'DDR SDRAM Controller Interface' that is connected > to the DDR Module itself, and if possible be connected to other DDR > Controller Interface, can that be possible? such that when I access > BAR1, for example i'm accessing DDR1 Interface, BAR2 for DDR2 Interface > etc., along with this a Custom logic1 that use DDR1as its data must be > able to access the same 'DDR Controller Interface1' , Custom Logic2 > that use DDR2 as its data must be able to access the same DDR > Controller Interface2, etc. Hi There's really *nothing* fancy here. Imagine a system with a microprocessor (with integrated cache), DDR and a PCI bus... NicolasArticle: 106013
> Hi, > on the www.fpgaarcade.com site there is a program called romgen (with source). The latest version is in the Space Invaders game. > This will take a binary file and output VDHL source for either xilinx block rams or vendor neutral case statements or arrays. > Cheers, > MikeJ That's a nice tool. However, it is not so easy to find - burried too deep in the pacman .zip file. Would it be possible to provide it in it's own .zip file. I can use this kind of tool for a computer architecture lab in the fall and would like to link to it. BTW: perhaps there are some comments and suggestions on this course. It is an open-content Wikiversity course at: http://en.wikibooks.org/wiki/Wikiversity:Computer_Architecture_Lab Cheers, MartinArticle: 106014
Hi I have uploaded the files once available from Pauls website at the university in Australia http://hydraxc.xilant.com/CMS/index.php?option=com_remository&Itemid=41&func=select&id=11 the archive contains all that I fetched from the web when it was available. I do not know exact reasons why the original pages are vanished, but for me the files from there have been a big help to get ppc linux working on Virtex-4 AnttiArticle: 106015
> > That's a nice tool. However, it is not so easy to find - burried > too deep in the pacman .zip file. Would it be possible to provide > it in it's own .zip file. good point, I'll put the latest version on the Library page. /mikeArticle: 106016
CBFalconer wrote: > Weng Tianxiang wrote: > > > > Your method is interesting, but is far from what I am looking for. > > > > It is too slow. My target is 64-bit inputs on every clock and one must > > find its entry within 1-2 clocks and resolve entry conflicts if any at > > the same time. > > > > This design, if succeeded, can be widely used for any dynamic Huffman > > encoding. > > > > I think there is no such hardware design so far in the world and why I > > found that almost all Huffman encoding applications are static as in > > FAX, electronic books, ZIP files, JPEG, MPEG and so on. > > Please do not top-post. Your reply belongs after, or intermixed > with, the *snipped* material to which you reply. > > Huffman encoding is rarely used today. Adaptive Huffman is more > common. For a complete review see: "The Compression Book" by Mark > Nelson and Jean-Loup Gailly, M & T Books, ISBN 1-5581-434-1. > > -- > Chuck F (cbfalconer@yahoo.com) (cbfalconer@maineline.net) > Available for consulting/temporary embedded and systems. > <http://cbfalconer.home.att.net> USE maineline address! Hi Chuck, Thank you for your advice. I have bought the book "The Compression Book". WengArticle: 106017
Hi During loading for post route simulation (modelsim_SE, ISE7.1), following errors occurred. The design block contains "lots of" ports (which is more than 300). So what I did was I implemented after uncheking "Trim unconnected signals" and checking "Create I/O Pads for Ports". In UCF file, I connected clock and reset pins only. It seems that the I/O of design module and test bench are not matching. I checked NCD file using FPGA editor and it is (seems) quite okay. Does anyone have this experience? thankyou again in advance ---------------------------------------------------------------------------------------------------------- # Loading work.pe(structure) # ** Failure: (vsim-3807) Types do not match between component and entity for port rd_data_i # Time: 0 ns Iteration: 0 Instance: /pe_tb/top File: # Loading C:/Modeltech_6.1c/Compxlib/simprim.x_tri_pp(x_tri_pp_v) # Loading C:/Modeltech_6.1c/Compxlib/simprim.x_inv_pp(x_inv_pp_v) # Fatal error at c:/Xilinx/vhdl/src/simprims/simprim_VITAL_mti.vhd line 109182 # while elaborating region: /pe_tb/top/rd_data_0_13_obuf # Load interrupted ---------------------------------------------------------------------------------------------------------Article: 106018
Hi Group I have to implement a design which requires an FPGA, but to do so among other things I obviousely first have to learn one of the two mentioned languages. I got the impression that europe seems to be more vhdl centric whereas verilog seems to be more popular in the US but this argument alone is for reasons beond the scope of this question not so important to me. I have a strong background in C programming (should that matter anyhow) and in general experience with embedded systems, but FPGAs are new to me. I'm otherwise completely open and alas wonder what you guys suggest I should choose. I'm mostly interested in replies from people which know both languages cause otherwise I fear that this thread ends up in some sort of religious war... TIA MarkusArticle: 106019
Markus Zingg wrote: > Hi Group > > I have to implement a design which requires an FPGA, but to do so > among other things I obviousely first have to learn one of the two > mentioned languages. I got the impression that europe seems to be more > vhdl centric whereas verilog seems to be more popular in the US but > this argument alone is for reasons beond the scope of this question > not so important to me. I have a strong background in C programming > (should that matter anyhow) and in general experience with embedded > systems, but FPGAs are new to me. I'm otherwise completely open and > alas wonder what you guys suggest I should choose. I'm mostly > interested in replies from people which know both languages cause > otherwise I fear that this thread ends up in some sort of religious > war... > > TIA > > Markus > Do not fear: It'll end up in a religious war no matter what. FWIW I'm a trained analog circuits & systems guy who usually adds value by architecting systems, designing control and communications algorithms, or implementing said algorithms in C or C++. For years my job title was "software engineer" and the only circuit design I did was at home. When I picked up FPGA design it was using Verilog because the two people I had to lean on for help were Verilog people. I found it very easy and obvious, as long as I remembered that I was writing hardware descriptions, not writing "code". -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 106020
Joseph Samson wrote: > heinerlitz@gmx.de wrote: > > Hi, > > I finally got to run the MIG created DDR2 for VIrtex4 devices > > controller. However I have two problems with the controller: > > > > 1. I am observing the ERROR signal which is created by the dataCompare > > module. It goes high every 8th read pulse. Could this be related to the > > FIFO16 bug? > > I don't have the DDR2 source code with me at home, but I'm pretty sure > that the FIFO16 use was limited to the write data and the > address/command. The write data FIFO has 2 different clocks, but the > FIFO read clock is 90 degrees out of phase with FIFO write clock, so I > think it is not a problem. I had problems with the address/command FIFO. > The FIFO would be empty, but the DDR2 controller thought that the FIFO > had data, so it would repeatedly read the same address. > > Is there a way to fix the fifo in the design? It would be > > easy to fix the fifo issue in my own design but as I havent written the > > ddr controler i have no glue what the requirements of the fifo16 are > > and how the issue should can be fixed in the best way. Inverting the > > readclock (as I read somewhere) didnt work and I do not know if the > > coregenerated fifos are fast enough and if they can be simply exchanged > > (no fall through for example). > > I created a Block RAM FIFO with CoreGen; it was pretty simple;just look > at the MIG verilog or VHDL code. The FIFO16 is instantiated directly and > the parameters are specified in the code. Fall through is supported in > CoreGen. > > > > > > 2. My other problem is of different nature. The simulation environment > > which is supplied by xilinx does not work with some RAMs. I had no > > problem simulating a 8bit Micron DDR2 chip however the 16bit chip I am > > currently using does not work. THe whole testbench verilog files are > > corrupted showing false instantiations (wrong names, wrong bit sizes) > > has anybody experienced the same problems? > > I built a DIMM simulation out of 8-bit parts. Why not just use 2 8-bit > parts instead of a 16-bit? Even if you're trying to simulate with real > PCB delays, 2 parts could work. > > > > > Both problems could be probably solved by disassembing the whole > > design, but that takes hours, so If anybody has already a solution for > > the above problems I would be very happy. > > I'm not happy with the whole calibration procedure that DDR2 MIG has. > The IDELAY part that looks at the data strobes seems to work OK, but > then they write a pattern to memory, read it back and try to figure out > how many clocks to wait after the read command before the data is > available and can be shifted into the read data FIFO. Sometimes (most of > the time) that logic would make the wrong choice and miss some of the > read data. I eventually hard coded the delay and it worked fine after that. Did you hard coded the number of needed clock cycles or the delay in the IDELAY?? Thanks for help! > > --- > Joe Samson > Pixel VelocityArticle: 106021
I'm trying to get an FPGA (Spartan-II) to communicate with an ADC
(Serial interface, with a maximum throughput rate of 2Msps and the
maximum signal bandwith I'm sampling is 200kHz). I've been using a
counter to generate both the SCLK and CS signals and find that the ADC
doesn't seem to be sampling. The SCLK signal on the ADC board looks
distorted when I probe it with the scope and more worrying, I also see
the same distorted SCLK signal on the output data only biased about
ground! SCLK looks something like:
|||
| |
| |
| ||||
| | |
| | |
| | |
| | |
| | |
| ||||
| |
| |
|||
I've just been reading elsewhere on this forum that it is not advisable
to drive the ADC clock inputs with an FPGA. I was wondering if the term
'clock' also refers to the SPI SCLK signal? The recommendations on the
forum say to use an (analog?) PLL to drive the ADC clock and the FPGA
separately. Would a clock distribution IC like AD9513 (I need 2 ADC
clocks and 1 FPGA clock, all CMOS compatible) do the job, or can I use
an EPROM clock generator like CY2071A?
Thanks
Ki
Article: 106022> The SCLK signal on the ADC board looks > distorted when I probe it with the scope What you see is normal undershoot/overshoot, not really much to worry about unless it goes well beyond the spec of the device. However, I am not sure you are doing proper measurement. Whether what you see on the scope is really what's going on depends on the probe, how it is connected, and the scope itself, but I bet your problem is not related to the shape of this signal. > I've just been reading elsewhere on this forum that it is not advisable > to drive the ADC clock inputs with an FPGA. I was wondering if the term > 'clock' also refers to the SPI SCLK signal? No. It only applies to a sampling clock and only if jitter/phase noise of the clock is critical for the application. /MikhailArticle: 106023
Markus Zingg <m.zingg@nct.ch> wrote: >Hi Group > >I have to implement a design which requires an FPGA, but to do so >among other things I obviousely first have to learn one of the two >mentioned languages. I got the impression that europe seems to be more >vhdl centric whereas verilog seems to be more popular in the US but >this argument alone is for reasons beond the scope of this question >not so important to me. I have a strong background in C programming >(should that matter anyhow) and in general experience with embedded >systems, but FPGAs are new to me. I'm otherwise completely open and >alas wonder what you guys suggest I should choose. I'm mostly >interested in replies from people which know both languages cause >otherwise I fear that this thread ends up in some sort of religious >war... I have a feeling VHDL is slightly more used than Verilog. You should pick a language that you feel comfortable with. I never quite got the grasp of Verilog (to me it seems like a description of a circuit diagram instead of a structured language) so I choose to use VHDL. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 106024
I had no problem in driving a typical serial ADC's system clk and control impulses @60Meg and above, which is already very close to the ADCs spec! A common problem is, to generate an approp riate clock with a valid duty cycle. Here a PLL can be used to obtain a freq which ist no directly synthesizeable from the FPGAs system clock (just like 100Megs from out of 60Meg internal or 20Meg external). But typically, you will run a ADC with half of the system freq, in order to be able to do processing and decisions within one bit clock, and toggle the required signal outputs for any of the peripheric devices easily.(e.g. Bit0 of a counter, running at clock speed) A special case is running the data aquisition fully pipelined, where ADC's clock is equal to the fpga clock: With most programmable devices, you will somehow violate the system clock net in simply passing out the freq itself! You will have to use dual data rate cells instead (which also should be placed in the io-blocks for best performance). If you are not familiar with this: The ddr-cell is a switch for two channels controlled by a) the high level and b) as well the low level of the cells's clock. By feeding the ddr cell with static 1 and 0 at its inputs, it is somehow "abused" to switch a 1 at clk hi, and a zero at clk lo. Thus it doubles the frequency to obtain the virtual factor 2 mentioned above (toggeling). With a (pll based) well clk inside the FPGA, you will have a nice and perfectly driven system clk outside too, with a dc of 50:50 (nearly). The next issue is aquiring the ADCs output correctly according to the given delay at the board: Some ADCs pass out their data at the falling edge, and with a tycical delay of 10ns, so you will find the data valid in beneath of the next rising edge of the receiving flip flops. To avoid this, simply generate a doubled system clk and generate a delayed clock for the ddr-cells' clock to delay the ADCs clock. You may also invert 0/1 to push the phase in a way, that the incoming data perfectly meets to aquiring clock.
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