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 127875

Article: 127875
Subject: Re: How to program FPGA permanently?
From: Vagant <vladimir.v.korostelev@rambler.ru>
Date: Wed, 9 Jan 2008 10:36:50 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 9, 8:24=A0pm, Kris Vorwerk <kris.vorw...@gmail.com> wrote:
> > I have downloaded my program to FPGA and it works as it supposed to
> > do. However, I need to download it every time after I switch power
> > off. Hence I wonder - how to save program on FPGA permanently so that
> > it would work even after power was switched off and on again?
>
> Some vendors sell FPGAs which are SRAM-based; these devices lose their
> configuration when the power goes out. =A0They need to have a separate
> EEPROM connected to the FPGA. =A0This is usually well-documented in
> application notes for your particular vendor.
>
> Some vendors sell FPGAs which are SRAM-based but have nonvolatile
> storage built into the FPGA, so that when the power goes out, they
> reload the configuration from the onboard NVRAM. =A0These devices are
> also offered by most vendors.
>
> Actel ships FPGAs which are entirely flash-based; all configuration
> bits are non-volatile, so they retain their configuration when the
> power goes out. =A0Actel also ships antifuse-based FPGAs, which are one-
> time programmable, but won't lose their configuration.
>
> K.

Thank you. My FPGA is XC3S1600E and I will take look in application
notes.

Article: 127876
Subject: Creation of BUGMUX from non clock signals
From: axr0284 <axr0284@yahoo.com>
Date: Wed, 9 Jan 2008 10:45:05 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,
 I have a piece of VHDL code that is causing Xilinx ISE to pass non
clock lines through BUFGMUXes instead of using BUFGMUXes with only
clock lines. I currently cannot put the code on here since it's
proprietary. I just wanted to know if anybody had any general idea of
what could be causing it.
Amish

Article: 127877
Subject: Re: Real examples of metastability causing bugs
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 09 Jan 2008 10:48:29 -0800
Links: << >>  << T >>  << A >>
-jg wrote:

(snip)

> Most discussions use a simple model ot a log-log plot,
> on a couple of data points -  fine as a 'there be dragons' 
 > type warning, but not what I'd call true engineering..

The assumption is that it is exponential.  I don't know if you
can prove that or not.  Also, the measurements are not easy
and the result will be very sensitive to the exact timing.

I had the idea once in a discussion here of building a metastability
locked loop.  That is, a PLL with a FF in the feedback loop such that
the phase adjustment goes toward the metastability point.  That would
maximize the number of metastability events.  Then you need to find
a way to measure the resolving time and graph it...

-- glen


Article: 127878
Subject: Re: How to program FPGA permanently?
From: austin <austin@xilinx.com>
Date: Wed, 09 Jan 2008 10:52:56 -0800
Links: << >>  << T >>  << A >>
Vagant,

Put the program in a flash memory (non voltatile memory), so that the
FPGA programs itself every time it gets turned on (this only takes a few
tens of milliseconds, at most).

http://www.xilinx.com/publications/xcellonline/xcell_53/xc_solutions53.htm

The above solution uses the very inexpensive and readily available SPI
flash memories, or you may get a Spartan 3AN with the flash and the FPGA
in the same package.

Austin

Vagant wrote:
> Hello,
> 
> I have downloaded my program to FPGA and it works as it supposed to
> do. However, I need to download it every time after I switch power
> off. Hence I wonder - how to save program on FPGA permanently so that
> it would work even after power was switched off and on again?

Article: 127879
Subject: Re: Real examples of metastability causing bugs
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 9 Jan 2008 11:28:16 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 9, 10:48=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> -jg wrote:
>
> (snip)
>
> > Most discussions use a simple model ot a log-log plot,
> > on a couple of data points - =A0fine as a 'there be dragons'
>
Glen,
I have been thinking about this for decades, but I now consider it
hopeless.
If you believe the results of my statistical measurements, then you
realize that the capture window for a metastable delay of more than 2
ns is not picoseconds, but a fraction of a femtosecond.
There is no way to keep the circuitry stable within such a narrow
timing window. And if you could, how do you derive any quantitative
data from it?
I remain convinced that the randomly asynchronous testing approach is
the only one that gives us reliable results.
Peter Alfke

