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 138700

Article: 138700
Subject: Re: Spartan 6 3.3V (was Re: Virtex6 Virtex4 FPGA compatibility)
From: rickman <gnuarm@gmail.com>
Date: Thu, 5 Mar 2009 08:11:48 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 5, 3:44 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
> rickman <gnu...@gmail.com> writes:
> > Anyone know if 3.3 volt I/O is still with us in the new Spartan 6
> > devices?
>
> http://www.xilinx.com/publications/prod_mktg/Spartan6_Overview.pdf
>
> says :
>
> > Multi-voltage, multi-standard SelectIO banks
> > ...
> > - 3.3V to 1.2V I/O standards and protocols
>
> So yes - hurrah!
>
> Any bets on whether the next Spartan family will still have it?
>
> Cheers,
> Martin

I would say that depends on when it comes out.  I don't see any sign
of the 3.3 volt standard going away any time soon.  So over the next
five years, any FPGA aimed at the general logic market will pretty
much *have* to support 3.3 volts.  As the feature sizes shrink we hear
that (at least in the case of Xilinx) it becomes prohibitively
expensive to continue to support higher voltage I/O standards.
Although the semi companies that are making parts that aren't FPGAs
still seem to manage to support 5 volt tolerant I/Os, I guess at some
point this really is true.

It is just a matter of where your market is.  The FPGA vendors have
decided that the market for 5 volt tolerance is not worth the extra
per part cost.  They trade off the design wins they miss out on
because of price vs. the ones they lose on I/O voltages.  That is why
the Spartan and the Virtex lines have diverged at this point.  The
high end stuff does not use as much 3.3 volt TTL I/O as it demands
high speed serial and LVDS.  Spartan is aimed at a different market
that still demands a lot of 3.3 volt I/O without adding expensive and
bulky interface chips.  At some point even the 3.3 volt I/Os will
become a liability and the low cost product lines will drop support.

I think it is especially interesting that Lattice has dropped their
pursuit of the high end market.  I am sure that X and A will spin this
as L not being able to keep up with the big boys.  But there is also
the dynamics of the FPGA market.  It may well be that the high end is
not where the future is.  They may make $500 per 1500 pin/ 10,000,000
gate FPGA, but how many can they sell?  On the other hand, if they can
cost effectively get an FPGA into a digital camera they only need to
make a buck per chip to make millions.  Right now, in the cellular
market, they are pretty much limited to the low quantity base
stations.  If they can ever get a seat at the cell *phone* table, then
the sky is the limit!  And they might not need 3.3 volt compatibility
to do that...

Rick

Article: 138701
Subject: Re: Spartan 3AN wake up problem
From: gabor <gabor@alacron.com>
Date: Thu, 5 Mar 2009 08:29:13 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 5, 7:50=A0am, igalko...@gmail.com wrote:
> I'm using a deserializer 7 to 1 core (from xapp265) in Spartan 3AN.
> After power up it is not functional until I'm retriggering prog_b or
> loading the bit file from JTAG. It's impossible to debug this problem
> with Chipscope because in order to do that I need to load the bit file
> and after that it's working.
> What might be the problem?

Chipscope should be able to use the wake-up configuration without
re-loading the bit file.  You just need to program the version with
the Chipscope core in it into the flash.  Then if the chipscope
core doesn't "fix" the problem you can at least see the state of
the part while it isn't working (Chipscope won't be able to show
you what happens at power-on because the trigger needs to be armed
after you connect).

Article: 138702
Subject: Re: Lattice announces ECP3
From: Jecel <jecel@merlintec.com>
Date: Thu, 5 Mar 2009 09:48:36 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 4, 2:30=A0pm, Luc  wrote:
> but ECP2M is a good alternative.

I'll use those, then. It is easy enough to design different boards
later on.

Thanks for the advice,
-- Jecel

Article: 138703
Subject: Re: writing current date to a register
From: Mike Treseler <mtreseler@gmail.com>
Date: Thu, 05 Mar 2009 10:10:19 -0800
Links: << >>  << T >>  << A >>
oktem@su.sabanciuniv.edu wrote:

> Actually I was not able to do it with the makefile approach since it
> seems harder for me. I need a little more explanation.

Sometimes just editing a file n times
is quicker than automating the process.

Date and time information is already attached
to the source files. This is really a job
for a version control system like svn.

Production is more likely concerned with
release numbers, and these do not change
nearly as often as builds do.

       -- Mike Treseler

