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 74075

Article: 74075
Subject: Re: Quartus and VDHL misbehavior
From: Ben Twijnstra <btwijnstra@chello.nl>
Date: Sun, 03 Oct 2004 19:51:38 GMT
Links: << >>  << T >>  << A >>
Hi Phillip,

> Thanks for the reply.  I incorporated the component into a synchronous
> process and it works fine now.  However, I still have a few questions
> just so I can get a better understanding of what was going on.
> 
>> The way you have written this code will make sure that Modelsim only
>> 'schedules' the process if A_in or B_in changes.
> 
> That was my intention.  I wanted the output to change *only* when one
> of the two inputs changed.  I see what you mean that the 'internal
> states' were not counted as inputs though.  So, how would you go about
> making this component so that it will change state only when the input
> changes?

VHDL was initially designed as a simulation laguage based on ADA using
concurrent processes and the lot. Using the sensitivity list you could pick
which set of events could trigger scheduling of one such process during
simulation. 

The 'synthesizable subset' of VHDL, be it the 1987, 1993 or 200x version,
has the requirement that a process by nature is sensitive to any signal or
port to the right of an '<=', unless it's within a "clk'event or
clk='whatever' block. This will cause a process(a,b) not only to be
'scheduled' when a or b changes, but whenever any input in any of the
internal statement changes.

