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 141475

Article: 141475
Subject: Re: True dual-port RAM in VHDL: XST question
From: sleeman <kennheinrich@sympatico.ca>
Date: Thu, 25 Jun 2009 05:09:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 25, 6:55=A0am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > Originally coming from ASIC side I find this incredible but it seems
> > that majority of people doing FPGA design don't simulate. I was at an
> > FPGA infomercial the other day about two new device families coming
> > out from a vendor to stay nameless and only %20 or so people raised
> > their hands when asked this question. This might explain how these
> > templates survived as is for such a long time.
>
> Do you mean don't simulate the P&R'd design, or not at all?
>
> Nial.

This thread has brought up several very interesting themes. I'd like
to add my two cents to each.

1) Synthesis templates for RAMS. I think what Jonathan is doing is a
great idea. I'd love to see a better definition of what cross-device
code patterns are safe to use and supported by which tools.  From
experience, I can say that I've done it right for a few key designs,
and managed to leverage off of that by wrapping this inference in an
entity, giving me a device-independent (more-or-less) codebase but
still requiring structural coding around the RAM. It's not ideal by a
long shot. But by enforcing good version control discipline through
the organization and introducing a mindset that says "don't fiddle
around with a perfectly good library module, use it as-is or not at
all", we have managed to reduce the number of times designers sit
there, asking the same questions: "I only changed one line of code;
why did it start making distributed RAM? What were those attributes
again? When I don't use the read port how do I stop the synthesizer
from complaining?" and so on and so on.

2) Clocks versus asynchronous logic.  My view of this is that clocks
are both an obvious physical thing (as anyone who flies a scope for
living well knows) as well as an abstraction.  This abstraction is
what constitutes the "contract", or point of demarcation between high-
level circuit digital designer, and the guy who actually codes the
gate-level RAM and control logic.  The job of the low-level transistor
guy is to provide a circuit that acts as if the clock abstraction is a
true representation of what actually happens inside. He may use flops,
latches, vernier timing thingies, or whatever the heck he needs. But
he *must* obey the clock-concept contract.  The job of the high-level
(FPGA application developer) is to make use of the clock concept
abstraction in order to make his design synchronous, which implies
robustness, maintainability, and all the other virtues that regular
posters here know so well.

3) People who don't do simulation? Definitely.  I've help manage the
change in an organization growing from a couple of FPGA guys to a
fairly well-oiled FPGA talent pool with established version control,
substantial as-is module re-use, and an ingrained mindset that a
modules doesn't get released without a scripted, regressionable
testbench.  They're two points at opposite ends of a continuum of
process, but I see a lot of real work in industry done at both ends.

The "garage shop" FPGA approach typically has some guys who learned
VHDL in school, then got thrown into the deep end alone, or who "came
up through the ranks" from CPLDs and board design.  No VC, no software
techniques, no libraries, packages, functions or elegant code in the
source. Hack job, in short.  Two of these guys working on the same
project may often be running different tool versions, and not even be
able to load the design as-is from the other guy's sources, without a
lot of manual GUI fiddling to reset paths, manually link in the right
libraries, and so on.  There's little chance of even building the same
design twice in a row. These are the guys who throw their bitfile onto
the board, and if it doesn't work, start writing some testbenches
(aww, do I *have* to do that... what a pain). They don't want to
simulate because its too hard/too long to sim the whole chip, and
because there's poor structure and/or modularity in their own code to
begin with, so it's also too hard to isolate a portion and make a
simple test for it, too.

The "pro" is at the other end of the continuum. Most of the regular
posters here try to answer the "garage guys" with answers that will
point them in the direction of becoming a "pro".  It's a lot more
work, but there's a lot of benefit to being able to release a chip
that you know that anyone on your team can build again, bit/UCF/source-
accurately, when you're on vacation.