Article: 138704
Subject: Want to buy: FPGA T-Shirt $$
From: justforpretend@gmail.com
Date: Thu, 5 Mar 2009 10:42:06 -0800 (PST)
Links: << >>  << T >>  << A >>
I hope this isn't terribly inappropriate to post here.  I want to buy
three FPGA-related T-shirts.  I know that Altera and Xilinx have in
the past given out freebie shirts, and I'm trying to track some down
as gifts for my roommates, who work with FPGAs.  I will pay good money
for them!!

Let me know if you have something lying around that you don't mind
parting with.  They primarily use Altera, so that's preferable.

Thanks!

Article: 138705
Subject: Re: Spartan 6 3.3V (was Re: Virtex6 Virtex4 FPGA compatibility)
From: cs_posting@hotmail.com
Date: Thu, 5 Mar 2009 11:03:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 5, 3:44 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:

> > Multi-voltage, multi-standard SelectIO banks
> > ...
> > - 3.3V to 1.2V I/O standards and protocols
>
> So yes - hurrah!

Not so fast.  Listing 3.3v I/O and having it usable in the real world
are not the same thing.  You need to check how much allowance there is
for overshoot, which will determine how perfect your impedance match
needs to be to be able to use 3.3v I/O in the real world.  I don't
know about the part in question, but for some recent fab processes
there hasn't been much in the way of safety margin.

Article: 138706
Subject: Re: Spartan 6 3.3V (was Re: Virtex6 Virtex4 FPGA compatibility)
From: austin <austin@xilinx.com>
Date: Thu, 5 Mar 2009 11:51:59 -0800 (PST)
Links: << >>  << T >>  << A >>
All,

The fabs will make anything you want.  If you want a 5V IO, that is
what you get.

The market (and here I mean where the money is) wants very fast DDR3
interfaces.  To do this one requires 180nm IO transistors (optimally),
or 250nm IO transistors.

That means 1.8v IO or 2.5v IO.

So, for a FPGA, one must choose the highest performance you need, and
that will constrain your highest voltage options (unless you decide to
have more than one oxide for IO, which greatly increases cost, and
design complexity, decisions as to what to provide, and thus time to
market).

So, Xilinx doesn't decide to 'drop' 3.3v.  The V6 doesn't support 3.3v
IO like in previous families, but S6 does.  The customers told us
quite clearly what was required, for their dollars (yen, NT$, euros,
pounds, etc.).

As for 'safety margin' it is true that more aggressive process means
perhaps less tolerance to overshoot and undershoot.  Hopefully, the
recommended operating levels in the specifications are clear, and good
signal engineering practices are followed.  If you don't care about
SI, then you are likely to have other problems, so it isn't such a big
deal anymore.

Austin

Article: 138707
Subject: NGDBuild 604 Error while implementing the character generator design
From: Vesh <veshrajsharma@gmail.com>
Date: Thu, 5 Mar 2009 11:55:10 -0800 (PST)
Links: << >>  << T >>  << A >>
I was able to generate a character ROM using the Xilinx 10.1 ISE Core
generator and also a RAM using the same. This is only a part of my
final year project, not the project as a whole. But during
implemetation the following error occurred.

ERROR:NgdBuild:604 - logical block 'U_TEXT' with type 'mem_text' could
not be
   resolved. A pin name misspelling can cause this, a missing edif or
ngc file,
   or the misspelling of a type name. Symbol 'mem_text' is not
supported in
   target 'spartan3e'.
ERROR:NgdBuild:604 - logical block 'U_FONT' with type 'mem_font' could
not be
   resolved. A pin name misspelling can cause this, a missing edif or
ngc file,
   or the misspelling of a type name. Symbol 'mem_font' is not
supported in
   target 'spartan3e'.

the 'mem_text' is the generated RAM module and 'mem_font' is the
generated character ROM. U_TEXT and U_FONT are their instants in the
highest level module.

does anyone have a solution. I consulted the Xilinx website for these
errors but of no use.


Article: 138708
Subject: Re: writing current date to a register
From: Glen Herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 05 Mar 2009 14:01:33 -0700
Links: << >>  << T >>  << A >>
Mike Treseler wrote:

> oktem@su.sabanciuniv.edu wrote:

>>Actually I was not able to do it with the makefile approach since it
>>seems harder for me. I need a little more explanation.

> Sometimes just editing a file n times
> is quicker than automating the process.

It would seem that one would want the date/time of
the last make, or at least the last change to be
checked in.  With a manual process it is too
easy to forget.

