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 129050

Article: 129050
Subject: Re: When are FPGAs the right choice?
From: Mike Silva <snarflemike@yahoo.com>
Date: Wed, 13 Feb 2008 08:50:19 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 13, 11:08=A0am, "Symon" <symon_bre...@hotmail.com> wrote:
>
> Hi Mike,
> Did you try Google?
> fpga vs microcontroller
> Please come back when you have a specific application in mind that a Googl=
e
> search does help with.
> Cheers, Syms.
>
> p.s. It's very close on Googlefight!http://googlefight.com/index.php?lang=
=3Den_GB&word1=3Dfpga&word2=3Dmicrocon...

Well, I wasn't really thinking in terms of fpga vs. micro, although
I'm sure that's one tradeoff.  I was asking more about fpga (with or
without a soft core) vs. every other solution, and when fpgas are the
right choice, and when they might not be the right choice.  Does that
make sense?

And I don't have any application in mind - just interested in
expanding my horizons.

Mike

Article: 129051
Subject: Re: When are FPGAs the right choice?
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 13 Feb 2008 17:49:08 -0000
Links: << >>  << T >>  << A >>
Mike Silva wrote:
> On Feb 13, 11:08 am, "Symon" <symon_bre...@hotmail.com> wrote:
>>
>> Hi Mike,
>> Did you try Google?
>> fpga vs microcontroller
>> Please come back when you have a specific application in mind that a
>> Google
>> search does help with.
>> Cheers, Syms.
>>
>> p.s. It's very close on
>> Googlefight!http://googlefight.com/index.php?lang=en_GB&word1=fpga&word2=microcon...
>
> Well, I wasn't really thinking in terms of fpga vs. micro, although
> I'm sure that's one tradeoff.  I was asking more about fpga (with or
> without a soft core) vs. every other solution, and when fpgas are the
> right choice, and when they might not be the right choice.  Does that
> make sense?
>
> And I don't have any application in mind - just interested in
> expanding my horizons.
>
> Mike

Hi Mike,
OK, in your OP you mentioned micros, that's why I replied as I did. I'm 
unsure what else you want to compare with. DSPs are the other old chestnut. 
Google works for that also! CPLDs? 74 series logic?
Cheers, Syms. 



Article: 129052
Subject: Re: State machine outputs and tri-state
From: "RCIngham" <robert.ingham@gmail.com>
Date: Wed, 13 Feb 2008 11:49:58 -0600
Links: << >>  << T >>  << A >>
>[I posted this to comp.lang.vhdl, but maybe you FPGA experts know the 
>answer.]
>
>Hi
>I'm not a VHDL expert, just learning, so please don't shout.
>
>I'm using Xilinx ISE9.2sp4 and have the following code as part of a
state
>machine:
>CP_IN_OUTPUT_DECODE: process (state_cp_in)
>  begin
>    if state_cp_in = sta_idle then
>    RDY <= 'Z';
>    BUSY <= '0';
>  end if;
>
>  if state_cp_in = sta_1 then
>    RDY <= '0';
>    BUSY <= '0';
>  end if;
>
>  if state_cp_in = sta_2 then
>    RDY <= '1';
>    BUSY <= '1';
>  end if;
>...
>...etc
>
>The state machine goes from sta_idle, then to sta_1, then to sta_2, etc.
>RDY is a pin on the device.
>During operation, I can see RDY go low in sta_1, but not high in sta_2.
I
>know it gets to sta_2 as I can observe BUSY. I don't think RDY is
tri-stated
>in sta_2 as there is an external pull-up; it just stays low. Gray
encoding
>is used.
>
>If I change the RDY to rdyi (signal) and then have:
>RDY <= 'Z' when state_cp_in = sta_idle else rdyi;
>outside of the decode process then it all behaves itself.
>
>Apart from lack of experience, what mistake(s) have I made?
>Thanks.
>

Check that RDY is not being assigned from another process or concurrent
assignment.

Check that RDY is not being assigned later in the CP_IN_OUTPUT_DECODE
process. That will take precedence.

What happens in simulation?



