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 117925

Article: 117925
Subject: Simulating LogicCores with Webpack
From: Thomas Heller <theller@python.net>
Date: Fri, 13 Apr 2007 17:11:10 +0200
Links: << >>  << T >>  << A >>
Is it possible to simulate logic cores with WebPack?

I'm using Webpack 9.1.03i.  First I tried the ISE Simulator,
then the free ModelSIM XE/III Starter, and failed with both.

OTOH, I'm not sure that I am doing evenrything correctly...

Thanks,
Thomas

Article: 117926
Subject: Re: SETUP & HOLD time confusion
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 13 Apr 2007 16:36:57 +0100
Links: << >>  << T >>  << A >>
"Newman" <newman5382@yahoo.com> wrote in message 
news:1176476922.900374.236090@b75g2000hsg.googlegroups.com...
> Simulation is a necessary but insufficient for timing.  After
> everything is ready to go, I'll do a sanity check with a full timing
> simulation mainly for primary input stimulus.  I rarely get a timing
> violation, but I cannot say never.
>
Hello Newman,
OK, that's fine, but if you have an example where the post P&R failed the 
timing simulation but the P&R tool static timing said it passed, I'd be 
grateful if you could report it to the FPGA vendor. That would mean the 
design methodology followed by most folks on this newsgroup, myself 
included, is flawed, and something needs to be fixed.
>
> The information I gave is from an
> experience I had over ten years ago.  I found that a hold time
> violation masqueraded as a too long prop delay.
>
Right, but the software's got better in the last ten years. On second 
thoughts, I take your point! :-)

Thanks, Syms.

p.s. I couldn't resist the Seinfeld opening! :-) 



From Iwo.Mergler@soton.sc.philips.com Fri Apr 13 08:55:24 2007
Path: newsdbm05.news.prodigy.net!newsdbm04.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newsfeed.telusplanet.net!newsfeed2.telusplanet.net!newsfeed.telus.net!cycny01.gnilink.net!cyclone1.gnilink.net!gnilink.net!nx02.iad01.newshosting.com!newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.ision.net!newsfeed2.easynews.net!ision!news-lond.gip.net!news.gsl.net!gip.net!lon04-news-philips!53ab2750!not-for-mail
Message-Id: <dol4f4-dbe.ln1@c2968.soton.sc.philips.com>
From: Iwo Mergler <Iwo.Mergler@soton.sc.philips.com>
Subject: Re: No login in uClinux (Petalinux)
Newsgroups: comp.arch.fpga
References: <1176466354.260015.265730@n76g2000hsh.googlegroups.com>
Lines: 45
Organization: Not organised
User-Agent: KNode/0.9.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Date: Fri, 13 Apr 2007 16:55:24 +0100
NNTP-Posting-Host: 161.85.127.140
X-Complaints-To: newsmaster@rain.fr
X-Trace: lon04-news-philips 1176483343 161.85.127.140 (Fri, 13 Apr 2007 16:55:43 GMT)
NNTP-Posting-Date: Fri, 13 Apr 2007 16:55:43 GMT
Xref: prodigy.net comp.arch.fpga:129559

Pablo wrote:

> Is there some method to avoid "login prompt"?. The reason is that I
> have designed an application over uClinux and I want that this app run
> without introducing any information. Could I edit some inittab file?
> 
> Thanks

Hi Pablo,

there are several ways, depending on what your root
file system and init procedure is like.

I'm guessing you are using a initrd (RAM/ROM) file system.
In this case, the first thing the kernel does is executing
/linuxrc

Now, /linuxrc can be a shell script or a link to an
executable, typically /sbin/init

To answer your question, simply create a link from your
application to /linuxrc and your application is the
first thing to run after boot.

However, there are a few things to think about. If you
run an application from a shell, the shell will have
set up some environmental variable, command line options,
and so on. If you run your application directly, this
won't be the case.

If you find that your application doesn't like it,
you can always change /linuxrc into a shell script
and launch your application from there.

Another option is, as you said, edit /etc/inittab.
/etc/inittab is read by /sbin/init. You can place
your application in this file, instead of the
getty which is normally used. This would have the
advantage that you can respawn your application,
in case it exits or crashes.

Kind regards,

Iwo


