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
2017JanFebMarApr2017

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 34200

Article: 34200
Subject: Re: Slowing PCI for FPGA
From: "clevin1234" <clevin1234@home.com>
Date: Thu, 16 Aug 2001 12:57:08 GMT
Links: << >>  << T >>  << A >>
  The best FPGA solution for PCI applications is offered by QuickLogic.
They have FPGA's with embedded PCI interfaces at reasonable prices. Unlike
other FPGA vendors, there is no charge for the PCI IP. They offer both
Target only (QL5030) and Master/Target (QL5332) 32bit 33 Mhz cores along
with a 64 bit 66 Mhz device (QL5064).  In addition to the PCI core, the
parts offer user logic gates that can be programmed using VHDL or Verilog.
QuickLogic offers free programmed samples through there WebAsic program and
you can get a 30 day Software evaluation license to use the tools. You
should check out their web site at www.quicklogic.com for additional
information.


"Joey Oravec" <joey@sun.science.wayne.edu> wrote in message
news:9lesog$f65$1@cwis-1.wayne.edu...
> Hi, surely somebody else has run into this before.
>
> I am doing a prototype with a PCI interface and there isn't a prayer of
> making it work at 25mhz bus transfer (my slowest machine available)
> without a lot of effort. What would you do to easily slow things down? I
> know DINI group has a card for $600 that will halve the PCI clock and
> another for $3k which is more flexible. There's PCI-PCI bridge IP
> available but that's also expensive.
>
> Unfortunately I'm cheap and I'm thinking there must be a better
> inexpensive solution. Any thoughts?
>
> --
>   O..O    Arcade machine collection:
>  (----)        http://www.science.wayne.edu/~joey/arcade/
> ( >__< )  IRC - EFNet #rgvac: demigod2k
> ^^ ~~ ^^



Article: 34201
Subject: Re: Internal clock skew when using DLL
From: "fred" <x@y.z>
Date: Thu, 16 Aug 2001 14:17:38 +0100
Links: << >>  << T >>  << A >>

Peter Alfke <peter.alfke@xilinx.com> wrote in message
news:3B7AAEDB.47875520@xilinx.com...
> Since your two clock frequencies are fundamentally phase-coherent, albeit
> perhaps with a certain unpredictable tolerance, you can cross the
clock-domain
> boundary simply by using the opposite edge of the higher frequency clock.
This
> does cut into your timing budget, but is safe otherwise.
>
> Peter Alfke
>
Peter,

I imagine this is the safest bet. Are you being particularly cautious
because of the way this guy's clocks are arranged wrt the dlls - they don't
look unusual to me. I ask because several XAPPs do not seem to take this
ultra safe approach eg. XAPP214 p4 does not appear to take any 1/4 phase
precautions also previous (Xilinx) answers in this group have implied that
same phase data/control transfer is perfectly ok.

A couple of tick box answers to clarify:

1. [ ] Are you mad! Don't ever cross between 1x & 2x domains w/o 1/4 phase
precautions

2. [ ] Only cross between domains in same phase when using dlls in
mode/configuration X

3. [ ] Crossing between domains in same phase is possible but 1&2x clocks
must be on the same quadrant/branch of the clock tree

4. [ ] <enter own reply here>

Regards,

Fred



Article: 34202
Subject: Re: Xilinx WebPack .UCF file
From: jmrice@ntlworld.com (Martin Rice)
Date: 16 Aug 2001 06:38:16 -0700
Links: << >>  << T >>  << A >>
Mark Borgerson <mark@oes.to> wrote in message news:<3B75CFBC.72D93B07@oes.to>...
> I've put together my first design targeting a Coolrunner CPLD and
> gotten it to compile and generate the output files.  I would
> now like to edit the .ucf file so that I can arrange pins
> to simplify layout on my PCB.  Apparently, there are two
> options:
> 
> 1. Generate the default .ucf file  with the 'lock pins' process, then
> edit the .ucf file as text with notepad.  The problem I'm having
> is that if I go back and click on Edit UCF file under User
> Constraints,  Notepad opens with a blank file in the My Documents
> directory.  There is also a XILPerl window showing a file not 
> found error.  Have I missed the setup of a Path variable or 
> something of this sort??
> 
> 2.  If I manually open the Constraints Editor and try to open
> the default UCF file I generated, I also need to provide the
> name of a .NGD file.  But my design process so far has not
> produced a .NGD file!  Have I missed a step somewhere??
> 
> Any help or hints would be greatly appreciated.  The web pack tools
> seem to be great stuff for free tools,  but it seems that there
> is a definite learning curve!  
> 
> Mark Borgerson


XESS corporation provide a tutorial on using Webpack, that you may
find useful. It's a pdf file.  Find it on the www.xess.com website,
click tutorials and download Introduction to Webpack 3.1.

You may even find my book some use - there's a walkthrough on using
Webpack with ABEL, targeted at Coolrunner.

I find that, following a Lock Pins command, I *do* get a ucf file that
I can edit.  It's in the folder that I specified when setting up the
project.  It's just possible that My Documents is not a suitable place
for your project.  Some of the software doesn't like spaces in folder
names!  If possible stick to DOS names.

Good luck.  Once you get your first design downloaded to real hardware
it's all plain sailing!!!

