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 56150

Article: 56150
Subject: Re: Xilinx Spartan download with Parallel III cable
From: antti@case2000.com (Antti Lukats)
Date: 29 May 2003 08:24:32 -0700
Links: << >>  << T >>  << A >>
"Peter Seng" <p.seng@seng.de> wrote in message news:<bb1o7f$66s$1@online.de>...
> > 1) Tried maxjp (latest) does program the 18V02 but the programmed image
> 
> give me some hint, what is maxjp - never heard, hardware, software, where
> from ????

my mistake its naxjp from on japan fellow, programs Xc95 and XC18
just google on naxjp first hit is right

unfortunatly the 18V02 programming did not work for me, dont know why.

Article: 56151
Subject: Re: Nois generator - project
From: hmurray@suespammers.org (Hal Murray)
Date: Thu, 29 May 2003 15:25:12 -0000
Links: << >>  << T >>  << A >>
>I suggest using the outputs of several different-length LFSRs to
>generate a parallel word. Needless to say, the run length should all be
>relatively prime, which is actually hard to avoid.
>LFSRs are dirt-cheap especially using SRL16s in Virtex, and very fast.

That seems like a great idea, but I'm not sure things are
as simple as we would like them to be.

I think this was mentioned a year or two ago.  Somebody pointed
out that the polynomials are not prime and may have factors in
common.  That's about the limits of my math skills.  Or maybe
I'm just confused.

Another approach is to use N copies of the same polynomial but initialize
the register with different starting values.  I don't know how to select
"good" values or verify that proposed values are good ones.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 56152
Subject: Re: smallest embedded cpu....and the most pain?
From: hmurray@suespammers.org (Hal Murray)
Date: Thu, 29 May 2003 15:34:10 -0000
Links: << >>  << T >>  << A >>
>If it doesn't have an assember....

>Then it is a pain.  If it has an assembler OR it has a c compiler, then
>it is really much more fun.

>Picoblaze has assembler support, and MicroBlaze has c support.

Good points.

I'm thinking of the simple ROM based architecture where
the PC gets loaded from a next-instruction field in each
instruction.  An assembler for that sort of system is really
pretty simple.  (The parser is the hard part.)  All you need
to do is recognize tokens and pack their values together into
an instruction.  Not quite that simple.  There is also some
work to assign instructions to locations and/or to pair up
locations for the brancing logic.

It is pretty simple if you have an example to start with.
You just need to hack it to work with the appropriate tokens
for your system.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 56153
Subject: Re: Antifuse and SRAM FPGA
From: John Eaton <johne@hpvcljte.vcd.hp.com>
Date: 29 May 2003 15:45:55 GMT
Links: << >>  << T >>  << A >>
Wong <tatto0_2000@yahoo.com> wrote:
: Hi FPGA experts,
:   What are the differences between those Antifuse
: FPGAs(One-time-programmable, OTP) and SRAM-based FPGAs(I called it
: Many-time-programmable, MTP) ?    ;)
It's size verses flexibilty. Pick one.

All fpga's consist of switches that can configure logic arrays. In a
OTP those switches are set once at programming and never change. A
SRAM fpga needs a sram bit behind every switch and some method to
load those bits at powerup. OTP's are better IF you never have to
change the pattern. Even a single pattern change can make the SRAM
fpga a better choice.

Some OTP vendors offer a custom part where they take your fuse file
and create a mask with metal replacing the "on" switches. They are
faster and possibly cheaper than programming for high enough volumes.

John Eaton


Article: 56154
Subject: Re: FIFO Controller
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 29 May 2003 08:46:18 -0700
Links: << >>  << T >>  << A >>


Jim Granville wrote:
> 
> Peter Alfke wrote:
> >
> > I am looking at revamping the FIFO cores, giving you many options:
> > asynchr. vs synchronous, with exact empty and full
> > extra one-clock-early empty and full indicators
> 
> Interesting - this would allow a smaller fifo for
> continual streaming output ?
Jim, I do not understand. It's just a warning, one clock tick ahead...
> 
> > programmable almost empty and full indicators,
> > readable occupied size ,
> > etc
> > Any additional suggestions?
> 
>  Newer UART fifos have a WDOG type feature, where a montostable timer
> (runs at some multiple character time), generates an interrupt
> if ever bytes are 'left in the FIFO', but under the interrupt threshold.
>  Allows a fully interrupt design, and avoids separate polling to
> check for remnant data, which might be a noise side-effect.