Article: 117927
Subject: Re: Spartan 3E Not enough block ram.
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Fri, 13 Apr 2007 12:33:48 -0400
Links: << >>  << T >>  << A >>
Ken Soon wrote:
>> Adding output registers is simple...
>>
>> if rising_edge(clk) then
>>    memout_d1 <= memout;
>>    memout_d2 <= memout_d1;
>>    memout_d3 <= memout_d2;
>>    ...
>> end if;
>>
>> You could add a generic port to your memory template to automatically
>> generate these delays to keep your upper-level HDL clean.
>>
> Hmm...
> I dun suppose you mean by this way? :
> 
> begin
>    process (wr_clk)
>    begin
>       if (wr_clk'event and wr_clk = '1') then
>          if (ce = '1') then
>             if (wr_en = '1') then
>      din2 <= din;
>      din3 <= din2;
>                mem_array(conv_integer('0' & wr_addr)) <= din3;
>             end if;
>          end if;
>       end if;
>    end process;

If you delay the write data, you should also delay the write address 
otherwise you will have problems. Registers on the write would be mostly 
there to reduce the fanout, you probably do not need more than one extra 
input register here. (for data, address and enable since all three need to 
be equally delayed)

So, your write process (using your coding style) would resemble this:

process (wr_clk)
begin
   if (wr_clk'event and wr_clk = '1') then
     -- first determine if something needs to be written on the next cycle
     -- register duplication will be applied to these if necessary
     if (ce = '1') then
       wr_en1   <= wr_en;
       wr_addr1 <= wr_addr;
       din1     <= din;
     else
       wr_en1   <= '0';
     end if;

     -- then do the actual write
     if (wr_en1 = '1') then
       mem_array(conv_integer('0' & wr_addr1)) <= din1;
     end if;
   end if;
end process;


>    process (rd_clk)
>    begin
>       if (rd_clk'event and rd_clk = '1') then
>          if (ce = '1') then
>             if (rd_en = '1') then
>                dout3 <= mem_array(conv_integer('0' & rd_addr));
>      dout2 <= dout3;
>      dout <= dout2;
>             end if;
>          end if;
>       end if;
>    end process;

You probably do not want to put the delays within your enable block... and 
like the write, you probably want one register level on the address. With 
both tweaks, the process should look like this:

process (rd_clk)
begin
   if (rd_clk'event and rd_clk = '1') then
     if (ce = '1') then
       rd_en1   <= rd_en;
       rd_addr1 <= rd_addr;
     else
       rd_en1   <= '0';
     end if;

     if (rd_en1 = '1') then
       dout2 <= mem_array(conv_integer('0' & rd_addr1));
     end if;

     dout1 <= dout2;
     dout  <= dout1;
   end if;
end process;

> Oh yah, I went to use the FPGA editor. I found that this time, luckily, the
> 3 timing constraints all came from one CLB, so I can easily just focus on
> this CLb.  I thought of shifting up the CLB closer to its sources/
> destinations and thereby shortening the route. But then... the timing delays
> increased and subsequent shifting did not even change the timing constraint
> by a bit not matter where i shift above the original position.

Your slow paths probably were your clock/read/write-enables since you did 
not decouple the enable signal from the rest of the logic. The modified 
read/write processes in this message should fix this.

> Another engineer told me that it could have help as the route could have
> buffers which would have delay the signals so I had hope that it would work
> but alas it didn't.

When you have signals with large fan-outs and you do pipelining, you need 
to decouple your enable signals to keep fan-outs on enables in check. If 
you look at the two processes, you can see that I did this by combining all 
  incoming enables to generate a single-signal enable for the following 
pipeline stage.

> Now I wondering if my adding of the register levels is wrong. Well, I should
> hope that it is wrong huh, would mean still got chance...

Since you are new to FPGAs, it is normal that you are not (yet) familiar 
with the fundamentals of working around common design issues... but most of 
these you should be able to deduce by reading your static timing analysis 
and thinking about the simplest ways to fix the problems it reveals.

Article: 117928
Subject: Order of the synchronous operations
From: dalai lamah <antonio12358@hotmail.com>
Date: Fri, 13 Apr 2007 17:58:17 GMT
Links: << >>  << T >>  << A >>
Consider the very simple VHDL code at the end of the message. For each
clock cycle two operations are done:

1) A counter is incremented;
2) The bit 0 of the counter is checked. If it's '0', an output flag is
triggered.

If you simulate the post-translated model of this module with the ModelSim
starter edition shipped with the last WebPack, the behaviour is correct (or
at least is what I expect to be): the flag is triggered at the very first
clock cycle. When you exit from reset CNT is zero, so that at the first
clock its first bit is zero too.
If you instead simulate the behavioural model (i.e. plain VHDL) of the same
module, the flag is triggered at the *second* clock! Apparently the
simulator considers the increment operation as it were synchronous, so that
when CNT(0) is checked, it has already the value 1. In fact, if you put the
increment statement *after* the if statement, the behaviour changes again
and the flag is correctly triggered at the first clock.

My question is quite simple: is this a simulator bug, or did I always
misintepreted the synchronous circuits at their own very basic level?

Thank you!




library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity test is
    Port ( CLK : in  STD_LOGIC;
           O : out  STD_LOGIC;
           RESET : in  STD_LOGIC);
end test;

architecture Behavioral of test is
begin
	main: process( CLK, reset)
		variable CNT: std_logic_vector(15 downto 0);
	begin
		if RESET='1' then
			CNT := X"0000";
			O <= '0';
		elsif CLK='1' and CLK'event then
			CNT := CNT+1;		
			if CNT(0)='0' then
				O <= '1';
			end if;
		end if;
	end process;
end Behavioral;

-- 
emboliaschizoide.splinder.com

Article: 117929
Subject: Re: Which are the best books about CORDIC algorithms and applications
From: Walter Dvorak <use-reply-to@invalid.invalid>
Date: Fri, 13 Apr 2007 18:02:44 +0000 (UTC)
Links: << >>  << T >>  << A >>
Weng Tianxiang <wtxwtx@gmail.com> wrote:
> Which is the best book about CORDIC algorithms?

	my recommondation:

	Jean-Michel Muller: "Elementary Functions" - Algorithms and Implementation.
Birkäuser 2006, ISBN 0-8176-4372-9

	Covers different shift-and-add algos like cordic or BKM in detail...

WD
-- 

Article: 117930
Subject: Re: Order of the synchronous operations
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Fri, 13 Apr 2007 15:11:25 -0400
Links: << >>  << T >>  << A >>
dalai lamah wrote:
> Consider the very simple VHDL code at the end of the message. For each
> clock cycle two operations are done:
> 
> 1) A counter is incremented;
> 2) The bit 0 of the counter is checked. If it's '0', an output flag is
> triggered.
> 
> If you simulate the post-translated model of this module with the ModelSim
> starter edition shipped with the last WebPack, the behaviour is correct (or
> at least is what I expect to be): the flag is triggered at the very first
> clock cycle. When you exit from reset CNT is zero, so that at the first
> clock its first bit is zero too.
> If you instead simulate the behavioural model (i.e. plain VHDL) of the same
> module, the flag is triggered at the *second* clock! Apparently the
> simulator considers the increment operation as it were synchronous, so that
> when CNT(0) is checked, it has already the value 1. In fact, if you put the
> increment statement *after* the if statement, the behaviour changes again
> and the flag is correctly triggered at the first clock.
> 
> My question is quite simple: is this a simulator bug, or did I always
> misintepreted the synchronous circuits at their own very basic level?

