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 111150

Article: 111150
Subject: Re: Taking forever to synthesise (XILINX ISE 8.1i)
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Mon, 30 Oct 2006 10:25:58 -0700
Links: << >>  << T >>  << A >>
daver2 wrote:
> I am implementing an extremely old logic design (circa 1965!) on a
> Xilinx Virtex 4 (XC4VLX25).
> 
> For those interested - it is the logic for the computer that flew to
> the moon and back! The design is based on approximately 5,000 3-input
> NOR gates and not a flip flop in sight! For the circuit diagrams see
> website 'http://klabs.org/history/ech/agc_schematics/index.htm'.
> 

Does the design implement flops using NORs with feedback?  If so, that 
could be an issue.  The ISE tools don't like combinational feedback.
-KEvin

Article: 111151
Subject: Programming Virtex II Pro Eval Board
From: ramakrishnan.vijayakumar@gmail.com
Date: 30 Oct 2006 09:43:31 -0800
Links: << >>  << T >>  << A >>
Hi,
   I hope someone would be able to help me with my issue. I have a
Xilinx Virtex II Pro Eval board from Avnet. The board has a serial
interface to program it. I bought a Serial to USB Converter cable from
RadioShack to try to program the FPGA from Impact. I have had no luck
in doing this so far. Impact doesn't recognize the cable and it always
fails. Can someone point me on how would I be able to program the FPGA
with the Serial-USB Converter cable?. 

Ram.


Article: 111152
Subject: Question about importing modules to XPS.
From: "cathy" <hy34@njit.edu>
Date: 30 Oct 2006 09:50:20 -0800
Links: << >>  << T >>  << A >>
Hi, all:

I want to incorporate moduleA and moduleB  to XPS and connected them
with microblaze. ModuleA and ModuleB have connection with microblaze
through FSL and OPB separately, and also, moduleA and Moduleb have
connection between themselves. My question is: how to describe the
connection between moduleA/B in XPS.
Thanks a lot, 
Cathy


Article: 111153
Subject: Re: Picoblaze simulation
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 30 Oct 2006 10:06:07 -0800
Links: << >>  << T >>  << A >>
aravind wrote:
> Does anyone know how to simulate the picoblaze processor in
> modelsimXE(xilinx specific version)
> Is it possible?

http://www.mediatronix.com/pBlazeIDE.htm


Article: 111154
Subject: Re: Survey: simulator usage
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 30 Oct 2006 10:09:49 -0800
Links: << >>  << T >>  << A >>
Evan Lavelle wrote:

> - What are MicroWriteBus() and MicroReadBus()? I can do macros and
> pass parameters to the macros; you can call the macros from wherever
> you want in the vector file. I can also do basic C-like control
> structures - looping, branching based on tested values, and so on.

Shorthand notation for "generic test-bench procedure/task call that
performs a read or write on my microprocessor's external bus, from the
micro's point-of-view."

-a


Article: 111155
Subject: Re: Chipscope and debugger through the same JTAG port
From: "MM" <mbmsv@yahoo.com>
Date: Mon, 30 Oct 2006 13:49:12 -0500
Links: << >>  << T >>  << A >>
"Joseph Samson" <user@example.net> wrote in message
news:wvK0h.24436$7I1.12748@newssvr27.news.prodigy.net...
>
> I run xmd and chipscope together all the time on the same JTAG port. In
> fact, recently I was debugging 2 different systems simultaneously with
> one JTAG cable. I'd plug into one system and do some xmd commands,
> unplug the flying leads, plug into the other board and trigger
> chipscope. Nither was confused.
>
> Did you have any timing errors after routing the chip with the chipscope
> inserted? That might cause errors in the ChipScope display.
>

Joseph,

I might have had a few timing errors, which could affect some of the
channels but not all... What kind of cable (USB, parallel, etc.) are you
using and what chip/CPU combination?

Thanks,
/Mikhail



