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
>Ok, again that clears much up. But programming my algorithms in VHDL >then placing them on an FGPA would result in far superior than using >the Nios II core? It is probably a 'how long is a piece of string' >type of question, but what performance penalties are there in using >the Nios II core in comparison to direct VHDL programming? If a state machine gets really complicated, it's often easier/simpler to turn it into a software problem. Usually, "complicated" means lots of states. Sometimes it can be lots of things to do each cycle. In that case, think of a wide instruction rather than a typical RISC instruction. That sort of software is often called microcode. I haven't worked with Nios. I assume it's a reasonably typical software environment. Software is often easier to change/fix/manage and it's often easier to hire software people than hardware people. (Though a web designer type software person isn't likely to be useful on this sort of software.) -- These are my opinions, not necessarily my employer's. I hate spam.Article: 124601
emrith@gmail.com wrote: > please i´m very new on this, whats the difference between Xilinx ISE > and Xilinx´s EDK, and what for is the IP ??? > ISE - tools for building fpga hardware EDK - tools for building uP software and managing IP blocks IP = intellectual property - uarts, bus controllers, etc.Article: 124602
Jon Elson wrote: > ... (I don't know why anyone would WANT to use ModelSim, it seems > insanely creaky and cumbersome, and I have to relearn the DAMN thing > every time I use it.) ... Jon, I've always rather liked modelsim (not its price!) - but I'm not defending it - I'm just curious if you know of any better solutions for simulation. -JeffArticle: 124603
Symon wrote: > I guess you have some data to back up your statement? I'm sure you wouldn't > just spout off on usenet without doing some research. ;-) Absolutely! I rolled a '1' and a '3'... they're pretty small numbers? ;) > Now, I guess that includes a lot of free seats from the web download thingy, > but the press release is talking about seats 'sold'. I would contend that > this is more than a 'drop in the ocean'. As someone elsewhere in this thread hypothesized, those numbers are questionable. But I'll retract my statement pending further evidence. Someone else also made a good point - the 'lock-in' to a vendor due to investment in development tools. However, I'd also venture to suggest that perhaps experience with a particular vendor's silicon and tools is perhaps more valuable than a few $K??? Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 124604
fpgabuilder wrote: > I personally haven't been thrilled about Altera's support. Actually, I have been pretty happy with Altera. I opened a few support cases on Altera's site and did receive satisfactory, timely answers. And to be absolutely fair, I have done the same on Xilinx's site as well! Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 124605
I prefer Active-HDL, it has all of the same features as ModelSim and a much better GUI. Plus it has better options for driving signals during a quick simulation run. Although I did find a bug in a recent past version but it has been fixed in the current version. The version of ModelSim at the time didn't have the same problem. ---Matthew Hicks > Jon Elson wrote: > >> ... (I don't know why anyone would WANT to use ModelSim, it seems >> insanely creaky and cumbersome, and I have to relearn the DAMN thing >> every time I use it.) ... >> > Jon, > I've always rather liked modelsim (not its price!) - but I'm not > defending it - I'm just curious if you know of any better solutions > for > simulation. > -JeffArticle: 124606
On Sep 27, 5:55 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote: > I prefer Active-HDL, it has all of the same features as ModelSim and a much > better GUI. Plus it has better options for driving signals during a quick > simulation run. Although I did find a bug in a recent past version but it > has been fixed in the current version. The version of ModelSim at the time > didn't have the same problem. While we are off topic, I find all the GUI based simulators unbearable slow to use. Icarus Verilog is free, works the same on Mac OSX, Linux, and Windows, and integrates perfectly into a Makefile driven work flow. I can't believe the original posters childish rant could span such a long thread! It must be a slow week. In my experience both A and X are fine companies though neither is perfect. TommyArticle: 124607
On 27 Sep., 21:20, Andy <jonesa...@comcast.net> wrote: > On Sep 27, 12:45 am, Thomas Stanka <usenet...@stanka-web.de> wrote: > > > > > Hi, > > > I have a behavior in Synplify Pro for Actel Fpgas I would call a bug > > (seen in each old version I could find up to the newest 9.0) > > > If having a register file which is accessed only in words with fixed > > width and an asynchronous reset, synplify detects a ram structure in > > the compile step. If the ram isn't used later (due to constrained ram- > > style register, or due to resource usage), synplify uses FF without an > > asynchronous reset for the register bank and a hell of logic to force > > the circuit to behave like it uses asynchnous reset. I have a simple > > example(6x8 bit), were synplicity uses twice the register normaly > > necessary. This behavior is only seen when using a technology which > > provides ram at all. So I like to know if there is a reason to > > consider this a problem of the tech library? Is there anybody out > > seeing the same behavior in other technologies than Actel (APA, AX)? > > > regards Thomas > > Can you post some code? It is difficult to understand what you want, > let alone the problem with what you are getting, without seeing some > example code. Also, does your target even support async reset on RAMs? Just to clearify: I have a code which Synplify detects as Ram in compile step. If Synplify didn't use a RAM later to implement this structure but a set of pure registers (either due to resource usage, time contraints or because I use the pragma" syn_ramstyle register" in VHDL-code. A example code in VHDL TYPE array_type is ARRAY (1 to 6) of std_ulogic_vector(7 downto 0); signal my_array : array_type; ... process (clk, rst) if rst='0' then my_array <= (others => (others =>'0')); elsif rising_edge(clk) thenArticle: 124608
Hi,
On 27 Sep., 21:20, Andy <jonesa...@comcast.net> wrote:
> Can you post some code? It is difficult to understand what you want,
> let alone the problem with what you are getting, without seeing some
> example code. Also, does your target even support async reset on RAMs?
Just to clearify:
I have a code which Synplify detects as Ram in compile step.
If Synplify didn't use a RAM later to implement this structure but a
set of pure registers (either due to resource usage, time contraints
or because I use the pragma" syn_ramstyle register" in VHDL-code) I
get some functional correct result but the solution uses way too much
registers.
Below is a sample code in VHDL which will result to ram infering in
the first place(not checked for correctness of syntax)
The example below should fit in 3 bit counter and 6x8 FF with asynch
reset. I got a result which uses nearly twice the number of FF
(without asynch. reset) in order to provide the same functionality
with a slightly more complex code, but no need to have that much
register doubling for load balance or anything like that. A lot of
registers are used in order to manage the "asynch reset" in a synchron
way.
TYPE array_type is ARRAY (1 to 6) of std_ulogic_vector(7 downto 0);
signal my_array : array_type;
attribute syn_ramstyle of my_array is register;
...
process (clk, rst)
variable cnt: integer range 0 to 7;
if rst='0' then
my_array <= (others => (others =>'0'));
cnt :=0;
elsif rising_edge(clk) then
if load = '1' then
my_array(cnt) <= an_input;
end if;
.....
Article: 124609> TYPE array_type is ARRAY (1 to 6) of std_ulogic_vector(7 downto 0); > signal my_array : array_type; > attribute syn_ramstyle of my_array is register; > ... > process (clk, rst) > variable cnt: integer range 0 to 7; > if rst='0' then > my_array <= (others => (others =>'0')); D'oh. No SRAM can be reset in one cycle. TommyArticle: 124610
On 27 Sep, 20:17, emr...@gmail.com wrote: > please i=B4m very new on this, whats the difference between Xilinx ISE > and Xilinx=B4s EDK, and what for is the IP ??? You can also read my blog: http://www.fpgafromscratch.com SvenArticle: 124611
On 28 sep, 03:03, svenand <sven...@comhem.se> wrote: > On 27 Sep, 20:17, emr...@gmail.com wrote: > > > please i=B4m very new on this, whats the difference between Xilinx ISE > > and Xilinx=B4s EDK, and what for is the IP ??? > > You can also read my blog:http://www.fpgafromscratch.com > > Sven thank you so much!Article: 124612
On 27 sep, 19:39, Gabor <ga...@alacron.com> wrote: > On Sep 27, 12:46 pm, Pablo <pbantu...@gmail.com> wrote: > > > Hi, I need some help in this design: > > > I use a design in which I have detected some skew problems. I have > > seen the archive.ucf (with the constraints), so "slew" and "drive" > > properties are used in some pins. I suppose that these properties are > > used for delays, but I don't know for what. > > > Can anyone explain me the meaning of these properties? > > > Best Regards > > For LVCMOS and LVTTL outputs, there are selectable drive strengths > ans slew rates (Xilinx parts). SLEW=SLOW or SLEW=FAST select the > two possible output slew rates. Unconstrained LVTTL and LVCMOS > outputs default to SLEW=SLOW to reduce ground bounce and noise. > > DRIVE=n, where n is the strength in milliamperes, defines the > drive strength. For most outputs the default frive is 12 mA. > Available strengths depend on the I/O standard used. > > In the electrical specifications for your part, there are tables > of timing adders for the various output standards, drive strengths > and slew rates. It is possible to address skew issues between > source-synchronous pins by assigning differing SLEW or DRIVE > properties, but it's probably a Band-Aid approach to fixing > a problem. Usually, at least in the recent parts containing > DCM's, it's better to handle timing shifts with clock phase > shifting, or in the newest parts using variable delay elements > in the IOB's. > > Regards, > Gabor Thanks so much.Article: 124613
On 2007-09-03, austin <austin@xilinx.com> wrote: > "3. Restrictions. To protect the Intellectual Property contained in the > Software, you may not decompile, translate, reverse-engineer, > disassemble, or otherwise reduce the Software, data files generated by > the Software, and/or programmable hardware devices, transmit the Just a quick follow up to this posting, I didn't want to say anything more until I knew more about. I have finally been able to confirm with Xilinx that "data files generated by the Software" is not intended to include XDL files. Austin: Thanks for helping me get in touch with the right people. /AndreasArticle: 124614
Tommy Thorn <tommy.thorn@gmail.com> writes: > On Sep 27, 5:55 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote: >> I prefer Active-HDL, it has all of the same features as ModelSim and a much >> better GUI. Plus it has better options for driving signals during a quick >> simulation run. Although I did find a bug in a recent past version but it >> has been fixed in the current version. The version of ModelSim at the time >> didn't have the same problem. > > While we are off topic, I find all the GUI based simulators unbearable > slow to use. Icarus Verilog is free, works the same on Mac OSX, Linux, > and Windows, and integrates perfectly into a Makefile driven work > flow. Modelsim is hardly tied to a GUI - I use a makefile driven flow (Modelsim even has a command for making a makefile!), and often use the simulator in "text-mode" as well. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 124615
On Sep 27, 1:51 pm, Gabor <ga...@alacron.com> wrote:
> On Sep 26, 1:22 pm, Wei Wang <camww...@gmail.com> wrote:
>
>
>
>
>
> > On Sep 26, 3:14 pm, Wei Wang <camww...@gmail.com> wrote:
>
> > > On Sep 26, 1:37 pm, Gabor <ga...@alacron.com> wrote:
>
> > > > On Sep 25, 6:48 pm, Wei Wang <camww...@gmail.com> wrote:
>
> > > > > On Sep 25, 9:31 pm, Gabor <ga...@alacron.com> wrote:
>
> > > > > > On Sep 25, 2:12 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > > > > > On Sep 25, 8:51 am, Wei Wang <camww...@gmail.com> wrote:
>
> > > > > > > > All I can find is a one-page specification of "Kingston
> > > > > > > > KVR100X64C2/128", but I do not know about the input and output
> > > > > > > > interface of this SDRAM, e.g., what are the input and output signals,
> > > > > > > > and how the input and output signals are wired into each Synchronous
> > > > > > > > DRAM (Infineon HYB39S128800CT-8) module. Many thanks, -Wei
>
> > > > > > > Hi,
> > > > > > > Go to Infineon or Micron, or Samsung to search for similar SDRAM
> > > > > > > chips.
>
> > > > > > > Kingston is not a chip manufacture, but a DIMM manufacture.
>
> > > > > > > All SDRAM chips are almost same with Micron having the tighest
> > > > > > > requirements.
>
> > > > > > > You may print Micron 128800CT-8 SDRAM to see if there is a document
> > > > > > > over there. Maybe they are all out of date.
>
> > > > > > > Weng
>
> > > > > > A good source for DIMM data is JEDEC. On their website, jedec.org,
> > > > > > you
> > > > > > can find standard connections for all standard DIMM types. If you
> > > > > > know
> > > > > > the type of chip and number of chips on your module you can generally
> > > > > > narrow down the choices to one JEDEC standard.
>
> > > > > > Their website is a little hard to navigate, but the search feature
> > > > > > generally gets you to the information you need, and all of the
> > > > > > standards
> > > > > > include reference schematics so you can see the chip connections.
>
> > > > > > HTH,
> > > > > > Gabor- Hide quoted text -
>
> > > > > > - Show quoted text -
>
> > > > > Thanks Tianxiang and Gabor for your inputs, but I was a little
> > > > > confused with the description in Kingston KVR100X64C2/128 "The
> > > > > components on this module
> > > > > include sixteen 8M x 8-bit (2M x 8-bit x 4 Bank / PC100 components)
> > > > > SDRAM in TSOP packages", but when I look at Infineon HYB39S128800CT-8,
> > > > > the chip has four banks inside,
> > > > > each bank is 8 bits wide with 4M address, so each chip is 4Mx8bitx4,
> > > > > which is 16MB. As the Kingston is 128 MB big and it has 8 Infineon
> > > > > chips fitted, so I don't see why the KVR specification says the module
> > > > > contains sixteeen 8Mx8-bit SDRAM. Should it be 8 16Mx8-bit SDRAM, then
> > > > > I could not find this in JEDEC standard while I could find the JEDEC
> > > > > standard for sixteen 8Mx8bit? Could somebody give me some hints on
> > > > > this, thanks!!!
>
> > > > The data sheet also notes:
>
> > > > "Note: The module defined in this data sheet is one of several
> > > > configurations available under this part number. While all
> > > > configurations are compatible, the DRAM combination and/or the
> > > > module height may vary from what is described here."
>
> > > > I'm not sure what they consider "compatible" in the case of modules
> > > > with different memory organizations under the same part number,
> > > > but I also noticed that they offer "Free Technical Support".
>
> > > > Perhaps someone at Kingston can address the issue?
>
> > > > Regards,
> > > > Gabor- Hide quoted text -
>
> > > > - Show quoted text -
>
> > > Many thanks again for your input, I've called Kingston US support line
> > > yesterday, but I was told that they could not provide anything in more
> > > detail beyond the one-page specification found on their website. I've
> > > however managed to find something very similar, such as the Samsung
> > > KMM366S1723T datasheet which provides a better view of chip
> > > organization.- Hide quoted text -
>
> > > - Show quoted text -
>
> > The signals are pretty similar in either Samsung or Kingston, but I'm
> > not entirely sure with the chip select signals. Just wondering whether
> > the select signals should be the same for sdrams with same number of
> > chips.
>
> The chip select should be the same for the same total number of
> data bits, i.e. # of chips times # bits per chip. If there is
> only enough for one bank (or DIMM "side" as it is sometimes called)
> only the first chip select is used. When the total number of data
> pins is twice the DIMM data width ("two-sided" DIMM) both chip
> selects are used.- Hide quoted text -
>
> - Show quoted text -
Thanks for mentioning "bank". I found Figure 4.5.4-J in JEDEC DIMM
standards (X64 SDRAM DIMM, 1 Bank with X8 SDRAM)
Article: 124616Hi I am evaluating the possibility to use 2 resitor video output from FPGA similar to: http://www.excamera.com/articles/15/ntsc.html to generate color NTSC output, so far my results show less quality then the test picture in the link above I use 300/600 ohm with Xilinx Spartan3A starterkit I am not yet sure if the difference in visible output is from the different receiver USB video grabber vs TV receiver, but the video as grabbed with cheap 25EUR grabber is very noisy, almost like the 80MHz would be pass the input filtering so that the 16 shaders are almost not recognizeable, also there is too much noisy flickering at the top the screen. I will be testing with real TV set later, so I can compare better. so just asking if anyone has any compare results or suggestions for ultra low cost and simple direct video output with FPGA, there is one design with 9 resistors and 2 bipolar transistors, or then R-2R type networking, both are too complex, if a PWM based solution could work with some little neat tricks AnttiArticle: 124617
On Sep 28, 10:34 am, Antti <Antti.Luk...@googlemail.com> wrote: > Hi > > I am evaluating the possibility to use 2 resitor video output from > FPGA similar to: > > http://www.excamera.com/articles/15/ntsc.html > > to generate color NTSC output, so far my results show less quality > then the test picture in the link above > I use 300/600 ohm with Xilinx Spartan3A starterkit > > I am not yet sure if the difference in visible output is from the > different receiver USB video grabber vs TV receiver, but the video as > grabbed with cheap 25EUR grabber is very noisy, almost like the 80MHz > would be pass the input filtering so that the 16 shaders are almost > not recognizeable, also there is too much noisy flickering at the top > the screen. I will be testing with real TV set later, so I can compare > better. > > so just asking if anyone has any compare results or suggestions for > ultra low cost and simple direct video output with FPGA, there is one > design with 9 resistors and 2 bipolar transistors, or then R-2R type > networking, both are too complex, if a PWM based solution could work > with some little neat tricks > > Antti A television will have a low-pass filter on the video and may look better. If you didn't add at least a capacitor (1 pole LPF) after your PWM, the digital grabber will no doubt show the effects of sampling the 80 MHz PWM signal. Noise at the top of the screen may indicate some problem with sync levels. My guess is that a proper LPF might fix this, too. Good luck, GaborArticle: 124618
On 28 Sep., 17:39, Gabor <ga...@alacron.com> wrote: > On Sep 28, 10:34 am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > > > Hi > > > I am evaluating the possibility to use 2 resitor video output from > > FPGA similar to: > > >http://www.excamera.com/articles/15/ntsc.html > > > to generate color NTSC output, so far my results show less quality > > then the test picture in the link above > > I use 300/600 ohm with Xilinx Spartan3A starterkit > > > I am not yet sure if the difference in visible output is from the > > different receiver USB video grabber vs TV receiver, but the video as > > grabbed with cheap 25EUR grabber is very noisy, almost like the 80MHz > > would be pass the input filtering so that the 16 shaders are almost > > not recognizeable, also there is too much noisy flickering at the top > > the screen. I will be testing with real TV set later, so I can compare > > better. > > > so just asking if anyone has any compare results or suggestions for > > ultra low cost and simple direct video output with FPGA, there is one > > design with 9 resistors and 2 bipolar transistors, or then R-2R type > > networking, both are too complex, if a PWM based solution could work > > with some little neat tricks > > > Antti > > A television will have a low-pass filter on the video and may look > better. If you didn't add at least a capacitor (1 pole LPF) after > your PWM, the digital grabber will no doubt show the effects of > sampling the 80 MHz PWM signal. > > Noise at the top of the screen may indicate some problem with > sync levels. My guess is that a proper LPF might fix this, too. > > Good luck, > Gabor- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - ha, eh the PWM is clocked with 80MHz and for 16 grey levels the PWM frew is 5 MHz :( yes i already tried some cap for filter, it makes it a very little better only for color signal i guess at least the R-2R thing is needed I will try without by using 500MHz clocked delta sigma, that should be much better then 80mhz clocked PWM but not sure if even that is useable for color. AnttiArticle: 124619
"Antti" <Antti.Lukats@googlemail.com> wrote in message news:1190994565.617357.99810@50g2000hsm.googlegroups.com... > > ha, eh the PWM is clocked with 80MHz and for 16 grey levels the PWM > frew is 5 MHz :( > yes i already tried some cap for filter, it makes it a very little > better only > > for color signal i guess at least the R-2R thing is needed > I will try without by using 500MHz clocked delta sigma, that should be > much better then 80mhz clocked PWM but not sure if even that is > useable for color. > > Antti At better than 100:1, I'd expect the 500 MHz delta to give good results. The filtering will be less of an issue for the delta scheme. Until or unless you have the nice modulator configured, would you consider using some TV analog filter chips to clean up the video? Your low-cost end solution might not use a part like the US$0.59 MAX9512 from maxim-ic.com, but it could make the initial development a little easier. - John_HArticle: 124620
On 28 Sep., 18:56, "John_H" <newsgr...@johnhandwork.com> wrote: > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > news:1190994565.617357.99810@50g2000hsm.googlegroups.com... > > > > > ha, eh the PWM is clocked with 80MHz and for 16 grey levels the PWM > > frew is 5 MHz :( > > yes i already tried some cap for filter, it makes it a very little > > better only > > > for color signal i guess at least the R-2R thing is needed > > I will try without by using 500MHz clocked delta sigma, that should be > > much better then 80mhz clocked PWM but not sure if even that is > > useable for color. > > > Antti > > At better than 100:1, I'd expect the 500 MHz delta to give good results. > The filtering will be less of an issue for the delta scheme. > > Until or unless you have the nice modulator configured, would you consider > using some TV analog filter chips to clean up the video? Your low-cost end > solution might not use a part like the US$0.59 MAX9512 from maxim-ic.com, > but it could make the initial development a little easier. > > - John_H Hi John, wau thanks for this link - I was considering that http://www.jcwolfram.de/projekte/vhdl/fbas_enc/main.php but I think feeding the maxim thing from FPGA would give better results the 0.59 may still be in the budget, well the total self cost are below 12USD (hopefully havent got FPGA pricing yet) so it is more than just peanuts, but not so bad AnttiArticle: 124621
Jeff Cunningham wrote: > Jon Elson wrote: > >> ... (I don't know why anyone would WANT to use ModelSim, it seems >> insanely creaky and cumbersome, and I have to relearn the DAMN thing >> every time I use it.) ... > > > Jon, > I've always rather liked modelsim (not its price!) - but I'm not > defending it - I'm just curious if you know of any better solutions for > simulation. > -Jeff I have both Modelsim and Aldec's ActiveHDL. I much prefer Aldec's simulator over Modelsim. The UI is more intuitive and much easier to use, Aldec supports hooks into matlab for testbenches and simulation of edif netlists. It also has a design entry tool that is far above the text editor in Modelsim. I've also found tech support for Aldec to be much more responsive, often having a fix the next day (I've been an Aldec user now for about 10 years; early versions had a number of bugs, but they were always good at getting a patch made quickly) Tech support is especially good if you use the magic words: "runs fine in modelsim". If you haven't already, please check out the Aldec tools, and if they ask where you heard of them feel free to drop my name.Article: 124622
Andy wrote: > When you let it infer ram, are you getting LUT based rams > (combinatorial read), or block rams (registered reads)? > > LUT rams cannot be reset. I seem to recall block rams on some devices > can have a reset. But the results of that reset may be deferred by the > synchronous read circuitry (depending on whether you registered the > read address, or registered the read data in the inferring code), so > implementing that same cycle-accurate behavior may take more flops > than you thought, but since you did not post how you are reading the > RAM, I cannot tell. > > Andy > The Block RAM reset does not reset cells in the memory array, it just resets bits in the output register forcing the output to the reset value. The contents of the array are left unchanged.Article: 124623
On Sep 28, 1:00 am, Thomas Stanka <usenet...@stanka-web.de> wrote: > Hi, > > On 27 Sep., 21:20, Andy <jonesa...@comcast.net> wrote: > > > Can you post some code? It is difficult to understand what you want, > > let alone the problem with what you are getting, without seeing some > > example code. Also, does your target even support async reset on RAMs? > > Just to clearify: > I have a code which Synplify detects as Ram in compile step. > If Synplify didn't use a RAM later to implement this structure but a > set of pure registers (either due to resource usage, time contraints > or because I use the pragma" syn_ramstyle register" in VHDL-code) I > get some functional correct result but the solution uses way too much > registers. > > Below is a sample code in VHDL which will result to ram infering in > the first place(not checked for correctness of syntax) > The example below should fit in 3 bit counter and 6x8 FF with asynch > reset. I got a result which uses nearly twice the number of FF > (without asynch. reset) in order to provide the same functionality > with a slightly more complex code, but no need to have that much > register doubling for load balance or anything like that. A lot of > registers are used in order to manage the "asynch reset" in a synchron > way. > > TYPE array_type is ARRAY (1 to 6) of std_ulogic_vector(7 downto 0); > signal my_array : array_type; > attribute syn_ramstyle of my_array is register; > ... > process (clk, rst) > variable cnt: integer range 0 to 7; > if rst='0' then > my_array <= (others => (others =>'0')); > cnt :=0; > elsif rising_edge(clk) then > if load = '1' then > my_array(cnt) <= an_input; > end if; > ..... When you let it infer ram, are you getting LUT based rams (combinatorial read), or block rams (registered reads)? LUT rams cannot be reset. I seem to recall block rams on some devices can have a reset. But the results of that reset may be deferred by the synchronous read circuitry (depending on whether you registered the read address, or registered the read data in the inferring code), so implementing that same cycle-accurate behavior may take more flops than you thought, but since you did not post how you are reading the RAM, I cannot tell. AndyArticle: 124624
Antti wrote: > Hi > > I am evaluating the possibility to use 2 resitor video output from > FPGA similar to: > > http://www.excamera.com/articles/15/ntsc.html > > to generate color NTSC output, so far my results show less quality > then the test picture in the link above > I use 300/600 ohm with Xilinx Spartan3A starterkit > > I am not yet sure if the difference in visible output is from the > different receiver USB video grabber vs TV receiver, but the video as > grabbed with cheap 25EUR grabber is very noisy, almost like the 80MHz > would be pass the input filtering so that the 16 shaders are almost > not recognizeable, also there is too much noisy flickering at the top > the screen. I will be testing with real TV set later, so I can compare > better. > > so just asking if anyone has any compare results or suggestions for > ultra low cost and simple direct video output with FPGA, there is one > design with 9 resistors and 2 bipolar transistors, or then R-2R type > networking, both are too complex, if a PWM based solution could work > with some little neat tricks > > Antti > That's interesting. I think several of the Xilinx evaluation boards have VGA outputs with R-2R networks so you get a very limited set of colors. I'm not sure why you wouldn't just use a video DAC, though. Are they too expensive? They can be very small and low-resolution versions don't use too many inputs. -Kevin
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