Article: 34203
Subject: Re: Replication of FFs in Xilinx XC4000
From: Magnus Homann <d0asta@licia.dtek.chalmers.se>
Date: 16 Aug 2001 16:01:41 +0200
Links: << >>  << T >>  << A >>
hmurray-nospam@megapathdsl.net (Hal Murray) writes:

> >We are working on a design in an XC4000 about 64K gates and are having a
> >problem with register replication. The P$R tool is replicating a FF that
> >is the critical element of a cross clock domain synchronizer. I call
> >this a "bad thing". 
> 
> Did you spot this by eyeball?  Or did you encounter a problem and track
> it back?
> 
> The normal synchronizer setup is a FF, a short wire, then another FF,
> with both FFs running on the same clock.
> 
> So I assume it replicated the second FF.

I thought his comment was equivalent to replicating the first FF. But
Im not sure what he tried to do anyway.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 34204
Subject: Re: Reconfigurable Computational Accelerator
From: Luke Roth <roth@harp.cse.psu.edu>
Date: Thu, 16 Aug 2001 10:13:37 -0400
Links: << >>  << T >>  << A >>
	The easiest way we found to memory map the device is to remain
inactive during the initial bootup of the BIOS & OS, and then map the
accelerator card into memory right after the standard SDRAM address space.
The limitation here is that 1) the sdram on the card is only usable by
accelerator-aware applications, and 2) the accelerator card must be
plugged into a memory slot on the motherboard numbered higher than the
rest of the standard memory modules.  Both of these aren't big limitations
for us.
	The biggest problem is that we'll need a slightly different driver
for every major chipset we use the card with; right now we've standardized
on the Intel 440BX chipset since it is so ubiquitous, cheap, and
relatively high-performance.  We are also doing all of our development in
Linux, which makes writing new drivers pretty easy.
	Luke
On Thu, 16 Aug 2001, Dave Feustel wrote:

