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
sometimes I wonder whether the shipping cost rip-off is organized. It is possible to ship at very low cost - Xess, Numato, Papilio prove that. But then, try to order a BeMicro CV (or many other Altera boards) to Europe. Shipping costs about as much as the board itself, everywhere. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156676
Hi,
I'm looking for the Linux driver for Xilinx 10GBASE-R core.
In the DTS it is reported as:
axi_10g_ethernet_0_ten_gig_eth_mac: ten-gig-eth-mac@44a00000 {
compatible = "xlnx,ten-gig-eth-mac-13.0";
reg = <0x44a00000 0x10000>;
} ;
Does such driver exist, or do we need it to write it ourselves?
--
TIA & Regards,
Wojtek
Article: 156677On 6/2/2014 2:43 PM, Syed Huq wrote: > Well the folks at TI are not much help since they themselves outsourced the coding for the FPGA. The way I want the Trigger to work is that, when the trigger occurs, the data samples are stored for a few seconds. I also want to ensure that there is a bit of hold-off time within which another trigger cannot occur. How would I do that ? I'm not sure what you are asking. That is called logic design. I have not looked at the existing code, but clearly the data is stored in a memory with an address. You just need to set up a counter to generate an address which increments each time a sample is stored in memory. Obviously this would be either a pipelined design if a sample is stored on each system clock or if the ADC to memory transfers are not so fast a finite state machine can be used to control it all. Does any of this mean much to you? What level is your background in FPGAs? -- RickArticle: 156678
wzab01@gmail.com wrote:
> Hi,
>
> I'm looking for the Linux driver for Xilinx 10GBASE-R core.
> In the DTS it is reported as:
>
> axi_10g_ethernet_0_ten_gig_eth_mac: ten-gig-eth-mac@44a00000 {
> compatible = "xlnx,ten-gig-eth-mac-13.0";
> reg = <0x44a00000 0x10000>;
> } ;
>
> Does such driver exist, or do we need it to write it ourselves?
Do you mean a driver for Linux running on the FPGA, or using the FPGA as a
NIC in a PC?
If the latter, NetFPGA has drivers:
https://github.com/NetFPGA/NetFPGA-public/wiki/NIC-Driver
but you'd probably need to adapt the stack for your setup.
Theo
Article: 156679Hi, I want to ask you if it's feasible to create an ECG compression/decompression algorithm using decomposition of the ECG signal into orthogonal polynomials bases on FPGA. And if it's possible, do you think this solution is more efficient on FPGA ? Compared to PSoC or DPSs for say. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156680
>Hi I have just gotten a custom FPGA board in house and I am having trouble >programming it. >The FPGA I am using the Actel(Microsemi) Igloo AGL250V2-FGG1441 >There is a 10 pin JTAG header on the board. >And I am using Microsemi's FlashPro3 to program it. >The header of the FlashPro3 is 12 pins. There is a extra pin called >VJTAGENB - that is used for IGLOO nano devices so I have left that pin >unconnected. >When I try and program the device with FlashPro I get the following error >messages: >Error: programmer '71917' : Signal Integrity Failure > Integrity Check Pattern Not Found. > Integrity Check Pattern : > 550FAAF000FF0000FFFF > IrScan Error. > TDO stuck at 0 > Chain Analysis Failed. >Error: programmer '71917' : Data Bit length : 8272 >Error: programmer '71917' : Compare Data : 000108080008649...... >Error: programmer '71917' : Scan Chain FAILED. > >I have tried two board and they get the same error. I have also scoped the >JTAG lines and they look the same of two board. The trst seems to stay low >and tms seems to switch up and down at higher fequecy then tck before >settling on low. Not sure how to post the scope pictures here. Let me know >if you want to see them or any of info I forgot to add. > >The igloo app note, says that this error could mean by a broken td0 net, >are there any other possible reasons. > > > >--------------------------------------- >Posted through http://www.FPGARelated.com > Hi, In my case I had to wire agl_trst to VCC_JTAG to be able to connect to Igloo Nano Starter board, since my JTAG programmer lack TRST line (Altium JTAG). Regards, Darko --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156681
In article <3eidnZ7ikNcFSxDOnZ2dnUVZ_rednZ2d@giganews.com>, "Weiss" <100383@embeddedrelated> writes: >And if it's possible, do you think this solution is more efficient on FPGA >? Compared to PSoC or DPSs for say. A good rule of thumb is that if you can do it in software, that's probably easier and cheaper. -- These are my opinions. I hate spam.Article: 156682
On 6/3/2014 10:07 AM, Weiss wrote: > Hi, > > I want to ask you if it's feasible to create an ECG > compression/decompression algorithm using decomposition of the ECG signal > into orthogonal polynomials bases on FPGA. > > And if it's possible, do you think this solution is more efficient on FPGA > ? Compared to PSoC or DPSs for say. The choice of algorithm for your compression is another field of study than FPGA design. There is a newsgroup for that, comp.compression. Once you have found a reasonable compression algorithm for your signal, then you can choose an implementation based on the various requirements. -- RickArticle: 156683
W dniu wtorek, 3 czerwca 2014 12:34:21 UTC+2 u=C5=BCytkownik Theo Markettos=
napisa=C5=82:
> wzab01@gmail.com wrote:
>=20
> > Hi,
>=20
> >=20
>=20
> > I'm looking for the Linux driver for Xilinx 10GBASE-R core.
>=20
> > In the DTS it is reported as:
>=20
> >=20
>=20
> > axi_10g_ethernet_0_ten_gig_eth_mac: ten-gig-eth-mac@44a00000 {
>=20
> > compatible =3D "xlnx,ten-gig-eth-mac-13.0";
>=20
> > reg =3D <0x44a00000 0x10000>;
>=20
> > } ;
>=20
> >=20
>=20
> > Does such driver exist, or do we need it to write it ourselves?
>=20
>=20
>=20
> Do you mean a driver for Linux running on the FPGA, or using the FPGA as =
a
>=20
> NIC in a PC?
>=20
>=20
>=20
> If the latter, NetFPGA has drivers:
>=20
> https://github.com/NetFPGA/NetFPGA-public/wiki/NIC-Driver
>=20
> but you'd probably need to adapt the stack for your setup.
>=20
>=20
>=20
> Theo
OK. I have not described the setuo fully. This is a system implemented
on the FPGA based board (now the standard KC705, later a custom board).
The system consists of the Microblaze wit DDR RAM and some peripherials
including the Xilinx 10Gb/s MAC:
http://www.xilinx.com/products/intellectual-property/DO-DI-10GEMAC.htm
http://www.xilinx.com/support/documentation/ip_documentation/ten_gig_eth_ma=
c/v13_1/pg072-ten-gig-eth-mac.pdf
The Linux system for the above embedded system was successfully compiled
with Buildroot environment, but I was not able to find the appropriate driv=
er=20
for that MAC.=20
I've searched all accessible kernel repositories (including=20
https://github.com/Xilinx/linux-xlnx/tree/master/drivers/net/ethernet/xilin=
x
) for driver declaring
compatibility with "xlnx,ten-gig-eth-mac-13.0", but nothing seems to be ava=
ilable.
Of course I can get rid of Microblaze and this MAC, and build something
based on Wishbone, with MAC: http://opencores.org/project,xge_mac
(especially if I have to develop the driver myself, I'd rather prefer to
do it for an open solution, than for the commercial one).
Regards,
Wojtek
Article: 156684Weiss wrote: > Hi, > > I want to ask you if it's feasible to create an ECG > compression/decompression algorithm using decomposition of the ECG signal > into orthogonal polynomials bases on FPGA. > > And if it's possible, do you think this solution is more efficient on FPGA > ? Compared to PSoC or DPSs for say. In most cases, the sampling rate is low enough that even general-purpose micros ought to be able to handle the task. JonArticle: 156685
HI i am facing problem of 16 clock in my design although planahead says only 8 clocks can be usedArticle: 156686
On Wednesday, June 4, 2014 6:15:59 AM UTC-4, hilu...@gmail.com wrote: > HI i am facing problem of 16 clock in my design although planahead says only 8 > clocks can be used If you have 16 clocks then you likely don't understand how to design digital systems. Since you didn't post any actual question or request for anything specific, all I can offer is 'Good Luck'. KJArticle: 156687
On Tue, 03 Jun 2014 13:50:02 -0400, rickman wrote: > On 6/3/2014 10:07 AM, Weiss wrote: >> Hi, >> >> I want to ask you if it's feasible to create an ECG >> compression/decompression algorithm using decomposition of the ECG >> signal into orthogonal polynomials bases on FPGA. >> >> And if it's possible, do you think this solution is more efficient on >> FPGA ? Compared to PSoC or DPSs for say. > > The choice of algorithm for your compression is another field of study > than FPGA design. There is a newsgroup for that, comp.compression. > > Once you have found a reasonable compression algorithm for your signal, > then you can choose an implementation based on the various requirements. Is comp.compression active? I haven't heard of it. comp.dsp may be a good resource, too. ECG signals (assuming you mean electro cardio-gram) have some unique features that should make efficient compression both a joy and a terror, given that (a) the signal has a lot of "quiet time" with low information content, and (b) it's medical, which means that lives will depend on the fidelity of the reconstruction. Given the life-critical nature of the thing, I'd certainly want to start by finding a lossless compression method, and see if that's good enough. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 156688
On 04/06/2014 11:15, hiluckydr@gmail.com wrote: > HI i am facing problem of 16 clock in my design although planahead says only 8 clocks can be used Why do you need 16 unrelated clocks in your design? Some more information is required. It is unusual to need 16. There are techniques of creating enables from low speed clock edges that can be used to "eliminate" a clock from a design. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 156689
Tim Wescott <tim@seemywebsite.really> wrote: >> On 6/3/2014 10:07 AM, Weiss wrote: >>> I want to ask you if it's feasible to create an ECG >>> compression/decompression algorithm using decomposition of the ECG >>> signal into orthogonal polynomials bases on FPGA. (snip) > Is comp.compression active? I haven't heard of it. It has been pretty quiet lately, as has comp.dsp. > comp.dsp may be a good resource, too. ECG signals (assuming you mean > electro cardio-gram) have some unique features that should make efficient > compression both a joy and a terror, given that (a) the signal has a lot > of "quiet time" with low information content, and (b) it's medical, which > means that lives will depend on the fidelity of the reconstruction. OK, who remembers watching "Emergency!" many years ago. They have a portable machine which, if I remember right, sends the signal though a phone line. That is, pretty much an analog modem. (Actually, one direction, so modulator on one end, demodulator on the other.) Seems like that sets a limit on the needed bandwidth. But I presume the needed bandwidth is a lot less than 4kHz. > Given the life-critical nature of the thing, I'd certainly want to start > by finding a lossless compression method, and see if that's good enough. If you know exactly the features that are needed, you can compress down to just those features. But the bandwidth seems low enough to me, that I don't see why you need to work that hard. -- glenArticle: 156690
Mike Perkins <spam@spam.com> wrote: > On 04/06/2014 11:15, hiluckydr@gmail.com wrote: >> HI i am facing problem of 16 clock in my design although >> planahead says only 8 clocks can be used > Why do you need 16 unrelated clocks in your design? Does seem pretty unusual. > Some more information is required. It is unusual to need 16. I can image a data multiplexer that takes 15 signals, each with their own clock, and combines them into one output signal. > There are techniques of creating enables from low speed clock > edges that can be used to "eliminate" a clock from a design. There is special clock trees in most FPGAs to distribute low skew clocks to large numbers of FFs. There might be some that need more clocks, but don't need the low skew, and can use ordinary routing for the rest. -- glenArticle: 156691
On Wed, 04 Jun 2014 20:18:14 +0000, glen herrmannsfeldt wrote: > Tim Wescott <tim@seemywebsite.really> wrote: >>> On 6/3/2014 10:07 AM, Weiss wrote: > >>>> I want to ask you if it's feasible to create an ECG >>>> compression/decompression algorithm using decomposition of the ECG >>>> signal into orthogonal polynomials bases on FPGA. > > (snip) > >> Is comp.compression active? I haven't heard of it. > > It has been pretty quiet lately, as has comp.dsp. > >> comp.dsp may be a good resource, too. ECG signals (assuming you mean >> electro cardio-gram) have some unique features that should make >> efficient compression both a joy and a terror, given that (a) the >> signal has a lot of "quiet time" with low information content, and (b) >> it's medical, which means that lives will depend on the fidelity of the >> reconstruction. > > OK, who remembers watching "Emergency!" many years ago. They have a > portable machine which, if I remember right, sends the signal though a > phone line. That is, pretty much an analog modem. (Actually, one > direction, so modulator on one end, demodulator on the other.) Seems > like that sets a limit on the needed bandwidth. > > But I presume the needed bandwidth is a lot less than 4kHz. > >> Given the life-critical nature of the thing, I'd certainly want to >> start by finding a lossless compression method, and see if that's good >> enough. > > If you know exactly the features that are needed, you can compress down > to just those features. But the bandwidth seems low enough to me, that I > don't see why you need to work that hard. > > -- glen The OP did not say what he wanted to compress down to, true -- but your small may be his huge. My gut feel is that you can accurately reproduce an ECG signal with less than 100Hz of bandwidth, but without knowing the OP's needs, who can say if that's small enough? -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 156692
On 6/4/2014 4:18 PM, glen herrmannsfeldt wrote: > Tim Wescott <tim@seemywebsite.really> wrote: >>> On 6/3/2014 10:07 AM, Weiss wrote: > >>>> I want to ask you if it's feasible to create an ECG >>>> compression/decompression algorithm using decomposition of the ECG >>>> signal into orthogonal polynomials bases on FPGA. > > (snip) > >> Is comp.compression active? I haven't heard of it. > > It has been pretty quiet lately, as has comp.dsp. I've never seen a time when comp.compression had much useful activity, but from the postings I see there the people frequenting the group seem to understand the topic pretty well. I'm not sure the OP needs that particular group since he seems to have picked his compression algorithm. I don't know how that particular algorithm works so I can comment on how easy it would be to implement in an FPGA. Perhaps comp.compression can help him understand how to implement it. >> comp.dsp may be a good resource, too. ECG signals (assuming you mean >> electro cardio-gram) have some unique features that should make efficient >> compression both a joy and a terror, given that (a) the signal has a lot >> of "quiet time" with low information content, and (b) it's medical, which >> means that lives will depend on the fidelity of the reconstruction. > > OK, who remembers watching "Emergency!" many years ago. They have > a portable machine which, if I remember right, sends the signal > though a phone line. That is, pretty much an analog modem. > (Actually, one direction, so modulator on one end, demodulator > on the other.) Seems like that sets a limit on the needed > bandwidth. > > But I presume the needed bandwidth is a lot less than 4kHz. > >> Given the life-critical nature of the thing, I'd certainly want to start >> by finding a lossless compression method, and see if that's good enough. > > If you know exactly the features that are needed, you can compress > down to just those features. But the bandwidth seems low enough to > me, that I don't see why you need to work that hard. I would bet it is like SONAR work. They aren't likely to be willing to give up much fidelity because of fear of not conveying some information. Military SONAR doesn't compress the signal even when sending over expensive satellite links because there is no way to compress noise and most of the signal is noise. Compress that and you lose the opportunity to pull weak signals from it. If you could isolate the important features for compression you are just one step away from reading the EKG and eliminating the radiologist or whoever interprets those things. I expect they aren't interested in letting that happen. -- RickArticle: 156693
Tim Wescott <tim@seemywebsite.really> wrote: (snip, I wrote, regarding EKG signals) (I always heard it as EKG, thought I don't know why) >> But I presume the needed bandwidth is a lot less than 4kHz. (snip) >> If you know exactly the features that are needed, you can compress down >> to just those features. But the bandwidth seems low enough to me, that I >> don't see why you need to work that hard. > The OP did not say what he wanted to compress down to, true -- but your > small may be his huge. > My gut feel is that you can accurately reproduce an ECG signal with less > than 100Hz of bandwidth, but without knowing the OP's needs, who can say > if that's small enough? OK, so 100Hz, say 8 bit samples are enough, and 10s for total length, so 16000 bits. So, it won't fit in a tweet, but is small enough for just about everything else. -- glenArticle: 156694
In comp.arch.fpga, rickman <gnuarm@gmail.com> wrote: > On 6/4/2014 4:18 PM, glen herrmannsfeldt wrote: >> Tim Wescott <tim@seemywebsite.really> wrote: >>>> On 6/3/2014 10:07 AM, Weiss wrote: >> >>> Given the life-critical nature of the thing, I'd certainly want to start >>> by finding a lossless compression method, and see if that's good enough. >> >> If you know exactly the features that are needed, you can compress >> down to just those features. But the bandwidth seems low enough to >> me, that I don't see why you need to work that hard. > > I would bet it is like SONAR work. They aren't likely to be willing to > give up much fidelity because of fear of not conveying some information. > Military SONAR doesn't compress the signal even when sending over > expensive satellite links because there is no way to compress noise and > most of the signal is noise. Compress that and you lose the opportunity > to pull weak signals from it. > > If you could isolate the important features for compression you are just > one step away from reading the EKG and eliminating the radiologist or > whoever interprets those things. I expect they aren't interested in > letting that happen. Many people would be interested in that. But development and, mostly, certification of such a device will be far more than that of a 'simple' ECG monitor. Such a diagnostic device would have to be proved in probably years of clinical studies. For an ECG monitor it is enough to comply with existing standards as it is proven technology. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) When the going gets tough, the tough go shopping.Article: 156695
Recently i used the xfuzzy software create vhdl code. It was created vhdl code that used to xilinx edk add new project. and i search some information or literatures. It show GPIO and hardware BUS approaches. So i want to use GPIO approach build xfuzzy ip. my builded ways is : 1- add to xps_GPIO to system assembly view of edk and connect peripheral BU= S 2- generate addresses to instance=20 3-modify the fuzzy ip port.=20 this part ,case is my edk proj have gpio system and i want to use in1=E3=80= =81in2=E3=80=81out1=E3=80=81pipeline port connect it . But i am how to connect those port to gpio system. because i modify mhs and add xfuzzy ip with top.vhd document together. Moreover this is my first time design this project, it is let me feel order= less to work. who can somebody give suggest or other method? In here i post my original source code and project file. https://mega.co.nz/#!KU43XTKa!oJiLRPmI0OYIAAHcGQVxLhBoF3QYLxWp4cXA0PUnsY0Article: 156696
In comp.arch.fpga, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > Tim Wescott <tim@seemywebsite.really> wrote: > > (snip, I wrote, regarding EKG signals) > > (I always heard it as EKG, thought I don't know why) > >>> But I presume the needed bandwidth is a lot less than 4kHz. > > (snip) > >>> If you know exactly the features that are needed, you can compress down >>> to just those features. But the bandwidth seems low enough to me, that I >>> don't see why you need to work that hard. > >> The OP did not say what he wanted to compress down to, true -- but your >> small may be his huge. > >> My gut feel is that you can accurately reproduce an ECG signal with less >> than 100Hz of bandwidth, but without knowing the OP's needs, who can say >> if that's small enough? > > OK, so 100Hz, say 8 bit samples are enough, and 10s for total length, > so 16000 bits. So, it won't fit in a tweet, but is small enough > for just about everything else. > What bandwidth is required, depends on the application. IIRC, the standard bandwidth for 'normal' ECG is 150Hz. For that you would at least need 300SPS, and I believe 500SPS is commonly used. But in some conditions higher rates are required. For some applications, 10 seconds may be enough. But in others you would want to see an entire 24h period, looking for rate variations and other abnormalities. And resolution? 8-bit may be enough in some applications to send to send the filtered result. Aquisition is often done at 24-bit, but this usually includes a large DC offset. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) The meek shall inherit the earth -- they are too weak to refuse.Article: 156697
>For some applications, 10 seconds may be enough. But in others you would >want to see an entire 24h period, looking for rate variations and other >abnormalities. > >And resolution? 8-bit may be enough in some applications to send to send >the filtered result. Aquisition is often done at 24-bit, but this usually >includes a large DC offset. > >-- >Stef Exactly, this algorithm is needed for those cases where you need to record 24H worth of the signal, and then upload it, which will take too much time with no or lossless compression. I just want to be clear about this, so basically, this algorithm has to : 1- Sample the ECG signal (Analog) to pick every cardiac cycle. 2- Decompose every cardiac cycle signal using an orthogonal polynomial base (Legendre polynomials for example). 3- Save the more relevant coefficients of this decomposition, it's the compression part. (These coefficients will be used to recreate the signal) And all that must be done on an FPGA. And about the comp.compression, i don't know which one you are referring to, because i only found one Google group. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156698
In article <M-idnfszQIRIWA3OnZ2dnUVZ_tSdnZ2d@giganews.com>, "Weiss" <100383@embeddedrelated> writes: [ECG compression] >And all that must be done on an FPGA. Why? That seems like a poor approach. It will be much simpler and cheaper to do it in software. -- These are my opinions. I hate spam.Article: 156699
On 6/5/2014 3:32 PM, Weiss wrote: >> For some applications, 10 seconds may be enough. But in others you would >> want to see an entire 24h period, looking for rate variations and other >> abnormalities. >> >> And resolution? 8-bit may be enough in some applications to send to send >> the filtered result. Aquisition is often done at 24-bit, but this usually >> includes a large DC offset. >> >> -- >> Stef > > Exactly, this algorithm is needed for those cases where you need to record > 24H worth of the signal, and then upload it, which will take too much time > with no or lossless compression. > > I just want to be clear about this, so basically, this algorithm has to : > 1- Sample the ECG signal (Analog) to pick every cardiac cycle. > 2- Decompose every cardiac cycle signal using an orthogonal polynomial base > (Legendre polynomials for example). > 3- Save the more relevant coefficients of this decomposition, it's the > compression part. (These coefficients will be used to recreate the signal) > > And all that must be done on an FPGA. Ok, so where is the question? > And about the comp.compression, i don't know which one you are referring > to, because i only found one Google group. I'm not sure what to say. comp.compression is a newsgroup just like comp.arch.fpga. I only suggested that group in case you were not familiar with the math behind the compression method. If you understand the algorithm then implementation is the next step. I take it you are not familiar with FPGAs? What exactly do you need help with? -- Rick
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