This is inherent to the fact that within a process you are merely decribing
a more or less complex set of combinatorial equations, possibly ending in a
bunch of registers at the end (which are inferred by the clk'event stuff). 

So, at this point I don't see an easy way to do this, unless you want to use
the a and b signals as true and inverted clocks to a set of toggle
registers and use the relative state of these registers as your state
vector.

>> If you synthesize this with Quartus (or any synthesis tool for that
>> matter) you will get warnings that state(1) and state(0) should also be
>> on the sensitivity list.
> 
> In fact, Quartus gives the following message:  "Design
> top_quadrature_decoder: Netlist extraction and synthesis were
> successful. 0 errors, 0 warnings"

I think you should get a warning that something else should be on the
sensitivity list as well. I'll give it a try on monday and file an SR if I
don't get one.

>> Even though I hate using the /= operator on a std_logic.
> 
> Is this just a personal preference?  or is there a reason one should
> avoid the /= operator?

A bit only has values '0' and '1', so saying "if x /= '0'" basically means
"if x = '1'", so no problem there. However, a std_logic has seven possible
values, so saying "if x /= '0'" basically means "if x='1' or x='Z' or x='H'
or x='L' or x='X' or x='U'". Most of these don't make sense during
synthesis and ar happily ignored, but I've had two cases where such a
comparison was made on a signal that was part of a tri-state bus somewhere
upstream, and the 'Z' (or tri-state) case was taken into account as well,
causing a lot of initialy inexplicable behavior.

Best regards,


Ben



Article: 74076
Subject: Re: FPGA vs ASIC area
From: austin <austin@xilinx.com>
Date: Sun, 03 Oct 2004 13:12:11 -0700
Links: << >>  << T >>  << A >>
Rick,

I can not say how long, because that is proprietary information.

I know exactly how long it takes to test the CLB, BRAM, DCM, PPC, MGT, etc.

Exactly.

Austin

rickman wrote:
> austin wrote:
> 
>>Rick,
>>
>>Configuration of a test pattern can make efficient use of our partial
>>reconfiguration capabilities.  I can not say how many seconds an FPGA
>>spends in the tester, but it is less that an ASIC does.  There also may
>>be much faster ways to configure that we can use, but do not offer to
>>customers.
> 
> 
> Austin, if you don't know how much time it takes to test your FPGAs,
> then how can you possibly say it is faster than an ASIC that you also
> don't know the test time for???  I think you and Peter are talking
> through your hats on this one.  Much like the other arguments that FPGAs
> are better than ASICs that pretty much ignore the fact that an ASIC can
> be done using several generations older technology to get the same
> overall costs.  Your 90nm chips may be very dense, but they are using
> the most expensive equipment around and automatically have a 10:1 hit in
> most areas of cost.  
> 
> 
> 
>>Why can we do 1,000's of BIST patterns faster?  Well one obvious reason
>>is that a BIST pattern in a FPGA can run at the speed of the FPGA, which
>>is often 10X to 100X faster than the tester.  It might have to run for
>>1000 clocks to finish, and then go on to the next test, which might be
>>different by the contents of a few LUTs.
>>
>>If you are really curious of how we perform this magic, you can research
>>all of our BIST patents and think about what you would do if you faced
>>such a problem.
>>
>>Again, Peter is right.
> 
> 
> I am sure Peter is right about a lot of stuff.  But you don't provide
> any information that shows he is right about this.  
> 

Article: 74077
Subject: Re: FPGA vs ASIC area
From: austin <austin@xilinx.com>
Date: Sun, 03 Oct 2004 13:33:27 -0700
Links: << >>  << T >>  << A >>
Rick,

see below

Austin

rickman wrote:

> austin wrote:
> 
>>Rick,
>>
>>Bad hair day?
> 
> 
> Austin, Peter sends me private emails asking me to ignore your
> nonsense.

I will discuss it with Peter.  As well, I have no shortage of folks who 
email me directly or on this board to let me know if they do not like a 
posting.

   He tells me you are a valuable asset to this group because
> you have significant knowledge.

Untrue.  I have only been at Xilinx for 6 years, before that I spent 26 
years in the telecom business.  What I know about ICs and FPGAs has been 
gained from 6 produt releases.  There are many at Xilinx with many many 
more years, and products, under their belts than I.  I consult them for 
my responses, as I by myself, am nothing.

But your BS is enormous.

No need to be insulting.

   This comment
> is the sort of thing that is not welcome in the group, at least by me. 
> If you want to discuss the issues, then leave the crap at home.  I find
> you to be a very unprofessional representative for Xilinx and I have
> even told my local sales people that.

I have not heard this feedback.  Let me know who you contacted.  It is 
important to me that all feedback get back to the people who should hear it.

   I don't know if this ever makes
> it back to your managers, but I sincerly hope that I never have to
> depend on you for any sort of support.  In fact, you personally are one
> of the reasons that I keep looking at the solutions offered by Altera,
> and have ended up filling at least one of the sockets on our boards with
> an Altera part.  

I am sorry if I have offended you in any way. I have no idea what I have 
done.

My managers are well aware of my postings, as well as what people say 
about me.  If there is something you feel they should know, email me 
directly and I will give you their email addresses so you may reply in 
private to them.  Or post it here.

If you wish, I can be reached directly by this email address.  I am 
always willing to listen to how I can improve.

Article: 74078
Subject: Re: FPGA vs ASIC area
From: austin <austin@xilinx.com>
Date: Sun, 03 Oct 2004 13:41:17 -0700
Links: << >>  << T >>  << A >>
MK,

Unfortunately, I do not.  My information was from word of mouth from IC 
designers that worked at Intel, but are no longer there.

It counts every single FF added for capture, scan chain, as well as all 
test loopbacks, multiplexers, etc. that are added for any reason that is 
not purely functional.

I know that there is not that much area added to the IBM 405PPC, and not 
that much added to the MGT, etc. but the Pentium is much more complex, 
and may require more logic for test reasons to get better coverage.

If I find a reference, I will post it.

As I said to Rick, I really don't know all that much, but I am a good 
listener.  And when I listen to IC designers talk about what they did, 
and so forth, I do remember what they say.

Austin

mk wrote:

> On Fri, 01 Oct 2004 07:54:13 -0700, Austin Lesea <austin@xilinx.com>
> wrote:
> 
>>30%+ of a Pentium IV is BIST logic
> 
> 
> I find that very hard to believe. Do you have any references to back
> up that claim ?
> 

Article: 74079
Subject: Re: NV on-chip memory?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 04 Oct 2004 09:43:50 +1300
Links: << >>  << T >>  << A >>
Martin Schoeberl wrote:
>>Martin- It makes sense that integrating ram replacing external memory
> 
> would
> 
>>reduce pin count etc, the confusing part of your message is realted to
> 
> this
> 
>>thread being NV memory oriented.  Do you want your 128KB on chip memory
>>truly for ram or for code storage?  Does that relate to the NV aspect
> 
> of the
> 
>>discussion for those low density devices you mention?
>>-cheers
> 
> 
> It does not direct relate to the NV aspect, but Paul was talking about
> the SRAM contained in an FPGA. So I throwed in my larger SRAM wish.

This Code-Ram  should also be able to be Wide path and split, so
that multiple cores can be supported, with wide opcodes if desired.

Given the relatively high Static Icc now of FPGAs, it would also
make sense to look at Self-refresh DRAM - DRAM is much more die
efficent.


> For code memory I'm happy with larger serial Flash chips when I can access
> them from the FPGA. Here the pin count is not so problematic and I know
> Flash integration is problematic from the technology point.

Serial 'Data Storage' Flash is getting better all the time, and could 
serve as code memory in some instances. 'Jumps outside the Cache' would
be relatively costly, but the streaming speeds are getting quite good.

-jg


Article: 74080
Subject: Re: M*Blaze in Cyclone ! End of What? ;)
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 04 Oct 2004 09:49:40 +1300
Links: << >>  << T >>  << A >>
Antti Lukats wrote:

> Hi
> 
> I would like to quote Martin Schoeberl: "And a MB on an Altera FPGA, that's
> the end of the world."
> 
> Well the end of the world must then be TODAY?
> MB is working in Cyclone FPGA, screenshots available:
> 
> http://uclinux.openchip.org/forum/viewtopic.php?t=11

  Impressive, Wonder when we will see NIOS-II on Spartan-3 ;)