Article: 129053
Subject: OT. Posting with Outlook Express?
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 13 Feb 2008 17:51:49 -0000
Links: << >>  << T >>  << A >>
Hi All,
I just found this, and thought it might be of interest. Seems to work quite 
well.
http://home.in.tum.de/~jain/software/oe-quotefix/
Cheers, Syms.
p.s. I know, I should be using Thunderbird... 



Article: 129054
Subject: Re: State machine outputs and tri-state
From: "Grumps" <grumpsnothere@hotmail.com>
Date: Wed, 13 Feb 2008 17:59:13 -0000
Links: << >>  << T >>  << A >>
"RCIngham" <robert.ingham@gmail.com> wrote in message 
news:O9mdnTt96ZdbsC7aRVn_vwA@giganews.com...
> >[I posted this to comp.lang.vhdl, but maybe you FPGA experts know the
>>answer.]
>>
>>Hi
>>I'm not a VHDL expert, just learning, so please don't shout.
>>
>>I'm using Xilinx ISE9.2sp4 and have the following code as part of a
> state
>>machine:
>>CP_IN_OUTPUT_DECODE: process (state_cp_in)
>>  begin
>>    if state_cp_in = sta_idle then
>>    RDY <= 'Z';
>>    BUSY <= '0';
>>  end if;
>>
>>  if state_cp_in = sta_1 then
>>    RDY <= '0';
>>    BUSY <= '0';
>>  end if;
>>
>>  if state_cp_in = sta_2 then
>>    RDY <= '1';
>>    BUSY <= '1';
>>  end if;
>>...
>>...etc
>>
>>The state machine goes from sta_idle, then to sta_1, then to sta_2, etc.
>>RDY is a pin on the device.
>>During operation, I can see RDY go low in sta_1, but not high in sta_2.
> I
>>know it gets to sta_2 as I can observe BUSY. I don't think RDY is
> tri-stated
>>in sta_2 as there is an external pull-up; it just stays low. Gray
> encoding
>>is used.
>>
>>If I change the RDY to rdyi (signal) and then have:
>>RDY <= 'Z' when state_cp_in = sta_idle else rdyi;
>>outside of the decode process then it all behaves itself.
>>
>>Apart from lack of experience, what mistake(s) have I made?
>>Thanks.
>>
>
> Check that RDY is not being assigned from another process or concurrent
> assignment.

RDY isn't assigned in another process.

> Check that RDY is not being assigned later in the CP_IN_OUTPUT_DECODE
> process. That will take precedence.

The state machine has 9 states. RDY is assigned in each state, and only 
tri-stated in sta_idle. Is this wrong?
It seems to be the tri-state assignment that throws it.

> What happens in simulation?

Ah yes, simulation. As this was supposed to be a simple design, I went 
straight to hardware and a scope.
Thanks. 



Article: 129055
Subject: Re: When are FPGAs the right choice?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 14 Feb 2008 07:32:14 +1300
Links: << >>  << T >>  << A >>
Mike Silva wrote:
> I've been programming embedded micros for a long time, and have a
> decent understanding of hardware.  I finally ordered an FPGA
> development kit (still in the mail) because I find the whole FPGA
> concept fascinating.  What I don't grasp is when an FPGA is the best
> choice.  To get a better feel for this, I'd like to hear some comments
> on when an FPGA is the best fit, and also when an FPGA turned out to
> be a poor choice.  Many thanks for any advice.

When you cannot do the task with a Microcontroller alone.
It is very common to have both, so then the question is one
of task allocation, rather than "when an FPGA is the best choice".

Micros have advanced quite a bit in recent times, and Atmel
are claiming above 200MIPS from flash with AT91SAM9XE series.
This uses 128 bit fetch & starts at $7.30/10K
- so that device would make a good FPGA companion.

-jg


Article: 129056
Subject: Is a FPGA the solution ?
From: L-C <Louis-Charles.Caron@usherbrooke.ca>
Date: Wed, 13 Feb 2008 10:50:08 -0800 (PST)
Links: << >>  << T >>  << A >>
I would like to know if a FPGA is suited for this application: sound
sources localization and separation.  The algorithm comes in 3 steps:
sources detection using a steered beamformer (in frequency-domain), a
particle filter to track the sources and a combination of a geometric
source separation algorithm and a non-linear post-filter for source
separation.