> =A0> type warning, but not what I'd call true engineering..
>
> The assumption is that it is exponential. =A0I don't know if you
> can prove that or not. =A0Also, the measurements are not easy
> and the result will be very sensitive to the exact timing.
>
> I had the idea once in a discussion here of building a metastability
> locked loop. =A0That is, a PLL with a FF in the feedback loop such that
> the phase adjustment goes toward the metastability point. =A0That would
> maximize the number of metastability events. =A0Then you need to find
> a way to measure the resolving time and graph it...
>
> -- glen


Article: 127880
Subject: Re: How to program FPGA permanently?
From: John McCaskill <jhmccaskill@gmail.com>
Date: Wed, 9 Jan 2008 11:38:27 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 9, 12:01 pm, Vagant <vladimir.v.koroste...@rambler.ru> wrote:
> Hello,
>
> I have downloaded my program to FPGA and it works as it supposed to
> do. However, I need to download it every time after I switch power
> off. Hence I wonder - how to save program on FPGA permanently so that
> it would work even after power was switched off and on again?


You mentioned previously that you are using the Spartan 3E 1600E
Microblaze Development Kit. The user guide for it is here:

http://www.xilinx.com/support/documentation/boards_and_kits/ug257.pdf

Take a look at the chapter "FPGA Configuration Options".  It describes
the various configuration memories that are on the board, and how to
put your program into those memories.

If you program one of the configuration memories on the board with
your bitfile, and have the jumpers set to use that memory, then your
bitfile will be loaded every time you power on the board.

If you changed your startup clock to be the Jtag clock to get rid of
the warning you mentioned in your last thread, don't forget to change
it back to the CCLK option.

Regards,

John McCaskill
www.FasterTechnology.com


Article: 127881
Subject: Re: Identification of FPGA Development Board
From: Ben Jackson <ben@ben.com>
Date: Wed, 09 Jan 2008 13:39:58 -0600
Links: << >>  << T >>  << A >>
On 2008-01-09, koltes@fmi.uni-passau.de <koltes@fmi.uni-passau.de> wrote:
>
> recently, I acquired an old FPGA development board out of the
> remainder of stock of a company. The board has quite powerful FPGAs on

That doesn't look like a development board to me.  It's probably a
prototype of a commercial product.  Prototype because the rework looks
a little sloppy to me.  The unidentified chips are probably ASICs.
It's unlikely that you will ever find enough data to do anything useful
with this board.

Also the high-end Virtex II devices didn't used to be in the Webpack,
but I haven't checked in a long time.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 127882
Subject: Re: Using DDR SDRAM as single data rate ..?
From: Ben Jackson <ben@ben.com>
Date: Wed, 09 Jan 2008 13:43:01 -0600
Links: << >>  << T >>  << A >>
On 2008-01-09, posedge52@yahoo.com <posedge52@yahoo.com> wrote:
> Is it possible to use DDR SDRAM as single data rate SDRAM and thus
>...
> The idea is to ignore the data sent on the second flank,

I've always wondered that myself.  I hope someone who knows will
understand and answer your question.  So far people seem to be stuck
on the clock rate issue instead of the question of whether you can
just store/read the same data on the rising/falling edge during the
transfers and treat it like an SDR SDRAM.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 127883
Subject: Re: MPMC3, DDR 32Mx16, S3E1200, single bank, impossible?
From: Guru <ales.gorkic@email.si>
Date: Wed, 9 Jan 2008 11:44:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 9, 1:14 pm, Joseph Samson <u...@not.my.company> wrote:
> Guru wrote:
> > Hi all,
>
> > I wonder if it possible to make a MIG1.73 compliant design by
> > connecting 32Mx16 DDR SDRAM to a single bank on a FG320 Spartan3E1200?
> > Btw MIG1.73 compliance is a must for using the MPMC3 memory controller
> > in EDK9.2.
>
> > Unfortunately the MIG coregen does not allow to put all of the DDR
> > pins in a single bank.
>
> It wasn't a problem in MIG 1.5, and when MIG 1.6 came out, I verified
> that it generated a ucf with the same pinouts as MIG1.5. I haven't tried
> MIG 1.7.
>
> ---
> Joe Samson
> Pixel Velocity

 Hi Joe,