Variable assignments are processed sequentially while signal assignments 
are processed synchronously... at least in principle. Since 'CNT' is a 
variable, it incrementation becomes effective immediately and the check 
done after the incrementation occurs on the incremented value.

If you used a signal instead, the test would happen on the CNT value that 
was in effect before the process was evaluated - signal assignments become 
effective after an event's processing (re-evaluate all affected processes) 
is completed.

With the code you posted, the correct behavior is for the flag to be set on 
the first cycle... and if you put the increment after the test, the correct 
behavior becomes the flag being set on the second cycle. If you used a 
signal instead of a variable, the test result would be independent from its 
position relative to assignment operations since the test would be done on 
inputs as of the moment the process' evaluation was triggered - the 
previous cycle's output.

Since not all synthesis and simulation tools agree on how to deal with 
variables in synthesizable code, some weird bugs can come up so it is 
generally better to use signals which more closely (less ambiguously) 
represents how synchronous hardware works.

Article: 117931
Subject: Re: Which are the best books about CORDIC algorithms and applications
From: Ray Andraka <ray@andraka.com>
Date: Fri, 13 Apr 2007 15:38:57 -0400
Links: << >>  << T >>  << A >>
Weng Tianxiang wrote:
> On Apr 12, 9:24 am, "Ben Jones" <ben.jo...@xilinx.com> wrote:
> 
>>"Weng Tianxiang" <wtx...@gmail.com> wrote in message
>>
>>news:1176392513.597727.256450@d57g2000hsg.googlegroups.com...
>>
>>
>>>Thank you for your pointing to Ray Andraka website.
>>>I have read his paper, a very nice paper. I will print all references
>>>in his paper too. But I am afraid that the paper was published 1998,
>>>almost 9 years ago and there must have been new progresses on this
>>>topics.
>>
>>Not necessarily. All the books on my reference shelf I refer to most often
>>are >10 years old. :-)
>>
>>CORDIC was a great way to do many DSP functions before FPGAs with dedicated
>>fast low-power multipliers came along. Nowadays, a lot of its advantages are
>>waning. However, it's still a fascinating and elegant idea and worthy of
>>study (certainly I keep meaning to learn more about it!).
>>
>>I'd definitely start by absorbing all that Ray has to say on the subject,
>>then go from there.
>>
>>    -Ben-
> 
> 
> Hi Ben,
> I have read Ray paper and went to his website and read "How to
> calculate sine()". After reading I still have difficulties
> understanding its process.
> 
> Can you give an example on how to calculate sine(x), where x = 35
> degrees?
> 
> I don't understand why he could calculate the factor K before starting
> calculation. Because during calculating, one doesn't know how many
> iterations should be taken to reach required accuracy.
> 
> Thank you.
> 
> Weng
> 

Weng,

First, thanks for looking at my paper.  I'm not aware of much research 
on the CORDIC algorithm itself.  There are a fair amount of applications 
papers that are using CORDIC in order to help solve problems, but 
nothing as far as I know regarding the algorithm itself.

There also are not a lot of books that devote much attention to CORDIC, 
although I suppose there are more now than there were when I wrote that 
paper.  THere are a few books where I've seen a section on CORDIC.  I 
think Frerking's Digital Communications (also ~10 years old now) has a 
section, as does Meyer-Baese's DSP with FPGAs.  I don't think either has 
much more information than I have in my paper though.

Regarding the algorithm, the accuracy of the result is a function of the 
number of iterations you perform.  Generally speaking, you compute the 
number of iterations required to meet the accuracy specification for 
your application and that becomes a system constant.  From there, you 
compute K to determine the exact gain of your design in that 
application.  In short, you do know how many iterations you are going to 
go before doing the calculation.  Roughly speaking, the magnitude output 
for a vectoring CORDIC improves by two bits for each iteration.  Phase 
output improves by one bit per iteration, and for rotation mode, the I 
and Q output accuracy improves by 1 bit per iteration.

