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
Flying the flag for our range http://www.enterpoint.co.uk/boardproducts.html. There is also a university program if that is relevant - http://www.enterpoint.co.uk/uap/uap.html. Most of the range are available for next day, or day after, delivery to N America and Europe. Other countries may take one or two more days. The only boards that might be of interest to a starter that are currently out of stock are the Drigmorn and some of the Craignell1 boards. These are in a remake cycle and should be available again in a few weeks. If you have a particular application or project in mind it would be worth telling the group. Some boards may be better than others for a given application. John Adair Enterpoint Ltd. On 11 May, 03:08, Samuel Thomas Kerr <stk...@cs.purdue.edu> wrote: > Hi guys, I'd like to get started with FPGAs and I'm looking for a good > development board to get started with. > > Could you please point me to some good boards?Article: 140376
Good Day, All: I am looking for a reference design for coprocessor architecture: Xilinx FPGA + TI DSP. Does anyone know open source project or reference design like what I need? I have done many times of internet digging without results. I believe EMIF interface between the two is fast, any faster interface? Altera has some refreence designs however this time I'll stick to Xilinx with better hardware performance and flexibility. Thank you all.Article: 140377
On May 11, 1:29=A0pm, pe...@xilinx.com wrote:
> I am surprised about the interest in write_first vs read_first.
> The read output during a write operation came really about as an
> afterthought. ("It's easy, theportis already there, so it costs
> nothing").
> But why do you want to read from the same location that you are
> writing to?
For "READ_FIRST" it makes sense. Your reading an old value and
the same time your updating a new value. For us it's an image
processing algorithm, where pixels are going into a line buffer.
We needed line[n-1] pixel value now (the READ data), along with
the current value (the WRITE data). On the next line the
previously written data is now line[n-1], repeat. So the
address of the READ, and WRITE are ALWAYS the same (the column
address). So (depending on how you count things) this consumes
one RAM port.
> Especially when you are reading what you already know, since you
> simultaneously are writing it (which was the original mode).
> Then we found that read-before-write was an easy modification, and
> more valuable.
I agree, "WRITE_FIRST" has more limited utility. I didn't know
the history that was the only available mode previously.
> But still: why do you read from the write address, when you have a
> separate readportwith its own dedicated addressing available?
Yes, Xilinx has "True Dual Port", but I'd rather
code to the minimum that I need in tech independant manner,
and let the tool build from what's available.
If the tool can't build it I'd rather it barf and quit, rather
than just build something willy-nilly that doesn't match the
description. (okay, a bit snarky - I guess I'm still a little
sore over all that time in the lab debugging an XST issue...)
--Mark
Article: 140378
On May 11, 4:04=A0pm, Mark <m...@cacurry.net> wrote:
> On May 11, 1:29=A0pm, pe...@xilinx.com wrote:
>
> > I am surprised about the interest in write_first vs read_first.
> > The read output during a write operation came really about as an
> > afterthought. ("It's easy, theportis already there, so it costs
> > nothing").
> > But why do you want to read from the same location that you are
> > writing to?
>
> For "READ_FIRST" it makes sense. =A0Your reading an old value and
> the same time your updating a new value. =A0For us it's an image
> processing algorithm, where pixels are going into a line buffer.
> We needed line[n-1] pixel value now (the READ data), along with
> the current value (the WRITE data). =A0On the next line the
> previously written data is now line[n-1], repeat. =A0So the
> address of the READ, and WRITE are ALWAYS the same (the column
> address). =A0So (depending on how you count things) this consumes
> one RAM port.
>
> > Especially when you are reading what you already know, since you
> > simultaneously are writing it (which was the original mode).
> > Then we found that read-before-write was an easy modification, and
> > more valuable.
>
> I agree, "WRITE_FIRST" has more limited utility. =A0I didn't know
> the history that was the only available mode previously.
>
> > But still: why do you read from the write address, when you have a
> > separate readportwith its own dedicated addressing available?
>
> Yes, Xilinx has "True Dual Port", but I'd rather
> code to the minimum that I need in tech independant manner,
> and let the tool build from what's available.
>
> If the tool can't build it I'd rather it barf and quit, rather
> than just build something willy-nilly that doesn't match the
> description. =A0(okay, a bit snarky - I guess I'm still a little
> sore over all that time in the lab debugging an XST issue...)
>
> --Mark
Mark, there are clearly several different ways to implement your
design: single port with read-before-write (the most elegant way),
or dual-port with duplicated offset addressing,
or even time-sequenced read-then-write, time permitting.
It is frustrating to know that it can be done, but not be able to do
it.
Maybe you expect the synthesizers to be more versatile and smarter
than they really are.
Peter Alfke
Article: 140379
On May 11, 4:39=A0pm, pe...@xilinx.com wrote:
> On May 11, 4:04=A0pm, Mark <m...@cacurry.net> wrote:
>
>
>
>
>
> > On May 11, 1:29=A0pm, pe...@xilinx.com wrote:
>
> > > I am surprised about the interest in write_first vs read_first.
> > > The read output during a write operation came really about as an
> > > afterthought. ("It's easy, theportis already there, so it costs
> > > nothing").
> > > But why do you want to read from the same location that you are
> > > writing to?
>
> > For "READ_FIRST" it makes sense. =A0Your reading an old value and
> > the same time your updating a new value. =A0For us it's an image
> > processing algorithm, where pixels are going into a line buffer.
> > We needed line[n-1] pixel value now (the READ data), along with
> > the current value (the WRITE data). =A0On the next line the
> > previously written data is now line[n-1], repeat. =A0So the
> > address of the READ, and WRITE are ALWAYS the same (the column
> > address). =A0So (depending on how you count things) this consumes
> > one RAMport.
>
> > > Especially when you are reading what you already know, since you
> > > simultaneously are writing it (which was the original mode).
> > > Then we found that read-before-write was an easy modification, and
> > > more valuable.
>
> > I agree, "WRITE_FIRST" has more limited utility. =A0I didn't know
> > the history that was the only available mode previously.
>
> > > But still: why do you read from the write address, when you have a
> > > separate readportwith its own dedicated addressing available?
>
> > Yes, Xilinx has "TrueDualPort", but I'd rather
> > code to the minimum that I need in tech independant manner,
> > and let the tool build from what's available.
>
> > If the tool can't build it I'd rather it barf and quit, rather
> > than just build something willy-nilly that doesn't match the
> > description. =A0(okay, a bit snarky - I guess I'm still a little
> > sore over all that time in the lab debugging an XST issue...)
>
> > --Mark
>
> Mark, there are clearly several different ways to implement your
> design: singleportwith read-before-write (the most elegant way),
> ordual-portwith duplicated offset addressing,
> or even time-sequenced read-then-write, time permitting.
> It is frustrating to know that it can be done, but not be able to do
> it.
> Maybe you expect the synthesizers to be more versatile and smarter
> than they really are.
I'm not asking the synthesis tool to optimize across multiple
solutions.
A time-sequenced read-then-write would be an architecture change that
certainly outside the scope of a synthesis tool.
Inferring "Read_First" vs. "Write_First" behaviour correctly is quite
easily within the scope of the tool.
I just wanted to warn folks to check their template results closely
in the log files for these inferred RAMS. I was bitten, and
don't want others to repeat.
--Mark
Article: 140380
Have a look at the tools of HDL Works ('www.hdlworks.com'
(http://www.hdlworks.com)).
Devas
--
devas
------------------------------------------------------------------------
devas's Profile: http://www.fpgacentral.com/group/member.php?userid=84
View this thread: http://www.fpgacentral.com/group/showthread.php?t=89949
Article: 140381On May 11, 8:26=A0am, hamze60 <hamz...@gmail.com> wrote: > I want to design a space system and don't want to use airspace > expensive fpga. considering space radiation I want to make this system > fault tolerant. ACTEL is flash-based but in program lost condition > ( even with low probability ) it should be reprogrammed so a > programing circuit is also needed. Xilinx or Altera are RAMbased but > they have very small size EPROMs to store both hardware configuration > and software, so using multiple of EPROMs is possible for redundancy. > can anybody suggest better solution or even a new idea? You can also check this FPGA serie from Xilinx: http://www.xilinx.com/produ= cts/v4qv/index.htmArticle: 140382
On May 12, 12:22=A0pm, "Sebastien @ Sundance" <maury.sebast...@gmail.com> wrote: > On May 11, 8:26=A0am, hamze60 <hamz...@gmail.com> wrote: > > > I want to design a space system and don't want to use airspace > > expensive fpga. considering space radiation I want to make this system > > fault tolerant. ACTEL is flash-based but in program lost condition > > ( even with low probability ) it should be reprogrammed so a > > programing circuit is also needed. Xilinx or Altera are RAMbased but > > they have very small size EPROMs to store both hardware configuration > > and software, so using multiple of EPROMs is possible for redundancy. > > can anybody suggest better solution or even a new idea? > > You can also check this FPGA serie from Xilinx:http://www.xilinx.com/prod= ucts/v4qv/index.htm the OP asked for LOW COST not for HIGH COST AnttiArticle: 140383
On May 11, 10:51=A0pm, bigca...@gmail.com wrote: > Good Day, All: > > I am looking for a reference design for coprocessor architecture: > Xilinx FPGA + TI DSP. Does anyone know open source project or > reference design like what I need? > > I have done many times of internet digging without results. > > I believe EMIF interface between the two is fast, any faster > interface? > > Altera has some refreence designs however this time I'll stick to > Xilinx with better hardware performance and flexibility. > > Thank you all. Using the EMIF_A interface is the fastest and easier way to interface an Xilinx FPGA to a TI DSP (or several DSPs). Many hardware vendors, like Sundance (www.sundance.com) offer such COTS solutions. If you choose some C6455 DSPs, you would then be able to use the serial rapid I/O (SRIO) links, which are point-to-point. Four links are available per C6455 DSP, so you can reach 2.5Gbps x4 in terms of data rate between the DSP and the FPGA. For this solution, you would need to implement the Xilinx SRIO IP core. You can check: - SMT395: C6416T DSP with Virtex-II/Pro 30 (http://www.sundance.com/ web/files/productpage.asp?STRFilter=3DSMT395-VP30-6) - SMT362: Dual C6455 with Virtex-4 FX60 (http://www.sundance.com/web/ files/productpage.asp?STRFilter=3DSMT362) Thank you, - SebastienArticle: 140384
On May 11, 2:06=A0pm, "HT-Lab" <han...@ht-lab.com> wrote: > ><Antti.Luk...@googlemail.com> wrote in message > >news:0b8f026a-a206-4d6f-9f9d->97dd719de__BEGIN_MASK_n#9g02mG7!__...__END= _MASK_i?a63jfAD$z__@r36g2000vbr.googlegroups.com... > >On May 11, 10:26 am, hamze60 <hamz...@gmail.com> wrote: > >> I want to design a space system and don't want to use airspace > >> expensive fpga. considering space radiation I want to make this system > >> fault tolerant. ACTEL is flash-based but in program lost condition > >> ( even with low probability ) it should be reprogrammed so a > >> programing circuit is also needed. Xilinx or Altera are RAMbased but > >> they have very small size EPROMs to store both hardware configuration > >> and software, so using multiple of EPROMs is possible for redundancy. > >> can anybody suggest better solution or even a new idea? > > >sorry to ask this but where do you get low cost rocket to get to the > >thing into space? > > There are a number of places, in my previous company we used Ariane4 ASAP > and later Russian Cosmos launchers from Plesetsk (interesting place to sa= y > the least :-) > > We used military grade Actel A1010, A1020 and 1280 and they all worked gr= eat > but then again we launched into a quite a "mild" radiation orbit > (LEO,800KM), > > Hanswww.ht-lab.com > > > > >my son would be very interested, we had long discussion about rockets > >this weekend. > >he is only 6, so I had to spend lots of time explaining the laws of > >aerodynamics > >eg, why the rockets normally need tail-stabilizing wings when flying > >in air > >we later agreed that specially designer rocket body could also > >guarantee > >stable flight in the air (without any wings/stabilizers) if designed > >properly. > >(very likely i have to design such a rocket now!!) > > >Antti is it true that ACTEL ordinary products like ProASIC3 are safe for ( LEO, 800Km ) and there is no need for fault telorant design? is only shielding enough?Article: 140385
I got used to Altera, but now I have to launch a big project in Xilinx Virtex. My problem which I encountered today is that message: ERROR:Pack:1107 - Unable to combine the following symbols into a single IOB component: PAD symbol "clk200_n" (Pad Signal = clk200_n) SlaveBuffer symbol "u_infrastructure/u_ibufg_clk200/ SLAVEBUF.DIFFIN" (Output Signal = u_infrastructure/u_ibufg_clk200/SLAVEBUF.DIFFIN) An IO component of type IOB was chosen because the IO contains symbols and/or properties consistent with input, output, or bi-directional usage and contains no other symbols or properties that require a more specific IO component type. Each of the following constraints specifies an illegal physical site for a component of type IOB: Symbol "clk200_n" (LOC=C8 [Physical Site Type = IPAD]) The component type is determined by the types of logic and the properties and configuration of the logic it contains. Please double check that the types of logic elements and all of their relevant properties and configuration options are compatible with the physical site type of the constraint. Please correct the constraints accordingly. More or less, I understand the problem. Some important information is missing in my UCF file, which I prepared, but incorrectly. Please help me. What should I do to "correct the constraints accordingly"?Article: 140386
On 12 Mai, 15:06, Marteno Rodia <marteno_ro...@o2.pl> wrote: > I got used to Altera, but now I have to launch a big project in Xilinx > Virtex. > > My problem which I encountered today is that message: > > ERROR:Pack:1107 - Unable to combine the following symbols into a > single IOB > =A0 =A0component: > =A0 =A0 =A0 =A0 PAD symbol "clk200_n" (Pad Signal =3D clk200_n) > =A0 =A0 =A0 =A0 SlaveBuffer symbol "u_infrastructure/u_ibufg_clk200/ > SLAVEBUF.DIFFIN" (Output > =A0 =A0Signal =3D u_infrastructure/u_ibufg_clk200/SLAVEBUF.DIFFIN) > =A0 =A0An IO component of type IOB was chosen because the IO contains > symbols and/or > =A0 =A0properties consistent with input, output, or bi-directional usage > and > =A0 =A0contains no other symbols or properties that require a more > specific IO > =A0 =A0component type. > =A0 =A0Each of the following constraints specifies an illegal physical > site for a > =A0 =A0component of type IOB: > =A0 =A0 =A0 =A0 Symbol "clk200_n" (LOC=3DC8 [Physical Site Type =3D IPAD]= ) > =A0 =A0The component type is determined by the types of logic and the > properties and > =A0 =A0configuration of the logic it contains. Please double check that > the types of > =A0 =A0logic elements and all of their relevant properties and > configuration options > =A0 =A0are compatible with the physical site type of the constraint. > =A0 =A0Please correct the constraints accordingly. > > More or less, I understand the problem. Some important information is > missing in my UCF file, which I prepared, but incorrectly. Please help > me. What should I do to "correct the constraints accordingly"? Hi Marteno, looks like you want to use a differential clock Input (clk200_n) but you have placed it on a pad that has no such input (for clock signals) connected to it. Take a closer look at the datasheet for the locations of global clock inputs and their corresponding differential inputs. Have a nice synthesis EilertArticle: 140387
On May 8, 6:11=A0am, Joachim F=F6rster <J...@gmx.de> wrote: > We are using OpenCores CAN controller for some time now (with a SoC on > Xilinx FPGA). Works great, using it for Low- and HighSpeed CAN > (transceiver next to FPGA) - nothing to complain about :-). > It has the well-known SJA1000 interface, ... I agree, it works very well. You need to read the SJA1000 data sheet to find out how to use it. And you will need to interface the FPGA I/O to some kind of analogue transceiver chip to drive the bus e.g. TJA1040. -TArticle: 140388
i tried this description of RAM but i can't syntesize it and i have the following error: ERROR:Pack:18 - The design is too large for the given device and package. i think i will be to use the external SRAM FPGA's board, but i don't know if i can use it without EDK and how i can read and write in this SRAM.Article: 140389
I want to capture data from an ADC and send to PC though PCI-E. I prefer using the Virtex5 XC5VLX20T-FF323 to implement the PCI-E Lane X4 interface. I need real time data capturing, and the input data rate is about 500Mbytes per second. Although the PCI-E X4 could provide a data channel of about 800Mbytes per second (based on the Xilinx ML555 PCI-E X4 experiment data), I am afraid that if the host PC has other PCI-E devices(say video card or another data capture card), and the data transfer performance would be affected. Therefore I need proper data buffering: A. Use Block RAM to buffer captured data. The buffer is quite small, I could use twenty 36kBRAM at most, equivalent to 20X2Kbytes = 40Kbytes. I do not know whether this buffering depth is enough or not. If the PCI-E bus is very busy or other device is occupying for a long time, the buffer will overflow. B. Use external DDR2 memory to buffer captured data. The buffer depth is not a problem, but I need to implement an 32bit DDR2 interface, and the free user I/O of FF323 package is not enough. I have to choose XC5VLX30T-FF665, which will increase the cost largely. Now I am eager to prove that 20~40Kbytes buffer depth is enough for my application. However I check the PCI-E v1.1 spec for several days, this is not such conclusion or experiment data. Please give me some suggestions. Thanks a lot!Article: 140390
i tried a description of RAM but i can't syntesize it and i have the following error: ERROR:Pack:18 - The design is too large for the given device and package. i think i will be to use the external SRAM FPGA's board, but i don't know if i can use it without EDK and how i can read and write in this SRAM.Article: 140391
On Tue, 12 May 2009 06:06:42 -0700 (PDT), Marteno Rodia <marteno_rodia@o2.pl> wrote: >ERROR:Pack:1107 - Unable to combine the following symbols into a >single IOB > component: > PAD symbol "clk200_n" (Pad Signal = clk200_n) > SlaveBuffer symbol "u_infrastructure/u_ibufg_clk200/ ... >More or less, I understand the problem. Some important information is >missing in my UCF file, which I prepared, but incorrectly. Please help >me. What should I do to "correct the constraints accordingly"? By looking at your name of the pad (and assuming there is a clk200_p) I'm assuming you want differential IO. If that's the case you need to add a property to your UCF file marking them so ie LVPECL etc. Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 140392
On May 11, 4:04=A0pm, Mark <m...@cacurry.net> wrote:
> On May 11, 1:29=A0pm, pe...@xilinx.com wrote:
>
> > I am surprised about the interest in write_first vs read_first.
> > The read output during a write operation came really about as an
> > afterthought. ("It's easy, theportis already there, so it costs
> > nothing").
> > But why do you want to read from the same location that you are
> > writing to?
>
> For "READ_FIRST" it makes sense. =A0Your reading an old value and
> the same time your updating a new value. =A0For us it's an image
> processing algorithm, where pixels are going into a line buffer.
> We needed line[n-1] pixel value now (the READ data), along with
> the current value (the WRITE data). =A0On the next line the
> previously written data is now line[n-1], repeat. =A0So the
> address of the READ, and WRITE are ALWAYS the same (the column
> address). =A0So (depending on how you count things) this consumes
> one RAM port.
>
> > Especially when you are reading what you already know, since you
> > simultaneously are writing it (which was the original mode).
> > Then we found that read-before-write was an easy modification, and
> > more valuable.
>
> I agree, "WRITE_FIRST" has more limited utility. =A0I didn't know
> the history that was the only available mode previously.
>
> > But still: why do you read from the write address, when you have a
> > separate readportwith its own dedicated addressing available?
>
> Yes, Xilinx has "True Dual Port", but I'd rather
> code to the minimum that I need in tech independant manner,
> and let the tool build from what's available.
>
> If the tool can't build it I'd rather it barf and quit, rather
> than just build something willy-nilly that doesn't match the
> description. =A0(okay, a bit snarky - I guess I'm still a little
> sore over all that time in the lab debugging an XST issue...)
>
> --Mark
Mark, I listened to Obama's comment that his wife "has the right to
bear (bare) arms". That was a very clever pun, but it would not
translate into any other language.
If you expect your talk to be translated automatically (or even by
humans) into French, German, or Chinese, you have to avoid all such
clever constructs, and go for boring middle-of-the-road statements.
Same with logic design. If you design generically, you miss out on
many subtleties.
This is not meant as an excuse for Xilinx to misunderstand relatively
simple BRAM constructs...
Peter Alfke
Article: 140393On Tue, 12 May 2009 07:54:52 -0700 (PDT) vcar <hitsx@163.com> wrote: > I want to capture data from an ADC and send to PC though PCI-E. I > prefer using the Virtex5 XC5VLX20T-FF323 to implement the PCI-E Lane > X4 interface. I need real time data capturing, and the input data rate > is about 500Mbytes per second. Although the PCI-E X4 could provide a > data channel of about 800Mbytes per second (based on the Xilinx ML555 > PCI-E X4 experiment data), I am afraid that if the host PC has other > PCI-E devices(say video card or another data capture card), and the > data transfer performance would be affected. Therefore I need proper > data buffering: > > A. Use Block RAM to buffer captured data. The buffer is quite > small, I could use twenty 36kBRAM at most, equivalent to 20X2Kbytes = > 40Kbytes. I do not know whether this buffering depth is enough or > not. If the PCI-E bus is very busy or other device is occupying for a > long time, the buffer will overflow. > > B. Use external DDR2 memory to buffer captured data. The > buffer depth is not a problem, but I need to implement an 32bit DDR2 > interface, and the free user I/O of FF323 package is not enough. I > have to choose XC5VLX30T-FF665, which will increase the cost largely. > > Now I am eager to prove that 20~40Kbytes buffer depth is enough for my > application. However I check the PCI-E v1.1 spec for several days, > this is not such conclusion or experiment data. > > Please give me some suggestions. Thanks a lot! PCIe is a point-to-point link, not a shared bus. You own the four lanes coming up to your board entirely, no time sharing. The problem is that you don't know whether those lines go directly back to your northbridge/RAM controller or whether they're going through a PCIe-PCIe switch that you're sharing with other devices. But that's not anything you'll be able to find in the PCIe documentation, that's specific to the actual motherboard you're plugged into. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 140394
I have an ML403 devkit and am attempting to program the XCF32P by bit- banging the JTAG interface from a microcontroller devboard. My problem is that the FPGA does not want to configure with from the PROM when I load it this way. I have tried to troubleshoot the issue and found the following: 1. If I program the flash using iMPACT, erase Revision 0 (the only one I'm using), and then program Revision 0 from the microcontroller, the FPGA will configure successfully. When performing this test, I do verify that Revision 0 was successfully erased before I re-program it. 2. If I erase the entire flash, program the relevant registers (DATA- BTC, DATA-CCB, DATA-SUCR, and DONE), and then program Revision 0, the FPGA will NOT configure successfully. I have read out the configuration data as well as the non-data registers to verify they are identical to what is programmed via iMPACT. I can use iMPACT in my development environment but the final system will not have external access to the JTAG pins and so I need to find a way to program the flash from an initially blank state. Does anyone have any ideas why Method 2 is not working or other troubleshooting measures I can take? Is there a specific instruction sequence or timing restriction that must be adhered to even though all the registers and data seem correct?Article: 140395
On May 12, 8:34=A0pm, Dave <dhsch...@gmail.com> wrote: > I have an ML403 devkit and am attempting to program the XCF32P by bit- > banging the JTAG interface from a microcontroller devboard. My problem > is that the FPGA does not want to configure with from the PROM when I > load it this way. I have tried to troubleshoot the issue and found the > following: > > 1. If I program the flash using iMPACT, erase Revision 0 (the only one > I'm using), and then program Revision 0 from the microcontroller, the > FPGA will configure successfully. When performing this test, I do > verify that Revision 0 was successfully erased before I re-program it. > > 2. If I erase the entire flash, program the relevant registers (DATA- > BTC, DATA-CCB, DATA-SUCR, and DONE), and then program Revision 0, the > FPGA will NOT configure successfully. I have read out the > configuration data as well as the non-data registers to verify they > are identical to what is programmed via iMPACT. > > I can use iMPACT in my development environment but the final system > will not have external access to the JTAG pins and so I need to find a > way to program the flash from an initially blank state. Does anyone > have any ideas why Method 2 is not working or other troubleshooting > measures I can take? Is there a specific instruction sequence or > timing restriction that must be adhered to even though all the > registers and data seem correct? i had EXACT the same off behaviour after A LOT of figth i did win, and got it working i think there is also some XC32P revision issue, your ML403 may have different rev that has different behav then the production unit i can look my project, but it takes time (what i dont have) AnttiArticle: 140396
On May 12, 2:31=A0am, "Sebastien @ Sundance" <maury.sebast...@gmail.com> wrote: > On May 11, 10:51=A0pm, bigca...@gmail.com wrote: > > > Good Day, All: > > > I am looking for a reference design for coprocessor architecture: > > Xilinx FPGA + TI DSP. Does anyone know open source project or > > reference design like what I need? > > > I have done many times of internet digging without results. > > > I believe EMIF interface between the two is fast, any faster > > interface? > > > Altera has some refreence designs however this time I'll stick to > > Xilinx with better hardware performance and flexibility. > > > Thank you all. > > Using the EMIF_A interface is the fastest and easier way to interface > an Xilinx FPGA to a TI DSP (or several DSPs). Many hardware vendors, > like Sundance (www.sundance.com) offer such COTS solutions. > If you choose some C6455 DSPs, you would then be able to use the > serial rapid I/O (SRIO) links, which are point-to-point. Four links > are available per C6455 DSP, so you can reach 2.5Gbps x4 in terms of > data rate between the DSP and the FPGA. For this solution, you would > need to implement the Xilinx SRIO IP core. > > You can check: > - SMT395: C6416T DSP with Virtex-II/Pro 30 (http://www.sundance.com/ > web/files/productpage.asp?STRFilter=3DSMT395-VP30-6) > - SMT362: Dual C6455 with Virtex-4 FX60 (http://www.sundance.com/web/ > files/productpage.asp?STRFilter=3DSMT362) > > Thank you, > - Sebastien thanks, I'll take a look at it.Article: 140397
On May 12, 9:36=A0pm, bigca...@gmail.com wrote: > On May 12, 2:31=A0am, "Sebastien @ Sundance" <maury.sebast...@gmail.com> > wrote: > > > > > > > On May 11, 10:51=A0pm, bigca...@gmail.com wrote: > > > > Good Day, All: > > > > I am looking for a reference design for coprocessor architecture: > > > Xilinx FPGA + TI DSP. Does anyone know open source project or > > > reference design like what I need? > > > > I have done many times of internet digging without results. > > > > I believe EMIF interface between the two is fast, any faster > > > interface? > > > > Altera has some refreence designs however this time I'll stick to > > > Xilinx with better hardware performance and flexibility. > > > > Thank you all. > > > Using the EMIF_A interface is the fastest and easier way to interface > > an Xilinx FPGA to a TI DSP (or several DSPs). Many hardware vendors, > > like Sundance (www.sundance.com) offer such COTS solutions. > > If you choose some C6455 DSPs, you would then be able to use the > > serial rapid I/O (SRIO) links, which are point-to-point. Four links > > are available per C6455 DSP, so you can reach 2.5Gbps x4 in terms of > > data rate between the DSP and the FPGA. For this solution, you would > > need to implement the Xilinx SRIO IP core. > > > You can check: > > - SMT395: C6416T DSP with Virtex-II/Pro 30 (http://www.sundance.com/ > > web/files/productpage.asp?STRFilter=3DSMT395-VP30-6) > > - SMT362: Dual C6455 with Virtex-4 FX60 (http://www.sundance.com/web/ > > files/productpage.asp?STRFilter=3DSMT362) > > > Thank you, > > - Sebastien > > thanks, I'll take a look at it.- Hide quoted text - > > - Show quoted text - CommAgility also have boards with single, or multiple, TI DSPs connected to a Xilinx FPGA via EMIF. e.g. http://www.commagility.com/amc-d1f1.php I have used their boards, and I am impressed with them. Ken Morrow, Morrow Electronics Limited.Article: 140398
<lolita.tangier@gmail.com> wrote in message news:8c3adb4f-d8b7-4b74-aae5-199208feefc9@r36g2000vbr.googlegroups.com... >i tried a description of RAM but i can't syntesize it and i have > the following error: > > ERROR:Pack:18 - The design is too large for the given device and > package. > > i think i will be to use the external SRAM FPGA's board, but i don't > know if i can use it without EDK and how i can read and write in this > SRAM. Search the docs for examples on loading the configuration from serial flash. Avnet has a few good tutorials on how to do this on their boards in particular. The concepts apply to others boards in general.Article: 140399
Try decreasing the size of leds/push/dip (if applicable) on the address tab of system assembly view. On May 12, 4:13=A0pm, lolita.tang...@gmail.com wrote: > i tried a description of RAM but i can't syntesize it and i have > the following error: > > ERROR:Pack:18 - The design is too large for the given device and > package. > > i think i will be to use the external SRAM FPGA's board, but i don't > know if i can use it without EDK and how i can read and write in this > SRAM.
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