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
Volker wrote: > Hello, > did anyone know how to realize a CMI Coder/Decoder in a FPGA (preferred in > VHDL). Thanks for answers an tipps. > Volker CMI coder is super-easy. Understand the format and you should be able to code it in very few lines. CMI decoder requires a recovered clock that is not integral to the FPGA except, perhaps, for some SERDES blocks. At 140-155 Mb/s, perhaps not. Because of the need for the recovered clock as part of the system design and the extremely simple coding method, I doubt you'll find pre-bundled code out there.Article: 113476
Jim Granville wrote: > rponsard@gmail.com wrote: > > I don't need your IP secrecies... > > > > This is for my students : what, in your current design, requires using > > a fpga + softcore, in place of a COTS micro controler ? > > less IC -> lower footprint, lower power cons., parallelism,... > > There are two levels of softCPU apps : > a) The tiny ones, where the code fits inside the FPGA, in BRAM. > b) The larger ones, that need external code memory. > > For a) the SoftCPU comes almost for free, and can be used to > handle less time-critical tasks, and give a degree of > programmability to all the other FPGA coded peripherals. > Or they may be DSP(s), doing focused tasks. > > Unless you need ADCs / DACs, or similar peripherals, these > do meet the lower footprint consideration. > > For b) once you have to add Code memory, you've lost the 'single chip', > and the interface between the memory/fpga is poor for RFI & pin count. > > Now it's becomes less clear-cut on which is better, and > the choice swings somewhat, as each alternative goes thru > generation cycles, or as code size changes. > If your code CAN fit into an external 32 bit uC, and meet > speed targets, the tight local bus Code-CPU, gives the uC > quite an edge. > Better 32 bit uC now have DMA SSC channels, so FPGA > interfaces can have low pin counts, and they have quite > impressive FLASH resource, so the SoftCPU can struggle > against this growing option. > Leading example: Atmels upcomming AT91SAM9XE512 Flash uC. > > Once your app gets so large (MBytes), that is has outgrown uC Flash, > and it needs SDRAM to run, then it swings more balanced. > SDRAM uC are appearing, but not widely yet (example: AT91SAM9263), > and both choices have PCB traces to SDRAM, so there less of a clear edge. > > Also, show your students this: > http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=HAHXOJ0RM2UHYQSNDLSCKHA?articleID=196603670 > > Details are presently sketchy, but a large dual port memory that was not > niche-priced, would be interesting indeed to FPGA + SoftCPU + uC trade offs. > > -jg Aye, if you require external memory, you do no longer have a single chip solution. However, note that the Spartan 3e can boot from a NOR Flash memory. You can configure from one end of the device, and store your application in the other. I'm not sure if the Virtex 5's support this feature or not, but it is quite handy on the spartan 3e sample pack board.Article: 113477
I have an XPS/ISE project for a Xilinx Virtex II Pro. The XPS design is called PPC_DDR and is instantiated on a top level schematic in ISE (called JTT_DDR). I am unable to get the .bit file to be updated with the code from the XPS application that is marked for BRAM initialization. I cannot get ISE to create an _bd.bmm file with placement information in it. XPS created two files: PPC_DDR.bmm and PPC_DDR_stub.bmm, both in JTT_DDR\PPC_DDR\implementation\. ISE created a file called edkBmmFile.bmm in the JTT_DDR directory. edkBmmFile.bmm and PPC_DDR_stub.bmm are identical. I have tried adding either of these files to the ISE project and get the same result in either case. The error message listed below is reported and a file called XpsTempBmm.bmm is created. The XpsTempBmm.bmm file contains only the line "#include edkBmmFile.bmm" *TWICE*. which seems to be the error and explain the error message below. How am I supposed to get ISE to produced the "placed" version of the bmm file?? Error Message: --------------------------------------- NGDBUILD done. ERROR:Data2MEM:34 - Duplicate ADDRESS_SPACE or ADDRESS_MAP name usage 'plb_bram_if_cntlr_1_bram'. Line #4, File "edkBmmFile.bmm". ADDRESS_BLOCK plb_bram_if_cntlr_1_bram RAMB16 [0xffffc000:0xffffffff] ^ Line #3, File "XpsTempBmm.bmm". FATAL:Data2MEM:43 - Release of unknown memory pointer, 0x04A85520. Source file "../s/D2BUtil_Data2Bram_impl.c", line number 96.Article: 113478
radarman schrieb: > Jim Granville wrote: > > rponsard@gmail.com wrote: > > > I don't need your IP secrecies... > > > > > > This is for my students : what, in your current design, requires using > > > a fpga + softcore, in place of a COTS micro controler ? > > > less IC -> lower footprint, lower power cons., parallelism,... > > > > There are two levels of softCPU apps : > > a) The tiny ones, where the code fits inside the FPGA, in BRAM. > > b) The larger ones, that need external code memory. > > > > For a) the SoftCPU comes almost for free, and can be used to > > handle less time-critical tasks, and give a degree of > > programmability to all the other FPGA coded peripherals. > > Or they may be DSP(s), doing focused tasks. > > > > Unless you need ADCs / DACs, or similar peripherals, these > > do meet the lower footprint consideration. > > > > For b) once you have to add Code memory, you've lost the 'single chip', > > and the interface between the memory/fpga is poor for RFI & pin count. > > > > Now it's becomes less clear-cut on which is better, and > > the choice swings somewhat, as each alternative goes thru > > generation cycles, or as code size changes. > > If your code CAN fit into an external 32 bit uC, and meet > > speed targets, the tight local bus Code-CPU, gives the uC > > quite an edge. > > Better 32 bit uC now have DMA SSC channels, so FPGA > > interfaces can have low pin counts, and they have quite > > impressive FLASH resource, so the SoftCPU can struggle > > against this growing option. > > Leading example: Atmels upcomming AT91SAM9XE512 Flash uC. > > > > Once your app gets so large (MBytes), that is has outgrown uC Flash, > > and it needs SDRAM to run, then it swings more balanced. > > SDRAM uC are appearing, but not widely yet (example: AT91SAM9263), > > and both choices have PCB traces to SDRAM, so there less of a clear edge. > > > > Also, show your students this: > > http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=HAHXOJ0RM2UHYQSNDLSCKHA?articleID=196603670 > > > > Details are presently sketchy, but a large dual port memory that was not > > niche-priced, would be interesting indeed to FPGA + SoftCPU + uC trade offs. > > > > -jg > > Aye, if you require external memory, you do no longer have a single > chip solution. However, note that the Spartan 3e can boot from a NOR > Flash memory. You can configure from one end of the device, and store > your application in the other. I'm not sure if the Virtex 5's support > this feature or not, but it is quite handy on the spartan 3e sample > pack board. xilinx config evolution s3e - NOR config, multi-boot, 2 bit files, can init reconfig from opposite direction v5 NOR config, can select new boot address s3a NOR config, can select new boot address, can change reboot mode, eg start from SPI loc 0, then reboot to some location from NOR flash, then reboot again from different address in SPI, etc. v5,s3a also have watchdog timers AnttiArticle: 113479
Hi Vasanth. Thank you for your answer. I use it both for compiler & Linker. Cheers, Al.Article: 113480
>There is a wrong way and a right way to convert binary to Gray count >values: >The wrong way hangs the (simple!) combinatorial conversion logic (XORs) >on the binary outputs. That does you no good, since the Gray code will >just reflect the binary transient errors. >The right way takes the D inputs of the binary counter (, converts them >independently to Gray and registers them in their own flip-flops. Now >you have two parallel rgisters, both counting in step, the first in >binary, the other in Gray, and there are no funny decoding spikes. >BTW, only Gray counter outputs have the feature that you can compare >two asynchronous counters for identity, without transient errors. >If the Gray code does not come from a counter, it might change multiple >bits per transition... <snip /> Whether that is the right answer rather depends on WHY the OP "has" to use Gray Code, which is still not fully established. BTW, there is a quite interesting article on Gray Code just posted at: http://www.pldesignline.com/showArticle.jhtml?articleID=196604078Article: 113481
>KJ wrote: > >>>I know of no tool that infers FIFOs, async or synchronous. >>> >> >> You must be using very primitive tools. Altera, Xilinx and Synplify (and >> probably most other major players) certainly do. > >As far as I know they don't. That would be quite an accomplishment. I quickly >checked Synplify Premiere 8.6.2 manual and there was nothing about inferring >FIFOs. Also Mentor Precicsion 2006a Synthesis Style Guide did not tell about >fifo inference. And also Xilinx 8.2i xst manual did not have any text about fifo >inferring. Could you point me to the right page in manuals? > >Completely other thing is lpm_fifo and different DW_*fifo* components. But they >must be instantiated directly. Same applies to coregen, altera megafunctions etc. > >--Kim > I agree with Kim. The Altera Quartus tool help shows several ways of instantiating FIFO "macros", but apparently none of inferring one! Inferring counters, shift registers and the like is easy, but I can't imagine how to do so for a FIFO. I've had quite enough difficulty inferring a ROM...Article: 113482
>fl wrote: >> Hi, I still cannot get better performance, even for your code. > >If I assign the same device, I also get your result. >I don't know how the author could do much better. >That's a real old part, by the way. > > -- Mike Treseler > >FLEX10K: EPF10K20RC240-4. 59.52 MHz ( period = 16.800 ns ) >Info: Clock "clk" has Internal fmax of 59.52 MHz between source register >"\only:x_v[0]" and destination register "\only:sum_v[14]" (period= 16.8 ns) > Maybe the version of tools he was using gave a rather optimistic timing estimate, or else he constrained the temperature to something rather cold.Article: 113483
I had a similar kind of error, when I was using a wrong netlist..Basically in my source, I had a component with few ports declared as INOUT, but the netlist just had OUT's. So MAP was failing giving me this error. After I had the correct netlist, I never got this error.. Hope this helps... -- Parag Jiten wrote: > Hi, > I am getting this error while implementing my design with the xilinx > ise tool > > Using target part "2v6000ff1152-4". > Mapping design into LUTs... > ERROR:MapLib:661 - LUT4 symbol > "ins_part0/ins_partition_0/Partition_0_1_Multiclock_event_out127" > (output > signal=fpga0_top_multiclock_event0_out_OBUF) has input signal > "evtDetect5" > which will be trimmed. See the trim report for details about why the > input > signal will become undriven. > > Error found in mapping process, exiting... > Errors found during the mapping phase. Please see map report file for > more > details. Output files will not be written. > > If anybody have solved this, waiting for their positive response. > Regards > JitendraArticle: 113484
In an asynchronous FIFO, reading and writing is controlled by two counters with independent clocks. If you need to detect FULL or EMPTY, you compare the two counters for identity. If you do that with binary counters, you are vulnerable to strange decoding glitches, while multiple binary bits change (almost, but not quite, simultaneously). You never have that problem with Gray counters, where only one bit changes, from one state to the next. Peter Alfke ============= RCIngham wrote: > >There is a wrong way and a right way to convert binary to Gray count > >values: > >The wrong way hangs the (simple!) combinatorial conversion logic (XORs) > >on the binary outputs. That does you no good, since the Gray code will > >just reflect the binary transient errors. > >The right way takes the D inputs of the binary counter (, converts them > >independently to Gray and registers them in their own flip-flops. Now > >you have two parallel rgisters, both counting in step, the first in > >binary, the other in Gray, and there are no funny decoding spikes. > >BTW, only Gray counter outputs have the feature that you can compare > >two asynchronous counters for identity, without transient errors. > >If the Gray code does not come from a counter, it might change multiple > >bits per transition... > > <snip /> > Whether that is the right answer rather depends on WHY the OP "has" to use > Gray Code, which is still not fully established. > > BTW, there is a quite interesting article on Gray Code just posted at: > http://www.pldesignline.com/showArticle.jhtml?articleID=196604078Article: 113485
It is reflection and not noise, since it looks the same on every pulse. I'm trying to use LVDCI_33 on my clock signal and LVTTL on my data lines. They're all on the same bank (7). It compiles and programs but I read there is only one IOSTANDARD allowed per bank? How come it still works? Also, how much of a difference does it make where the source terminators are located? The interface board was designed with the source terminators closer to the destination rather than the source, unfortunately. Thanks.Article: 113486
Kim Enkovaara wrote: > KJ wrote: > > > > If someone does have an application that really requires true programmable > > flags I'd be interested to hear about it. The environment though is > > - Fifo is inside a programmable part. > > - That programmable part can be updated in system. > > I have many examples from telecom side. For example if you have some universal > interface card, that has each port configurable to different protocol (for > example STM1/4/16). That kind of big change in speed usually needs some changes > in fifo limits to get maximum efficiency. If you have for example 8 ports that > would need quite many different FPGA images to cover static settings. Also > partial reconfiguration in my opinion is little too dififficult way to handle > this problem. > > Of course you can code the static values for each protocol and use mux to select > one of them to the fifo comparison logic. But it's easier just to add > one register and let the software to handle the values. Also usually maximum > efficiency needs some lab testing to find the optimal fifo values. And waiting > hours for new fpga after each change in the limits is not fun. > > I have used programmable flags so many times in lab while debugging different > problems in the design, and while trying to understand the dynamics how different > limits affect interconnected fifo fystems between chips etc. > Having a single fifo with (in your case) 8 different flags come out at those 8 different fill levels would accomplish the same thing. The only thing that needing muxing would be the 8 different flags not 8 entire fifos. Software would write to a register which would select one of the 8 pre-defined constants. At some point though the logic required to generate an arbitrary number of flags that are comparisons of the fill level to a set of fixed constants becomes greater than the cost to compare the fill level to a programmable register. At what point that you cross that threshold depends on the number of bits in the counter, but in the cases where I've run across it was cheaper (in logic) and faster in performance to do the multiple comparisons and select but that was with 4 sets of fill levels....8 choices might just push you over. I agree that lab testing to empirically find those optimal values can be a pain when it means an FPGA rebuild but once beyond that and the optimal values determined they usually tend to stay set in concrete. Hard coding them in at that point would tend to give you less logic and better performance (again, how much depends on the counter size). Good example. KJArticle: 113487
Peter Alfke wrote: > In an asynchronous FIFO, reading and writing is controlled by two > counters with independent clocks. > If you need to detect FULL or EMPTY, you compare the two counters for > identity. > If you do that with binary counters, you are vulnerable to strange > decoding glitches, while multiple binary bits change (almost, but not > quite, simultaneously). You never have that problem with Gray counters, > where only one bit changes, from one state to the next. How about a different way? Couldn't one simply maintain two views (one for each clock) of the state of the FIFO, always a conservative approximation to the "true" state, and use standard handshake techniques to communicate to the writer "since our last handshake, I've dequeued X words", and visa versa. The advantage of this (besides simplicity) is that one can pipeline the handshake arbitrarily much, only at the expense of added latency between full->non-full and empty->non-empty transitions. Isn't this a standard technique? TommyArticle: 113488
Show me... What tool (and what code!) infers a FIFO from RTL functional code? Today's latest tools can infer _memories_ from rtl functional descriptions, even dual port ones, but not FIFOs. There aren't any yet that can even infer the port size changing hardware built into some block rams. You can roll your own, but it will use luts, etc. to build the extra hardware, not use the built-in features of the memory primitive. Andy KJ wrote: > "John_H" <newsgroup@johnhandwork.com> wrote in message > news:tz5gh.7746$Li6.5593@trndny03... > > ashish.dobhal@gmail.com wrote: > >> In the presence of numerous styles for designing asynchronous FIFOs, > >> how does FPGA synthesis tools infer the FIFO specified in RTL? > >> > >> Thanks in advance. > >> > >> Ashish > > > > I know of no tool that infers FIFOs, async or synchronous. > > > You must be using very primitive tools. Altera, Xilinx and Synplify (and > probably most other major players) certainly do. > > As to the original question there probably aren't really that many 'styles' > as you may think. One time through whatever part of the tool chain it is > that takes the raw source code and converts it to something equivalent but > easier for the downstream tools to chew on and those supposedly numerous > styles likely all pop out looking the same. Remember, no matter how you > code it, the functionality of the fifo isn't changing. > > After all, there are many ways to code just a flip flop and the tools can > recognize all of those as well so you could rightly ask the same question > about how the tools detect a flip flop. > > KJArticle: 113489
RCIngham wrote:
> I agree with Kim. The Altera Quartus tool help shows several ways of
> instantiating FIFO "macros", but apparently none of inferring one!
> Inferring counters, shift registers and the like is easy, but I can't
> imagine how to do so for a FIFO. I've had quite enough difficulty
> inferring a ROM...
I can *design* a fifo by inferring dpram
and counters. The only reason I can't
infer the vendor fifos exactly is
that the vendors don't want to give
away the source code for such a template.
-- Mike Treseler
Article: 113490> How am I supposed to get ISE to produced the "placed" version of the > bmm file?? The "placed" version is actually produced by bitgen, i.e. you need to run the Generate Programming File process if you use GUI... /MikhailArticle: 113491
Those clock inputs cannot be configured as LVPECL? I know general purpose differential inputs can be LVPECL. You have to terminate on board though. Are there other things on board clocked off the same clock? If not (i.e. nothing external is synchronous to that clock somewhere, then what does it matter which side you get into the FPGA on; just pick one and build the board that way. I can't imagine the FPGA clock design would be nearly as complex (or risky) as what you want to do on the board. Andy Kurt Kaiser wrote: > "Andy" <jonesandy@comcast.net> schrieb im Newsbeitrag > news:1166052157.531419.185640@l12g2000cwl.googlegroups.com... > > Why do you need to connect the same clock to more than one clock input > > on your FPGA? What kind of FPGA are you using? > > > > If I had to buffer and translate, I would rather translate, then > > buffer. Unless you are very careful with your resistors and > > interconnect, a resistor translator may not work too well. > > > > Andy > > Thanks so far for your answer. I'm using Virtex-4 FX60. Depending on the > implemented designs I will use either the clock input on one side or the > other, not both the at the same time of course. So I'm hoping for more > flexibility and freedom of clock routing if I have two clocks available and > stick to the one that fits better from design to design. The FPGA's input is > LVDS.Article: 113492
lbo_user wrote: > Thanks Pete, > > I'm happy with the functionality of the flash, I'm more concerned with > the amount of effort needed to write my own controller. The majority > of the work looks to be in the program/erase polling state machines. > I'm just really short on time and have been looking for faster > alternatives to writing my own controller. It's looking more and more > like that's the way I'll have to go though. > > Ta. > I am sure there are cores out there; this is not a new area. Have you asked the FPGA vendors or checked the third party links? Cheers PeteSArticle: 113493
lingamaneni.naveen@gmail.com wrote: > Hello Guys, > First of all thanks for all of your valuble suggestions.I was able to > get the source code (ABEL) for all the PAL's now.Since most of the > PAL's were absolute now and for ROHS compliance we are redesigning the > board and now we want to replace bulky PAL's around 70 Wow, that's some sea-of-pals! What parts are they ? > and eight XC3130 series(VHDL) into state of the art FPGA devices. Does this need to be 'instant-on' ? - or 5V complaint ? > Coming to my first point > 1. Can i have a VHDL main module and integrate all the individual .ABL > files as it is and achieve the same functionality of all the PAL's > within FPGA. > (With out converting ABEL to VHDL) See Gabor's post. This sounds worth trying, perhaps on a couple of Xilinx tool flows (and I think Lattice also have Abel in their flows ) > > 2. Here the board performance (timing of PAL) has to remain the same > with high speed FPGA also.Never worked on timing issues till now but > heard registering and using flip flop can solve problem any better > ideas? > (First i am working out on how to get the timing of a PAL from the old > board before knowing how to achieve the same timing with in a high > speed FPGA ) > > Sorry for my list of questions and Thanks for being supportive. This could be interesting... Trying to actually match timing is not going to be easy. If the PLD code is all Clock-based, then you only need to be 'the same, or faster' on the FPGA. - but the PLD code may not be quite that clean.... I'd suggest a scan of the Abel sources, and also compile the sources you have (minimal changes, non-merged), to a legal target (XC2C32A?), and read the warnings and fitter report files. The try merge of a couple of sources, into one Abel source file, if you use PIN for the external signals, and nodes for the ones that are only pal-pal, then the tools can optimise if they need to, or use keep if you want to avoid that. -jgArticle: 113494
Hi, I start to work on FPGA Embedded system. I am trying to port the MonstaVista Linux on the system. First I built the system with EDK, the option for my system is: XUPV2P: powerPC 405 300MHz Bus 100MHz RS232_Uart_1 OPB UART 16550 (interrupt) Ethernet_MAC OPB ETHERNET (interrupt) SysACE_Compact Flash (interrupt) DDR_512MB I continue to work on software platform which is: Linux_mv131 version 1.01.b MEM_SIZE 0x10000000 PLB_CLOCK_FREQ_HZ 100000000 (100 MHz) Connected_periphs RS232_Uart_1, Ethernet_MAC, SysACE_CompactFlash, opb_intc_0 After generate the bitstream, then Generate Libraries and BSPs, I meet this error: TARGET_DIR : D:\My_Researches\Workspace\Report2\os\ ERROR:MDT - ERROR FROM TCL:- linux_mvl31 () - /usr/bin/bash: -c: line 1: unexpected EOF while looking for matching `"' /usr/bin/bash: -c: line 2: syntax error: unexpected end of file while executing "exec bash -c "cp -Rfp $cur_dir/linux/* $value"" (procedure "::sw_linux_mvl31_v1_01_b::post_generate" line 166) invoked from within "::sw_linux_mvl31_v1_01_b::post_generate 43482512" ERROR:MDT - Error while running "post_generate" for processor ppc405_0... make: *** [ppc405_0/lib/libxil.a] Error 2 If you meet this before, PLease give me some recommendation. I highly appreciate your help. Thang NguyenArticle: 113495
Frank Buss ha scritto:
> 50 MHz is not good, because it violates timing of the DDR RAM. Use this
> code for generating 266 MHz:
>
> -- Spartan 3E stepping 0, speed grade -4 devices:
> -- CLKFX frequency in "high" mode: min: 220 MHz, max: 307 MHz
> clock266: dcm_sp
> generic map(
> clkfx_multiply => 16,
> clkfx_divide => 3,
> clkin_period => 4.0,
> dfs_frequency_mode => "HIGH")
> port map(
> clkfx => clk_266mhz,
> clkin => clk_50mhz);
>
> As far as I understand, you can't divide to 133 MHz, because the datasheet
> specifies different ranges for high and low mode for the speed grade -4
> devices, so I've used this additional code for dividing 266 MHz by two:
>
> -- divide 266 MHz to system clock
> clock_divide: process(clk_266mhz)
> begin
> if rising_edge(clk_266mhz) then
> clk_133mhz <= not clk_133mhz;
> end if;
> end process;
>
> The signals:
>
> signal clk_266mhz: std_logic := '0';
> signal clk_133mhz: std_logic := '0';
>
> Imports:
>
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.NUMERIC_STD.ALL;
> use IEEE.MATH_REAL.ALL;
>
> Library UNISIM;
> use UNISIM.vcomponents.all;
>
> At least it works for my TCP/IP receiver/sender core, let me know, if it
> works with your DDR implementation and maybe upload the project somewhere
> or submit your modifications to the Open Cores project.
>
> --
> Frank Buss, fb@frank-buss.de
> http://www.frank-buss.de, http://www.it4-systems.de
Hello,
now the controller work at 133MHz; I use directly the DCM like this:
clk_in_ibufg : IBUFG port map (I=>sys_clk_pin, O=>CLKIN_IBUFG);
DCM_SP_INST : DCM_SP generic map(
CLK_FEEDBACK => "NONE",
CLKDV_DIVIDE => 2.0,
CLKFX_DIVIDE => 3,
CLKFX_MULTIPLY => 8,
CLKIN_DIVIDE_BY_2 => FALSE,
CLKIN_PERIOD => 20.0,
CLKOUT_PHASE_SHIFT => "NONE",
DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS",
DFS_FREQUENCY_MODE => "LOW",
DLL_FREQUENCY_MODE => "LOW",
DUTY_CYCLE_CORRECTION => TRUE,
FACTORY_JF => x"C080",
PHASE_SHIFT => 0,
STARTUP_WAIT => FALSE)
port map (
CLKFB=>'0',
CLKIN=>CLKIN_IBUFG,
DSSEN=>'0',
PSCLK=>'0',
PSEN=>'0',
PSINCDEC=>'0',
RST=>sys_rst_pin,
CLKFX=>CLKFX_BUF,
LOCKED=>rst_n,
PSDONE=>open,
STATUS=>open);
clkfx_bufg : BUFG port map (I=>CLKFX_BUF, O=>clk100mhz);
where sys_clk_pin is the S3E board clock (at 50MHz).
Why do you think that is better to use 266Mhz and after divide by 2 the
clock? (is the jitter better?)
May I also know if sameone say me how can I modify the controller to
use all the DDR memory (the opencore's DDR is for 256 Mbit but I have a
512 Mbit).
Thanks for all.
Daniele
Article: 113496Hi! Does anybody here have experience with Virtex-4 MGTs in SONET alignment configuration? We turn of ENPCOMMAALIGN and ENMCOMMAALIGN immediately after we see COMMDA_DETECT and still the byte aligner shifts bits around the next time it sees an A1 or A2 pattern.(This happens a couple of clock cycles after the sync pattern of 12 times A1 folloed by 12 times A2 was received. Kolja Sulimma cronologic ohgArticle: 113497
Hello, We are using the Xilinx Virtex-II Pro Developement System XUP-V2P. Our objective is to read a binary file that contains 0101 into the board from the compact flash card, then modify the file and write it back to the board. Right now we would just like to invert the numbers, to make things simple. Our main problem is when we connect the CF Card to the Board the SYSTEM ACE ERROR light illuminates. We have checked to make sure that it is formatted correcly using mkdosfs, as recommended by Xilinx. The only thing loaded on the card is our .bin file. Does anyone know what else could cause this? Thank you.Article: 113498
cippalippa wrote: > where sys_clk_pin is the S3E board clock (at 50MHz). > Why do you think that is better to use 266Mhz and after divide by 2 the > clock? (is the jitter better?) See the datasheet ds312.pdf page 145: For stepping 0, speed grade -4 devices, like on my S3E board, there are 2 DFS_FREQUENCY_MODE modes: low and high. For low CLKOUT_FREQ_FX has to be between 5 and 90 MHz and for high it must be between 220 and 307 MHz. At least this is how I interpret it. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 113499
Why do we do a quadratic add of jitter when calculating total jitter. For example, with an input jitter of +/- 100 pS, and a DCM jitter of +/- 100pS, will there not be an instant (with very low probability) that when the input hits the -100pS, the DCM follows it with another - 100pS, leading to a total time period narrowing of 200pS?
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