Article: 117932
Subject: Re: Which are the best books about CORDIC algorithms and applications
From: Ray Andraka <ray@andraka.com>
Date: Fri, 13 Apr 2007 15:41:26 -0400
Links: << >>  << T >>  << A >>
Walter Dvorak wrote:

> Weng Tianxiang <wtxwtx@gmail.com> wrote:
> 
>>Which is the best book about CORDIC algorithms?
> 
> 
> 	my recommondation:
> 
> 	Jean-Michel Muller: "Elementary Functions" - Algorithms and Implementation.
> Birkäuser 2006, ISBN 0-8176-4372-9
> 
> 	Covers different shift-and-add algos like cordic or BKM in detail...
> 
> WD


I think the treatment in Frerking as well as that in Meyer-Baese is mor 
readable.  Muller has a more complete treatise, but it is a difficult 
read comparatively speaking.

Article: 117933
Subject: Re: Which are the best books about CORDIC algorithms and applications
From: Ray Andraka <ray@andraka.com>
Date: Fri, 13 Apr 2007 15:45:16 -0400
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:

> On 12 Apr 2007 12:40:55 -0700, "Weng Tianxiang" 
> <wtxwtx@gmail.com> wrote:
> 
> 
>>I have read Ray paper and went to his website and read "How to
>>calculate sine()". After reading I still have difficulties
>>understanding its process.
>>
>>Can you give an example on how to calculate sine(x), where x = 35
>>degrees?
>>
>>I don't understand why he could calculate the factor K before starting
>>calculation. Because during calculating, one doesn't know how many
>>iterations should be taken to reach required accuracy.
> 
> 
> Ah, but that's not so.  The whole point about CORDIC is that
> you *do* know in advance how many iterations it takes.
> You *never* stop the iterations early.
> 
> Having said that... the fudge-factor K reaches an asymptote
> so quickly that the error (for any number of iterations greater
> than about 10) is negligibly small.
> 
> I'll try an explanation... be sure to read it in a
> monospaced (Courier etc) font.
> 
> I can rotate a vector (x,y) through any angle A, giving a 
> rotated vector (x', y'),  by using the matrix multiplication
> 
>  / x' \     / cos(A)  -sin(A) \     / x \
>  |    |  =  |                 |  *  |   |
>  \ y' /     \ sin(A)   cos(A) /     \ y /
> 
> We can divide both sides of the equation by cos(A)...
> 
>  / x'/cos(A) \     / 1  -tan(A) \     / x \
>  |           |  =  |            |  *  |   |
>  \ y'/cos(A) /     \ tan(A)  1  /     \ y /
> 
> since tan(A) = sin(A)/cos(A).  That works out
> fairly easily as
> 
>  x'/cos(A) = x - y.tan(A)  or  x' = cos(A) * (x - y.tan(A))
>  y'/cos(A) = x.tan(A) + y  or  y' = cos(A) * (x.tan(A) + y)
> 
> Now here comes the cunning part:  Suppose we choose A 
> so that tan(A) is exactly 2^(-N) for some integer N.
> The calculation of x.tan(A) and y.tan(A) is now a 
> simple right shift (division by an exact power of 2).
> Note, too, that you can make the rotation negative
> simply by swapping the + and - operations.
> 
> Of course, to get this we require 
>   A = arctan(2^(-N))
> for some integer N.  For example:
> 
> N=0: A = arctan(1) = 45 degrees
> N=1: A = arctan(0.5) = 26.565... degrees
> N=2: A = arctan(0.25) = 14.036... degrees
> 
> All this would be harmless fun, until Volder (in his 1959
> paper) was able to prove that ANY angle within a certain
> range (roughly +/- 100 degrees) can be expressed as the 
> sum of all these different A, for N=0,1,2....infinity,
> if each of those terms is either added or subtracted
> (i.e. multiplied by +1 or -1).  Of course we don't need
> to go to infinity, but only "far enough" for any given
> accuracy.  To take your 35-degree example:
> 
> start                                     0     ... too small
> add      arctan(1)      0     + 45     = 45     ... too big
> subtract arctan(1/2)   45     - 26.565 = 18.435 ... too small
> add      arctan(1/4)   18.435 + 14.036 = 32.471 ... too small
> add      arctan(1/8)   32.471 +  7.125 = 39.696 ... too big
> subtract arctan(1/16)  39.696 -  3.576 = 36.120 ... too big
> ...
> 
> and after, let's say, 16 such steps you will have converged 
> on your desired 35 degree angle to within about 0.002%.
> Of course, you pre-calculate all these arctan angles and
> store them in a little lookup table.
> 
> Meanwhile, as you have been adding and subtracting these
> angles you have also been doing the matrix multiplication
> (in the right direction at each step, of course).
> If you started with x = 1.00000 and y = 0, then
> by the time you have finished, the final x and y values
> will be the cosine and sine of your desired angle
> BUT they will also have been multiplied by all the
> 1/cos(A) factors at each step.  So you get a
> scaling (the CORDIC gain) of
> 
>   1/cos(arctan(1)) * 1/cos(arctan(0.5)) * ...
> 
> Try it on a spreadsheet; you'll find this value very
> quickly converging on the limit value 1.646760258.
> To fix this problem, all you need to do is start with
> x=0.607252935...  instead of 1.00000.
> 
> SUCH a pretty algorithm... but, as others have said,
> in these days of fast, cheap multipliers it's not
> so useful as it once was.