> This looks interesting. How do you deal with cpu memory mapping?
>
> "Luke Roth" <roth@harp.cse.psu.edu> wrote in message
> news:Pine.SOL.4.33.0108151347090.7311-100000@harp.cse.psu.edu...
> > Alternatively, as part of my research (I'm a grad student at Penn
> > State) we're building an FPGA accelerator card which resides on the SDRAM
> > memory bus.  Much faster than PCI (up to 133MHz x 64 bits vs 33MHz x 32
> > bits) and _much_ lower latency.  Our current board has a Virtex XCV300 and
> > 64MB of SDRAM, sufficient for quite a few interesting applications.
> > There are some limitations with this approach - for example, there
> > are no nice interrupt facilities as available on the PCI bus - but other
> > than that it seems like a great solution.  We're testing our first board
> > now, it will interesting to see what kind of performance we can acheive
> > with this method.  If you're interested in some more (admittedly a bit
> > outdated) information, check out www.cedcc.psu.edu/smartdimm/
> > Luke Roth
> >
> > On Wed, 15 Aug 2001, Dave Feustel wrote:
> >
> > > I've been thinking about the i/o interface obstacle that exists between
> > > cpu and pci-bus mediated fpga accelerators for a couple of days now.
> > > I have come to the conclusion that the way to have *really* fast
> > > fpga accelerators is to put a hardwired cpu on the fpga chip along
> > > with the accelerator logic and make the entire application run
> > > directly from the fpga. You now can get fpgas with ARM, Powerpc
> > > and or other custom cpus preprogrammed into them and still have
> > > lots of room for your accelerator logic. IP cores for almost every
> > > commonly used peripheral are available to be incorporated onto
> > > the fpga chip - leave off the interfaces you don't need.
> > > Put the whole thing on a PCI card and plug it into your pc to
> > > make development easier(download through the pci bus).
> > >
> > > "Mike Butts" <mbutts@realizer.com> wrote in message
> news:3B758FB0.B98CA76A@realizer.com...
> > > > Dave Feustel wrote:
> > > > > The real short version is
> > > > > that the PCI bus interface is so slow relative to the
> > > > > speeds of the cpu and accelerator that it usually
> > > > > isn't worth adding an accelerator if the interface
> > > > > is via the PCI bus.
> > > >
> > > > This is often, but not necessarily true.  Accelerator architecture
> > > > totally depends on your application.  This is exactly what Philip
> > > > meant by "how long should a piece of string be".  Not ridicule,
> > > > just maybe a little drier wit than we're used to...
> > > >
> > > > If your application depends on lots of back-and-forth
> > > > between the host and the card in its core kernel, PCI is usually
> > > > a barrier.  Many early research projects in this field found this
> > > > out the hard way.  It's not the bandwidth that matters in such
> > > > cases, it's the latency, the round-trip time for a single operation.
> > > >
> > > > PCI, especially as implemented in modern PCs and workstations,
> > > > can be very bad at that.  Mark Shand gave an excellent and
> > > > most useful paper about this at FCCM '97, that anyone using PCI
> > > > must study:
> > > > Laurent Moll and Mark Shand. Systems performance measurement on
> > > > PCI Pamette. In FPGAs for Custom Computing Machines
> > > >      (FCCM'97). IEEE, April 1997.
> > > > http://www.research.compaq.com/SRC/staff/shand/bib.html
> > > >
> > > > If, on the other hand, your app is a self-contained kernel that
> > > > grinds away mostly on its own, PCI can be fine.  Often signal
> > > > processing apps are like this, with the signal I/O direct to
> > > > the card.
> > > >
> > > > I believe a very big win for reconfigurable computing is for
> > > > apps that demand lots of parallel memory bandwidth, since the
> > > > processor-memory bottleneck is so fundamental to conventional
> > > > computing.  I'm working with a project at Oregon Graduate Institute
> > > > lately to develop a neural network accelerator.  In our case, it's all
> > > > about memory bandwidth.  I/O to/from the host is orders of
> > > > magnitude less.  We're planning a PCI card with as many SDRAM DIMMs
> > > > as we can hook up to some FPGAs for them to grind away on matrix-
> > > > vector multiplies in parallel at 100 MHz.  PCI will just control
> > > > and program the card, and feed inputs and collect results at a
> > > > lazy and latency-insensitive pace.
> > > >
> > > > So tell us more about your application, and maybe we can give you
> > > > better advice.
> > > >
> > > >    --Mike
> > >
> > >
> > >
> >
>
>
>


Article: 34205
Subject: Virtex Pro Info
From: "Dave Feustel" <dfeustel1@home.com>
Date: Thu, 16 Aug 2001 14:16:27 GMT
Links: << >>  << T >>  << A >>
Is there any publically available info on
Xilinx's upcoming Virtex Pro series of FPGAs?

Thanks.



Article: 34206
Subject: Re: Help with ACEX1K100 device
From: "Gerald B" <mdesigns@ipa.net>
Date: Thu, 16 Aug 2001 09:23:16 -0500
Links: << >>  << T >>  << A >>
I recently worked on a Acex 1K30 design.  I found Altera's app. note AN116
"Configuring APEX 20K, FLEX 10K, & FLEX 6000 Devices" to be very helpful.  I
have not looked at AN116 for the last few months, but the version I last
down loaded had not been updated for the ACEX family yet.  This app. note is
still helpful since ACEX is basically the same as the FLEX 10K parts.  Table
24 in the AN116 indicates whether or not the pins are available in User
Mode.  http://www.altera.com/literature/an/an116.pdf

Hope this helps.  Gerald

"Andrew Gray" <s9813479@student.up.ac.za> wrote in message
news:997947985.88785@nntp.up.ac.za...
> Hi
>
> Can anyone tell me what the following pins are used for when they are not
> used as user IO pins:
>
> nCEO
> CS
> nCS
> nRS
> nWS
> DEV_OE
> DEV_nCLR
> INIT_DONE
> RDY_nBSY
>
> Thank You
>
> Andrew Gray
>
>
>



Article: 34207
Subject: Re: Internal clock skew when using DLL
From: "Jamie Sanderson" <jamie@nortelnetworks.com>
Date: Thu, 16 Aug 2001 10:32:50 -0400
Links: << >>  << T >>  << A >>
There are many configurations that "work". My concern is whether or not they
are "safe". In the configuration you describe, the net I'd be using to drive
logic and the net used to provide feedback are not the same. Therefore, the
DLL will not be able to account for skew on the net I'm using.

It's very hard to imagine it even being possible, but what if the 66 MHz net
were so heavily loaded that it wiped out the 1/4 cycle of clock skew?

Anyhow, thanks for the suggestion nonetheless. It would save me the work of
adjusting the clock polarity elsewhere in the design, and Virtex 2 is more
generous with BUFG(MUX) so it's okay to use an extra one.

Cheers,
Jamie

"Philip Freidin" <philip@fliptronics.com> wrote in message
news:dhqmnt8oii8p0bel5taqqnj4dffh9sacdb@4ax.com...
> I created a test design to see what could be done. Here is a possible
> solution:
>
> 33MHz mhz goes thru IBUFG then BUFG to be your clk_33
>
> Output of IBUFG also goes to DCM CLKIN
>
> DCM CLK2X goes to a BUFG, its output goes to CLKFB
> DCM CLK2X180 goes to a BUFG, its output is your somewhat delayed CLK_66
>
> (assume that the two BUFGs are reasonabbly matched. Remember that you
> will be adding more loads to the CLK_66 net)
>
> I ran the design successfully through M3.3.08i
>
> Philip




Article: 34208
Subject: Re: fpga with the smallest i/o setup and hold requirement
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 16 Aug 2001 07:47:14 -0700
Links: << >>  << T >>  << A >>
Dave,

There is a whole range of designs/cores in process.

See the TNF announcement:

 http://www.xilinx.com/terabit/index.htm

Every single interface to all of those company's logos (parts) are DDR.

Austin

Dave Feustel wrote:

> DDR interfaces to Spartan/Virtex chips would seem to be sufficiently
> common that a reference design would be worth while.
> Is there such a reference design in the works?
>
> Thanks.
>
> "Austin Lesea" <austin.lesea@xilinx.com> wrote in message
> news:3B7AF3FA.4A934374@xilinx.com...
> > Adrianus,
> >
> > Virtex II is (less than) 300 ps for the DDR setup and hold in the clock
> > forwarded case using the DCM.  The DDR clock forwarded interface requires
> > a combination of system features to be used, and we just finished
> > characterizing the combinations.
> >
> > For the non-clock forwarded DDR case, the larger numbers apply.
> >
> > We have released a DDR spec available to the FAE's to cover these
> > interfaces.
> >
> > Single ended HSTL is another matter.  250 MHz is 500 Mb/s, and HSTL isn't
> > the best interface to use at these frequencies.  Signal integrity is
> > going to be a PhD thesis, and coupling, noise, and jitter will be a tough
> > system design road to travel down.
> >
> > I suggest you run some simple IBIS simulations to look at duty cycle, and
> > rise and fall times of the HSTL standards at this frequency.
> >
> > Austin
> > Xilinx FPGA Lab
> >
> > Adrianus wrote:
> >
> > > Hi,
> > >
> > > I'm looking for a device that has very small setup and hold
> > > requirement. I'm trying to use this device to capture a 250 MHz DDR
> > > bus with single ended HSTL level. Ideally, I would like the device to
> > > require not more than 300 ps of setup and hold window. My gross data
> > > window is 2ns, but after the driver clk to data skew, edge rate
> > > effect, board effect, etc... I don't have much margin left.
> > >
> > > It seems to me that Xilinx Virtex II is pretty decent, it is spec'ed
> > > at 690 ps of setup and 0 hold. Does anyone know any other device
> > > that's better??
> > >
> > > Any help would be greatly appreciated!
> > >
> > > THanks,
> > > Adrianus
> >


Article: 34209
Subject: Re: Virtex-II and 5V devices
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 16 Aug 2001 07:53:49 -0700
Links: << >>  << T >>  << A >>
Marc,

There is an answer record for this that suggests a 120 ohm reisistor to keep
the current into the io pin at less than 10 ms.

I suggest you simulate the pair of chips in IBIS, no resistor at all could be
the result if the current is already less than 10 mA.

Many 5V parts use a stacked nmos output structure for TTL compatibility, and
can not source much current at all.  If the output is full cmos, then a
resistor will be required.  Its value is related to the maximum source
current of the output at 3.3 V.  This is in the IBIS model as the IV curve,
and can be directly viewed for the strong/fast/cold operating
voltage/process/temperature corner, or used in the simulation automatically.

Austin

Marc Battyani wrote:

> There is a Xilinx app note (vtt002) about using 5V devices with Virtex
> devices but it states explicitely that this does not work with Virtex-II.
>
> I need to connect some 5V AD devices to a Virtex-II. The ADs are TTL
> compatible so no pb to drive them from the Virtex-II but I have to read
> values form these ADs.
>
> So what are the solutions for this ? (small ones please...)
>
> Thanks
>
> Marc Battyani


Article: 34210
Subject: Re: Reconfigurable Computational Accelerator
From: "Dave Feustel" <dfeustel1@home.com>
Date: Thu, 16 Aug 2001 14:57:50 GMT
Links: << >>  << T >>  << A >>
Does paging cause any problems?

Is there a mailing list that I could subscribe to and
follow your progress?

Dave

"Luke Roth" <roth@harp.cse.psu.edu> wrote in message
news:Pine.SOL.4.33.0108161004300.1797-100000@harp.cse.psu.edu...
> The easiest way we found to memory map the device is to remain
> inactive during the initial bootup of the BIOS & OS, and then map the
> accelerator card into memory right after the standard SDRAM address space.
> The limitation here is that 1) the sdram on the card is only usable by
> accelerator-aware applications, and 2) the accelerator card must be
> plugged into a memory slot on the motherboard numbered higher than the
> rest of the standard memory modules.  Both of these aren't big limitations
> for us.
> The biggest problem is that we'll need a slightly different driver
> for every major chipset we use the card with; right now we've standardized
> on the Intel 440BX chipset since it is so ubiquitous, cheap, and
> relatively high-performance.  We are also doing all of our development in
> Linux, which makes writing new drivers pretty easy.
> Luke
> On Thu, 16 Aug 2001, Dave Feustel wrote:
>
> > This looks interesting. How do you deal with cpu memory mapping?




