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 15850

Article: 15850
Subject: Re: std_logic_arith
From: William <wlhunterjr@hti.com>
Date: Fri, 16 Apr 1999 15:53:38 -0500
Links: << >>  << T >>  << A >>
The assert condition will report when the condition is false.

Pieter Op De Beeck wrote:

> Hi,
>
> I was wondering what the following slice of code is all about (it is
> from the std_logic_arith package in the IEEE library) :
>
> in function CONV_INTEGER (line 2045 :) )
> ...
> assert ARG'length <= 32
>   report "ARG is too large in CONV_INTEGER"
>   severity FAILURE;
> ...
>
> my question : should the 'smaller than or equal' sign not be a 'larger'
> sign?
> If not, could you please explain?
>
> greetings,
> Pieter



Article: 15851
Subject: partial reconfiguration
From: Asa Kalavade <kalavade@bell-labs.com>
Date: Fri, 16 Apr 1999 16:55:39 -0400
Links: << >>  << T >>  << A >>

A question on partial reconfiguration:

I am trying to understand partial reconfiguration on the Virtex devices. 
Any pointers? 

Some of my current questions:
- How is the partial bitstream generated? What tool support exists?
- How is the area of the device to be reconfigured specified?
- How is the new partial configuration loaded at run-time?
- What is the partial re-configuration delay (as a function of area)?
Any other information is appreciated.

thanks,
Asa
kalavade@lucent.com
Article: 15852
Subject: Re: std_logic_arith
From: Richard Guerin <guerin2@home.com>
Date: Fri, 16 Apr 1999 21:24:03 GMT
Links: << >>  << T >>  << A >>
In VHDL, the integer data type represents a mathematical integer value
who's range is bounded by +/- 2^31 - 1. The assertion statement ensures
that arguments passed to the function are within the valid integer
range.  A failure is reported only if the assertion fails .... that is,
a failure is reported if more than 32 bits are required to represent the
argument being passed to the CONV_INTEGER function.  Hope that helps :-)


Pieter Op De Beeck wrote:
> 
> Hi,
> 
> I was wondering what the following slice of code is all about (it is
> from the std_logic_arith package in the IEEE library) :
> 
> in function CONV_INTEGER (line 2045 :) )
> ...
> assert ARG'length <= 32
>   report "ARG is too large in CONV_INTEGER"
>   severity FAILURE;
> ...
> 
> my question : should the 'smaller than or equal' sign not be a 'larger'
> sign?
> If not, could you please explain?
> 
> greetings,
> Pieter
Article: 15853
Subject: Re: 75% PAL video bars
From: bob elkind <eteam@aracnet.com>
Date: Fri, 16 Apr 1999 15:01:28 -0700
Links: << >>  << T >>  << A >>
It is *way* easier to generate the data words in a 4:2:2 data stream,
and then use a cheap ($5-$20) PAL video encoder.  The results will be
way better than what you can get trying to do (digital) PAL on your own.

Samsung makes some very good encoders.  So do Brooktree (a div of
Rockwell) and Philips.  Be warned that Brooktree and Philips make
encoders and decoders that span a broad quality range.  Spend the
extra $5-$10 to get one of their "better" devices.

-- Bob Elkind