CORDIC still is hard to beat for extracting magnitude and phase.  It's 
advantage is much less clear for phase rotators,e.g. mixers where there 
are plentiful fast multipliers on the FPGA.  It is also still useful 
when you need a phase resolution on a rotator of more than about 2^12 
revolutions, as the Sin/Cos lut starts getting unwieldy or needing more 
complicated interpolation to get the resolution.

Article: 117934
Subject: SoC
From: "M Ihsan Baig" <mirzamihsan@hotmail.com>
Date: 13 Apr 2007 12:48:50 -0700
Links: << >>  << T >>  << A >>
Hi experts,
I want to persue my PhD in SoC , would you tell me best institutes or
research goroups in Europe in this area.
Thanks,
Baig


Article: 117935
Subject: Re: has anyone used mathstar field programmable object arrays?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 13 Apr 2007 15:49:45 -0400
Links: << >>  << T >>  << A >>

unless their tools have improved very significantly in the past couple 
years, I think you are going to be dissappointed with the amount of 
detail work you are going to need to do.  Their tools are not in the 
same league as Xilinx and Altera.  It is much more like working in the 
old Xilinx XDS back around 1990 (much like doing the design under 
today's FPGA Editor).

Article: 117936
Subject: Re: Which are the best books about CORDIC algorithms and applications
From: Eric Smith <eric@brouhaha.com>
Date: 13 Apr 2007 12:53:05 -0700
Links: << >>  << T >>  << A >>
Weng Tianxiang wrote:
> Which is the best book about CORDIC algorithms?

Walter Dvorak wrote:
> my recommondation:
> 
> Jean-Michel Muller: "Elementary Functions" - Algorithms and Implementation.
> Birkäuser 2006, ISBN 0-8176-4372-9

I second that.  It's an excellent book.  Although there are other
good sources of information on CORDIC, this book had the best explanations
I've seen for CORDIC algorithms (including many variations) and other
shift-and-add algorithms (e.g., e^x, ln).

There was an earlier edition, so if you buy it used, you may want to
make sure you get the 2006 edition.

Article: 117937
Subject: Distributor stock (was Re: spartan 3e availability)
From: Eric Smith <eric@brouhaha.com>
Date: 13 Apr 2007 13:07:53 -0700
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Distributors have been squeezed pretty hard by price conscious
> customers:  there is no such thing as shelf stock any longer.  It is all
> "virtual stock."

I understand the reason, but it still seems to me that local
distributors aren't providing nearly the value add that they did back in
the good old days.  It used to be that if I urgently needed a part (and
it wasn't too exotic), there was a reasonable chance that I could order
it from a local distributor for will call, and pick it up later the same
day, because they did have shelf stock.

On the other hand, back then we didn't have overnight and two-day
shipping options.  If the part had to be shipped from another
distributor location, it would take a week, and if it had to be ordered
from the factory, it would take at least two weeks.

Nowdays, I buy everything I can from Digikey and Mouser, and my general
rule of thumb is that if they don't have it in stock, it doesn't really
exist.  Of course, as with any rule of thumb, there are exceptions.
Digikey doesn't seem to stock the latest Xilinx parts or development
boards.  Is that because they don't want to stock them, or because they
aren't able to get them from Xilinx?

Anyhow, from the manufacturer's perspective, wasn't the main purpose of
a network of distributors that the stock would be closer to the
customers, and the manufacturer wouldn't have to deal with small orders?
Otherwise what's the point?  If the manufacturer is going to drop-ship
orders anyhow, and the distributor can't/won't accept orders for less
than the minimum order quantity, the manufacturer might as well cut out
the middleman.

Eric

Article: 117938
Subject: Re: Which are the best books about CORDIC algorithms and applications
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 13 Apr 2007 13:38:13 -0700
Links: << >>  << T >>  << A >>
On Apr 12, 3:32 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On 12 Apr 2007 12:40:55 -0700, "Weng Tianxiang"
>
> <wtx...@gmail.com> wrote:
> >I have read Ray paper and went to his website and read "How to
> >calculate sine()". After reading I still have difficulties
> >understanding its process.
>
> >Can you give an example on how to calculate sine(x), where x = 35
> >degrees?
>
> >I don't understand why he could calculate the factor K before starting
> >calculation. Because during calculating, one doesn't know how many
> >iterations should be taken to reach required accuracy.
>
> Ah, but that's not so.  The whole point about CORDIC is that
> you *do* know in advance how many iterations it takes.
> You *never* stop the iterations early.
>
> Having said that... the fudge-factor K reaches an asymptote
> so quickly that the error (for any number of iterations greater
> than about 10) is negligibly small.
>
> I'll try an explanation... be sure to read it in a
> monospaced (Courier etc) font.
>
> I can rotate a vector (x,y) through any angle A, giving a
> rotated vector (x', y'),  by using the matrix multiplication
>
>  / x' \     / cos(A)  -sin(A) \     / x \
>  |    |  =  |                 |  *  |   |
>  \ y' /     \ sin(A)   cos(A) /     \ y /
>
> We can divide both sides of the equation by cos(A)...
>
>  / x'/cos(A) \     / 1  -tan(A) \     / x \
>  |           |  =  |            |  *  |   |
>  \ y'/cos(A) /     \ tan(A)  1  /     \ y /
>
> since tan(A) = sin(A)/cos(A).  That works out
> fairly easily as
>
>  x'/cos(A) = x - y.tan(A)  or  x' = cos(A) * (x - y.tan(A))
>  y'/cos(A) = x.tan(A) + y  or  y' = cos(A) * (x.tan(A) + y)
>
> Now here comes the cunning part:  Suppose we choose A
> so that tan(A) is exactly 2^(-N) for some integer N.
> The calculation of x.tan(A) and y.tan(A) is now a
> simple right shift (division by an exact power of 2).
> Note, too, that you can make the rotation negative
> simply by swapping the + and - operations.
>
> Of course, to get this we require
>   A = arctan(2^(-N))
> for some integer N.  For example:
>
> N=0: A = arctan(1) = 45 degrees
> N=1: A = arctan(0.5) = 26.565... degrees
> N=2: A = arctan(0.25) = 14.036... degrees
>
> All this would be harmless fun, until Volder (in his 1959
> paper) was able to prove that ANY angle within a certain
> range (roughly +/- 100 degrees) can be expressed as the
> sum of all these different A, for N=0,1,2....infinity,
> if each of those terms is either added or subtracted
> (i.e. multiplied by +1 or -1).  Of course we don't need
> to go to infinity, but only "far enough" for any given
> accuracy.  To take your 35-degree example:
>
> start                                     0     ... too small
> add      arctan(1)      0     + 45     = 45     ... too big
> subtract arctan(1/2)   45     - 26.565 = 18.435 ... too small
> add      arctan(1/4)   18.435 + 14.036 = 32.471 ... too small
> add      arctan(1/8)   32.471 +  7.125 = 39.696 ... too big
> subtract arctan(1/16)  39.696 -  3.576 = 36.120 ... too big
> ...
>
> and after, let's say, 16 such steps you will have converged
> on your desired 35 degree angle to within about 0.002%.
> Of course, you pre-calculate all these arctan angles and
> store them in a little lookup table.
>
> Meanwhile, as you have been adding and subtracting these
> angles you have also been doing the matrix multiplication
> (in the right direction at each step, of course).
> If you started with x = 1.00000 and y = 0, then
> by the time you have finished, the final x and y values
> will be the cosine and sine of your desired angle
> BUT they will also have been multiplied by all the
> 1/cos(A) factors at each step.  So you get a
> scaling (the CORDIC gain) of
>
>   1/cos(arctan(1)) * 1/cos(arctan(0.5)) * ...
>
> Try it on a spreadsheet; you'll find this value very
> quickly converging on the limit value 1.646760258.
> To fix this problem, all you need to do is start with
> x=0.607252935...  instead of 1.00000.
>
> SUCH a pretty algorithm... but, as others have said,
> in these days of fast, cheap multipliers it's not
> so useful as it once was.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

Hi Jonathan,
Thank you very much for you explanation. Very excellent
explanation !!!

This is second time for me to get your help. The first time was when I
was programming a random generation circuit copying your post in this
group.

Weng


Article: 117939
Subject: Re: Which are the best books about CORDIC algorithms and applications
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 13 Apr 2007 13:39:54 -0700
Links: << >>  << T >>  << A >>
On Apr 13, 11:02 am, Walter Dvorak <use-reply...@invalid.invalid>
wrote:
> Weng Tianxiang <wtx...@gmail.com> wrote:
> > Which is the best book about CORDIC algorithms?
>
>         my recommondation:
>
>         Jean-Michel Muller: "Elementary Functions" - Algorithms and Imple=
mentation.
> Birk=E4user 2006, ISBN 0-8176-4372-9
>
>         Covers different shift-and-add algos like cordic or BKM in detail=
.=2E.
>
> WD
> --

Hi WD,
Thank you for your recommendation. I will review the book and
determine if I buy it.

Weng


Article: 117940
Subject: Re: SoC
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 13 Apr 2007 21:57:14 +0100
Links: << >>  << T >>  << A >>
On 13 Apr 2007 12:48:50 -0700, "M Ihsan Baig"
<mirzamihsan@hotmail.com> wrote:

>I want to persue my PhD in SoC , would you tell me best institutes or
>research goroups in Europe in this area.

IMEC in Leuven, Belgium?
ISLI in Livingston, Scotland?
And plenty more, I'm sure.  Take a look at the proceedings
of FDL (European near-equivalent of DVCon) to see who is
most active in your area of interest.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 117941
Subject: Re: Order of the synchronous operations
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 13 Apr 2007 22:09:42 +0100
Links: << >>  << T >>  << A >>
On Fri, 13 Apr 2007 17:58:17 GMT, dalai lamah
<antonio12358@hotmail.com> wrote:

>Consider the very simple VHDL code at the end of the message. For each
>clock cycle two operations are done:
>
>1) A counter is incremented;
>2) The bit 0 of the counter is checked. If it's '0', an output flag is
>triggered.