Article: 111156
Subject: Re: On the Futility of Documentation Webcases ( Was: Xilinx documentation typos )
From: "rickman" <gnuarm@gmail.com>
Date: 30 Oct 2006 10:55:07 -0800
Links: << >>  << T >>  << A >>
Brian Davis wrote:
> Peter Alfke wrote:
> >  we may have different definitions of the word "nasty"
> <snip>
> > I wish these problems could be ventilated in a less aggressive tone,
> > but that may be a question of personal taste.
>
>  Since you continue to refer to my original post as "nasty"
> and now "agressive", I ask you once again to explain
> exactly what part of that post you found offensive.
>
>  I am hardly the first person on the newsgroup to express
> exactly these same opinions about the usefulness of WebCases,
> and your documentation system's handling of both customer
> feedback and long-known, yet poorly documented, problems.
>
>  My comments are based on 20 years of experience using
> Xilinx parts; during that time I have attempted to have Xilinx
> correct serious flaws in their documentation and/or software
> on several occasions, with no success, as described in my
> original post.

You might not want to go down this road.  The Xilinx reps in this group
are a bit quick to assume that others are posting with an attitude all
the while giving all the attitude in the world in their own posts.
Peter is actually one of the nicer guys, but he has his moments as you
have found.  I am of the opinion that it may be a bit of a cultural
thing at the company.  They seem to have developed a corporate opinion
over the years that they are the best and are better off being
defensive about their faults.  Of course this is not accurate as a
blanket statement.  There are many times when they are very helpful.
This is a comment about the "tone" of the replies you may get from time
to time.

My point is that it is not likely to be worth the effort to try calling
them out on the "tone" (or even substance) of their posts.


Article: 111157
Subject: Re: Taking forever to synthesise (XILINX ISE 8.1i)
From: "daver2" <davidroberts@siemens.com>
Date: 30 Oct 2006 11:01:34 -0800
Links: << >>  << T >>  << A >>

Kevin Neilson wrote:
> daver2 wrote:
> > I am implementing an extremely old logic design (circa 1965!) on a
> > Xilinx Virtex 4 (XC4VLX25).
> >
> > For those interested - it is the logic for the computer that flew to
> > the moon and back! The design is based on approximately 5,000 3-input
> > NOR gates and not a flip flop in sight! For the circuit diagrams see
> > website 'http://klabs.org/history/ech/agc_schematics/index.htm'.
> >
>
> Does the design implement flops using NORs with feedback?  If so, that
> could be an issue.  The ISE tools don't like combinational feedback.
> -KEvin

Kevin,

Yes, the design does use NOR gates with feedback to create the
flipflops - and yes I am getting warnings from XST about combinatorial
loops. I am (as we speak) going through the network that the
synthesiser has generated for the 4LUT's to see that what it has
generated is what should have been generated!

The original logic would have potentially suffered from unstable
oscillation and glitches if it had not been designed properly in the
first place so it is my belief that ISE is complaining about something
that won't occur in reality.

Dave


Article: 111158
Subject: Re: Taking forever to synthesise (XILINX ISE 8.1i)
From: "daver2" <davidroberts@siemens.com>
Date: 30 Oct 2006 11:06:27 -0800
Links: << >>  << T >>  << A >>

Tim wrote:
> daver2 wrote
> > I don't really want to change the logic to suite the tool as I am
> > trying to be as true to the original design as I can be. I have coded
> > the logic up in a similar manner to the following:
> ...
> ...
> > \37101\ <= not( \37105\ or \37102\ );
> > \37102\ <= not( \37101\ or CLOCK or \37103\ ) after gate_delay;
> > \37103\ <= not( \37102\ or CLOCK or \37104\ );
> > \37104\ <= not( \37103\ or \37106\ ); PHS2 <= \37104\;
>
> Can you write a Perl script to whizz through the code and extract the flops
> and latches?

Tim,

Thanks for the idea Tim. Let me think about that one for a while...

Dave


Article: 111159
Subject: Re: Chipscope and debugger through the same JTAG port
From: Joseph Samson <user@example.net>
Date: Mon, 30 Oct 2006 19:06:33 GMT
Links: << >>  << T >>  << A >>
MM wrote:
> Joseph,
> 
> I might have had a few timing errors, which could affect some of the
> channels but not all... What kind of cable (USB, parallel, etc.) are you
> using and what chip/CPU combination?
Parallel Cable IV running under XP, connecting to Virtex2Pro, Virtex4 
FX60 and Virtex 4 SX55.


---
Joe Samson
Pixel Velocity

