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
fpgar@my-dejanews.com wrote: > Hi. > > I need to introduce a 40-50 ns delay in the line clock of > the fpga (the clock > will be in the 5-8MHz range). how can i do it?? > > I thought in feeding back the clock in a new pin and > delaying with a cap, > but, i suppose this delay can be do with internal logic > also. Using internal logic or routing delays will give you wide-ranging errors, perhaps 3-to-1, due to temperature effects ( 0.25% per degree C ), voltage effects ( 10 to 15% over the Vcc range ), and processing differences, (up to 50%). Here is my suggestion: The cleanest would be to take the opposite clock edge. That's something you have external control over. The alternative is an external RC. I suggest 330 Ohm in series and 150 pF to ground. That swamps out the drive impedance and the input capacitance. Peter Alfke, Xilinx ApplicationsArticle: 15201
fpgar@my-dejanews.com wrote: > Hi. > > I need to introduce a 40-50 ns delay in the line clock of > the fpga (the clock > will be in the 5-8MHz range). how can i do it?? > > I thought in feeding back the clock in a new pin and > delaying with a cap, > but, i suppose this delay can be do with internal logic > also. > Having endorsed the external low-pass RC filter as a delay element, my bad conscience causes me to post this warning: It introduces a slow-risetime clock, which can lead to double-triggering if there is ground-bounce or other noise in the system ( and where is this not!) So be very careful how you use this clock. You could also increase the hysteresis (Schmitt trigger action) on the delayed clock input, but that costs you an additional output. I much prefer the opposite-clock-edge approach. Peter Alfke, XilinxArticle: 15202
This is a multi-part message in MIME format. ------=_NextPart_000_001B_01BE6CD6.EA043CE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Peter, thank you for the message. But it is a too late for the italian people :-( Ciao Luigi ------=_NextPart_000_001B_01BE6CD6.EA043CE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 face=3DArial size=3D2>Dear Peter,<BR>thank = you for the=20 message.<BR>But it is a too late for the italian people = :-(</FONT> </DIV> <DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT><FONT = face=3DArial=20 size=3D2>Ciao</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Luigi</FONT></DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: = 5px"> <DIV> </DIV></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_001B_01BE6CD6.EA043CE0--Article: 15203
Thanks Peter The specific problem is: I need a write enable signal for a 100 ns RAM. The clock of the system is 5-8 MHz, and i need write once per cycle. If i use the opposite clock-edge i must change the RAM to 60ns access time. This memory is controlled something like that Wenable --+ +--+ ¦ ¦ ¦ +------+ +---..... -> <100n <- CLK --+ +----+ ¦ ¦ ¦ +----+ +----..... With a 8 Mhz clock i thougth generating it as Wenable = /CLOCK*Clockdelayed so i assure the minimun access time. Also I can delay the clock with external digital logic to avoid the slow rise time, but i was looking for the easy and cheapest solution. Thanks for your help drp@lettera.net -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 15204
This is what I've used * AND + OR @ XOR ~ NOT/INVERT hope this helps, Stephen Swearingen ICS Triplex Alex Rast wrote: > I am creating a low-level FPGA design using Xilinx EPIC. Great program, but > nowhere can I find any documentation on the syntax for the LUT equations. > Essentially, if you highlight a logic slice in a CLB, pick editblock, pick a > LUT (by clicking on the check box market "LUT" on the logic element), then > click attr (for attibutes), you get a dialog box with "LUT Equations". Great, > that's just what I need, but a few syntax guesses all errored out. I called > Xilinx tech support - they said they would find out (didn't know immediately > over the phone) - and I have not heard back from them since. No phone, no > voice mail, no e-mail. I also called up one of our local distribution reps - > he again said he would try to find me the right person, but when I called him > today, he hemmed and hawed, said he was having difficulty tracking down > someone who could help, said he would try looking through old manuals, faxed > me a sheet, and it did not help. So I'm still stopped. So, very simply put, > > What is the correct syntax for entering LUT equations for Virtex parts in the > dialog box for that purpose in Xilinx EPIC 1.5? > > Any help would be MUCH appreciated. > > TIA, > > Alex Rast > arast@inficom.comArticle: 15205
What I suggest is a FPGA pin drives an AC (or anything reasonably fast as long as it has a CMOS threshold) gate, which drives an RC network (say 100pF and 560 ohm) which drives another AC gate, and drives back into the FPGA. Play with the R to get the right delay (probably something smaller than 560 will be needed, but it depends on the sum of the delay through the FPGA driver, the Tpd of the gates, and the delay through the input buffer). I don't recommend using internal delays. Your mileage may vary... fpgar@my-dejanews.com wrote in message <7cbkvc$nvd$1@nnrp1.dejanews.com>... >Hi. > > I need to introduce a 40-50 ns delay in the line clock of the fpga (the clock >will be in the 5-8MHz range). how can i do it?? > > I thought in feeding back the clock in a new pin and delaying with a cap, >but, i suppose this delay can be do with internal logic also. > >Thanks. > >-----------== Posted via Deja News, The Discussion Network ==---------- >http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 15206
Can anyone suggest a good post-route power estimation method/tool for FPGA's ? (realize that this is highly dependent on frequency and probability of switching events .... Pav=CL*VDD^2*f)Article: 15207
Hi, ALTERA offers in their data book and as an application note (*.pdf) a calculation sheet for power estimation. Ciao, CS Richard Guerin <guerin2@home.com> schrieb in Nachricht 36E9C804.13E88966@home.com.../// >Can anyone suggest a good post-route power estimation method/tool for >FPGA's ? (realize that this is highly dependent on frequency and >probability of switching events .... Pav=CL*VDD^2*f)Article: 15208
In my opinion Actel FPGA's are great if only they would increase the number of clock lines (announced for the SX64) family and would make a low pin-count small package version of the SX family (e.g. SOIC). Their free development tools are easy to use and the Actmap synthesiser produces in most cases much better result than the $$ tools. As far as I know (correct me if I am wrong) there is no low cost programmer available. We are currently in the final stages of implementing a high speed EDAC controller in a SX16. Hans. In article <7c6od4$ebu$1@nnrp1.dejanews.com>, ggli@dictaphone.com says... > >I'm looking at using some Actel FPGA's . . . you know the anti-fuse variety. >It seems the ..SX16 family is quick and definitely inexpensive on a gate per >gate basis vs. other vendors. My question is, has anybody used these yet, >and what general pros and cons do you see. I'd still consider using an SRAM >based part from say Altera (FLEX10K series) if needed. Are there any >penalties (besides OTP) that this architecture has? > >Any help would be great > >gene >ggli@dictaphone.com > >-----------== Posted via Deja News, The Discussion Network ==---------- >http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 15209
In article <7c6od4$ebu$1@nnrp1.dejanews.com>, ggli@dictaphone.com wrote: > I'm looking at using some Actel FPGA's . . . you know the anti-fuse variety. > It seems the ..SX16 family is quick and definitely inexpensive on a gate per > gate basis vs. other vendors. My question is, has anybody used these yet, > and what general pros and cons do you see. I'd still consider using an SRAM > based part from say Altera (FLEX10K series) if needed. Are there any > penalties (besides OTP) that this architecture has? > > Any help would be great > > gene > ggli@dictaphone.com > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own We have just completed two Actel SX16 designs. These parts are **very** fast, although the design tools are not quite there yet. Timing driven place and route does not work yet. We had problems routing both designs to a chosen pinout. R398 just failed completely. We had to get an alpha version of R199 to get the parts to route, and even then they are on the verge of not routing. Performance, though, is excellent. One design runs at 90 MHz and the other at 83 MHz worst case. Clock pin to output is around 5 ns. I submitted the design to an Altera FAE to put into a FLEX 10KA part and the best he was able to do on the 90 MHz design was 68 MHz. Nate ---------------------------------------------------- Nate Goldshlag nateg@pobox.com Arlington, MA http://www.pobox.com/~nategArticle: 15210
In addition to the databook/app note they have a Excel spreadsheet which implements the stuff in the app note.. Matthew Carlhermann Schlehaus wrote in message <7cctda$qn5$1@news08.btx.dtag.de>... >Hi, > >ALTERA offers in their data book and as an application note (*.pdf) a >calculation sheet for power estimation. > >Ciao, CS >Richard Guerin <guerin2@home.com> schrieb in Nachricht >36E9C804.13E88966@home.com.../// >>Can anyone suggest a good post-route power estimation method/tool for >>FPGA's ? (realize that this is highly dependent on frequency and >>probability of switching events .... Pav=CL*VDD^2*f) > >Article: 15211
Could you post the seminar on the net for those of us who can't include the seminar in our schedules? Simon - http://www.tefbbs.com/spacetime/index.htmlArticle: 15212
Nate Goldshlag wrote: > In article <7c6od4$ebu$1@nnrp1.dejanews.com>, ggli@dictaphone.com wrote: > > > I'm looking at using some Actel FPGA's . . . you know the anti-fuse variety. > > It seems the ..SX16 family is quick and definitely inexpensive on a gate per > > gate basis vs. other vendors. My question is, has anybody used these yet, > > and what general pros and cons do you see. I'd still consider using an SRAM > > based part from say Altera (FLEX10K series) if needed. Are there any > > penalties (besides OTP) that this architecture has? > > > > Any help would be great > > > > gene > > ggli@dictaphone.com > > > > -----------== Posted via Deja News, The Discussion Network ==---------- > > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own > > We have just completed two Actel SX16 designs. These parts are **very** > fast, although the design tools are not quite there yet. Timing driven > place and route does not work yet. We had problems routing both designs > to a chosen pinout. R398 just failed completely. We had to get an alpha > version of R199 to get the parts to route, and even then they are on the > verge of not routing. > > Performance, though, is excellent. One design runs at 90 MHz and the > other at 83 MHz worst case. Clock pin to output is around 5 ns. > > I submitted the design to an Altera FAE to put into a FLEX 10KA part and > the best he was able to do on the 90 MHz design was 68 MHz. > > Nate hi, i would suggest "unfixing" all of the i/o pins and then trying r3-1998 again, and see how it does. also, for comparison, you might want to try p&r the design in an a1280a and an a14100a to see how the routability compares between the new device and the older families, after removing the fixed i/o properties. generally, my designs and the designs i have seen others do haven't had routing problems - except when the pins were fixed in advanced without consideration for the logic on the chip. also, in general, with a good i/o placement, a relatively high percentage of internal logic modifications had no effect on routability. rkArticle: 15213
At my company, Actel anti-fused products are the preferred programmable device, especially for the saftey-critical flight control applications that we design (many of these designs simply can't tolerate the latency associated with device configuration nor can they tolerate the small probability of an anomalous event during during configuration ... such as in the rare event of an in-flight system reset). In terms of performance and reliability (across Military temp ranges), we've had pretty good experience with Actel (plastic) devices ...( albiet I haven't worked with the SX16 family yet). With their fine-grained anti-fused based architecture, Actel devices (in my opinion) represent some of the most ASIC-like FPGA's available today (hope I don't piss off any QuickLogic people). As far as tools go.... Actel is offering a free development suite (for a limited time) that includes, VeriBest, Synplify-Lite, and Designer-Lite R3-1998 (See: http://www.acteldesktop.com/). These tools are pretty decent ....definitely get the job done for most applications (though you'll have to pry my Model Tech & Exemplar dongles from my dead hand) One nice feature, that the Actel devices offer, is the action probe capability (See: http://www.actel.com/html/_____silicon_explorer.html). The ability to monitor internal signals (real time) during system debug has proven invaluable and has saved numerous hours of debug time. Hope that helps ....Good luck in your new design :-) ggli@dictaphone.com wrote: > > I'm looking at using some Actel FPGA's . . . you know the anti-fuse variety. > It seems the ..SX16 family is quick and definitely inexpensive on a gate per > gate basis vs. other vendors. My question is, has anybody used these yet, > and what general pros and cons do you see. I'd still consider using an SRAM > based part from say Altera (FLEX10K series) if needed. Are there any > penalties (besides OTP) that this architecture has? > > Any help would be great > > gene > ggli@dictaphone.com > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 15214
Hi, We have a product that has been using an XC4013EPQ240C. I built a new board and populated it with an XCS30PQ240C, with NO changes to the bit stream at all...and...it just worked. I did two cuts on the PCB to isolate pins 58 and 62. That's it! Big cost savings ;-) Austin Franklin austin@darkroom.comArticle: 15215
Hi, I simulate a design by Vsystem4.4j, the result is correct with no SDF. But when I apply SDF file to my design, each Components has a ERROR, vsim -sdftyp d:\time_sim.sdf, then I select design Unit in Menu. ... #ERROR: d:\time_sim.sdf(97):The design does not have an instance named'/c55'. ... But I can find all the Components in both time_sim.sdf and time_sim.vhd. I use Foundation Express v1.5. can anyone help me? TomArticle: 15216
Hi all, I just ended my studies to become an electronic engineer and I'd like to start a few projects. This is intended for learning purposes. I heard that FPGA can be managed with a PC and a few hunred dollars, is it true? What can I do using FPGA at the moment? Damiano Rullo Trezzano S/N Milan, Italy http://members.it.tripod.de/Damianoux/index.html mailto: dmn@cheerful.com mailto: damiano@mclink.itArticle: 15217
VAX wrote: > Hi, > > I simulate a design by Vsystem4.4j, the result is correct with no SDF. > But when I apply SDF file to my design, each Components has a ERROR, > > vsim -sdftyp d:\time_sim.sdf, then I select design Unit in Menu. > ... > > #ERROR: d:\time_sim.sdf(97):The design does not have an instance named'/c55'. > > ... > > But I can find all the Components in both time_sim.sdf and time_sim.vhd. > I use Foundation Express v1.5. > > can anyone help me? > > Tom I did it like that : vsim testop -sdfmax I1=/home/../time_sim.sdf (time_sim.sdf applied to the module I1 of the top level testop, I1 is the vhdl file produced by Foundation, other modules are stimuli). Good luck. Michel Le Mer Gerpi sa (Xilinx Xpert) 3, rue du Bosphore Alma city 35000 Rennes France (02 99 51 17 18) http://www.xilinx.com/company/consultants/partdatabase/europedatabase/gerpi.htmArticle: 15218
Does anyone have a suggestion on how to make a clock multiplier according to specs below: Fin: 10 Hz - 2000 Hz Fout: Fin*100 I would like to use a FPGA but other ideas are also appreciated. SvenArticle: 15219
Xilinx FPGA development boards by Associated Professional Systems Inc. (APS) are now available direct in Europe from EuroEDA Limited. Full details from http://www.euro-eda.com or email info@euro-eda.com.Article: 15220
we are experiencing a problem with xilinx XC4010E FPGAs. So far the problem manifests itself as a stuck pin (Pin 126 of PQ208 package) to VCC. Two XC4010E fpgas with different date codes (FPGA #1 = PQ208CKM9809 A105288A 4I, FPGA #2 = PQ208CKJ9701 A105288A 4I) are programmed with the same image file. FPGA #2 works properly but FPGA #1 with 9809 Date code has the stuck pin problem. In the current design, Pin 126 is used as an external RAM data pin which constantly being used. Per our xilinx rep, FPGA #2 has a smaller die than #1. Presently, we are not sure whether if it is a timing problem with we are having with the latest die. Since the fpga design was farmed out to an outside firm and they are currently unavailable to aid us, we can't take a look at the timing simulation to see whether we are border line or not, or, bring out test pins to monitor the logics that affect pin 126. Has anyone out there experienced or heard of similar problems? If yes, how did you overcome it? And if no, can you offer any advise? Thanks, gilles -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 15221
wgilles@my-dejanews.com writes: > Per our xilinx rep, FPGA #2 has a smaller die than #1. Presently, we are not > sure whether if it is a timing problem with we are having with the latest > die. Since the fpga design was farmed out to an outside firm and they are > currently unavailable to aid us, we can't take a look at the timing > simulation to see whether we are border line or not, or, bring out test pins > to monitor the logics that affect pin 126. If it's purely a timing problem, then variations in chip temperature and power supply voltage should demonstrate the problem on FPGA#2 as well and make it go away on FPGA#1. Get out that cold spray and the hair dryer. If it is indeed a timing problem, I'd suggest taking the designer to task over it. Achim Gratz. --+<[ It's the small pleasures that make life so miserable. ]>+-- WWW: http://www.inf.tu-dresden.de/~ag7/{english/} E-Mail: gratz@ite.inf.tu-dresden.de Phone: +49 351 463 - 8325Article: 15222
This is a multi-part message in MIME format. --------------05DA82C062B78C1D8A05BFA3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A couple of comments: 1. If you have only seen the 'stuck at' problem on one FPGA then you should consider that it might be a bad chip rather than there being a systematic problem with all shrunk FPGA's. Maybe that pin got zapped by static or the bond wire fell off or there is a bad solder joint on the board or ...... 2. Second most likely problem is a timing problem in the design. Heating it up or cooling it down *may* cause the other FPGA to have problems if the design is poor. But it is not guaranteed to: heating up or cooling down should make all timing paths delays scale by the same amount (e.g. 10% faster) with a shrink some paths might get 10% faster and others 20% faster. Tom. wgilles@my-dejanews.com wrote: > we are experiencing a problem with xilinx XC4010E FPGAs. So far the problem > manifests itself as a stuck pin (Pin 126 of PQ208 package) to VCC. Two > XC4010E fpgas with different date codes (FPGA #1 = PQ208CKM9809 A105288A 4I, > FPGA #2 = PQ208CKJ9701 A105288A 4I) are programmed with the same image file. > FPGA #2 works properly but FPGA #1 with 9809 Date code has the stuck pin > problem. In the current design, Pin 126 is used as an external RAM data pin > which constantly being used. > > Per our xilinx rep, FPGA #2 has a smaller die than #1. Presently, we are not > sure whether if it is a timing problem with we are having with the latest > die. Since the fpga design was farmed out to an outside firm and they are > currently unavailable to aid us, we can't take a look at the timing > simulation to see whether we are border line or not, or, bring out test pins > to monitor the logics that affect pin 126. > > Has anyone out there experienced or heard of similar problems? If yes, how did > you overcome it? And if no, can you offer any advise? > > Thanks, > > gilles > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------05DA82C062B78C1D8A05BFA3 Content-Type: text/x-vcard; charset=us-ascii; name="tom.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tom Kean Content-Disposition: attachment; filename="tom.vcf" begin:vcard n:Kean;Tom tel;fax:UK +44 131 556 9247 tel;work:UK +44 131 556 9242 x-mozilla-html:TRUE org:Algotronix Ltd. adr:;;P.O. Box 23116;Edinburgh;;EH8 8YB;Scotland version:2.1 email;internet:tom@algotronix.com title:Director note:Web Site: www.algotronix.com x-mozilla-cpt:;4768 fn:Tom Kean end:vcard --------------05DA82C062B78C1D8A05BFA3--Article: 15223
Hi, I'm designing a small RISC on a Flex10k20 and have run into a problem implementing my register file. The register file I want is 16 regs deep, each with width 16 bits. I need five data out (read) ports (two to the alu, three so I can do branch condition detection and program counter loads on a branch), and one data in (write) port. I tried to implement this as 16 registers with the output ports as five huge 16:1 16 bit muxes. On compilation and fitting, I found that this was must too large for the Flex10k20. My question ... is there a more efficient way to implement this kind of functionality? Thanks for your advice, NebuArticle: 15224
Hello In the example below I have used only 'if' and 'case' statements to write/read the RAM memory. I would like to know if it is possible to use 'for' statements in this synthesizable code. For example, when FLAG_POWERUP = '0' I want to find out if DATA_IN is located in the memory. Is it possible to sweep the memory using a 'for' loop? Thanks Eduardo. P.S. This code is working without any problem in an XC4010XL (XS40 - XESS board). library IEEE; use IEEE.std_logic_1164.all; use IEEE.std_logic_unsigned.all; entity RDWR_RAM256x8 is port ( -- CLK_IN : in std_logic; -- Global clock RESET_NEG_IN : in std_logic; -- Global reset (P0, parallel port) DATA_IN : in std_logic_vector(3 downto 0); -- parallel port (P5..P2) DATA_OUT : out std_logic_vector(6 downto 0) -- 7-seg display ); end RDWR_RAM256x8; architecture RDWR_RAM256x8_BEH of RDWR_RAM256x8 is component RAM256x8 port ( a : in std_logic_vector(7 downto 0); -- RAM address (WE = 1, write; CE=1, read) d : in std_logic_vector(7 downto 0); -- Data input (WE = 1, C = 1) we : in std_logic; -- '1' == write to the memory c : in std_logic; -- Clock ce : in std_logic; -- '1' == read memory q : out std_logic_vector(7 downto 0) -- Data output (CE = 1, C = 1) ); end component; component HEX2LED port ( CLK_IN : in std_logic; DATA_IN : in std_logic_vector (7 downto 0); DATA_OUT : out std_logic_vector (6 downto 0) ); end component; component OSC4 port ( F8M : out std_logic; F15 : out std_logic ); end component; component BUFG port ( I : in std_logic; O : out std_logic ); end component; -- declarations for RAM256x8 signal ADDR_RAM256x8 : std_logic_vector(7 downto 0); signal DATAIN_RAM256x8 : std_logic_vector(7 downto 0); signal WR_RAM256x8 : std_logic; signal CLK_RAM256x8 : std_logic; signal CE_RAM256x8 : std_logic; signal DATAOUT_RAM256x8 : std_logic_vector(7 downto 0); -- declarations for HEX2LED signal CLK_HEX2LED : std_logic; signal DATAIN_HEX2LED : std_logic_vector(7 downto 0); signal DATAOUT_HEX2LED : std_logic_vector(6 downto 0); -- declarations for OSC4 signal CLK8M, CLK15Hz : std_logic; -- declarations for BUFG signal OSCOUT, CLK_IN : std_logic; signal FLAG_POWERUP, NOT_FOUND : std_logic; signal OLD_DATA : std_logic_vector(3 downto 0); type STATES_TYP is (SX_C, S1_C, S2_C, S3_C, S4_C, S5_C, S6_C, S7_C); signal NEXT_STATE : STATES_TYP; begin -- -- instantiate the components -- RAM256x8_1 : RAM256x8 port map ( a => ADDR_RAM256x8, d => DATAIN_RAM256x8, we => WR_RAM256x8, c => CLK_RAM256x8, ce => CE_RAM256x8, q => DATAOUT_RAM256x8 ); HEX2LED_1 : HEX2LED port map ( CLK_IN => CLK_HEX2LED, DATA_IN => DATAIN_HEX2LED, DATA_OUT => DATAOUT_HEX2LED ); OSCILLATOR: OSC4 port map ( F8M => CLK8M, F15 => CLK15Hz ); CLOCKBUF:BUFG port map ( I => OSCOUT, O => CLK_IN ); OSCOUT <= CLK15Hz; CLK_RAM256x8 <= CLK_IN; CLK_HEX2LED <= CLK_IN; DATAIN_HEX2LED <= "11111111" when NOT_FOUND = '1' else DATAOUT_RAM256x8; DATA_OUT <= DATAOUT_HEX2LED; RDWR_RAM256x8_PRO: process (CLK_IN, RESET_NEG_IN ) begin if RESET_NEG_IN = '0' then NOT_FOUND <= '1'; ADDR_RAM256x8 <= (others => '0'); DATAIN_RAM256x8 <= (others => '0'); WR_RAM256x8 <= '1'; -- Write memory on power up CE_RAM256x8 <= '0'; -- Don't read memory FLAG_POWERUP <= '1'; elsif CLK_IN'event and CLK_IN = '1' then ----------------------------------------------------------------------------- -- Initialize on Powerup ----------------------------------------------------------------------------- if FLAG_POWERUP = '1' then if WR_RAM256x8 = '0' then -- -- Fill SRAM with RAMPS -- if ADDR_RAM256x8 = 255 then -- last address == 255 DATAIN_RAM256x8 <= ADDR_RAM256x8(7 downto 1) & "0"; NEXT_STATE <= S1_C; FLAG_POWERUP <= '0'; else -- fill memories DATAIN_RAM256x8 <= ADDR_RAM256x8(7 downto 1) & "0"; FLAG_POWERUP <= '1'; -- keep filling RAM; end if; WR_RAM256x8 <= '1'; -- Next clock, write else DATAIN_RAM256x8 <= (others => '0'); FLAG_POWERUP <= '1'; -- keep filling RAM; ADDR_RAM256x8 <= ADDR_RAM256x8 + 1; WR_RAM256x8 <= '0'; -- Next clock, don't write end if; else FLAG_POWERUP <= '0'; CE_RAM256x8 <= '1'; WR_RAM256x8 <= '0'; -- Next clock, don't write case NEXT_STATE is -- SX_C is used for simulation purposes only. No hardware is generated to represent -- this initialization state. It is used to detect resetting problems. when SX_C => NEXT_STATE <= SX_C; when S1_C => NOT_FOUND <= '1'; OLD_DATA <= DATA_IN; ADDR_RAM256x8 <= (others => '0'); NEXT_STATE <= S2_C; when S2_C => if ADDR_RAM256x8 = 255 then NOT_FOUND <= '1'; NEXT_STATE <= S3_C; else if DATAOUT_RAM256x8 = ("0000" & OLD_DATA) then NOT_FOUND <= '0'; NEXT_STATE <= S3_C; else NOT_FOUND <= '1'; ADDR_RAM256x8 <= ADDR_RAM256x8 + 1; NEXT_STATE <= S2_C; end if; end if; when S3_C => if DATA_IN = OLD_DATA then NEXT_STATE <= S3_C; else NEXT_STATE <= S1_C; end if; when others => NEXT_STATE <= S4_C; end case; end if; end if; end process RDWR_RAM256x8_PRO; end RDWR_RAM256x8_BEH;
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