Todd Kline wrote:
> 
> Hi Alessandro,
> 
> Can you get a copy of "Video Demystified" by Keith Jack (Hightext Publications) or some other such book?  There are many
> little details in generating the base timing signals which requires good documentation.
> 
> I assume you only need to support the 625 line PAL with a 4.43361875 MHz color-subcarrier (csc) frequency (Fsc) and you will
> be feeding an 8-bit A/D.
> 
> There are three basic problems:
> 
> 1.) Generate the base composite video (CV) signal.  This is done with two counters, one to count horizontal pixel ticks, and
> another to count lines.  Decode these counters to generate the edge transitions and gating signals.
> 
> 2.) Next you have to generate the color-subcarrier (a sine wave) and the burst signal and insert the burst signal into the CV
> signal on the proper lines at the proper location.  For PAL, the burst is rotated +/- 135 degrees from the csc.  The +/-
> component is called the PAL switch.  If not handled properly, the PAL switch will drive you batty.  =80
> 
> The csc frequency and the horizontal frequency are related as follows:
> 
> Fsc = (1135/4 + 1/625) * Fh, where Fh = horizontal line frequency
> 
> 1135/4=283.75 => the .75 causes the csc to drift backwards by 90 degrees per line,
> 
> 1/625 => every frame (i.e. two fields) an extra cycle has accumulated.
> 
> Both of these factors will conspire to make your life interesting.  The clock frequency you select to generate your video will
> dictate how you manage these two factors.  If you select a clock running at 4xFsc, your csc generation is easy, but you need
> to add two extra clocks (1137) at the end of each field to "catch-up" to the 1/625 term which you are ignoring.  You can also
> run at 13.5 MHz but you will need sin/cos look-up tables.  This is O.K. for FPGA's.  It is not appropriate for PLD's.
> 
> 3.) Finally, you have:
> 
> Em = E'y + E'v * sin(2nFsc') +/- E'v * cos(2nFsc') = Yuck!
> 
> It's not really as bad as it looks.  The +/- comes from the PAL switch again.  The sin and cos are the color-subcarriers.
> E'y, E'v, and E'v are the YUV components of the video.  If running at 4xFsc, the sin/cos multiplies become simple shift/add
> functions.  If running at 13.5MHz, you need real multipliers.
> 
> The Em term then gets added to the CV signal from 2.
> 
> 
> 75% amplitude, 100% saturation color bars:
>    White  Yellow  Cyan  Green  Magenta  Red  Blue  Black
> Y   137     91     72     60     42      31   12     0
> U    0     -45     15    -30     30     -15   45     0
> V    0      10    -63    -53     53      63  -10     0
> 
> I repeat, GET GOOD DOCUMENTATION.
> 
> Hope this helps to get you started.
> 
> Todd
> 
> Alessandro Caserta wrote:
> 
> > Hello to everyone who can help.
> > I would like to implement a PAL cinescope (PAL monitor 75% color BAR)
> > using a PLD alone or in conjunction with an EPROM, does any experienced
> > programmer of such devises know how to implement such a thing? could you
> > help in this "to me" very important matter ?
> >
> > the second Q. may be stupid. any one knows what is the differences
> > between microcontrollers and EPROMs, which is better?
> >
> > reply to following emails:
> >
> > alcasert@tin.it
> > Alessandro.Caserta@orbit.net
> >
> > solong and onece again thanks.
Article: 15854
Subject: Industry Network?
From: sjeffers@netcom.com (Sandy Jeffers)
Date: Fri, 16 Apr 1999 23:52:42 GMT
Links: << >>  << T >>  << A >>
Thought this might be of interest to the group.

-Sandy

>MIME-Version: 1.0
>To: Sandy Jeffers <sjeffers@netcom.com>
>Subject: Industry Network Project
>Content-Transfer-Encoding: 7bit
>Content-Type: text/plain; charset=us-ascii
>Content-Length: 1056
>
>
>
>ELECTRONIC PRODUCTS magazine is forming a network 
>of industry professionals that we can contact/interview 
>for stories we're researching for publication. The goal is
>to include feedback from more practicing EEs/design engineers
>in our stories.
>
>If you'd like to participate, please fill-out 
>the web form at:
>
> http://www.enlist.com/cgi-bin/eps3
>
>As a token of our thanks, I'd like to offer you 
>a free subscription to ELECTRONIC PRODUCTS.
>And feel free to forward this message on to colleagues at
>your company who might have an interest in participating.
>
>Regards,
>
>Barry Green
>ELECTRONIC PRODUCTS Magazine

------- End of Forwarded Message
Article: 15855
Subject: Re: std_logic_arith
From: Tim Davis <timdavis@tdcon.com>
Date: Fri, 16 Apr 1999 19:08:25 -0600
Links: << >>  << T >>  << A >>
Pieter,

The assert statement makes a claim of truth. IE it ASSERTS (or claims) that the expression should
always be true. When it isn't true the message is REPORTed with the SEVERITY of failure.
Consequently the programmer who wrote the description is saying that the length of the argument
vector must always be 32 or less. This is a bit of VHDL that always throws people. You might also
see this crazy statement:

   assert false report "Simulation Finished" severity note;

Since the expression (the assertion) is always "false" (ie the assertion is not TRUE) the report
message will always be printed when the simulator gets around to executing the statement in a
process. In VHDL'93 they made it easy and you can just use the following:

     report "Simulation Finished" severity note;

Hope that helps.

Pieter Op De Beeck wrote:

> Hi,
>
> I was wondering what the following slice of code is all about (it is
> from the std_logic_arith package in the IEEE library) :
>
> in function CONV_INTEGER (line 2045 :) )
> ...
> assert ARG'length <= 32
>   report "ARG is too large in CONV_INTEGER"
>   severity FAILURE;
> ...
>
> my question : should the 'smaller than or equal' sign not be a 'larger'
> sign?
> If not, could you please explain?
>
> greetings,
> Pieter

--

Tim Davis
Timothy Davis Consulting

TimDavis@TDCon.com - +1 (303) 426-0800 - Fax +1 (303) 426-1023

+------------------------------------------------------------+
: THE CONTENTS OF THIS MESSAGE ARE CONFIDENTIAL AND CONTAIN  :
: PROPRIETARY INFORMATION OF TIMOTHY DAVIS CONSULTING. USE,  :
:       DUPLICATION, AND DISCLOSURE ARE RESTRICTED           :
+------------------------------------------------------------+


Article: 15856
Subject: Re: partial reconfiguration
From: Steve Casselman <sc@vcc.com>
Date: Fri, 16 Apr 1999 18:21:39 -0700
Links: << >>  << T >>  << A >>
Asa Kalavade wrote:

> A question on partial reconfiguration:
>
> I am trying to understand partial reconfiguration on the Virtex devices.
> Any pointers?
>
> Some of my current questions:
> - How is the partial bitstream generated? What tool support exists?

You start with a fully placed and routed bit stream and then modify itusing JBits.

> - How is the area of the device to be reconfigured specified?

JBits

> - How is the new partial configuration loaded at run-time?

Same as always (although I think you have to write a blank columnto flush (push) the buffer) through the select map
(although
you might be able to load a frame through I'm not sure). The designer
must still design a system that can deliver the partial bit stream.

> - What is the partial re-configuration delay (as a function of area)?
> Any other information is appreciated.
>

From a post by Ed McGettiganIn article <3701F050.DCF70028@irisa.fr>,
Steven Derrien  <sderrien@irisa.fr> wrote:
>I was wondering if such an operation requires the download of a whole
>frame to the Virtex  ? It it is the case, this leads to a significant
>reconfiguration overhead ,  (a few hundred microseconds ) Am I right?
>

It's much faster than that. Each Virtex device has a different frame
size with the popular V300 device having a frame size of 672 bits.
Loading just the frame data in the SelectMAP mode (8-bits) @ 50MHz
would only take 1.68uS (672/8*20ns).

Ed

> thanks,
> Asa
> kalavade@lucent.com

  Now that JBits is comming out, it is time to start
talking about that CopyLefted Tools project everyone
talkes about:-) finally!


--
Steve Casselman, President
Virtual Computer Corporation
http://www.vcc.com


Article: 15857
Subject: Re: Some FPGA questions
From: "Austin Franklin" <austin@darkr9oom.com>
Date: 17 Apr 1999 01:22:54 GMT
Links: << >>  << T >>  << A >>
> Be sure that you are not doing a process or two using both clock edges
(positive
> and negative). For example two processes, one using the positive clk edge
and
> another using the negative clk edge and operating on the same signal.
That won't
> work.

Why not?  May be I don't understand what you are saying here....  It sounds
to me like you are saying a signal can't be an input to a flop that is
clocked on the rising edge, AND be an input to a flop clocked on the
falling edge....

Austin

Article: 15858
Subject: XC4000 LUT on the fly programming
From: Khaled benkrid <k.benkrid@qub.ac.uk>
Date: Sat, 17 Apr 1999 02:25:58 +0100
Links: << >>  << T >>  << A >>
Hi All,

I heard that it is possible to modify 'on the fly' the content of LUTs
in XC4000 series. How is that done?.

Thanks.

Article: 15859
Subject: VHDL Tutorial/Class
From: "Kalyan Gokhale" <kgokhale@execpc.com>
Date: Fri, 16 Apr 1999 21:39:42 -0500
Links: << >>  << T >>  << A >>
Is any FPGA vendoe planning on a one day (or 1/2 day) tutorial/class in the
Milwaukee area?

Best Regards,
                        Kalyan
   kgokhale@execpc.com





Article: 15860
Subject: Re: High speed reconfigurability
From: "Tom Meagher" <tomm@icshou.com>
Date: Fri, 16 Apr 1999 22:38:17 -0500
Links: << >>  << T >>  << A >>
It sounds as though the FPGA architecture you have in are describing the
same as a new developmental device from NEC.  Here is a link to the EE Times
article:  http://www.eetimes.com/story/OEG19990215S0004

[excerpt from article] ...
By storing multiple contexts-each of which carries a particular device
configuration-on-chip, NEC is able to slash the reconfiguration latency from
the minutes it takes to reprogram a large SRAM FPGA to only 4.6 nanoseconds.
On the prototype device, the area required to store the eight contexts saved
is 35 percent greater than the area of an equivalent FPGA, but NEC claims
the benefit is eight times more usable gates. And in the future, using DRAM
instead of SRAM cells to save context, the company can potentially pack 256
contexts together instead of eight, Motomura said.
[end of excerpt] ...

Trying to tame this beast would be a lot of fun, and for the right
application, ... wow.

Tom Meagher


Mark wrote in message <37166B04.5DB4@xs4all.nl>...
[snip]
>What i think would be really interesting, is being able to re-configure
>an entire FPGA really quickly (say 1 system clock period ideally).  This
>translates into the idea of having 'layers' of FPGA config data which
>can be latched into the FPGA config area.  The inactive 'layers' being
>updated or replaced while not in use -> pretty much like a video display
>where an image is built up in the off screen buffer before the active
>video buffer is toggled.



Article: 15861
Subject: Re: Illegal States in 1 Hot State Machines
From: murray@pa.dec.com (Hal Murray)
Date: 17 Apr 1999 03:44:25 GMT
Links: << >>  << T >>  << A >>

I had an "interesting" adventure in that
area a couple of years ago.  Maybe if I
write it down here a few other people can
avoid reinventing this wheel.

I had a simple 1 hot state machine.  It
was just a timing chain.  No conditions.
Just run through the states A, B, C, D,
A, B, ...

How can it possibly screw up?  (There were
no timing problems.)

Well, Murphy found the way.  This was on
a Xilinx 3090.  The global reset is
asynchronous.

My normal trick for initializing 1 hot
systems when the only tool is a Reset
is to flip one of the state bits so
the all 0s state is legal.  In this case,
1 in 1000 (or 10K?) times coming out
of reset, the state machine would end
up with 2 bits active - the setup on the
asynchronous reset was meeting the time
needed for the second state bit to turn on
but not meeting the time for the first bit
to turn on too.

Asynchronous signals are dangerous.
-- 
These are my opinions, not necessarily my employers.
Article: 15862
Subject: Re: High speed reconfigurability
From: Ray Andraka <randraka@ids.net>
Date: Sat, 17 Apr 1999 00:07:50 -0400
Links: << >>  << T >>  << A >>
There are a few devices out there that support partial reconfiguration to
varying degrees.  Currently sold devices include Atmel 6K and 40K, Xilinx
6200 and Virtex.  Of these, the 6200 has  the nicest interface for
configuring.  It is however handicapped by an architecture that is at
best awkward for arithmetic type operations.  The Atmel 40K is probably
the best choice for real-world partially reconfigured systems.  Virtex
suffers in partial reconfiguration somewhat because a a whole column has
to be done at a time.  That has the potential to disrupt signals routed
across the column while the configuration is occuring, which means you
need either stop the clock or configure synchronously with the clock to
avoid problems in the rest of the circuit.  Additionally, the xilinx
tools do not currently adequately address routing to be able to
successfully handle partial reconfiguration without a ton of careful hand
routing (not that anyone elses tools are any better).

The single clock context switching you talk about has been discussed in
academia for several years now.  There are some major implementation
issues that need to be addressed. First, power consumption of the chip is
related closely to the number of nodes switching at at time.  In the case
of a single clock cycle context switch, essentially every node on the
device switches at the same time, introducing a severe ground bounce
problem on the chip.  Second is the issue of silicon usage.  The extra
area required to hold and mux the configurations significantly increases
the the complexity of the chip, lowering the density of the programmable
portion of the logic by a large factor.  The factor is large enough that
for the majority of applications a larger single context device
(occupying the same silicon area) is capable of doing the same job as the
multicontext one while using less power and using conventional design
techniques and tools.  If you add partial configurability to the mix so
that half of a single context array  can be reprogramed while the rest is
operating, you get nearly the same capability as a multicontext device
with a device that appeals to a much larger segment of the market.

Michael Barr wrote:

> Mark,
>
> I don't know of any such devices.  I have used the Xilinx 6200 series
> parts and played around with my thoughts for an appropriate swapping
> architecture for hardware.  The best ideas seemed to come from the
> theory of memory paging.  I presented a paper on this at DesignCon98
> that you may be interested in reading.  Follow the link below and go
> to the "Reconfigurable Computing" section.
>
>         http://www.netrino.com/Publications/
>
> Cheers,
>         Michael



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 15863
Subject: Re: XC4000 LUT on the fly programming
From: Ray Andraka <randraka@ids.net>
Date: Sat, 17 Apr 1999 00:35:15 -0400
Links: << >>  << T >>  << A >>
Use the LUT as RAM.  In schematics, you use the RAM primatives.  In HDL,
it depends on the HDL compiler...Read the manual for yours.

Khaled benkrid wrote:

> Hi All,
>
> I heard that it is possible to modify 'on the fly' the content of LUTs
> in XC4000 series. How is that done?.
>
> Thanks.



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 15864
Subject: Re: High speed reconfigurability
From: Ray Andraka <randraka@ids.net>
Date: Sat, 17 Apr 1999 00:36:59 -0400
Links: << >>  << T >>  << A >>
I knew NEC was working on a device.  I was not aware that it was multicontext.
Interesting.

Tom Meagher wrote:

> It sounds as though the FPGA architecture you have in are describing the
> same as a new developmental device from NEC.  Here is a link to the EE Times
> article:  http://www.eetimes.com/story/OEG19990215S0004
>
> [excerpt from article] ...
> By storing multiple contexts-each of which carries a particular device
> configuration-on-chip, NEC is able to slash the reconfiguration latency from
> the minutes it takes to reprogram a large SRAM FPGA to only 4.6 nanoseconds.
> On the prototype device, the area required to store the eight contexts saved
> is 35 percent greater than the area of an equivalent FPGA, but NEC claims
> the benefit is eight times more usable gates. And in the future, using DRAM
> instead of SRAM cells to save context, the company can potentially pack 256
> contexts together instead of eight, Motomura said.
> [end of excerpt] ...
>
> Trying to tame this beast would be a lot of fun, and for the right
> application, ... wow.
>
> Tom Meagher
>
> Mark wrote in message <37166B04.5DB4@xs4all.nl>...
> [snip]
> >What i think would be really interesting, is being able to re-configure
> >an entire FPGA really quickly (say 1 system clock period ideally).  This
> >translates into the idea of having 'layers' of FPGA config data which
> >can be latched into the FPGA config area.  The inactive 'layers' being
> >updated or replaced while not in use -> pretty much like a video display
> >where an image is built up in the off screen buffer before the active
> >video buffer is toggled.



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 15865
Subject: Re: Zero power gals won't wake up on slow input transitions?
From: z80@ds2.com (Peter)
Date: Sat, 17 Apr 1999 06:48:14 GMT
Links: << >>  << T >>  << A >>
I don't know about your problem but you are not using a proper 'zero
power' GAL. Yours is a standard-power part with power-down and a input
transition detector. Try a real ZP device from one of the other firms;
I can't recall names but I use the Philips P5Z22V10.

>I'm using a 16v8Z gal from AMD/ VANTIS. Its a zero-power device - sleeping
>when no input activity is sensed(50ns timeout) and waking up when any input
>transition is detected.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but remove the X and the Y.
Please do NOT copy usenet posts to email - it is NOT necessary.
Article: 15866
Subject: Re: Altera 10K and High Density FLASH Memory
From: "Anthony Ellis - LogicWorks" <aelogic@iafrica.com>
Date: Sat, 17 Apr 1999 10:56:06 +0200
Links: << >>  << T >>  << A >>
Let an offline PC do the smart work - the programming algorithms. Implement
a simple serial to parallel command interface through your FPGA ie. a
primative JTAG type interface in your FPGA . Just let the FPGA convert the
serial data to Flash parallel format and toggle the lines. If the FLASH is
readable via the FPGA then you have all the address and data lines wired
anyhow.

Paul Venginickal wrote in message <01be882b$c3a1e190$132afa84@pvengin>...
>I am trying to develop a system that uses an Altera 10K and ~ 32M x 16 of
>Flash memory.  All the flash products I have found either are too small
>(density) or require an enormous amount of control and configuration, which
>is fine for a microprocessor or a microcontroller.  But when you try and
>incorporate all that into an FPGA, you loose most of your gates to the
>initial setup.
>
>Are there any Flash product that have a TAP (JTAG) port on the chip?  This
>way I could program it externally and just read using the Altera.
>
>Has anybody seen a canned JTAG interface for the 10K series?  ie, can you
>embed a TAP programmer and use that to program the Flash from the Altera.
>I know you can program the 10K itself with its built in JTAG port, but can
>you use that interface through the 10K to program something else.
>
>Should I be looking at some other method of non volatile memory to
>interface to the 10K?
>
>Thanks.
>Paul
>


Article: 15867
Subject: Re: Altera 10K and High Density FLASH Memory
From: "Kuznetsov Dmitry" <dkuzn@orc.ru>
Date: 17 Apr 1999 12:51:44 GMT
Links: << >>  << T >>  << A >>
Hi, Paul!
-- 
Paul Venginickal <pvegnin@REMOVEccf.nrl.navy.mil> ...
>  I am trying to develop a system that uses an Altera 10K and ~ 32M x 16
> of Flash memory. All the flash products I have found either are too small
> (density) or require an enormous amount of control and configuration,
> which is fine for a microprocessor or a microcontroller. But when you try
> and incorporate all that into an FPGA, you loose most of your gates to
> the initial setup.

 For the first time I am pushed with the similar problem, when me it took
use in one of my projects AM29F100 in case TSOP-48. This project also
contained EPF10K10TC144. Possible, my experience will you useful. I needed
was write in the Flash small booter by the size in several kilobytes.

>  Are there any Flash product that have a TAP (JTAG) port on the chip?
> This way I could program it externally and just read using the Altera.
> 
>  Has anybody seen a canned JTAG interface for the 10K series? ie, can you
> embed a TAP programmer and use that to program the Flash from the Altera. 
> I know you can program the 10K itself with its built in JTAG port, but
> can you use that interface through the 10K to program something else.
> 
>  Should I be looking at some other method of non volatile memory to
> interface to the 10K?

 On my homepage brought 2 examples to organizations of programming
a flash memory on the board just.
   http://www.orc.ru/~dkuzn/j_jam.htm
 Example 1: Flash AM29F100B (AMD)  + FPGA EPF10K10TC144 (Altera).
 Example 2: Flash AT29**** (Atmel) + FPGA EPF8281ALC84  (Altera).

 The first example you nearly approach. However, I advice you will look
as well as second example. Since it is made later and more aptly.
 Apropos, in the second example I happen to to avoid a restriction for
a maximum time between pulses of record (150 us). This restriction is
specified by the ATMEL specification. For its deciding was aplying by
RC-chain as shown in the drawing.
 When using a strategy from the second example for flash without
this timing restriction sufficiently simply to exclude manipulates
by corresponding output (SYN).

 Important remarks to the second example.
    File JTAG_DEF.TXT:
 Definition of real sequence of devices in JTAG chain and their
characteristics (in the given example - 2 equal devices).
    File AT29_DEF.TXT:
 Assign of FPGA concrete pins in the project.
    File AT29_TBL.TXT:
 The table of Manufacturer ID and Device Type ID.
    File AT29_SUB.TXT:
 When set a flag (DRSCAN_DUMP = 1) program gives on the display
a listings of all their own operations for flash.
 Variable, which name begin from the prefix "BL_", characterize specific
arrays for organizations of block operations of writing or reading.
    Files AT29_[E/L/S/T/V].TXT:
 Concrete script for: Erase; Loading in the flash; Saving in the file;
Testing a Manufacturer ID and Device Type ID; Verification (comparisons).
 For transformation of source file in HEX format in necessary format for
connecting to JAM serves HEX2JAM0.EXE program.

 Programs of functioning in examples is written on special language for
working with JTAG port - JAM. This language is presented by the ALTERA.

 Also on my homepage you may find a description Boundary-Scan Register
(BSR) aplying chips of FPGA. Since branded information I have no (and
its no on their site), BSR for EPF10K10TC144 revealled by practical
consideration. For this was used program BLINKOUT on JAM language.
It also bes included in the first example.
   http://www.orc.ru/~dkuzn/j_bso.htm

 Ask I will beforehand forgive, but information on my homepage in the first
place intended for russian users. Beside me presently at all no time to do
a translation.
 Hopes that you find a specialist with knowing russian.
HTML pages in the coding Windows-1251, but text of inwardly archives
in DOS coding (CodePage-866).

PS. The Rest details possible to discuss in the further correspondence.

Bue!
<< Прости, Вилли. Я слегка паникую! (с) Альф
 Kuznetsov Dmitry, Moscow, http://www.orc.ru/~dkuzn/index.htm
                     Alias   http://attend.to/dkuzn

Article: 15868
Subject: Re: Some FPGA questions
From: ems@riverside-machines.com.NOSPAM
Date: Sat, 17 Apr 1999 15:58:11 GMT
Links: << >>  << T >>  << A >>
On 17 Apr 1999 01:22:54 GMT, "Austin Franklin" <austin@darkr9oom.com>
wrote:

>> Be sure that you are not doing a process or two using both clock edges
>(positive
>> and negative). For example two processes, one using the positive clk edge
>and
>> another using the negative clk edge and operating on the same signal.
>That won't
>> work.
>
>Why not?  May be I don't understand what you are saying here....  It sounds
>to me like you are saying a signal can't be an input to a flop that is
>clocked on the rising edge, AND be an input to a flop clocked on the
>falling edge....

by 'operating on' he means 'updating', ie. you can't update a signal
on both clock edges.

the line of code iteself is ok, so i'd suggest that eldho posts some
more code if he's still got a problem.
Article: 15869
Subject: Re: High speed reconfigurability
From: Tim Tyler <tt@cryogen.com>
Date: Sat, 17 Apr 1999 16:16:06 GMT
Links: << >>  << T >>  << A >>
Mark <mkinsley@xs4all.nl> wrote:
: I like to possibilities offered by reconfigurable FPGAs [...]

: What i think would be really interesting, is being able to re-configure
: an entire FPGA really quickly (say 1 system clock period ideally) [...]

One clock period for a whole FPGA's worth of LUT data?  You are going to
need one fat pipe ;-)