Since this is programmable logic, I suggest each user implements this in
the logic fabric.
Agreed?
Peter
> 
>  -jg

Article: 56155
Subject: Re: FIFO Controller
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 29 May 2003 08:49:30 -0700
Links: << >>  << T >>  << A >>


Pete Fraser wrote:
> 
> Like the old NEC uPD42101.
> 
> In clock, in enable, in reset (synchronous).
> Out clock, out enable, out reset (synchronous).

I find this too primitive, no Full or Empty, no "dipstick", etc

> Contents can be read multiple times
This is complicated and can have strange ramifications. Is this really desirable?
Peter Alfke

Article: 56156
Subject: Re: Any recommendation for an FPGA kit ?
From: kempaj@yahoo.com (Jesse Kempa)
Date: 29 May 2003 09:09:19 -0700
Links: << >>  << T >>  << A >>
Hi all,

As someone mentioned the Altera DSP development kits have on-board
ADCs and DACs. However, if you're interested in some other FPGA dev
board that doesn't have these features, I'd suggest checking out El
Camino's daughter card before building your own:
http://www.elca.de/Products/prod%20andilabe.html

This little card will fit on any dev board with "Santa Cruz" headers
which are found on all the Altera Nios dev boards, Altera DSP Dev
board, and a many other third-party dev boards featuring Altera FPGAs.

Jesse Kempa
Altera Corp.
jkempa at altera dot com


> Not yet.
> I have a NIOS Stratix kit and will have a look at that subject soon.
> There is a range of ADC/DAC available from different manufacturers.
> They operate similarly. I'll possibly opt for an affordable 50Msample
> pair. They shouldn't be too hard to add on a little board.
> 
> 
> Rene

Article: 56157
Subject: Re: Moore Vs Mealy machine ..
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Thu, 29 May 2003 10:33:07 -0700
Links: << >>  << T >>  << A >>
rickman wrote:

> You can put registers anywhere you want in a design.  But neither Moore
> nor Mealy machines have registers on the output values unless the
> outputs happen to be the same as your state variables.

I apologize for extending this recurring thread
with distinctions that I don't really believe are useful.

I see fitting gates for my HDL state-machine-like synchronous
process as a job for my synthesis software.

Synthesis is not concerned about
the mealyness nor mooreness of my outputs or case statement.
It does not really care if a flop is a state or output register.
It just makes a netlist the sims like the code.

If I stick to the standard synchronous process template,
I have no combinational outputs to consider.

However, the text-book machine models also work fine,
so if you want to do one by the book, I will withhold
judgment in the future.

   -- Mike Treseler


Article: 56158
Subject: Re: FIFO Controller
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 29 May 2003 10:53:49 -0700
Links: << >>  << T >>  << A >>


Marc Randolph wrote:
>
> Howdy Peter,
> 
> This might be more effort than you had in mind, but we've had a need
> several times for an asymetric async FIFO... 8 bits in @ 155 MHz, 32
> bits out @ 50 MHz.  And the reverse of course.  While I'm dreaming, we
> could use them in both BRAM and LUT RAM form.

Expect it this fall, but probably only in BRAM form.
The problem is that 1, 2 or 3 eight-bit words might get left stuck in
the FIFO when it declares itself empty, because there is no more 32-bit
word to be read.    :-)

I'll think about the other suggestions, but they may be unlikely.

Peter Alfke
> 
>

Article: 56159
Subject: Re: Moore Vs Mealy machine ..
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 29 May 2003 14:05:08 -0400
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> 
> rickman wrote:
> 
> > You can put registers anywhere you want in a design.  But neither Moore
> > nor Mealy machines have registers on the output values unless the
> > outputs happen to be the same as your state variables.
> 
> I apologize for extending this recurring thread
> with distinctions that I don't really believe are useful.
> 
> I see fitting gates for my HDL state-machine-like synchronous
> process as a job for my synthesis software.
> 
> Synthesis is not concerned about
> the mealyness nor mooreness of my outputs or case statement.
> It does not really care if a flop is a state or output register.
> It just makes a netlist the sims like the code.
> 
> If I stick to the standard synchronous process template,
> I have no combinational outputs to consider.
> 
> However, the text-book machine models also work fine,
> so if you want to do one by the book, I will withhold
> judgment in the future.