Also, the audio stream comes from an array of 8 microphones, and all
possible microphone pairs must be considered during the detection
phase.

This algorithm is already implemented of a floating point DSP and I
would like to know if a FPGA could be a good choice to improve
performance.

I heard that a FPGA wouldn't beat a DSP in floating point calculation,
what do you think about that?  Still, I know that an implementation on
a FPGA will require a lot of work to translate the code anyway, so I
suppose it wouldn't be harder to rethink it directly in fixed point.

The FPGA could be used to improve only a fraction of the algorithm
too.
Thanks for your comments.

L-C

Article: 129057
Subject: Re: My first verilog/cpld project
From: nospam <nospam@please.invalid>
Date: Wed, 13 Feb 2008 19:05:23 +0000
Links: << >>  << T >>  << A >>
"Dwayne Dilbeck" <ddilbeck@yahoo.com> wrote:

>Don't try it.   XST will complain that the second operand of DIV and MOD 
>operators have to be powers of two, atleast, in the webpack version.
>
>I ran your code and the below code through the Cadence HDL-ICE synthesizer.
>(For Emulation only)  The case statement was mapped to 188 cells in thier 
>library, the DIV/MOD mapped to 92 cells. (AND02,OR02,XOR02,INV,etc.)
>
>But since this code doesn't work in the free ISE it doesn't matter.
>
>module bcd(ibin, bcd2,bcd1,bcd0);
>
>   input [7:0] ibin;
>   output[3:0]   bcd2, bcd1, bcd0;
>
>   wire [7 : 0]     temp [0:1];
>
>   assign temp[0] = ibin/4'd10;
>   assign bcd0     =  ibin%4'd10;
>   assign temp[1]=  temp[0]/4'd10;
>   assign bcd1    =  temp[0]%4'd10;
>   assign bcd2    =  temp[1]%4'd10;
>
>endmodule

This is static logic, each output is defined by a logical equation
containing inputs. Regardless of how you express it in HDL the equations
are the same and the synthesiser should minimise and fit them just the
same. 

Shitty that your synthesiser didn't, assuming you really did express the
same thing in different ways. 
-- 

Article: 129058
Subject: Re: My first verilog/cpld project
From: Jon Elson <elson@wustl.edu>
Date: Wed, 13 Feb 2008 13:31:11 -0600
Links: << >>  << T >>  << A >>


DJ Delorie wrote:
> Jon Elson <elson@wustl.edu> writes:
> 
>>Aughhh!  Isn't there a better way to do the binary to BCD conversion?
>>Not that there'd be any difference in performance or area, just that
>>the brute-force enumeration of all possible states seems ugly.
> 
> 
> It was pointed out elsewhere that it can be done like this:
> 
>  214 : bcd <= 10'h214 ;
>  215 : bcd <= 10'h215 ;
> 
If you can do this, then you can write it in a loop in about 4 lines!
(Either Verilog or VHDL)

Jon


Article: 129059
Subject: Re: When are FPGAs the right choice?
From: Jon Elson <elson@wustl.edu>
Date: Wed, 13 Feb 2008 13:39:36 -0600
Links: << >>  << T >>  << A >>


Mike Silva wrote:
> I've been programming embedded micros for a long time, and have a
> decent understanding of hardware.  I finally ordered an FPGA
> development kit (still in the mail) because I find the whole FPGA
> concept fascinating.  What I don't grasp is when an FPGA is the best
> choice.  To get a better feel for this, I'd like to hear some comments
> on when an FPGA is the best fit, and also when an FPGA turned out to
> be a poor choice.  Many thanks for any advice.
CPU's are serial, they do one thing at a time.  One other thing is they 
can't
be clocked by an external transition, ie. that their time to respond to 
an external event is VERY finite.