Article: 111160
Subject: Re: On the Futility of Documentation Webcases ( Was: Xilinx documentation typos )
From: "Peter Alfke" <peter@xilinx.com>
Date: 30 Oct 2006 11:50:16 -0800
Links: << >>  << T >>  << A >>
Rickman, I disagree. I may be (overly?) sensitive to a nasty tone, and
I don't like to be called a  "Troll of Implausible Deniability".
Instead, I want to address the issues. I have funneled many comments
from this newsgroup to our support management. And they have
acknowledged them, and have admitted errors.
And we are working on improvements.
But as I wrote earlier, the parts are getting very complex and are
being used in many different ways. Making every user happy is our goal,
but I have been around long enough to relize that this is an elusive
goal.
Xilinx is listening and responding to this newsgroup, you have to give
us credit for that. Whether our "bedside manners" are always perfect is
another question. The "patients" don't always show perfect behavior
either...
Peter Alfke
===============================
On Oct 30, 10:55 am, "rickman" <gnu...@gmail.com> wrote:
> Brian Davis wrote:
> > Peter Alfke wrote:
> > >  we may have different definitions of the word "nasty"
> > <snip>
> > > I wish these problems could be ventilated in a less aggressive tone,
> > > but that may be a question of personal taste.
>
> >  Since you continue to refer to my original post as "nasty"
> > and now "agressive", I ask you once again to explain
> > exactly what part of that post you found offensive.
>
> >  I am hardly the first person on the newsgroup to express
> > exactly these same opinions about the usefulness of WebCases,
> > and your documentation system's handling of both customer
> > feedback and long-known, yet poorly documented, problems.
>
> >  My comments are based on 20 years of experience using
> > Xilinx parts; during that time I have attempted to have Xilinx
> > correct serious flaws in their documentation and/or software
> > on several occasions, with no success, as described in my
> > original post.You might not want to go down this road.  The Xilinx reps in this group
> are a bit quick to assume that others are posting with an attitude all
> the while giving all the attitude in the world in their own posts.
> Peter is actually one of the nicer guys, but he has his moments as you
> have found.  I am of the opinion that it may be a bit of a cultural
> thing at the company.  They seem to have developed a corporate opinion
> over the years that they are the best and are better off being
> defensive about their faults.  Of course this is not accurate as a
> blanket statement.  There are many times when they are very helpful.
> This is a comment about the "tone" of the replies you may get from time
> to time.
>
> My point is that it is not likely to be worth the effort to try calling
> them out on the "tone" (or even substance) of their posts.


Article: 111161
Subject: Re: clock multiplexor device
From: "Andy" <jonesandy@comcast.net>
Date: 30 Oct 2006 11:51:06 -0800
Links: << >>  << T >>  << A >>
If you're doing this because you don't have another two available pins
on the FPGA, you need a  bigger FPGA, or save pins somewhere else. I
would not go into a board design using more than 90-95% of the pins on
the FPGA. Now if I was updating a mature design or something like that,
I might allow that margin to get a little tighter. The flexibility and
reliability of doing this sort of thing, especially with clocks, inside
the FPGA (where the STA tools can manage your timing) is far superior
to trying to do it with an extra component on the board.

Andy


Elmo Fuchs wrote:
> Hi,
>
> I'm currently developing a PCB featuring a Xilinx Virtex-4 device. Unlinke
> the Virtex-II series they now offer the possibility to route various clock
> signals to several domains on the FPGA and select them locally by specific
> clock multiplexer inputs.
> Because of the restricted amount of available pins on the device I selected
> (Virtex-4 FX40 with 352 user I/Os) I would like to use just one clock input
> on each side of the FPGA, thereby saving clock multiplexer inputs which I
> can use as normal GPIOs, and use an external clock multiplexer instead for
> my 3 clocks.
> Has anyone made experience with such or similar solution? Has anyone used an
> external clock multiplexer device for frequencies up to 500 MHz, yet? Is
> there any recommendation which chip I could use for this application in
> terms of jitter, etc.? And by the way... is my approach advisable, at all?
> 
> Any comments are appreciated.
> 
> Regards Elmo


Article: 111162
Subject: Re: Survey: simulator usage
From: "Andy" <jonesandy@comcast.net>
Date: 30 Oct 2006 12:07:58 -0800
Links: << >>  << T >>  << A >>