-jg


Article: 74081
Subject: Re: MicroBlaze is no available as Open-Source!! (from independant 3rd party)
From: jon@beniston.com (Jon Beniston)
Date: 3 Oct 2004 16:27:34 -0700
Links: << >>  << T >>  << A >>
"David Brown" <david@no.westcontrol.spam.com> wrote in message news:<cjm4ke$p5$1@news.netpower.no>...
> "Antti Lukats" <antti@case2000.com> wrote in message
> news:cjjtgn$mp6$03$1@news.t-online.com...
> > "Jon Beniston" <jon@beniston.com> wrote in message
> > news:e87b9ce8.0410010514.6fa501a@posting.google.com...
> > > > # Xilinx benefit if MicroBlaze is in the news
> > > >
> > > > # Such efforts expand usage of, and research in, MicroBlaze
> > > >
> > > > # It can be a usefull second opinion / benchmark
> > > >
> > > > # Xilinx will have trademark rights to MicroBlaze, so they can
> > > > restrict use of the name. Other examples of this are 6805 uC and i2c
> > > > instances.
> > > >
> > > > # The open source core is only a tiny portion of system development:
> > > > you also have compilers/SWdebuggers/HWDebuggers/Libraries, and all of
> > > > those will have Xilinx license restrictions for Xilinx FPGAs.
> > >
> > > Actully, the compiler & I believe the debugger are open source. This
> > > means that people are very close to having everything for free.
> >
> > 1) The compiler and binutils are GPL GNU stuff - that is Xilinx *must*
> > provide the source of the those GNU tools in source code form at no
>  charge,
> > what they are doing, the gnu source of the tools is freely available from
> > Xilinx. And due to the GPL licensing they can not limit the access to that
> > source code.
> 
> Xilinx don't have to provide the source free of charge.  What they have to
> do is provide an offer to those who have access to the binaries, offering
> them the source code for no more than a reasonable distribution fee.  They
> have no obligation to make the source code available to anyone else, nor do
> they have to make it free (as in beer), only free (as in speach).  However,
> if someone buys a MicroBlaze development kit including the compiler, etc.,
> then Xilinx must provide the source code to that someone, and they can then
> pass it on freely if they want.  What this boils down to is that Xilinx has
> no obligations to make the tools easily available, but if someone posts the
> tools on opencores then Xilinx cannot complain (except perhaps regarding
> trademarks on the name).

They do actually provide the source code for free. There is a link on
their web site.

Cheers,
JonB

Article: 74082
Subject: Differences between Xilinx ISE Foundation and WebPACK.
From: "Antti Karttunen (remove the trailing .do from the address)" <Antti.Karttunen@iki.fi.do>
Date: Mon, 04 Oct 2004 02:29:31 +0300
Links: << >>  << T >>  << A >>
Martin Schoeberl wrote:
>
> You can find a 6809 with VGA, UART and keyboard controller running on the
> Starter Kit at:
> http://members.optushome.com.au/jekent/Spartan3/index.html
> 
> Martin

Thanks!
(so I guess similar 8-bit processors should
be on its limits.)

Here follows more newbie-questions.

As the Spartan-3 Starter Kit comes with only sixty
days evaluation version of "ISE Foundation", and
not time-limited version of "ISE WebPACK", I listed
their differences from http://www.xilinx.com/ise/devsys_feature_guide.pdf

and realized that WebPACK is lacking at least
these features that come with the Foundation:

CORE Generator System
Modular Design
FPGA Editor with Probe
SMARTModels for PowerPC and RocketIO.

What are these, and how essential they are
if I (eventually/immediately) want to do my own designs?

Also, does WebPACK support both VHDL and Verilog
fully?

Anybody knows if there there plans to port it (WebPACK)
to Linux or other Unix-systems, and when?
(And similar question for Altera's Quartus-II software.)


Yours,

Antti

Article: 74083
Subject: Re: MicroBlaze is no available as Open-Source!! (from independant 3rd party)
From: jon@beniston.com (Jon Beniston)
Date: 3 Oct 2004 16:29:46 -0700
Links: << >>  << T >>  << A >>
> 2) It is not of big news yet, but the new EDK software ide is based on
> Open-Source Eclipse Platform as well, but Eclipse licensing is different so
> using Xilinx Eclipse tools is possible not free, but as Eclipse itself is
> free and Open-Source there are no limitations for 3rd parties to develop
> Eclipse based IDE for the Open-Source M*Blaze

No doubt their version of eclipse will be based on the standard C/C++
plugin with a few extras. It's already pretty easy to set eclipse up
to target MicroBlaze / NIOS / any other GNU toolchain based processor.

Cheers,
Jon