> Date and time information is already attached
> to the source files. This is really a job
> for a version control system like svn.

I think with make it is possible to have it
remake a file each time, but I don't remember
how to do it.  Is there a way to have cvs or svn
update the date/time on one file when any in the
project is checked in?

Interestingly, pretty much the same question came
up yesterday on comp.lang.fortran.

> Production is more likely concerned with
> release numbers, and these do not change
> nearly as often as builds do.

-- glen


Article: 138709
Subject: Re: Spartan 6 3.3V (was Re: Virtex6 Virtex4 FPGA compatibility)
From: Glen Herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 05 Mar 2009 14:10:15 -0700
Links: << >>  << T >>  << A >>
rickman wrote:
(snip)

> I would say that depends on when it comes out.  I don't see any sign
> of the 3.3 volt standard going away any time soon.  So over the next
> five years, any FPGA aimed at the general logic market will pretty
> much *have* to support 3.3 volts.  As the feature sizes shrink we hear
> that (at least in the case of Xilinx) it becomes prohibitively
> expensive to continue to support higher voltage I/O standards.
> Although the semi companies that are making parts that aren't FPGAs
> still seem to manage to support 5 volt tolerant I/Os, I guess at some
> point this really is true.

Even for the original TTL, logic high was just 2.0 volts.
For an output, you only need to get up to 2.0.  For inputs, many
Xilinx families will do it with a current limiting resistor such
that the protection diodes aren't overdriven.  I suppose one could
add external diodes for extra protection.

For tristate (bidirectional) I/O, though, the resistor approach
probably won't work.  An external protection diode might, though.

> It is just a matter of where your market is.  The FPGA vendors have
> decided that the market for 5 volt tolerance is not worth the extra
> per part cost.  They trade off the design wins they miss out on
> because of price vs. the ones they lose on I/O voltages. 

As far as I understand it, the thicker oxide for higher voltage
results in slower transistors.  You can have speed or volts,
but not both.

> That is why
> the Spartan and the Virtex lines have diverged at this point.  The
> high end stuff does not use as much 3.3 volt TTL I/O as it demands
> high speed serial and LVDS.  Spartan is aimed at a different market
> that still demands a lot of 3.3 volt I/O without adding expensive and
> bulky interface chips.  At some point even the 3.3 volt I/Os will
> become a liability and the low cost product lines will drop support.

-- glen


Article: 138710
Subject: Re: writing current date to a register
From: Mike Treseler <mtreseler@gmail.com>
Date: Thu, 05 Mar 2009 14:41:46 -0800
Links: << >>  << T >>  << A >>
Glen Herrmannsfeldt wrote:

> It would seem that one would want the date/time of
> the last make, or at least the last change to be
> checked in.

That is what version control does.
That is why I use it.

>  With a manual process it is too
> easy to forget.

Maybe for the OP it is better than nothing.

> Interestingly, pretty much the same question came
> up yesterday on comp.lang.fortran.

Guess I've lost interest.
It comes up here regularly.

    -- Mike Treseler

Article: 138711
Subject: Re: writing current date to a register
From: Glen Herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 05 Mar 2009 15:54:00 -0700
Links: << >>  << T >>  << A >>
Mike Treseler wrote:

> Glen Herrmannsfeldt wrote:

>>It would seem that one would want the date/time of
>>the last make, or at least the last change to be
>>checked in.

> That is what version control does.
> That is why I use it.

I suppose I will have to look in the CVS or SVN manual.

I know it updates each file as it is checked in, but
in this case one wants one file/module to contain the
time/date of the last change to any other file/module.

Last time I used SVN or CVS we didn't need that.

-- glen


Article: 138712
Subject: make ise take ngc as source
From: Mike Treseler <mtreseler@gmail.com>
Date: Thu, 05 Mar 2009 15:01:47 -0800
Links: << >>  << T >>  << A >>
Ise 9.2i will not accept a .ngc file as a source file via the gui,
but it does seem to find and use it if I just copy it
into the project directory with where the .v and .vhd files end up.

If anyone has a cleaner method, without regenerating the core,
I would like to hear about it.
Thanks.

      -- Mike Treseler

Article: 138713
Subject: DDR access on Spartan 3E 500 Starter Kit
From: Keith M <kmongm@gmail.com>
Date: Thu, 5 Mar 2009 16:50:45 -0800 (PST)
Links: << >>  << T >>  << A >>
So being new to FPGAs, I've bought a Digilent 3E Starter Kit that has
onboard ddr memory to which I'd like to get access.