Evan Lavelle wrote:
> Ok, is it worth any more than $0 now? :)

In a word, no.

Why go to the trouble of learning a new language to try to do things
like macros, loops, random stimulus, etc. when you have the power of
the VHDL language at your disposal in a VHDL testbench?  Now, if you
have vectors from an external model/simulation, those can be applied
with text-io relatively easily from within a vhdl testbench that will
run on any vhdl simulator.

My "unit level tests" are usually at a high enough level that I need a
lot more capability than is available in any vector based scripting
language.

Andy


From janvi@t-online.de Mon Oct 30 12:17:56 2006
Path: newssvr11.news.prodigy.com!newsdbm04.news.prodigy.com!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newshub.sdsu.edu!newsfeed.freenet.de!news.albasani.net!news.warperbbs.de!news.weisnix.org!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Message-Id: <45465df7$0$30329$9b4e6d93@newsspool1.arcor-online.net>
From: janka vietzen <janvi@t-online.de>
Subject: Profibus implementation?
Newsgroups: comp.arch.fpga
Date: Mon, 30 Oct 2006 21:17:56 +0100
User-Agent: KNode/0.10.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 5
Organization: Arcor
NNTP-Posting-Date: 30 Oct 2006 21:17:59 CET
NNTP-Posting-Host: 2426e695.newsspool1.arcor-online.net
X-Trace: DXC=[8RHHgkj\kg<6cDJZfMd_cic==]BZ:afn4Fo<]lROoRa^YC2XCjHcbiDd]5FP7@cFhFdWcRPJWW\aDVg6_Sj8ZmeV]^[o?7LY4b
X-Complaints-To: usenet-abuse@arcor.de
Xref: prodigy.net comp.arch.fpga:122126

Is there any implementation of the profibus protocol for FPGA/CPLD known? DP
V0 for cyclic traffic is sufficient. Preferably implementations for MachXO
or general VHDL. The Siemens Profibus Chip bothers a lot and muxed address
data bus only fits to old fashioned mikrokontrollers. 


Article: 111163
Subject: Re: Question about generic usage?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 30 Oct 2006 12:20:19 -0800
Links: << >>  << T >>  << A >>
fl wrote:
> Hi,
> I am learning VHDL from Mike's example Uart.vhd in ISE 8.2. For
> behavioral simulation, I can run Modelsim smoothly. 

> After I check the library work, I find the work.uart (for other than
> behavioral simulation) does not have char_len_g anymore (only the
> source, i.e. behavioral file has that generic definition). How to deal
> with this?

Choose one.

1. Skip the post-route sim because it is not normally
needed with a synchronous design.

2. Search and replace the _g identifiers with constants.

3. Open a case with Xilinx and ask them
   to fix whatever software generates test_uart.ndo

4. Write your own do script using vsim -G as shown
   in the reference testbench.

          -- Mike Treseler

Article: 111164
Subject: Re: Taking forever to synthesise (XILINX ISE 8.1i)
From: Ray Andraka <ray@andraka.com>
Date: Mon, 30 Oct 2006 15:22:55 -0500
Links: << >>  << T >>  << A >>
daver2 wrote:
> Kevin Neilson wrote:
> 
>>daver2 wrote:
>>
>>>I am implementing an extremely old logic design (circa 1965!) on a
>>>Xilinx Virtex 4 (XC4VLX25).
>>>
>>>For those interested - it is the logic for the computer that flew to
>>>the moon and back! The design is based on approximately 5,000 3-input
>>>NOR gates and not a flip flop in sight! For the circuit diagrams see
>>>website 'http://klabs.org/history/ech/agc_schematics/index.htm'.
>>>
>>
>>Does the design implement flops using NORs with feedback?  If so, that
>>could be an issue.  The ISE tools don't like combinational feedback.
>>-KEvin
> 
> 
> Kevin,
> 
> Yes, the design does use NOR gates with feedback to create the
> flipflops - and yes I am getting warnings from XST about combinatorial
> loops. I am (as we speak) going through the network that the
> synthesiser has generated for the 4LUT's to see that what it has
> generated is what should have been generated!
> 
> The original logic would have potentially suffered from unstable
> oscillation and glitches if it had not been designed properly in the
> first place so it is my belief that ISE is complaining about something
> that won't occur in reality.
> 
> Dave
> 


Unfortunately, the original design depends on redundant cover terms and 
circuit delays to guarantee that proper operation.  FPGAs are not 
intended for what amounts to asynchronous logic.  Unlike the original 
design, the delays in the interconnect between the gates in the FPGA are 
significant and need to be considered when doing the design.  Unless you 
intend to had route this, you can't guarantee the delays are properly 
balanced to avoid the hazards the original design avoids.  Also, the 
FPGA tools generally do not leave the cover terms necessary to avoid 
glitch hazards in an async design without you explicitly forcing the 
tools to keep the terms.  You would be more likely to achieve success by 
  converting the flip-flops in the original design to FPGA flip-flops, 
something that kind of goes against your intent I suppose.

The ISE complaints are quite valid, and unless you take the pains to 
make sure the design is not reduced by the tools and that the routing 
delays are properly balanced and considered, you will likely not wind up 
with a working design.

In order to get the tools to keep from optimizing out stuff you need in 
there for hazard covers, you will at least need to put syn_keeps or the 
equivalent on each node in the original design, and may have to go as 
far as explicitly instantiating xilinx primitives with the proper init 
strings for each gate.  Instantiation might in the long run be the 
easier way to go, as it gives you a bit more control when it comes to 
placement.

Good luck.

Article: 111165
Subject: Re: Chipscope and debugger through the same JTAG port
From: "MM" <mbmsv@yahoo.com>
Date: Mon, 30 Oct 2006 16:15:22 -0500
Links: << >>  << T >>  << A >>
> Parallel Cable IV running under XP, connecting to Virtex2Pro, Virtex4
> FX60 and Virtex 4 SX55.

Hmm... The only difference I can see is that I am using a Platform Cable
USB... The chip is V4FX60 and I am using its PPC core...

/Mikhail



Article: 111166
Subject: Re: Taking forever to synthesise (XILINX ISE 8.1i)
From: "Andy" <jonesandy@comcast.net>
Date: 30 Oct 2006 13:40:51 -0800
Links: << >>  << T >>  << A >>
The original design was verified for the timing and behavior
(specifically glitch-free behavior) of hard NOR gates within the gate
array fabric that it was implemented on.

Change the NORs to luts, and change the timing (radically), and you no
longer have a reliable design, no matter how reliable the original was.

Combinatorial feedback loops in FPGAs are bad medicine.

If the original design had macros for every flop built out of NORs, you
could replace those macros with rtl code for conventional flops, and
then ISE would be happy, and so would you/your design. Otherwise your
going to have to be able to recognize the pattern of feedback in NOR
networks that makes a flop, then cut that out and replace it with a
conventional flop.

Andy


daver2 wrote:
> Kevin Neilson wrote:
> > daver2 wrote:
> > > I am implementing an extremely old logic design (circa 1965!) on a
> > > Xilinx Virtex 4 (XC4VLX25).
> > >
> > > For those interested - it is the logic for the computer that flew to
> > > the moon and back! The design is based on approximately 5,000 3-input
> > > NOR gates and not a flip flop in sight! For the circuit diagrams see
> > > website 'http://klabs.org/history/ech/agc_schematics/index.htm'.
> > >
> >
> > Does the design implement flops using NORs with feedback?  If so, that
> > could be an issue.  The ISE tools don't like combinational feedback.
> > -KEvin
>
> Kevin,
>
> Yes, the design does use NOR gates with feedback to create the
> flipflops - and yes I am getting warnings from XST about combinatorial
> loops. I am (as we speak) going through the network that the
> synthesiser has generated for the 4LUT's to see that what it has
> generated is what should have been generated!
>
> The original logic would have potentially suffered from unstable
> oscillation and glitches if it had not been designed properly in the
> first place so it is my belief that ISE is complaining about something
> that won't occur in reality.
> 
> Dave


Article: 111167
Subject: Re: Xilinx Virtex4 Outputs for Camera Link
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Mon, 30 Oct 2006 13:45:49 -0800
Links: << >>  << T >>  << A >>

>> I was unable, however, to use a double edge clock circuit
>> on the output. The OSERDES does not have a 7x option and
>> when you try 8x you get 8x data bits no matter how you
>> drive the clkdiv input.
>
> Hi Brad,  (You can now spend all evening wondering where I know you 
> from...)

Mutual client, I suppose.

> I can't shed any light on your Virtex problems, but I am interested as to 
> what leads you to bother with trying to do CameraLink with an FPGA, rather 
> than just using the appropriate NatSemi ChannelLink chip (I'm too lazy to 
> look up the number, but you know the one I mean.)

Pin count and input/output flexibility. I have used the National Chips 
before.

> When everything about CameraLink is designed around those interface chips, 
> it has always seemed to me like unnecessarily hard work to reimplement 
> their behaviour elsewhere.
>
> Is it cost, space or a sense of adventure which pushes you away from them 
> in this design?

Yes.

> Cheers,
>
> Will
> 



Article: 111168
Subject: Re: Xilinx Virtex4 Outputs for Camera Link
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Mon, 30 Oct 2006 13:54:15 -0800
Links: << >>  << T >>  << A >>

> You already need to use an entire IO tile for each output pair, as you
> are using a differential IO standard.  As such you have two OSERDES
> available for each pair.  While you could use them together to get DDR
> mode (as you have done), I would suggest using them cascaded in SDR x7
> mode.  The slowest speed grade of V4 will easily support 280MHz clock,
> and IO, and no additional logic is required to determine pixel
> boundary.  This will sork up to the max clock rate of the DCM, which is
> (IIRC) about 400MHz, or about a 57MHz pixel clock.

I would be willing to give this a try again if you tell me you have had
good success with SDR. I believe when I tried SDR, I needed two DCMs to
generate the high frequency and was having data corruption on receiving.
I might have been doing something wrong.

Another vote for National Chips if the highest frequency at SDR is 57MHz.
The Camera Link standard should go to 80MHz.

>
>
> Regards,
> Erik.
>
> ---
> Erik Widding
> President
> Birger Engineering, Inc.
>
> (mail) 100 Boylston St #1070; Boston, MA 02116
> (voice) 617.695.9233
> (fax) 617.695.9234
> (web) http://www.birger.com
> 



Article: 111169
Subject: Re: On the Futility of Documentation Webcases ( Was: Xilinx documentation typos )
From: "John_H" <newsgroup@johnhandwork.com>
Date: Mon, 30 Oct 2006 21:58:08 GMT
Links: << >>  << T >>  << A >>
Thanks, Peter.  It seems the apparant name calling was the problem.  Brian - 
you can fill us in on what you actually meant if it's different from Peter's 
interpretation.  Personally, I saw other interpretations and saw the text as 
trying "to be cute, but [he] blew it."

The original post is pertinent.  I stopped trying to submit webcases a while 
back, instead calling straight to the Xilinx hotline to kickstart the issue 
rather than dealing with the typical email response of "we need more 
information" even when extreme care was taken to provide all needed 
information.  I was even called by someone from Xilinx asking about my use 
of the hotline versus webcase; I fed back the information I felt pertinent.

I like the idea of a "mystery shopper" approach where Xilinx can do an 
informal audit of their own procedures by submitting cases of their own.  It 
may sound at first listen like it would be a waste of resources, having a 
CAE doing work that results in no actual help to the customer.  But it could 
be a serious help to the customer if it exposes the limited effectivity (at 
times) of the WebCase process.  It appears that we can't submit bugs for CRs 
unless we submit our design since software likes to have cases that can 
reproduce the bug to prove a bug fix.  My company is hesitant about shipping 
out source code in spite of the bidirectional NDAs in place.

Webcase isn't (or wasn't when I used it) a terribly effective way of 
communicating an issue no matter how well considered in the original 
submission.  Even if 60% of webcases succeed in providing a timely accurate 
response, the experience from the other 40% swamps the engineers memory.