Article: 74084
Subject: Re: Open-Source MicroBlaze IP-Core working in FPGA :)
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Mon, 04 Oct 2004 09:49:57 +1000
Links: << >>  << T >>  << A >>
Hi,

whatisasics wrote:
> Antti Lukats wrote:
> 
>> http://uclinux.openchip.org/forum/viewtopic.php?t=4
>>
>> here is proof :)
>>
>> the opensource version as available from opencores is not yet good 
>> enough to
>> run uCLinux - well lets see if that will change,
>> I think there is a wish to have an open-souce multi-vendor FPGA softcare
>> capable to run uCLinux inside many people :)
> 
> And this is what irks me...if you "need" a "free" FPGA cpu core, there
> are already several to choose from (www.opencores.org.)  One of them
> even has a full GNU-tool chain.  So what makes the Microblaze so
> special?  Is it because it has some industry recognition, better
> performance/functionality, or is it simply because more people have
> already used it, and want to continue use what they're familiar with?
> 
> Maybe it's because Xilinx poured in a lot of R&D into Microblaze,
> proved the design, and are committed to future support of it.
> Enough customers haved used the design that people in the industry
> collectively 'know' its strengths/weaknesses.

I think the reasons our mb-uclinux project is a success, with high 
visibility and good commercial and academic penetration, are its 
openness, its community, and its independence.

uClinux on Altera NIOS 1 seems to have gone almost no-where, I think 
partially because the rights to sell the development kit were bundled 
into Microtronix.   The uClinux mailing list now sees a few individuals 
trying to scrape together the bits and pieces from that project, to get 
a free, public distribution.

Evidence that Altera learned their lesson comes from the fact that 
uClinux support for NIOS 2 was announced the same day as the NIOS2 core 
was available, and AFAIK this time it is free.  Good move.

 > Sorry I went off on a rant...I'm struggling to understand why
 > OpenRISC 1k, despite being 'proven' for more than a year, isn't really
 > showing up anywhere.

There is/was a port for uClinux 2.0 kernel for OR1K - however I think 
system performance in generic FPGA fabric might have been an issue. 
Also, there is more to building a system than justing having a processor 
and a compiler, you need tools to interconnect system componebts and so 
on - the Xilinx EDK and Altera equivalent. Without the tools, free or 
not there hurdle is too high.

> I suppose the upside is that old engineering saying: "copying is the
> highest form of flattery." :)

Indeed - has anyone reverse engineered NIOS yet? ;-)

Regards,

John

Article: 74085
Subject: Xilinx FPGA EMAC Drivers
From: bayshore_23@yahoo.com (Tony K)
Date: 3 Oct 2004 16:50:41 -0700
Links: << >>  << T >>  << A >>
Hi

I am working with a xilinx EMAC core on a virtex II FPGA. I have  
successfully (at least I think) placed the EMAC core on the board and  
able to compile all cores and able to synthesize the design. I am also  
able to run some sample code on the board. Now I am working with  
EMAC and xilinx low level drivers. In my drivers I am calling functions  
from Xilnx EMAC drivers  (loopback, selftest). I am able to successfully  
call some functions for EMAC for ex. setMac Address and initialize  
device but the selftest functions for emac always fails. I am not sure if  
its the hardware or broken drivers. Any ideas or advice will be greatly  
appreciated. 
thank

Mike K. 
SUNY Farmingdale

Article: 74086
Subject: Re: FPGA for OCR processing
From: hpa@terminus.zytor.com (H. Peter Anvin)
Date: Sun, 3 Oct 2004 23:50:49 +0000 (UTC)
Links: << >>  << T >>  << A >>
Followup to:  <cjev60$2cnv$1@biggoron.nerim.net>
By author:    "Daniel" <df@yahoo.com>
In newsgroup: comp.arch.fpga
> 
> Why not a reimplementation of software? Is it more difficult to develop a
> version for a FPGA solution (if the publisher can do it) than to programme
> the FPGA in order to adjusted it to the soft?
> 

Doing a sequential algorithm in an FPGA is bound to be much slower
than one on a hardwired CPU.

The FPGA will win if you can exploit the parallellism inherent in the
hardware solution.

	-hpa



Article: 74087
Subject: Re: M*Blaze in Cyclone ! End of What? ;)
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Mon, 04 Oct 2004 09:57:16 +1000
Links: << >>  << T >>  << A >>
Hi folks,

Antti Lukats wrote:

> the M*Blaze/uCLinux has already received first donation offers, but more
> donations are welcome of course, specially in form of FPGA development
> hardware.

I would like to point out that this has nothing to do with the 
Microblaze uClinux project that is run out of The University of 
Queensland.  We are neither soliciting nor accepting donations for this 
work.

The Microblaze uClinux project home page:

http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux

Regards,

John