Article: 34211
Subject: Xilinx Floorplanner in batch mode?
From: "Olaf Reichenbaecher" <Olaf.Reichenbaecher@sci-worx.com>
Date: Thu, 16 Aug 2001 08:12:50 -0700
Links: << >>  << T >>  << A >>
hello all,

yes, this really sounds like a stupid question. but on a second thought may be not:
i have a VHDL-design which is currently under verification in RTL simulations. in parallel i have generated a bitstream for the first tests in real hardware. in order to achieve a reasonable timing on the FPGA (Xilinx Virtex) i created a floorplan using area constraints for certain blocks/hierarchies in the design.
while the design is subject to modifications on RTL during the verification i need to generate new bitstreams for the hardware tests every now an then. the netlist every time i do a new synthesis differs that much from the previous version that i am not able to re-use the floorplan data as they are. unfortunately my synthesis-tool fatals when i try to do a sort of incremental synthesis, i have to generate a complete netlist every time. so i need to update the old floorplan with the new netlist which basically is a task to be done interactively / manually. all the rest of the flow (from modified RTL code to bitstream generation) is make-automated. but i have to interrupt this processing in order to do some, always the same mouse-clicks in the floorplanner-gui just to restart the same automated process afterwards.
so, is there a possibility to run the Xilinx floorplanner (m3.1iSP8) in batch mode? i don't want to modify or even create the floorplan itself, i just want to update an existing one with a new netlist.

any help is appreciated.

cheers!

  olaf