- John_H


"Peter Alfke" <peter@xilinx.com> wrote in message 
news:1162237816.355133.116950@e3g2000cwe.googlegroups.com...
> Rickman, I disagree. I may be (overly?) sensitive to a nasty tone, and
> I don't like to be called a  "Troll of Implausible Deniability".
> Instead, I want to address the issues. I have funneled many comments
> from this newsgroup to our support management. And they have
> acknowledged them, and have admitted errors.
> And we are working on improvements.
> But as I wrote earlier, the parts are getting very complex and are
> being used in many different ways. Making every user happy is our goal,
> but I have been around long enough to relize that this is an elusive
> goal.
> Xilinx is listening and responding to this newsgroup, you have to give
> us credit for that. Whether our "bedside manners" are always perfect is
> another question. The "patients" don't always show perfect behavior
> either...
> Peter Alfke
> ===============================



Article: 111170
Subject: Re: Programming Virtex II Pro Eval Board
From: "Matthew Hicks" <mdhicks2@uiuc.edu>
Date: Mon, 30 Oct 2006 16:20:28 -0600
Links: << >>  << T >>  << A >>
My guess would be that you need a special driver/software to do the 
programming because it would take an application aware middle device to 
convert from USB to the boards programming interface.


---Matthew Hicks


<ramakrishnan.vijayakumar@gmail.com> wrote in message 
news:1162230211.740121.266040@i42g2000cwa.googlegroups.com...
> Hi,
>   I hope someone would be able to help me with my issue. I have a
> Xilinx Virtex II Pro Eval board from Avnet. The board has a serial
> interface to program it. I bought a Serial to USB Converter cable from
> RadioShack to try to program the FPGA from Impact. I have had no luck
> in doing this so far. Impact doesn't recognize the cable and it always
> fails. Can someone point me on how would I be able to program the FPGA
> with the Serial-USB Converter cable?.
>
> Ram.
> 



