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
Hello all, I was wondering if catapult C HLS has a built in exp() for floating point numbers. If yes is the generated RTL description vendor independent and the modules used sharable or open etc.? ThanksArticle: 155101
How is your experience with Catapult C? Does it work? I don't have an answer to your exact question, but if you don't find a built-in function, a lookup table or a Maclaurin series are your best bets.Article: 155102
Hi, If you have Catapult-SL, you should be able to use the C-Core feature and wrap-up a module from flopoco (http://flopoco.gforge.inria.fr/) which produces HDL. Ragards, Steven On 15/04/2013 16:09, turin231@gmail.com wrote: > Hello all, > > I was wondering if catapult C HLS has a built in exp() for floating point numbers. If yes is the generated RTL description vendor independent and the modules used sharable or open etc.? > > ThanksArticle: 155103
Hi, I'm looking for possibly cheap FPGA based board with 4 channel 500 Msps ADC (at least 8bit). The board should allow preprocessing of acquired data and transmission of results to the PC (via PCIe, Ethernet or USB - the amount of data after preprocessing will be significantly reduced). I have found boards like: http://www.signatec.com/products/daq/high-speed-digitizer-fpga-pcie-board-px1500-4.html (unfortunately price is not published). One additional demand. The board should allow implementation of user's own IP core in the FPGA, so all details needed to communicate with ADC and with PC should be open. -- TIA & Regards, WojtekArticle: 155104
@ Kevin...Did not try it yet...I will tell when i try it but most consider catapult C as one of the most robust... Thanks for the replies...I will try and check backArticle: 155105
I used to work on the development a high-level design tool but it never worked out well. Plus, Verilog/VHDL keep getting more abstract all the time. But I'm always interested to hear about these other tools. If you can't use a lookup, the Horner-style Maclaurin for y=exp(x) isn't too hard. Something like: y=1; temp=1; for n = 1 to N temp = temp * x/n; y = y + temp; end Accuracy depends on N. You can store the reciprocals of n in a ROM so you don't have to do divides. If x is purely imaginary, just use a sin/cos lookup.Article: 155106
On Tue, 16 Apr 2013 14:09:38 -0700, wzab wrote: > Hi, > > I'm looking for possibly cheap FPGA based board with 4 channel 500 Msps > ADC (at least 8bit). > The board should allow preprocessing of acquired data and transmission > of results to the PC (via PCIe, Ethernet or USB - the amount of data > after preprocessing will be significantly reduced). > > I have found boards like: > http://www.signatec.com/products/daq/high-speed-digitizer-fpga-pcie- board-px1500-4.html > (unfortunately price is not published). > > One additional demand. The board should allow implementation of user's > own IP core in the FPGA, > so all details needed to communicate with ADC and with PC should be > open. If you are just building one of something, and particularly if it's going to be a lab queen, then look at the evaluation boards from the FPGA vendors. Documentation will be complete, but basic -- you'll get a schematic and an example application, and the rest will be up to you. Beyond that -- I'd be surprised if there's not more out there. Some sort of a general-purpose data acquisition card with an FPGA in it seems an obvious sort of thing to sell to people just like you. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 155107
In comp.arch.fpga, wzab <wzab01@gmail.com> wrote: > Hi, > > I'm looking for possibly cheap FPGA based board with 4 channel 500 > Msps ADC (at least 8bit). > The board should allow preprocessing of acquired data and transmission > of results to the PC (via > PCIe, Ethernet or USB - the amount of data after preprocessing will be > significantly reduced). > > I have found boards like: > http://www.signatec.com/products/daq/high-speed-digitizer-fpga-pcie-board-px1500-4.html > (unfortunately price is not published). > > One additional demand. The board should allow implementation of user's > own IP core in the FPGA, > so all details needed to communicate with ADC and with PC should be > open. Just got an ad-mail from Analog devices for their "Pmod I/O interface boards", suitable for "Signal integration to FPGA designs". May be of interest to you if you can't find a suitable single-board solution. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) "No matter where you go, there you are..." -- Buckaroo BanzaiArticle: 155108
In comp.arch.fpga, Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote: [Pmod] Sorry, should have checked out these boards before posting. Forget those Pmod boards, it's all slow stuff, nowhere near 500MSPS. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Wherever you go...There you are. - Buckaroo BanzaiArticle: 155109
Check Ettus research for USRP series. "wzab" wrote in message news:1bb09ab3-f3c5-4ef6-8647-94c700fac4c0@b3g2000vbo.googlegroups.com... Hi, I'm looking for possibly cheap FPGA based board with 4 channel 500 Msps ADC (at least 8bit). The board should allow preprocessing of acquired data and transmission of results to the PC (via PCIe, Ethernet or USB - the amount of data after preprocessing will be significantly reduced). I have found boards like: http://www.signatec.com/products/daq/high-speed-digitizer-fpga-pcie-board-px1500-4.html (unfortunately price is not published). One additional demand. The board should allow implementation of user's own IP core in the FPGA, so all details needed to communicate with ADC and with PC should be open. -- TIA & Regards, WojtekArticle: 155110
Andy, There are two approaches to doing this in an FPGA. The OP is looking at one= that would bring the TMDS and clock lines directly to the FPGA (assuming a= ppropriate equalization / level shift / drivers on PCB). An FPGA cannot pro= vide a simple crosspoint function internally, thus one would have to put 16= instances of HDMI RX and 16 instances of HDMI TX cores in the device and c= reate the crosspoint in the fabric. My personal opinion is that the number = of cores, the clocking resources, and logic required would make this a futi= le exercise. The second approach is mentioned by Thomas already. This at least keeps the= HDMI PHY and RX/TX stack out of the FPGA, but will require quite a bit of = IO depending on OP needs.=20 To attempt either will require a large and costly FPGA, I think the OP will= find the crosspoints cheaper in the end. -Matt=20Article: 155111
On 20/04/13 00:15, matt.lettau@gmail.com wrote: > Andy, > > There are two approaches to doing this in an FPGA. The OP is looking > at one that would bring the TMDS and clock lines directly to the FPGA > (assuming appropriate equalization / level shift / drivers on PCB). > An FPGA cannot provide a simple crosspoint function internally, thus > one would have to put 16 instances of HDMI RX and 16 instances of > HDMI TX cores in the device and create the crosspoint in the fabric. > My personal opinion is that the number of cores, the clocking > resources, and logic required would make this a futile exercise. > > The second approach is mentioned by Thomas already. This at least > keeps the HDMI PHY and RX/TX stack out of the FPGA, but will require > quite a bit of IO depending on OP needs. > > To attempt either will require a large and costly FPGA, I think the > OP will find the crosspoints cheaper in the end. > > -Matt > Yes, that's pretty much the same conclusion as we came to (after you and another off-list poster suggested crosspoints) - and we are now using such a crosspoint switch on the board. Thanks to all for their suggestions. DavidArticle: 155112
Matt, OK, it's an economic issue, not a technical issue. Thanks, AndyArticle: 155113
On 22/04/13 20:27, jonesandy@comcast.net wrote: > Matt, > > OK, it's an economic issue, not a technical issue. > > Thanks, > > Andy > I think it's a bit of both - when looking at the numbers of I/O's needed, I don't think there are FPGA's big enough on the market. Had it been 8x8 rather than 16x16, it would perhaps have been an economic issue. But with 16x16, we would need 64 inputs at 3.4 Gpbs and 64 outputs at 3.4 Gpbs - I don't think there are any FPGAs that have that many high-speed channels. And if we use external encoder/decoder chips, the speeds per line are lower but we would need far more of them. Certainly in principle an FPGA can be used for an HDMI cross-point switch, but it seems that it is not a practical solution for such a big switch.Article: 155114
Matt, This is not a question of practical/economic consideration, per your original statement. Altera Stratix V GX B series has 66 full-duplex, 14.1 Gbps transceivers with independent Rx/Tx PLLs (e.g. 66 inputs, 66 outputs), and 490K-952K logic elements for an x-bar. Probably not cost effective, but technically feasible. AndyArticle: 155115
On 23/04/13 01:36, jonesandy@comcast.net wrote: > Matt, > > This is not a question of practical/economic consideration, per your > original statement. > > Altera Stratix V GX B series has 66 full-duplex, 14.1 Gbps > transceivers with independent Rx/Tx PLLs (e.g. 66 inputs, 66 > outputs), and 490K-952K logic elements for an x-bar. I didn't realise the Rx and Tx sides of the transceivers could operate independently - that's why I dismissed these as too small. > > Probably not cost effective, but technically feasible. Well, if it is possible to buy these devices, then I agree. > > Andy >Article: 155116
Arrow shows 5SGXEB6R2F40C3N in stock @ $9,092.00 ea (min/multiple = 1). Very likely not cost effective... AndyArticle: 155117
Not a fgpa solution, but have a look at analog devices ADN4605 and its likes.. A few of those and you got full matrix of even more ports.Article: 155118
David Brown wrote: > On 08/04/13 17:58, thomas.entner99@gmail.com wrote: >> You might consider to use 16 external receivers and 16 external >> transmitters and use the FPGA to mux the databuses. There are some >> Rx/Tx that support DDR on the databuses, so this will get you 16pins >> per Rx/TX (12b+HD+VD+DE+Clk) x 32 = 512 Pins Total. There are at >> least low cost Cyclone IV that have so many IOs (CE30/CE40). >> >> But I have not checked if this DDR-style Rx/Tx are also available for >> HDMI1.4 and how this solution compares to this crosspoint switches. >> >> Regards, >> >> Thomas >> > > Unfortunately, the numbers are bigger than that. HDMI receivers and > transmitters that I have seen have SDR on the databus, but for HDMI1.4 > that would be 36 lines at 340 Mbps. So for 16 channels in and 16 > channels out, that would be 36*16*2 = 1152 pins, all running at 340 > Mbps. That's a lot of pins - and even if we got an FPGA big enough, > designing such a board and getting matched lengths on all the lines > needed would be a serious effort. > > The crosspoint switches mentioned by another poster are one likely > choice. The other realistic architecture is to use large numbers of > 4-to-1 HDMI multiplexers. Probably not a good solution at 340 Mbps, but when you have a large parallel bus and need a number of these in a crossbar, you can split the bus into bit slices and handle them in separate smaller and much cheaper devices. Generally, using a very high pin-count FPGA with very little logic is a big waste of silicon. For something as regular in structure as a parallel-bus crossbar, splitting the bus into slices can reduce the silicon area by using a number of FPGA's programmed identically each handling the same slice from every port on the crossbar. The problem at very high speeds would be part to part skew. You can control voltage and temperature among the parts, but you're at the mercy of the manufacturer for process variation. -- GaborArticle: 155119
The Xilinx built-in blockRAM FIFOs seem pretty nice, but is there any way t= o infer them? Probably not. They're not that useful otherwise, unless you= want to instantiate the primitive (not really), use CoreGen (no), and simu= late using a unisim (who's got the time?). I always thought it'd be nice if Synplify could infer the Systemverilog pus= h_front and pop_back queue commands as a FIFO and then use its own SynCore = tool to make a FIFO from that. I might have to wait another 7-8 years for = that one.Article: 155120
Why is Modelsim so expensive? It is a mature product and yet it segfaults = on me all the time. Constantly. Often, when it ought to give me warnings = or errors (such as when there is a port width mismatch) it just core dumps = instead, leaving me to comment out lines one at a time until I figure out w= hy it's crashing. That's my rant. It's still pretty decent, but ought to = be cheaper if it's going to coredump like freeware.Article: 155121
On Tue, 23 Apr 2013 13:13:42 -0700 (PDT) Kevin Neilson <kevin.neilson@xilinx.com> wrote: > Why is Modelsim so expensive? It is a mature product and yet it segfaults on me all the time. Constantly. Often, when it ought to give me warnings or errors (such as when there is a port width mismatch) it just core dumps instead, leaving me to comment out lines one at a time until I figure out why it's crashing. That's my rant. It's still pretty decent, but ought to be cheaper if it's going to coredump like freeware. An argument could be made that it's so expensive even with its segfaults because, even with it segfaulting all the time, you were willing to pay them as much as they asked for it. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 155122
On 4/23/2013 4:13 PM, Kevin Neilson wrote: > Why is Modelsim so expensive? It is a mature product and yet it segfaults on me all the time. Constantly. Often, when it ought to give me warnings or errors (such as when there is a port width mismatch) it just core dumps instead, leaving me to comment out lines one at a time until I figure out why it's crashing. That's my rant. It's still pretty decent, but ought to be cheaper if it's going to coredump like freeware. I am using ActiveHDL which is a competing product, but both are free as far as I know. I don't buy them, I get them with the vendors free tools. I guess when you pay for them you get a version that isn't crippled and runs faster. Most of the stuff I do the simulation doesn't take so long that this is a problem. I've never seen the sort of bugs you are talking about. I do remember that some 10 years ago they had a memory leak that would crash it after running for some hours. I never saw them fix that problem, it continued release after release. I only switched to AHDL because Lattice switched tools. I ordered a paid version of their tools (at that time they didn't give a simulator) and between the time I placed the order and the time I received it an tried to fire it up, it wouldn't license! Seems they switched brands and I *had* to use AHDL whether I wanted to or not. I ranted and raved for a bit (that was pretty dirty pool) but in the end I didn't see much of a difference and like AHDL pretty well. I think they have a trial version, you might give it a try. I don't see it crashing like you are saying Modelsim does. -- RickArticle: 155123
On 4/23/2013 4:20 PM, Rob Gaddi wrote: > On Tue, 23 Apr 2013 13:13:42 -0700 (PDT) > Kevin Neilson<kevin.neilson@xilinx.com> wrote: > >> Why is Modelsim so expensive? It is a mature product and yet it segfaults on me all the time. Constantly. Often, when it ought to give me warnings or errors (such as when there is a port width mismatch) it just core dumps instead, leaving me to comment out lines one at a time until I figure out why it's crashing. That's my rant. It's still pretty decent, but ought to be cheaper if it's going to coredump like freeware. > > An argument could be made that it's so expensive even with its > segfaults because, even with it segfaulting all the time, you were > willing to pay them as much as they asked for it. Yes, you could make that argument... but why bother? -- RickArticle: 155124
Hi All, I'm looking at FPGA implementation of Timing Recovery Loop and Interpolatio= n controller. I would like to refer an exact implementation block diagram. = I have refered Micheal Rice - Digital Communication book. But I would like = to refer an actual implementation model. Thanks.
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