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 67950

Article: 67950
Subject: Re: Virtex-4
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 23 Mar 2004 16:09:16 GMT
Links: << >>  << T >>  << A >>
"Brannon King" <bking@starbridgesystems.com> wrote in message
news:fqudnURdQ-3vLcLdRVn-vw@comcast.com...
> I hear the V2Pro was known at various locations internally as the V3. To
> avoid the confusion they just skipped to V4.
>
> I don't understand the clock issue. Mine lookes like this all the way
> around:
>
> /^^\__/^^\__/^^\__/^^\........
>
> And I assume they will add an Over-Score key about the time I get my clock
> looking smooth on top.

As a help to get your clock looking cleaner:

 /ŻŻ\__/ŻŻ\__/ŻŻ\__/ŻŻ\........


(the clock issue was roman numeral IIII rather than IV on decent wall
clocks)



Article: 67951
Subject: Re: How many times can I burn an FPGA?
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 23 Mar 2004 08:22:35 -0800
Links: << >>  << T >>  << A >>
Better than that:
The FPGA can be reprogrammed an unlimited number of times (same as
flip-flops in a computer can be e an unlimited number of times), and the
EEPROM or FlashPROM can also be read an unlimited number of times.(There may
be a limitation on write cycles, but not on read operations).
Don't worry, be happy!
Peter Alfke, Xilinx Applicationas

> From: Ray Andraka <ray@andraka.com>
> Organization: Andraka Consulting Group, Inc
> Newsgroups: comp.arch.fpga
> Date: Tue, 23 Mar 2004 09:22:39 -0500
> Subject: Re: How many times can I burn an FPGA?
> 
> There is no limit to the reconfiguration on FPGAs.  The configuration is held
> in
> registers similar to the flip-flops in the design (although the registers are
> designed to be slower and therefore more robust against unintended upsets).
> They won't wear out.  The only life limited item would be the EPROM you load
> the
> FPGA from.
> 
> Hendra Gunawan wrote:
> 
>> Hi folks,
>> typically how many times can I burn/download an FPGA before it becomes
>> unreliable. I read Xilinx FPGA datasheets and couldn't find the answer.
>> I am asking because I am wondering if someone is going to make a commercial
>> FPGA product that need to be frequently turned on and off, this can be an
>> issue. Every time the device is turned on, the FPGA chip need to be
>> redownloaded from an EPROM. If the device is turned on and off 3 or 4 times
>> a day and the device is used every day, and if the device can only be
>> reprogrammed 1000 times, then in less than a year the device can not be used
>> anymore.
>> 
>> Thanks!
>> 
>> Hendra
> 
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
> 
> "They that give up essential liberty to obtain a little
> temporary safety deserve neither liberty nor safety."
> -Benjamin Franklin, 1759
> 
> 


Article: 67952
Subject: Quartus with AMD64 processors?
From: "Nial Stewart" <nial@nialstewartdevelopments.co.uk>
Date: Tue, 23 Mar 2004 17:28:51 -0000
Links: << >>  << T >>  << A >>
I'm sure I've read here about problems running Quartus with
one/some of AMD's 64 bits processors. I think the problem
was a script checking the processor and crashing out
because it didn't recognise the AMD64.

Does anyone know if this has been fixed? Do all versions of
Quartus work with 64 bit processors (specifically Athlon64s)?

My main machine's a bit old and tired and I'm thinking of
building myself a new one, but need it to be able to run
tools from A and X.


Thanks for any pointers,

Nial.


------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
Cyclone based 'Easy PCI' proto board
www.nialstewartdevelopments.co.uk



Article: 67953
Subject: Re: XCV2000E survived 3.3V core voltage!
From: Lasse Langwadt Christensen <langwadt@ieee.org>
Date: Tue, 23 Mar 2004 18:39:59 +0100
Links: << >>  << T >>  << A >>
Kevin Neilson wrote:
> Man, you're hardcore--soldering wires to balls and wire-wrapping.  I hope
> the savings are worthwhile.
> -Kevin
> 

Digikey says something like 2000$ for xcv2000e, so for 49$ and three hours
work it can't be that bad :)

-Lasse


> "Antti Lukats" <antti@case2000.com> wrote in message
> news:80a3aea5.0403220442.1e9d0756@posting.google.com...
> 
>>interesting - while doing wire wrapping to create a development board
>>with XCV2000E (BGA FG860) I accidently connected VCCINT to 3.3V supply
>>- I would guessed to see smoke or at least dead FPGA (the power supply
>>did deliver full 3.3V to VCCINT), but no! The FPGA was a little warm,
>>but not hot. After fixing the VCCINT back to 1.8V I did get long time
>>the famous error
>>
>>"DONE DID NOT GO HIGH"
>>
>>but after reading the datasheet and pulling PROGRAM to high the
>>XCV2000E did come fully alive, i.e. it really survived several minutes
>>of 3.3V on VCCINT.
>>
>>Antti Lukats
>>
>>PS if i get some time to breathe I will upload the picture of this 2M
>>Gate development board (my self-costs $49!! )
>>
>>just clarification: I am using a FPGA in BGA package that is removed
>>from equipment and I am soldering wires directly to BGA pads.
>>The FG860 is actually really easy to handle, and if I dont need many
>>IO pins such a wire wrap development board can be made in 3 hours max.
> 
> 
> 



Article: 67954
Subject: Re: How many times can I burn an FPGA?
From: edaudio2000@yahoo.co.uk (ted)
Date: 23 Mar 2004 09:46:51 -0800
Links: << >>  << T >>  << A >>
Altera FPGA devices can be programmed any number of times, 

But be aware that Altera' spec sheets say that CPLD devices can only
be programmed 100 (one hundred) times only.

Don't know about Xilinx.

"Hendra Gunawan" <u1000393@email.sjsu.edu> wrote in message news:<c3oh3k$6eb27$1@hades.csu.net>...
> Hi folks,
> typically how many times can I burn/download an FPGA before it becomes
> unreliable. I read Xilinx FPGA datasheets and couldn't find the answer.
> I am asking because I am wondering if someone is going to make a commercial
> FPGA product that need to be frequently turned on and off, this can be an
> issue. Every time the device is turned on, the FPGA chip need to be
> redownloaded from an EPROM. If the device is turned on and off 3 or 4 times
> a day and the device is used every day, and if the device can only be
> reprogrammed 1000 times, then in less than a year the device can not be used
> anymore.
> 
> Thanks!
> 
> Hendra