Article: 111171
Subject: Re: On the Futility of Documentation Webcases ( Was: Xilinx documentation
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 30 Oct 2006 14:33:07 -0800
Links: << >>  << T >>  << A >>
John,

Peter and I are very serious about improving the customer experience.

After all, that is really all that counts:  happy customers all
designing commercially successful products with Xilinx FPGAs.

This dialog is providing for some real creative thinking, so please let
it continue.

Just one comment, for every case that is resolved in a un-satisfactory
way, it takes more than ten cases with the same engineer to repair the
'damage'.  The good news is that we are doing much much better than 9 in
10 cases successfully concluded, but all it takes is a few to cause a
lot of anguish (and unhappy postings to a newsgroup).

We don't even want a few cases to go unresolved, but realize
realistically that some cases will be.  Just have to make those as few
as we possibly can, and be sure that we learn all the lessons we can
from them.

Austin

John_H wrote:
> Thanks, Peter.  It seems the apparant name calling was the problem.  Brian - 
> you can fill us in on what you actually meant if it's different from Peter's 
> interpretation.  Personally, I saw other interpretations and saw the text as 
> trying "to be cute, but [he] blew it."
> 
> The original post is pertinent.  I stopped trying to submit webcases a while 
> back, instead calling straight to the Xilinx hotline to kickstart the issue 
> rather than dealing with the typical email response of "we need more 
> information" even when extreme care was taken to provide all needed 
> information.  I was even called by someone from Xilinx asking about my use 
> of the hotline versus webcase; I fed back the information I felt pertinent.
> 
> I like the idea of a "mystery shopper" approach where Xilinx can do an 
> informal audit of their own procedures by submitting cases of their own.  It 
> may sound at first listen like it would be a waste of resources, having a 
> CAE doing work that results in no actual help to the customer.  But it could 
> be a serious help to the customer if it exposes the limited effectivity (at 
> times) of the WebCase process.  It appears that we can't submit bugs for CRs 
> unless we submit our design since software likes to have cases that can 
> reproduce the bug to prove a bug fix.  My company is hesitant about shipping 
> out source code in spite of the bidirectional NDAs in place.
> 
> Webcase isn't (or wasn't when I used it) a terribly effective way of 
> communicating an issue no matter how well considered in the original 
> submission.  Even if 60% of webcases succeed in providing a timely accurate 
> response, the experience from the other 40% swamps the engineers memory.
> 
> - John_H
> 
> 
> "Peter Alfke" <peter@xilinx.com> wrote in message 
> news:1162237816.355133.116950@e3g2000cwe.googlegroups.com...
>> Rickman, I disagree. I may be (overly?) sensitive to a nasty tone, and
>> I don't like to be called a  "Troll of Implausible Deniability".
>> Instead, I want to address the issues. I have funneled many comments
>> from this newsgroup to our support management. And they have
>> acknowledged them, and have admitted errors.
>> And we are working on improvements.
>> But as I wrote earlier, the parts are getting very complex and are
>> being used in many different ways. Making every user happy is our goal,
>> but I have been around long enough to relize that this is an elusive
>> goal.
>> Xilinx is listening and responding to this newsgroup, you have to give
>> us credit for that. Whether our "bedside manners" are always perfect is
>> another question. The "patients" don't always show perfect behavior
>> either...
>> Peter Alfke
>> ===============================
> 
> 