Not after reset, though.  After reset, your output flag is
stuck at zero.

>If you simulate the post-translated model of this module with the ModelSim
>starter edition shipped with the last WebPack, the behaviour is correct (or
>at least is what I expect to be): the flag is triggered at the very first
>clock cycle. When you exit from reset CNT is zero, so that at the first
>clock its first bit is zero too.

Really?  That sounds wrong to me.

>If you instead simulate the behavioural model (i.e. plain VHDL) of the same
>module, the flag is triggered at the *second* clock! Apparently the
>simulator considers the increment operation as it were synchronous, so that
>when CNT(0) is checked, it has already the value 1. 

Exactly as it should.

> In fact, if you put the
>increment statement *after* the if statement, the behaviour changes again
>and the flag is correctly triggered at the first clock.

Also exactly as it should.

>My question is quite simple: is this a simulator bug, 

Not in the behavioural case.

> or did I always misintepreted the
> synchronous circuits at their own very basic level?

As Daniel S. said, it's not "basic" - people often get 
confused about the behaviour of variables in VHDL 
clocked processes.  The action of the behavioural VHDL
that you describe is exactly as it should be.  The
question that needs answering is: why does the post-
synthesis simulation not match it?  On the first
clock after reset, CNT:=CNT+1 immediately updates
CNT to X"0001".  Consequently the assignment to O
does not happen.  On the next clock, though, CNT
is incremented to X"0002" and O should be set.
Immediately after the assignment CNT:=CNT+1,
the variable CNT represents the next-state value
of CNT - in other words, the value presented to
the D-inputs of the CNT register.  Output O should
be synchronously set if this next-state value has
'0' in its LSB.  If your observation is correct,
then the Xilinx simulation or place-and-route
tools are in error and you should raise a bug report.