Article: 67955
Subject: Re: Altera and PCI-X
From: Dwayne Surdu-Miller <miller@SEDsystems.nospam.ca>
Date: Tue, 23 Mar 2004 12:17:57 -0600
Links: << >>  << T >>  << A >>
Yes.  Although the PCI spec indicates that PCI 2.2 motherboards should 
have both 5V and 3.3V supplies on the bus, that is not what industry has 
generally implemented.  When implementing a universal PCI card, ensure 
that your card can operate with and without a 3.3V supply present, and 
with and without a 5V supply present on the bus.  That is, be sure to 
have 5V-to-3.3V regulation on board, as well as means for operating from 
only a 3.3V supply.

The PCI specs from PCI-sig are about all the documentation I'd been able 
to find.  It's comprehensive, but unfortunately it can't cover what is 
actually being implemented in industry.

Avoid the I/O scheme where the host computer master-initiates burst 
reads from your PCI core operating as a target.  That particular I/O 
scheme is not supported by standard PCI bridge chips.  The standard 
alternatives are to either perform single DWORD reads from your PCI core 
operating as target, or to have your PCI core become bus master and 
burst write data to the host PC's memory.

Pre-plan how to establish the Vendor ID and Device ID that you will be 
slipping into your PCI core's configuration space.  If you want your own 
Vendor ID, PCI-sig will reserve one to you as long as you pay an annual 
membership fee.  Otherwise, Altera can most likely provide you with one 
that you can use, and can likely reserve a block of Device IDs for you 
as well.  We're using a Xilinx PCI core, and Xilinx has provided us with 
their umbrella Vendor ID and a block of Device ID's reserved for our 
use.  I'm quite sure Altera will provide similar service.

We've used 5V-tolerant FPGAs for universal PCI cards and 3.3-V tolerant 
FPGAs for 3.3V PCI cards, so we haven't had to concern ourselves with 
clipping or converting 5V signaling for 3.3V compatibility so far.

Those are most of the issues we've dealt with regarding PCI design so 
far.  There are likely conflicting notions out there.  I hope that we'll 
see some in this thread.

Best regards and good luck,
Dwayne Surdu-Miller
SED Systems
---------------------------------------------------

Neven Colak wrote:
> HI,
> 
> I am designing a PCI card which will have a Stratix FPGA as the PCI
> controller.  The Stratix will have a PCI-X core with PCI backwards
> compatibility.  Now from my readings, PCI-X is 3.3V only signalling,
> whereas today the majority of PC motherboards (pre PCI 2.3 spec) are
> 5V signalling.  For obvious reasons I will have to make my PCI card a
> universal card (keyed to both 5V and 3V3) in order to accept present
> day common motherboards (PCI 5V) and future motherboards (PCI-X/PCI
> 3V3).
> Is there anything special I need to consider? 
> 
> Does anybody know where I can find info on making my universal card. 
> Any good books or App notes.
> 
> Thanks,
> Neven


Article: 67956
Subject: Re: How many times can I burn an FPGA?
From: nonewsno@yahoo.com (Mark Sandford)
Date: 23 Mar 2004 11:09:22 -0800
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote in message news:<4060482F.8F69BB5@andraka.com>...
> There is no limit to the reconfiguration on FPGAs.  The configuration is held in
> registers similar to the flip-flops in the design (although the registers are
> designed to be slower and therefore more robust against unintended upsets).
> They won't wear out.  The only life limited item would be the EPROM you load the
> FPGA from.

This is not completely correct, Xilinx and Altera (and others) are
SRAM based and can be reprogrammed infinitely, but others are FLASH or
Anti-fuse based and thus can only be programmed a limited number of
times.  Flash can be reprogrammed a large number of times in the range
10,000 to 100,000 (see the datasheet for details).  Anti-fuse types
are like blowing a fuse and you can program one time only and if there
is a mistake or an upgrade is wanted it is now only a not so heavy
paperwieght.


 
> Hendra Gunawan wrote:
> 
> > Hi folks,
> > typically how many times can I burn/download an FPGA before it becomes
> > unreliable. I read Xilinx FPGA datasheets and couldn't find the answer.
> > I am asking because I am wondering if someone is going to make a commercial
> > FPGA product that need to be frequently turned on and off, this can be an
> > issue. Every time the device is turned on, the FPGA chip need to be
> > redownloaded from an EPROM. If the device is turned on and off 3 or 4 times
> > a day and the device is used every day, and if the device can only be
> > reprogrammed 1000 times, then in less than a year the device can not be used
> > anymore.
> >
> > Thanks!
> >
> > Hendra
> 
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
> 
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759

Article: 67957
Subject: Re: Quick Syntax question...
From: "Brannon King" <bking@starbridgesystems.com>
Date: 23 Mar 2004 14:11:33 EST
Links: << >>  << T >>  << A >>
Make sure you're putting it in the correct location in your file. See

http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/cgd/cgd0124_77.html


"Chris Cheung" <chris_cheung66@hotmail.com> wrote in message
news:1HF7c.268115$Hy3.236086@edtnps89...
> hi,
>     I am doing the IOSTANDARD attribute for my lvds buffer: See the
> following:
>
>  attribute IOSTANDARD : string;
> attribute IOSTANDARD of databuf : label is "LVDS_25";
> attribute IOSTANDARD of framebuf : label is "LVDS_25";
>
>     Of course, there is syntax error above.  Could anyone help me to
correct
> it?
>
>     Thanks
>
>     Chris
>
>



Article: 67958
Subject: Re: Quartus with AMD64 processors?
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 23 Mar 2004 21:15:27 +0100
Links: << >>  << T >>  << A >>
"Nial Stewart" <nial@nialstewartdevelopments.co.uk> writes:

> I'm sure I've read here about problems running Quartus with
> one/some of AMD's 64 bits processors. I think the problem
> was a script checking the processor and crashing out
> because it didn't recognise the AMD64.

This was the case running the Linux version of Quartus on AMD64
systems. I don't have access to Windows based AMD64 based systems.

> Does anyone know if this has been fixed? Do all versions of
> Quartus work with 64 bit processors (specifically Athlon64s)?

I don't think so. Maybe somebody from Altera could confirm this. I
still get the same message:


$quartus_sh -h
Unknown Linux processor
MWARCH: Undefined variable.
MWCURRENT_LIBPATH: Undefined variable.

This is very sad news since the AMD64 based systems are one of the
best price/performance systems available today, e.g. see
http://tinyurl.com/234d8 Not only that, but it seems like it got even
worse. It wont even run on my old Athlon system:

The Quartus II software is optimized for the Intel Pentium III processor
and newer processors.  The required extensions were not found on:
'AMD Athlon(tm) Processor'