Article: 111172
Subject: Re: On the Futility of Documentation Webcases ( Was: Xilinx documentation
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 31 Oct 2006 11:35:52 +1300
Links: << >>  << T >>  << A >>
John_H wrote:
> 
> I like the idea of a "mystery shopper" approach where Xilinx can do an 
> informal audit of their own procedures by submitting cases of their own.  It 
> may sound at first listen like it would be a waste of resources, having a 
> CAE doing work that results in no actual help to the customer.  

What about the _really_ radical idea, of getting the "mystery shopper"
to actually try and use the tools, and submit a real web case,
based on whatever issues they encountered ?   :)
[that way, they do actually help the user base !]

-jg


Article: 111173
Subject: Re: On the Futility of Documentation Webcases ( Was: Xilinx documentation
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 30 Oct 2006 14:57:12 -0800
Links: << >>  << T >>  << A >>
Jim,

It may surprise you, but the FPGA Lab (which I manage) leads in the
verification and characterization of new silicon.

In order to do this, we use the same software tools the customers do
(the surprising part, perhaps?).

So, we typically file hundreds of change requests, and bugs per month
when we first get the silicon back.

Yes, we are the first users, and no, we don't do just "goofy" special
stuff, but are required to help get things like the PCIe designs working
for the plug-fests and testing off-site, the DSP filters to work, the
FIFO/BRAM to pack properly, measure the SRL16 power, and so on.

Next time you wonder "Hasn't anyone ever even tried this before!" the
folks in my group probably have, and may have a bug fix request in for it.

If not, we probably just got lucky, and missed that particular case.  We
try to keep lots of old cases around for regression testing (just common
good practice).

We are not alone, there is the systems engineering group, the
applications group, product test group, the DSP group, the embedded
systems folks, early access customers, design services group, all the
FAE's that can't wait to see if the new part is a better fit for their
customers, and a whole slew of other quality control systems in place.

Admittedly, all it takes is just one bug that isn't caught to ruin your day.

Austin

Jim Granville wrote:
> John_H wrote:
>>
>> I like the idea of a "mystery shopper" approach where Xilinx can do an
>> informal audit of their own procedures by submitting cases of their
>> own.  It may sound at first listen like it would be a waste of
>> resources, having a CAE doing work that results in no actual help to
>> the customer.  
> 
> What about the _really_ radical idea, of getting the "mystery shopper"
> to actually try and use the tools, and submit a real web case,
> based on whatever issues they encountered ?   :)
> [that way, they do actually help the user base !]
> 
> -jg
> 

Article: 111174
Subject: xup virtex2 pro
From: "nana" <nmichou@utk.edu>
Date: 30 Oct 2006 15:09:56 -0800
Links: << >>  << T >>  << A >>
Hello,
    > I am using xup virtex2 pro with xc2vp30 fpga and I am trying to
send data
    > between two boards.
    > I do not want to use the example (xupv2p_aurora.zip), I want to
create it.
    > using aurora software, I generated the aurora core and at the
command page I
    > used xilperl to create the .ise file, then I used project
navigator to run the
    > project.
    > Using chipscope, I synthesized and inserted ila.cdc file into the
design.
    > One of my problems is when I try to modify my connections in
chipscope
    > inserter I don't know what I'm doing, I am a beginner in this.
Another problem
    > is the data, I don't know how to deal with it, in other words I
don't know how
    > and where to insert it into the design ( I am not very good in
vhdl or
    > verilog). And the last problem is that I am using one board right
now to loop
    > my data out and in the board, now when I use two boards how do I
deal with
    > this and what file should I make changes to?
    > I really appreciate your help
    >




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