Something I have made a LOT of are quadrature encoder counters, where 
you don't want to miss transitions on the quadrature lines.  I have the
counter clocked at 1 MHz, so I can implement some digital filtering on 
the quadrature inputs.  This allows the counter to count with absolutely 
guaranteed reliability up to at least 300,000 counts/second.  One FPGA 
handles 4 channels like this with parallel logic.  I'd challenge anyone 
to make a traditional microcontroller do this without dedicated logic on 
the CPU, just by sampling the input ports.  This is a trivial exercise 
on an FPGA.  I also generate PWM signals with 100 ns resolution.  This 
could be done easily with counter/timer functions.

Jon


Article: 129060
Subject: Re: When are FPGAs the right choice?
From: Sky465nm@trline5.org
Date: Wed, 13 Feb 2008 20:53:44 +0100 (CET)
Links: << >>  << T >>  << A >>
Mike Silva <snarflemike@yahoo.com> wrote:
>I've been programming embedded micros for a long time, and have a
>decent understanding of hardware.  I finally ordered an FPGA
>development kit (still in the mail) because I find the whole FPGA
>concept fascinating.  What I don't grasp is when an FPGA is the best
>choice.  To get a better feel for this, I'd like to hear some comments
>on when an FPGA is the best fit, and also when an FPGA turned out to
>be a poor choice.  Many thanks for any advice.

When you have algorithms that can benefit from:
  * Parallism
  * Pipelining
  * Tight I/O timing

  FPGA might be an improvement over an asic microcontroller in these cases.

FPGA enables you to replicate a microcontroller in FPGA. And add instructions
for special hardware operations such that you can combine the simple structure
of an MCU with the performance of lowlevel gate operations.

FPGA gates are however slower compared to ASIC. So one challenge is to use it
in a way that it doesn't matter.


Article: 129061
Subject: Re: Newbie looking for guidance
From: gavin@allegro.com (Gavin Scott)
Date: Wed, 13 Feb 2008 19:54:04 -0000
Links: << >>  << T >>  << A >>
everphilski@gmail.com <everphilski@gmail.com> wrote:
> Could I get you to expand on the difference between "DSP hardware" and
> "FPGA" in this context? My (albeit new) understanding was, DSP
> techniques were implemented on FPGA hardware to do digital signal
> processing.

Well, first of all, DSP is probably the topic of yours that I know the
least about so take anything I say with a couple grains of salt.

When I personally think DSP, what comes to mind are things like the 
TI DSP processors which were/are more like general purpose CPUs with
an emphasis on high-speed fixed- or floating-point math rather than
being a general purpose "sea of gates" as an FPGA is.  TI has some
introductory info here it looks like:

   http://focus.ti.com/dsp/docs/dspsupporto.tsp?sectionId=4&tabId=1443

Modern FPGAs have some of the basic building blocks (interger multiply
units, etc.) that make it possible to do traditional DSP processing, 
but you're still mostly building up a machine from scratch to do what
you want rather than just writing a program to express an algorithm.

I don't think it's always easy to answer the question of what should
be done in hardware versus software.  Often there are techniques to
do it either way, and the background of the particular designer tends
to tilt the decision more than anything else.

FPGAs are incredibly cool.  They're great when you need boatloads of
exotic I/Os, extreme parallelism, and complete flexibility.  They don't
make great general purpose CPUs usually.  From a software point of view
they're again the most flexible but probably also the most complex.
From a hardware point of view they're pretty much all cutting-edge 
technology and none of their design is there to make the life of a
hobbyist easy, so building your own FPGA-based hardware designs is 
pretty complex.  Fortunately there are lots of inexpensive boards
you can buy to experiment with.

If you pick up an FPGA board to play with and spend some time with 
it then I don't think you'll regret that learning experience at all.
Whether at the end you decide that the FPGA route is your best one
for implementing the things you want to do is something you'll only
know once you get there.

G.

Article: 129062
Subject: Re: When are FPGAs the right choice?
From: Eric Smith <eric@brouhaha.com>
Date: Wed, 13 Feb 2008 11:59:36 -0800
Links: << >>  << T >>  << A >>
Mike Silva wrote:
> What I don't grasp is when an FPGA is the best choice.  To get a better
> feel for this, I'd like to hear some comments
> on when an FPGA is the best fit, and also when an FPGA turned out to
> be a poor choice.