: ....any comments ?

What applications are there which require such rapid reconfiguration -
and can't be reasonably cheaply implemented by using a number of parts?
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  tt@cryogen.com

6.50129 - the natural logarithm of the Beast.
Article: 15870
Subject: Re: XC4000 LUT on the fly programming
From: Khaled benkrid <k.benkrid@qub.ac.uk>
Date: Sat, 17 Apr 1999 17:55:49 +0100
Links: << >>  << T >>  << A >>
And how is the content of the RAM modified on the fly for the 4k series
(JTAG?).

Ray Andraka wrote:

> Use the LUT as RAM.  In schematics, you use the RAM primatives.  In HDL,
> it depends on the HDL compiler...Read the manual for yours.
>
> Khaled benkrid wrote:
>
> > Hi All,
> >
> > I heard that it is possible to modify 'on the fly' the content of LUTs
> > in XC4000 series. How is that done?.
> >
> > Thanks.
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email randraka@ids.net
> http://users.ids.net/~randraka



Article: 15871
Subject: Re: Some FPGA questions
From: ekuria01@kepler.poly.edu
Date: Sat, 17 Apr 1999 18:07:10 GMT
Links: << >>  << T >>  << A >>
Hello all,  Thank you for all the input. The problem was solved by moving the
falling edge events into another process. Basically, I was shifting data into
a shift register (input_shift_reg) on the rising edge and shifting data out
of ANOTHER shift register (output_shift_reg). So, I put the input_shift_reg
stuff in a process that looks for rising edges, and the output_shift_reg
stuff in a process that waits on the falling edges.