>	main: process( CLK, reset)
>		variable CNT: std_logic_vector(15 downto 0);
>	begin
>		if RESET='1' then
>			CNT := X"0000";
>			O <= '0';
>		elsif CLK='1' and CLK'event then
>			CNT := CNT+1;		
>			if CNT(0)='0' then
>				O <= '1';
>			end if;
>		end if;
>	end process;
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 117942
Subject: Re: Which are the best books about CORDIC algorithms and applications
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 13 Apr 2007 22:21:47 +0100
Links: << >>  << T >>  << A >>
On Fri, 13 Apr 2007 15:45:16 -0400, 
Ray Andraka <ray@andraka.com> wrote:

>CORDIC [...] is also still useful 
>when you need a phase resolution on a rotator of more than about 2^12 
>revolutions, as the Sin/Cos lut starts getting unwieldy or needing more 
>complicated interpolation to get the resolution.

I'm not entirely sure I understand this, since you can rather easily
extract any derivative of sin/cos from a sin/cos lookup table with
the help of a multiplier.  For example, if I have a sin/cos LUT 
with 2^10/rev precision, can't I get sin/cos to nearly 2^20
precision with only one first-order interpolation?  I agree that
it's not so hardware-friendly a calculation as a CORDIC step,
but it seems to offer much more bang per buck if you have hardware
multipliers to hand.

Having said that, I probably should have done the sums before
writing this post :-)
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 117943
Subject: Re: Distributor stock (was Re: spartan 3e availability)
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 13 Apr 2007 14:33:06 -0700
Links: << >>  << T >>  << A >>
Eric,

I agree that the reason behind having stock was to provide the service
of "nearly same day delivery."

But, you are correct, that does not exist anymore, partially because you
(and everyone else) orders on-line, and expects "just in time" delivery.

The business model of a distributor is not what it used to be.

As for your comment: "so what exactly is the middleman providing in
value added?" I will have to let you ask them (I am not an expert in
that at all).

Austin

Article: 117944
Subject: Re: SETUP & HOLD time confusion
From: "M. Hamed" <mhs000@gmail.com>
Date: 13 Apr 2007 16:16:43 -0700
Links: << >>  << T >>  << A >>
Thank you, Newman, Peter, and Symon. As you have mentioned, I traced
the problem down to a setup time problem reported as hold time
violation. I still don't understand the paragraph in question, and
hopfully Peter will provide the answer.

>OK, that's fine, but if you have an example where the post P&R failed the
>timing simulation but the P&R tool static timing said it passed, I'd be
>grateful if you could report it to the FPGA vendor.

This is very likely to happen if you have functional asynchronous
resets or inferred latches. But as you mentioned, only if you dont
follow proper design guidelines.

/MHS