What's the best way to get a simple read/write interface to the
memory?  I'm learning verilog and prefer examples or code written in
it.

I've tried a couple options:

1. Memory Interface Generator from Xilinx. (MIG 23)  This looks like
the most robust solution, but the code that is output seems overly
complicated, mostly uncommented, and the example test bench is
anything but straight forward.  The user guide UG086 is written ok.

2. Couple of opencores solutions, including ddr ctrl (the non wishbone
version)  While it's commented better, there is zero documentation.  I
can't get it to synthesize even though it's specifically designed for
my kit.  The problems are related to .ucf constraints, but when I
manually look through them, most of them seem ok.  It's as if the
format of the .ucf file is not what XST(or whatever component that is)
expects, so it generates about 40 errors.

Is accessing this DDR memory more simple via Picoblaze or Microblaze?
Is Microblaze and associated parts free?  I didn't get any CDs
whatsoever w/ my board.

Thanks

Keith

Article: 138714
Subject: Re: DDR access on Spartan 3E 500 Starter Kit
From: Glen Herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 05 Mar 2009 18:25:50 -0700
Links: << >>  << T >>  << A >>
Keith M wrote:

> So being new to FPGAs, I've bought a Digilent 3E Starter Kit that has
> onboard ddr memory to which I'd like to get access.

> What's the best way to get a simple read/write interface to the
> memory?  I'm learning verilog and prefer examples or code written in
> it.

I asked this question not so long ago.  I am also interested
in a simple (if not fast) solution.

-- glen


Article: 138715
Subject: Re: writing current date to a register
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Thu, 05 Mar 2009 19:48:13 -0600
Links: << >>  << T >>  << A >>

>I know it updates each file as it is checked in, but
>in this case one wants one file/module to contain the
>time/date of the last change to any other file/module.

I'm not a make wizard.  I've worked with people who are.

If you have something like a clump of compile steps
and then a link step, it's simple to put an extra
clump of shell commands in front of the link step.
One of them can touch a file and then do whatever
you want, or just use the date command.  That gives
you the date/time when you run that part of make
rather than the time of last checkin.  With a bit more
work, you could get the checkin time of the last file
checked in.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 138716
Subject: Re: DDR access on Spartan 3E 500 Starter Kit
From: Keith M <kmongm@gmail.com>
Date: Thu, 5 Mar 2009 17:50:05 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 5, 8:25=A0pm, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> I asked this question not so long ago. =A0I am also interested
> in a simple (if not fast) solution.
>
> -- glen

Yeah Glen, I saw the thread.

I should have mentioned that I scanned the various threads in the ng
before posting --- but saw nothing that approached an answer that
could help.

Thanks

Keith


Article: 138717
Subject: Re: make ise take ngc as source
From: Muzaffer Kal <kal@dspia.com>
Date: Thu, 05 Mar 2009 18:40:10 -0800
Links: << >>  << T >>  << A >>
On Thu, 05 Mar 2009 15:01:47 -0800, Mike Treseler
<mtreseler@gmail.com> wrote:

>Ise 9.2i will not accept a .ngc file as a source file via the gui,
>but it does seem to find and use it if I just copy it
>into the project directory with where the .v and .vhd files end up.
>
>If anyone has a cleaner method, without regenerating the core,
>I would like to hear about it.
>Thanks.
>
>      -- Mike Treseler

Add the associated .xco file to your project.

-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com

Article: 138718
Subject: Re: Configure FPGA via PCIe
From: sk6357@gmail.com
Date: Thu, 5 Mar 2009 18:58:15 -0800 (PST)
Links: << >>  << T >>  << A >>

This FPGA configuration device uses SPI to receive new FPGA
configuration bitstreams.  Most processors and mezzanine cards
have SPI capability.  Slower than PCIe of course, but would this be
useful?
http://www.intellitech.com/products/systembist.asp

Satish