Thank you all again for the help.

Eldho Kuriakose

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 15872
Subject: Visit The Programmable Logic Jump Station (www.optimagic.com)
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Sat, 17 Apr 1999 11:10:01 -0700
Links: << >>  << T >>  << A >>
See the latest in programmable logic technology on
the Programmable Logic Jump Station at:


                   http://www.optimagic.com/


The Programmable Logic Jump Station is a comprehensive set of
links to nearly all matters related to programmable logic.



Featuring:
---------


          --- Frequently-Asked Questions (FAQ) ---


Programmable Logic FAQ - http://www.optimagic.com/faq.html
A great resource for designers new to programmable logic.



          --- FPGAs, CPLDs, FPICs, etc. ---


Recent Developments - http://www.optimagic.com
Find out the latest news about programmable logic.


Device Vendors - http://www.optimagic.com/companies.html
FPGA, CPLD, SPLD, and FPIC manufacturers.


Device Summary - http://www.optimagic.com/summary.html
Who makes what and where to find out more.


Market Statistics - http://www.optimagic.com/market.html
Total high-density programmable logic sales and market share.



            --- Development Software ---


Free and Low-Cost Software - http://www.optimagic.com/lowcost.shtml
Free, downloadable demos and evaluation versions from all the major
suppliers.