The general answer is that the FPGA is the best fit when the
FPGA-based solution is less costly than the non-FPGA-based solution.
However, one usually has to consider development and support costs,
not just the BOM cost of the hardware.

So how does one determine which will be less costly?  The only way
I've found is to do at least a rough block diagram and BOM for each.

For my designs, I've found that the choice isn't usually between an
FPGA and something else, but rather between an FPGA alone, or a
microcontroller with a smaller FPGA.

Article: 129063
Subject: Re: Newbie looking for guidance
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 14 Feb 2008 09:06:26 +1300
Links: << >>  << T >>  << A >>
everphilski@gmail.com wrote:

> Rob,
> 
> On Feb 13, 4:18 am, Rob <BertyBoos...@googlemail.com> wrote:
> 
>>>Xilinx's FireBlaze processor simulation on a FPGA.
>>
>>Do you mean Xilinx's MicroBlaze processor? If so, note that this is a
>>general purpose CPU with a fairly average MIPs spec. You'd easily be
>>able to get comparable or better performance with an off the shelf
>>microprocessor -and without all the headaches!
> 
> 
> Yes, I meant MicroBlaze, thanks for catching the typo. This is good,
> so you are saying you would prefer working with a discrete
> microcontroller interfaced to a FPGA, instead of a FPGA with a
> MicroBlaze (or other core) onboard?

PFGA+MicroBlaze lacks code memory, so that's a significant cost.
Generally, if you can find a single chip uC that will fit your task,
you get the EMC & reliability benefits of on-chip memory, and
also (probably) get to use a smaller/cheaper FPGA+LoaderPROM

A good topical example of a companion processor for FPGA,
would be the Atmel AT91SAM9XE series. 200+ MIPS, from 128 bit wide
flash, and $7.30/10K, with 128/256/512K FLASH.

Plus all this fruit:
[USB 2.0 Full Speed Host and Device Ports, an Ethernet 10/100 Base-T MAC 
as well as a two-slot Multimedia Card Interface (SDCard/SDIO and 
MultiMediaCard Compliant), a Synchronous Serial Controller (SSC), four 
USARTs, two master/slave Serial Peripheral Interfaces (SPI), a debug 
UART and two Two Wire Interfaces (TWI).]

If you need megabytes of code, then the balance tips back a little.

-jg



Article: 129064
Subject: Re: My first verilog/cpld project
From: Arlet Ottens <usenet+5@c-scape.nl>
Date: Wed, 13 Feb 2008 21:15:58 +0100
Links: << >>  << T >>  << A >>
Jon Elson wrote:

> DJ Delorie wrote:
>> Jon Elson <elson@wustl.edu> writes:
>>
>>> Aughhh!  Isn't there a better way to do the binary to BCD conversion?
>>> Not that there'd be any difference in performance or area, just that
>>> the brute-force enumeration of all possible states seems ugly.
>>
>>
>> It was pointed out elsewhere that it can be done like this:
>>
>>  214 : bcd <= 10'h214 ;
>>  215 : bcd <= 10'h215 ;
>>
> If you can do this, then you can write it in a loop in about 4 lines!
> (Either Verilog or VHDL)

Sounds interesting. Can you elaborate ?

Article: 129065
Subject: Re: When are FPGAs the right choice?
From: gavin@allegro.com (Gavin Scott)
Date: Wed, 13 Feb 2008 20:19:49 -0000
Links: << >>  << T >>  << A >>
Jon Elson <elson@wustl.edu> wrote:
> Something I have made a LOT of are quadrature encoder counters, where 
> you don't want to miss transitions on the quadrature lines.  I have the
> counter clocked at 1 MHz, so I can implement some digital filtering on 
> the quadrature inputs.  This allows the counter to count with absolutely 
> guaranteed reliability up to at least 300,000 counts/second.  One FPGA 
> handles 4 channels like this with parallel logic.  I'd challenge anyone 
> to make a traditional microcontroller do this without dedicated logic on 
> the CPU, just by sampling the input ports.