On Feb 27, 1:58=A0am, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
> rickman wrote:
> > When you refer to "high end" processors, you are talking about a
> > literal handful of devices compared to the hundreds or thousands of
> > types of CPUs that are used in embedded systems. =A0If you are talking
>
> I'm referring to chips like Intel atom, new PowerQuicc IIP/III
> processors etc. They usually have few PCIe ports as a default and if
> they are not enough a switch is needed. And I don't see why
> low end would not adopt PCIe. Each saved pin helps to get into a
> smaller and cheaper package (altough wirebond and PCIe frequencies
> might be challenging).
>
> > about adding a "switch" then you are adding an extra chip and you can
> > just as easily add any sort of chip to facilitate booting the FPGA.
>
> The problem is that there are only few vendors for special bridge chips
> to GPIO etc. But for PCIe switches there are many vendors even
> some with identical pinouts. That helps multisourcing for manufacturing.
> Also Industrial temperature requirements narrow down the choices.
>
> > I'm not familar with PCIe, but I know in PCI apps you can't use the
> > PCI interface to boot the FPGA. =A0Are you talking about an embedded ap=
p
>
> You could use it, if there would be FPGA on the market with hardcore IP
> for PCI and someone would have thought of using it for configuration at
> FPGA vendor. But that would have required too many pins etc. to be a
> good and widely used solution.
>
> > where you can work "around" the PCIe spec and just talk to the FPGA
> > without worrying about the spec'd protocol? =A0In that case you have on=
e
>
> I'm thinking that if you have hardcore IP for PCIe then it can
> immediatly answer to the bus even if the FPGA is not loaded. If the
> PCI configuration space would then have extended configuration register
> that could be used to bang the data in via configuration cycles. Or
> other option would be one hardcoded PCI BAR for the configuration image.
> Memory mapped configuration image also might create some pretty
> interesting opportunities for dynamic reconfiguration.
>
> > of the few apps where your PCIe port is dedicated to the FPGA. =A0Yes,
> > in that case this works. =A0But that is rare enough that the FPGA
> > vendors aren't going to add that capability for those few apps.
>
> With hardcore it can be done in a standard way, altough the boot
> code needs some changes. And SIVGX, V5LXT, V5FXT, V6, S6, ArriaIIGX
> at least have PCIe hardcore already. They just haven't built the
> configuration interface yet (or they might have, but are not
> documenting it). There are usually undocumented features in FPGAs
> that are just not enabled, and might be enabled for few customers
> with custom IP for testing.
>
> > I seem to recall that there was support for a JTAG or some other
> > serial interface on PCI, but it has been so long that I don't recall.
>
> I think you are referring to SMBus. It is I2C style slow (10kHz-100kHz)
> interface. I think it would be too slow for FPGA configuration.
>


Article: 138719
Subject: Re: New person to CPLD programming
From: Alex Freed <alex_news@mirrow.com>
Date: Thu, 05 Mar 2009 19:35:57 -0800
Links: << >>  << T >>  << A >>
Rob Gaddi wrote:
> On Mon, 02 Mar 2009 01:57:58 -0800
> Alex Freed <alex_news@mirrow.com> wrote:
> 
>> dracosilv wrote:
>>> I think I'm going to go with Verilog or VHDL (not 100% sure which
>>> yet, but probably VHDL), since the logic seems pretty simple.
>> I wonder what drives you towards VHDL - not to start a religious war 
>> here. The same functionality can look like
>>
>> module BUFF4(input e, input [3:0] I, output [3:0] O);
>>
>> assign O = (e == 1) ? I : 4'bz;
>> endmodule
>>
>> -Alex.
> 
> And in VHDL as:
> 
> library IEEE;
> use IEEE.STD_LOGIC_1164.all;
> 
> entity BUFE4 is
> 
> port(
>     O  : out std_logic_vector(3 downto 0);
>     E  : in  std_logic;
>     I  : in  std_logic_vector(3 downto 0);
>   );
> end BUFE4;
> 
> architecture BUFE4_V of BUFE4 is
> begin
> 
>   O <= I when (E = '1') else "ZZZZ";
> 
> end BUFE4_V;
> 
> What made the original code a little cumbersome was not using vectors,
> not language choice.
>

That I understand. In fact I learned VHDL before Verilog because it was 
the standard at the time and used in the company I worked for.

My point is that even this optimized VHDL is 13 lines vs. my 3 lines. 
More than a factor of 4. Does it buy any clarity? I'm not arguing. Just 
trying to understand what is it that atracts people to VHDL if they have 
a choice and start from scratch.

-Alex.


Article: 138720
Subject: Re: DDR access on Spartan 3E 500 Starter Kit
From: Glen Herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 05 Mar 2009 21:00:02 -0700
Links: << >>  << T >>  << A >>
Keith M wrote:

> On Mar 5, 8:25 pm, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

>>I asked this question not so long ago.  I am also interested
>>in a simple (if not fast) solution.

