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 134275

Article: 134275
Subject: Re: Schematic Capture tutorials/books?
From: Mike Treseler <mtreseler@gmail.com>
Date: Mon, 04 Aug 2008 05:17:13 -0700
Links: << >>  << T >>  << A >>
laserbeak43 wrote:
> I'm new to FPGAs I just bought a Spartan 3E Starter Kit and I'm
> looking for documentation on Schematic capture with ISE or whatever
> would work for a good tutorial. It seems VERY hard to find ANY
> documentation though. I did find a starter video from digilent, but
> that was very short and seemed to be more of an intro to dataflow
> programming.
> Can anyone point me in the right direction?

Schematic capture for FPGA design entry is moribund.
Consider learning vhdl or verilog instead.
If schematics are non-negotiable, consider quartus:
multimedia.ece.uic.edu/wahmad/quartus_ii_tutorial.pdf
Good luck.

    -- Mike Treseler

Article: 134276
Subject: Re: Schematic Capture tutorials/books?
From: Gabor <gabor@alacron.com>
Date: Mon, 4 Aug 2008 05:30:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 4, 8:17 am, Mike Treseler <mtrese...@gmail.com> wrote:
> laserbeak43 wrote:
> > I'm new to FPGAs I just bought a Spartan 3E Starter Kit and I'm
> > looking for documentation on Schematic capture with ISE or whatever
> > would work for a good tutorial. It seems VERY hard to find ANY
> > documentation though. I did find a starter video from digilent, but
> > that was very short and seemed to be more of an intro to dataflow
> > programming.
> > Can anyone point me in the right direction?
>
> Schematic capture for FPGA design entry is moribund.
> Consider learning vhdl or verilog instead.
> If schematics are non-negotiable, consider quartus:
> multimedia.ece.uic.edu/wahmad/quartus_ii_tutorial.pdf
> Good luck.
>
>     -- Mike Treseler

Since the OP already bought the Xilinx stuff, he may want to
open ISE (or WebPack) and under Help --> Tutorials -->
Tutorials on the Web, he can find what is available from
Xilinx.  Look for "ECS" schematics.  By the way I have
not looked at these myself.  I too use  HDL rather than
schematics since I "upgraded" from version 4.1 - the
last Foundation version with Aldec schematics.  Also
go to http://forums.xilinx.com/ and check out all of
the chatter on schematics.  In my opinion, the ECS
schematics are not ready for prime time.  The
associated documentation is not likely to be better.

Oh, and before you get ideas of using Foundation
4.1 schematics, it is no longer available from Xilinx
due to a termination of their agreement with Aldec.

Aldec has wonderful new software that supports
Xilinx parts and others, but it would cost a lot more
than a good Altera evaluation board and a copy of
Quartus.

Just my 2 cents,
Gabor

Article: 134277
Subject: Is HDL-Designer not supporting records correctly?
From: Svenn Are Bjerkem <svenn.bjerkem@googlemail.com>
Date: Mon, 4 Aug 2008 06:18:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
I converted some vhdl files from text to graphics and note that
connections to signals in records does not get a visual connection to
the pins where the single wires are supposed to be connected. They are
just open, and there are no input pins for the records entering the
block placed. I inspect the generated vhdl and symbol, and they are
added correctly to the symbol and to the output rtl.

Anybody know if this is a "feature" or is there an option that I need
to set somewhere to see  the connections? I use version 2007.1a.

--
Svenn

Article: 134278
Subject: Re: Is HDL-Designer not supporting records correctly?
From: "HT-Lab" <hans64@ht-lab.com>
Date: Mon, 4 Aug 2008 15:04:31 +0100
Links: << >>  << T >>  << A >>

"Svenn Are Bjerkem" <svenn.bjerkem@googlemail.com> wrote in message 
news:7e7320a6-ee66-4285-9c61-20f16670f54a@d1g2000hsg.googlegroups.com...
> Hi,
> I converted some vhdl files from text to graphics and note that
> connections to signals in records does not get a visual connection to
> the pins where the single wires are supposed to be connected. They are
> just open, and there are no input pins for the records entering the
> block placed. I inspect the generated vhdl and symbol, and they are
> added correctly to the symbol and to the output rtl.
>
> Anybody know if this is a "feature" or is there an option that I need
> to set somewhere to see  the connections? I use version 2007.1a.
>
> --
> Svenn