I think you could do it on a slightly non-traditional microcontroller,
i.e. the Parallax Propeller, which would let you dedicate one cpu core
to each set of I/O lines.  Clocked at 80Mhz you would get up to 20 
instructions per microsecond to deal with your 1 MHz event stream.

One of the primary design ideas of the Propeller seems to be that CPU
cores are so cheap we don't need to support interrupts at all.  You
just dedicate a CPU to each external device and it basically operates
synchronously with resepect to that device.

It's an interesting idea, and when mainstream processors start having
>16 cores, it will also be interesting to see when people start
"throwing away" things like x86 cores in a similar fashion.

G.

Article: 129066
Subject: Re: When are FPGAs the right choice?
From: Mike Silva <snarflemike@yahoo.com>
Date: Wed, 13 Feb 2008 12:22:20 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 13, 1:32=A0pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Mike Silva wrote:
> > I've been programming embedded micros for a long time, and have a
> > decent understanding of hardware. =A0I finally ordered an FPGA
> > development kit (still in the mail) because I find the whole FPGA
> > concept fascinating. =A0What I don't grasp is when an FPGA is the best
> > choice. =A0To get a better feel for this, I'd like to hear some comments=

> > on when an FPGA is the best fit, and also when an FPGA turned out to
> > be a poor choice. =A0Many thanks for any advice.
>
> When you cannot do the task with a Microcontroller alone.
> It is very common to have both, so then the question is one
> of task allocation, rather than "when an FPGA is the best choice".

Sounds reasonable.  Is the more usual case then to have both micro(s)
and FPGA(s) together, as opposed to FPGA without micro?  Is FPGA
without attached (or internal) micro an uncommon situation?

Mike

Article: 129067
Subject: Re: When are FPGAs the right choice?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 14 Feb 2008 10:47:04 +1300
Links: << >>  << T >>  << A >>
Jon Elson wrote:
> Something I have made a LOT of are quadrature encoder counters, where 
> you don't want to miss transitions on the quadrature lines.  I have the
> counter clocked at 1 MHz, so I can implement some digital filtering on 
> the quadrature inputs.  This allows the counter to count with absolutely 
> guaranteed reliability up to at least 300,000 counts/second.  One FPGA 
> handles 4 channels like this with parallel logic.  I'd challenge anyone 
> to make a traditional microcontroller do this without dedicated logic on 
> the CPU, just by sampling the input ports.  

Surprisingly few uC have Quadrature inputs, given that the logic
is not large in uC terms.

Winbond have just released a group (W79E22x), with encoder to 1/4 FCPU 
per half period ( so max INC/DEC rate is fCPU/2 I think )

The old 89C52 added DIRN, which allows a coarse quadrature support, of 
one INC/DEC per whole cycle, but that's only one quarter of the possible 
resolution. A small PLD can pre-condition to give the higher resolution.


> This is a trivial exercise  on an FPGA.  I also generate PWM signals with 100 ns resolution.  
 > This could be done easily with counter/timer functions.

Or a CPLD, where it will fit.

A common weakness in uC, is that the Peripherals cannot clock faster 
than the core, so you can get situations where you need a fast CPU 
clock, just to run the peripherals (and get the power impact of that in 
the core)...

Of course, most modern FPGAs are not helping the power budgets at all... :(

-jg



Article: 129068
Subject: Re: microblaze firmware + UART handshaking blues
From: Alex Freed <alexf@mirrow.com>
Date: Wed, 13 Feb 2008 13:58:12 -0800
Links: << >>  << T >>  << A >>
GMM50 wrote:

> Hi All:
> 
> This may indeed be a problem but how does debug make it all work.
> 
> george

In my experience the most common scenario is a lack of "volatile" 
keyword. Debug version turns optimization off and release version 
optimizes a read of a hardware register out, 'cause it doesn't know it 
is hardware and nothing in the code changes it's value.

The second possibility is a race condition. Dubug version may execute 
more slowly.

-Alex.


Article: 129069
Subject: Virtex-5 User Guide "Lite"
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 13 Feb 2008 15:20:08 -0800 (PST)
Links: << >>  << T >>  << A >>
If you want to get a feel for what you can do with Virtex-5, click on

http://www.pldesignline.com/howto/206503253;jsessionid=S30OVRH051RUYQSNDLPCKH0CJUNN2JVN

This was a labor of love.
Something like it should have been written ten years ago,
but: "Better late than never".
Hope you like it, and can draw some benefit from it.
Please don't hesitate to post or send me comments of any kind.
Anything good can always be improved!
(BTW, I have 30 patents, not 4. And the picture is 15 years old.
Residual vanity...)
Peter Alfke, Xilinx

Article: 129070
Subject: Re: microblaze firmware + UART handshaking blues
From: chrisdekoh@gmail.com
Date: Wed, 13 Feb 2008 15:41:40 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

1) Does a microprocessor in debug mode run on a slower clock? I din
know that
2) under what circumstances should what variables be volatile?