The point of making a distinction between Moore, Mealy and other FSMs is
that, although your synthesis software may not care what is being
synthesized, your design and analysis of the FSM operation is different
for the various types.  

You can design any FSM that you can dream up.  But if you want to use
the tools that understand how FSMs work and assist you in your design,
it helps if the common language is understood.  

Of course, I have not often used software to help me with FSM design. 
So the "definition" of Moore and Mealy may have changed.  But FSMs with
registered outputs are not at all the same as non-registered outputs
unless your design happens to not care about the extra clock cycle
delay.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 56160
Subject: MapLib Error (463 ) in Modular Design Flow
From: eduwenzel@yahoo.com.br (=?ISO-8859-1?Q?Eduardo_Wenzel_Bri=E3o?=)
Date: 29 May 2003 11:13:20 -0700
Links: << >>  << T >>  << A >>
Hi

I am developing a medium size reconfigurable project described in
VHDL. Modular Design flow is being applied in my project. I inserted
bus macros and I coded according to XAPP290 document. My project is
divided in two modules: reconfigurable module (client module) and
fixed module (memory controller module). The second phase of Modular
Design (Active Module Implementation Phase) has been performed with
errors. When map tool is performed for mapping reconfigurable module
(client module), that program issues the following error:

ERROR:MapLib:463 - Module reconfig_module contains multiple output
ports
   connected to signal datain_from_module(10)
   This is not allowed in modular design. Consolidate the ports into
one port
   during the Initial Budgeting Phase. Or, if you are working with an
incomplete
   modular design, use one of the following methods to ensure a unique
signal
   drives each output port:
     - Add buffers
     - Replicate logic
   See the answer database (http://support.xilinx.com) for more
information.



datain_from_module is a bus declared inside of top module. This signal
is connected in the "dataout" port declared inside of reconfig module.
The mapping error happens in this piece of code:

-------------------------------------------------
-- Register dataout contains the value to write
-- in memory at the moment of the write request
-------------------------------------------------
dt_out: process (reset, clock)
begin 
   if reset='1' then
      dataout <= (others=>'0');
   elsif clock'event and clock='1' then
      if ld_dataout='1' then 
         if addr_count(0)='0' then
            dataout <= x"48FFFF84";		  
         else 
            dataout <= x"B700007B";
         end if;  
      end if;
   end if;
end process;


I tried to modify this piece of code and the map error disappeared.
However, this modification changed the behavior of client module,
turning the communication between client module and memory controller
module inconsistent. I read the Development System Reference Guide in
the Modular Design Chapter, and I didn´t find the point of my client
module that it needs for adding buffers and replicating logic. Can
someone find this point in the code? What can be happen in my project?
What kind of procedure someone can recommend? I appreciate any kind of
help.

Eduardo Wenzel Brião
Pontifícia Universidade Católica do Rio Grande do Sul - PUCRS
Porto Alegre city
Brazil

Article: 56161
(removed)


Article: 56162
Subject: Re: Antifuse and SRAM FPGA
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 29 May 2003 12:05:15 -0700
Links: << >>  << T >>  << A >>
Here are the undisputed pros and cons:

Antifuse advantages:
Instant-on, needs no configuration PROM or other store, security is
easier, and radiation tolerance is better for space applications.

Antifuse disadvantages:
one-time only programming (you have to throw the device away if you want
to make any change)
slow programming,( takes many minutes for larger devices)
more restricted upper device-size limit ( no multi-mega-gate circuits)
fewer sophisticated features (clock manipulation, RAMs, multipliers, etc)

And a business aspect:
Antifuse FPGAs represent a more specialized market, served by two
relatively small suppliers.  SRAM-based FPGAs are offered by the two big
FPGA manufacturers plus some others, resulting in  tougher competition
and faster innovation.

Yes, I am biased, but trying to be fair. Please no flames !
Peter Alfke, speaking for himself.

 



Wong wrote:
> 
> Hi FPGA experts,
>   What are the differences between those Antifuse
> FPGAs(One-time-programmable, OTP) and SRAM-based FPGAs(I called it
> Many-time-programmable, MTP) ?    ;)
>   If one is using antifuse and would like to 'migrate' to SRAM-based,
> what are the *important* considerations before the migration ?
>   As far as I know, one of the consideration would be the amount of
> Sequential and Combinational cells are greatly 'sacrified' for RAMs in
> SRAM-based FPGAs(compare both with the same amount of system gates).
> Besides, SRAM-based FPGAs need external ROM during power-up to
> download the bitstream. But look at Antifuse FPGAs, it is
> S&C-cell-rich compare to SRAM-based and no extra device for
> downloading the bitstream.
>   Any other considerations ? Please feel free to correct me if I am
> wrong.
>   Thank you guys.