Of course, some "pros" work in garage shops. But the Big Tool (Big
Two?) vendors tend to cater most of their tools to the garage shop
guys. Everything can be set by clicking on a GUI button. Everything
about a project is stored in unreadable binary files.  They try to
force you into their half-assed version control scheme, if they offer
one at all.  How are you ever going to share designs or document them
for the future that way?  And all of the "sex appeal" about the new
devices is put into the GUI, the new buttons that you can click on,
and the new auto-wizards (that don't usually have a mode to generate
output from anything other than unreliable, unrepeatable user mouse
clicks). ( I tend to think of this emphasis on sexy GUI tools leading
then to bad project practices as being akin to drug dealers pushing
crack in the schoolyards, but that would get me in trouble with my
local FAEs so I'll refrain :-)

Don't get me wrong... I had a lot of fun as a garage guy myself. I
built some pretty damn fine hardware "back in the day" before I even
had the option of simulating my code. But I agree, there are still a
lot of guys who view testbenches and simulation as something painful
and only to be done if really necessary. In truth, it's like pretty
much everything else in life: you get out more when you put in more
work.

OK, I'm done ranting now :-)

 - Kenn

Article: 141476
Subject: Re: 720 Mhz IF Processing
From: recoder <kurtulmehtap@gmail.com>
Date: Thu, 25 Jun 2009 05:10:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 25 Haziran, 10:59, "Sebastien @ Sundance"
<maury.sebast...@gmail.com> wrote:
> On Jun 24, 11:15=A0pm, recoder <kurtulmeh...@gmail.com> wrote:
>
> > =A0We are used to process 70 Mhz IF by using ADC boards to interface to
> > our fpga boards.
> > Now we have to process the following signal:
> > 720 Mhz IF
> > qpsk modulated
> > =A080 mhz bandwith (3 dB)
>
> > Can anybody recommend a board to interface the 720 Mhz IF to a FPGA
> > board?
>
> If you are looking at a complete system, you can check the SMT702 that
> may do the job :http://www.sundance.com/web/files/productpage.asp?STRFilt=
er=3DSMT702
>
> - Sebastien

Thank you for your recommendation but I think downconverting 720 mhz
to 140 or 70 Mhz would be a better solution. I am looking for a board
that can do the job.

Article: 141477
Subject: Re: SRAM vs Flash based FPGA one more time
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Thu, 25 Jun 2009 16:02:30 +0300
Links: << >>  << T >>  << A >>
urock wrote:
> Everybody knows that from user point of view Flash based FPGA are
> better because they are nonvvolatile, tolerable to radiation, do not
> consume high current at startup and better secure intellectual
> property. On the other hand SRAM FPGA are much easier to manufacture.

Everybody does not share those positive points. For example I think that
SRAM based FPGA is easier in terms of image management. It can be easily
connected to an external CPU, that has access to big flash etc. You can
easily put many different images to external flash, and load them as
needed, or even use dynamic reconfiguration.

Also the high load current was more of a problem in the past. It's not
that bad anymore compared to the current in normal mode. And IP
can be protected via encrypted configuration streams in most of the new
SRAM based FPGAs.

Radiation tolerance is possibly better for flash based devices, but I
have not compared the FIT rates for configuration data (I think usually
just combined FIT is shown. The SRAM based configuration bits are not
traditional sram cells as far as I know. And for normal functional logic
same problems are shared in terms of SEU.

--Kim

Article: 141478
Subject: Has anybody tried ISE for Virtex-6/Spartan-6?
From: Dirk Koch <dirk.koch@cs.fau.de>
Date: Thu, 25 Jun 2009 15:20:59 +0200
Links: << >>  << T >>  << A >>
Dear all!
Today, I tried to download and install webpack that failed
with the message:
   soap version mismatch or invalid soap message
Then I tried the same with the evaluation version of ISE
and got the following from the Xilinx web server:
   Error
   We cannot fulfill your request due to technical difficulties.
   Please try again later.

Has anybody had more luck/success?
In particular, I am interested in the routing fabric of V6/S6.

Best regards!
Dirk

Article: 141479
Subject: Re: Has anybody tried ISE for Virtex-6/Spartan-6?
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Thu, 25 Jun 2009 06:44:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 25, 4:20=A0pm, Dirk Koch <dirk.k...@cs.fau.de> wrote:
> Dear all!
> Today, I tried to download and install webpack that failed
> with the message:
> =A0 =A0soap version mismatch or invalid soap message
> Then I tried the same with the evaluation version of ISE
> and got the following from the Xilinx web server:
> =A0 =A0Error
> =A0 =A0We cannot fulfill your request due to technical difficulties.
> =A0 =A0Please try again later.
>
> Has anybody had more luck/success?
> In particular, I am interested in the routing fabric of V6/S6.
>
> Best regards!
> Dirk

LOL

SOAP was a soap opera long ago

am about to try out as well, but have registration problem at xilinx
web

Antti


Article: 141480
Subject: Re: Has anybody tried ISE for Virtex-6/Spartan-6?
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Thu, 25 Jun 2009 06:46:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 25, 4:20=A0pm, Dirk Koch <dirk.k...@cs.fau.de> wrote:
> Dear all!
> Today, I tried to download and install webpack that failed
> with the message:
> =A0 =A0soap version mismatch or invalid soap message
> Then I tried the same with the evaluation version of ISE
> and got the following from the Xilinx web server:
> =A0 =A0Error
> =A0 =A0We cannot fulfill your request due to technical difficulties.
> =A0 =A0Please try again later.
>
> Has anybody had more luck/success?
> In particular, I am interested in the routing fabric of V6/S6.
>
> Best regards!
> Dirk

you had error during DOWNLOAD or during install?

there was no problem with webpack download, that worked ok
will try to install in a second
Antti


Article: 141481
Subject: Re: True dual-port RAM in VHDL: XST question
From: rickman <gnuarm@gmail.com>
Date: Thu, 25 Jun 2009 07:33:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 24, 2:11=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
> On Wed, 24 Jun 2009 18:57:29 +0100, Jonathan Bromley
>
> <jonathan.brom...@MYCOMPANY.com> wrote:
> >I'm trying to assemble a complete and accurate list
> >of the _synthesizable_ templates for all common types
> >of FPGA memory, and I have discovered a template
> >that synthesizes to dual-clock RAM in two FPGA
> >vendors' tools but is a complete nonsense for
> >simulation. =A0I want to know why this has happened,
> >what we can do about it, and why the vendors haven't
> >already been beaten to pulp over it by users.
>
> Originally coming from ASIC side I find this incredible but it seems
> that majority of people doing FPGA design don't simulate. I was at an
> FPGA infomercial the other day about two new device families coming
> out from a vendor to stay nameless and only %20 or so people raised
> their hands when asked this question.

I missed something.  What question exactly?

Rick

Article: 141482
Subject: Re: SRAM vs Flash based FPGA one more time
From: rickman <gnuarm@gmail.com>
Date: Thu, 25 Jun 2009 07:38:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 25, 9:02=A0am, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
> urock wrote:
> > Everybody knows that from user point of view Flash based FPGA are
> > better because they are nonvvolatile, tolerable to radiation, do not
> > consume high current at startup and better secure intellectual
> > property. On the other hand SRAM FPGA are much easier to manufacture.
>
> Everybody does not share those positive points. For example I think that
> SRAM based FPGA is easier in terms of image management. It can be easily
> connected to an external CPU, that has access to big flash etc. You can
> easily put many different images to external flash, and load them as
> needed, or even use dynamic reconfiguration.

Why can't you do that with Flash based FPGAs?  At least the Lattice
parts are a RAM based FPGA with a flash configuration memory
integrated.  So they have the advantages of both RAM and flash based
parts.  They are low cost too.  That is the main reason that Xilinx
has touted for not making flash based parts, that the flash process is
behind the power curve and parts can be made cost effectively.  BAH!


> Also the high load current was more of a problem in the past. It's not
> that bad anymore compared to the current in normal mode. And IP
> can be protected via encrypted configuration streams in most of the new
> SRAM based FPGAs.
>
> Radiation tolerance is possibly better for flash based devices, but I
> have not compared the FIT rates for configuration data (I think usually
> just combined FIT is shown. The SRAM based configuration bits are not
> traditional sram cells as far as I know. And for normal functional logic
> same problems are shared in terms of SEU.

Not if they are RAM based with flash config mem.  These parts get the
advantages of both, but also the disadvantages of both if that makes
sense...

Rick

Article: 141483
Subject: Re: Has anybody tried ISE for Virtex-6/Spartan-6?
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Thu, 25 Jun 2009 07:55:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 25, 4:20=A0pm, Dirk Koch <dirk.k...@cs.fau.de> wrote:
> Dear all!
> Today, I tried to download and install webpack that failed
> with the message:
> =A0 =A0soap version mismatch or invalid soap message
> Then I tried the same with the evaluation version of ISE
> and got the following from the Xilinx web server:
> =A0 =A0Error
> =A0 =A0We cannot fulfill your request due to technical difficulties.
> =A0 =A0Please try again later.
>
> Has anybody had more luck/success?
> In particular, I am interested in the routing fabric of V6/S6.
>
> Best regards!
> Dirk

beware i JUST downloaded and installed the NEW LATEST SFD ISE install

but it was just plain old 11.1 so you need actually only grab the 11.2
UPDATE
downloading the ISE SFD install will give only 11.1 release
stupid

update is now installing, will see if it does have the s6 included

Antti


Article: 141484
Subject: Re: True dual-port RAM in VHDL: XST question
From: Muzaffer Kal <kal@dspia.com>
Date: Thu, 25 Jun 2009 08:44:33 -0700
Links: << >>  << T >>  << A >>
On Thu, 25 Jun 2009 07:33:06 -0700 (PDT), rickman <gnuarm@gmail.com>
wrote:

>On Jun 24, 2:11 pm, Muzaffer Kal <k...@dspia.com> wrote:
>> On Wed, 24 Jun 2009 18:57:29 +0100, Jonathan Bromley
>>
>> <jonathan.brom...@MYCOMPANY.com> wrote:
>> >I'm trying to assemble a complete and accurate list
>> >of the _synthesizable_ templates for all common types
>> >of FPGA memory, and I have discovered a template
>> >that synthesizes to dual-clock RAM in two FPGA
>> >vendors' tools but is a complete nonsense for
>> >simulation.  I want to know why this has happened,
>> >what we can do about it, and why the vendors haven't
>> >already been beaten to pulp over it by users.
>>
>> Originally coming from ASIC side I find this incredible but it seems
>> that majority of people doing FPGA design don't simulate. I was at an
>> FPGA infomercial the other day about two new device families coming
>> out from a vendor to stay nameless and only %20 or so people raised
>> their hands when asked this question.
>
>I missed something.  What question exactly?

Whether they simulate their designs, (before downloading & testing on
the board). 
-
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 141485
Subject: Re: 11.1 & USB cable drivers
From: "Chet" <chetferry@comcast.net>
Date: Thu, 25 Jun 2009 12:27:29 -0500
Links: << >>  << T >>  << A >>
>Chet <chetferry@comcast.net> wrote:
>> I have read through this thread and was hoping to solicit some help. 
Here
>> is my problem.
>
>> Impact does not find USB II cable using libusb.  It works fine for me
with
>> ISE 10.1.03.
>>  
>> -My OS is Suse Linux 64 bit Enterprise Desktop 11
>
>> -I have libusb and fxload packages installed (works fine with ISE
>> 10.1.03)
>
>> -I have run the setup_pcusb script
>
>> -I have tried setting  XIL_IMPACT_USE_LIBUSB env var to 0, 1, and not
>> defined.
>
>> -I have tried creating a soft link in my home directory named libusb.so
in
>> my home directory to 
>
>> /usr/lib/libusb-0.1.so.4.4.4 
>
>> -I have tried creating a soft link in my home directory named libusb.so
in
>> my home directory to 
>
>> /usr/lib64/libusb-0.1.so.4.4.4 
>>  
>
>> -The USB cable LED turns green when it is plugged into computer
>
>> -USB II cable and target are proven good because it works when I
switch
>> back to ISE 10.1.03
>
>> Any ideas or thoughts would be most appreciated.  I am a Linux newbie
and
>> not sure what else to try. 
>
>What does 'lsusb' report? How are the permissions on the node set?
>
>-- 
>Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>
>Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
>--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>


It turns out that I was making the soft link it in the wrong directory and
pointing it to the wrong .so file.

Here is what I did that got it working for me:

cd to the /usr/lib64 directory

sudo ln -s libusb-0.1.so.4 libusb.so

Also I had to set the XIL_IMPACT_USE_LIBUSB env var to 1.  Even though the
Xilinx install notes for 11.1 say you do not need to define it.

This is on a 64 bit OS so I am assuming if you are running a 32 bit OS
that you may want to do the same thing in the /usr/lib directory instead?



Article: 141486
Subject: Re: 720 Mhz IF Processing
From: Eric Jacobsen <eric.jacobsen@ieee.org>
Date: Thu, 25 Jun 2009 10:41:51 -0700
Links: << >>  << T >>  << A >>
On 6/25/2009 5:10 AM, recoder wrote:
> On 25 Haziran, 10:59, "Sebastien @ Sundance"
> <maury.sebast...@gmail.com>  wrote:
>> On Jun 24, 11:15 pm, recoder<kurtulmeh...@gmail.com>  wrote:
>>
>>>   We are used to process 70 Mhz IF by using ADC boards to interface to
>>> our fpga boards.
>>> Now we have to process the following signal:
>>> 720 Mhz IF
>>> qpsk modulated
>>>   80 mhz bandwith (3 dB)
>>> Can anybody recommend a board to interface the 720 Mhz IF to a FPGA
>>> board?
>> If you are looking at a complete system, you can check the SMT702 that
>> may do the job :http://www.sundance.com/web/files/productpage.asp?STRFilter=SMT702
>>
>> - Sebastien
>
> Thank you for your recommendation but I think downconverting 720 mhz
> to 140 or 70 Mhz would be a better solution. I am looking for a board
> that can do the job.

You seem to be looking for a UHF to 70MHz downconverter.   There are 
lots of UHF tuners with 70MHz outputs, but many/most are for broadcast 
applications and only support bandwidths up to about 8MHz.

You may be able to find something with a bandwidth as wide as you're 
asking (80MHz), but I suspect you'll have to look around and it won't be 
cheap.   That's a pretty wide bandwidth and most applications don't need 
or support that much.




Article: 141487
Subject: Re: 720 Mhz IF Processing
From: Joerg <invalid@invalid.invalid>
Date: Thu, 25 Jun 2009 10:56:16 -0700
Links: << >>  << T >>  << A >>
Eric Jacobsen wrote:
> On 6/25/2009 5:10 AM, recoder wrote:
>> On 25 Haziran, 10:59, "Sebastien @ Sundance"
>> <maury.sebast...@gmail.com>  wrote:
>>> On Jun 24, 11:15 pm, recoder<kurtulmeh...@gmail.com>  wrote:
>>>
>>>>   We are used to process 70 Mhz IF by using ADC boards to interface to
>>>> our fpga boards.
>>>> Now we have to process the following signal:
>>>> 720 Mhz IF
>>>> qpsk modulated
>>>>   80 mhz bandwith (3 dB)
>>>> Can anybody recommend a board to interface the 720 Mhz IF to a FPGA
>>>> board?
>>> If you are looking at a complete system, you can check the SMT702 that
>>> may do the job 
>>> :http://www.sundance.com/web/files/productpage.asp?STRFilter=SMT702
>>>
>>> - Sebastien
>>
>> Thank you for your recommendation but I think downconverting 720 mhz
>> to 140 or 70 Mhz would be a better solution. I am looking for a board
>> that can do the job.
> 
> You seem to be looking for a UHF to 70MHz downconverter.   There are 
> lots of UHF tuners with 70MHz outputs, but many/most are for broadcast 
> applications and only support bandwidths up to about 8MHz.
> 
> You may be able to find something with a bandwidth as wide as you're 
> asking (80MHz), but I suspect you'll have to look around and it won't be 
> cheap.   That's a pretty wide bandwidth and most applications don't need 
> or support that much.
> 

For parts this would be a good place to start:

http://www.mini-circuits.com/

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Article: 141488
Subject: Re: 720 Mhz IF Processing
From: spope33@speedymail.org (Steve Pope)
Date: Thu, 25 Jun 2009 18:01:02 +0000 (UTC)
Links: << >>  << T >>  << A >>
Eric Jacobsen  <eric.jacobsen@ieee.org> wrote:

>You seem to be looking for a UHF to 70MHz downconverter.   There are 
>lots of UHF tuners with 70MHz outputs, but many/most are for broadcast 
>applications and only support bandwidths up to about 8MHz.

>You may be able to find something with a bandwidth as wide as you're 
>asking (80MHz), but I suspect you'll have to look around and it won't be 
>cheap.   That's a pretty wide bandwidth and most applications don't need 
>or support that much.

This is why I suggested a quadrature mixer down to baseband.
Then the output bandwidth is only ~40 MHz.  A little googling
suggests such a connectorized component exists.  Dunno about
the cost though.

Steve

Article: 141489
Subject: Re: 720 Mhz IF Processing
From: "langwadt@fonz.dk" <langwadt@fonz.dk>
Date: Thu, 25 Jun 2009 11:07:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 25 Jun., 14:10, recoder <kurtulmeh...@gmail.com> wrote:
> On 25 Haziran, 10:59, "Sebastien @ Sundance"
>
>
>
> <maury.sebast...@gmail.com> wrote:
> > On Jun 24, 11:15=A0pm, recoder <kurtulmeh...@gmail.com> wrote:
>
> > > =A0We are used to process 70 Mhz IF by using ADC boards to interface =
to
> > > our fpga boards.
> > > Now we have to process the following signal:
> > > 720 Mhz IF
> > > qpsk modulated
> > > =A080 mhz bandwith (3 dB)
>
> > > Can anybody recommend a board to interface the 720 Mhz IF to a FPGA
> > > board?
>
> > If you are looking at a complete system, you can check the SMT702 that
> > may do the job :http://www.sundance.com/web/files/productpage.asp?STRFi=
lter=3DSMT702
>
> > - Sebastien
>
> Thank you for your recommendation but I think downconverting 720 mhz
> to 140 or 70 Mhz would be a better solution. I am looking for a board
> that can do the job.

something like a combo of   ad8348 and adf4360-7  eval boards ?

-Lasse

Article: 141490
Subject: Re: Has anybody tried ISE for Virtex-6/Spartan-6?
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Thu, 25 Jun 2009 11:08:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 25, 4:20=A0pm, Dirk Koch <dirk.k...@cs.fau.de> wrote:
> Dear all!
> Today, I tried to download and install webpack that failed
> with the message:
> =A0 =A0soap version mismatch or invalid soap message
> Then I tried the same with the evaluation version of ISE
> and got the following from the Xilinx web server:
> =A0 =A0Error
> =A0 =A0We cannot fulfill your request due to technical difficulties.
> =A0 =A0Please try again later.
>
> Has anybody had more luck/success?
> In particular, I am interested in the routing fabric of V6/S6.
>
> Best regards!
> Dirk

everything works

ISE 11.2 time to first PROBLEM 4 minutes
well its minor one,


ICAP_SPARTAN6 can not be placed onto schematics
really a minor bug, hopefully it can be used in HDL

well DNA is not working in -ES silicon :(
maybe some other stuff too

Antti




Article: 141491
Subject: Re: True dual-port RAM in VHDL: XST question
From: rickman <gnuarm@gmail.com>
Date: Thu, 25 Jun 2009 11:11:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 25, 11:44=A0am, Muzaffer Kal <k...@dspia.com> wrote:
> On Thu, 25 Jun 2009 07:33:06 -0700 (PDT), rickman <gnu...@gmail.com>
> wrote:
>
>
>
> >On Jun 24, 2:11=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
> >> On Wed, 24 Jun 2009 18:57:29 +0100, Jonathan Bromley
>
> >> <jonathan.brom...@MYCOMPANY.com> wrote:
> >> >I'm trying to assemble a complete and accurate list
> >> >of the _synthesizable_ templates for all common types
> >> >of FPGA memory, and I have discovered a template
> >> >that synthesizes to dual-clock RAM in two FPGA
> >> >vendors' tools but is a complete nonsense for
> >> >simulation. =A0I want to know why this has happened,
> >> >what we can do about it, and why the vendors haven't
> >> >already been beaten to pulp over it by users.
>
> >> Originally coming from ASIC side I find this incredible but it seems
> >> that majority of people doing FPGA design don't simulate. I was at an
> >> FPGA infomercial the other day about two new device families coming
> >> out from a vendor to stay nameless and only %20 or so people raised
> >> their hands when asked this question.
>
> >I missed something. =A0What question exactly?
>
> Whether they simulate their designs, (before downloading & testing on
> the board).

Oh, I see.  The last place I worked was a pretty good sized defense
contractor making push to talk radios.  They actually had the FPGA
group under the software department because they felt it has more in
common (such as using version control on the source files).  I was in
the hardware group and so not allowed to work on anything in the FPGA,
including code to test my hardware.  One of the other "hardware"
engineers gave a "training" lecture to the entire hardware department
(most of who were RF designers) about FPGA design.  His method of
doing timing analysis was to run a simulation!!!  I had to stop him
right there are point out that was what static timing analysis was
for.  He said that was not needed, since he could do a post route
simulation.  How insane is that!!!!!????

The other side of the coin was that they had a newbie working the FPGA
code which was a collection of a couple of UARTs, I2C and a custom
serial interface. Instead of simulating (or maybe just not a very good
simulation) they were relying on the Xilinx logic analyzer tool.  I
can't think of a more painful way of doing the initial debug.  I was
asked to help them get the FPGA to load a bit file the first time and
they didn't want to listen much to me.  They had five (yes FIVE!!!)
engineers working on it including a very senior engineer and a first
level manager.  No one could seem to figure out what was wrong.  I had
to wedge my way into the fray and started showing them the few simple
steps you have to take to get it going.  I kept pointing out that you
need to give a few extra clocks at the end of downloading the file to
get the part out of configuration mode and they kept telling me that
was already tried.  But the symptoms all pointed to this as the
problem.  So I had to beat on it over and over again until finally
someone realized that they had tried adding strobes up to 64k as a
magic bullet and when that didn't make it work (they had more than one
problem) it was removed entirely!  So they finally listened to me for
a moment and the devices loaded...  FIVE engineers couldn't figure
that out!!!

So we have engineers who don't believe it is productive to run
simulation, engineers who believe they don't need to use static timing
analysis and engineers who can't debug their way out of a paper bag!!!

Are engineers the stupidest people in the world or is it just defense
contractors?

Rick

Article: 141492
Subject: Re: 720 Mhz IF Processing
From: Josh Model <model@ll.mit.edu>
Date: Thu, 25 Jun 2009 14:15:55 -0400
Links: << >>  << T >>  << A >>
Ettus Research might be a likely candidate...

http://www.ettus.com/order


langwadt@fonz.dk wrote:
> On 25 Jun., 14:10, recoder <kurtulmeh...@gmail.com> wrote:
>> On 25 Haziran, 10:59, "Sebastien @ Sundance"
>>
>>
>>
>> <maury.sebast...@gmail.com> wrote:
>>> On Jun 24, 11:15 pm, recoder <kurtulmeh...@gmail.com> wrote:
>>>>  We are used to process 70 Mhz IF by using ADC boards to interface to
>>>> our fpga boards.
>>>> Now we have to process the following signal:
>>>> 720 Mhz IF
>>>> qpsk modulated
>>>>  80 mhz bandwith (3 dB)
>>>> Can anybody recommend a board to interface the 720 Mhz IF to a FPGA
>>>> board?
>>> If you are looking at a complete system, you can check the SMT702 that
>>> may do the job :http://www.sundance.com/web/files/productpage.asp?STRFilter=SMT702
>>> - Sebastien
>> Thank you for your recommendation but I think downconverting 720 mhz
>> to 140 or 70 Mhz would be a better solution. I am looking for a board
>> that can do the job.
> 
> something like a combo of   ad8348 and adf4360-7  eval boards ?
> 
> -Lasse

Article: 141493
Subject: Re: Cable autodetection/programming the Xilinx Virtex2Pro FPGA failing.
From: "Chet" <chetferry@comcast.net>
Date: Thu, 25 Jun 2009 13:45:12 -0500
Links: << >>  << T >>  << A >>
>Hi,
>I was using the USB cable provided with Xilinx Vertex 2Pro board in my
>PC earlier. Recently I upgraded my PC to Intel Core2Duo Processor and
>it's corresponding mother board. Also I have added another NetMOS PCI
>ECP Parallel port add on as there was no parallel port by default on
>the mother board.
>But now I am not able to program the FPGA board.
>Here are the error messages I get when I do   "Output" ---> "Cable
>Auto Detect"
>
>*************************
>Welcome to iMPACT
>// *** BATCH CMD : loadProjectFile -file "E:/vhdl_proj/
>for_2_exp_19_samples/for_2_exp_19_samples.ipf"
>'1': Loading file 'E:/vhdl_proj/for_2_exp_19_samples/
>top_module_26th_may_ratioed_avg_for_2exp19_samples.bit' ...
>done.
>INFO:iMPACT:1777 -
>Reading C:/Program Files/Xilinx91i/virtex2p/data/xc2vp30.bsd...
>WARNING:iMPACT:2257 - Startup Clock has been changed to 'JtagClk' in
>the bitstream stored in memory,
>but the original bitstream file remains unchanged.
>INFO:iMPACT:501 - '1': Added Device xc2vp30 successfully.
>----------------------------------------------------------------------
>----------------------------------------------------------------------
>Active mode is BS
>// *** BATCH CMD : setMode -ss
>// *** BATCH CMD : setMode -sm
>// *** BATCH CMD : setMode -hw140
>// *** BATCH CMD : setMode -spi
>// *** BATCH CMD : setMode -acecf
>// *** BATCH CMD : setMode -acempm
>// *** BATCH CMD : setMode -pff
>// *** BATCH CMD : setMode -bs
>// *** BATCH CMD : setMode -bs
>// *** BATCH CMD : setMode -bs
>// *** BATCH CMD : setMode -bs
>GUI --- Auto connect to cable...
>// *** BATCH CMD : setCable -port auto
>AutoDetecting cable. Please wait.
>PROGRESS_START - Starting Operation.
>Connecting to cable (Parallel Port - LPT1).
>Checking cable driver.
> Driver windrvr6.sys version = 8.1.0.0.Connecting to cable (Parallel
>Port - LPT2).
>Checking cable driver.
> Driver windrvr6.sys version = 8.1.0.0.Connecting to cable (Parallel
>Port - LPT3).
>Checking cable driver.
> Driver windrvr6.sys version = 8.1.0.0.Connecting to cable (Parallel
>Port - LPT4).
>Checking cable driver.
> Driver windrvr6.sys version = 8.1.0.0.Connecting to cable (Usb Port -
>USB21).
>Checking cable driver.
> Driver xusbdfwu.sys version: 1021 (1021).
> Driver windrvr6.sys version = 8.1.0.0.Cable connection failed.
>PROGRESS_END - End Operation.
>Elapsed time =      2 sec.
>Cable autodetection failed.
>*************************
>
>I have no idea how to make the cable detectable now. When I plugin the
>Xilinx cable, it asks for the drivers and automatically detects them
>after a click. But still I am not able to load my program into the
>FPGA board.
>Waiting for a response.
>-Pratap
>

What OS are you using?

Article: 141494
Subject: Re: SRAM vs Flash based FPGA one more time
From: gabor <gabor@alacron.com>
Date: Thu, 25 Jun 2009 11:49:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 25, 7:22=A0am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Jun 25, 2:12=A0pm, "Nial Stewart"
>
> <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > > Everybody knows that from user point of view Flash based FPGA are
> > > better because they are nonvvolatile, tolerable to radiation, do not
> > > consume high current at startup and better secure intellectual
> > > property. On the other hand SRAM FPGA are much easier to manufacture.
>
> > > That's it?
>
> > No.
>
> > All I'll say is that if you're used to the sort of P&R results you get
> > with Altera/Xilinx tools and devices be wary of committing to a transfe=
r
> > to a Flash based device without a _lot_ of experimenting first.
>
> > Nial.
>
> well that counts for ACTEL yes!!!!
>
> Lattice is almost like Xilinx, even has distributed RAM (only SRL16
> mode is missing)
> ic65L is like old Xilinx LUT4FF
>
> but in generic yes, need run real P&R and compare actual designs
> before
> doing any decisions
>
> Antti

Lattice's mixed flash / SRAM parts also don't have the same
instant-on and radiation tolerance features of the Actel parts.
So in essence you lose some of the features to gain better
density and architecture.

Article: 141495
Subject: Re: True dual-port RAM in VHDL: XST question
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Thu, 25 Jun 2009 19:53:11 +0100
Links: << >>  << T >>  << A >>
On Thu, 25 Jun 2009 11:11:59 -0700 (PDT), rickman wrote:

>Are engineers the stupidest people in the world

No, I don't think so.  I meet loads of engineers in
my training work, and it is rare indeed to find a
stupid one.  Some are quite extraordinarily smart.

However, engineers do very complicated, occasionally
very difficult, and certainly very arcane things.  
I reckon they get used to the idea that no-one they
meet is likely to be able to help them much.  So
they get very narrowly focused on the (perceived)
task at hand, and lose the ability to look outside
their narrow concerns.  (I'm sure I fall into that
trap frequently myself.)  That narrowness can 
easily come across as arrogance and/or reluctance
to accept advice.

Getting software folk and digital designers 
talking to each other would be a big step in
the right direction.  Sometimes that works well,
but certain project management styles (as in Rick's
story) go a long way towards preventing it.

Re-skilling, as often as you get the chance, is
a pretty good antidote to belief that you know
it all.  Career circumstances don't usually make
that easy to do, sadly.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 141496
Subject: Re: SRAM vs Flash based FPGA one more time
From: rickman <gnuarm@gmail.com>
Date: Thu, 25 Jun 2009 12:00:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 25, 2:49 pm, gabor <ga...@alacron.com> wrote:
> On Jun 25, 7:22 am, "Antti.Luk...@googlemail.com"
>
>
>
> <Antti.Luk...@googlemail.com> wrote:
> > On Jun 25, 2:12 pm, "Nial Stewart"
>
> > <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > > > Everybody knows that from user point of view Flash based FPGA are
> > > > better because they are nonvvolatile, tolerable to radiation, do not
> > > > consume high current at startup and better secure intellectual
> > > > property. On the other hand SRAM FPGA are much easier to manufacture.
>
> > > > That's it?
>
> > > No.
>
> > > All I'll say is that if you're used to the sort of P&R results you get
> > > with Altera/Xilinx tools and devices be wary of committing to a transfer
> > > to a Flash based device without a _lot_ of experimenting first.
>
> > > Nial.
>
> > well that counts for ACTEL yes!!!!
>
> > Lattice is almost like Xilinx, even has distributed RAM (only SRL16
> > mode is missing)
> > ic65L is like old Xilinx LUT4FF
>
> > but in generic yes, need run real P&R and compare actual designs
> > before
> > doing any decisions
>
> > Antti
>
> Lattice's mixed flash / SRAM parts also don't have the same
> instant-on and radiation tolerance features of the Actel parts.
> So in essence you lose some of the features to gain better
> density and architecture.

Certainly radiation tolerance is a seldom used feature that has use
only in very specialized applications.  When is the "instant on"
feature needed really?  I don't think I have had an app that needed
"instant on" in the 30 years I have been designing electronics.
Digital stuff always has a reset to hold it off until all power, etc
is ready for operation.  When I use an FPGA, I use one of the FPGA
outputs to hold the rest of the circuit in reset so the FPGA is the
first thing to come alive.  Even if the FPGA is on a PCI bus, I
believe they have provision to give devices time to boot themselves
before they have to respond, no?

Is "instant on" another seldom needed feature?

Rick

Article: 141497
Subject: Re: Cable autodetection/programming the Xilinx Virtex2Pro FPGA
From: Pratap <pratap.iisc@gmail.com>
Date: Thu, 25 Jun 2009 12:50:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 25, 11:45=A0pm, "Chet" <chetfe...@comcast.net> wrote:
> >Hi,
> >I was using the USB cable provided with Xilinx Vertex 2Pro board in my
> >PC earlier. Recently I upgraded my PC to Intel Core2Duo Processor and
> >it's corresponding mother board. Also I have added another NetMOS PCI
> >ECP Parallel port add on as there was no parallel port by default on
> >the mother board.
> >But now I am not able to program the FPGA board.
> >Here are the error messages I get when I do =A0 "Output" ---> "Cable
> >Auto Detect"
>
> >*************************
> >Welcome to iMPACT
> >// *** BATCH CMD : loadProjectFile -file "E:/vhdl_proj/
> >for_2_exp_19_samples/for_2_exp_19_samples.ipf"
> >'1': Loading file 'E:/vhdl_proj/for_2_exp_19_samples/
> >top_module_26th_may_ratioed_avg_for_2exp19_samples.bit' ...
> >done.
> >INFO:iMPACT:1777 -
> >Reading C:/Program Files/Xilinx91i/virtex2p/data/xc2vp30.bsd...
> >WARNING:iMPACT:2257 - Startup Clock has been changed to 'JtagClk' in
> >the bitstream stored in memory,
> >but the original bitstream file remains unchanged.
> >INFO:iMPACT:501 - '1': Added Device xc2vp30 successfully.
> >----------------------------------------------------------------------
> >----------------------------------------------------------------------
> >Active mode is BS
> >// *** BATCH CMD : setMode -ss
> >// *** BATCH CMD : setMode -sm
> >// *** BATCH CMD : setMode -hw140
> >// *** BATCH CMD : setMode -spi
> >// *** BATCH CMD : setMode -acecf
> >// *** BATCH CMD : setMode -acempm
> >// *** BATCH CMD : setMode -pff
> >// *** BATCH CMD : setMode -bs
> >// *** BATCH CMD : setMode -bs
> >// *** BATCH CMD : setMode -bs
> >// *** BATCH CMD : setMode -bs
> >GUI --- Auto connect to cable...
> >// *** BATCH CMD : setCable -port auto
> >AutoDetecting cable. Please wait.
> >PROGRESS_START - Starting Operation.
> >Connecting to cable (Parallel Port - LPT1).
> >Checking cable driver.
> > Driver windrvr6.sys version =3D 8.1.0.0.Connecting to cable (Parallel
> >Port - LPT2).
> >Checking cable driver.
> > Driver windrvr6.sys version =3D 8.1.0.0.Connecting to cable (Parallel
> >Port - LPT3).
> >Checking cable driver.
> > Driver windrvr6.sys version =3D 8.1.0.0.Connecting to cable (Parallel
> >Port - LPT4).
> >Checking cable driver.
> > Driver windrvr6.sys version =3D 8.1.0.0.Connecting to cable (Usb Port -
> >USB21).
> >Checking cable driver.
> > Driver xusbdfwu.sys version: 1021 (1021).
> > Driver windrvr6.sys version =3D 8.1.0.0.Cable connection failed.
> >PROGRESS_END - End Operation.
> >Elapsed time =3D =A0 =A0 =A02 sec.
> >Cable autodetection failed.
> >*************************
>
> >I have no idea how to make the cable detectable now. When I plugin the
> >Xilinx cable, it asks for the drivers and automatically detects them
> >after a click. But still I am not able to load my program into the
> >FPGA board.
> >Waiting for a response.
> >-Pratap
>
> What OS are you using?

I am using Windows...Earlier also I was using Windows.

Article: 141498
Subject: Re: EPM7064 Altera PLD oe1\oe2\gclr1
From: Aldorus <him@hereonearth.com>
Date: Thu, 25 Jun 2009 19:58:28 GMT
Links: << >>  << T >>  << A >>
> I connected pins 1, 2 and 44 to ground as the pin report suggested and
> it worked for me.

pin report?
theres a seperate pin report from the Quartus II software?
where?
would it be there if i assigned the pins manually?


Article: 141499
Subject: pre-initialized dpram functional simulation
From: Serkan <oktem@su.sabanciuniv.edu>
Date: Thu, 25 Jun 2009 13:50:16 -0700 (PDT)
Links: << >>  << T >>  << A >>

I am using Xilinx ISE 9.1.i and Modelsim XE 6.2C
I am generating a dpram_32k using Core Generator.
All I can see is 0s (zero) at the output.
How can I see pre-entered initial values in the functional
simulation?

serkan



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