Chris


On Feb 14, 5:58=A0am, Alex Freed <al...@mirrow.com> wrote:
> GMM50 wrote:
> > Hi All:
>
> > This may indeed be a problem but how does debug make it all work.
>
> > george
>
> In my experience the most common scenario is a lack of "volatile"
> keyword. Debug version turns optimization off and release version
> optimizes a read of a hardware register out, 'cause it doesn't know it
> is hardware and nothing in the code changes it's value.
>
> The second possibility is a race condition. Dubug version may execute
> more slowly.
>
> -Alex.


Article: 129071
Subject: Re: State machine outputs and tri-state
From: bobster.thelobster@yahoo.co.nz
Date: Wed, 13 Feb 2008 15:47:20 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 14, 6:59 am, "Grumps" <grumpsnoth...@hotmail.com> wrote:
> "RCIngham" <robert.ing...@gmail.com> wrote in message
>
> news:O9mdnTt96ZdbsC7aRVn_vwA@giganews.com...
>
>
>
>
>
> > >[I posted this to comp.lang.vhdl, but maybe you FPGA experts know the
> >>answer.]
>
> >>Hi
> >>I'm not a VHDL expert, just learning, so please don't shout.
>
> >>I'm using Xilinx ISE9.2sp4 and have the following code as part of a
> > state
> >>machine:
> >>CP_IN_OUTPUT_DECODE: process (state_cp_in)
> >>  begin
> >>    if state_cp_in =3D sta_idle then
> >>    RDY <=3D 'Z';
> >>    BUSY <=3D '0';
> >>  end if;
>
> >>  if state_cp_in =3D sta_1 then
> >>    RDY <=3D '0';
> >>    BUSY <=3D '0';
> >>  end if;
>
> >>  if state_cp_in =3D sta_2 then
> >>    RDY <=3D '1';
> >>    BUSY <=3D '1';
> >>  end if;
> >>...
> >>...etc
>
> >>The state machine goes from sta_idle, then to sta_1, then to sta_2, etc.=

> >>RDY is a pin on the device.
> >>During operation, I can see RDY go low in sta_1, but not high in sta_2.
> > I
> >>know it gets to sta_2 as I can observe BUSY. I don't think RDY is
> > tri-stated
> >>in sta_2 as there is an external pull-up; it just stays low. Gray
> > encoding
> >>is used.
>
> >>If I change the RDY to rdyi (signal) and then have:
> >>RDY <=3D 'Z' when state_cp_in =3D sta_idle else rdyi;
> >>outside of the decode process then it all behaves itself.
>
> >>Apart from lack of experience, what mistake(s) have I made?
> >>Thanks.
>
> > Check that RDY is not being assigned from another process or concurrent
> > assignment.
>
> RDY isn't assigned in another process.
>
> > Check that RDY is not being assigned later in the CP_IN_OUTPUT_DECODE
> > process. That will take precedence.
>
> The state machine has 9 states. RDY is assigned in each state, and only
> tri-stated in sta_idle. Is this wrong?
> It seems to be the tri-state assignment that throws it.
>
> > What happens in simulation?
>
> Ah yes, simulation. As this was supposed to be a simple design, I went
> straight to hardware and a scope.
> Thanks.- Hide quoted text -
>
> - Show quoted text -

I'm saying that only because you said you were a beginner, not because
of you code =83=BA.