Article: 74088
Subject: Re: FPGA for OCR processing
From: hmurray@suespammers.org (Hal Murray)
Date: Sun, 03 Oct 2004 19:47:27 -0500
Links: << >>  << T >>  << A >>
>Doing a sequential algorithm in an FPGA is bound to be much slower
>than one on a hardwired CPU.

Why?  Is that comment true in general, or just for OCR problems?

I'd expect there are some sequential problems that would be
much faster in a FPGA.

Suppose we assume the clock on the CPU is N times as fast as
the FPGA and the CPU.  Then any problem that takes more than N
cycles on the CPU will be faster on the FPGA if the FPGA only
takes 1 cycle.  How about something like computing a CRC?

Better would be doing a CRC type calculation while searching
for a pattern.  I think the Fire codes use something like that
for error correction.

-- 
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: 74089
Subject: Re: Hardware Log and EXP
From: Ray Andraka <ray@andraka.com>
Date: Sun, 03 Oct 2004 21:18:45 -0400
Links: << >>  << T >>  << A >>
Mike,

Neither CORDIC nor the software approximations are all that appropriate
for hardware (FPGA) implementation.  The first question is how accurate do
you need the log?  A quick and dirty Log will get you to about 1/4 dB
using a very small LUT and barrel shift.  Here's the secret:

You've got some number Y which has a big dynamic range (say it's floating
point, for example).  Y can be broken into Y=(2^b)*a where a is a
normalized value such that 1.0<=a<2.0.  Then Log(Y)= bLog(2)+Log(a).  Use
a normalizing barrel shift to shift the unsigned mantissa all the way to
the left so that the MSB is a '1', counting the number of bits shifted.
The number of bits shifted is related to the exponent b by a simple
subtraction.  Log(2) is a constant multiply of the exponent.  The exponent
gets you to 6dB alone.  Now since the mantissa is normalized, you can use
the MSBs to address a look up table to get the part of the log due to the
fraction.  The MSB is always a '1', so it does not need to be used in
forming the address.  If you use the next 4 MSBs to address a 16 entry
table you get better than a half dB accuracy, and it only takes a 4 input
LUT per bit to do.  Oh, one more thing.  If you choose the log base as 2,
then you simply concatenate the exponent bits (no multiplication) to the
output of the mantissa LUT.  If you then need a different base, you can
multiply that complete log by a constant equal to 1/Log(2) in the desired
base.

Floating point input to the Log is actually nearly ideal, because the
mantissa is already normalized and the exponent already separated, so you
can do the log directly.

Computing exp(x) is similar except the operations are accomplished in
reverse (it is easiest to do in base 2):  First, convert to a log base of
two by multiplying by the appropriate constant.  Next separate the integer
and fraction parts (this is jsut a fixed selection of the bits in the
log).  The fraction part address a look up table containing the antilog of
the fraction (you can get by using jsut a few MSBs once again, and you'll
want to add on an implied 1 so that the fraction is between 1.0 and 2.0).
Then shift the value read from the LUT by the number of bits indicated by
the integer part of the Log value.

If you need higher precision than what you get with a reasonably sized
LUT, you can iterate on this method or use one of several algorithms.  In
most cases, you do not need the extra precision.


Mike Delaney wrote:

> snipped, basically he needs log and exp in floating point

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 74090
Subject: Re: Hardware Log and EXP
From: Ray Andraka <ray@andraka.com>
Date: Sun, 03 Oct 2004 21:33:53 -0400
Links: << >>  << T >>  << A >>
Oh yeah, I forgot to mention this.  Of course the CORDIC is fixed point.  CORDIC
is an inherently fixed point algorithm.  It makes absolutely no sense to attempt
CORDIC as floating point.  If you need to use CORDIC for floats, then you should
first normalize your I and Q inputs so that the larger is left justified and
they share a common exponent,  Then you perform the CORDIC rotation on the
normalized mantissa pair as a fixed point operation, passing the common exponent
around the CORDIC.  At the CORDIC output, you can renormalize the I and Q and
marry those individually with the common exponent.  It doesn't make sense to do
the insides of CORDIC in floating point because it is a shift and add
operation.  Each iteration requires the mantissa for either I or Q to be
denormalized so that they have a common exponent so that they can be summed.
Further, each elemental rotation does not alter the magnitude of the vector
(other than a small fixed gain), so each stage in the CORDIC rotation has the
same common exponent.

The CORDIC Log is somewhat awkward in that it involves some rather hardware
intesive set up to get the (a-1)/(a+1) term from the log argurment, a.  There
are better algorithms (for example, I developed a precision log algorithm
similar to CORDIC that I have not published yet, but have used in a design where
I needed to compute a Log with an accuracy of 0.005dB ).