Article: 56163
Subject: FPGA's an Flash
From: "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com>
Date: Fri, 30 May 2003 07:56:53 +1200
Links: << >>  << T >>  << A >>
I don't know much about Semiconductor processes.  But I wonder why it isn't
possible to make FPGA's with some flash memory in there, enough to hold 2x
the bit streams for the FPGA. A little Flash boot section (like CPLDS') of
FPGA could be used to configure the rest of the FPGA from the Embedded
flash.

This means you can self configure with a protected bitstream, you can use
the flash in your application if you like, etc etc.   It also gives you NV
ram in the FPGA which just can't be a bad thing.

Seems like a simple idea - and a nice setup, is there a big technical
barrier to such a setup? Is it comming?  Should I have pateneted it? Are
there already some out there?

Ralph



Article: 56164
Subject: Re: New version,Low Speed
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 30 May 2003 09:12:24 +1200
Links: << >>  << T >>  << A >>
Vaughn Betz wrote:
> 
> Hi Leon,
> 
> As Paul points out, some random bounce is pretty much unavoidable.  To
> minimize the bounce / get the best result, you can "seed sweep" which
> basically runs the compiler multiple times with slightly different
> starting point.  By picking the best run, you can gain a little bit of
> speed, by picking the luckiest compile.  This also tends to cut the
> random bounce from release to release, of course at the expense of
> compile time.
> 
> To do this, go to Tools->Tcl Scripts->Sweeper.  The script is pretty
> self-explanatory -- tell it what you want, and how many compiles
> you're willing to do.
> 
> You can also do this manually by using the "Initial Placement
> Configuration" (sometimes called "Seed") setting in the
> Assignments->Settings->Fitter Settings dialog.
> 
> As Paul pointed out, another option is to back-annotate the placement
> and/or routing to "lock in" the results of a good compile.  All Altera
> devices support back-annotation of placement.  Only Stratix,
> Stratix-GX and Cyclone support back-annotation of routing.
> 
> When back-annotating placement to lock in performance, the best option
> is typically to back-annotate and demote assignments to LABs (i.e.
> don't lock down to the LE level).  This reduces, but does not
> completely eliminate bounce unless you also lock down the routing too,
> and unfortunately locking down the routing isn't supported for the
> 10K.

 Interesting - these tools are (slowly) becomming more like PCB design
tools.

 Can you manually do a partial/local un-route, to support 
'incremental compiles' ? ( which should be a LOT faster ? )

 If a revison is fed into a route-back-annotated design, 
( ie skip the manual un-route) how do the tools handle the conflicts ?
 
-jg

Article: 56165
Subject: Re: FPGA's an Flash
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Thu, 29 May 2003 14:15:26 -0700
Links: << >>  << T >>  << A >>
Ralph,

The simple answer is that there is a real barrier to doing this.  The
cost.

To stay ahead of competition and offer the most cost effective product,
vendors choose to implement the latest FPGA with the latest process
available:  standard CMOS at .15, .13, .09, .065, etc.....

If you choose a process that has flash technology, you tyically wait two
years (or more) until after the same process geometry is available in
CMOS.  Where are we with FPGAs? Where are we with CPLDs?  Both are at
the absolute leading edge of their respective technologies, however
FPGAs are farther down 'Moore's Curve'.

The simple result?  Yopu can have the new technology chip in CMOS for
1/4 the cost of the old technology chip with flash.

Buying a separate flash is so cheap, that you can not make the economic
argument to have them both on the same chip.

The other problem, is that a little flash ram is not so little: 2.5
Mbytes.

Austin

Ralph Mason wrote:
> 
> I don't know much about Semiconductor processes.  But I wonder why it isn't
> possible to make FPGA's with some flash memory in there, enough to hold 2x
> the bit streams for the FPGA. A little Flash boot section (like CPLDS') of
> FPGA could be used to configure the rest of the FPGA from the Embedded
> flash.
> 
> This means you can self configure with a protected bitstream, you can use
> the flash in your application if you like, etc etc.   It also gives you NV
> ram in the FPGA which just can't be a bad thing.
> 
> Seems like a simple idea - and a nice setup, is there a big technical
> barrier to such a setup? Is it comming?  Should I have pateneted it? Are
> there already some out there?
> 
> Ralph

Article: 56166
Subject: Re: FIFO Controller
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 30 May 2003 09:19:50 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Marc Randolph wrote:
> >
> > Howdy Peter,
> >
> > This might be more effort than you had in mind, but we've had a need
> > several times for an asymetric async FIFO... 8 bits in @ 155 MHz, 32
> > bits out @ 50 MHz.  And the reverse of course.  While I'm dreaming, we
> > could use them in both BRAM and LUT RAM form.
> 
> Expect it this fall, but probably only in BRAM form.
> The problem is that 1, 2 or 3 eight-bit words might get left stuck in
> the FIFO when it declares itself empty, because there is no more 32-bit
> word to be read.    :-)

 unless the system _guaranteed_ x4 byte streams, you would need a
'Valid' flag with each 8 bits anyway, so it would be a 36 bit
( or maybe 34 bit ) read.
-jg

Article: 56167
Subject: Re: FIFO Controller
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 30 May 2003 09:32:10 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Jim Granville wrote:
> >
> > Peter Alfke wrote:
> > >
> > > I am looking at revamping the FIFO cores, giving you many options:
> > > asynchr. vs synchronous, with exact empty and full
> > > extra one-clock-early empty and full indicators
> >
> > Interesting - this would allow a smaller fifo for
> > continual streaming output ?
> Jim, I do not understand. It's just a warning, one clock tick ahead...

 I was thinking about a (possible) application, where sync state engines 
drive the FIFO, and no-pauses is a goal. If you wait for truly empty,
then a pause must result, but a early empty might, with some gymnastics,
allow full depth usage, and pre-empt the pause.
 More a mind-exercise than a real problem :)

> >
> > > programmable almost empty and full indicators,
> > > readable occupied size ,
> > > etc
> > > Any additional suggestions?
> >
> >  Newer UART fifos have a WDOG type feature, where a montostable timer
> > (runs at some multiple character time), generates an interrupt
> > if ever bytes are 'left in the FIFO', but under the interrupt threshold.
> >  Allows a fully interrupt design, and avoids separate polling to
> > check for remnant data, which might be a noise side-effect.
> 
> Since this is programmable logic, I suggest each user implements this in
> the logic fabric.
> Agreed?
> Peter

Yes and no.
 Since you were taking the FIFO to the 'comprehensive' end of the scale,
and I was also thinking of what the FIFO might be driving 
( eg 'soft core' processors ), it seemed a logical thing to include
such 'gotcha' captures into the FIFO.
 A SW designer ( I can feel the shudders ) who is doing an IP-paste job
may not realise such a FIFO-remnant effect is even possible - it's
a relatively 'late' feature in UARTS, so that field was slow to identify
it.

 An experienced HW designer would, of course, anticipate such problems,
and
include FIFO-WDOG blocks from their library :)