Aren't you using Virtex series? It is more suitable for MIG phy I
think.

The problem with this particular Spartan3E package is that banks 1 and
3 have just enough pins (except for calibration loop) for 32Mx16 DDR,
but MIG does not want to use them (it forces clocks to bank 0 and 2).
If I follow MIG guidelines then I loose another bank - it should be
connected to 2.5V.

I have never used MIG before and I do not know how to surpass these
limitations.
Any help is welcome.

Cheers,

Ales


Article: 127884
Subject: Synthesizing big RAMs
From: "Xin Xiao" <x@x.com>
Date: Wed, 9 Jan 2008 20:45:39 +0100
Links: << >>  << T >>  << A >>
Hi, I would like to implement a 64K x 16-bit RAM, but no FPGA of my design 
tool (Xilinx ISE) has enough blocks or LUTs. Is it possible to implement 
such big RAMs in FPGAs?

My code is VHDL.

Thanks


Article: 127885
Subject: Re: Real examples of metastability causing bugs
From: John_H <newsgroup@johnhandwork.com>
Date: Wed, 9 Jan 2008 11:58:41 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 9, 10:35=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
<snip>
> ... Efficient logic design
> maximizes the logic between register stages, and so gets closer
> to failure due to metastability caused delay. =A0A synchronizing
> register allows the maximum time for metastability to be
> resolved before entering the next FF.

A single synchronizing register DOES NOT allow the maximum time for
metastability.  Two synchronizing registers are closer to "correct."

With only one synchronizing flop for one control signal - ignoring
vectors for the moment - the only way to guarantee logic will work
properly with this single flop on "this side" of the time domain is to
tighten the timing constraint such that any metastability delay is
acceptable in the system.  If the tightened constraint is too
difficult, a second single flop is needed to distribute the
synchronized signal.

- John_H

Article: 127886
Subject: Re: MPMC3, DDR 32Mx16, S3E1200, single bank, impossible?
From: Joseph Samson <user@not.my.company>
Date: Wed, 09 Jan 2008 15:13:55 -0500
Links: << >>  << T >>  << A >>
Guru wrote:
> Aren't you using Virtex series? It is more suitable for MIG phy I
> think.

This product is on Spartan 3E 1600, but the original work was using the 
1200.
> 
> The problem with this particular Spartan3E package is that banks 1 and
> 3 have just enough pins (except for calibration loop) for 32Mx16 DDR,
> but MIG does not want to use them (it forces clocks to bank 0 and 2).

Which clocks do you mean - a master oscillator input? MIG wants that on 
bank 0 or 2 because those have the global clock inputs. Bank 3's LHCLK 
local clocks will only supply the left hand side of the chip. The global 
clocks supply the entire chip. I suppose that you could generate a 
design that had the pinouts that you like in Bank 3, then investigate 
modding the code to use a LHCLK input. In the design that MIG1.5 
generated, LHCLK1 was unused.

> If I follow MIG guidelines then I loose another bank - it should be
> connected to 2.5V.
There are lots of oscillators available; there is probably one that 
supports the standard that you want for bank 0 or 2.


---
Joe

Article: 127887
Subject: Re: Real examples of metastability causing bugs
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 09 Jan 2008 12:25:47 -0800
Links: << >>  << T >>  << A >>
In response to my post:

 >>I had the idea once in a discussion here of building a metastability
 >>locked loop.  That is, a PLL with a FF in the feedback loop such that
 >>the phase adjustment goes toward the metastability point.  That would
 >>maximize the number of metastability events.  Then you need to find
 >>a way to measure the resolving time and graph it...

Peter Alfke wrote:

> I have been thinking about this for decades, but I now consider it
> hopeless.

Much longer that I have thought about it.

> If you believe the results of my statistical measurements, then you
> realize that the capture window for a metastable delay of more than 2
> ns is not picoseconds, but a fraction of a femtosecond.
> There is no way to keep the circuitry stable within such a narrow
> timing window. 

It did occur to me while writing that, that temperature variations
would shift the metastable point.  The goal of the MLL is to maximize
the rate of observations of metastability...

 > And if you could, how do you derive any quantitative
 > data from it?