Kevin Neilson wrote:
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 74091
Subject: Re: FPGA servo motor controller
From: "Antti Lukats" <antti@case2000.com>
Date: Sun, 3 Oct 2004 18:42:50 -0700
Links: << >>  << T >>  << A >>
"iceman" <static123ph@yahoo.com> wrote in message
news:62011d8f.0410030504.40932424@posting.google.com...
> ei anyone can help me with the algorithm on how to control a
> servomotor... cause we are gonna use it on our thesis... by the it's
> called "FPGA based intravenous infusion monitoring and control system"
>
> can anyone help us out on how to control a servomotor...will be using
> the servomotor to clamp the tube of an I.V.(intravenous) tube... the
> flow of the algorithm will bw this... first a personnel will input how
> many dosage a patient gets and then the servomotor will clamp the I.V.
> tube so that the desired dosage is achive... by the way will be using
> optical sensors to monitor the drops of the I.V. fluid i will be
> placed at the outside of the drip chamber...
>
> but we have a problem what if the drip of the fluid change how will
> the servomotor adjust it so that the dosage will be maintained...will
> use a feedback but how are we gonna implement it on FPGA..
>
> got any suggestion on the algorithm... or any sites that can help us
> solve this problem

you did not specify what type of servo you need to control, if that R/C
servo then that can be easily connected to FPGA there are some free ip cores
for that.

BUT controlling R/C servo and doing some algorithm is way simpler faster and
cheaper when implemented using some small microcontroller not an FPGA - so
unless there are other reasons to use FPGA then microcontroller based design
would be better choice

antti



Article: 74092
Subject: Re: How to generate a signal on Xilinx Spartan II
From: Ray Andraka <ray@andraka.com>
Date: Sun, 03 Oct 2004 21:44:25 -0400
Links: << >>  << T >>  << A >>
The best solution is to use a phase accumulator (aka Direct Digital Synthesis).  All
that is is a fancy name for an accumulator that adds a fixed increment value to itself
on every clock cycle.  The MSB of the accumulator is the clock output, and the output
frequency is related to the master clock frequency by:

    fo = fc*n/(2^k)

where:
    fo = output frquency
    fc = master clock frequency
    n = increment value (integer)
    k = number of bits in accumulator.

For example, you have a 200 MHz master clock, and you need the output to be 400 Hz.
Lets say we use an 32 bit accumulator, so n = 400/200M * (2^32) = 8589.9, which rounded
is 8590.  Plugging that back in, you have an output frequency of 400.003 Hz.  The
number of bits in the accumulator sets the resolution of the frequency setting you can
have.  The output will have a maximum jitter of +/- 1/2 clock period of the master
clock.

The circuit is just an accumulator that always adds the constant n to itself.  This
works by taking advantage modulo arithmetic.  Basically , you keep accumulating the
fractional part and throwing away the integer part of the accumulated sum.  Each time
the sum crosses over to the next integer, the integer part is dropped.


Rakesh Sharma wrote:

> Hi,
>
>    I wish to generate a frequency of approx 400 Hz using Xilinx
> Spartan II(200 MHz)and send the 1 bit signal to a speaker output and
> hope to hear some noise.
>    My VHDL code, tested on PeakVHDL simulator does generate the
> waveform and is pasted at the far bottom. The problem is that the code
> does not compile on Xilinx because "WAIT for 2.5 ns" is not supported
> on Xilinx Spartan II for a process. What would be the simplest way out
> to generate 400 approx Hz on a Xilinx 200MHz device? I have used
> 200MHz/(2 to the power of 19) = 382 Hz approx. (Use MSB of 19 bits of
> STD_LOGIC_VECTOR)
>
>   Another thing which has confused me is: If I wish to write an
> entity(below) for Spartan II, does the programmer worry about
> generating the signal for "clk" input? Or simply connect it to the
> correct pin of FPGA and I should get the signal of 200MHz?
>
> ENTITY some_entity IS
>         PORT (clk : IN BIT);
> END some_entity;
>
>  For my code tested on PeakVHDL, I have generated the 200MHz signal
> using a test bed(music_tester) and then modified it to 400Hz.
>
>  I apologise if the question is basic.
>
> Thanks in advance
>
> ENTITY music_tester IS
>         PORT (clk : OUT STD_LOGIC; freq : IN STD_LOGIC);
> END music_tester;
>
> ARCHITECTURE behavioral OF  music_tester  IS
> BEGIN
>         process
>         BEGIN
>                         clk <= '1';
>                         -- 200MHz is 5ns cycle
>                         WAIT FOR 2.5 ns;
>                         clk <= '0';
>                         WAIT FOR 2.5 ns;
>         END process;
> END behavioral;
>
> ENTITY music1 IS
>        PORT (clk : IN STD_LOGIC; pinout : OUT STD_LOGIC);
> END music1;
>
> ARCHITECTURE music1_structure OF music1 IS
> BEGIN
>
>         PROCESS(clk)
>                 VARIABLE  counter : STD_LOGIC_VECTOR(18 DOWNTO 0) :=
> conv_std_logic_vector(0, 19);
>                 VARIABLE Aint : INTEGER RANGE 0 TO 524287 := 0; -- 19 bits
>
>         BEGIN
>                                 IF RISING_EDGE(clk) THEN
>                                         counter := conv_std_logic_vector(Aint, 19);
>                                         Aint  := Aint + 1;
>                                         -- Divide 200 Mhz/(2*2*2...19
> times)
>                                         -- MSB has approx 382Hz
>                                         pinout <= counter(18);
>                         END IF;
> END process;
> END music1_structure;
>
> ENTITY testbench IS
> END testbench;
>
> ARCHITECTURE structure OF testbench IS
>         COMPONENT music_tester PORT (clk : OUT STD_LOGIC; freq : IN
> STD_LOGIC); END COMPONENT;
>         COMPONENT music1        PORT (clk : IN STD_LOGIC; pinout : OUT STD_LOGIC);
> END COMPONENT;
>         SIGNAL a, b :STD_LOGIC;
> BEGIN
>         tester: music_tester PORT MAP(a, b);
>         UUT: music1 PORT MAP(a, b);
> END structure;

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 74093
Subject: Re: Removing set/reset logic for shift register (HDL ADVISOR )
From: Ray Andraka <ray@andraka.com>
Date: Sun, 03 Oct 2004 21:52:54 -0400
Links: << >>  << T >>  << A >>
Depends on your design and what you are willing to settle for.  Technically
speaking, all you really need to do is provide a way of clearing stuff in your
design tht is inside hardware loops.  For example, a state machine or an IIR
filter have a 'loop' that needs to be broken in order to bring the hardware to a
known state.  In many cases, it is perfectly acceptable to clear only key points
in the design, and sometimes even require the reset be asserted for some minimum
number of clock cycles to achieve a known state.  Yes, the easy methodology is
to reset every flip-flop, but it is not necessary and can cost you dearly in
terms of both gates and reset signal fan out (and therefore delay).



Dave wrote:

> Ok I understand...but isn't it better to have a reset for all our flip flop?
> If something goes wrong - or when I press the reset button...- the
> controller can always reset everything to zero before we start again...
>
> Thanks,
> David
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:415DAEA4.AAFC9B99@andraka.com...
> > The SRL16 does not have a reset pin on it...ie, you can't clear its
> > contents in one clock cycle.  Your code has a reset in it that clears the
> > whole shift register, which means it cannot be implemented using an SRL16
> > primitive (which costs only one LUT+FF instead of 9).  If you can
> > eliminate the reset on this shift register, then you get a more compact
> > implementation.  Your code would look like this:
> >
> > always @ (posedge mclk or negedge resetb)
> > begin
> >                   if (sclkRise == 1) begin
> >                         datain[63:1] <= datain[62:0];
> >                         datain[0] <= sdata;
> >                 end
> >                 if (lrclkRise == 1) begin
> >                         leftdata <= datain[63:40];
> >                         rightdata <= datain[31:8];
> >                 end
> >
> > end
> >
> > David wrote:
> >
> > > Hi,
> > > I'm getting an HDL ADVISOR message when I synthesize this code.
> > > Basically, it is a big shift register that shift-in data on each
> > > rising edge of mclk if srclkRise is high, and outputs its data on the
> > > rising edge of mclk if lrclkRise is high. I don't quite understand the
> > > advice here. Can anybody help?
> > > Thanks,
> > > David
> > >
> > > --ADVICE
> > > INFO:Xst:741 - HDL ADVISOR - A 9-bit shift register was found for
> > > signal <datain<8>> and currently occupies 9 logic cells (5 slices).
> > > Removing the set/reset logic would take advantage of SRL16 (and
> > > derived) primitives and reduce this to 1 logic cells (1 slices).
> > > Evaluate if the set/reset can be removed for this simple shift
> > > register. The majority of simple pipeline structures do not need to be
> > > set/reset operationally.
> > >
> > > --CODE
> > > always @ (posedge mclk or negedge resetb)
> > > begin
> > >         if (~resetb) begin
> > >                 datain <= 0;
> > >                 leftdata <= 0;
> > >                 rightdata <= 0;
> > >         end
> > >         else begin
> > >                 if (sclkRise == 1) begin
> > >                         datain[63:1] <= datain[62:0];
> > >                         datain[0] <= sdata;
> > >                 end
> > >                 if (lrclkRise == 1) begin
> > >                         leftdata <= datain[63:40];
> > >                         rightdata <= datain[31:8];
> > >                 end
> > >         end
> > > end
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> >  "They that give up essential liberty to obtain a little
> >   temporary safety deserve neither liberty nor safety."
> >                                           -Benjamin Franklin, 1759
> >
> >

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 74094
Subject: Re: FPGA vs ASIC area
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 04 Oct 2004 01:54:28 GMT
Links: << >>  << T >>  << A >>
austin wrote:

