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
I've been trying to code a simple VGA controller to run on my Altera DE1 board. You can see my code here: http://pastebin.com/GMfxs6Xz Note that my board has a DAC which converts the 4-bit digital signal for each of the RGB colors to the analog signal required by VGA. The timings are as found here for example: http://tinyvga.com/vga-timing/640x480@60Hz When I run this code the monitor leaves the "No Signal Found" indication but it stays black no matter which color I choose. I know that the board works because the VGA output works fine with the demonstration provided by Altera. Any help greatly appreciated.Article: 148151
On Jun 23, 7:54=A0am, Gladys <yuhu...@gmail.com> wrote: > I found that Xilinx provide an IP core called RAM-based Shift > Register, the maximum depth is 1088, however, my image could have a > high resolution of 3664 x 2748, which means I need a depth of 2748, is > there any other methode to implement this? Thank you There's a white paper from Xilinx titled "Implementing and Testing Efficient Video Line Stores". It explains how to use Block RAMs as a huge shift register of an arbitrary length. I've used the provided examples with success in the past. You can find it here: http://www.xilinx.com/products/boards/s3estarter/reference_designs.htm Regards, SergioArticle: 148152
On Fri, 18 Jun 2010 10:27:03 -0700, Rob Gaddi wrote: >I'm no luck figuring out how to implement the timing constraints for >something that, to my mind, ought to be pretty simple. [source-synchronous timing, as pointed out by Gabor] >I've gone through the Constraints Guide. I've gone through UG612. I've >gone through Austin's 5 part series over on the Xilinx forums. And I'm >still lost. Anyone have any revelations for me? This is kinda easy to do with Altera Timequest. There are some distinctly non-trivial wrinkles with Timequest but, whenever Ie tried it, I got really good results without needing any manual-instantiation or set-dont-touch crud. I'm slightly surprised that it's so hard to get X to do it. But then it's always been a source of amazement to me that the documentation on UCF constraints language was so hard to get at. Timequest documentation is only a little better, but tends to rely on the idea that people already know the Synopsys constraints language and can extrapolate from that. UCF is like nothing else, so nothing else helps. <sigh of exasperation> -- Jonathan BromleyArticle: 148153
On Jun 23, 12:55=A0pm, Giorgos Tzampanakis <g...@hw.ac.uk> wrote: > I've been trying to code a simple VGA controller to run on my > Altera DE1 board. You can see my code here: > > http://pastebin.com/GMfxs6Xz > > Note that my board has a DAC which converts the 4-bit digital > signal for each of the RGB colors to the analog signal required > by VGA. The timings are as found here for example: > > http://tinyvga.com/vga-timing/640x480@60Hz > > When I run this code the monitor leaves the "No Signal Found" > indication but it stays black no matter which color I choose. > > I know that the board works because the VGA output works fine > with the demonstration provided by Altera. > > Any help greatly appreciated. Have you simulated this? Just looking quickly I don't see how vga_hs works. It looks like maybe your sync pulses are only one clock long. That won't drive any monitor I know of. -- GaborArticle: 148154
Sergio <checo22@gmail.com> wrote: >On Jun 23, 7:54=A0am, Gladys <yuhu...@gmail.com> wrote: >> I found that Xilinx provide an IP core called RAM-based Shift >> Register, the maximum depth is 1088, however, my image could have a >> high resolution of 3664 x 2748, which means I need a depth of 2748, is >> there any other methode to implement this? Thank you > >There's a white paper from Xilinx titled "Implementing and Testing >Efficient Video Line Stores". It explains how to use Block RAMs as a >huge shift register of an arbitrary length. I've used the provided >examples with success in the past. You can find it here: >http://www.xilinx.com/products/boards/s3estarter/reference_designs.htm Such designs are actually circular buffers. Not very difficult to create by yourself. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 148155
On Jun 22, 12:14=A0pm, Rich Webb <bbew...@mapson.nozirev.ten> wrote: > On Tue, 22 Jun 2010 11:17:31 -0700 (PDT), martin_05 > > <martin...@rocketmail.com> wrote: > >> >you can create a group within "google groups" and moderate it. It is > >> >"sponsored" by google-ads, which is nice. No banners, no popups, and > >> >usually the ads are relevant to the content of the page being > >> >currently viewed. > > >> So because of the spam-floods from googlegroups that render much of > >> Usenet a less than happy experience for many users, one should move to > >> googlegroups and put eyeballs on their sponsored advertisements? How > >> nice of them to provide such a service... > > >No, I am talking about creating a set of forums on a privately owned > >server that has nothing whatsoever to do with any of the FPGA > >companies. > > Roger that. Replying to the suggestion to move to GoogleGroups. > > >It's a shame to see CAF and other valuable usenet lists get clobbered > >with viagra and other crap. =A0My intent would be to create a nice clean > >and professional environment that would be just as useful, if not more > >due to newer technologies, than the usenet lists but devoid of trash. > > Take a look athttp://www.embeddedrelated.com/index.php, which gateways > comp.arch.embedded to and from a web forum, for some ideas. There is > minimal spam so I'd guess that their moderators or their upstream feed > does do some housekeeping. The advantage is that it still has Usenet > visibility, both ways. > > -- > Rich Webb =A0 =A0 Norfolk, VA Yet another way Google can make money from spam. "We are not evil" - yeah, right.Article: 148156
On Jun 22, 7:35=A0am, "rduar002" <rduar002@n_o_s_p_a_m.fiu.edu> wrote: > Hi, > I successfully ported Petalinux on the XUPV5-LX110T FPGA board using 8 KB > of Data/Instruction Cache. My SDRAM is 256 MB (MT4HTF3264HY-667F1). Howev= er > when I create a file (vi myFile) at the /var/tmp location, myFile cannot = be > bigger than 25 MB otherwise Petalinux will complain that my system is out > of memory and it will log me off. Does anyone knows how to solve this > issue. Any help will be greatly appreciated it. > > Petalinux version: 0.40-rc3 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com What does the command 'cat /proc/meminfo' tell you? How about 'df' ??Article: 148157
Gabor <gabor@alacron.com> wrote in news:cc66c286-0547-416a-
9edf-3c43de9b7807@f8g2000vbl.googlegroups.com:
> Have you simulated this? Just looking quickly I don't see
how
> vga_hs works. It looks like maybe your sync pulses are only
> one clock long. That won't drive any monitor I know of.
I run it on the board and look at the signals using SignalTap
or an external logic analyzer. It doesn't simulate correctly on
the simulator, but the signals are as expected on the logic
analyzer.
The pulses are not one clock long, notice:
case (next_state)
`vertical_sync: begin
vga_vs <= 1'b0;
if (line_count ==
`max_vertical_sync_count && pulse_count ==
`max_pulse_count)
next_state <= `vertical_front_porch;
end
etc...
So the low value on the sync pin will stay until the machine
moves on to the next state. Why did you think that the pulse
only stays for one clock cycle?
Article: 148158>I've been trying to code a simple VGA controller to run on my >Altera DE1 board. You can see my code here: > >http://pastebin.com/GMfxs6Xz > >Note that my board has a DAC which converts the 4-bit digital >signal for each of the RGB colors to the analog signal required >by VGA. The timings are as found here for example: > >http://tinyvga.com/vga-timing/640x480@60Hz > >When I run this code the monitor leaves the "No Signal Found" >indication but it stays black no matter which color I choose. > >I know that the board works because the VGA output works fine >with the demonstration provided by Altera. > >Any help greatly appreciated. > I simulated your code @ 25 Mhz after striping out the divider on clock_50 and it shows: 4 us Horizontal pulse every 33.5 us 67.1 us Vertical pulse every 17.6 ms Your running it at 15 hz John --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148159
Hi Group, Could you guys please recommend me a non volatile fpga (which can hold its bit stream in, an on-chip flash). I might need to put a soft core cpu in the fpga as well. so a medium size device like Spartan-3AN-700 will be fine for me. I am looking for any device which is smaller in size than Spartan-3AN-700 which is 23mmX23mm. Xilinx Spartan 3AN devices have no variety available in terms of same packages but with different CLB sizes. Regards, AsimArticle: 148160
On Jun 24, 1:43=A0am, asimlink <asiml...@gmail.com> wrote: > Hi Group, > > Could you guys please recommend me a non volatile fpga (which can hold > its bit stream in, an on-chip flash). > I might need to put a soft core cpu in the fpga as well. so a medium > size device like Spartan-3AN-700 will be fine for me. I am looking for > any device which is smaller in size than Spartan-3AN-700 which is > 23mmX23mm. Xilinx Spartan 3AN devices have no variety available in > terms of same packages but with different CLB sizes. > > Regards, > > Asim You should check out the Lattice XP2 series. They also offer a 32-bit CPU development platform (Mico-32) and their chip offerings are broader for non-volatile devices. If you're tied to Xilinx, then 3AN is your only choice.Article: 148161
On Jun 23, 7:01=A0pm, Giorgos Tzampanakis <g...@hw.ac.uk> wrote: > Gabor <ga...@alacron.com> wrote in news:cc66c286-0547-416a- > 9edf-3c43de9b7...@f8g2000vbl.googlegroups.com: > > > > > Have you simulated this? =A0Just looking quickly I don't see > how > > vga_hs works. =A0It looks like maybe your sync pulses are only > > one clock long. =A0That won't drive any monitor I know of. > > I run it on the board and look at the signals using SignalTap > or an external logic analyzer. It doesn't simulate correctly on > the simulator, but the signals are as expected on the logic > analyzer. > > The pulses are not one clock long, notice: > > case (next_state) > =A0 =A0 =A0 `vertical_sync: begin > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vga_vs <=3D 1'b0; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (line_count =3D=3D = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 `max_vertical_sync_count = && pulse_count =3D=3D =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 `max_puls= e_count) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0next_state <=3D `verti= cal_front_porch; > =A0 =A0 =A0 end > > etc... > > So the low value on the sync pin will stay until the machine > moves on to the next state. Why did you think that the pulse > only stays for one clock cycle? As I said I only looked at it quickly and saw lines 74 and 75 setting the sync pulses high (outside the state machine case statement), which is something I usually do to create pulses. Looking back at the code I see that the value is assigned throughout the state. If your monitor doesn't lock, you should make sure that the sync signals are actually reaching the sync pins of the monitor. Also check if the working version of the VGA code gives the same active level for the sync pulses. Most monitors use the sync active level as a code to suggest a resolution standard. This comes from the original VESA definitions for PC video. Getting it wrong doesn't usually prevent the monitor from syncing, but your monitor may be more finicky. Regards, GaborArticle: 148162
"jt_eaton" <z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote in news:0smdnezRz6VsJr_RnZ2dnUVZ_vednZ2d@giganews.com: > I simulated your code @ 25 Mhz after striping out the > divider on clock_50 and > it shows: > > 4 us Horizontal pulse every 33.5 us > 67.1 us Vertical pulse every 17.6 ms > > > Your running it at 15 hz > These times look about correct based on http://tinyvga.com/vga- timing/640x480@60Hz . Am I missing something? The page says these are the 60 Hz timings.Article: 148163
Gabor <gabor@alacron.com> wrote in news:2b315a7b-decf-407a-a018-97425e869103@c10g2000yqi.googlegro ups.com: > If your monitor doesn't lock, you should make sure that the > sync signals > are actually reaching the sync pins of the monitor. Also > check if the working version of the VGA code gives the same > active level for the sync pulses. Most monitors use the > sync active level as a code to suggest a resolution > standard. This comes from the original VESA definitions for > PC video. Getting it wrong doesn't usually prevent the > monitor from syncing, but your monitor may be more finicky. > I will check those suggestions, but I have no control over the level, I can only set it to 0 or 1 within the fpga, so it's unlikely that there is some problem there, given that the demo program runs fine.Article: 148164
Giorgos Tzampanakis <gt67@hw.ac.uk> wrote in news:Xns9DA0B66A6D054fdnbgui7uhu5h8hrnuio@188.40.43.230: > I've been trying to code a simple VGA controller to run on > my Altera DE1 board. You can see my code here: > > http://pastebin.com/GMfxs6Xz > > Note that my board has a DAC which converts the 4-bit > digital signal for each of the RGB colors to the analog > signal required by VGA. The timings are as found here for > example: > > http://tinyvga.com/vga-timing/640x480@60Hz > > When I run this code the monitor leaves the "No Signal > Found" indication but it stays black no matter which color I > choose. > > I know that the board works because the VGA output works > fine with the demonstration provided by Altera. > > Any help greatly appreciated. Fixed. The problem was that I was only driving the horizontal sync pulses while the pixel rgb values were driven.Article: 148165
On Jun 24, 11:17=A0am, Giorgos Tzampanakis <g...@hw.ac.uk> wrote: > Gabor <ga...@alacron.com> wrote innews:2b315a7b-decf-407a-a018-97425e8691= 03@c10g2000yqi.googlegro > ups.com: > > > If your monitor doesn't lock, you should make sure that the > > sync signals > > are actually reaching the sync pins of the monitor. =A0Also > > check if the working version of the VGA code gives the same > > active level for the sync pulses. =A0Most monitors use the > > sync active level as a code to suggest a resolution > > standard. =A0This comes from the original VESA definitions for > > PC video. =A0Getting it wrong doesn't usually prevent the > > monitor from syncing, but your monitor may be more finicky. > > I will check those suggestions, but I have no control over the > level, I can only set it to 0 or 1 within the fpga, so it's > unlikely that there is some problem there, given that the demo > program runs fine. What I meant by "levels" was active high vs active low, not the actual voltage which should be TTL. Anyway glad to see you've got it fixed. regards, GaborArticle: 148166
>"jt_eaton" <z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote >in news:0smdnezRz6VsJr_RnZ2dnUVZ_vednZ2d@giganews.com: > >> I simulated your code @ 25 Mhz after striping out the >> divider on clock_50 and >> it shows: >> >> 4 us Horizontal pulse every 33.5 us >> 67.1 us Vertical pulse every 17.6 ms >> >> >> Your running it at 15 hz >> > >These times look about correct based on http://tinyvga.com/vga- >timing/640x480@60Hz . > >Am I missing something? The page says these are the 60 Hz >timings. > My Bad. I grabbed the wrong number when I divided. John --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148167
On Jun 24, 5:43=A0pm, asimlink <asiml...@gmail.com> wrote: > Hi Group, > > Could you guys please recommend me a non volatile fpga (which can hold > its bit stream in, an on-chip flash). > I might need to put a soft core cpu in the fpga as well. so a medium > size device like Spartan-3AN-700 will be fine for me. I am looking for > any device which is smaller in size than Spartan-3AN-700 which is > 23mmX23mm. Xilinx Spartan 3AN devices have no variety available in > terms of same packages but with different CLB sizes. The usual suspects would be Lattice, Actel, SiliconBlue and if you don't need it today ;) then even Menta who have a MRAM based FPGA coming... http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=3D225600023 If you can shrink the fpga by avoiding the soft-cpu, then Cypress and Actel have Arm+Logic solutions -jgArticle: 148168
We have a Spartan6/45 that's talking to 16 separate SPI A/D converters. The data we get back is different, but the clock and chip select timings are the same. To get the timing right, avoiding routing delays, we need our outgoing stuff to be reclocked by i/o cell flipflops. So what happens is that we have one state machine running all 16 SPI interfaces. We tell the software that we want the adc chip select flops in i/o cells. The compiler decides that all are seeing the same input signal, so reduces them to one flipflop. Then it concludes that that flipflop can't be in an i/o block, and builds it that way. The resulting routing delays are deadly. We couldn't find a way to force these 16 flops into IOBs. Really. The fix is to fool the compiler into thinking the flipflop states are not the same. Turns out the the synchronous clear inputs to the flops are unused in our design. My suggestion was to ground an input pin, run that into the serial input of a 16-bit shift register, and route the sr taps to the clears of the 16 output flops. The compiler can't know that these levels are in fact always low, so has to gen 16 different flops. *Then* it allows the flops to be forced into IOBs. Rob has a better idea, just make a 16-bit SR that generates a thermometer code on powerup, namely walk a 1 into it, and have the sr output bits un-clear the i/o flops sequentially. The compiler isn't smart enough catch onto that, and we don't need to ground a pin. It works. Isn't that all perfectly stupid? The Altera folks are coming to make their pitch tomorrow. This story may amuse them. JohnArticle: 148169
On 25/06/2010 3:09 PM, John Larkin wrote: > Rob has a better idea, just make a 16-bit SR that generates a > thermometer code on powerup, namely walk a 1 into it, and have the sr > output bits un-clear the i/o flops sequentially. The compiler isn't > smart enough catch onto that, and we don't need to ground a pin. The compiler isn't smart enough in its current version. You may be laying a trap for the future if you use a technique that relies on the compiler not performing an analysis that it could perform in principle, but just doesn't at the moment. I suppose it doesn't matter if you sure that neither this circuit, nor any variant of it, will ever be processed by a newer version of the compiler. Sylvia.Article: 148170
In comp.arch.fpga Sylvia Else <sylvia@not.here.invalid> wrote: > On 25/06/2010 3:09 PM, John Larkin wrote: >> Rob has a better idea, just make a 16-bit SR that generates a >> thermometer code on powerup, namely walk a 1 into it, and have the sr >> output bits un-clear the i/o flops sequentially. The compiler isn't >> smart enough catch onto that, and we don't need to ground a pin. > The compiler isn't smart enough in its current version. You may be > laying a trap for the future if you use a technique that relies on the > compiler not performing an analysis that it could perform in principle, > but just doesn't at the moment. That could only happen if the compiler figured out that you weren't looking at the output for the first 16 cycles. You can know that, but normally the compiler can't assume that. That is, with the assumption that the SR initializes to zero and clocks a 1 in. -- glenArticle: 148171
In comp.arch.fpga John Larkin <jjlarkin@highnotlandthistechnologypart.com> wrote: > We have a Spartan6/45 that's talking to 16 separate SPI A/D > converters. The data we get back is different, but the clock and chip > select timings are the same. To get the timing right, avoiding routing > delays, we need our outgoing stuff to be reclocked by i/o cell > flipflops. > So what happens is that we have one state machine running all 16 SPI > interfaces. We tell the software that we want the adc chip select > flops in i/o cells. The compiler decides that all are seeing the same > input signal, so reduces them to one flipflop. Then it concludes that > that flipflop can't be in an i/o block, and builds it that way. The > resulting routing delays are deadly. > We couldn't find a way to force these 16 flops into IOBs. Really. > The fix is to fool the compiler into thinking the flipflop states are > not the same. Turns out the the synchronous clear inputs to the flops > are unused in our design. My suggestion was to ground an input pin, > run that into the serial input of a 16-bit shift register, and route > the sr taps to the clears of the 16 output flops. The compiler can't > know that these levels are in fact always low, so has to gen 16 > different flops. *Then* it allows the flops to be forced into IOBs. > Rob has a better idea, just make a 16-bit SR that generates a > thermometer code on powerup, namely walk a 1 into it, and have the sr > output bits un-clear the i/o flops sequentially. The compiler isn't > smart enough catch onto that, and we don't need to ground a pin. > It works. > Isn't that all perfectly stupid? Did you try to attach a (* KEEP = "TRUE" *) attribute to the registers in question? I had a similar problem with registers meant to get places in an IOB absorbed by the feeding BRAM -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 148172
On Jun 25, 1:09=A0am, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > > We couldn't find a way to force these 16 flops into IOBs. Really. In Synplify, this common type of situation is easily handled with the "syn_preserve" directive which is different than Synplify's "keep" used for wires in my Verilog code. It's good to get intimate with your compiler's list of attributes and directives. While it's often "pushing the rope" to get the results you expect, it's good to become more expert at pushing. - John_HArticle: 148173
I would be amazed if you cant get XST to keep all 16 flipflops. I know you can do it in Synplify. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148174
Am 25.06.2010 12:31, schrieb John_H: > On Jun 25, 1:09 am, John Larkin > <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> >> We couldn't find a way to force these 16 flops into IOBs. Really. > > In Synplify, this common type of situation is easily handled with the > "syn_preserve" directive which is different than Synplify's "keep" > used for wires in my Verilog code. Hmm, but is there a portable way to do these things? Something like C's "volatile"? Philipp
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