Design Software - http://www.optimagic.com/software.html
Find the right tool for building your programmable logic design.


Synthesis Tutorials - http://www.optimagic.com/tutorials.html
How to use VHDL or Verilog.



              --- Related Topics ---


FPGA Boards - http://www.optimagic.com/boards.html
See the latest FPGA boards and reconfigurable computers.


Design Consultants - http://www.optimagic.com/consultants.html
Find a programmable logic expert in your area of the world.


Research Groups - http://www.optimagic.com/research.html
The latest developments from universities, industry, and
government R&D facilities covering FPGA and CPLD devices,
applications, and reconfigurable computing.


News Groups - http://www.optimagic.com/newsgroups.html
Information on useful newsgroups.


Related Conferences - http://www.optimagic.com/conferences.html
Conferences and seminars on programmable logic.


Information Search - http://www.optimagic.com/search.html
Pre-built queries for popular search engines plus other
information resources.


The Programmable Logic Bookstore - http://www.optimagic.com/books.html
Books on programmable logic, VHDL, and Verilog.  Most can be
ordered on-line, in association with Amazon.com



            . . . and much, much more.


Bookmark it today!





Article: 15873
Subject: Re: XC4000 LUT on the fly programming
From: nweaver@hiss.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 17 Apr 1999 18:37:48 GMT
Links: << >>  << T >>  << A >>
In article <3718BD15.4E473B3@qub.ac.uk>,
Khaled benkrid  <k.benkrid@qub.ac.uk> wrote:
>And how is the content of the RAM modified on the fly for the 4k series
>(JTAG?).

	THe later ones of the 4000 series allow both LUTS in a single