> Configuration of a test pattern can make efficient use of our partial 
> reconfiguration capabilities.  I can not say how many seconds an FPGA 
> spends in the tester, but it is less that an ASIC does.  There also may 
> be much faster ways to configure that we can use, but do not offer to 
> customers.

How long it takes to run the tests is one thing, how long to
design the tests is another.  For a small volume ASIC the
design (human) time could be long amortized over the chips
produced.

-- glen


Article: 74095
Subject: Re: FPGA vs ASIC area
From: austin <austin@xilinx.com>
Date: Sun, 03 Oct 2004 19:34:30 -0700
Links: << >>  << T >>  << A >>
Glen,

One potential advantage we have is that we have been doing this for 20 
years, and testing the interconnect, FFs and LUTs doesn't change that 
much from generation to generation.

Same could be said for an ASIC cell that has been used for the last few 
generations, too (as long as it hasn't changed much).

The overall ASIC functional test vectors are often quite complex.

That leaves time to get clever with paterns.

Austin

glen herrmannsfeldt wrote:
> austin wrote:
> 
>> Configuration of a test pattern can make efficient use of our partial 
>> reconfiguration capabilities.  I can not say how many seconds an FPGA 
>> spends in the tester, but it is less that an ASIC does.  There also 
>> may be much faster ways to configure that we can use, but do not offer 
>> to customers.
> 
> 
> How long it takes to run the tests is one thing, how long to
> design the tests is another.  For a small volume ASIC the
> design (human) time could be long amortized over the chips
> produced.
> 
> -- glen
> 

Article: 74096
Subject: Re: Looking for a Design for a Small FPGA Board
From: daragoth@kuririnmail.com (Daragoth)
Date: 3 Oct 2004 22:10:42 -0700
Links: << >>  << T >>  << A >>
maxfoo <maxfoo@punkassSPAM.com> wrote in message news:<uhlal0l0dqdsess20ijlh2a4i4jh1h4346@4ax.com>...
> Have you looked at the development boards at www.digilent.com
> 
> Xilinx only, but the lowest priced ones I've seen anywhere on the web...

I believe I've looked at those before... the dimensions of the boards
there don't seem to be listed on the website, but from what I can tell
they appear to be too large, unfortunately.

-Darien

Article: 74097
Subject: Uploading data to the DDR memory on the ML300 board
From: ouj <ouj@aludra.usc.edu>
Date: Sun, 3 Oct 2004 22:15:23 -0700
Links: << >>  << T >>  << A >>
Dear all,

I am working on the Xilinx ML300 prototying board. I have a Linux image
that needs to be uploaded to the DDR memroy.

I tried for a few days and was unable to figure out how this can be done.
Can any one kindly give me some hints?

Even if you may not have the board, can you share your experience on how
usually this is done?

Thanks a lot!

Best regards,
Jingzhao

PS: I do know that the data for the on-chip BRAM is initialized through
the bitstream generated using the DATA2BRAM program.


Article: 74098
Subject: Help with old CUPL Ver 4.7A
From: perls@ime.net (RJP)
Date: 3 Oct 2004 22:29:22 -0700
Links: << >>  << T >>  << A >>
Howdy all-


I'm doing some archive work and I am attempting to ressurect an old
version of Logical Devices CUPL Total Designer/WIN V4.7A...
would/could anyone who might have the install disks or install file
set lurking around help me out?

I need three files from or an image of distribution disk #12---

Fit1500.EX_
Espresso.EX_
Flexfit.EX_

Help would be greatly appreciated.

Many thanks


Regards,

Robert

Article: 74099
Subject: Re: M*Blaze in Cyclone ! End of What? ;)
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Mon, 04 Oct 2004 17:32:40 +1000
Links: << >>  << T >>  << A >>
Antti,

Antti Lukats wrote:

 > the M*Blaze/uCLinux has already received first donation offers, but more
 > donations are welcome of course, specially in form of FPGA development
 > hardware.

> PS I am not the author of the open-source M*Blaze, neither is the M*Blaze
> IP-Core downloadable from openchip, the primary download location for the
> M*Blaze IP-Core is the opencores website, project name aeMB.

You are also not the author of a single line of source code in the 
microblaze-uclinux project.  I would appreciate it if you did not make 
comments that could be misunderstood as representing me or any other 
contributor to that project.

There is no such thing as M*Blaze. The author of aeMB has wisely avoided 
any direct reference to Microblaze.  If the Leon core had been called 
SP*RC, it would have lasted about 10 minutes before Sun jumped on it.

Please let the people who do the work, speak for themselves.

Thanks,

John





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