Anyway look at a state machine, it's usually a mishmash of flipflops
and logic gates.
A tristate is usually a buffer on a bus. In hardware that's 2
different jobs.

So do something like this

1st describe a tri-state buffer something like


signal MY_BUFFER_OUT, MY_BUFFER_IN, MY_BUFFER_CONTROL : std_logic;

MY_BUFFER_OUT <=3D MY_BUFFER_IN when MY_BUFFER_CONTROL =3D '1' else 'Z';

Assign MY_BUFFER_CONTROL from your state machine, only assign 1 and 0
to RDY, connect MY_BUFFER_OUT to your port and MY_BUFFER_IN to the
equivalent of  RDY.

This looks exactly the same if you think of it in software terms but
it's a different beast altogether if you take a hardware view.
I'd just like to add, I'm glad to see your using ISE, unlike the more
expensive tools it wont accept nonsense, my advice is stick with ISE
until your competent, then don't lose those good coding habbits.

Let me know how it goes Bobsterthelobster

Article: 129072
Subject: Re: State machine outputs and tri-state
From: bobster.thelobster@yahoo.co.nz
Date: Wed, 13 Feb 2008 15:48:50 -0800 (PST)
Links: << >>  << T >>  << A >>
Sorry only half the post went :-) here it is again

Hi Grumps,

You say you=A1=A6re a beginner, so please allow me to offer the one piece
of advice that you should never waver from.
You are designing hardware, its not software, if you ignore that point
you=A1=A6ll join the ranks of people that are giving the industry a bad
name with their unstable designs.
Always try to imagine the circuit you=A1=A6re describing, and you won=A1=A6t=
 go
far wrong.

I=A1=A6m saying that only because you said you were a beginner, not because
of you code =83=BA.


Anyway look at a state machine, it=A1=A6s usually a mishmash of flipflops
and logic gates.
A tristate is usually a buffer on a bus. In hardware that=A1=A6s 2
different jobs.

So do something like this

1st describe a tri-state buffer something like


signal MY_BUFFER_OUT, MY_BUFFER_IN, MY_BUFFER_CONTROL : std_logic;

MY_BUFFER_OUT <=3D MY_BUFFER_IN when MY_BUFFER_CONTROL =3D =A1=A51=A1=A6 els=
e =A1=A5Z=A1=A6;

Assign MY_BUFFER_CONTROL from your state machine, only assign 1 and 0
to RDY, connect MY_BUFFER_OUT to your port and MY_BUFFER_IN to the
equivalent of  RDY.

This looks exactly the same if you think of it in software terms but
it=A1=A6s a different beast altogether if you take a hardware view.
I=A1=A6d just like to add, I=A1=A6m glad to see your using ISE, unlike the m=
ore
expensive tools it wont accept nonsense, my advice is stick with ISE
until your competent, then don=A1=A6t lose those good coding habbits.

Let me know how it goes Bobsterthelobster



Article: 129073
Subject: Re: Virtex-5 User Guide "Lite"
From: bobster.thelobster@yahoo.co.nz
Date: Wed, 13 Feb 2008 16:10:22 -0800 (PST)
Links: << >>  << T >>  << A >>


Thanks Peter

Its an almost effortless, easy read, but still informative, a
translation from xilinx to English, LOL,, well done that man

Well I for one intend to keep a copy of it.

Article: 129074
Subject: Re: Virtex-5 User Guide "Lite"
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 14 Feb 2008 00:39:49 -0000
Links: << >>  << T >>  << A >>
Hi Peter,

"The array size is between 8 Mb and 79 Mb (1 to 10 MB),"
When your photo was taken, 15 years ago*, was when I started work on a new 
design using brand new XC4000 series parts. My PC's hard disk was 10MB!

That's a nice article, one that I planning on linking to!

Cheers, Syms.

* Also, I had to get up in the morning at ten o'clock at night half an hour 
before I went to bed, drink a cup of sulphuric acid, work twenty-nine hours 
a day down mill, and pay mill owner for permission to come to work, and when 
we got home, our Dad and our mother would kill us and dance about on our 
graves singing Hallelujah. 





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