> Yeah Glen, I saw the thread.

> I should have mentioned that I scanned the various threads in the ng
> before posting --- but saw nothing that approached an answer that
> could help.

OK.  I thought it was interesting to see pretty much
the same question.  I haven't been working on that much lately.
I will probably try using the BRAMs first and get that working
before going on to the DDR RAM.

Also, I wasn't sure that the MIG output could be used in
open source projects.

-- glen


Article: 138721
Subject: Re: New person to CPLD programming
From: "dracosilv" <dracosilver@wi.rr.com>
Date: Thu, 5 Mar 2009 22:46:13 -0600
Links: << >>  << T >>  << A >>
Alex Freed wrote:
> dracosilv wrote:
>>
>> I think I'm going to go with Verilog or VHDL (not 100% sure which
>> yet, but probably VHDL), since the logic seems pretty simple.
>
> I wonder what drives you towards VHDL - not to start a religious war
> here. The same functionality can look like
>
> module BUFF4(input e, input [3:0] I, output [3:0] O);
>
> assign O = (e == 1) ? I : 4'bz;
> endmodule
>
> -Alex.

Qbasic.  If/then/else and A <= 'B' (basically an A=B sort of thing.

-- 
But they spend 90% of their time standing there looking stupid and (in
your case) eyeballing everyone and wondering how they look naked.
gregvk on what he thinks WalMart greeters do.

In the immortal words of §ñühw¤£f:
This is you not giving a shit?
HA HA I MADE YUO POST!
I win & stuff.

"Over the years, I've seen many jerks come and go. The latest crop is
not as smart. They're less ass and more hole or is it the other way
around? <snicker>" The Daring Dufas

How do he produce so much doo-doo so fast? It's amazing!
The Daring Dufas

Yeah, UPS, Usenet Performance Stupidity.  ^_^
Onideus Mad Hatter

Golly Wiggle!
Uncle Monster





Article: 138722
Subject: Re: Spartan 6 3.3V (was Re: Virtex6 Virtex4 FPGA compatibility)
From: rickman <gnuarm@gmail.com>
Date: Thu, 5 Mar 2009 21:10:03 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 5, 2:03=A0pm, cs_post...@hotmail.com wrote:
> On Mar 5, 3:44 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
>
> > > Multi-voltage, multi-standard SelectIO banks
> > > ...
> > > - 3.3V to 1.2V I/O standards and protocols
>
> > So yes - hurrah!
>
> Not so fast. =A0Listing 3.3v I/O and having it usable in the real world
> are not the same thing. =A0You need to check how much allowance there is
> for overshoot, which will determine how perfect your impedance match
> needs to be to be able to use 3.3v I/O in the real world. =A0I don't
> know about the part in question, but for some recent fab processes
> there hasn't been much in the way of safety margin.

That reminds me of the initial versions of the Spartan 3 which had
*very* tight specs on over and undershoot.  The eventually relaxed it
a bit as a lot of people screamed about it... at least they did here.
Hopefully that lesson has been learned.

Rick

Article: 138723
Subject: Re: Digilent Nexys 2 Issue
From: dave@embeddedcomputer.co.uk
Date: Thu, 5 Mar 2009 21:11:41 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi Steve,

I am running Windows XP Pro
No shorting of anything being used.
The mode jumper JP9 is set to JTAG.

I have even used the board with an Altium USB JTAG interface and it
detects the JTAG chain.

You may have a faulty board.

Good luck.

Dave...

On Feb 4, 10:59=A0am, "freesp...@gmail.com" <freesp...@gmail.com> wrote:
> * your OS version
> * whether you are shorting any pins on the JTAG port
> * setting of the MODE jumper (jp9)
>
> Cheers,
> Steve

Article: 138724
Subject: Re: make ise take ngc as source
From: Jan Pech <invalid@void.domain>
Date: Fri, 06 Mar 2009 08:17:30 +0100
Links: << >>  << T >>  << A >>

On Thu, 2009-03-05 at 15:01 -0800, Mike Treseler wrote:
> Ise 9.2i will not accept a .ngc file as a source file via the gui,
> but it does seem to find and use it if I just copy it
> into the project directory with where the .v and .vhd files end up.
> 
> If anyone has a cleaner method, without regenerating the core,
> I would like to hear about it.
> Thanks.
> 
>       -- Mike Treseler

Of course, ISE accepts NGC files as sources but you have to set the
"Top-Level Source Type" to NGC/NGO instead of HDL.

Jan




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