:-(

On a Xeon based system I get:

quartus_sh -h
Quartus II Shell
Version 4.0 Build 190 1/28/2004 SJ Full Version
...



Petter

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 67959
Subject: Re: Apparent Altera Cyclone JTAG problem
From: rrr@ieee.org (Rajeev)
Date: 23 Mar 2004 12:21:29 -0800
Links: << >>  << T >>  << A >>
bob <bob@bob.com> wrote in message news:<405F6DAD.2B7CDE60@bob.com>...
<...>

> Has anyone seen strange loading faults where CONF_DONE goes high BUT the
> FPGA is not operating properly?  It
> happens to us only every few thousand loads.
> 
> I am keen to resolve this in some way.

Bob,

Indeed yes.

Don't know if you've seen this thread, or if you find it of any use
(Aug 18,2003 "Altera JTAG Verification")

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=c0f37b00.0308180607.97eec69%40posting.google.com&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3Drajeev%2BJAM%2BACEX%26btnG%3DGoogle%2BSearch%26meta%3Dgroup%253Dcomp.arch.fpga

My personal advice is to use any scheme other JTAG for Altera
configuration, at least in a production situation.

Regards,
-rajeev-

Article: 67960
Subject: xilinx PPC map file
From: Matthew E Rosenthal <mer2@andrew.cmu.edu>
Date: Tue, 23 Mar 2004 15:27:19 -0500 (EST)
Links: << >>  << T >>  << A >>
Can someone point me to some documentation explaining the map file.
I have taken the EDK tutorial sample on a memec board and I want to
expand it to do more stuff.  It looks like i need more addressable memory
to do this.
The memec board ccomes with a SDRAM chip that I would like to use as
memory but I can't find much documentation about the map file to make use
of this.

Thanks for your help

Matt


Article: 67961
Subject: Re: How many times can I burn an FPGA?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 24 Mar 2004 08:57:50 +1200
Links: << >>  << T >>  << A >>
Hendra Gunawan wrote:
> Hi folks,
> typically how many times can I burn/download an FPGA before it becomes
> unreliable. I read Xilinx FPGA datasheets and couldn't find the answer.
> I am asking because I am wondering if someone is going to make a commercial
> FPGA product that need to be frequently turned on and off, this can be an
> issue. Every time the device is turned on, the FPGA chip need to be
> redownloaded from an EPROM. If the device is turned on and off 3 or 4 times
> a day and the device is used every day, and if the device can only be
> reprogrammed 1000 times, then in less than a year the device can not be used
> anymore.

  Homework perhaps ?
  Burn and Download are two distinct operations. Not every type of
FPGA has a Download phase, but all require some non volatile storage
of the bit stream, either on-chip, or off-chip.
  Where Download is done, it is NV memory -> RAM storage, so has no
wear-out mechanism.
  Pgm of the NV storage itself, can have cycle limits from once for
Anti-fuse style chips, to > 100,000 for FLASH.
  There is a general tendancy to quote small cycle numbers (100-1000),
as that can give a testing saving.
-jg


Article: 67962
Subject: Re: How many times can I burn an FPGA?
From: Ray Andraka <ray@andraka.com>
Date: Tue, 23 Mar 2004 16:01:43 -0500
Links: << >>  << T >>  << A >>
I assumed he was talking about XILINX FPGAs since his post indicated he read teh XILINX
data sheet and couldn't find a life limit.  I apparently was not clear on the EPROM life
limit either (the number of write cycles, actually more specifically the number of erase
cycles for and EPROM are limited, reads are not).  Just for the record:

so called SRAM FPGAs have no limit on the number of reconfigurations.  The configuration
is held in flip-flops (granted, they are slow fat flip-flops for robustness), not in any
non-volatile storage.  These include Altera FPGAs (10K, 20K, mercury, stratix, stratixII,
cyclone), Xilinx FPGAs, Lucent, Atmel etc.  Other FPGAs (Actel, Quicklogic) are anti-fuse
based, and can only be programmed once.  Non-volatile technologies, including the flash
technologies used in many CPLDs do have a limit on the number of times they can be
reprogrammed, as do EPROMs.  The mainstream FPGAs however are either SRAM based and are
infinitely reprogrammable, or they are anti-fuse and are one-time programmed.  I can't
think of any FPGAs (not CPLDs) that are not one of these and are still available today.





Mark Sandford wrote:

> Ray Andraka <ray@andraka.com> wrote in message news:<4060482F.8F69BB5@andraka.com>...
> > There is no limit to the reconfiguration on FPGAs.  The configuration is held in
> > registers similar to the flip-flops in the design (although the registers are
> > designed to be slower and therefore more robust against unintended upsets).
> > They won't wear out.  The only life limited item would be the EPROM you load the
> > FPGA from.
>
> This is not completely correct, Xilinx and Altera (and others) are
> SRAM based and can be reprogrammed infinitely, but others are FLASH or
> Anti-fuse based and thus can only be programmed a limited number of
> times.  Flash can be reprogrammed a large number of times in the range
> 10,000 to 100,000 (see the datasheet for details).  Anti-fuse types
> are like blowing a fuse and you can program one time only and if there
> is a mistake or an upgrade is wanted it is now only a not so heavy
> paperwieght.
>
>
> > Hendra Gunawan wrote:
> >
> > > Hi folks,
> > > typically how many times can I burn/download an FPGA before it becomes
> > > unreliable. I read Xilinx FPGA datasheets and couldn't find the answer.
> > > I am asking because I am wondering if someone is going to make a commercial
> > > FPGA product that need to be frequently turned on and off, this can be an
> > > issue. Every time the device is turned on, the FPGA chip need to be
> > > redownloaded from an EPROM. If the device is turned on and off 3 or 4 times
> > > a day and the device is used every day, and if the device can only be
> > > reprogrammed 1000 times, then in less than a year the device can not be used
> > > anymore.
> > >
> > > Thanks!
> > >
> > > Hendra
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> >  "They that give up essential liberty to obtain a little
> >   temporary safety deserve neither liberty nor safety."
> >                                           -Benjamin Franklin, 1759

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 67963
Subject: Bus width between registers in IIR
From: "Sam \(rép. sans -no-sp-am\)" <totalsam-no-sp-am@hotmail.com>
Date: Tue, 23 Mar 2004 22:19:42 +0100
Links: << >>  << T >>  << A >>
Hi all !

Thank you for reading this message !

I would like to know how width are the busses between the registers of an
IIR filter (ie implemented in a FPGA), because these filters have coeffs >
1. I have seen that the result of b0*x(n-1) can be as large as 5e5 with a
simple sin as input signal !

Could anybody help me ??

thanks in advance !

Sam



Article: 67964
Subject: Re: How many times can I burn an FPGA?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 24 Mar 2004 09:20:16 +1200
Links: << >>  << T >>  << A >>
Ray Andraka wrote:

> I assumed he was talking about XILINX FPGAs since his post indicated he read teh XILINX
> data sheet and couldn't find a life limit.  I apparently was not clear on the EPROM life
> limit either (the number of write cycles, actually more specifically the number of erase
> cycles for and EPROM are limited, reads are not).  Just for the record:
> 
> so called SRAM FPGAs have no limit on the number of reconfigurations.  The configuration
> is held in flip-flops (granted, they are slow fat flip-flops for robustness), not in any
> non-volatile storage.  These include Altera FPGAs (10K, 20K, mercury, stratix, stratixII,
> cyclone), Xilinx FPGAs, Lucent, Atmel etc.  Other FPGAs (Actel, Quicklogic) are anti-fuse
> based, and can only be programmed once.  Non-volatile technologies, including the flash
> technologies used in many CPLDs do have a limit on the number of times they can be
> reprogrammed, as do EPROMs.  The mainstream FPGAs however are either SRAM based and are
> infinitely reprogrammable, or they are anti-fuse and are one-time programmed.  I can't
> think of any FPGAs (not CPLDs) that are not one of these and are still available today.

  The ProASIC perhaps ?
The distinction between CPLD and FPGA is getting 'fuzzier', with latest 
Lattice and Altera devices using a single chip, flash transfer approach,
and the MAX II has a FPGA LE fabric...
-jg


Article: 67965
Subject: Re: EDK 6.1 and MGT UCF Inst Parameters
From: Paulo Dutra <paulo.dutra@xilinx.com>
Date: Tue, 23 Mar 2004 13:22:51 -0800
Links: << >>  << T >>  << A >>
To find the known path. I run the design without the UCF.
Once processed through par, bring the design up in FPGA editor.
You can find all known components with instance paths.

Tony wrote:
> I probably should have been more explicit...
> 
> That <Insert attempted path here> is what i added in to indicate a
> wildcard that NONE of my attempted paths worked... I get a series of
> those exact messages containing the paths i tried.  I.e.
> 
> ERROR:NgdBuild:753 - Line 1074 in 'system.ucf': Could not find 
> instance(s)
>    'plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i' in the
> design. 
>    To suppress this error specify the correct instance name or remove
> the
>    constraint.
> ERROR:NgdBuild:753 - Line 1075 in 'system.ucf': Could not find 
> instance(s)
>    'system/plb_gigacore_1/auroracore_i/aurora_lane_0_ii' in the
> design. 
>    To suppress this error specify the correct instance name or remove
> the
>    constraint.
> ERROR:NgdBuild:753 - Line 1076 in 'system.ucf': Could not find 
> instance(s)
>    'plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i' in the
> design. 
>    To suppress this error specify the correct instance name or remove
> the
>    constraint.
> ....
> 
> 
> 
> Thanks,
> Tony
> 
> 
> On Mon, 22 Mar 2004 18:49:05 -0800, Paulo Dutra
> <Paulo.Dutra@xilinx.com> wrote:
> 
> 
>>It looks like ngdbuild is finding the wrong UCF. I think xps copies the 
>>UCF from the
>><proj>/data directory into <proj>/implementation directory. This wrong UCF
>>contains "<INSERT ATTEMPTED PATH HERE>" in the hierarchy path.
>>
>>Tony wrote:
>>
>>
>>>I am constructing a user aurora protocol core based on the PLB SSP1
>>>reference.  It utilizes the MGT on a V2P-7.  
>>>I am having difficulty setting the "INST" parameters in the ucf file.
>>>I do not know the path to the MGT parameters.
>>>I've tried many locations... a subset of the attempts is:
>>>
>>>INST plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i
>>>LOC=GT_X0Y1;
>>>INST system/plb_gigacore_1/auroracore_i/aurora_lane_0_i
>>>ALIGN_COMMA_MSB          = ...;
>>>INST "plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i"
>>>CHAN_BOND_MODE           = ...;
>>>INST system/plb_gigacore_1/auroracore_i/aurora_lane_0_i
>>>CHAN_BOND_ONE_SHOT       = ...;
>>>INST system/plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i
>>>CHAN_BOND_SEQ_1_1        = ...;
>>>
>>>
>>>My core is instantiated in the EDK as plb_gigacore_1.
>>>the path to the aurora core in the VHDL files is as follows:
>>>
>>>
>>>plb_core_ssp1_ref.vhd defines USER_LOGIC_I : user_logic
>>>user_logic.vhd defines auroracore_i : auroracore
>>>auroracore.vhd defines lane_0_mgt_i : GT_CUSTOM
>>>and        global_logic_i : GLOBAL_LOGIC
>>>
>>>The error I receive is always:
>>>ERROR:NgdBuild:753 - Line 1074 in 'system.ucf': Could not find
>>>instance(s)
>>>  '<INSERT ATTEMPTED PATH HERE>/auroracore_i/aurora_lane_0_i' in the
>>>design. 
>>>  To suppress this error specify the correct instance name or remove
>>>the
>>>  constraint.
>>>
>>>
>>> 
>>>
> 
> 


-- 
/ 7\'7 Paulo Dutra (paulo.dutra@xilinx.com)
\ \ `  Xilinx                              hotline@xilinx.com
/ /    2100 Logic Drive                    http://www.xilinx.com
\_\/.\ San Jose, California 95124-3450 USA


Article: 67966
Subject: Re: Quartus with AMD64 processors?
From: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
Date: Tue, 23 Mar 2004 21:43:40 GMT
Links: << >>  << T >>  << A >>
Petter Gustad wrote:

> "Nial Stewart" <nial@nialstewartdevelopments.co.uk> writes:
> 
>> I'm sure I've read here about problems running Quartus with
>> one/some of AMD's 64 bits processors. I think the problem
>> was a script checking the processor and crashing out
>> because it didn't recognise the AMD64.
> 
> This was the case running the Linux version of Quartus on AMD64
> systems. I don't have access to Windows based AMD64 based systems.
> 
>> Does anyone know if this has been fixed? Do all versions of
>> Quartus work with 64 bit processors (specifically Athlon64s)?
> 
> I don't think so. Maybe somebody from Altera could confirm this. I
> still get the same message:
> 
> 
> $quartus_sh -h
> Unknown Linux processor
> MWARCH: Undefined variable.
> MWCURRENT_LIBPATH: Undefined variable.

What happens if you define these?

> 
> This is very sad news since the AMD64 based systems are one of the
> best price/performance systems available today, e.g. see
> http://tinyurl.com/234d8 Not only that, but it seems like it got even
> worse. It wont even run on my old Athlon system:
> 
> The Quartus II software is optimized for the Intel Pentium III processor
> and newer processors.  The required extensions were not found on:
> 'AMD Athlon(tm) Processor'
> 
> :-(
> 
> On a Xeon based system I get:
> 
> quartus_sh -h
> Quartus II Shell
> Version 4.0 Build 190 1/28/2004 SJ Full Version
> ...

Quartus II might be compiled with the Intel compiler...

Opteron / Athlon 64 has SSE2 but the Intel produced code
checks if the processor is an _Intel_ with SSE2 - if not
it refuses to run...
        There was a long thread on comp.arch about this
        issue...
        Patcing the binary to remove the check got
        it to run.

/RogerL

-- 
Roger Larsson
Skellefteċ
Sweden

Article: 67967
Subject: Re: Logiclock TCL flow for Quartus II
From: pguzy@altera.com (Przemek Guzy)
Date: 23 Mar 2004 13:51:08 -0800
Links: << >>  << T >>  << A >>
Hi Peter,

I realize now what you were doing wrong.  In the command line help for
logiclock back-annotate it says:


"-routing: Back-annotate the LogicLock region's routing.  Must use
-lock, -no_demote_lab.  Must not use -no_contents"
        

So when you want to back annotate routing, you should type:

logiclock_back_annotate -routing -lock -no_demote_lab -region
my_region_name


Now for your question about export.  Yes export generally does very
little to the ESF.  However, in cases where the project has multiple
ESFs then export will merge them all into one.  However, export does
make significant changes to the RCF.  The exported RCF is different
from the back annotated RCF.  The back annotated one is suitable in a
flow where you are trying to preserve routing within a project.  While
the exported RCF is more suitable to an export/import flow.  The
differences are due to VQMs and routing to and from IO pins.

Unfortunately, there is not specific TCL guide to using LogicLock.  I
would recommend:

1) read the handbook.  (I believe you said you already did)
2) go to www.altera.com and search for TCL.  There are some general
TCL guides here but nothing specific to LogicLock
3) quartus_sh --qhelp is the official help.  

The TCL interface is geared towards the advanced user, so the help is
really meant for the GUI user.

Please continue asking questions here in the newsgroup, and I will try
to answer them for you.

Thanks


Przemek Guzy
Altera Corp.

Article: 67968
Subject: IBUFDS -> BUFG
From: Tony <tonym_98@nospam_hotmail.com>
Date: Tue, 23 Mar 2004 21:52:27 GMT
Links: << >>  << T >>  << A >>
Hello, 

I have a UCF problem regarding pin locations.
I am creating a custom PLB core that utilizes the MGT on an XV2P7.  I
have dug my way through and up into the NgdBuild stage.  The system is
using the system_hello EDK 6.1 ML300 reference design with
audio&ethernet stripped out to make room for the MGT core.  We are
trying to use either the 125 MHz clock on Ppin-B14/Npin-C14 (4S/5P) or
the 156.25 MHz clock on Ppin-AD14/Npin-AE14 (6P/7S).

Errors are generated when using either B14/C14 or AD14/AE14.  I am not
sure what to do to fix the problem.  Somehow IBUF's are being
instantiated, but nowhere in my code indicates this(maybe in EDK it
throws it in there?).  There are similar tech solutions on xilinx.com
that tell you how to fix Synplicity problems that would create a
IBUFDS and IBUF on the same pad (and generate a similar problem to
mine), but I am using ISE 6.1.03 to work with EDK 6.1 sp2.

Thanks,

Tony

PLB Core MPD file:
...
PORT RXP           	= "",		DIR = I, IOB_STATE=BUF
PORT RXN           	= "",		DIR = I, IOB_STATE=BUF
PORT TXP            	= "",		DIR = O, IOB_STATE=BUF
PORT TXN            	= "",		DIR = O, IOB_STATE=BUF
PORT TOP_BREF_CLK_P	= "",		DIR = I
PORT TOP_BREF_CLK_N	= "",		DIR = I

The port list in EDK  ties TOP_BREF_CLK_P/TOP_BREF_CLK_N to
BREF_CLK_P/BREF_CLK_N external output pins.

I believe I have correctly defined the VHDL instances of the 
entity user_logic is
...
    RXP              : in std_logic;
    RXN              : in std_logic;
    TXP              : out std_logic;
    TXN              : out std_logic;
    TOP_BREF_CLK_P   : in std_logic;
    TOP_BREF_CLK_N	 : in std_logic
  );
end entity user_logic;

architecture IMP of User_Logic is

signal TOP_BREF_CLK_i	 : std_logic;	-- FAST reference clock going
to MGT xcvr & buffered Ref clock
signal USER_CLK_i		 : std_logic;	-- Buffered FAST
reference clock for user and MGT logic
...
begin

	-- Differential Clock Buffers for top clock input
    diff_clk_buff_i : IBUFGDS_LVDS_25  
    port map (
        I  => TOP_BREF_CLK_P,
        IB => TOP_BREF_CLK_N,
        O  => TOP_BREF_CLK_i
    );


    -- Bufg used to drive user clk on global clock net
    user_clock_bufg_i : BUFG  
    port map (
        I  => TOP_BREF_CLK_i,
        O  => USER_CLK_i
    );

The TOP_BREF_CLK_i goes direct to the MGT, while the USER_CLK_i goes
anywhere user logic requires the fast clock.



UCF settigns:
...
# 156.25 MHz Diff Crystal Connection
#same errors generated with/without IOSTANDARD spec.
NET BREF_CLK_P IOSTANDARD = LVDS_25;
NET BREF_CLK_N IOSTANDARD = LVDS_25;
NET BREF_CLK_P  LOC=AD14;
NET BREF_CLK_N  LOC=AE14;


Error Output:
...
ERROR:NgdBuild:455 - logical net 'BREF_CLK_N_IBUF' has multiple
drivers. The
   possible drivers causing this are:
     pin O on block ibuf_245 with type IBUF,
     pin PAD on block BREF_CLK_N_IBUF with type PAD
WARNING:NgdBuild:463 - input pad net 'BREF_CLK_N_IBUF' has an illegal
input
   buffer
ERROR:NgdBuild:466 - input pad net 'BREF_CLK_N_IBUF' has illegal
connection.
   Possible pins causing this are:
     pin O on block ibuf_245 with type IBUF
ERROR:NgdBuild:455 - logical net 'BREF_CLK_P_IBUF' has multiple
drivers. The
   possible drivers causing this are:
     pin O on block ibuf_244 with type IBUF,
     pin PAD on block BREF_CLK_P_IBUF with type PAD
WARNING:NgdBuild:463 - input pad net 'BREF_CLK_P_IBUF' has an illegal
input
   buffer
ERROR:NgdBuild:466 - input pad net 'BREF_CLK_P_IBUF' has illegal
connection.
   Possible pins causing this are:
     pin O on block ibuf_244 with type IBUF


Article: 67969
Subject: Re: EDK 6.1 and MGT UCF Inst Parameters
From: Tony <tonym_98@nospam_hotmail.com>
Date: Tue, 23 Mar 2004 21:54:08 GMT
Links: << >>  << T >>  << A >>
Wow!  Thanks!  Excellent advice and was able to find the correct path.


Regards,
Tony

On Tue, 23 Mar 2004 13:22:51 -0800, Paulo Dutra
<paulo.dutra@xilinx.com> wrote:

>To find the known path. I run the design without the UCF.
>Once processed through par, bring the design up in FPGA editor.
>You can find all known components with instance paths.
>
>Tony wrote:
>> I probably should have been more explicit...
>> 
>> That <Insert attempted path here> is what i added in to indicate a
>> wildcard that NONE of my attempted paths worked... I get a series of
>> those exact messages containing the paths i tried.  I.e.
>> 
>> ERROR:NgdBuild:753 - Line 1074 in 'system.ucf': Could not find 
>> instance(s)
>>    'plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i' in the
>> design. 
>>    To suppress this error specify the correct instance name or remove
>> the
>>    constraint.
>> ERROR:NgdBuild:753 - Line 1075 in 'system.ucf': Could not find 
>> instance(s)
>>    'system/plb_gigacore_1/auroracore_i/aurora_lane_0_ii' in the
>> design. 
>>    To suppress this error specify the correct instance name or remove
>> the
>>    constraint.
>> ERROR:NgdBuild:753 - Line 1076 in 'system.ucf': Could not find 
>> instance(s)
>>    'plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i' in the
>> design. 
>>    To suppress this error specify the correct instance name or remove
>> the
>>    constraint.
>> ....
>> 
>> 
>> 
>> Thanks,
>> Tony
>> 
>> 
>> On Mon, 22 Mar 2004 18:49:05 -0800, Paulo Dutra
>> <Paulo.Dutra@xilinx.com> wrote:
>> 
>> 
>>>It looks like ngdbuild is finding the wrong UCF. I think xps copies the 
>>>UCF from the
>>><proj>/data directory into <proj>/implementation directory. This wrong UCF
>>>contains "<INSERT ATTEMPTED PATH HERE>" in the hierarchy path.
>>>
>>>Tony wrote:
>>>
>>>
>>>>I am constructing a user aurora protocol core based on the PLB SSP1
>>>>reference.  It utilizes the MGT on a V2P-7.  
>>>>I am having difficulty setting the "INST" parameters in the ucf file.
>>>>I do not know the path to the MGT parameters.
>>>>I've tried many locations... a subset of the attempts is:
>>>>
>>>>INST plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i
>>>>LOC=GT_X0Y1;
>>>>INST system/plb_gigacore_1/auroracore_i/aurora_lane_0_i
>>>>ALIGN_COMMA_MSB          = ...;
>>>>INST "plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i"
>>>>CHAN_BOND_MODE           = ...;
>>>>INST system/plb_gigacore_1/auroracore_i/aurora_lane_0_i
>>>>CHAN_BOND_ONE_SHOT       = ...;
>>>>INST system/plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i
>>>>CHAN_BOND_SEQ_1_1        = ...;
>>>>
>>>>
>>>>My core is instantiated in the EDK as plb_gigacore_1.
>>>>the path to the aurora core in the VHDL files is as follows:
>>>>
>>>>
>>>>plb_core_ssp1_ref.vhd defines USER_LOGIC_I : user_logic
>>>>user_logic.vhd defines auroracore_i : auroracore
>>>>auroracore.vhd defines lane_0_mgt_i : GT_CUSTOM
>>>>and        global_logic_i : GLOBAL_LOGIC
>>>>
>>>>The error I receive is always:
>>>>ERROR:NgdBuild:753 - Line 1074 in 'system.ucf': Could not find
>>>>instance(s)
>>>>  '<INSERT ATTEMPTED PATH HERE>/auroracore_i/aurora_lane_0_i' in the
>>>>design. 
>>>>  To suppress this error specify the correct instance name or remove
>>>>the
>>>>  constraint.
>>>>
>>>>
>>>> 
>>>>
>> 
>> 


Article: 67970
Subject: RE: IBUFDS -> BUFG
From: Matthew E Rosenthal <mer2@andrew.cmu.edu>
Date: Tue, 23 Mar 2004 17:27:18 -0500 (EST)
Links: << >>  << T >>  << A >>
Tony,
I had similiar pin issues when I switched my design from the ml300 to a
memec board.
I am a little new to MGTs so bear with me.  When instantianting a MGT you
have two places you have to tell it which clock inputs you are using.
1.  in the UCF file under a parameter that looks similiar to
INST instname*mgt REF_CLK_V_SEL = 1
2.  in your HDL instantiation of your MGT you should have a parameter that
looks similiar to
REFCLKSEL => '1'

Between the two places for each of those parameters there are 4
options you can send the clock input into the MGT.

So there are 4 locations you can send a clock into a MGT
REFCLK, REFCLK2, BREFCLK and BREFCLK2

and these inputs can only be mapped to certain pins on the fpga
so if your inputs are coming in on B14 and C14 you have to determine which
location on the MGT to send that too.

You need to determine which pin locations can go to which clock input and
set all the values appropriately.

I hope this helps

Matt

---------- Forwarded message ----------
Date: Tue, 23 Mar 2004 21:52:27 GMT
From: Tony <tonym_98@nospam>
Newsgroups: comp.arch.fpga
Subject: IBUFDS -> BUFG

Hello,

I have a UCF problem regarding pin locations.
I am creating a custom PLB core that utilizes the MGT on an XV2P7.  I
have dug my way through and up into the NgdBuild stage.  The system is
using the system_hello EDK 6.1 ML300 reference design with
audio&ethernet stripped out to make room for the MGT core.  We are
trying to use either the 125 MHz clock on Ppin-B14/Npin-C14 (4S/5P) or
the 156.25 MHz clock on Ppin-AD14/Npin-AE14 (6P/7S).

Errors are generated when using either B14/C14 or AD14/AE14.  I am not
sure what to do to fix the problem.  Somehow IBUF's are being
instantiated, but nowhere in my code indicates this(maybe in EDK it
throws it in there?).  There are similar tech solutions on xilinx.com
that tell you how to fix Synplicity problems that would create a
IBUFDS and IBUF on the same pad (and generate a similar problem to
mine), but I am using ISE 6.1.03 to work with EDK 6.1 sp2.

Thanks,

Tony

PLB Core MPD file:
...
PORT RXP           	= "",		DIR = I, IOB_STATE=BUF
PORT RXN           	= "",		DIR = I, IOB_STATE=BUF
PORT TXP            	= "",		DIR = O, IOB_STATE=BUF
PORT TXN            	= "",		DIR = O, IOB_STATE=BUF
PORT TOP_BREF_CLK_P	= "",		DIR = I
PORT TOP_BREF_CLK_N	= "",		DIR = I

The port list in EDK  ties TOP_BREF_CLK_P/TOP_BREF_CLK_N to
BREF_CLK_P/BREF_CLK_N external output pins.

I believe I have correctly defined the VHDL instances of the
entity user_logic is
...
    RXP              : in std_logic;
    RXN              : in std_logic;
    TXP              : out std_logic;
    TXN              : out std_logic;
    TOP_BREF_CLK_P   : in std_logic;
    TOP_BREF_CLK_N	 : in std_logic
  );
end entity user_logic;

architecture IMP of User_Logic is

signal TOP_BREF_CLK_i	 : std_logic;	-- FAST reference clock going
to MGT xcvr & buffered Ref clock
signal USER_CLK_i		 : std_logic;	-- Buffered FAST
reference clock for user and MGT logic
...
begin

	-- Differential Clock Buffers for top clock input
    diff_clk_buff_i : IBUFGDS_LVDS_25
    port map (
        I  => TOP_BREF_CLK_P,
        IB => TOP_BREF_CLK_N,
        O  => TOP_BREF_CLK_i
    );


    -- Bufg used to drive user clk on global clock net
    user_clock_bufg_i : BUFG
    port map (
        I  => TOP_BREF_CLK_i,
        O  => USER_CLK_i
    );

The TOP_BREF_CLK_i goes direct to the MGT, while the USER_CLK_i goes
anywhere user logic requires the fast clock.



UCF settigns:
...
# 156.25 MHz Diff Crystal Connection
#same errors generated with/without IOSTANDARD spec.
NET BREF_CLK_P IOSTANDARD = LVDS_25;
NET BREF_CLK_N IOSTANDARD = LVDS_25;
NET BREF_CLK_P  LOC=AD14;
NET BREF_CLK_N  LOC=AE14;


Error Output:
...
ERROR:NgdBuild:455 - logical net 'BREF_CLK_N_IBUF' has multiple
drivers. The
   possible drivers causing this are:
     pin O on block ibuf_245 with type IBUF,
     pin PAD on block BREF_CLK_N_IBUF with type PAD
WARNING:NgdBuild:463 - input pad net 'BREF_CLK_N_IBUF' has an illegal
input
   buffer
ERROR:NgdBuild:466 - input pad net 'BREF_CLK_N_IBUF' has illegal
connection.
   Possible pins causing this are:
     pin O on block ibuf_245 with type IBUF
ERROR:NgdBuild:455 - logical net 'BREF_CLK_P_IBUF' has multiple
drivers. The
   possible drivers causing this are:
     pin O on block ibuf_244 with type IBUF,
     pin PAD on block BREF_CLK_P_IBUF with type PAD
WARNING:NgdBuild:463 - input pad net 'BREF_CLK_P_IBUF' has an illegal
input
   buffer
ERROR:NgdBuild:466 - input pad net 'BREF_CLK_P_IBUF' has illegal
connection.
   Possible pins causing this are:
     pin O on block ibuf_244 with type IBUF


Article: 67971
Subject: Re: PCI Development Board
From: Bassman59a@yahoo.com (Andy Peters)
Date: 23 Mar 2004 14:42:07 -0800
Links: << >>  << T >>  << A >>
"Spike" <me.hates:spam@me.net> wrote in message news:<YgD7c.53175$mU6.222519@newsb.telia.net>...
> Thanks for you tip, I'll take it under consideration.
> 
> Has anyone tried this one: http://www.plxtech.com/tools/rdk/9030rdk-lite.htm

I didn't use the RDK, but I did do a board based on the 9030.  I wrote
a pretty damn complete bus-functional model of the 9030's local bus
(PLX wanted it but we wouldn't give it to 'em).  It all came together
quite easily.
 
> Does PLX PCI chips require some sort of EEPROM to store PCI configuration
> space or any other information, if so what kind of ROM is needed?

Yes, you'll need a serial EEPROM.  It holds not only the PCI
configuration info, but some other configuration info used by the chip
(things like local-bus sizes, wait state info, chip-select info, etc.)
 Download the data sheets from PLX and everything will be revealed.

-a

Article: 67972
Subject: Re: Bus width between registers in IIR
From: Jerry Avins <jya@ieee.org>
Date: Tue, 23 Mar 2004 18:03:15 -0500
Links: << >>  << T >>  << A >>
Sam (rép. sans -no-sp-am) wrote:
> Hi all !
> 
> Thank you for reading this message !
> 
> I would like to know how width are the busses between the registers of an
> IIR filter (ie implemented in a FPGA), because these filters have coeffs >
> 1. I have seen that the result of b0*x(n-1) can be as large as 5e5 with a
> simple sin as input signal !
> 
> Could anybody help me ??
> 
> thanks in advance !
> 
> Sam

FPGA stands for field-programmable gate array. With one, you implement
whatever circuit you design (or choose). The number of bits in a design
is whatever the designer decides. In parallel designs, the width of the
busses is the bit count. In bit-serial designs, those numbers are
uncoupled. With proper scaling, the size of a number and the bit count
aren't necessarily related.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ


Article: 67973
Subject: Re: IBUFDS -> BUFG
From: Tony <tonym_98@nospam_hotmail.com>
Date: Tue, 23 Mar 2004 23:46:25 GMT
Links: << >>  << T >>  << A >>
Thanks for the reply Matt,

I took a look again at the ug024 pdf, and while REFCLKSEL was = 0 (to
select brefclk, not brefclk2) and the ucf had REF_CLK_V_SEL=>1 (select
brefclk_x and not refclk_x), i think the MGT instantiation was messed
up. 

I relooked at the ML300 CPU schematics and GIGE0 uses pin A6/A7/A4/A5
for its RX/TX.  I didnt readily find it in the V2P User Guide so I
guessed it used MGT X0Y1... it was actually the other side of the
chip, X3Y1, and since the brefclks could only be used in that same
quadrant, I have a feeling that this may have played a role.  I'll
repost with my results after the changes.

Tony


On Tue, 23 Mar 2004 17:27:18 -0500 (EST), Matthew E Rosenthal
<mer2@andrew.cmu.edu> wrote:

>Tony,
>I had similiar pin issues when I switched my design from the ml300 to a
>memec board.
>I am a little new to MGTs so bear with me.  When instantianting a MGT you
>have two places you have to tell it which clock inputs you are using.
>1.  in the UCF file under a parameter that looks similiar to
>INST instname*mgt REF_CLK_V_SEL = 1
>2.  in your HDL instantiation of your MGT you should have a parameter that
>looks similiar to
>REFCLKSEL => '1'
>
>Between the two places for each of those parameters there are 4
>options you can send the clock input into the MGT.
>
>So there are 4 locations you can send a clock into a MGT
>REFCLK, REFCLK2, BREFCLK and BREFCLK2
>
>and these inputs can only be mapped to certain pins on the fpga
>so if your inputs are coming in on B14 and C14 you have to determine which
>location on the MGT to send that too.
>
>You need to determine which pin locations can go to which clock input and
>set all the values appropriately.
>
>I hope this helps
>
>Matt
>
>---------- Forwarded message ----------
>Date: Tue, 23 Mar 2004 21:52:27 GMT
>From: Tony <tonym_98@nospam>
>Newsgroups: comp.arch.fpga
>Subject: IBUFDS -> BUFG
>
>Hello,
>
>I have a UCF problem regarding pin locations.
>I am creating a custom PLB core that utilizes the MGT on an XV2P7.  I
>have dug my way through and up into the NgdBuild stage.  The system is
>using the system_hello EDK 6.1 ML300 reference design with
>audio&ethernet stripped out to make room for the MGT core.  We are
>trying to use either the 125 MHz clock on Ppin-B14/Npin-C14 (4S/5P) or
>the 156.25 MHz clock on Ppin-AD14/Npin-AE14 (6P/7S).
>
>Errors are generated when using either B14/C14 or AD14/AE14.  I am not
>sure what to do to fix the problem.  Somehow IBUF's are being
>instantiated, but nowhere in my code indicates this(maybe in EDK it
>throws it in there?).  There are similar tech solutions on xilinx.com
>that tell you how to fix Synplicity problems that would create a
>IBUFDS and IBUF on the same pad (and generate a similar problem to
>mine), but I am using ISE 6.1.03 to work with EDK 6.1 sp2.
>
>Thanks,
>
>Tony
>
>PLB Core MPD file:
>...
>PORT RXP           	= "",		DIR = I, IOB_STATE=BUF
>PORT RXN           	= "",		DIR = I, IOB_STATE=BUF
>PORT TXP            	= "",		DIR = O, IOB_STATE=BUF
>PORT TXN            	= "",		DIR = O, IOB_STATE=BUF
>PORT TOP_BREF_CLK_P	= "",		DIR = I
>PORT TOP_BREF_CLK_N	= "",		DIR = I
>
>The port list in EDK  ties TOP_BREF_CLK_P/TOP_BREF_CLK_N to
>BREF_CLK_P/BREF_CLK_N external output pins.
>
>I believe I have correctly defined the VHDL instances of the
>entity user_logic is
>...
>    RXP              : in std_logic;
>    RXN              : in std_logic;
>    TXP              : out std_logic;
>    TXN              : out std_logic;
>    TOP_BREF_CLK_P   : in std_logic;
>    TOP_BREF_CLK_N	 : in std_logic
>  );
>end entity user_logic;
>
>architecture IMP of User_Logic is
>
>signal TOP_BREF_CLK_i	 : std_logic;	-- FAST reference clock going
>to MGT xcvr & buffered Ref clock
>signal USER_CLK_i		 : std_logic;	-- Buffered FAST
>reference clock for user and MGT logic
>...
>begin
>
>	-- Differential Clock Buffers for top clock input
>    diff_clk_buff_i : IBUFGDS_LVDS_25
>    port map (
>        I  => TOP_BREF_CLK_P,
>        IB => TOP_BREF_CLK_N,
>        O  => TOP_BREF_CLK_i
>    );
>
>
>    -- Bufg used to drive user clk on global clock net
>    user_clock_bufg_i : BUFG
>    port map (
>        I  => TOP_BREF_CLK_i,
>        O  => USER_CLK_i
>    );
>
>The TOP_BREF_CLK_i goes direct to the MGT, while the USER_CLK_i goes
>anywhere user logic requires the fast clock.
>
>
>
>UCF settigns:
>...
># 156.25 MHz Diff Crystal Connection
>#same errors generated with/without IOSTANDARD spec.
>NET BREF_CLK_P IOSTANDARD = LVDS_25;
>NET BREF_CLK_N IOSTANDARD = LVDS_25;
>NET BREF_CLK_P  LOC=AD14;
>NET BREF_CLK_N  LOC=AE14;
>
>
>Error Output:
>...
>ERROR:NgdBuild:455 - logical net 'BREF_CLK_N_IBUF' has multiple
>drivers. The
>   possible drivers causing this are:
>     pin O on block ibuf_245 with type IBUF,
>     pin PAD on block BREF_CLK_N_IBUF with type PAD
>WARNING:NgdBuild:463 - input pad net 'BREF_CLK_N_IBUF' has an illegal
>input
>   buffer
>ERROR:NgdBuild:466 - input pad net 'BREF_CLK_N_IBUF' has illegal
>connection.
>   Possible pins causing this are:
>     pin O on block ibuf_245 with type IBUF
>ERROR:NgdBuild:455 - logical net 'BREF_CLK_P_IBUF' has multiple
>drivers. The
>   possible drivers causing this are:
>     pin O on block ibuf_244 with type IBUF,
>     pin PAD on block BREF_CLK_P_IBUF with type PAD
>WARNING:NgdBuild:463 - input pad net 'BREF_CLK_P_IBUF' has an illegal
>input
>   buffer
>ERROR:NgdBuild:466 - input pad net 'BREF_CLK_P_IBUF' has illegal
>connection.
>   Possible pins causing this are:
>     pin O on block ibuf_244 with type IBUF


Article: 67974
Subject: Re: Bus width between registers in IIR
From: Ray Andraka <ray@andraka.com>
Date: Tue, 23 Mar 2004 19:15:06 -0500
Links: << >>  << T >>  << A >>
Depends on your filter design.  Implementing an IIR filter in fixed point
usually has to use a rather wide word, and care needs to be taken in the
selection of the coefficients in order to avoid nasty quantization effects.
Implementation in an FPGA has little to do with the filter design other than
the physical realization of it.

"Sam (rép. sans -no-sp-am)" wrote:

> Hi all !
>
> Thank you for reading this message !
>
> I would like to know how width are the busses between the registers of an
> IIR filter (ie implemented in a FPGA), because these filters have coeffs >
> 1. I have seen that the result of b0*x(n-1) can be as large as 5e5 with a
> simple sin as input signal !
>
> Could anybody help me ??
>
> thanks in advance !
>
> Sam

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759





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