The only one I have thought of so far is to add a variable
voltage sine to the MLL feedback loop.  Increasing the voltage
should decrease the probability of 2ns metastability events.

Not having the design for the feedback loop of the MLL, it seems
that there might be a gate with a signal that is high for the
amount of time of the metastability, plus or minus some propagation
delays.  Those delays would have to be measured, and then the
average metastability time could be measured by the average
voltage on that line.  The change in the average time with
the sine voltage disturbing the feedback loop, and the time
variation due to the feedback voltage, would allow one to
determine the probability vs. metastability time curve.

> I remain convinced that the randomly asynchronous testing
> approach is the only one that gives us reliable results.

It would seem to require simpler measurements than the MLL.

-- glen


Article: 127888
Subject: Re: Synthesizing big RAMs
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Wed, 09 Jan 2008 13:27:42 -0700
Links: << >>  << T >>  << A >>
Xin Xiao wrote:
> Hi, I would like to implement a 64K x 16-bit RAM, but no FPGA of my 
> design tool (Xilinx ISE) has enough blocks or LUTs. Is it possible to 
> implement such big RAMs in FPGAs?
> 
> My code is VHDL.
> 
> Thanks
> 
That is 1Mbit, and plenty of Xilinx parts have that much blockRAM.  That 
is "only" about 32 V5 blockRAMs, and every V5 part has at least that 
much.  If you just want a large RAM with a single access point, it's 
often best to use an external RAM and a smaller FPGA.  The blockRAMs are 
designed for parallel processing.  -Kevin

