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 Does anyone have a working vhdl sample that will teach me to to write and read to spartan 3 block ram? I used the language templates to create this vhdl for a ram in write first mode. process (clk) begin if (clk'event and clk = '1') then if (en = '1') then if (we = '1') then RAMX(conv_integer(addr)) <= di; do <= di; else do <= RAMX(conv_integer(addr)); end if; end if; end if; end process; I have a single global clock in my design. ThanksArticle: 134651
Subroto Datta wrote: > On Aug 19, 11:12 pm, Jamie Morken <jmor...@shaw.ca> wrote: >> Nial Stewart wrote: >>>> Hi, >>>> How does the vertical migration, using different parts with the same package work with the altera >>>> cyclone 3 devices? For the EP3C40 and >>>> EP3C16 parts in the FBGA464 packages, pin D7 is gnd on the 16K part, >>>> and D7 is diffio on the 40K part. Also some gnd pins on the 40K part >>>> are I/O on the 16K part. So to design a PCB that can work with both of >>>> these parts alot of extra I/O will have to be grounded I guess? >>>> cheers, >>>> Jamie >>> Jamie, >>> Be careful here the documentation's not that clear, you could easily get >>> your fingers burnt with this migration. >>> We discovered that the vref's change position between the different >>> devices that are supposed to be 'easily' migrate-able. It took a >>> big spreadsheet cross-referencing the three parts (we wanted to >>> be able to use the '55 too) to get a pinout that was compatable. >> Hi, >> >> You wouldn't happen to still have that spreadsheet would you? :) >> >> I went through the pin differences between the EP3C40 and EP3C16 parts >> in the FBGA484 package, and verified there are 22 I/O in the EP3C16 that >> can't be used in a EP3C40 compatible layout, and also there are 7 I/O in >> the EP3C40 that can't be used in a EP3C16 compatible layout, so the end >> result is a layout with 7 fewer I/O than the EP3C40 has in order to make >> it work with both parts. I didn't notice any vref's changing positions >> between these two parts, but you got me scared now ;) >> >> The 7 I/O on the EP3C40 that can't be used in a EP3C16 compatible layout >> are package balls: >> D7 >> H8 >> J5 >> J8 >> T13 >> U16 >> U17 >> >> The 22 I/O on the EP3C16 that can't be used in a EP3C40 compatible >> layout are package balls: >> F12 >> G12 >> H12 >> H13 >> H9 >> J15 >> J16 >> K15 >> K16 >> L15 >> L16 >> M15 >> N14 >> N15 >> P14 >> P8 >> R10 >> R11 >> R12 >> R13 >> R8 >> R9 >> >> so those 22+7 pins can be grounded or tied to VCC, and then that layout >> will work with both the parts, but a layout optimized only for the >> EP3C16 would have 29 more available I/O's. (346 instead of 317) >> >> Any verification of my results would be nice to hear, it is my first >> FPGA layout and first real BGA PCB at the same time! >> >> cheers, >> Jamie >> >> >> >> >> >>> Nial.- Hide quoted text - >> - Show quoted text -- Hide quoted text - >> >> - Show quoted text - > > Hi Jamie, use the Pin Migration View in the Pin Planner. The > instructions are available at http://www.altera.com/literature/hb/qts/qts_qii52013.pdf > Pg 38-40. > > Hope this helps, > Subroto Datta > Altera Corp. Thanks! :) cheers, JamieArticle: 134652
bzigon wrote: > Does anyone have a working vhdl sample that will teach me to to write > and read to spartan 3 block ram? It looks to me like you do. Did your example not work? Mine is similar: http://mysite.verizon.net/miketreseler/block_ram.vhd > I have a single global clock in my design. Good. That will make things easier for you. -- Mike TreselerArticle: 134653
Hi, I have been trying to simulate Xilinx's MPMC (mpmc_v4_02_a, a DDR memory controller) in VCSMX. But it is not working. i.e., the MPMC_InitDone is at value '0' for some time then goes to 'z' indefinitely. But the same MPMC is working OK in Modelsim,. How to do the MPMC simulation work in VCSMX? Has anyone tried it before, successfully? Best regards, MuthuArticle: 134654
Hi there, I'm making a kind of sniffer for a small network with very low traffic. I need to capture the traffic and store the packets in a permanent storage medium. At this time I'm using the ML403 board from Xilinx, EDK 10.1 and the xilfats library. As a preliminary test, I'm sending controlled individuals packets, and the device receive the packet and save it in a file into the CF card. This works for a time but the application crash after some time. With the xilfatfs library, I open a file, and at the reception of a packet I write the content and close the file. This step is repeated for every packet. I'm using a 64 K BRAM memory for the system. Using the defaults options for the linker script, the system hangs after receiving 15 packets (15 files). Increasing the stack size allows to handle more files but the system always hangs. Increasing too much the stack size is not a valid option, because in practice I need the system being able to handle large amount of data. Also, saving more packets in a single file allows to manage more information. For example, in this case I can save a total of 60 KB of data instead of 15 KB with small files before the system hangs. But in any case, this is far for the limits imposed for the FAT16 file- system, which is used in the CF card. In summary, I save the data in a temporal array which have fixed size, at the end I write the content of the array in a file and close the file. So, my question is: If I'm using a fixed amount of memory for the temporal data, and just one file open at any time, why the system go out of memory? I'm new on the embedded applications and I don't manage all the concepts about memory maps, linkers, etc. So I'm generally using the default options from the tools. I don't know if I 'm doing something wrong or there are some conceptual misconceptions. But I have been reading and trying a lot of hours without success. Any clue would be really appreciated. Cheers!Article: 134655
On Aug 22, 5:57=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > xilinx added a few packages, but not those that would be really in > demand > > 1) XC3SAN-200 TQFP144 > 2)XC3SAN-50/100 VQFP100 - maybe that does not fit the plastic? > 3) 8x8 mm paclage option for S3AN > 4) EASY BGA (0.5mm with 1 row spares for routing)- like the > siliconblue devices Where's the XC3S400AN in the same 256 BGA as the 200? =3DaArticle: 134656
On Aug 19, 5:25=A0am, morphiend <morphi...@gmail.com> wrote: > On Aug 18, 1:04=A0pm, austin <aus...@xilinx.com> wrote: > > > I strongly recommend that folks try our forums at: > > >http://forums.xilinx.com/xlnx/ > > > where there is a healthy activity. > > By many people just looking for someone to do their work. At its re- > birth, it was filled with a decent amount of people honestly posting > about questions and problems. Now it has turned into a haven for those > who don't even take the time to read the names of the buttons on the > GUIs. They just so happened to get something from somewhere and then > they wonder why it doesn't work. </rant> > > I actually stopped browsing through it a few months back because of > the deluge of questions that either were barely comprehensible or just > down right looking for someone to fix their stuff. I have since > started reading it again, but am still a little underwhelmed. Ain't it the truth. A Xilinx support person sent me an e-mail, saying that I was not nice enough to a newbie whose post was so broad it was ridiculous. My first answer was succinct, his follow-up was equally confused, my response was "RTFM," and I was finally chewed out for daring to suggest that the newbie was lazy. I'm sorry, but sometimes, RTFM is the correct answer and the poster is indeed lazy. I suppose I could have ignored the guy's message; it would have been only one of the hundreds of unanswered "gimme help" posts. If Xilinx wants a forum full of unanswered broken-English "gimme help" posts, that's their prerogative. Good luck with that. -aArticle: 134657
On Aug 10, 4:11=A0pm, andersod2 <thechrisander...@gmail.com> wrote: > No prob...sorry I couldn't help more. =A0If you do a fresh install, > maybe just try removing those two programs, and double-checking the > registry that the appropriate entries are gone...then just ISE to see > if your upgraded version works right without MinGW there...I'd also be > curious to see what a registry cleaner has to say about that > entry...last time I cleaned my registry there was a buttload of > useless entries (guess I should do it more often than every 5 > years)... Hi there, Deleting all instances of MinGW and Xilinx (all but national instruments and the usb drivers for my eval board) has seemed to clear this issue up. thanks a lot for your suggestions :)Article: 134658
MikeWhy wrote: > "Ed McGettigan" <ed.mcgettigan@xilinx.com> wrote in message > news:g8kves$qql2@cnn.xsj.xilinx.com... >> ... >> online order tools today, but there should be no problems ordering >> these through a sales person at Avnet, NuHorizon or Silica. > > Not to be *too* cynical. Of course they'll take your order. I have open, > no-cancel no-refund backorders with Avnet dating from May. > > The NuHorizons site now has the new Spartan-3A part/package combinations listed with a lead time of 5 weeks. The Avnet site is still lagging, but I would expect to see these online shortly. I'm curious about your Avnet order from May which has either been on the books for 12 to 16 weeks. If you want to share the details with me through email, I'll take a look. Ed McGettigan -- Xilinx Inc.Article: 134659
I am working on a video project using an FPGA for all the signal processing and output video generation, as well as to control all the peripheral PHYs, and the image sensor chip. Now, one thing that concerns me is that there is a digital control interface to the imager IC (to the control the read out of imager rows/ cols, as well as other integrated functions), yet the video output from the imager is a single analog pin. The analog output is actually synchronized to a clock that is sent to the imager IC from the FPGA. Based on the timing diagram, the analog video should be sampled on the falling edge of the clock that is sent to the imager IC. Now in between the FPGA and the imager IC, I need a fast analog amplifier (to get the analog video in the correct voltage range to be sampled - this will depend on the input voltage accepted by the chosen ADC) and an ADC IC (to sample the analog video). I think both the ADC and the imager will run on the same clock (again, generated by the FPGA from external Osc.). My concern is with synchronizing the FPGA, the ADC, and the imager, so that the analog pixel values are sampled at the right time on the ADC (since they are sync'ed to the clock), and registered in at the right time by the FPGA (in the eye of the sampled data). I am worried that the PCB may introduce delays that will force me to have to manually tune (possibly several) clock phase shift(s) sent to the imager, the ADC, and the clock used in the FPGA to register in the sampled data. Each block will run at the same clock speed, but may need different phase offsets in order to account for delays induced by the PCB interconnect or delays through various ICs (phase delay through gain ckt, phase delay through sampler, etc). Does anyone have any thoughts on this? Perhaps there is a ref. design or white paper that you might know of that discusses how to handle capturing this kind of analog video output using an FPGA? Further assumptions/details: (comments appreciated) video clock: <=15MHz (based on frame rate required) ADC sample rate: >= 15MSPS? ADC sampler bits: 14 (set by system requirements, or should there be more than this, due to sampler noise or other PCB induced noise?) Analog Gain IC stop/pass band: (pass band should be uniformly flat and extend from DC to well above 15MHz, so as not to attenuate any analog pixel values?)Article: 134660
So many thanks Symon:) That exactly the application note i was looking for and the passwords. Don't really understund why Xilinx removed this application note without archiving it. And why they still provide the CentOS VM without at least a readme file with the passwords. Hope it will help other people too. BenArticle: 134661
On Aug 25, 12:08 pm, wallge <wal...@gmail.com> wrote: > I am working on a video project using an FPGA for all the signal > processing and output > video generation, as well as to control all the peripheral PHYs, and > the image sensor chip. Perhaps you could tell us which FPGA and which image sensor? > Now, one thing that concerns me is that there is a digital control > interface to the imager IC (to the control the read out of imager rows/ > cols, as well as other integrated functions), yet the video output > from the imager is a single analog pin. The analog output is actually > synchronized to a clock that is sent to the imager IC from the FPGA. > Based on the timing diagram, the analog video should be sampled on the > falling edge of the clock that is sent to the imager IC. > > Now in between the FPGA and the imager IC, I need a fast analog > amplifier (to get the analog video in the correct voltage range to be > sampled - this will depend on the input voltage accepted by the chosen > ADC) and an ADC IC (to sample the analog video). > I think both the ADC and the imager will run on the same clock (again, > generated by the FPGA from external Osc.). My concern is with > synchronizing the FPGA, the ADC, and the imager, so that the analog > pixel values are sampled at the right time on the ADC (since they are > sync'ed to the clock), and registered in at the right time by the FPGA > (in the eye of the sampled data). > I am worried that the PCB may introduce delays that will force me to > have to manually tune (possibly several) clock phase shift(s) sent to > the imager, the ADC, and the clock used in the FPGA to register in the > sampled data. Each block will run at the same clock speed, but may > need different phase offsets in order to account for delays induced by > the PCB interconnect or delays through various ICs (phase delay > through gain ckt, phase delay through sampler, etc). At 15 MHz, the PCB effects on phase should be almost negligible. I would recommend separate outputs from the FPGA for each clock load, however, as this would allow you to tune the relative phase. All clock loads inside the FPGA can be adjusted fairly easily if you have a typical modern FPGA with clock phase / DLL / PLL components. > Does anyone have any thoughts on this? Perhaps there is a ref. design > or white paper that you might know of that discusses how to handle > capturing this kind of analog video output using an FPGA? Your best bet for a reference design will be the image sensor manufacturer. > Further assumptions/details: (comments appreciated) > video clock: <=15MHz (based on frame rate required) > ADC sample rate: >= 15MSPS? > ADC sampler bits: 14 (set by system requirements, or should there be > more than this, due to sampler noise or other PCB induced noise?) More bits in the ADC cannot help you with noise. Work at separating noisy circuits as much as possible from the analog section, including the output signals from the ADC. Even if you have everything on one circuit board, design as if the image sensor and related analog electronics were on a separate board, with breaks in the power and ground planes. Place the ADC at the plane split. > Analog Gain IC stop/pass band: (pass band should be uniformly flat and > extend from DC to well above 15MHz, so as not to attenuate any analog > pixel values?) The output of an imager has frequency components significantly higher than the pixel rate. Remember that you would like to have a fairly flat voltage from the sensor during the sampling phase. Also remember that you can have full amplitude swing from one pixel to the next assuming you have sharp focus. Trimming down the bandwidth too much will blur the image horizontally. The noise-reduction vs bandwidth trade-off is not simple at 14 bits. You may want to look for an ADC that doesn't require an additional external gain stage especially if you really need the 14-bit linearity. Regards, GaborArticle: 134662
On Aug 25, 1:48=A0pm, Gabor <ga...@alacron.com> wrote: > On Aug 25, 12:08 pm, wallge <wal...@gmail.com> wrote: > > > I am working on a video project using an FPGA for all the signal > > processing and output > > video generation, as well as to control all the peripheral PHYs, and > > the image sensor chip. > > Perhaps you could tell us which FPGA and which image sensor? > > > > > Now, one thing that concerns me is that there is a digital control > > interface to the imager IC (to the control the read out of imager rows/ > > cols, as well as other integrated functions), yet the video output > > from the imager is a single analog pin. The analog output is actually > > synchronized to a clock that is sent to the imager IC from the FPGA. > > Based on the timing diagram, the analog video should be sampled on the > > falling edge of the clock that is sent to the imager IC. > > > Now in between the FPGA and the imager IC, I need a fast analog > > amplifier (to get the analog video in the correct voltage range to be > > sampled - this will depend on the input voltage accepted by the chosen > > ADC) and an ADC IC (to sample the analog video). > > I think both the ADC and the imager will run on the same clock (again, > > generated by the FPGA from external Osc.). My concern is with > > synchronizing the FPGA, the ADC, and the imager, so that the analog > > pixel values are sampled at the right time on the ADC (since they are > > sync'ed to the clock), and registered in at the right time by the FPGA > > (in the eye of the sampled data). > > I am worried that the PCB may introduce delays that will force me to > > have to manually tune (possibly several) clock phase shift(s) sent to > > the imager, the ADC, and the clock used in the FPGA to register in the > > sampled data. =A0Each block will run at the same clock speed, but may > > need different phase offsets in order to account for delays induced by > > the PCB interconnect or delays through various ICs (phase delay > > through gain ckt, phase delay through sampler, etc). > > At 15 MHz, the PCB effects on phase should be almost negligible. =A0I > would recommend separate outputs from the FPGA for each clock > load, however, as this would allow you to tune the relative phase. > > All clock loads inside the FPGA can be adjusted fairly easily if > you have a typical modern FPGA with clock phase / DLL / PLL > components. > > > Does anyone have any thoughts on this? Perhaps there is a ref. design > > or white paper that you might know of that discusses how to handle > > capturing this kind of analog video output using an FPGA? > > Your best bet for a reference design will be the image sensor > manufacturer. > > > Further assumptions/details: (comments appreciated) > > video clock: <=3D15MHz (based on frame rate required) > > ADC sample rate: >=3D 15MSPS? > > ADC sampler bits: 14 (set by system requirements, or should there be > > more than this, due to sampler noise or other PCB induced noise?) > > More bits in the ADC cannot help you with noise. =A0Work at separating > noisy circuits as much as possible from the analog section, including > the output signals from the ADC. =A0Even if you have everything on one > circuit board, design as if the image sensor and related analog > electronics were on a separate board, with breaks in the power > and ground planes. =A0Place the ADC at the plane split. > > > Analog Gain IC stop/pass band: (pass band should be uniformly flat and > > extend from DC to well above 15MHz, so as not to attenuate any analog > > pixel values?) > > The output of an imager has frequency components significantly higher > than the pixel rate. =A0Remember that you would like to have a fairly > flat > voltage from the sensor during the sampling phase. =A0Also remember that > you can have full amplitude swing from one pixel to the next assuming > you have sharp focus. =A0Trimming down the bandwidth too much will > blur the image horizontally. =A0The noise-reduction vs bandwidth > trade-off is not simple at 14 bits. =A0You may want to look for an ADC > that doesn't require an additional external gain stage especially if > you really need the 14-bit linearity. > > Regards, > Gabor Gabor, thanks for the response. I can't say which image sensor due to NDA, but I can say that there is no ref. design sensor. I am looking at using cyclone III for main FPGA.Article: 134663
On Aug 24, 7:47=A0pm, Mike Treseler <mtrese...@gmail.com> wrote: > bzigon wrote: > > Does anyone have a working vhdl sample that will teach me to to write > > and read to spartan 3 block ram? > > It looks to me like you do. > Did your example not work? > > Mine is similar:http://mysite.verizon.net/miketreseler/block_ram.vhd > > > I have a single global clock in my design. > > Good. That will make things easier for you. > > =A0 -- Mike Treseler Mike The vhdl that I posted is for the RAM itself. I have it wrapped in an entity. I just didnt post the entity definition. I instance the ram entity in my design. Let's assume I want to write the byte value 7 into location 8. How do I do that? Similarly, how do I read the contents of ram location 22? I suspect these require state machines. I also have setup and hold times that I assume must be met. How do I perform these reads and writes so that the setup and hold times are met? BobArticle: 134664
Hello, all, I just got a potential project thrown in my lap. I designed an all-analog delay generator module, with 32 delays that trigger 32 pulse widths. So, basically, 64 wide-range programmable one-shots on one board. LVDS in, ECL out (for legacy gear). These one-shots can be programmed from about 10 ns to 12 us in several ranges. Somebody asked, "Gee, couldn't you do that with an FPGA?" Well, a few years ago, maybe not. So, could anyone suggest some fast FPGAs that can handle clocks in the 500+ MHz range? I normally work with Xilinx, but could look at some others, too. I suspect RAM-based FPGAs would be desirable over one-time programmed. It would not be a problem to use several smaller FPGAs to keep them from overheating at the high clock rate. We have forced-air cooling in the equipment, but you lose that when modules are put on extenders. The basic circuit would look like a 13-bit counter with a 13-bit preset register, and a zero comparator. (It could also be a 13-bit counter that starts at zero, and a preset register that sets the terminal count.) So, 432 FFs would do 8 channels of this dual one-shot logic. Half of the FFs would be clocked at the 500+ MHz rate, the other half would be essentially static. Thanks in advance for any suggestions! JonArticle: 134665
On Mon, 25 Aug 2008 09:08:12 -0700, wallge wrote: > Does anyone have any thoughts on this? Perhaps there is a ref. design > or white paper that you might know of that discusses how to handle > capturing this kind of analog video output using an FPGA? You have a system with various delays. I not sure that you will find a white paper on it - you just need to understand where the delays are in your system and ensure your signals come out of your FPGA at the right times. After reading your post, it looks to me that you need to just look in the data sheets for the devices in your system. Paul.Article: 134666
On Aug 25, 1:17=A0pm, wallge <wal...@gmail.com> wrote: > On Aug 25, 1:48=A0pm, Gabor <ga...@alacron.com> wrote: > > > > > > > On Aug 25, 12:08 pm, wallge <wal...@gmail.com> wrote: > > > > I am working on a video project using an FPGA for all the signal > > > processing and output > > > video generation, as well as to control all the peripheral PHYs, and > > > the image sensor chip. > > > Perhaps you could tell us which FPGA and which image sensor? > > > > Now, one thing that concerns me is that there is a digital control > > > interface to the imager IC (to the control the read out of imager row= s/ > > > cols, as well as other integrated functions), yet the video output > > > from the imager is a single analog pin. The analog output is actually > > > synchronized to a clock that is sent to the imager IC from the FPGA. > > > Based on the timing diagram, the analog video should be sampled on th= e > > > falling edge of the clock that is sent to the imager IC. > > > > Now in between the FPGA and the imager IC, I need a fast analog > > > amplifier (to get the analog video in the correct voltage range to be > > > sampled - this will depend on the input voltage accepted by the chose= n > > > ADC) and an ADC IC (to sample the analog video). > > > I think both the ADC and the imager will run on the same clock (again= , > > > generated by the FPGA from external Osc.). My concern is with > > > synchronizing the FPGA, the ADC, and the imager, so that the analog > > > pixel values are sampled at the right time on the ADC (since they are > > > sync'ed to the clock), and registered in at the right time by the FPG= A > > > (in the eye of the sampled data). > > > I am worried that the PCB may introduce delays that will force me to > > > have to manually tune (possibly several) clock phase shift(s) sent to > > > the imager, the ADC, and the clock used in the FPGA to register in th= e > > > sampled data. =A0Each block will run at the same clock speed, but may > > > need different phase offsets in order to account for delays induced b= y > > > the PCB interconnect or delays through various ICs (phase delay > > > through gain ckt, phase delay through sampler, etc). > > > At 15 MHz, the PCB effects on phase should be almost negligible. =A0I > > would recommend separate outputs from the FPGA for each clock > > load, however, as this would allow you to tune the relative phase. > > > All clock loads inside the FPGA can be adjusted fairly easily if > > you have a typical modern FPGA with clock phase / DLL / PLL > > components. > > > > Does anyone have any thoughts on this? Perhaps there is a ref. design > > > or white paper that you might know of that discusses how to handle > > > capturing this kind of analog video output using an FPGA? > > > Your best bet for a reference design will be the image sensor > > manufacturer. > > > > Further assumptions/details: (comments appreciated) > > > video clock: <=3D15MHz (based on frame rate required) > > > ADC sample rate: >=3D 15MSPS? > > > ADC sampler bits: 14 (set by system requirements, or should there be > > > more than this, due to sampler noise or other PCB induced noise?) > > > More bits in the ADC cannot help you with noise. =A0Work at separating > > noisy circuits as much as possible from the analog section, including > > the output signals from the ADC. =A0Even if you have everything on one > > circuit board, design as if the image sensor and related analog > > electronics were on a separate board, with breaks in the power > > and ground planes. =A0Place the ADC at the plane split. > > > > Analog Gain IC stop/pass band: (pass band should be uniformly flat an= d > > > extend from DC to well above 15MHz, so as not to attenuate any analog > > > pixel values?) > > > The output of an imager has frequency components significantly higher > > than the pixel rate. =A0Remember that you would like to have a fairly > > flat > > voltage from the sensor during the sampling phase. =A0Also remember tha= t > > you can have full amplitude swing from one pixel to the next assuming > > you have sharp focus. =A0Trimming down the bandwidth too much will > > blur the image horizontally. =A0The noise-reduction vs bandwidth > > trade-off is not simple at 14 bits. =A0You may want to look for an ADC > > that doesn't require an additional external gain stage especially if > > you really need the 14-bit linearity. > > > Regards, > > Gabor > > Gabor, > > thanks for the response. > I can't say which image sensor due to NDA, but > I can say that there is no ref. design sensor. > I am looking at using cyclone III for main FPGA.- Hide quoted text - > > - Show quoted text - Why you need to worry about timing since image sensor output is an "analog" signal ?Article: 134667
On Aug 25, 3:08 pm, Jon Elson <el...@wustl.edu> wrote: > Hello, all, > > I just got a potential project thrown in my lap. I designed an > all-analog delay generator module, with 32 delays that trigger 32 pulse > widths. So, basically, 64 wide-range programmable one-shots on one > board. LVDS in, ECL out (for legacy gear). These one-shots can be > programmed from about 10 ns to 12 us in several ranges. > > Somebody asked, "Gee, couldn't you do that with an FPGA?" Well, a few > years ago, maybe not. So, could anyone suggest some fast FPGAs that can > handle clocks in the 500+ MHz range? I normally work with Xilinx, but > could look at some others, too. I suspect RAM-based FPGAs would be > desirable over one-time programmed. It would not be a problem to use > several smaller FPGAs to keep them from overheating at the high clock > rate. We have forced-air cooling in the equipment, but you lose that > when modules are put on extenders. > > The basic circuit would look like a 13-bit counter with a 13-bit preset > register, and a zero comparator. (It could also be a 13-bit counter > that starts at zero, and a preset register that sets the terminal > count.) So, 432 FFs would do 8 channels of this dual one-shot logic. > Half of the FFs would be clocked at the 500+ MHz rate, the other half > would be essentially static. > > Thanks in advance for any suggestions! > > Jon Do you really need 500 MHz, or are just assuming that because you want 2ns resolution? For example using DDR outputregisters and a 250 MHz clock you can also get 2nS resolution and perhaps save some money over the Virtex 5 class of part you need at 500 MHz.Article: 134668
On Aug 25, 3:35=A0pm, Marlboro <cco...@netscape.net> wrote: > On Aug 25, 1:17=A0pm, wallge <wal...@gmail.com> wrote: > > > > > > > On Aug 25, 1:48=A0pm, Gabor <ga...@alacron.com> wrote: > > > > On Aug 25, 12:08 pm, wallge <wal...@gmail.com> wrote: > > > > > I am working on a video project using an FPGA for all the signal > > > > processing and output > > > > video generation, as well as to control all the peripheral PHYs, an= d > > > > the image sensor chip. > > > > Perhaps you could tell us which FPGA and which image sensor? > > > > > Now, one thing that concerns me is that there is a digital control > > > > interface to the imager IC (to the control the read out of imager r= ows/ > > > > cols, as well as other integrated functions), yet the video output > > > > from the imager is a single analog pin. The analog output is actual= ly > > > > synchronized to a clock that is sent to the imager IC from the FPGA= . > > > > Based on the timing diagram, the analog video should be sampled on = the > > > > falling edge of the clock that is sent to the imager IC. > > > > > Now in between the FPGA and the imager IC, I need a fast analog > > > > amplifier (to get the analog video in the correct voltage range to = be > > > > sampled - this will depend on the input voltage accepted by the cho= sen > > > > ADC) and an ADC IC (to sample the analog video). > > > > I think both the ADC and the imager will run on the same clock (aga= in, > > > > generated by the FPGA from external Osc.). My concern is with > > > > synchronizing the FPGA, the ADC, and the imager, so that the analog > > > > pixel values are sampled at the right time on the ADC (since they a= re > > > > sync'ed to the clock), and registered in at the right time by the F= PGA > > > > (in the eye of the sampled data). > > > > I am worried that the PCB may introduce delays that will force me t= o > > > > have to manually tune (possibly several) clock phase shift(s) sent = to > > > > the imager, the ADC, and the clock used in the FPGA to register in = the > > > > sampled data. =A0Each block will run at the same clock speed, but m= ay > > > > need different phase offsets in order to account for delays induced= by > > > > the PCB interconnect or delays through various ICs (phase delay > > > > through gain ckt, phase delay through sampler, etc). > > > > At 15 MHz, the PCB effects on phase should be almost negligible. =A0I > > > would recommend separate outputs from the FPGA for each clock > > > load, however, as this would allow you to tune the relative phase. > > > > All clock loads inside the FPGA can be adjusted fairly easily if > > > you have a typical modern FPGA with clock phase / DLL / PLL > > > components. > > > > > Does anyone have any thoughts on this? Perhaps there is a ref. desi= gn > > > > or white paper that you might know of that discusses how to handle > > > > capturing this kind of analog video output using an FPGA? > > > > Your best bet for a reference design will be the image sensor > > > manufacturer. > > > > > Further assumptions/details: (comments appreciated) > > > > video clock: <=3D15MHz (based on frame rate required) > > > > ADC sample rate: >=3D 15MSPS? > > > > ADC sampler bits: 14 (set by system requirements, or should there b= e > > > > more than this, due to sampler noise or other PCB induced noise?) > > > > More bits in the ADC cannot help you with noise. =A0Work at separatin= g > > > noisy circuits as much as possible from the analog section, including > > > the output signals from the ADC. =A0Even if you have everything on on= e > > > circuit board, design as if the image sensor and related analog > > > electronics were on a separate board, with breaks in the power > > > and ground planes. =A0Place the ADC at the plane split. > > > > > Analog Gain IC stop/pass band: (pass band should be uniformly flat = and > > > > extend from DC to well above 15MHz, so as not to attenuate any anal= og > > > > pixel values?) > > > > The output of an imager has frequency components significantly higher > > > than the pixel rate. =A0Remember that you would like to have a fairly > > > flat > > > voltage from the sensor during the sampling phase. =A0Also remember t= hat > > > you can have full amplitude swing from one pixel to the next assuming > > > you have sharp focus. =A0Trimming down the bandwidth too much will > > > blur the image horizontally. =A0The noise-reduction vs bandwidth > > > trade-off is not simple at 14 bits. =A0You may want to look for an AD= C > > > that doesn't require an additional external gain stage especially if > > > you really need the 14-bit linearity. > > > > Regards, > > > Gabor > > > Gabor, > > > thanks for the response. > > I can't say which image sensor due to NDA, but > > I can say that there is no ref. design sensor. > > I am looking at using cyclone III for main FPGA.- Hide quoted text - > > > - Show quoted text - > > Why you need to worry about timing since image sensor output is an > "analog" signal ?- Hide quoted text - > > - Show quoted text - If I was you I would like to have something to control the phaseshift for the clocks going ADC and the sensorArticle: 134669
On Aug 25, 12:08=A0pm, Jon Elson <el...@wustl.edu> wrote: > Hello, all, > > I just got a potential project thrown in my lap. =A0I designed an > all-analog delay generator module, with 32 delays that trigger 32 pulse > widths. =A0So, basically, 64 wide-range programmable one-shots on one > board. =A0LVDS in, ECL out (for legacy gear). =A0These one-shots can be > programmed from about 10 ns to 12 us in several ranges. > > Somebody asked, "Gee, couldn't you do that with an FPGA?" =A0Well, a few > years ago, maybe not. =A0So, could anyone suggest some fast FPGAs that ca= n > handle clocks in the 500+ MHz range? =A0I normally work with Xilinx, but > could look at some others, too. =A0I suspect RAM-based FPGAs would be > desirable over one-time programmed. =A0It would not be a problem to use > several smaller FPGAs to keep them from overheating at the high clock > rate. =A0We have forced-air cooling in the equipment, but you lose that > when modules are put on extenders. > > The basic circuit would look like a 13-bit counter with a 13-bit preset > register, and a zero comparator. =A0(It could also be a 13-bit counter > that starts at zero, and a preset register that sets the terminal > count.) =A0So, 432 FFs would do 8 channels of this dual one-shot logic. > Half of the FFs would be clocked at the 500+ MHz rate, the other half > would be essentially static. > > Thanks in advance for any suggestions! > > Jon You can feed a 500 MHz clock to a Spartan3 style device, use a divide- by-2 in the DCM, and clock the output I/O blocks with the 250MHz clock in DDR mode. You just need to handle the logic to deal with odd/even starts and stops. I don't think you'll have power problems running only 32 channels of 13-bit counters but a power analysis will give you an idea of the actual need (XPOWER tool?). The counters are simple. The DDR is straightforward. The boundary conditions are limited. If you want better than 2ns resolution, you can use the SERDES channels on a Virtex-5FX style part (much more expensive) and hit resolution under 300ps; a nice option for a piece of test equipment where one-up price is of little consequence compared to the engineering time but harder to swallow for production. If you want slower channels, you can even add prescaling to slow down the amount of fast-clocked logic. The possibilities are endless. Your needs are limited.Article: 134670
On Aug 25, 4:41=A0pm, Marlboro <cco...@netscape.net> wrote: > On Aug 25, 3:35=A0pm, Marlboro <cco...@netscape.net> wrote: > > > > > On Aug 25, 1:17=A0pm, wallge <wal...@gmail.com> wrote: > > > > On Aug 25, 1:48=A0pm, Gabor <ga...@alacron.com> wrote: > > > > > On Aug 25, 12:08 pm, wallge <wal...@gmail.com> wrote: > > > > > > I am working on a video project using an FPGA for all the signal > > > > > processing and output > > > > > video generation, as well as to control all the peripheral PHYs, = and > > > > > the image sensor chip. > > > > > Perhaps you could tell us which FPGA and which image sensor? > > > > > > Now, one thing that concerns me is that there is a digital contro= l > > > > > interface to the imager IC (to the control the read out of imager= rows/ > > > > > cols, as well as other integrated functions), yet the video outpu= t > > > > > from the imager is a single analog pin. The analog output is actu= ally > > > > > synchronized to a clock that is sent to the imager IC from the FP= GA. > > > > > Based on the timing diagram, the analog video should be sampled o= n the > > > > > falling edge of the clock that is sent to the imager IC. > > > > > > Now in between the FPGA and the imager IC, I need a fast analog > > > > > amplifier (to get the analog video in the correct voltage range t= o be > > > > > sampled - this will depend on the input voltage accepted by the c= hosen > > > > > ADC) and an ADC IC (to sample the analog video). > > > > > I think both the ADC and the imager will run on the same clock (a= gain, > > > > > generated by the FPGA from external Osc.). My concern is with > > > > > synchronizing the FPGA, the ADC, and the imager, so that the anal= og > > > > > pixel values are sampled at the right time on the ADC (since they= are > > > > > sync'ed to the clock), and registered in at the right time by the= FPGA > > > > > (in the eye of the sampled data). > > > > > I am worried that the PCB may introduce delays that will force me= to > > > > > have to manually tune (possibly several) clock phase shift(s) sen= t to > > > > > the imager, the ADC, and the clock used in the FPGA to register i= n the > > > > > sampled data. =A0Each block will run at the same clock speed, but= may > > > > > need different phase offsets in order to account for delays induc= ed by > > > > > the PCB interconnect or delays through various ICs (phase delay > > > > > through gain ckt, phase delay through sampler, etc). > > > > > At 15 MHz, the PCB effects on phase should be almost negligible. = =A0I > > > > would recommend separate outputs from the FPGA for each clock > > > > load, however, as this would allow you to tune the relative phase. > > > > > All clock loads inside the FPGA can be adjusted fairly easily if > > > > you have a typical modern FPGA with clock phase / DLL / PLL > > > > components. > > > > > > Does anyone have any thoughts on this? Perhaps there is a ref. de= sign > > > > > or white paper that you might know of that discusses how to handl= e > > > > > capturing this kind of analog video output using an FPGA? > > > > > Your best bet for a reference design will be the image sensor > > > > manufacturer. > > > > > > Further assumptions/details: (comments appreciated) > > > > > video clock: <=3D15MHz (based on frame rate required) > > > > > ADC sample rate: >=3D 15MSPS? > > > > > ADC sampler bits: 14 (set by system requirements, or should there= be > > > > > more than this, due to sampler noise or other PCB induced noise?) > > > > > More bits in the ADC cannot help you with noise. =A0Work at separat= ing > > > > noisy circuits as much as possible from the analog section, includi= ng > > > > the output signals from the ADC. =A0Even if you have everything on = one > > > > circuit board, design as if the image sensor and related analog > > > > electronics were on a separate board, with breaks in the power > > > > and ground planes. =A0Place the ADC at the plane split. > > > > > > Analog Gain IC stop/pass band: (pass band should be uniformly fla= t and > > > > > extend from DC to well above 15MHz, so as not to attenuate any an= alog > > > > > pixel values?) > > > > > The output of an imager has frequency components significantly high= er > > > > than the pixel rate. =A0Remember that you would like to have a fair= ly > > > > flat > > > > voltage from the sensor during the sampling phase. =A0Also remember= that > > > > you can have full amplitude swing from one pixel to the next assumi= ng > > > > you have sharp focus. =A0Trimming down the bandwidth too much will > > > > blur the image horizontally. =A0The noise-reduction vs bandwidth > > > > trade-off is not simple at 14 bits. =A0You may want to look for an = ADC > > > > that doesn't require an additional external gain stage especially i= f > > > > you really need the 14-bit linearity. > > > > > Regards, > > > > Gabor > > > > Gabor, > > > > thanks for the response. > > > I can't say which image sensor due to NDA, but > > > I can say that there is no ref. design sensor. > > > I am looking at using cyclone III for main FPGA.- Hide quoted text - > > > > - Show quoted text - > > > Why you need to worry about timing since image sensor output is an > > "analog" signal ?- Hide quoted text - > > > - Show quoted text - > > If I was you I would like to have something to control the phaseshift > for the clocks going ADC =A0and the sensor I can use a PLL to send several different clocks of the same frequency, but with different phases out to the various peripherals on the PCB. I was just hoping I would not have to manually tune these phase shifts so that the data was sampled (in the case of the ADC) or registered (in the case of the FPGA receiving the sampled data) in the middle of the "eye" of the data. Also I am not sure how to tune the phase shifts correctly, since my imager does not have the capability (as far as I know) to generate a reference or "ground truth" pattern that I could use to tune the phase shifts until the sampled data looked good (matched the known ground truth value). Does anyone have thoughts about how to tune the clock phases, so that the data is being sampled in the middle of the "eye" where the pixel value is stable? I mean this both in terms of (1) clocking the ADC with correct phase shift so that it samples the analog video during the time interval when the pixel value is stable, and (2) registering in the output of the ADC to the FPGA in the middle of the "eye" of sampled data. I suppose 15MHz is pretty slow, so maybe as long as I get the phase in the right ballpark (say within 90 to 120 degrees), everything will be sampled/registered correctly....? Maybe I just have to experiment with various clock phase shifts until I get decent looking video through my pixel pipeline...?Article: 134671
Gabor wrote: > > Do you really need 500 MHz, or are just assuming that because you > want 2ns resolution? For example using DDR outputregisters and a > 250 MHz clock you can also get 2nS resolution and perhaps save > some money over the Virtex 5 class of part you need at 500 MHz. OK, but it gets more complicated, as the input signals are not correlated in time to anything. (They are from analog comparators looking at nuclear signals, so they are TRULY random.) But, if the input logic can tell which clock edge they immediately followed, then that could set which edge they will come out on. The deal is we need to delay the randomly-arriving signal with the best resolution and minimum jitter. One obvious way is to just use an insane clock frequency. At 500 MHz, the jitter never exceeds 2 ns. I'm not exactly clear on how you sort out these arrival edges. I guess you use two flip-flops at the input, one clocking on each edge. Setting of either one starts the counter, but it can remember which FF set first, and use that to select which output FF gets set first. I'll have to study the IOBs to see how you do this. (I'll also have to study the HDL constructs to code for this.) It seems XC4VLX devices can clock at 500 MHz, and the smaller ones are ~$200 each. And, they are BGAs, which I only know about from reading the trade mags. We don't have the gear here to work with them. If we can clock the Virtex 4 at 500 MHz, then the bosses will want 1 ns resolution! Thanks for your comments! JonArticle: 134672
John_H wrote: > You can feed a 500 MHz clock to a Spartan3 style device, use a divide- > by-2 in the DCM, and clock the output I/O blocks with the 250MHz clock > in DDR mode. You just need to handle the logic to deal with odd/even > starts and stops. > We don't need to distribute a 500 MHz clock, 250 or even 125 with LVDS would be fine. > I don't think you'll have power problems running only 32 channels of > 13-bit counters but a power analysis will give you an idea of the > actual need (XPOWER tool?). > Spartan 3, huh? I'm just a little more comfortable with that, as I just did a migration to Spartan IIE (always on the trailing edge!) I can even get those in TQFP's, which I can mount and rework myself. I'm avoiding BGAs. I will have to look into the implications of using Spartan 3E on this. If the counters are running at 250 MHz, then the granularity of timing timing settings is 4 ns, which may well be tolerable. If they need finer resolution, then there are ways to fudge that with the DDR. So, you think a 13-bit counter feeding a 13-bit identity comparator will work at 250 MHz? (I've never pushed the speeds on these FPGAs at all, all of by previous projects were very relaxed by comparison, like 40 MHz.) > The counters are simple. The DDR is straightforward. The boundary > conditions are limited. > > If you want better than 2ns resolution, you can use the SERDES > channels on a Virtex-5FX style part (much more expensive) and hit > resolution under 300ps; a nice option for a piece of test equipment > where one-up price is of little consequence compared to the > engineering time but harder to swallow for production. > Yeah, I really don't think we can handle $2000 IC's. This isn't a real production project, we might build 5 of them at a time, but we are still cost-sensitive. Thanks, JonArticle: 134673
bzigon wrote:
> The vhdl that I posted is for the RAM itself. I have it wrapped in an
> entity. I just didnt post the entity definition.
Consider just pasting the process into your
design if there is only one ram.
> I instance the ram entity in my design. Let's assume I want to write
> the byte value 7 into location 8. How do I do that?
Some process must drive addr, en, we and di
for read and write cycles.
If you already know the values you want,
use a constant array (rom) instead of a ram.
> Similarly, how do I read the contents of ram location 22? I suspect
> these require state machines.
or a counter and some booleans.
Register all the signals driving the block ram.
Use a registered strobe to drive en.
> I also have setup and
> hold times that I assume must be met. How do I perform these reads and
> writes so that the setup and hold times are met?
If your design makes static timing,
the block ram will read or write in one cycle.
Block rams must be clocked.
No clock, no data.
Related example:
http://mysite.verizon.net/miketreseler/stack.vhd
-- Mike Treseler
Article: 134674On Aug 22, 12:58=A0pm, ajwitz <horow...@ibiquity.com> wrote: > Just wondering if anyone out there has had experience with or comments > on either Dini or ProDesign ChipIt Virtex 5 evaluation boards... > > Any feedback is appreciated... > > Adam I would repsond, but I am biased. From rgaddi@technologyhighland.com Mon Aug 25 16:54:44 2008 Path: flpi142.ffdc.sbc.com!flpi088.ffdc.sbc.com!prodigy.com!flpi089.ffdc.sbc.com!prodigy.net!newshub.sdsu.edu!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.lmi.net!news.lmi.net.POSTED!not-for-mail NNTP-Posting-Date: Mon, 25 Aug 2008 18:54:41 -0500 Date: Mon, 25 Aug 2008 16:54:44 -0700 From: Rob Gaddi <rgaddi@technologyhighland.com> Newsgroups: comp.arch.fpga Subject: Re: need fast FPGA suggestions Message-Id: <20080825165444.1da08acf.rgaddi@technologyhighland.com> References: <48B30324.2000603@wustl.edu> <e9399c93-012c-4e7c-8783-c724eba7fe99@k36g2000pri.googlegroups.com> <48B3242D.2020705@wustl.edu> Organization: Highland Technology, Inc. X-Newsreader: Sylpheed 2.5.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Lines: 22 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 66.117.134.49 X-Trace: sv3-rBld8tbsW3SMJLU2EQCSlqLHP0+QplynbibTwIuJWrFgb4it8q/P5kIEKf7tVbn3Zg385DDcDhwFUJp!RAjHIZTNQEvaEXA9DrIPsV+ryt9ZKpVlYu74yAJtEE+azZdPzSR36Kv8KTRnizpqGmTk9Hm6JJKC!zY3n4dOLFNB2sjwFt50= X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.39 Xref: prodigy.net comp.arch.fpga:147472 X-Received-Date: Mon, 25 Aug 2008 19:54:42 EDT (flpi142.ffdc.sbc.com) > > John_H wrote: > > I will have to look into the implications of using Spartan 3E on this. > If the counters are running at 250 MHz, then the granularity of timing > timing settings is 4 ns, which may well be tolerable. If they need > finer resolution, then there are ways to fudge that with the DDR. > So, you think a 13-bit counter feeding a 13-bit identity comparator will > work at 250 MHz? (I've never pushed the speeds on these FPGAs at all, > all of by previous projects were very relaxed by comparison, like 40 MHz.) > Tight, but probably doable. On a Spartan 3 (fastest speed grade) I'm doing 20 bit full adders and 16-bit magnitude compares at 128 MHz with time to spare. If you wanted to get excessive, you could run 4 phases of a 250 MHz clock around the chip, use them in pairs to generate 2 possible DDR outputs per channel, and diode OR them into an ECL flip-flop that you clock at 1 GHz to square the timing back up. Something of a power hog, but the Micrel 10EL31s are under $3 a pop. You could also possibly get subclock resolution by being clever with some tapped carry-chain delay lines. There's an example of this sort of thing in XAPP250. You could use something similar to note how far into your logic clock you were when the input trigger came, and then squirt the same back out after your clocked delays. -- Rob Gaddi, Highland Technology Email address is currently out of order
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