CLB to act as a single, dual ported, 16x1 RAM, so you have the
"compute lut" be one port, and reconfigure through the second.

-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
Article: 15874
Subject: Re: XC4000 LUT on the fly programming
From: Ray Andraka <randraka@ids.net>
Date: Sat, 17 Apr 1999 15:25:14 -0400
Links: << >>  << T >>  << A >>
You need to include the write path and write logic in your design.  The 4000
series does not permit partial reconfiguration, which it sounds like you are
talking about.  You can do a work-around by configuring the LUTs as RAMs and
including logic for writing the RAMs from the JTAG port (you need to include a
JTAG controller in your design).  The RAM addresses need to be muxed so that
the loader can access each of the 16 locations during a reload, and so the 4
inputs control the ram address during normal operation.  That is the closest
you will get to reprogamming 'on-the-fly' in a xilinx 4K part.  The other
option using 4K is to include a path in your design to offload the current
state of critical registers into off-chip storage, reprogram the device with
the new circuit, and then reload the stored register values.  That takes a bit
of time, and is likely not to be suitable for your application.  If it is
suitable, a new tool being introduced by xilinx called J-bits allows you to
manipulate the bitstream so that you can directly change LUT contents without
having to reiterate the place and route process.  Still, you need to reload
the whole device.

There are devices out there that can handle partial configuration: Atmel 40K,
Atmel 6K, Xilinx 6200 and Xilinx Virtex are the only ones that come to mind
that are currently commercially available.  Xilinx 6200 has an open bitstream
format, which allows the user the access to manipulate the bitstream
directly.  The 6200 however has an awkward architecture for most real-world
applications.


Khaled benkrid wrote:

> And how is the content of the RAM modified on the fly for the 4k series
> (JTAG?).
>
> Ray Andraka wrote:
>
> > Use the LUT as RAM.  In schematics, you use the RAM primatives.  In HDL,
> > it depends on the HDL compiler...Read the manual for yours.
> >
> > Khaled benkrid wrote:
> >
> > > Hi All,
> > >
> > > I heard that it is possible to modify 'on the fly' the content of LUTs
> > > in XC4000 series. How is that done?.
> > >
> > > Thanks.
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email randraka@ids.net
> > http://users.ids.net/~randraka



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka




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