Article: 34212
Subject: Re: DPLL frequency synthesis
From: John_H <johnhandwork@mail.com>
Date: Thu, 16 Aug 2001 15:55:05 GMT
Links: << >>  << T >>  << A >>
How about just an accumulator?  Continue to add the fraction of full-scale
corresponding to your frequency ratio and you could use the MSbit of the
accumulator as your clock (or use the rollover as a clock enable).  Since
you're working from 2.95MHz to 4.26MHz, your accumulator values would be about
.085 to .059 of full scal when clocked by 50MHz.  How precise does your
frequency need to be?  That will determine the size of your accumulator.

You'll get a little jitter on your clock (+/- 10nS max) but it sounds like
that might be a non-issue for you.

Pierre de Vos wrote:

> Hi,
>
> I need to to generate a synthesised frequency of Fin * 65536 where  45Hz <
> Fin < 65Hz.  Does anybody know of a VHDL core that can do this.  I have
> FLEX6016, reference CLK=50MHz.
>
> Regards
> Pierre


Article: 34213
Subject: Re: Internal clock skew when using DLL
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Thu, 16 Aug 2001 18:08:52 +0200
Links: << >>  << T >>  << A >>
Jamie Sanderson schrieb:
> 
> Hi;
> 
> I have a question regarding the DLL and clock to clock skew with Xilinx
> Virtex2 devices. I have two groups of logic which I want to run at different
> speeds. One group is at 33 MHz, and the clock net is driven without using a
> DLL (ibufg directly to bufg). This is defined in their PCI core.

> The other logic would benefit from running at a higher speed, but I want to
> avoid any metastability issues with crossing clock domains. My questions are

We discussed this some time ago. Conclusion was.

Use the DLL to double the clock BUT dont transfer datas from one clock
domain to the other on the same clock edge. Because when the clock nets
are loaded very unequal, skew can be an issue, even with the DLL.
This is a advice from Ray Andraka. He can explain this more detailed.

> as follows: Should I feed the DLL using the bufg output, or should I tap
> into the ibufg output? Secondly, will the software automatically account for

Feed it with the first BUFG output, because you want to phase align to
this clock net.

> any skew between the clock nets? In other words, will it make sure that
> setup/hold times are met when crossing from a register on the 33 MHz domain
> and the 33*n MHz domain? Or, do I have to somehow figure out what skew is

AFAIK NO.

> and write an appropriate constraint? Finally, does it matter if I were using
> the 2x DLL output, as opposed to the frequency synthesis output?

Hmm, should be no difference.

-- 
MFG
Falk



Article: 34214
Subject: Re: Xilinx Floorplanner in batch mode?
From: Steven Derrien <sderrien@irisa.fr>
Date: Thu, 16 Aug 2001 18:15:17 +0200
Links: << >>  << T >>  << A >>


Olaf Reichenbaecher wrote:
> 
> hello all,
> 
> yes, this really sounds like a stupid question. but on a second thought may be not:
> i have a VHDL-design which is currently under verification in RTL simulations. in parallel i have generated a bitstream for the first tests in real hardware. in order to achieve a reasonable timing on the FPGA (Xilinx Virtex) i created a floorplan using area constraints for certain blocks/hierarchies in the design.
> while the design is subject to modifications on RTL during the verification i need to generate new bitstreams for the hardware tests every now an then. the netlist every time i do a new synthesis differs that much from the previous version that i am not able to re-use the floorplan data as they are. unfortunately my synthesis-tool fatals when i try to do a sort of incremental synthesis, i have to generate a complete netlist every time. so i need to update the old floorplan with the new netlist which basically is a task to be done interactively / manually. all the rest of the flow (from modified RTL code to bitstream generation) is make-automated. but i have to interrupt this processing in order to do some, always the same mouse-clicks in the floorplanner-gui just to restart the same automated process afterwards.
> so, is there a possibility to run the Xilinx floorplanner (m3.1iSP8) in batch mode? i don't want to modify or even create the floorplan itself, i just want to update an existing one with a new netlist.
> 
> any help is appreciated.
> 
> cheers!
> 
>   olaf

I'm not sure it can really help you, but you can do a manual
floorplanning using wildcard in UCF files, just define some instance
group using the area group command (see axemple below).

Of course it requires a non flattened netlist so that instances names
reflect the orginal
hierachy of your design.

Here is an example :

