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 159325

Article: 159325
Subject: Vivado HLS (C/C++/SystemC to ASIC/FPGA)
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 6 Oct 2016 03:22:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
Does anybody have experience with Vivado HLS?

     https://www.xilinx.com/products/design-tools/vivado/integration/esl-design.html

This tool is very similar to the internal processes I have planned for
my Logician tool.

Best regards,
Rick C. Hodgin

Article: 159326
Subject: Re: How do I preserve Hazard safety terms?
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 6 Oct 2016 04:55:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, October 5, 2016 at 11:17:22 PM UTC-4, Johann Klammer wrote:
> On 10/06/2016 03:41 AM, KJ wrote:
> >=20
> > I have no idea what tool you are using, but you'll need to look into
> > the tool specific way to preserve signals.
> >=20
> > Kevin Jennings
> >=20
> It's not about a signal, but a (redundant) term getting lost during the
> simplification (in abc here: <https://bitbucket.org/alanmi/abc>)
> That is, the term is redundant w.r.t logic, but not in terms of timing(gl=
itches).=20
> Searching for `hazard' in the repository (.c files) does not give a match=
.=20
> There are methods in there to find muxen, so maybe sthg can be cobbled=20
> together from that.=20
> But before doing that I'd rather ask here if I've missed something, or
> maybe there's something similar wot can do this already.

It's a tool specific attribute that will need to be attached to the signals=
 in order to preserve the logic as you've written.

Why do you think you need to prevent a glitch in the first place?  If it's =
because the signal is going to the input of an edge sensitive device, then =
you've got a bigger problem, you should not be using internally generated c=
lock signals or, even worse, internally generated by logic (as opposed to t=
he output of a flip flop).  Unless this is a homework assignment, I strongl=
y suspect you're trying to solve the wrong problem by searching for the met=
hod to prevent optimization that removes logic cover terms.

Kevin Jennings

Article: 159327
Subject: Re: How do I preserve Hazard safety terms?
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Thu, 06 Oct 2016 15:29:09 +0200
Links: << >>  << T >>  << A >>
On 10/06/2016 10:53 AM, rickman wrote:
> 
> I may be way off base here, but I think this is something that is not
> applicable to FPGAs.  FPGAs use a LUT for logic.  This is exactly
> equivalent to the Karnaugh map table that is filled in with 1s and
> 0s. Notice I didn't say anything about grouping terms for
> simplification. That is because none of that is needed when you have
> such a table. Since there is no grouping of terms, preserving term
> groups is meaningless.
> 
> Are you intending for the logic to generate multiple LUTs with these
> terms separate and another LUT to OR them together?
> 
> I can't say for sure about every FPGA family, but Xilinx has
> indicated they design the muxes in their LUTs to be hazard proof for
> the problem you are trying to prevent.  They do this by the use of
> transmission gates rather than logic.  As the transmission gates turn
> off and on, the capacitance of the output line keeps the present
> value until the next transmission gate turns on driving the output to
> the new value.  If the old and new values are the same, no glitch
> guaranteed.
> 
> Does this address your concerns?
> 
1) I'm targeting a PLD. 
2) cda has hazard.c which does that. 
3) It targets PLDs too. 
4) So it's probably useful here. 
5) There is no pld group. 



Article: 159328
Subject: Re: xilinx aurora lane order
From: Allan Herriman <allanherriman@hotmail.com>
Date: 06 Oct 2016 14:19:42 GMT
Links: << >>  << T >>  << A >>
On Thu, 06 Oct 2016 01:40:32 -0700, colin wrote:

> Guys
> 
> I have two FPGAs with 4 MGTs connected between them using Aurora. The
> firmware guy has insisted (and I've taken a quick look myself) that we
> cannot define the link order. This means that I have to layout the PCB
> with the MGTs crossing over each other.
> 
> Really?
> 
> I can't easily ask Xilinx directly because it is the firmware guys
> responsibility hence my post here.
> Does anyone here know whether this is definitely the case or not?
> 
> Sorry to use google to post this. I am certain that making a technical
> request to an admin dept run by HP in India to allow me proper usenet
> access will not succeed.


I have had similar issues with different interfaces that used multiple 
transceiver channels bonded.  In my case, I could specify any order I 
wanted just by changing the pin numbers for the various transceivers in 
the constraints file.
I understand that the internal connections between the transceivers and 
the core go via regular FPGA fabric, and as such you should be able to 
swap the transceivers around (unless operating at high clock rates, which 
might make it difficult to route to speed if you choose some wildly sub-
optimal ordering).

It ought to be pretty quick to test that in whatever tool you're using - 
just change the pinout and see if it builds.


I guess you also have DC blocking caps on the transceiver signals.  This 
implies that you'll have vias on the traces (to get them to an outer 
layer), which makes it pretty easy to swap the pairs around on the PCB if 
you can't get the FPGA tools to cooperate.

Allan

Article: 159329
Subject: Re: Vivado HLS (C/C++/SystemC to ASIC/FPGA)
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 6 Oct 2016 07:34:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, October 6, 2016 at 6:22:32 AM UTC-4, Rick C. Hodgin wrote:
> Does anybody have experience with Vivado HLS?
> 
>      https://www.xilinx.com/products/design-tools/vivado/integration/esl-design.html
> 
> This tool is very similar to the internal processes I have planned for
> my Logician tool.

They have a free 30-day evaluation.  I may find out what hardware I'll
need and schedule a time where I can devote a month to learning more
about this tool:

    https://www.xilinx.com/products/design-tools/vivado.html#buy

My Logician tool plans to be like Blender's node editor, with things
connected graphically like that, with source code and logic contained
within each node.  I have planned on making the source code a subset
of my CAlive language currently under development, with limited support
for local and global variables.

I can see the possibility from watching this video:

    C to FPGA Compilation and Domain-Specific Computing
    https://www.youtube.com/watch?v=TNF8EhKDM1c

...that there exists an interesting potential of analyzing the data
usage, and determining what type of CPU would be be applied to this
application, and in that way creating a literal custom CPU with an
ISA designed for the needs of the tasks, which would allow for a quick
and completely programmable CPU to be custom fabricated per the needs
of each app, ultimately creating heterogeneous cores which run in
massive parallel on a target FPGA for a given application.

Logician would handle the wiring and source code, and the compiler
would handle the details of taking that source design and generating
a workable and viable stand-alone CPU with periphery ties.

This will be my goal with Logician.

Best regards,
Rick C. Hodign

Article: 159330
Subject: Re: xilinx aurora lane order
From: colin <colin_toogood@yahoo.com>
Date: Thu, 6 Oct 2016 07:36:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
Allan

We tried a build by just changing the pinout and it fails. The Aurora wizar=
d has a setting where you tell it the first MGT you want to use and then it=
 uses the consecutive MGTs as required. It "helps" by then locking down whe=
re some of the logic is placed within the FPGA and so meeting timing become=
s impossible if you change MGT locations.

I had hoped our firmware guy had given up on finding a different Aurora wiz=
ard setting because he is busy and it is not a problem he needs to solve.

cheers,=20

Colin

Article: 159331
Subject: Re: How do I preserve Hazard safety terms?
From: rickman <gnuarm@gmail.com>
Date: Thu, 6 Oct 2016 12:49:55 -0400
Links: << >>  << T >>  << A >>
On 10/6/2016 9:29 AM, Johann Klammer wrote:
> On 10/06/2016 10:53 AM, rickman wrote:
>>
>> I may be way off base here, but I think this is something that is not
>> applicable to FPGAs.  FPGAs use a LUT for logic.  This is exactly
>> equivalent to the Karnaugh map table that is filled in with 1s and
>> 0s. Notice I didn't say anything about grouping terms for
>> simplification. That is because none of that is needed when you have
>> such a table. Since there is no grouping of terms, preserving term
>> groups is meaningless.
>>
>> Are you intending for the logic to generate multiple LUTs with these
>> terms separate and another LUT to OR them together?
>>
>> I can't say for sure about every FPGA family, but Xilinx has
>> indicated they design the muxes in their LUTs to be hazard proof for
>> the problem you are trying to prevent.  They do this by the use of
>> transmission gates rather than logic.  As the transmission gates turn
>> off and on, the capacitance of the output line keeps the present
>> value until the next transmission gate turns on driving the output to
>> the new value.  If the old and new values are the same, no glitch
>> guaranteed.
>>
>> Does this address your concerns?
>>
> 1) I'm targeting a PLD.
> 2) cda has hazard.c which does that.
> 3) It targets PLDs too.
> 4) So it's probably useful here.
> 5) There is no pld group.

Yes, if you are using simple PLDs then they work directly with product 
terms and you do need the covering terms for transitions between other 
terms.

I can't help you with your tool.  Is berkeley-abc the tool you are 
using?  What is the source of support?  If you have source code you 
might be able to figure out the input formats.  I expect the front end 
is not so complex.  Still, there *should* be some sort of documentation 
from the same source as the tool.

-- 

Rick C

Article: 159332
Subject: Re: xilinx aurora lane order
From: Allan Herriman <allanherriman@hotmail.com>
Date: 06 Oct 2016 22:04:22 GMT
Links: << >>  << T >>  << A >>
On Thu, 06 Oct 2016 07:36:58 -0700, colin wrote:

> Allan
> 
> We tried a build by just changing the pinout and it fails. The Aurora
> wizard has a setting where you tell it the first MGT you want to use and
> then it uses the consecutive MGTs as required. It "helps" by then
> locking down where some of the logic is placed within the FPGA and so
> meeting timing becomes impossible if you change MGT locations.
> 
> I had hoped our firmware guy had given up on finding a different Aurora
> wizard setting because he is busy and it is not a problem he needs to
> solve.


I suggest asking your question again in this forum:
https://forums.xilinx.com/t5/Networking-and-Connectivity/bd-p/CONN

BTW, An earlier thread in that forum may have the answers you want:
https://forums.xilinx.com/t5/Networking-and-Connectivity/Aurora-8B-10B-in-XC7K325-GTX-pin-assignments/m-p/713409

Regards,
Allan

Article: 159333
Subject: Help with multiplier code
From: Marvin L <user123random@gmail.com>
Date: Thu, 6 Oct 2016 23:19:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi, I am having problem with https://ptpb.pw/4Twc , https://ptpb.pw/UpJX and http://i.imgur.com/wGEVxuL.png

It just could not multiply 2 and 3.  and 3 is never read in. Why ?

Besides, there is timing violation, if I am not wrong, should be due to inefficient multiplier operator *

I searched online and found wallace tree and daddas multiplier.

Any advice ?

Article: 159334
Subject: CORDIC in a land of built-in multipliers
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Thu, 13 Oct 2016 13:46:18 -0500
Links: << >>  << T >>  << A >>
Now that FPGAs have built-in DSP blocks, how commonly is CORDIC used?  Is 
it still a necessary go-to for anyone contemplating doing DSP in an FPGA, 
or is it starting to ease onto the off-ramp of history?

And, putting FPGA use aside -- how common is it is ASICs?

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

Article: 159335
Subject: Re: CORDIC in a land of built-in multipliers
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Thu, 13 Oct 2016 14:03:22 -0500
Links: << >>  << T >>  << A >>
On Thu, 13 Oct 2016 13:46:18 -0500, Tim Wescott wrote:

> Now that FPGAs have built-in DSP blocks, how commonly is CORDIC used? 
> Is it still a necessary go-to for anyone contemplating doing DSP in an
> FPGA,
> or is it starting to ease onto the off-ramp of history?
> 
> And, putting FPGA use aside -- how common is it is ASICs?

Being bad because I'm cross-posting.  Being bad because I'm cross-posting 
a reply to _my own post_.

Oh well -- I'm thinking that maybe some of the folks on comp.dsp who 
aren't also on comp.arch.fpga will have some thoughts.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

Article: 159336
Subject: Re: CORDIC in a land of built-in multipliers
From: Rob Gaddi <rgaddi@highlandtechnology.invalid>
Date: Thu, 13 Oct 2016 20:59:49 -0000 (UTC)
Links: << >>  << T >>  << A >>
Tim Wescott wrote:

> On Thu, 13 Oct 2016 13:46:18 -0500, Tim Wescott wrote:
>
>> Now that FPGAs have built-in DSP blocks, how commonly is CORDIC used? 
>> Is it still a necessary go-to for anyone contemplating doing DSP in an
>> FPGA,
>> or is it starting to ease onto the off-ramp of history?
>> 
>> And, putting FPGA use aside -- how common is it is ASICs?
>
> Being bad because I'm cross-posting.  Being bad because I'm cross-posting 
> a reply to _my own post_.
>
> Oh well -- I'm thinking that maybe some of the folks on comp.dsp who 
> aren't also on comp.arch.fpga will have some thoughts.
>

I've considered it many times, but never used it.  Then again it's not
like I use the DSP blocks for CORDIC sorts of things anyhow; I just
throw a RAM lookup table at the problem.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 159337
Subject: Re: CORDIC in a land of built-in multipliers
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Thu, 13 Oct 2016 16:10:46 -0500
Links: << >>  << T >>  << A >>
On Thu, 13 Oct 2016 20:59:49 +0000, Rob Gaddi wrote:

> Tim Wescott wrote:
> 
>> On Thu, 13 Oct 2016 13:46:18 -0500, Tim Wescott wrote:
>>
>>> Now that FPGAs have built-in DSP blocks, how commonly is CORDIC used?
>>> Is it still a necessary go-to for anyone contemplating doing DSP in an
>>> FPGA,
>>> or is it starting to ease onto the off-ramp of history?
>>> 
>>> And, putting FPGA use aside -- how common is it is ASICs?
>>
>> Being bad because I'm cross-posting.  Being bad because I'm
>> cross-posting a reply to _my own post_.
>>
>> Oh well -- I'm thinking that maybe some of the folks on comp.dsp who
>> aren't also on comp.arch.fpga will have some thoughts.
>>
>>
> I've considered it many times, but never used it.  Then again it's not
> like I use the DSP blocks for CORDIC sorts of things anyhow; I just
> throw a RAM lookup table at the problem.

That was the other thing that I should have mentioned.

I've heard a lot of talk about CORDIC, but it seems to be one of those 
things that was Really Critically Important back when an Intel 4004 cost 
(reputedly) $5 in then-dollars, but maybe isn't so important now, when it 
seems like the package costs more than the silicon inside it.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

Article: 159338
Subject: Re: CORDIC in a land of built-in multipliers
From: rickman <gnuarm@gmail.com>
Date: Thu, 13 Oct 2016 18:14:58 -0400
Links: << >>  << T >>  << A >>
On 10/13/2016 5:10 PM, Tim Wescott wrote:
> On Thu, 13 Oct 2016 20:59:49 +0000, Rob Gaddi wrote:
>
>> Tim Wescott wrote:
>>
>>> On Thu, 13 Oct 2016 13:46:18 -0500, Tim Wescott wrote:
>>>
>>>> Now that FPGAs have built-in DSP blocks, how commonly is CORDIC used?
>>>> Is it still a necessary go-to for anyone contemplating doing DSP in an
>>>> FPGA,
>>>> or is it starting to ease onto the off-ramp of history?
>>>>
>>>> And, putting FPGA use aside -- how common is it is ASICs?
>>>
>>> Being bad because I'm cross-posting.  Being bad because I'm
>>> cross-posting a reply to _my own post_.
>>>
>>> Oh well -- I'm thinking that maybe some of the folks on comp.dsp who
>>> aren't also on comp.arch.fpga will have some thoughts.
>>>
>>>
>> I've considered it many times, but never used it.  Then again it's not
>> like I use the DSP blocks for CORDIC sorts of things anyhow; I just
>> throw a RAM lookup table at the problem.
>
> That was the other thing that I should have mentioned.
>
> I've heard a lot of talk about CORDIC, but it seems to be one of those
> things that was Really Critically Important back when an Intel 4004 cost
> (reputedly) $5 in then-dollars, but maybe isn't so important now, when it
> seems like the package costs more than the silicon inside it.

There are still FPGAs at the lower end that don't include multipliers. 
I have an older design in a small FPGA I am still shipping that does the 
iterative adding thing.  It has been a while since I considered using 
the CORDIC algorithm.  What exactly is the advantage of the CORDIC 
algorithm again?

-- 

Rick C

Article: 159339
Subject: Re: CORDIC in a land of built-in multipliers
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Thu, 13 Oct 2016 17:16:13 -0500
Links: << >>  << T >>  << A >>
On Thu, 13 Oct 2016 18:14:58 -0400, rickman wrote:

> On 10/13/2016 5:10 PM, Tim Wescott wrote:
>> On Thu, 13 Oct 2016 20:59:49 +0000, Rob Gaddi wrote:
>>
>>> Tim Wescott wrote:
>>>
>>>> On Thu, 13 Oct 2016 13:46:18 -0500, Tim Wescott wrote:
>>>>
>>>>> Now that FPGAs have built-in DSP blocks, how commonly is CORDIC
>>>>> used? Is it still a necessary go-to for anyone contemplating doing
>>>>> DSP in an FPGA,
>>>>> or is it starting to ease onto the off-ramp of history?
>>>>>
>>>>> And, putting FPGA use aside -- how common is it is ASICs?
>>>>
>>>> Being bad because I'm cross-posting.  Being bad because I'm
>>>> cross-posting a reply to _my own post_.
>>>>
>>>> Oh well -- I'm thinking that maybe some of the folks on comp.dsp who
>>>> aren't also on comp.arch.fpga will have some thoughts.
>>>>
>>>>
>>> I've considered it many times, but never used it.  Then again it's not
>>> like I use the DSP blocks for CORDIC sorts of things anyhow; I just
>>> throw a RAM lookup table at the problem.
>>
>> That was the other thing that I should have mentioned.
>>
>> I've heard a lot of talk about CORDIC, but it seems to be one of those
>> things that was Really Critically Important back when an Intel 4004
>> cost (reputedly) $5 in then-dollars, but maybe isn't so important now,
>> when it seems like the package costs more than the silicon inside it.
> 
> There are still FPGAs at the lower end that don't include multipliers. I
> have an older design in a small FPGA I am still shipping that does the
> iterative adding thing.  It has been a while since I considered using
> the CORDIC algorithm.  What exactly is the advantage of the CORDIC
> algorithm again?

It uses less gates.  Which is why I'm asking my question -- gates seem to 
be a lot cheaper these days, so do people still use CORDIC?

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

Article: 159340
Subject: Re: FPGA LABVIEW programming
From: gyansorova@gmail.com
Date: Thu, 13 Oct 2016 17:51:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, August 2, 2006 at 3:16:13 AM UTC+12, john wrote:
> Hello,
> National instruments has introduced new module in their labview 8 for
> programming the xilinx FPGA chips. It converts the labview programs
> into VHDL . It can borrow image processing libraries from the labview
> too. I was wondering that if somebody has used this module form labview
> 
> can give me details about it. 
> Thanks 
> Regards 
> John

Pretty damned good now I would say. One of a kind.

Article: 159341
Subject: Re: CORDIC in a land of built-in multipliers
From: rickman <gnuarm@gmail.com>
Date: Thu, 13 Oct 2016 21:33:49 -0400
Links: << >>  << T >>  << A >>
On 10/13/2016 6:16 PM, Tim Wescott wrote:
> On Thu, 13 Oct 2016 18:14:58 -0400, rickman wrote:
>
>> On 10/13/2016 5:10 PM, Tim Wescott wrote:
>>> On Thu, 13 Oct 2016 20:59:49 +0000, Rob Gaddi wrote:
>>>
>>>> Tim Wescott wrote:
>>>>
>>>>> On Thu, 13 Oct 2016 13:46:18 -0500, Tim Wescott wrote:
>>>>>
>>>>>> Now that FPGAs have built-in DSP blocks, how commonly is CORDIC
>>>>>> used? Is it still a necessary go-to for anyone contemplating doing
>>>>>> DSP in an FPGA,
>>>>>> or is it starting to ease onto the off-ramp of history?
>>>>>>
>>>>>> And, putting FPGA use aside -- how common is it is ASICs?
>>>>>
>>>>> Being bad because I'm cross-posting.  Being bad because I'm
>>>>> cross-posting a reply to _my own post_.
>>>>>
>>>>> Oh well -- I'm thinking that maybe some of the folks on comp.dsp who
>>>>> aren't also on comp.arch.fpga will have some thoughts.
>>>>>
>>>>>
>>>> I've considered it many times, but never used it.  Then again it's not
>>>> like I use the DSP blocks for CORDIC sorts of things anyhow; I just
>>>> throw a RAM lookup table at the problem.
>>>
>>> That was the other thing that I should have mentioned.
>>>
>>> I've heard a lot of talk about CORDIC, but it seems to be one of those
>>> things that was Really Critically Important back when an Intel 4004
>>> cost (reputedly) $5 in then-dollars, but maybe isn't so important now,
>>> when it seems like the package costs more than the silicon inside it.
>>
>> There are still FPGAs at the lower end that don't include multipliers. I
>> have an older design in a small FPGA I am still shipping that does the
>> iterative adding thing.  It has been a while since I considered using
>> the CORDIC algorithm.  What exactly is the advantage of the CORDIC
>> algorithm again?
>
> It uses less gates.  Which is why I'm asking my question -- gates seem to
> be a lot cheaper these days, so do people still use CORDIC?

Can you explain that briefly?  Why is it less gates than an adder? 
Adders are pretty durn simple.  I thought the CORDIC algorithm used an 
ADD.

-- 

Rick C

Article: 159342
Subject: Re: CORDIC in a land of built-in multipliers
From: rickman <gnuarm@gmail.com>
Date: Thu, 13 Oct 2016 21:37:39 -0400
Links: << >>  << T >>  << A >>
On 10/13/2016 9:33 PM, rickman wrote:
> On 10/13/2016 6:16 PM, Tim Wescott wrote:
>> On Thu, 13 Oct 2016 18:14:58 -0400, rickman wrote:
>>
>>> On 10/13/2016 5:10 PM, Tim Wescott wrote:
>>>> On Thu, 13 Oct 2016 20:59:49 +0000, Rob Gaddi wrote:
>>>>
>>>>> Tim Wescott wrote:
>>>>>
>>>>>> On Thu, 13 Oct 2016 13:46:18 -0500, Tim Wescott wrote:
>>>>>>
>>>>>>> Now that FPGAs have built-in DSP blocks, how commonly is CORDIC
>>>>>>> used? Is it still a necessary go-to for anyone contemplating doing
>>>>>>> DSP in an FPGA,
>>>>>>> or is it starting to ease onto the off-ramp of history?
>>>>>>>
>>>>>>> And, putting FPGA use aside -- how common is it is ASICs?
>>>>>>
>>>>>> Being bad because I'm cross-posting.  Being bad because I'm
>>>>>> cross-posting a reply to _my own post_.
>>>>>>
>>>>>> Oh well -- I'm thinking that maybe some of the folks on comp.dsp who
>>>>>> aren't also on comp.arch.fpga will have some thoughts.
>>>>>>
>>>>>>
>>>>> I've considered it many times, but never used it.  Then again it's not
>>>>> like I use the DSP blocks for CORDIC sorts of things anyhow; I just
>>>>> throw a RAM lookup table at the problem.
>>>>
>>>> That was the other thing that I should have mentioned.
>>>>
>>>> I've heard a lot of talk about CORDIC, but it seems to be one of those
>>>> things that was Really Critically Important back when an Intel 4004
>>>> cost (reputedly) $5 in then-dollars, but maybe isn't so important now,
>>>> when it seems like the package costs more than the silicon inside it.
>>>
>>> There are still FPGAs at the lower end that don't include multipliers. I
>>> have an older design in a small FPGA I am still shipping that does the
>>> iterative adding thing.  It has been a while since I considered using
>>> the CORDIC algorithm.  What exactly is the advantage of the CORDIC
>>> algorithm again?
>>
>> It uses less gates.  Which is why I'm asking my question -- gates seem to
>> be a lot cheaper these days, so do people still use CORDIC?
>
> Can you explain that briefly?  Why is it less gates than an adder?
> Adders are pretty durn simple.  I thought the CORDIC algorithm used an ADD.

Opps, I see the CORDIC doesn't replace a multiplication... it replaces a 
sine calculation.  I told you it had been a while since I looked at it.

Yes, I recall now the CORDIC typically converges faster than a power 
series and requires no multiplications.  Do I have it now?  Using fewer 
gates is a bit of an understatement.

-- 

Rick C

Article: 159343
Subject: Re: CORDIC in a land of built-in multipliers
From: BobH <wanderingmetalhead.nospam.please@yahoo.com>
Date: Thu, 13 Oct 2016 19:11:05 -0700
Links: << >>  << T >>  << A >>
On 10/13/2016 03:16 PM, Tim Wescott wrote:
> On Thu, 13 Oct 2016 18:14:58 -0400, rickman wrote:
>
>> On 10/13/2016 5:10 PM, Tim Wescott wrote:
>>> On Thu, 13 Oct 2016 20:59:49 +0000, Rob Gaddi wrote:
>>>
>>>> Tim Wescott wrote:
>>>>
>>>>> On Thu, 13 Oct 2016 13:46:18 -0500, Tim Wescott wrote:
>>>>>
>>>>>> Now that FPGAs have built-in DSP blocks, how commonly is CORDIC
>>>>>> used? Is it still a necessary go-to for anyone contemplating doing
>>>>>> DSP in an FPGA,
>>>>>> or is it starting to ease onto the off-ramp of history?
>>>>>>
>>>>>> And, putting FPGA use aside -- how common is it is ASICs?
>>>>>
>>>>> Being bad because I'm cross-posting.  Being bad because I'm
>>>>> cross-posting a reply to _my own post_.
>>>>>
>>>>> Oh well -- I'm thinking that maybe some of the folks on comp.dsp who
>>>>> aren't also on comp.arch.fpga will have some thoughts.
>>>>>
>>>>>
>>>> I've considered it many times, but never used it.  Then again it's not
>>>> like I use the DSP blocks for CORDIC sorts of things anyhow; I just
>>>> throw a RAM lookup table at the problem.
>>>
>>> That was the other thing that I should have mentioned.
>>>
>>> I've heard a lot of talk about CORDIC, but it seems to be one of those
>>> things that was Really Critically Important back when an Intel 4004
>>> cost (reputedly) $5 in then-dollars, but maybe isn't so important now,
>>> when it seems like the package costs more than the silicon inside it.
>>
>> There are still FPGAs at the lower end that don't include multipliers. I
>> have an older design in a small FPGA I am still shipping that does the
>> iterative adding thing.  It has been a while since I considered using
>> the CORDIC algorithm.  What exactly is the advantage of the CORDIC
>> algorithm again?
>
> It uses less gates.  Which is why I'm asking my question -- gates seem to
> be a lot cheaper these days, so do people still use CORDIC?
>

My understanding (kind of limited) is that CORDIC is used for trig and 
exponential calculations, more than just multiplication. I have never 
used a CORDIC implementation in an FPGA or an ASIC. I tend to do more 
control path and communications implementations than DSP/data path stuff 
though.

BobH


Article: 159344
Subject: Re: CORDIC in a land of built-in multipliers
From: Rafael Deliano <rafael_deliano@arcor.de>
Date: Fri, 14 Oct 2016 05:35:09 +0200
Links: << >>  << T >>  << A >>
> I've heard a lot of talk about CORDIC, but it seems to be one of those
> things that was Really Critically Important back when an Intel 4004 cost
> (reputedly) $5 in then-dollars,

It was used in (HP-)pocket calculators then and got well known
that way.
Later on floating point coprocessors. 8087, probably up to MC68882.
Guess Cyrix were the first there to implement a big float multiplier
and do it differently.
In the 70ies and 80ies on (rad-hard) RCA1802 CPUs in AMSAT
satellites.
It calculates not only sin, cos, but also atan, atanh, sinh, cosh ...
For navigation, robotics on small memory it may be still usefull.

But who knows after all these years what it is and
how to implement it ?
Same for Logarithmic Number Systems ( LNS ).
There may be niche applications that benefit, but industry
will not offer it, because customers will not know & buy.

MfG  JRD








Article: 159345
Subject: Re: CORDIC in a land of built-in multipliers
From: Cecil Bayona <cbayona@cbayona.com>
Date: Thu, 13 Oct 2016 22:51:11 -0500
Links: << >>  << T >>  << A >>
On 10/13/2016 8:33 PM, rickman wrote:
> On 10/13/2016 6:16 PM, Tim Wescott wrote:
>> On Thu, 13 Oct 2016 18:14:58 -0400, rickman wrote:
>>
>>> On 10/13/2016 5:10 PM, Tim Wescott wrote:
>>>> On Thu, 13 Oct 2016 20:59:49 +0000, Rob Gaddi wrote:
>>>>
>>>>> Tim Wescott wrote:
>>>>>
>>>>>> On Thu, 13 Oct 2016 13:46:18 -0500, Tim Wescott wrote:
>>>>>>
>>>>>>> Now that FPGAs have built-in DSP blocks, how commonly is CORDIC
>>>>>>> used? Is it still a necessary go-to for anyone contemplating doing
>>>>>>> DSP in an FPGA,
>>>>>>> or is it starting to ease onto the off-ramp of history?
>>>>>>>
>>>>>>> And, putting FPGA use aside -- how common is it is ASICs?
>>>>>>
>>>>>> Being bad because I'm cross-posting.  Being bad because I'm
>>>>>> cross-posting a reply to _my own post_.
>>>>>>
>>>>>> Oh well -- I'm thinking that maybe some of the folks on comp.dsp who
>>>>>> aren't also on comp.arch.fpga will have some thoughts.
>>>>>>
>>>>>>
>>>>> I've considered it many times, but never used it.  Then again it's not
>>>>> like I use the DSP blocks for CORDIC sorts of things anyhow; I just
>>>>> throw a RAM lookup table at the problem.
>>>>
>>>> That was the other thing that I should have mentioned.
>>>>
>>>> I've heard a lot of talk about CORDIC, but it seems to be one of those
>>>> things that was Really Critically Important back when an Intel 4004
>>>> cost (reputedly) $5 in then-dollars, but maybe isn't so important now,
>>>> when it seems like the package costs more than the silicon inside it.
>>>
>>> There are still FPGAs at the lower end that don't include multipliers. I
>>> have an older design in a small FPGA I am still shipping that does the
>>> iterative adding thing.  It has been a while since I considered using
>>> the CORDIC algorithm.  What exactly is the advantage of the CORDIC
>>> algorithm again?
>>
>> It uses less gates.  Which is why I'm asking my question -- gates seem to
>> be a lot cheaper these days, so do people still use CORDIC?
>
> Can you explain that briefly?  Why is it less gates than an adder?
> Adders are pretty durn simple.  I thought the CORDIC algorithm used an ADD.
>
Cordic is used for items like sine, cosine, tangent, square root,etc 
with involves multiplication and some division, but the Cordic 
Algorithms eliminate multiply and divide so it simplifies the logic by 
quite a bit. It's mainly used with devices that do not have multiply and 
divide capability even then Cordic could be faster.

-- 
Cecil - k5nwa

Article: 159346
Subject: Re: CORDIC in a land of built-in multipliers
From: rickman <gnuarm@gmail.com>
Date: Fri, 14 Oct 2016 03:32:40 -0400
Links: << >>  << T >>  << A >>
On 10/13/2016 11:51 PM, Cecil Bayona wrote:
> On 10/13/2016 8:33 PM, rickman wrote:
>> On 10/13/2016 6:16 PM, Tim Wescott wrote:
>>> On Thu, 13 Oct 2016 18:14:58 -0400, rickman wrote:
>>>
>>>> On 10/13/2016 5:10 PM, Tim Wescott wrote:
>>>>> On Thu, 13 Oct 2016 20:59:49 +0000, Rob Gaddi wrote:
>>>>>
>>>>>> Tim Wescott wrote:
>>>>>>
>>>>>>> On Thu, 13 Oct 2016 13:46:18 -0500, Tim Wescott wrote:
>>>>>>>
>>>>>>>> Now that FPGAs have built-in DSP blocks, how commonly is CORDIC
>>>>>>>> used? Is it still a necessary go-to for anyone contemplating doing
>>>>>>>> DSP in an FPGA,
>>>>>>>> or is it starting to ease onto the off-ramp of history?
>>>>>>>>
>>>>>>>> And, putting FPGA use aside -- how common is it is ASICs?
>>>>>>>
>>>>>>> Being bad because I'm cross-posting.  Being bad because I'm
>>>>>>> cross-posting a reply to _my own post_.
>>>>>>>
>>>>>>> Oh well -- I'm thinking that maybe some of the folks on comp.dsp who
>>>>>>> aren't also on comp.arch.fpga will have some thoughts.
>>>>>>>
>>>>>>>
>>>>>> I've considered it many times, but never used it.  Then again it's
>>>>>> not
>>>>>> like I use the DSP blocks for CORDIC sorts of things anyhow; I just
>>>>>> throw a RAM lookup table at the problem.
>>>>>
>>>>> That was the other thing that I should have mentioned.
>>>>>
>>>>> I've heard a lot of talk about CORDIC, but it seems to be one of those
>>>>> things that was Really Critically Important back when an Intel 4004
>>>>> cost (reputedly) $5 in then-dollars, but maybe isn't so important now,
>>>>> when it seems like the package costs more than the silicon inside it.
>>>>
>>>> There are still FPGAs at the lower end that don't include
>>>> multipliers. I
>>>> have an older design in a small FPGA I am still shipping that does the
>>>> iterative adding thing.  It has been a while since I considered using
>>>> the CORDIC algorithm.  What exactly is the advantage of the CORDIC
>>>> algorithm again?
>>>
>>> It uses less gates.  Which is why I'm asking my question -- gates
>>> seem to
>>> be a lot cheaper these days, so do people still use CORDIC?
>>
>> Can you explain that briefly?  Why is it less gates than an adder?
>> Adders are pretty durn simple.  I thought the CORDIC algorithm used an
>> ADD.
>>
> Cordic is used for items like sine, cosine, tangent, square root,etc
> with involves multiplication and some division, but the Cordic
> Algorithms eliminate multiply and divide so it simplifies the logic by
> quite a bit. It's mainly used with devices that do not have multiply and
> divide capability even then Cordic could be faster.

It can be faster at trig functions than multiplying (assuming the 
multiply was not with a parallel multiplier), but it is not faster than 
a multiplier at multiplying, even a shift and add multiplier.  The 
CORDIC function converges at 1 bit per iteration.  That's the same as a 
sequential multiplier doing a shift and add which is very similar to the 
CORDIC method.

The CORDIC function can always be pipelined to get higher throughput, 
but it is not likely to outrun a dedicated multiplier in an FPGA. 
Taylor series gets very high precisions very quickly.

-- 

Rick C

Article: 159347
Subject: Re: CORDIC in a land of built-in multipliers
From: already5chosen@yahoo.com
Date: Fri, 14 Oct 2016 06:04:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, October 14, 2016 at 4:37:39 AM UTC+3, rickman wrote:
> On 10/13/2016 9:33 PM, rickman wrote:
> > On 10/13/2016 6:16 PM, Tim Wescott wrote:
> >> On Thu, 13 Oct 2016 18:14:58 -0400, rickman wrote:
> >>
> >>> On 10/13/2016 5:10 PM, Tim Wescott wrote:
> >>>> On Thu, 13 Oct 2016 20:59:49 +0000, Rob Gaddi wrote:
> >>>>
> >>>>> Tim Wescott wrote:
> >>>>>
> >>>>>> On Thu, 13 Oct 2016 13:46:18 -0500, Tim Wescott wrote:
> >>>>>>
> >>>>>>> Now that FPGAs have built-in DSP blocks, how commonly is CORDIC
> >>>>>>> used? Is it still a necessary go-to for anyone contemplating doin=
g
> >>>>>>> DSP in an FPGA,
> >>>>>>> or is it starting to ease onto the off-ramp of history?
> >>>>>>>
> >>>>>>> And, putting FPGA use aside -- how common is it is ASICs?
> >>>>>>
> >>>>>> Being bad because I'm cross-posting.  Being bad because I'm
> >>>>>> cross-posting a reply to _my own post_.
> >>>>>>
> >>>>>> Oh well -- I'm thinking that maybe some of the folks on comp.dsp w=
ho
> >>>>>> aren't also on comp.arch.fpga will have some thoughts.
> >>>>>>
> >>>>>>
> >>>>> I've considered it many times, but never used it.  Then again it's =
not
> >>>>> like I use the DSP blocks for CORDIC sorts of things anyhow; I just
> >>>>> throw a RAM lookup table at the problem.
> >>>>
> >>>> That was the other thing that I should have mentioned.
> >>>>
> >>>> I've heard a lot of talk about CORDIC, but it seems to be one of tho=
se
> >>>> things that was Really Critically Important back when an Intel 4004
> >>>> cost (reputedly) $5 in then-dollars, but maybe isn't so important no=
w,
> >>>> when it seems like the package costs more than the silicon inside it=
.
> >>>
> >>> There are still FPGAs at the lower end that don't include multipliers=
. I
> >>> have an older design in a small FPGA I am still shipping that does th=
e
> >>> iterative adding thing.  It has been a while since I considered using
> >>> the CORDIC algorithm.  What exactly is the advantage of the CORDIC
> >>> algorithm again?
> >>
> >> It uses less gates.  Which is why I'm asking my question -- gates seem=
 to
> >> be a lot cheaper these days, so do people still use CORDIC?
> >
> > Can you explain that briefly?  Why is it less gates than an adder?
> > Adders are pretty durn simple.  I thought the CORDIC algorithm used an =
ADD.
>=20
> Opps, I see the CORDIC doesn't replace a multiplication... it replaces a=
=20
> sine calculation.  I told you it had been a while since I looked at it.
>=20
> Yes, I recall now the CORDIC typically converges faster than a power=20
> series=20

If you properly chose your ranges then power series will converge many time=
s faster than CORDIC.

For example, you want sin(x) for x in range [0..pi/2]. You don't apply powe=
r series to a full range.
Instead, you calculated it as sin(x_tab)*cos(x-x_tab)+cos(x)*sin(x-x_tab)
Where, sin(x_tab)/cos(x_tab) are taken from small table, e.g. 64 entries. T=
hen, you only apply power series to x-x_tab, which is a small number. Such =
power series converges very quickly, in specific case of sin() and of 64-en=
try table, ~13 bits per iteration.

Please, don't take what is written above as an actual algorithm. It's just =
a guideline. An algorithm, that wants to produces a result with max. error =
of < 1 ULP, would have to be a little more careful about details.

> and requires no multiplications.  Do I have it now?  Using fewer=20
> gates is a bit of an understatement.
>=20
> --=20
>=20
> Rick C


Article: 159348
Subject: Re: CORDIC in a land of built-in multipliers
From: already5chosen@yahoo.com
Date: Fri, 14 Oct 2016 06:17:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, October 14, 2016 at 6:35:12 AM UTC+3, Rafael Deliano wrote:
> > I've heard a lot of talk about CORDIC, but it seems to be one of those
> > things that was Really Critically Important back when an Intel 4004 cost
> > (reputedly) $5 in then-dollars,
> 
> It was used in (HP-)pocket calculators then and got well known
> that way.
> Later on floating point coprocessors. 8087,

Did 8087 use CORDIC for multiplication and division or only for trigonometric instructions, and, possibly, for BCD-binary conversions?
I googled for an answer several months ago, but found nothing.

> probably up to MC68882.
> Guess Cyrix were the first there to implement a big float multiplier
> and do it differently.
> In the 70ies and 80ies on (rad-hard) RCA1802 CPUs in AMSAT
> satellites.
> It calculates not only sin, cos, but also atan, atanh, sinh, cosh ...
> For navigation, robotics on small memory it may be still usefull.

Unlikely.
Nowadays, even small ARM Cortex-M4 has fast multiplier and is typically coupled with at least 128 KB of on-chip NOR flash. And robotics tend to use bigger CPUs than Cortex M4.

> 
> But who knows after all these years what it is and
> how to implement it ?
> Same for Logarithmic Number Systems ( LNS ).
> There may be niche applications that benefit, but industry
> will not offer it, because customers will not know & buy.
> 
> MfG  JRD

Article: 159349
Subject: Re: CORDIC in a land of built-in multipliers
From: spope33@speedymail.org (Steve Pope)
Date: Fri, 14 Oct 2016 14:40:02 +0000 (UTC)
Links: << >>  << T >>  << A >>
Cecil Bayona  <cbayona@cbayona.com> wrote:

>Cordic is used for items like sine, cosine, tangent, square root,etc 
>with involves multiplication and some division, but the Cordic 
>Algorithms eliminate multiply and divide so it simplifies the logic by 
>quite a bit. 

I've been designing DSP ASIC's since the 1980's and have never
chosen to use Cordic.  I can envision where Cordic might make sense --
where the precision requirements are not really known or are
very high, Cordic will win over LUT-based designs but most typically
the LUT-based designs are a simpler way to meet the requirement.

It's also possible that in some PLD-based designs Cordic might
be the way to go.

Steve



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