Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 113100

Article: 113100
Subject: Re: Clock phase shift
From: "Jim Wu" <jimwu88NOOOSPAM@yahoo.com>
Date: 6 Dec 2006 07:07:21 -0800
Links: << >>  << T >>  << A >>
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
> Ashish


Article: 113101
Subject: Re: Clock phase shift
From: Frank Buss <fb@frank-buss.de>
Date: Wed, 6 Dec 2006 16:10:28 +0100
Links: << >>  << T >>  << A >>
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.de

Article: 113102
Subject: Re: Xilinx MPMC2 "External Ports" question
From: "ed_h" <ehenciak@gmail.com>
Date: 6 Dec 2006 07:28:39 -0800
Links: << >>  << T >>  << A >>

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




> 
> /Mikhail


Article: 113103
Subject: Re: Xilinx MPMC2 "External Ports" question
From: "ed_h" <ehenciak@gmail.com>
Date: 6 Dec 2006 07:30:59 -0800
Links: << >>  << T >>  << A >>

> 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





> 
> Antti


Article: 113104
Subject: Re: Xilinx MPMC2 "External Ports" question
From: "ed_h" <ehenciak@gmail.com>
Date: 6 Dec 2006 07:39:34 -0800
Links: << >>  << T >>  << A >>

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
> > > 
> > > Antti


Article: 113105
Subject: Re: Clock phase shift
From: "Ashish" <ashish.shringarpure@gmail.com>
Date: 6 Dec 2006 07:42:03 -0800
Links: << >>  << T >>  << A >>

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.

Ashish


Article: 113106
Subject: Re: Free Anydivider, Divide clock by any number
From: topweaver@hotmail.com
Date: 6 Dec 2006 08:03:35 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Usage of BUFIO in Virtex 4?
From: "Brandon Jasionowski" <killerhertz@gmail.com>
Date: 6 Dec 2006 08:12:05 -0800
Links: << >>  << T >>  << A >>
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: 113108
Subject: Re: Free Anydivider, Divide clock by any number
From: "Gabor" <gabor@alacron.com>
Date: 6 Dec 2006 08:58:39 -0800
Links: << >>  << T >>  << A >>

topweaver@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,
Gabor


Article: 113109
Subject: help with Xilinx LVDS syntax
From: "Morgan" <morgank@lanl.gov>
Date: 6 Dec 2006 09:02:09 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: EDK 8.2, MDM, and ChipScope....
From: "motty" <mottoblatto@yahoo.com>
Date: 6 Dec 2006 09:27:40 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Free Anydivider, Divide clock by any number
From: "Peter Alfke" <peter@xilinx.com>
Date: 6 Dec 2006 09:32:49 -0800
Links: << >>  << T >>  << A >>
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 Alfke


Article: 113112
Subject: Re: Free Anydivider, Divide clock by any number
From: acher@in.tum.de (Georg Acher)
Date: Wed, 6 Dec 2006 17:56:49 +0000 (UTC)
Links: << >>  << T >>  << A >>
"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: 113113
Subject: Re: help with Xilinx LVDS syntax
From: "davide" <davide@xilinx.com>
Date: Wed, 6 Dec 2006 10:06:13 -0800
Links: << >>  << T >>  << A >>
The 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
Subject: Re: EDK 8.2, MDM, and ChipScope....
From: "motty" <mottoblatto@yahoo.com>
Date: 6 Dec 2006 10:07:32 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Firmware for Xilinx USB cable
From: Eric Smith <eric@brouhaha.com>
Date: 06 Dec 2006 10:12:59 -0800
Links: << >>  << T >>  << A >>
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.gz

Article: 113116
Subject: Re: Clock phase shift
From: Duane Clark <junkmail@junkmail.com>
Date: Wed, 06 Dec 2006 18:19:30 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: EDK 8.2, MDM, and ChipScope....
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 6 Dec 2006 19:22:08 +0100
Links: << >>  << T >>  << A >>
"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



Article: 113118
Subject: Re: EDK 8.2, MDM, and ChipScope....
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 6 Dec 2006 19:38:03 +0100
Links: << >>  << T >>  << A >>
"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

Antti




Article: 113119
Subject: Re: Usage of BUFIO in Virtex 4?
From: "markus" <markus_1401@yahoo.com>
Date: 6 Dec 2006 10:43:36 -0800
Links: << >>  << T >>  << A >>
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 Velocity


Article: 113120
Subject: Re: Altera starter kits
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 07 Dec 2006 07:51:10 +1300
Links: << >>  << T >>  << A >>
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.

-jg




Article: 113121
Subject: Re: Clock phase shift
From: "Peter Alfke" <peter@xilinx.com>
Date: 6 Dec 2006 10:51:47 -0800
Links: << >>  << T >>  << A >>
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.
> 
> Ashish


Article: 113122
Subject: Re: Spartan-3A launched
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 07 Dec 2006 07:56:13 +1300
Links: << >>  << T >>  << A >>
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?

-jg


Article: 113123
Subject: How do I delay signal to pad?
From: John <seabass950@yahoo.com>
Date: Wed, 6 Dec 2006 10:59:57 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Clock phase shift
From: "markus" <markus_1401@yahoo.com>
Date: 6 Dec 2006 11:00:56 -0800
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search