Article: 127889
Subject: Re: Using DDR SDRAM as single data rate ..?
From: Daniel Koethe <dkoethe@nospam-web.de>
Date: Wed, 09 Jan 2008 21:32:05 +0100
Links: << >>  << T >>  << A >>
In my opinion it should possible, but if you are a beginner. Do not 
start learning with a design of a memory controller. You will not 
successful and very frustrated. :-(

At DDR-Memories the timing critical operation is read. You must delay 
the DQS-Signal or a phase synchron clock signal by 90°. With this clock 
signal the data from the memory is sampled in two flip-flops one at 
rising a second at falling edge.

Assuming you double your data at write. This halves the memory size by two.

When you read back your data, you can shift the DQS direct by 180°(done 
with a simple inverter) and sample between the data0 and data1. The 
timing window should also doubled.

But this is only possible, if the read data is stable from setup of 
data0 to the end of data1. I think this will not guaranteed by any 
memory manufacturer.

Remark: This is only a theoretical assumption!

Daniel


posedge52@yahoo.com schrieb:
> Is it possible to use DDR SDRAM as single data rate SDRAM and thus
> eliminate the need for DCM's and tight clock frequency
> specifications ..?
> 
> The idea is to ignore the data sent on the second flank, and the
> timings associated with the DLL. The price is ofcourse half the
> datacapacity and half the speed. But the benefit is less complicated
> setup.

Article: 127890
Subject: Re: Synthesizing big RAMs
From: Eric Smith <eric@brouhaha.com>
Date: Wed, 09 Jan 2008 12:46:02 -0800
Links: << >>  << T >>  << A >>
Xin Xiao wrote:
> I would like to implement a 64K x 16-bit RAM, but no FPGA of my
> design tool (Xilinx ISE) has enough blocks or LUTs.

Incorrect.  Most Xilinx FPGAs have 18 Kbit block RAMs.  There are
parts with 64 or more block RAMs, for instance, all but the smallest
Virtex-4 parts, most Virtex-5 parts, Spartan 3 XC3S4000 and up, or
any Spartan-3A DSP, 

Article: 127891
Subject: Re: Real examples of metastability causing bugs
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 9 Jan 2008 13:20:50 -0800 (PST)
Links: << >>  << T >>  << A >>
The asynchronous test is a real beauty.
By adjusting one frequency, you can have the detected metstable events
come in at kilohertz speed, or at the much lower rate of one or two
during the lunch break or even overnight.
And it confirms the logarithmic relationship.
Real fun! (If the phenomenon itself weren't so ugly...)
Peter Alfke


Article: 127892
Subject: Re: Creation of BUGMUX from non clock signals
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Wed, 09 Jan 2008 14:52:12 -0700
Links: << >>  << T >>  << A >>
axr0284 wrote:
> Hi,
>  I have a piece of VHDL code that is causing Xilinx ISE to pass non
> clock lines through BUFGMUXes instead of using BUFGMUXes with only
> clock lines. I currently cannot put the code on here since it's
> proprietary. I just wanted to know if anybody had any general idea of
> what could be causing it.
> Amish
If you have a very high fanout on one line, sometimes a synthesizer will 
instantiate a global clock buffer for that line.  But it's also possible 
that the line is, unbeknownst to you, a clock.  You might have 
accidentally inferred a gated clock or a latch so that the line is 
actually driving a clock input somewhere.  -Kevin

Article: 127893
Subject: Re: Creation of BUGMUX from non clock signals
From: John McCaskill <jhmccaskill@gmail.com>
Date: Wed, 9 Jan 2008 15:17:14 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 9, 3:52 pm, Kevin Neilson <kevin_neil...@removethiscomcast.net>
wrote:
> axr0284 wrote:
> > Hi,
> >  I have a piece of VHDL code that is causing Xilinx ISE to pass non
> > clock lines through BUFGMUXes instead of using BUFGMUXes with only
> > clock lines. I currently cannot put the code on here since it's
> > proprietary. I just wanted to know if anybody had any general idea of
> > what could be causing it.
> > Amish
>
> If you have a very high fanout on one line, sometimes a synthesizer will
> instantiate a global clock buffer for that line.  But it's also possible
> that the line is, unbeknownst to you, a clock.  You might have
> accidentally inferred a gated clock or a latch so that the line is
> actually driving a clock input somewhere.  -Kevin


There was a recent thread discussing trying to use the clock lines for
a reset signal:

http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/c873f62c9a2b532d/1160752786dc035a?lnk=gst&q=reset+on+bufg#1160752786dc035a

or: http://tinyurl.com/2agz6f

In it, Austin stated that prior to the Virtex 5 it was not possible to
route a logic signal on a clock line.

What chip are you using?

If it is prior to the Virtex 5, your logic is creating a register or a
latch using that signal. If you look in the place and route report, it
has a list of clocks and their fan outs.  See if it list your signal
as a clock.  You could also load the design in the FPGA editor and
select that signal to see where it goes.

Regards,

John McCaskill
www.FasterTechnology.com


Article: 127894
Subject: Re: Using DDR SDRAM as single data rate ..?
From: ghelbig@lycos.com
Date: Wed, 9 Jan 2008 16:34:39 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 8, 10:43 pm, posedg...@yahoo.com wrote:
> Is it possible to use DDR SDRAM as single data rate SDRAM and thus
> eliminate the need for DCM's and tight clock frequency
> specifications ..?
>
> The idea is to ignore the data sent on the second flank, and the
> timings associated with the DLL. The price is ofcourse half the
> datacapacity and half the speed. But the benefit is less complicated
> setup.

There may be a "chicken & egg" problem doing this.

Some DDR's have a "x.5 clock" latency - you need to get data on the
"other" edge.

To re-configure the part, you (most likely) need to send a
configuration command which will use both edges.

Try it and see!  The Micron models should simulate this properly.

G.

Article: 127895
Subject: Xilinx ISE 7.1 to 9.2 Width Mismatch
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Wed, 9 Jan 2008 18:54:02 -0800
Links: << >>  << T >>  << A >>
I am getting 'width mismatch' warning on the
char_slv assignement and text garbage after
synthesis on this code that ran fine on ISE 7.1

Does any one have an idea of what's wrong?

Thanks much,
Brad Smallridge
AIVision

type text_type is array(0 to 2047) of character;
constant text : text_type :=
"   Bling 003   AiVision    Pat. 5,768,421 " &
. . .
"                                          " ;

signal char_slv  : std_logic_vector(6 downto 0);

begin

text_proc: process(clk)
variable char_val : character;
variable char_pos : integer;
begin
 if(clk'event and clk='1') then
 if(en='1') then
   char_val := text(to_integer(unsigned(text_index)));
   char_pos := character'pos(char_val);
   char_slv <= std_logic_vector(to_unsigned(char_pos, char_slv'length));
 end if;
 end if;
 end process;



Article: 127896
Subject: Re: Synthesizing big RAMs
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Wed, 9 Jan 2008 19:17:04 -0800
Links: << >>  << T >>  << A >>
I answered your code on the comp.vhdl group.
I think what you don't understand is that
if your dout statement is outside your clk block,
you will get what Xilinx calls an unregistered output.

For some reason, Xilinx decided that unregistered RAM
is distributed, that is, it is made up indivivdual
registers scatered throughout the fabric.

If the output is registered, on the other hand,
then ISE will drop your RAM into BRAM or Block RAM,
which is much more abundant in most Xilinx parts,
and also you will not task the synthesis tool to
scatter and then route your RAM, which is very time
consuming.

Try this for more memory models:
http://toolbox.xilinx.com/docsan/3_1i/data/fise/xst/chap02/xst02013.htm

Brad Smallridge
AiVision




Article: 127897
Subject: Re: Using DDR SDRAM as single data rate ..?
From: Ben Jackson <ben@ben.com>
Date: Wed, 09 Jan 2008 21:23:54 -0600
Links: << >>  << T >>  << A >>
On 2008-01-10, ghelbig@lycos.com <ghelbig@lycos.com> wrote:
> To re-configure the part, you (most likely) need to send a
> configuration command which will use both edges.

Ah yes, I hadn't considered the mode registers.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 127898
Subject: How to program and initialize Lattice XP devices
From: rickman <gnuarm@gmail.com>
Date: Wed, 9 Jan 2008 22:03:44 -0800 (PST)
Links: << >>  << T >>  << A >>
I am planning to use the Lattice XP flash based FPGA in a new design
and I have not worked with it before.  It seems to be a RAM based FPGA
which contains an internal flash for self booting.  I need to provide
an external JTAG port for factory programming, a system JTAG port for
in system programming by an embedded CPU and also allow the XP device
to boot itself in normal operation.

I understand how to use the JTAG port and I have set up controls to
allow it to be programmed from one of two sources on the JTAG port.
But I have not been able to find sufficient info to tell me what to do
after the device has been JTAG programmed in system.  Once the JTAG
port takes over control of the device, how do I exit that mode?  The
flash will contain the new configuration information, but how do I get
the XP device to load the RAM from the flash without cycling power?
Is cycling the PROGRAM_N pin sufficient?  I am planning to set the CFG
pins to 1, 1 for self program mode.

I may have a bit of trouble with this since I am designing a new board
to take the place of an older design using a simpler flash based
CPLD.  In that design the system could drive the JTAG port to
reprogram the CPLD.  That device would be immediately available with
the new load once programming was complete. With the XP device, once
the flash is reprogrammed by the system via JTAG, I believe it has to
be told to reboot the SRAM from the flash which I don't have a simple
way of doing.  I may have to share a incoming board pin between a
board disable control and the PROGRAM_N control.. if this is what is
required to reboot the device.

Anyone here know for sure that toggling the PROGRAM_N pin is needed
and sufficient to reload the SRAM from the Flash?


Article: 127899
Subject: OPB Emac : Sending a frame
From: Surya <aswingopalan@gmail.com>
Date: Wed, 9 Jan 2008 22:20:35 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello,

I am trying to send one single ethernet frame using Ethernet lite core
in the XUP2VP board from Digilent Inc. I am unable to do so. I am
trying to capture the sent packet using Wireshark (Ethereal). However,
i am not receiving any packet. But if i repeat the send functional
call in a for loop from 46 bytes to 1500 bytes, the frames are
received in the packet capture utility. (though not all of them, but
some 900-1000 frames)

i am using the XEmacLite_Send function call to send an ethernet
frame.

Is there an issue which i need to look at while sending a single
frame? kindly advice.

I tried to replace Emac Lite with OPB Emac (the full version), the
results are far worse. Not even a single frame is transmitted even if
i put it in a loop.. the opb emac has been configured as a master. I
am working with the PPC. In this case i am using the XEmac_PollSend
function.

Any help would be appreciated. I have not written any program of my
own. the reference design itself is not working.

Thanks in advance!

Regards,
Surya



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