INST TARGET/PROC/PE_3/* AREA_GROUP = PE_3_GRP;
AREA_GROUP PE_3_GRP COMPRESSION = 2;
AREA_GROUP PE_3_GRP RANGE = CLB_R8C55:CLB_R19C63 ;

this will map all primitives (LUT,DFFS,etc) of the module
TARGET/PROC/PE_3 
to the CLB area CLB_R8C55:CLB_R19C63.

Hope it can help.

steven


Steven

Article: 34215
Subject: Re: Internal clock skew when using DLL
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 16 Aug 2001 10:05:52 -0700
Links: << >>  << T >>  << A >>

--------------15D9D941924A7B1912A0F910
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Philip,

I was on a call today with a customer who needs a X2, X3, and a X4 clock, both
internally, and externally.  And, they had to transfer data between the three new
clock domains, both internally, and externally.

By the time they were done dreaming, they had used nine DCM's, multiple FIFO's,
(just to tranfer the internal data) and I began to get a little nervous.  Not that
it couldn't work, I am sure with the proper timing constraints it would eventually
work, but that they were adding unnecessary complexity to a simple problem.

Whatever happened to using the x4 clock as the source (an external oscillator was
being used at x1 anyway), and use clock enables everywhere, and keep the thing
synchronous?  Totally synchronous design = best guarantee of success!

Not that DCM's aren't great, but why use a new featured when the old way is probably
still the best way, especially since the whole thing was synchronous at the X4
rate?  With a totally synchronous design, they would still get to use the DCM's for
the CLKDV /2, /3 outputs to control the clock enables.  They would still need them
to deskew the external clock outputs.

I can understand using the DCM to deskew clocks, control phase thru the variable
fine phase shift feature, or generate a 7/8, or 17/13 clock for a turbo codec.

Just because it is there, doesn't mean you have to use it ....

Austin

Philip Freidin wrote:

> I created a test design to see what could be done. Here is a possible
> solution:
>
> 33MHz mhz goes thru IBUFG then BUFG to be your clk_33
>
> Output of IBUFG also goes to DCM CLKIN
>
> DCM CLK2X goes to a BUFG, its output goes to CLKFB
> DCM CLK2X180 goes to a BUFG, its output is your somewhat delayed CLK_66
>
> (assume that the two BUFGs are reasonabbly matched. Remember that you
> will be adding more loads to the CLK_66 net)
>
> I ran the design successfully through M3.3.08i
>
> Philip
>
> On Wed, 15 Aug 2001 14:06:36 -0400, "Jamie Sanderson" <jamie@nortelnetworks.com>
> wrote:
> >"Jamie Sanderson" <jamie@nortelnetworks.com> wrote in message
> >news:9ledgn$gb5$1@bcarh8ab.ca.nortel.com...
> >
> >> I think what I'll do is use the CLK2X180 output, instead of CLK2X. I think
> >> that allows me to use rising edge clocks everywhere, while providing a
> >> quarter clock period of setup/hold between the clock domains.
> >
> >Hmm, this gives me a mapper error
> >
> >ERROR:MapLib:326 - DCM symbol "dcm0" (output signal=slow2x_clk) CLKFB is not
> >
> >driven by the CLK0 or CLK2X pin of the same DCM.
> >
> >Errors found during the mapping phase. Output files will not be written.
> >
> >That's annoying... Back to the drawing board.
> >
> >
>
> Philip Freidin
> Fliptronics

--------------15D9D941924A7B1912A0F910
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Philip,
<p>I was on a call today with a customer who needs a X2, X3, and a X4 clock,
both internally, and externally.&nbsp; And, they had to transfer data between
the three new clock domains, both internally, and externally.
<p>By the time they were done dreaming, they had used nine DCM's, multiple
FIFO's, (just to tranfer the internal data) and I began to get a little
nervous.&nbsp; Not that it couldn't work, I am sure with the proper timing
constraints it would eventually work, but that they were adding unnecessary
complexity to a simple problem.
<p>Whatever happened to using the x4 clock as the source (an external oscillator
was being used at x1 anyway), and use clock enables everywhere, and keep
the thing synchronous?&nbsp; Totally synchronous design = best guarantee
of success!
<p>Not that DCM's aren't great, but why use a new featured when the old
way is probably still the best way, especially since the whole thing was
synchronous at the X4 rate?&nbsp; With a totally synchronous design, they
would still get to use the DCM's for the CLKDV /2, /3 outputs to control
the clock enables.&nbsp; They would still need them to deskew the external
clock outputs.
<p>I can understand using the DCM to deskew clocks, control phase thru
the variable fine phase shift feature, or generate a 7/8, or 17/13 clock
for a turbo codec.
<p>Just because it is there, doesn't mean you <b>have</b> to use it ....
<p>Austin
<p>Philip Freidin wrote:
<blockquote TYPE=CITE>I created a test design to see what could be done.
Here is a possible
<br>solution:
<p>33MHz mhz goes thru IBUFG then BUFG to be your clk_33
<p>Output of IBUFG also goes to DCM CLKIN
<p>DCM CLK2X goes to a BUFG, its output goes to CLKFB
<br>DCM CLK2X180 goes to a BUFG, its output is your somewhat delayed CLK_66
<p>(assume that the two BUFGs are reasonabbly matched. Remember that you
<br>will be adding more loads to the CLK_66 net)
<p>I ran the design successfully through M3.3.08i
<p>Philip
<p>On Wed, 15 Aug 2001 14:06:36 -0400, "Jamie Sanderson" &lt;jamie@nortelnetworks.com>
<br>wrote:
<br>>"Jamie Sanderson" &lt;jamie@nortelnetworks.com> wrote in message
<br>><a href="news:9ledgn$gb5$1@bcarh8ab.ca.nortel.com">news:9ledgn$gb5$1@bcarh8ab.ca.nortel.com</a>...
<br>>
<br>>> I think what I'll do is use the CLK2X180 output, instead of CLK2X.
I think
<br>>> that allows me to use rising edge clocks everywhere, while providing
a
<br>>> quarter clock period of setup/hold between the clock domains.
<br>>
<br>>Hmm, this gives me a mapper error
<br>>
<br>>ERROR:MapLib:326 - DCM symbol "dcm0" (output signal=slow2x_clk) CLKFB
is not
<br>>
<br>>driven by the CLK0 or CLK2X pin of the same DCM.
<br>>
<br>>Errors found during the mapping phase. Output files will not be written.
<br>>
<br>>That's annoying... Back to the drawing board.
<br>>
<br>>
<p>Philip Freidin
<br>Fliptronics</blockquote>
</html>

--------------15D9D941924A7B1912A0F910--


Article: 34216
Subject: Re: Slowing PCI for FPGA
From: "Austin Franklin" <austin@darkroom99.com>
Date: Thu, 16 Aug 2001 13:53:54 -0400
Links: << >>  << T >>  << A >>
>   The best FPGA solution for PCI applications is offered by QuickLogic.

I don't know if it's "the best", but it certainly is very good...but has one
major drawback..those parts are expensive and they are OTP.




Article: 34217
Subject: Re: Slowing PCI for FPGA
From: "Austin Franklin" <austin@darkroom99.com>
Date: Thu, 16 Aug 2001 13:55:15 -0400
Links: << >>  << T >>  << A >>
There is really no reason you can not make 25MHz, much less 33MHz with your
FPGA...if you're in an appropriate part, and your logic is "correct".

What part are you using, and what is causing your PCI interface to be so
slow?  Please be very specific in this answer if you could, and I might be
able to help you.

"Joey Oravec" <joey@sun.science.wayne.edu> wrote in message
news:9lesog$f65$1@cwis-1.wayne.edu...
> Hi, surely somebody else has run into this before.
>
> I am doing a prototype with a PCI interface and there isn't a prayer of
> making it work at 25mhz bus transfer (my slowest machine available)
> without a lot of effort. What would you do to easily slow things down? I
> know DINI group has a card for $600 that will halve the PCI clock and
> another for $3k which is more flexible. There's PCI-PCI bridge IP
> available but that's also expensive.
>
> Unfortunately I'm cheap and I'm thinking there must be a better
> inexpensive solution. Any thoughts?
>
> --
>   O..O    Arcade machine collection:
>  (----)        http://www.science.wayne.edu/~joey/arcade/
> ( >__< )  IRC - EFNet #rgvac: demigod2k
> ^^ ~~ ^^



Article: 34218
Subject: Re: Slowing PCI for FPGA
From: "Austin Franklin" <austin@darkroom99.com>
Date: Thu, 16 Aug 2001 13:56:45 -0400
Links: << >>  << T >>  << A >>
> The safest option would be to get a motherboard that can be underclocked
in
> BIOS. I've successfully used the Abit SA6R, setting FSB to 60 MHz, clock
> ratio to 4:4:1, resulting in 15 MHz PCI.
>
> Alternatively, you can check if you motherboard is supported by CPUCooL
> (http://www.podien.onlinehome.de/). It can change the PLL settings on many
> motherboard, even if the BIOS doesn't support that. Even better, it can be
> changed *runtime*, thus you can throttle your clock without rebooting
> in-between each attempt (as long as you don't lock up the system.....)
>
> Regards,
> - Olaf

That is very good information, Olaf.  Thank you.




Article: 34219
Subject: Re: Virtex-II and 5V devices
From: "Marc Battyani" <Marc.Battyani@fractalconcept.com>
Date: Thu, 16 Aug 2001 21:35:43 +0200
Links: << >>  << T >>  << A >>

"Austin Lesea" <austin.lesea@xilinx.com> wrote
> Marc,
>
> There is an answer record for this that suggests a 120 ohm reisistor to
keep
> the current into the io pin at less than 10 ms.
>
> I suggest you simulate the pair of chips in IBIS, no resistor at all could
be
> the result if the current is already less than 10 mA.
>
> Many 5V parts use a stacked nmos output structure for TTL compatibility,
and
> can not source much current at all.  If the output is full cmos, then a
> resistor will be required.  Its value is related to the maximum source
> current of the output at 3.3 V.  This is in the IBIS model as the IV
curve,
> and can be directly viewed for the strong/fast/cold operating
> voltage/process/temperature corner, or used in the simulation
automatically.

Thanks, a resistor is fine for me. But why do you state in vtt002.pdf that :
"Note: This does not apply to the Virtex-II family of devices, which are 3.3
V compliant only."

Is there another app note for the Virtex-II ?

Marc






Article: 34220
Subject: Re: Virtex Pro Info
From: Philip Freidin <philip@fliptronics.com>
Date: Thu, 16 Aug 2001 13:00:48 -0700
Links: << >>  << T >>  << A >>
Go to http://www.xilinx.com/events/seminars/xtremedsp.htm

Follow the link to "Go to Video On Demand Page*"

   (you will need to be registered, it's free)

Then download the PDF for section 7. The last bunch of pages
covers V-II-P

Philip

On Thu, 16 Aug 2001 14:16:27 GMT, "Dave Feustel" <dfeustel1@home.com> wrote:
>Is there any publically available info on
>Xilinx's upcoming Virtex Pro series of FPGAs?
>
>Thanks.
>

Philip Freidin
Fliptronics

Article: 34221
Subject: Re: Virtex-II and 5V devices
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Thu, 16 Aug 2001 20:08:24 GMT
Links: << >>  << T >>  << A >>
Marc,

There are a bunch of parts one can use to bridge the 5V <--> 3.3V gap. 
Basically, they're the usual sort of buffer types: '245, '541, '573,
'573, '823.  They're in various logic families: LPT, FCT, etc.  See the
Pericom or IDT web sites for examples.  Look for devices that have 3.3V
power rails and are 5V tolerant.

-andy 

Marc Battyani wrote:
> 
> There is a Xilinx app note (vtt002) about using 5V devices with Virtex
> devices but it states explicitely that this does not work with Virtex-II.
> 
> I need to connect some 5V AD devices to a Virtex-II. The ADs are TTL
> compatible so no pb to drive them from the Virtex-II but I have to read
> values form these ADs.
> 
> So what are the solutions for this ? (small ones please...)
> 
> Thanks
> 
> Marc Battyani

Article: 34222
Subject: Re: Xilinx WebPack .UCF file
From: Mark Borgerson <mark@oes.to>
Date: Thu, 16 Aug 2001 20:19:44 GMT
Links: << >>  << T >>  << A >>


Martin Rice wrote:
> 
<<SNIP>> 
> XESS corporation provide a tutorial on using Webpack, that you may
> find useful. It's a pdf file.  Find it on the www.xess.com website,
> click tutorials and download Introduction to Webpack 3.1.
> 
> You may even find my book some use - there's a walkthrough on using
> Webpack with ABEL, targeted at Coolrunner.
> 
> I find that, following a Lock Pins command, I *do* get a ucf file that
> I can edit.  It's in the folder that I specified when setting up the
> project.  It's just possible that My Documents is not a suitable place
> for your project.  Some of the software doesn't like spaces in folder
> names!  If possible stick to DOS names.

I got the .ucf file all right.  The problem was that when I click
the 'edit ucf file' entry in the project manager, it trys to
find the file in 'my documents'.  My project lives in a folder
in the XILINX folder.    I did find it was simply easier to
open the folder in the windows explorer and double-click the
.ucf file.  Notepad opens with the file and I'm set to go.
> 
> Good luck.  Once you get your first design downloaded to real hardware
> it's all plain sailing!!!

I'm looking forward to that moment!  The parallel port programmer
and first 5 chips are here from Xilinx.  The PC board should be
here Monday.   It was a blast doing the PCB layout!   After I
got the schematic together,  I loaded the netlist and looked
at the rats nest while rotating the part.  Massive net crossovers!
So I edited the  CPLD pin assignments to simplify the layout and
got the PCB laid out in about 1/3 the time it took to do the
same job with SSI and MSI parts.  Parts cost will be down by about
50% over the MSI solution, too!   THIS IS COOL STUFF!  <VBG>

I'll look over the XESS tutorial.  Thanks for the pointer.

Mark Borgerson

Article: 34223
Subject: Re: Slowing PCI for FPGA
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Thu, 16 Aug 2001 20:21:59 GMT
Links: << >>  << T >>  << A >>
Kevin Brace wrote:
>         I recently fired up Insight Electronics Spartan II PCI
> development board (http://www.insight-electronics.com/solutions/kits/xilinx/spartan-iipci.html)
> with my own PCI IP core (I didn't use Xilinx's PCI IP core), and even
> though the timing analyzer told me that some of the input signals
> require around 12ns Tsu, and around 15ns Tval for output signals, the
> board was recognized as a PCI device by the BIOS, and Windows 98
> detected the PCI card automatically at startup.
> This means that the PCI card with my PCI IP core worked even though
> the timings were not being met.
> The motherboard had 430TX chipset on it, and the PCI bus ran at 33MHz.
> My theory that the reason PCI card worked is that the PCI card used
> some of the Tprop (10ns. bus propagation time (the time signals travel
> on the PCB)) to meet the Tsu/Tval requirements.
> For the P&R (Place & Route), I used the the one that came with
> WebPack, and used only a User Constraint File to specify the timings I
> wanted.
> Since the PCI card with my PCI IP core that violated the timings
> worked okay at 33MHz, I will suspect that your problem is not the
> timings, but with your state machine design.

Don't forget that the timing analyzer reports worst-case numbers, and
the real part may be substantially better.  The next batch of chips may
not be as good, or you could run into problems as the chassis heats up,
or whatever.

Methinks you're lucky.  You should buy a lottery ticket!

-andy

Article: 34224
Subject: Re: Slowing PCI for FPGA
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Thu, 16 Aug 2001 20:24:31 GMT
Links: << >>  << T >>  << A >>
I'm with Falk here.

Buy a target device (like the 9030), and let that handle all of your PCI
stuff.  The 9030 has a local bus that can be clocked from essentially DC
to 60 MHz, and it does a lot of stuff for you.

You shouldn't be reinventing the wheel unless you've got a Real Good
Reason to do so!

-andy

Joey Oravec wrote:
> 
> Hi, surely somebody else has run into this before.
> 
> I am doing a prototype with a PCI interface and there isn't a prayer of
> making it work at 25mhz bus transfer (my slowest machine available)
> without a lot of effort. What would you do to easily slow things down? I
> know DINI group has a card for $600 that will halve the PCI clock and
> another for $3k which is more flexible. There's PCI-PCI bridge IP
> available but that's also expensive.
> 
> Unfortunately I'm cheap and I'm thinking there must be a better
> inexpensive solution. Any thoughts?
> 
> --
>   O..O    Arcade machine collection:
>  (----)        http://www.science.wayne.edu/~joey/arcade/
> ( >__< )  IRC - EFNet #rgvac: demigod2k
> ^^ ~~ ^^



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
2017JanFebMarApr2017

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