I am not sure I understand you 100%, records are supported and if you import 
some VHDL and convert it to graphics all should be OK. However, you are 
right that graphically you can not select an element from a record and 
connect it to a blue/green block pin. So what happens is that you get a 
yellow block with a "signal<=record.element;" type of assignment. This is a 
real shame and proper record support is something I have been asking for it 
since version 2004 :-(

Hans
www.ht-lab.com




Article: 134279
Subject: Chipscope - Clock Error
From: "zooplibob@gmail.com" <zooplibob@gmail.com>
Date: Mon, 4 Aug 2008 07:18:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi I'm trying to debug something on somebody's FPGA design using
Chipscope, and no matter which clock I select for chipscope to use, I
get the following error:

ERROR:Place:37 - This design is unroutable. A Global clock component
   <mbox_ddr2a/infrastructure_top0/clk_dcm0/BUFG_CLK90> configured as
a selectable mux is placed in site BUFGMUX0.  This
   configuration requires that the Global clock site BUFGMUX1 either
be empty or contain a Global buffer or mux with the
   inputs IN0 and IN1 configured in a specific manner. The IN0 and IN1
inputs must either not be driven by any signal or
   driven by the same signals as the paired clock buffer IN1 and IN0
pins respectively in order to route both of the
   inputs.  In other words the input signal for IN0 on one buffer must
be the same as the input signal driving IN1 on
   the other buffer (or one of them must not be driven) to place the
two buffers in the paired sites.  The site BUFGMUX1
   has the Global buffer <mbox_ddr2a/infrastructure_top0/clk_dcm0/
BUFG_CLK0> placed there.

Theres no information about this on their site. Any suggestions?

Article: 134280
Subject: Re: What's the deal with PSoC programmers?
From: Bryan <bryan.fletcher@avnet.com>
Date: Mon, 4 Aug 2008 07:53:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 1, 2:22=A0pm, andersod2 <thechrisander...@gmail.com> wrote:
> Hi, just wondering about these...what are they, what hardware is
> involved, what are the advantages etc...
>
> thanks

If you want a low-cost board to experiment with both a Xilinx FPGA and
a Cypress PSoC, try this $39 kit:

www.em.avnet.com/spartan3a-evl

Bryan

Article: 134281
Subject: Re: Chipscope - Clock Error
From: Gabor <gabor@alacron.com>
Date: Mon, 4 Aug 2008 07:54:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 4, 10:18 am, "zoopli...@gmail.com" <zoopli...@gmail.com> wrote:
> Hi I'm trying to debug something on somebody's FPGA design using
> Chipscope, and no matter which clock I select for chipscope to use, I
> get the following error:
>
> ERROR:Place:37 - This design is unroutable. A Global clock component
>    <mbox_ddr2a/infrastructure_top0/clk_dcm0/BUFG_CLK90> configured as
> a selectable mux is placed in site BUFGMUX0.  This
>    configuration requires that the Global clock site BUFGMUX1 either
> be empty or contain a Global buffer or mux with the
>    inputs IN0 and IN1 configured in a specific manner. The IN0 and IN1
> inputs must either not be driven by any signal or
>    driven by the same signals as the paired clock buffer IN1 and IN0
> pins respectively in order to route both of the
>    inputs.  In other words the input signal for IN0 on one buffer must
> be the same as the input signal driving IN1 on
>    the other buffer (or one of them must not be driven) to place the
> two buffers in the paired sites.  The site BUFGMUX1
>    has the Global buffer <mbox_ddr2a/infrastructure_top0/clk_dcm0/
> BUFG_CLK0> placed there.
>
> Theres no information about this on their site. Any suggestions?

This usually indicates that you need to do some hand placement
of the clock components.  In Virtex II and Spartan 3, the BUFGMUX
components come in pairs with common input routing.  So
if you use one half of the pair as a mux, requiring both inputs to
connect to live signals, the other half of the pair can only work
if it buffers one of the same signals connected to the mux.  The
placer is not always smart enough to find a workable combination
of BUFGMUX locations.

It is interesting that you get this when you add Chipscope to the
design, which should not be adding any more global clock
resources.  It seems that your previous implementation without
Chipscope just lucked out with the placer.  What I would recommend
is to look at the "working" placement with the FPGA editor and
lock down all instantiated DCM and BUFG / BUFGMUX
components to their current locations.  This should theoretically
give you a working placement when you add more logic to
the design, including ChipScope.

HTH,
Gabor

Article: 134282
Subject: Re: fixed FFT point implementation woes
From: robert bristow-johnson <rbj@audioimagination.com>
Date: Mon, 4 Aug 2008 07:55:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 4, 4:07=A0am, chrisde...@gmail.com wrote:
> Hi,
> =A0 =A0I am trying to create a mex file that does fixed point FFT (512
> point?). I am generally ok with creating a C code in single precision
> to compute the the result and have ensured that it works fine as i get
> the correct result. (i read it back and plotted it in matlab.)
> =A0 =A0 the problem comes in when i try to convert it to fixed point. My
> input data is 24 bits integer. In addition, I take the sine and cosine
> twiddles to also be 24 bits... I do the cos(2*pi*n/N) and sin(2*pi/N)
> for n from 0 to 255 the multply the result by ((2^23)-1) and store it
> in a look up table.
>
> =A0 =A0 What i really dun quite understand is how the scaling factors
> work. In FFT books, they generally say that the output from each scale
> should maybe be scaled by 1 bit to pre-empt bit growth problems. Also,
> for unscaled bit-growth, it generally grows by log2(N) for an N point
> FFT. But how does that work?
> =A0 =A0 What i see here is the following:
>
> 1) 24 bit input data. If i dun convert it to anything, it becomes Q.24
> format right?
> 2) 24 bit input data x 24 bit twiddle factor (Q.24 also). this becomes
> 48 bits. to prevent overflow, i scale by 24 say.

