Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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: 159326On 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 JenningsArticle: 159327
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
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. AllanArticle: 159329
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: 159330Allan 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 ColinArticle: 159331
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 CArticle: 159332
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, AllanArticle: 159333
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
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
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
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
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
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 CArticle: 159339
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
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
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 CArticle: 159342
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 CArticle: 159343
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. BobHArticle: 159344
> 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 JRDArticle: 159345
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 - k5nwaArticle: 159346
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 CArticle: 159347
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 CArticle: 159348
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 JRDArticle: 159349
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:
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