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's possible if you have a spare I/O. Basically you send the clock to output of this spare IO pad and connect the input of the same I/O pad to IDELAY. You then route the output from the IDELAY to the your original clock out pad. Cheers, Jim http://home.comcast.net/~jimwu88/tools/ Ashish wrote: > Hi, > > I need to phase shift (180 deg) an output clock(100MHz) , I have an > option of using DCM and with this it is possible. > > Is there any alternative way of implementing clock shift by using any > ready component to implement phase shift.(Xilinx Virtex 4 FPGA). I wish > to avoid using a DCM resource. > > I have used IDELAY component while phase shifting an incoming clock but > need similar alternative for o/p clock. > > Any suggestions /comments welcome. > > Thank you > AshishArticle: 113101
Alan Myler wrote: > Use an inverter? I don't think this will result in an exact 180 shifted signal at 100 MHz, because of the delay of the inverter, so using a DCM is a good idea. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 113102
MM wrote: > Ed, > > > Has anyone ever had success routing an NPI port of the MPMC2 > > controller to an External Port of a PPC based system component in EDK > > (i.e. I would like to route an NPI port to some custom logic... > > I haven't tried exporting MPMC2 ports, but I succeded in designing a NPI > peripheral. If you really want to export the pins you probably have to do > what Antti says, i.e. create a dummy peripheral. But then why not to do your > whole custom thing as a peripheral? > Mikhail, What I am trying to do is "quickly" generate a memory interface where my custom logic loads DRAM with data and the PowerPC performs computations based on data I loaded into this area of memory. Chances are that as I gain more experience with EDK I will make all of my custom logic a peripheral....until then, I am simply getting started with MPMC2 and taking it from there. Without going into high level details of the design, I am using this approach to give software engineers the ability to test algorithms out on the data stored in DRAM while I migrate SW algorithms to hardware (if reasonably possible). Eventually, I might be able to fit everything in HW, but we will see. I am not expecting the software to run in real time, but we will be able to see results at lower than full rate. Overall, it looks like I need to make an NPI set of wires to plug into the NPI port...I agree that modifying the generated MPD is not the way to do things :)! I already did this, but I must have some error in the files since EDK is not seeing my perhipheral :)! I'll fix this soon enough though. After I get this running, I have a few more questions about MPMC2, but I will save those for later...my hope is that this (and related) thread can become a reference for future users of this logic. If I get permission from the powers that be where I work, I will post the resulting files to make this easier for users in the future. I also hope Xilinx can include the stub in a future release of MPMC2 for other users. By the way, this MPMC2 is an outstanding piece of IP to offer to users for free....I am curious to see the performance! Although I am having headaches (and I am sure it is due to my inexperience with EDK), this should save me a lot of time nonetheless!!!! Ed > > /MikhailArticle: 113103
> if the direct port export realy isnt working you need to create a dummy > wrap-export > ip core that doesnt do anything except connects to NPI and export wires that > can > be used as external ports. this should work, and I would say its better than > post > modifying the MPMC2 generated MPD file Agreed. I am doing this now...I am making a Verilog file that wires directly to/from the NPI ports as well as the associated MPD. I am using the NPI <-> PLB as a reference....I will hopefully have results later today. I started to do this earlier, but I cannot get EDK to see my "wires" peripheral...I am assuming that I have a bug somewhere in my new files... Ed > > AnttiArticle: 113104
Guru wrote: > Ed, > > What are you doing? > Do not try to change anything of the MPMC2 core! > If there is no connection to NPI port, just it coment it in MHS: > # BUS_INTERFACE MPMC2_PIM_4 = npi I am not trying to change the core :)! I am only playing with the MPD right now. However, I am going to stop using that approach and create a component that will (hopefully) export the wires. > > I created NPI peripherals with single write (64bits), 4 words (2x > 64bits) cacheline write and 64 words write (the fastest xfer). The > declaration of NPI port should look like in MPMC2 MPD. > OK. > The NPI port is very handy bus to connect peripherals that require fast > and simple DMA access - huraa for the Xilinx MPMC2 team. > I agree 100% ... this core is a huge time saver and offers some nice flexibility. I am curious to see what performance is like :)! > Cheers, > > Guru > > ed_h wrote: > > HI Antti, > > > > First and foremost, thank you for the reply! > > > > I tried your suggestion at first, but when I go to build the netlist > > in EDK after connecting the ports using your suggested method, I get > > this error: > > > > ERROR:MDT - mpmc2_ddr_idpon_100mhz_x16_mt46v16m16_6t > > (mpmc2_ddr_idpon_100mhz_x16_mt46v16m16_6t_0) - > > C:\projects\test_single_npi\system.mhs line 235 - transparent bus > > interface > > connector 'npi_4' is only referenced once! > > > > That is why I started editing the MPD and started removing the > > transparent bus parameters and the like. I should have been a little > > clearer in my initial post, but just let me blame that on my > > inexperience with EDK :) . > > > > When I remove the transparent bus types from the MPD, I get this > > warning when I generate the block diagram : > > > > WARNING:MDT - Bridge mpmc2_ddr_idponn_100mhz_x16_mt46v16m16_6t_0 is > > connected to > > more than two busses > > WARNING:MDT - This condition is not handled by layout algorithm > > > > Now I am starting to wonder if "layout" means layout of the block > > diagram.....for whatever stupid reason, I associated "layout" with > > "place and route" since I used to "layout" ASICs for a living a long, > > long time ago :)! If all this means is that my block diagram is > > incorrect (which it is after I remove the transparent bus), I can most > > definitely live with that... > > > > Again, many thanks! I'll be sure to post the solution to my > > problem should I figure it out :)! > > > > Ed > > > > > > > > > > > > Antti Lukats wrote: > > > "ed_h" <ehenciak@gmail.com> schrieb im Newsbeitrag > > > news:1165351478.866080.261170@80g2000cwy.googlegroups.com... > > > > Hi all, > > > > > > > > Has anyone ever had success routing an NPI port of the MPMC2 > > > > controller to an External Port of a PPC based system component in EDK > > > > > > 1) dont change the MPD > > > 2) in EDK set port visible filter "all" > > > you should see all ports of all cores, and you can make any of then exertnal > > > > > > AnttiArticle: 113105
Frank Buss wrote: > Alan Myler wrote: > > > Use an inverter? > > I don't think this will result in an exact 180 shifted signal at 100 MHz, > because of the delay of the inverter, so using a DCM is a good idea. DCM is a always the best option. I just wanted to avoid using this resource. Using inverter it might not be exact 180 deg phase shift considering 100 Mhz clock and inverter delay. > > -- > Frank Buss, fb@frank-buss.de > http://www.frank-buss.de, http://www.it4-systems.de Is it still possible to use IDELAY component without having to loop back through IO pad? Thanks. AshishArticle: 113106
Hi Peter Alfke, Thanks for viewing Topweaver Anydivider (TAD). In fact the feature you said has been realized by TAD. And it is only a part of TAD. If TAD can only generate the "n and n-1 consecutive pulses", I can not name it ANY. The waveform of the output clock can be either from automatical calculation or from visual adjustment. The example of 4/11 is in manual mode, to illustrate how to drag the waveform to anything you want. And the performance report shows a jitter of 22.40437%. "A good solution" can be generated in the auto mode, which is shown in the first picture. A strong point of TAD is the powerful analysis ability, which can help the engineers to choose the best waveform. TAD "Peter Alfke =D0=B4=B5=C0=A3=BA " > This sounded interesting until I saw the output. > It is not a frequency of pulses, but rather the incoming pulse-stream > with the appropriate number of pulses deleted. That means a big jitter > (except for the trivial cases of integer division) and a broad > spectrum. > If that is acceptable, your solution is still not optimal, as shown in > your example of 4/11, which could have a better spectrum than the one > you provide. > A good solution should only delete n and n-1 consecutive pulses. > Peter Alfke >Article: 113107
Ok, well I'm pretty sure I don't have any need to implement a SERDES.
I'm not too familiar with source synchronous design, but based on
these,
http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/cgd/cgd0042_7.html
http://www.eetimes.com/story/OEG20031024S0033
I'm pretty sure I won't have to worry about using BUFIO's/BUFR. The
only reason I asked this question originally is because in the past
I've only had experience with a Virtex 2 COTs board, and now that I'm
using a Virtex 4 board. I stumbled upon some examples that had
BUFIO/BUFR's, but was sort of clueless as to why they used them. The
board I'm using has some ADCs (250 MSPS) and a FIFO for data capture,
yet they are using the BUFIO/BUFR combo. Do you suppose they are using
this to achieve higher clock rates in the front end? I can meet
front-end timing with BUFG's just fine...
Is ISE smart about dealing with the BUFR's? What if you have too many
slices for a given BUFR region and they can't fit? Will it burp?
Here is my current processing chain. Maybe you would have some
recommendations for clock schemes? It would be much appreciated.
--> [ADC IN] -- 250 MHz--> [FIFO] -- X MHz --> [SEQ PROCESSING] --> X/2
MHz --> [OUT]
Currently, I have X = 200 MHz, but obviously, I'm not meeting timing.
This is okay tho, beacuse I have a differential programmable oscillator
coming from off chip to drive all of my sequential processing, so I've
been using 160 MHz due to the below constraint failure below:
<SNIP>
Slack: -1.136ns (requirement - (data path - clock path
skew + uncertainty))
Source:
wideangle_drpp2_inst/qrdc_ins/multre_mux_reg_ins/d_r_12 (FF)
Destination:
wideangle_drpp2_inst/qrdc_ins/doutre_reg_ins/d_r_4 (FF)
Requirement: 5.000ns
Data Path Delay: 6.071ns (Levels of Logic = 1)
Clock Path Skew: -0.005ns
Source Clock: logic_clk rising at 0.000ns
Destination Clock: logic_clk rising at 5.000ns
Clock Uncertainty: 0.060ns
Timing Improvement Wizard
Data Path: wideangle_drpp2_inst/qrdc_ins/multre_mux_reg_ins/d_r_12 to
wideangle_drpp2_inst/qrdc_ins/doutre_reg_ins/d_r_4
Delay type Delay(ns) Logical Resource(s)
---------------------------- -------------------
Tcko 0.291
wideangle_drpp2_inst/qrdc_ins/multre_mux_reg_ins/d_r_12
net (fanout=6) 0.835
wideangle_drpp2_inst/qrdc_ins/multre_mux_reg_ins/d_r<12>
Tdspdo_APL 3.913
wideangle_drpp2_inst/qrdc_ins/multre_ins/Mmult_p
net (fanout=1) 0.783
wideangle_drpp2_inst/qrdc_ins/multre_p<15>
Tdick 0.249
wideangle_drpp2_inst/qrdc_ins/doutre_reg_ins/d_r_4
---------------------------- ---------------------------
Total 6.071ns (4.453ns logic, 1.618ns route)
(73.3% logic, 26.7% route)
</SNIP>
Is there anyway to improve timing with any of the Virtex 4
capabilities?
Thanks,
-Brandon
markus wrote:
> As stated BUFIO/BUFR is intended for Source Synchronous Applications.
> There are significant advantages of using BUFIO/BUFR with ISERDES for
> source sync data capture: The sampling window is smaller, and the setup
> time is negative. One simply can instantiate BUFIO/BUFR/ISERDES to
> capture data without doing any type of clock/data alignment; provided
> that the data eye > (setup+hold).
>
> Also, if you'd like to forward a clock for SDR application, you can
> only use BUFIO to drive clock frequency > 500MHz.
>
> -M
>
>
> Joseph Samson wrote:
> > Brandon Jasionowski wrote:
> > > Is there any advantage of using a BUFIO/BUFR's for driving IOB FF's
> > > versus a BUFG? After looking through that section in the V4 user guide
> > > I'm not sure I really see an advantage other than resource usage of the
> > > global clock buffers.
> > >
> > > Normally I just use the typical IBUFG -> DCM -> BUFG setup and use the
> > > output of the BUFG to drive everything...
> >
> > The BUFIO and BUFR are really meant for use with source-synchronous data
> > inputs. The BUFIO can only be driven from clock-capable input pins. The
> > BUFR can be driven from the BUFIO or the fabric, but there not much
> > advantage if you're driving it from the fabric. The typical use is to
> > have the BUFIO clock the input SERDES at the fast clock rate, and use
> > the BUFR with its divider to clock the SERDES outputs to the fabric.
> >
> > ---
> > Joe Samson
> > Pixel Velocity
Article: 113108topweaver@hotmail.com wrote: > Hi Peter Alfke, > Thanks for viewing Topweaver Anydivider (TAD). > In fact the feature you said has been realized by TAD. And it is only a > part of TAD. If TAD can only generate the "n and n-1 consecutive > pulses", I can not name it ANY. > The waveform of the output clock can be either from automatical > calculation or from visual adjustment. > The example of 4/11 is in manual mode, to illustrate how to drag the > waveform to anything you want. And the performance report shows a > jitter of 22.40437%. > "A good solution" can be generated in the auto mode, which is shown in > the first picture. > A strong point of TAD is the powerful analysis ability, which can help > the engineers to choose the best waveform. > > TAD > > "Peter Alfke =D0=B4=B5=C0=A3=BA > " > > This sounded interesting until I saw the output. > > It is not a frequency of pulses, but rather the incoming pulse-stream > > with the appropriate number of pulses deleted. That means a big jitter > > (except for the trivial cases of integer division) and a broad > > spectrum. > > If that is acceptable, your solution is still not optimal, as shown in > > your example of 4/11, which could have a better spectrum than the one > > you provide. > > A good solution should only delete n and n-1 consecutive pulses. > > Peter Alfke > > Very interesting program. I have a suggestion for code implementation to work better in Xilinx (and possibly other) FPGA's. Your code uses clock gating to generate narrow pulses. At least in Xilinx FPGA's it is not a good assumption that the Q output of a flip-flop has a longer delay to the gate input than the clock does. In fact, depending on the placement, a route from a global clock to a LUT input can be several nanoseconds. This can cause glitches even when you use the "correct" phase of the clock in your output logic. I would suggest using only flip-flop outputs to generate the module output, using XOR functions as necessary to generate outputs using both clock edges. The global clock routing to the flip-flop clocks is much better than you can do routing a global clock to a LUT input (or flip-flop D). For waveforms that change on both input clock edges, It should be possible to generate the output as the XOR of just two flip-flops, one clocked on each edge. One of the flip-flops would toggle at each edge in the output waveform. At higher input clock rates this method also gives improved duty cycle accuracy, as the clock to output path on each edge looks like one flip-flop clock to Q delay followed by one LUT delay. Differences in clock-to-Q for rising vs falling edge flip-flops are small compared to routing delays in the FPGA. Regars, GaborArticle: 113109
I apologize if this questions has been answered already. I was unable to find an answer in my search through this group. If you have any experience using LVDS with Xilinx FPGAs, please help. Q: If I have a LVDS input, must my top-level entity specify both the N and P ports, or is there a way to specify that a port should use LVDS in a constraint file and have the Xilinx tools infer the correct buffers? I know something to this effect works: ... input_p : std_logic; input_n : std_logic; ... port map ( I => input_p, IB => input_n, O => internal_single_ended_signal); But, is there a way to just have the following (plus specify that input is LVDS in a constraints file) and have the xilinx tools infer what is in the code above?: ... input : std_logic; ... Thank you in advance for your help.Article: 113110
Is there a source for an explanation on what the USERX registers do in the JTAG Configuration? I found the configuration guide, but that doesn't seem to explain it much with regards to the MDM and ChipScope. Thanks for the help!!!Article: 113111
Let me explain what I mean with n and n-1. If you want to reduce the number of pulses per unit time (that's what you are doing) you do that by eliminating pulses from the input stream. You can achieve ANY desired result by a pattern of eliminated pulses. I claim that this pattern can achieve the desired result best when the number of adjacently eliminated pulses never varies by more than one. If you must eliminate 4 adjacent pulses, then mix that with 3 adjacent pulses. Or for a lower "frequency" mix it with 5 adjacent pulses, but never with a mixture of 3, 4, and 5 adjacent pulses. There is no need for it mathematically. Peter Alfke On Dec 6, 8:03=C2=A0am, topwea...@hotmail.com wrote: > Hi Peter Alfke, > Thanks for viewing Topweaver Anydivider (TAD). > In fact the feature you said has been realized by TAD. And it is only a > part of TAD. If TAD can only generate the "n and n-1 consecutive > pulses", I can not name it ANY. > The waveform of the output clock can be either from automatical > calculation or from visual adjustment. > The example of 4/11 is in manual mode, to illustrate how to drag the > waveform to anything you want. And the performance report shows a > jitter of 22.40437%. > "A good solution" can be generated in the auto mode, which is shown in > the first picture. > A strong point of TAD is the powerful analysis ability, which can help > the engineers to choose the best waveform. > > TAD > > "Peter Alfke =E5=86=99=E9=81=93=EF=BC=9A > " > > > This sounded interesting until I saw the output. > > It is not a frequency of pulses, but rather the incoming pulse-stream > > with the appropriate number of pulses deleted. That means a big jitter > > (except for the trivial cases of integer division) and a broad > > spectrum. > > If that is acceptable, your solution is still not optimal, as shown in > > your example of 4/11, which could have a better spectrum than the one > > you provide. > > A good solution should only delete n and n-1 consecutive pulses. > > Peter AlfkeArticle: 113112
"Peter Alfke" <peter@xilinx.com> writes:
>Let me explain what I mean with n and n-1.
>
>If you want to reduce the number of pulses per unit time (that's what
>you are doing) you do that by eliminating pulses from the input stream.
>You can achieve ANY desired result by a pattern of eliminated pulses.
>I claim that this pattern can achieve the desired result best when the
>number of adjacently eliminated pulses never varies by more than one.
>If you must eliminate 4 adjacent pulses, then mix that with 3 adjacent
>pulses. Or for a lower "frequency" mix it with 5 adjacent pulses, but
>never with a mixture of 3, 4, and 5 adjacent pulses. There is no need
>for it mathematically.
Sounds to me like the good old SN7497 "binary rate multiplier".
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Article: 113113The port mapping must specify p and n sides of the input as you have done. The UCF needs to have the IOSTANDARD = LVDS_x set and only the P side pin needs a LOC constraint. The tools will pick up the IO standard correctly and place the N side on the correct corresponding P pin. "Morgan" <morgank@lanl.gov> wrote in message news:1165424528.893445.244150@l12g2000cwl.googlegroups.com... >I apologize if this questions has been answered already. I was unable > to find an answer in my search through this group. > > If you have any experience using LVDS with Xilinx FPGAs, please help. > > Q: If I have a LVDS input, must my top-level entity specify both the N > and P ports, or is there a way to specify that a port should use LVDS > in a constraint file and have the Xilinx tools infer the correct > buffers? > > I know something to this effect works: > > ... > input_p : std_logic; > input_n : std_logic; > ... > port map ( > I => input_p, > IB => input_n, > O => internal_single_ended_signal); > > > But, is there a way to just have the following (plus specify that input > is LVDS in a constraints file) and have the xilinx tools infer what is > in the code above?: > > ... > input : std_logic; > ... > > > Thank you in advance for your help. >Article: 113114
Is there a source for an explanation on what the USERX registers do in the JTAG Configuration? I found the configuration guide, but that doesn't seem to explain it much with regards to the MDM and ChipScope. Thanks for the help!!!Article: 113115
mark.jarvin@gmail.com writes: > The 1025 firmware is packaged with the new driver installation stuff: > ftp://ftp.xilinx.com/pub/utilities/install_drivers.tar.gz It may have moved; it now seems to be at: ftp://ftp.xilinx.com/pub/utilities/fpga/install_drivers.tar.gzArticle: 113116
Frank Buss wrote: > Alan Myler wrote: > >> Use an inverter? > > I don't think this will result in an exact 180 shifted signal at 100 MHz, > because of the delay of the inverter, so using a DCM is a good idea. > In virtually every place where the clock is used with X chips, the inverter will be absorbed into the IOB/slice and will not result in extra delay. Every FF, IO FF, BRAM, etc sticks a mux in front of the clock pin, with one inverting and one non-inverting input. There is no way to bypass them. The only consideration I can see when using the inverter method is whether the clock is close to a 50% duty cycle.Article: 113117
"motty" <mottoblatto@yahoo.com> schrieb im Newsbeitrag news:1165428452.399140.288090@n67g2000cwd.googlegroups.com... > Is there a source for an explanation on what the USERX registers do in > the JTAG Configuration? I found the configuration guide, but that > doesn't seem to explain it much with regards to the MDM and ChipScope. > Thanks for the help!!! > they are used to "bypass" the data from JTAG into FPGA fabric xilinx FPGAs before V4 has all 2 USER instructions V4 and V5 have 4 and unfortunatly the very first LX25 ES silicon has only USER1 working, eg USER2, USER3, USER4 are not working so you can have 2 clients in LX25-ES hence no chance to have CS and MDM in LX25-ES AnttiArticle: 113118
"Antti Lukats" <antti@openchip.org> schrieb im Newsbeitrag news:el71of$oog$1@online.de... > "motty" <mottoblatto@yahoo.com> schrieb im Newsbeitrag > news:1165428452.399140.288090@n67g2000cwd.googlegroups.com... >> Is there a source for an explanation on what the USERX registers do in >> the JTAG Configuration? I found the configuration guide, but that >> doesn't seem to explain it much with regards to the MDM and ChipScope. >> Thanks for the help!!! >> > > they are used to "bypass" the data from JTAG into FPGA fabric > xilinx FPGAs before V4 has all 2 USER instructions > V4 and V5 have 4 > and unfortunatly the very first LX25 ES silicon has only USER1 working, eg > USER2, USER3, USER4 are not working so you can have 2 clients in LX25-ES > > hence no chance to have CS and MDM in LX25-ES > > Antti > MDM uses normally USER2 and "exports" USER1 signals for chipscope the MDM 2.01.a is not a new verson its a PATCH version that is only for LX25-ES it uses USER1 for MDM, and nothing for chipscope AnttiArticle: 113119
I'm not familiar with ADC applications (i.e. whether they use source sync data capture etc). I think I may know why they use BUFIO/BUFR. I think what they are doing is to deserialize the incoming data. If you were to capture 250 MSPS data in an SDR fashion and no FIFOs or deserialization, you effectively force the FPGA fabric to operate at 250MHz. Although this is a valid and possible clock frequency to achieve, it becomes more and more difficult to achieve this frequency with a really packed FPGA. Perhaps the example deserialize the incoming data so that it doesn't have to operate at 250MHz. In regards to your question about BUFR. Yes, the tool should notify the user when there's not enough logic in the BUFR clock domain. Basically, what you want to do is to use the BUFR for deserialized clock domain in the data capture process, not for processing (unless you really need to). What I've personally have done int the past is to immediately transfer the deserialized data from BUFR to BUFG using FIFO16s. In regards to your question about meeting timing. Here are my options: 1). Go to higher speed grade, this is the easiest solution, but the most uneconomical 2). Check the data path that's failing, and insert pipelining register 3). Deserialized the data from 250MHz to a lower frequency. Hope this helps, -M Brandon Jasionowski wrote: > Ok, well I'm pretty sure I don't have any need to implement a SERDES. > I'm not too familiar with source synchronous design, but based on > these, > > http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/cgd/cgd0042_7.html > http://www.eetimes.com/story/OEG20031024S0033 > > I'm pretty sure I won't have to worry about using BUFIO's/BUFR. The > only reason I asked this question originally is because in the past > I've only had experience with a Virtex 2 COTs board, and now that I'm > using a Virtex 4 board. I stumbled upon some examples that had > BUFIO/BUFR's, but was sort of clueless as to why they used them. The > board I'm using has some ADCs (250 MSPS) and a FIFO for data capture, > yet they are using the BUFIO/BUFR combo. Do you suppose they are using > this to achieve higher clock rates in the front end? I can meet > front-end timing with BUFG's just fine... > > Is ISE smart about dealing with the BUFR's? What if you have too many > slices for a given BUFR region and they can't fit? Will it burp? > > Here is my current processing chain. Maybe you would have some > recommendations for clock schemes? It would be much appreciated. > > --> [ADC IN] -- 250 MHz--> [FIFO] -- X MHz --> [SEQ PROCESSING] --> X/2 > MHz --> [OUT] > > Currently, I have X = 200 MHz, but obviously, I'm not meeting timing. > This is okay tho, beacuse I have a differential programmable oscillator > coming from off chip to drive all of my sequential processing, so I've > been using 160 MHz due to the below constraint failure below: > > <SNIP> > Slack: -1.136ns (requirement - (data path - clock path > skew + uncertainty)) > Source: > wideangle_drpp2_inst/qrdc_ins/multre_mux_reg_ins/d_r_12 (FF) > Destination: > wideangle_drpp2_inst/qrdc_ins/doutre_reg_ins/d_r_4 (FF) > Requirement: 5.000ns > Data Path Delay: 6.071ns (Levels of Logic = 1) > Clock Path Skew: -0.005ns > Source Clock: logic_clk rising at 0.000ns > Destination Clock: logic_clk rising at 5.000ns > Clock Uncertainty: 0.060ns > Timing Improvement Wizard > Data Path: wideangle_drpp2_inst/qrdc_ins/multre_mux_reg_ins/d_r_12 to > wideangle_drpp2_inst/qrdc_ins/doutre_reg_ins/d_r_4 > Delay type Delay(ns) Logical Resource(s) > ---------------------------- ------------------- > Tcko 0.291 > wideangle_drpp2_inst/qrdc_ins/multre_mux_reg_ins/d_r_12 > net (fanout=6) 0.835 > wideangle_drpp2_inst/qrdc_ins/multre_mux_reg_ins/d_r<12> > Tdspdo_APL 3.913 > wideangle_drpp2_inst/qrdc_ins/multre_ins/Mmult_p > net (fanout=1) 0.783 > wideangle_drpp2_inst/qrdc_ins/multre_p<15> > Tdick 0.249 > wideangle_drpp2_inst/qrdc_ins/doutre_reg_ins/d_r_4 > ---------------------------- --------------------------- > Total 6.071ns (4.453ns logic, 1.618ns route) > (73.3% logic, 26.7% route) > </SNIP> > > Is there anyway to improve timing with any of the Virtex 4 > capabilities? > > Thanks, > -Brandon > > markus wrote: > > As stated BUFIO/BUFR is intended for Source Synchronous Applications. > > There are significant advantages of using BUFIO/BUFR with ISERDES for > > source sync data capture: The sampling window is smaller, and the setup > > time is negative. One simply can instantiate BUFIO/BUFR/ISERDES to > > capture data without doing any type of clock/data alignment; provided > > that the data eye > (setup+hold). > > > > Also, if you'd like to forward a clock for SDR application, you can > > only use BUFIO to drive clock frequency > 500MHz. > > > > -M > > > > > > Joseph Samson wrote: > > > Brandon Jasionowski wrote: > > > > Is there any advantage of using a BUFIO/BUFR's for driving IOB FF's > > > > versus a BUFG? After looking through that section in the V4 user guide > > > > I'm not sure I really see an advantage other than resource usage of the > > > > global clock buffers. > > > > > > > > Normally I just use the typical IBUFG -> DCM -> BUFG setup and use the > > > > output of the BUFG to drive everything... > > > > > > The BUFIO and BUFR are really meant for use with source-synchronous data > > > inputs. The BUFIO can only be driven from clock-capable input pins. The > > > BUFR can be driven from the BUFIO or the fabric, but there not much > > > advantage if you're driving it from the fabric. The typical use is to > > > have the BUFIO clock the input SERDES at the fast clock rate, and use > > > the BUFR with its divider to clock the SERDES outputs to the fabric. > > > > > > --- > > > Joe Samson > > > Pixel VelocityArticle: 113120
wanwan wrote: > What I really need to do is to program a chip to have a logic circuit, > so that I can use it elsewhere. I am considering this approach rather > than building with an IC circuit. Can anyone give me suggestions > please? Is it plug-able that's important ? How complex is that 'logic circuit' How fast does it need to operate ? - can you describe what you want to do, and you can get more accurate advice. -jgArticle: 113121
Ashish, everybody agrees that the DCM is the best solution, but you never told us why you want to avoid it at any cost. Peter Alfke On Dec 6, 7:42 am, "Ashish" <ashish.shringarp...@gmail.com> wrote: > Frank Buss wrote: > > Alan Myler wrote: > > > > Use an inverter? > > > I don't think this will result in an exact 180 shifted signal at 100 MHz, > > because of the delay of the inverter, so using a DCM is a good idea.DCM is a always the best option. > I just wanted to avoid using this resource. Using inverter it might not > be exact 180 deg phase shift considering 100 Mhz clock and inverter > delay. > > > > > -- > > Frank Buss, f...@frank-buss.de > >http://www.frank-buss.de,http://www.it4-systems.deIs it still possible to use IDELAY component without having to loop > back through IO pad? > > Thanks. > > AshishArticle: 113122
Antti wrote: <snip> > here is utilization report targetting S3-50A 2KB LMB > RAM (must use Byte write enables!) and OPB UART > > > Total Number 4 input LUTs: 1,195 out of 1,408 84% > Number used as logic: 848 > Number used as a route-thru: 5 > Number used for Dual Port RAMs: 256 > (Two LUTs used per Dual Port RAM) > Number used as Shift registers: 86 > Number of bonded IOBs: 4 out of 108 3% > IOB Flip Flops: 2 > Number of GCLKs: 1 out of 24 4% > Number of DCMs: 1 out of 2 50% > Number of RAMB16BWEs: 1 out of 3 33% > > the LUT utilization is is 84% not 75% Xilinx claims, but maybe MB ver > 6.0 brings some more size reduction, this report is with MB v 4.00.b Or maybe they omit the uart ? What do the speeds look like ? Can you eaily try MB 5? -jgArticle: 113123
I have Xilinx FPGA and need to delay a signal to pad. It is not a clock. I would like to do this in the constraints file, any examples?Article: 113124
I think the distortion from using inverter and CLK180 is negligible in Virtex-4. If imverter an issue, here's another alternative to forward clock out from Virtex-4. Note that you always need to use ODDR to forward a clock out. Usually it's instantiated this way: ODDR TX_CLK_OUT_00(.Q(PRECLKOUT[0]), .C(CLK), .CE(1'b1), .D1(1'b1), .D2(1'b0), .R(1'b0), .S(1'b0)); Now you can also do this: ODDR TX_CLK_OUT_00(.Q(PRECLKOUT[0]), .C(CLK), .CE(1'b1), .D1(1'b0), .D2(1'b1), .R(1'b0), .S(1'b0)); Notice that I invert the D1 and D2 inputs? This causes 180 phase shift without changing the CLK input path, as D1 and D2 are logic inputs. -M Duane Clark wrote: > Frank Buss wrote: > > Alan Myler wrote: > > > >> Use an inverter? > > > > I don't think this will result in an exact 180 shifted signal at 100 MHz, > > because of the delay of the inverter, so using a DCM is a good idea. > > > > In virtually every place where the clock is used with X chips, the > inverter will be absorbed into the IOB/slice and will not result in > extra delay. Every FF, IO FF, BRAM, etc sticks a mux in front of the > clock pin, with one inverting and one non-inverting input. There is no > way to bypass them. > > The only consideration I can see when using the inverter method is > whether the clock is close to a 50% duty cycle.
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