remember that when you do "fixed point" arithmetic, you are really
doing INTEGER arithmetic where *you* are knowledgable about where the
binary point lies.  now i would expect your data is instead Q1.23 so
that there are 23 fractional bits and on bit left of the binary point
for sign.  the implied range is then from -1.000000 oto +0.99999988


>
> But this is too much and the output frequency spectrum becomes a mess.
> I would forsee plenty of precision loss. If i scale by 1 from the
> output of each stage, then the FFT gets clipped.
>
> any ideas?what did i go wrong here? =A0:(

you might need to consider clipping in each pass of the FFT.  perhaps
you need to divide by 2 in the output of each butterfly, then your DFT
has a 1/N factor in front of the summation.  but then in the iDFT
there is no divide by two and your data amplitude grows.  or perhaps
you split the difference and divide by two only in every other pass of
the FFT.  then your DFT definition (and the iDFT) both have 1/sqrt(N)
in the definition.  this sorta thing you have to check out with the
nature of your data and see what works best.

or you can try "block floating-point" arithmetic.

r b-j

Article: 134283
Subject: AC coupling on GTX RocketIO clocks
From: Josh <model@ll.mit.edu>
Date: Mon, 04 Aug 2008 11:40:55 -0400
Links: << >>  << T >>  << A >>
I've got a GTX board-layout question, that I thought the group might 
have some experience with.

A coworker of mine is working on a design that includes Virtex-5 GTX 
transceivers.  One of the requirements on the "GTX Reference Clock 
Checklist" ( 
http://www.xilinx.com/support/documentation/user_guides/ug198.pdf )

is

"Provide AC coupling between the oscillator output pins and the 
dedicated GTX_DUAL clock input pins"

In laying out the board, it's much easier to put the AC coupling cap 
near the oscillator output pins than it is to put it near the clock in 
put pins.  Is there any issue with doing so?  Usually I've seen the cap 
placed near the input pins, not sure if that were rule-of-thumb or if 
there's a good reason to do so.

i.e.
do
~Osc~--|>--| |----PCBLine--------FPGA_REFCLK--

and

~Osc~--|>---------PCBLine----| |-FPGA_REFCLK--

both work?

Thanks,

--Josh




Article: 134284
Subject: Re: AC coupling on GTX RocketIO clocks
From: Gabor <gabor@alacron.com>
Date: Mon, 4 Aug 2008 08:54:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 4, 11:40 am, Josh <mo...@ll.mit.edu> wrote:
> I've got a GTX board-layout question, that I thought the group might
> have some experience with.
>
> A coworker of mine is working on a design that includes Virtex-5 GTX
> transceivers.  One of the requirements on the "GTX Reference Clock
> Checklist" (http://www.xilinx.com/support/documentation/user_guides/ug198.pdf)
>
> is
>
> "Provide AC coupling between the oscillator output pins and the
> dedicated GTX_DUAL clock input pins"
>
> In laying out the board, it's much easier to put the AC coupling cap
> near the oscillator output pins than it is to put it near the clock in
> put pins.  Is there any issue with doing so?  Usually I've seen the cap
> placed near the input pins, not sure if that were rule-of-thumb or if
> there's a good reason to do so.
>
> i.e.
> do
> ~Osc~--|>--| |----PCBLine--------FPGA_REFCLK--
>
> and
>
> ~Osc~--|>---------PCBLine----| |-FPGA_REFCLK--
>
> both work?
>
> Thanks,
>
> --Josh

Think of the capacitors as wires that only let through high frequency.
At any frequency requiring termination, therefore they are pretty
much just wires.  So the answer is that it really doesn't matter
where they go along the line as long as the package itself does
not create a big impedance bump (i.e. use small caps like 0402).

Regards,
Gabor

Article: 134285
Subject: Re: Why PCI9054 fails to assert pci interrupt when local interrupt
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Mon, 04 Aug 2008 09:18:38 -0700
Links: << >>  << T >>  << A >>
Leon wrote:
> Hi all,
> 
> I am doing a project involving PCI9054. 
>  
> I meet a problem of interrupt. I wanna  assert a PCI interrupt using the
> LINT#  pin which is set as input with the INTCSR register being setting
> as:
> 0X0f000900. But when I pull down the level of LINT# that is drived by
> FPGA, the INTCSR becomes 0X0f000100, that is, INTCSR[11](local interrupt
> input enable) is cleared and INTCSR[15](local input interrupt active) fails
> to be set 1. And also the interrupt handler is not called. I have no idea
> what the reason. 
>  
> However, when I set INTCSR as 0X0f000800 (PCI interrupt is not enabled)
> and then pull down LINT#, the INTCSR can come to the ideal value:
> 0X0f008800. I dont know its the reason of WinDriver diagnostic program or
> the PCI9054 itself. 
>  
> Any advice will be helpful, Thank u very much!
>  
> Leon,

While that's certainly not enough information for me to offer you any 
help, I'll throw out that in my experience PLX, who makes the only 
PCI9054 that I know of, has fairly responsive technical support when you 
send them an email.  They'll take a couple days to get back to you, but 
what you get will be both thought out and relevant to your question. 
Have you tried their guys yet?

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

Article: 134286
Subject: Re: Schematic Capture tutorials/books?
From: laserbeak43 <laserbeak43@gmail.com>
Date: Mon, 4 Aug 2008 10:06:37 -0700 (PDT)
Links: << >>  << T >>  << A >>

> > Schematic capture for FPGA design entry is moribund.
> > Consider learning vhdl or verilog instead.
> > If schematics are non-negotiable, consider quartus:
> > multimedia.ece.uic.edu/wahmad/quartus_ii_tutorial.pdf
> > Good luck.
>
> > =A0 =A0 -- Mike Treseler

Hmm, so i've heard. Everyone says Xilinx stuff is bad for beginners
and i must admit,
I've been doing nothing but troubleshooting ever since i got this
board, what a headache.


> Since the OP already bought the Xilinx stuff, he may want to
> open ISE (or WebPack) and under Help --> Tutorials -->
> Tutorials on the Web, he can find what is available from
> Xilinx. =A0Look for "ECS" schematics. =A0By the way I have
> not looked at these myself. =A0I too use =A0HDL rather than
> schematics since I "upgraded" from version 4.1 - the
> last Foundation version with Aldec schematics. =A0Also
> go tohttp://forums.xilinx.com/and check out all of
> the chatter on schematics. =A0In my opinion, the ECS
> schematics are not ready for prime time. =A0The
> associated documentation is not likely to be better.
>
> Oh, and before you get ideas of using Foundation
> 4.1 schematics, it is no longer available from Xilinx
> due to a termination of their agreement with Aldec.
>
> Aldec has wonderful new software that supports
> Xilinx parts and others, but it would cost a lot more
> than a good Altera evaluation board and a copy of
> Quartus.
>
> Just my 2 cents,
> Gabor


I think i'm gonnna sell this board and go for an Altera board.
but i'll try that first.

thanks guys.

Article: 134287
Subject: Re: Is HDL-Designer not supporting records correctly?
From: Mike Treseler <mtreseler@gmail.com>
Date: Mon, 04 Aug 2008 10:42:24 -0700
Links: << >>  << T >>  << A >>
Svenn Are Bjerkem wrote:
> I converted some vhdl files from text to graphics and note that
> connections to signals in records does not get a visual connection to
> the pins where the single wires are supposed to be connected. They are
> just open, and there are no input pins for the records entering the
> block placed. I inspect the generated vhdl and symbol, and they are
> added correctly to the symbol and to the output rtl.
> Anybody know if this is a "feature" or is there an option that I need
> to set somewhere to see  the connections? I use version 2007.1a.

The last time I evaluated a text to graphics application,
I got so annoyed about having to type critical bits of code
into little graphical boxes that I went back to emacs vhdl-mode
and never looked back.

The vhdl-mode browser (speedbar) sorts out locating, editing
and compiling the source files for this or that vhdl design unit.
It also helps with creating structural entities.

The quartus rtl viewer does a good job for graphical browsing
and for creating postscript schematic views from the synthesis code.
A key point is that such viewers are a post-process
on working code, rather than a nasty lump in
the design description itself.

         -- Mike Treseler


Article: 134288
Subject: Re: fixed FFT point implementation woes
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 04 Aug 2008 10:03:17 -0800
Links: << >>  << T >>  << A >>
robert bristow-johnson wrote:
(snip)

> remember that when you do "fixed point" arithmetic, you are really
> doing INTEGER arithmetic where *you* are knowledgable about where the
> binary point lies.  now i would expect your data is instead Q1.23 so
> that there are 23 fractional bits and on bit left of the binary point
> for sign.  the implied range is then from -1.000000 oto +0.99999988

That is pretty much true for assembly and C programming.

There are programming languages that do fixed point arithmetic
where the compiler keeps track of the radix point.
(Not necessarily binary.)  You still have to be a little careful
to know where overflow might occur.

-- glen


Article: 134289
Subject: Re: fixed FFT point implementation woes
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 04 Aug 2008 10:12:13 -0800
Links: << >>  << T >>  << A >>
chrisdekoh@gmail.com wrote:
(snip)

>     the problem comes in when i try to convert it to fixed point. My
> input data is 24 bits integer. In addition, I take the sine and cosine
> twiddles to also be 24 bits... I do the cos(2*pi*n/N) and sin(2*pi/N)
> for n from 0 to 255 the multply the result by ((2^23)-1) and store it
> in a look up table.

>     What i really dun quite understand is how the scaling factors
> work. In FFT books, they generally say that the output from each scale
> should maybe be scaled by 1 bit to pre-empt bit growth problems. Also,
> for unscaled bit-growth, it generally grows by log2(N) for an N point
> FFT. But how does that work?

First you have to be able to do the multiply.  If you multiply two
numbers, each with 23 bits after the binary point the product has
46 bits after the binary point.  You probably don't want all those
bits, but C doesn't have a good way to get the right bits.

If you have the bits, it is best to expand by one bit for each
stage, such that you avoid overflow but still keep all the
significant bits.  You can figure out at the end which bits
you really want.  Otherwise, you need to know more about the
actual data.  In most cases, bit growth will be somewhat
slower, except for the DC (0) term, which can fairly easily
accumulate large values.

-- glen


Article: 134290
Subject: Re: Chipscope - Clock Error
From: Mike Treseler <mtreseler@gmail.com>
Date: Mon, 04 Aug 2008 11:17:20 -0700
Links: << >>  << T >>  << A >>
zooplibob@gmail.com wrote:
> Hi I'm trying to debug something on somebody's FPGA design using
> Chipscope, and no matter which clock I select for chipscope to use, I
> get the following error:
> ERROR:Place:37 - This design is unroutable...
> Theres no information about this on their site. Any suggestions?

The chipscope hardware requires a few luts, flops, and wires.
This can perturb a tight design to be an routable one.
Your choices are

[]Run a sim to find the bug.
  Chances are the fix will be much smaller than
  the chipscope logic.
[]Add some testpoint pins for debugging instead of chipscope.
[]Relax the placement constraints and let
  the router have another go. If it doesn't fit
  try a larger device with the same pinout.
[]Fix up the routing manually as Gabor suggests.

      -- Mike Treseler

Article: 134291
Subject: RGMII with Xilinx ML405 Board
From: bishopg12@gmail.com
Date: Mon, 4 Aug 2008 14:02:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
Does anyone have any guidance into writing the timing constraints in
the UCF file to use RGMII on the ML405 development board from Xilinx?
Here is the relevant section in the UCF file:

#### Module Ethernet_MAC constraints

NET MDC_0         LOC = H11 | IOSTANDARD=LVCMOS33;
NET MDIO_0        LOC = K13 | IOSTANDARD=LVCMOS33;
NET phy_rst_n     LOC = J13 | IOSTANDARD=LVCMOS33;
Net phy_rst_n     TIG;

NET RGMII_TXD_0<3> LOC = G15 | IOSTANDARD=LVCMOS33 | SLEW=FAST;
NET RGMII_TXD_0<2> LOC = H12 | IOSTANDARD=LVCMOS33 | SLEW=FAST;
NET RGMII_TXD_0<1> LOC = H16 | IOSTANDARD=LVCMOS33 | SLEW=FAST;
NET RGMII_TXD_0<0> LOC = J16 | IOSTANDARD=LVCMOS33 | SLEW=FAST;

NET RGMII_TX_CTL_0 LOC = K12 | IOSTANDARD=LVCMOS33 | SLEW=FAST;
NET RGMII_TXC_0    LOC = D15 | IOSTANDARD=LVCMOS25 | SLEW=FAST;

NET RGMII_RXD_0<3> LOC = G16 | IOSTANDARD=LVCMOS33;
NET RGMII_RXD_0<2> LOC = H14 | IOSTANDARD=LVCMOS33;
NET RGMII_RXD_0<1> LOC = G14 | IOSTANDARD=LVCMOS33;
NET RGMII_RXD_0<0> LOC = J15 | IOSTANDARD=LVCMOS33;

NET RGMII_RX_CTL_0 LOC = J14 | IOSTANDARD=LVCMOS33;
NET RGMII_RXC_0    LOC = F15 | IOSTANDARD=LVCMOS25;

NET phy_rst_n      TIG;


#### New GMAC Coregen Derived Constraints

NET "*tx_gmii_mii_clk*"    			TNM_NET = "clk_phy_tx_clk0";
NET "*tx_gmii_mii_clk_in_0_i"    	TNM_NET = "clk_phy_tx_clk0";
NET "*tx_gmii_mii_clk_out_0_i"    	TNM_NET = "clk_phy_tx_clk0";
TIMESPEC "TS_phy_tx_clk0"            = PERIOD "clk_phy_tx_clk0" 7200
ps HIGH 50 %;

NET "*gmii_rx_clk*"					TNM_NET = "clk_phy_rx_clk0";
TIMESPEC "TS_phy_rx_clk0"             = PERIOD "clk_phy_rx_clk0" 7200
ps HIGH 50 %;

NET "*tx_client_clk*"      			TNM_NET = "clk_client_tx_clk0";
TIMESPEC "TS_client_tx_clk0"            = PERIOD "clk_client_tx_clk0"
7200 ps HIGH 50 %;

NET "*rx_client_clk*"      			TNM_NET = "clk_client_rx_clk0";
TIMESPEC "TS_client_rx_clk0"            = PERIOD "clk_client_rx_clk0"
7200 ps HIGH 50 %;

NET "*mii_tx_clk*"            		TNM_NET = "clk_mii_tx_clk0";
TIMESPEC "TS_mii_tx_clk0"               = PERIOD "clk_mii_tx_clk0"
25000 ps HIGH 50 %;


# Place flip flops in IOBs
INST "*gmii0?RXD_TO_MAC*"    IOB = true;
INST "*gmii0?RX_DV_TO_MAC"   IOB = true;
INST "*gmii0?RX_ER_TO_MAC"   IOB = true;

# IDELAY on data path to align it with the clock
INST "*gmii_rxd?_delay"     IOBDELAY_TYPE = FIXED;
INST "*gmii_rx_dv_delay"    IOBDELAY_TYPE = FIXED;
INST "*gmii_rx_er_delay"    IOBDELAY_TYPE = FIXED;
INST "*gmii_rxd?_delay"     IOBDELAY_VALUE = 0;
INST "*gmii_rx_dv_delay"    IOBDELAY_VALUE = 0;
INST "*gmii_rx_er_delay"    IOBDELAY_VALUE = 0;
INST "*gmii_rx_clk_?_delay" IOBDELAY_TYPE = FIXED;
INST "*gmii_rx_clk_0_delay" IOBDELAY_VALUE =31 ;

# Need to TIG between the LocalLink clock and the rx_client and
tx_client clocks
NET "*/LlinkTemac0_CLK*" TNM_NET = "LLCLK";

TIMESPEC "TS_LL_CLK_2_RX_CLIENT_CLK"  = FROM LLCLK TO
clk_client_rx_clk0 8000 ps DATAPATHONLY;
TIMESPEC "TS_LL_CLK_2_TX_CLIENT_CLK"  = FROM LLCLK TO
clk_client_tx_clk0 8000 ps DATAPATHONLY;
TIMESPEC "TS_RX_CLIENT_CLK_2_LL_CLK"  = FROM clk_client_rx_clk0 TO
LLCLK 10000 ps DATAPATHONLY;
TIMESPEC "TS_TX_CLIENT_CLK_2_LL_CLK"  = FROM clk_client_tx_clk0 TO
LLCLK 10000 ps DATAPATHONLY;

I have tried the timing constraints generated from the wizard and from
the data sheet.  In both cases I get errors like this:

ERROR:Place:872 - Delay element
   "TriMode_MAC_GMII/TriMode_MAC_GMII/V4HARD_SYS.I_TEMAC/
SINGLE_RGMII2.I_EMAC_TO
   P/rgmii_rxd_rising_0_i<0>" has been placed at ILOGIC_X1Y95 due to
the
   following location constraint on component "RGMII_RXD_0<0>":
   	COMP "RGMII_RXD_0<0>" LOCATE = SITE "J15" LEVEL 1
   However, the delay controller that calibrates this delay element
has not been
   used. Please instantiate a delay controller and apply appropriate
location
   constraint, or instantiate one delay controller for the design with
out any
   location constraint. Please refer to the usage document to use the
controller
   efficiently.

Thanks!
-George

Article: 134292
Subject: Re: Schematic Capture tutorials/books?
From: "Eric Crabill" <eric.crabill@xilinx.com>
Date: Mon, 4 Aug 2008 14:03:33 -0700
Links: << >>  << T >>  << A >>
Hi,



If you have the time, I invite you to contact me directly (privately) to 
discuss your experience with the Spartan-3E Starter Kit.  As you might 
imagine, it is intended for "starters" and not intended to generate 
frustration!



I know you are interested in schematic based design entry, so the following 
resource may be of limited interest (but I'll include it anyway):



http://www.engr.sjsu.edu/crabill



I look forward to hearing from you,

Eric Crabill



=====



"laserbeak43" <laserbeak43@gmail.com> wrote in message 
news:38faf0eb-3746-49f1-84f3-1720ba98d399@r66g2000hsg.googlegroups.com...

> > Schematic capture for FPGA design entry is moribund.
> > Consider learning vhdl or verilog instead.
> > If schematics are non-negotiable, consider quartus:
> > multimedia.ece.uic.edu/wahmad/quartus_ii_tutorial.pdf
> > Good luck.
>
> > -- Mike Treseler

Hmm, so i've heard. Everyone says Xilinx stuff is bad for beginners
and i must admit,
I've been doing nothing but troubleshooting ever since i got this
board, what a headache.

> Since the OP already bought the Xilinx stuff, he may want to
> open ISE (or WebPack) and under Help --> Tutorials -->
> Tutorials on the Web, he can find what is available from
> Xilinx. Look for "ECS" schematics. By the way I have
> not looked at these myself. I too use HDL rather than
> schematics since I "upgraded" from version 4.1 - the
> last Foundation version with Aldec schematics. Also
> go tohttp://forums.xilinx.com/and check out all of
> the chatter on schematics. In my opinion, the ECS
> schematics are not ready for prime time. The
> associated documentation is not likely to be better.
>
> Oh, and before you get ideas of using Foundation
> 4.1 schematics, it is no longer available from Xilinx
> due to a termination of their agreement with Aldec.
>
> Aldec has wonderful new software that supports
> Xilinx parts and others, but it would cost a lot more
> than a good Altera evaluation board and a copy of
> Quartus.
>
> Just my 2 cents,
> Gabor

I think i'm gonnna sell this board and go for an Altera board.
but i'll try that first.

thanks guys. 



Article: 134293
Subject: Re: Chipscope - Clock Error
From: Mike Treseler <mtreseler@gmail.com>
Date: Mon, 04 Aug 2008 20:28:56 -0700
Links: << >>  << T >>  << A >>
> This can perturb a tight design to be an routable one.
                                           ^unroutable

Article: 134294
Subject: Altera sues Zilog - signs of desperation from Programmable Vendor
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 05 Aug 2008 15:52:24 +1200
Links: << >>  << T >>  << A >>
  A strange world when a Programmable Logic Vendor, sues
a Microcontroller company. Have they really been losing sales
to minnow Zilog, or do their lawyers need something to
justify their salaries ?
  Or, is this a retaliation to Zilog's suit back in
Jan 2007 ?
-jg




Article: 134295
Subject: vhdl or verilog code for 64 point ifft
From: irfan.mohammed@gmail.com
Date: Mon, 4 Aug 2008 21:25:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
Dear friends,

i am having 8 point ifft implementation in vhdl,how can i convert it
to 64 point ifft(inverse fast forier transform). please help me i need
yor valuable sugessions and if any one is having the code for this in
vhdl or verilog it would be great.

as i have 8 point ifft,can i use this core to implement 64 point ifft?

Thanks in advance
Irfan


Article: 134296
Subject: I whant connected one port of dual port BRAM from NIOS. help....
From: axalay <axalay@gmail.com>
Date: Tue, 5 Aug 2008 01:02:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
I greate new component, but it dont work correctly

Article: 134297
Subject: Re: Altera sues Zilog - signs of desperation from Programmable Vendor
From: Jon Beniston <jon@beniston.com>
Date: Tue, 5 Aug 2008 01:25:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
Do you know what the relevant patents are?



Article: 134298
Subject: Re: I whant connected one port of dual port BRAM from NIOS. help....
From: axalay <axalay@gmail.com>
Date: Tue, 5 Aug 2008 04:10:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 5 =C1=D7=C7, 12:02, axalay <axa...@gmail.com> wrote:
> I greate new component, but it dont work correctly

The problem is solved. Problem arises when I use NIOS II/f. I am not
understand why

Article: 134299
Subject: Re: Altera sues Zilog - signs of desperation from Programmable Vendor
From: Mike Treseler <mtreseler@gmail.com>
Date: Tue, 05 Aug 2008 06:39:11 -0700
Links: << >>  << T >>  << A >>
Jim Granville wrote:
>  A strange world when a Programmable Logic Vendor, sues
> a Microcontroller company. Have they really been losing sales
> to minnow Zilog, or do their lawyers need something to
> justify their salaries ?

Patents are insurance policies.

>  Or, is this a retaliation to Zilog's suit back in

That's how the game is played:
http://www.edn.com/index.asp?layout=article&articleid=CA6409006

   -- Mike Treseler



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