- jg

Article: 56168
Subject: Re: FPGA's an Flash
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 29 May 2003 14:40:06 -0700
Links: << >>  << T >>  << A >>
As Austin also explained:
What you suggest can be done, and has be done: in 1989 Xilinx made an
XC3720, which was an XC3020 with on-chip nonvolatile configuration
store, and it had the adantages you mention: self-contained and could
easily be made secure.
The problem was cost and performance. We used to joke: "Twice the price
for half the speed".
The price is higher because the chip is bigger: It has the extra storage
cells, and it is made on a less advanced, (read bigger-geometry),
process that can accomodate this mixture of device technologies. The
chip is also slower for the same reasons.
Most customers considered this a bad deal, and gladly bought the
"normal" devices that somehow store their configuration externally.

Undoubtably there might be a market for what you describe, but it would
be for single-chip applications, where cost is secondary, and
performance does not count. We think that this too small a market for us
to engage in.

Peter Alfke, Xilinx Applications

Ralph Mason wrote:
> 
> I don't know much about Semiconductor processes.  But I wonder why it isn't
> possible to make FPGA's with some flash memory in there, enough to hold 2x
> the bit streams for the FPGA. A little Flash boot section (like CPLDS') of
> FPGA could be used to configure the rest of the FPGA from the Embedded
> flash.
> 
> This means you can self configure with a protected bitstream, you can use
> the flash in your application if you like, etc etc.   It also gives you NV
> ram in the FPGA which just can't be a bad thing.
> 
> Seems like a simple idea - and a nice setup, is there a big technical
> barrier to such a setup? Is it comming?  Should I have pateneted it? Are
> there already some out there?
> 
> Ralph

Article: 56169
Subject: Re: smallest embedded cpu....and the most pain?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 30 May 2003 09:43:20 +1200
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> >If it doesn't have an assember....
> 
> >Then it is a pain.  If it has an assembler OR it has a c compiler, then
> >it is really much more fun.
> 
> >Picoblaze has assembler support, and MicroBlaze has c support.
> 
> Good points.
> 
> I'm thinking of the simple ROM based architecture where
> the PC gets loaded from a next-instruction field in each
> instruction.  An assembler for that sort of system is really
> pretty simple.  (The parser is the hard part.)  All you need
> to do is recognize tokens and pack their values together into
> an instruction.  Not quite that simple.  There is also some
> work to assign instructions to locations and/or to pair up
> locations for the brancing logic.
> 
> It is pretty simple if you have an example to start with.
> You just need to hack it to work with the appropriate tokens
> for your system.

 On this path, there was mention a while ago in c.a.f  of a (very old) 
uC core that used a LFSR as the PC. This solved a speed-bottleneck, 
(plus uses less logic) but needed more work in the assembler.
 Seems this could have real merit in the 'smallest cpu' direction.

-jg

Article: 56170
Subject: Re: FPGA's an Flash
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 30 May 2003 09:56:58 +1200
Links: << >>  << T >>  << A >>
Ralph Mason wrote:
> 
> I don't know much about Semiconductor processes.  But I wonder why it isn't
> possible to make FPGA's with some flash memory in there, enough to hold 2x
> the bit streams for the FPGA. A little Flash boot section (like CPLDS') of
> FPGA could be used to configure the rest of the FPGA from the Embedded
> flash.
> 
> This means you can self configure with a protected bitstream, you can use
> the flash in your application if you like, etc etc.   It also gives you NV
> ram in the FPGA which just can't be a bad thing.
> 
> Seems like a simple idea - and a nice setup, is there a big technical
> barrier to such a setup? Is it comming?  Should I have pateneted it? Are
> there already some out there?

 Austin has given the ecconomic-reason reply, but there is another
pathway to get what you ask for, it just has not hit the FPGA sector
yet.

 In Cellphones esp, there is growing stacked-chip deployment, and this
needs some co-ordination between the die-layout teams, but the results
allow DSP/FLASH/RAM to all be specialised 'best-process-fit' and 
importantly of late-selection sizes.
 There is no process-barrier to prevent this stack also including
a FPGA - just needs the will and foresight to arrange things so the
die can stack/bond.

- jg

Article: 56171
Subject: Re: FIFO Controller
From: mrand@my-deja.com (Marc Randolph)
Date: 29 May 2003 14:57:00 -0700
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> wrote in message news:<3ED6492D.E3CF97AB@xilinx.com>...
> Marc Randolph wrote:
> 
>>Howdy Peter,
>>
>>This might be more effort than you had in mind, but we've had a need
>>several times for an asymetric async FIFO... 8 bits in @ 155 MHz, 32
>>bits out @ 50 MHz.  And the reverse of course.  While I'm dreaming,
we
>>could use them in both BRAM and LUT RAM form.
> 
> 
> Expect it this fall, but probably only in BRAM form.
> The problem is that 1, 2 or 3 eight-bit words might get left stuck in
> the FIFO when it declares itself empty, because there is no more 32-bit
> word to be read.    :-)

Surely it isn't that hard to have a "flush" input pin that jumps the
write pointer by whatever amount is necessary to produce the output
word size?  Or same concept, different method (less work on your
part): a two bit input that provides an amount to add to the normal +1
increment of the write pointer (00 = don't add extra; 11 = +3).

> I'll think about the other suggestions, but they may be unlikely.

Darn!  :-)

Thank you again,

   Marc

Article: 56172
Subject: Re: JTAG madness
From: Fred Viles <fv+abuse@nospam.epitools.com>
Date: Thu, 29 May 2003 21:57:27 GMT
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> wrote in
news:3ED5FB2E.D1EF6320@yahoo.com: 

> Fred Viles wrote:
>> 
>> rickman <spamgoeshere4@yahoo.com> wrote in
>> news:3ED3A6C7.229A5223@yahoo.com:
>> 
>> >...
>> > The second will have an ARM MCU and a large CPLD.
>> >...
>> 
>> There are JTAG probes available for ARM, at least, that have no
>> problem with there being mulitple TAPs on the JTAG chain.
>> (MultiICE from ARM and MAJIC from EPI, just to name two). 
>> Unless your CPLD programmer can't handle it, you shouldn't need
>> to provide for isolating the TAPs in this section.
>>...
> To the best of my knowledge, the number of devices in the chain
> has little to do with the hardware.  I belive it is entirely up
> to the software.

Well sure.  For some definition of "software" which varies 
depending on the probe you choose.  E.g. for MultiICE it's an RDI 
compliant DLL on the PC, and for MAJIC it's firmware in the probe 
itself.  For a cheap parallel port bit-banger like a Wiggler, it's 
host software either in a shared library or directly in the 
debugger.

But I guess I don't understand how that observation is relevant to 
the question of whether your target board needs to isolate the 
various TAPs or not.  I would think the only question is whether 
the probe+software you will use for each device supports the device 
not being the only TAP on the chain.

I don't know about your CPLD, so I was just pointing out that for 
the ARM, at least, the answer can be yes.

>  I am not up to speed on the many suppliers of
> debugging hardware and software for the ARM yet.  I have heard a
> lot of recommendations, but not many provide info on *why* one
> combination is good or bad.

That's a big subject to cover.  There are a *lot* of products on 
offer from a lot of companies, not to mention the freeware/hobbiest 
options.  They all have strengths and weaknesses, and what makes 
one a better solution than another is largely dependent on your 
particular needs.

Do you need download performance?  Multi-TAP support?  Multi-
Processor support?  RTCLK support?  ETM support?  Networkability?  
Support for a particular debugger?  Low cost?  etc.

>...

- Fred

Article: 56173
Subject: Re: Antifuse and SRAM FPGA
From: H. Peter Anvin <hpa@zytor.com>
Date: 29 May 2003 15:04:21 -0700
Links: << >>  << T >>  << A >>
Followup to:  <3ED659EA.F20FBA79@xilinx.com>
By author:    Peter Alfke <peter@xilinx.com>
In newsgroup: comp.arch.fpga
>
> Here are the undisputed pros and cons:
> 
> Antifuse advantages:
> Instant-on, needs no configuration PROM or other store, security is
> easier, and radiation tolerance is better for space applications.
> 
> Antifuse disadvantages:
> one-time only programming (you have to throw the device away if you want
> to make any change)
> slow programming,( takes many minutes for larger devices)
> more restricted upper device-size limit ( no multi-mega-gate circuits)
> fewer sophisticated features (clock manipulation, RAMs, multipliers, etc)
> 

You're forgetting one: yield.  Because an antifuse FPGA is OTP, no
testing done at the factory can guarantee that every device will
program correctly.  I don't know that the fallout percentage is
nowadays -- for all I know it might be negible -- but still...

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Article: 56174
Subject: Re: smallest embedded cpu....and the most pain?
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 29 May 2003 15:04:41 -0700
Links: << >>  << T >>  << A >>

Jim Granville wrote:
> 
>
>  On this path, there was mention a while ago in c.a.f  of a (very old)
> uC core that used a LFSR as the PC. This solved a speed-bottleneck,
> (plus uses less logic) but needed more work in the assembler.
>  Seems this could have real merit in the 'smallest cpu' direction.
> 
Not worth the trouble. Dedicated carry has made binary counters as
efficient and almost as fast as LFSRs.  Was different 10 and 20 ears ago...

Peter Alfke



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