Article: 117945
Subject: picoblaze C compiler download wanted
From: Eric Smith <eric@brouhaha.com>
Date: 13 Apr 2007 16:35:37 -0700
Links: << >>  << T >>  << A >>
I was hoping to download Francesco Poderico's Picoblaze C compiler
today, but unfortunately his domain is expired.  Google didn't
turn up any other sites from which I can download it; does anyone
know of such a location, or would anyone be willing to make it
available online or send me a copy?  (Provided that doing so
doesn't violate any license terms.)

Thanks!
Eric

Article: 117946
Subject: Re: SETUP & HOLD time confusion
From: "Brian Davis" <brimdavis@aol.com>
Date: 13 Apr 2007 17:38:04 -0700
Links: << >>  << T >>  << A >>
M. Hamed wrote:
>
> I traced the problem down to a setup time problem reported
> as hold time violation. I still don't understand the paragraph
> in question, and hopfully Peter will provide the answer.
>

 In some cases, the particulars of modeling the back annotated
clock & data path delays results in certain simulation 'features'
that can cause the exact location & type of the reported timing
violation to migrate about within the post-PAR simulation model.

 I have listed a few typical Answer Records of that sort below.
(You didn't post the details of your timimg error, so I'm not
suggesting that any of these are your exact problem.)

24220 9.1i Timing - Clock skew master record

24289 9.1i Timing - How does clock skew relate to Hold/Race Checks
functionality?

17224 8.1i Timing Analyzer/TRACE - How does clock skew affect setup/
hold
      calculations? (Hold violation)

11067 SimPrim - ModelSim Simulations: Input and Output clocks of the
      DCM and CLKDLL models do not appear to be de-skewed (VHDL,
Verilog)

18668 7.1i Timing Analyzer/TRCE - Timing tools do not properly adjust
for my
      equivalent positive phase shift

23689 LogiCORE Blk Men Gen v2.1 - Virtex-4, timing simulation fails
due to
      setup time violation in X_SFF

good luck,
Brian


Article: 117947
Subject: Re: No login in uClinux (Petalinux)
From: fpga_toys@yahoo.com
Date: 13 Apr 2007 18:15:57 -0700
Links: << >>  << T >>  << A >>
On Apr 13, 6:12 am, "Pablo" <pbantu...@gmail.com> wrote:
> Is there some method to avoid "login prompt"?. The reason is that I
> have designed an application over uClinux and I want that this app run
> without introducing any information. Could I edit some inittab file?

If you have a dedicated application and do not need the bulk of CLI
tools,
one small, fast, easy solution is to have the application be the
"init" process,
or to have /bin/sh be the init process and stick the startup scriping
in the
shell startup scripts. Do this either by replacing the init binary, or
using
the kernel boot arg overrides init.

This is also a usable "back door" for lost root passwords on most
Linux
systems booted with Lilo/Grub which allow editing the kernel arguments
at boot time.



Article: 117948
Subject: Re: Where is Open Source for FPGA development?
From: fpga_toys@yahoo.com
Date: 13 Apr 2007 18:37:48 -0700
Links: << >>  << T >>  << A >>
On Mar 25, 11:11 pm, "Daniel S."
<digitalmastrmind_no_s...@hotmail.com> wrote:
> While it would certainly be nice to have open-source tools to support FPGA
> development (more options is almost always good for those days where
> ISE&all keep on crashing and burning), the rather small world-wide pool of
> FPGA people with both the programming knowledge and motivation to build and
> maintain this sort of project as volunteers is, unfortunately, almost
> certainly far too small.

Actually, many of the large open source projects are full time staffed
by industry
giants ... for example many of the linux developers have a day job
maintaining
linux for their respective empoyer's hardware platforms ... in IBM,
SUN, HP,
etc ... while also having hat's as core developers in various distro's
as a paid
job. Much of the integration and testing of distro's is also funded
day work, via
contracts ... it's how RedHat engineers get paid.

This is big business, not just volunteer work. The hardware interfaces
into computers
and not "just easy" pieces of code to develop and maintain, and are
loaded with heavy
IP rights ... just like the internal chip interfaces for FPGA's. The
difference is, that
software developers took those interfaces public with open source
operating systems.

If it can work for operating systems and major distro's ... then it
can work in other
industries where there is leadership in open source to obtain
advantages for both
the Corporations and their customers.  So far, Xilinx and Altera are
not taking that
lead ... which should result in a significantly better tool set for
the industry.

As I have suggested before ... places where vendors are crying about
not having
enough funds to support their product lines (IE dropping support for
entire product
lines like the XC4K chips) while new product is on the shelf in
distribution and
production inventory ... could have done that much better by turning
over to a
customer/vendor open source partnership.

We hear frequently here that vendors cann't support anything other
than the top
few dozen customers ... that changes with active open source industry
partnerships
which are lead by industry paid staff.

John


Article: 117949
Subject: Re: Where is Open Source for FPGA development?
From: "jbnote" <jbnote@gmail.com>
Date: 13 Apr 2007 23:59:56 -0700
Links: << >>  << T >>  << A >>
I'd guess FPGA vendors are certainly not unaware of the advantages of
the opensource model.

I think that the problem for them is twofold:

1/ for old chips, netlists could be reverse-engineered from bitstream
easily with the chip specs. This would be a major blow to some FPGA
users.

2/ for newer chips, even with strong crypto and/or eeproms available
on all chip lines to prevent bitstream reversing, the major problem
would be to still allow selling closed IP components for the platform.
There's no solution to this problem -- it simply is unsolvable from an
information theory standpoint. The only thing possible would be to
change the business model, and I guess this is not likely to happen
anytime soon.

The change won't come from the most established FPGA vendor, that's
for sure -- maybe the contender could do something about it, though...

JB




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