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
sunny wrote: > > altera's byteblaster did include the 74hc244. the byteblastermv consists of an 74ls244. the schematic should be ok and it should work fine with the ls part. I assume that your cable is more than 20cm in length. shorten the cable and it will work fine. NO, the byteblasterMV has a 74HC244. 74LS244 won't work at lower than 5V. The MV schematic has no VCC-GND bypass cap, even tho the real dongle has. Make sure you add one.Article: 41376
vlad@comsys.ntu-kpi.kiev.ua wrote: > Hi All , > Where can I find information about numerical characteristic of failure > rate of Xilinx Chips(Spartan2, Virtex series)? This information is > needed for calculation reliability index of entire device. I'd be interested in hearing any stories of end-user problems with devices containing Xilinx CPLDs or FPGAs. I am about at the Beta-test stage with several products that attach to a PC's parallel port, and use some XC9572 CPLDs and some XCS10 and XCS30 Spartan 5V parts. One customer in particular has blitzed quite a few of these chips, and I'm trying to identify the cause long distance. I seem to see symptoms of blown I/O pins, and he seems to indicate that it works until he unplugs something, so ESD is almost certain. So, I'm wondering if anyone has some experience with the ESD sensitivity of these chips compared to other 74HC type logic, for instance. There are some substantial reasons why I don't want to put ESD suppression devices on all signal lines on every board. JonArticle: 41377
Mik e Payne wrote: > Falk, > > I've got the Keil monitor programmed into the interal flash of the > AT89S8252. I can use the dScope program to read/write to the SRAM. I > can write to some locations so I've put a small looping program that > continuously writes 0x00 to location 0x00ff. I run this program and > then us a Tek 2246 100Mhz scope to examine the signals. > > The write to SRAM will fail if 6 or more of the low address/data lines > have to transition from a '1'(for the low address) to a '0' (for the > data to write). Oh, man! This very clearly looks like a ground bounce type of problem. Your comments on the board construction in another response makes me wonder how much decoupling capacitance is available to the CPLD. I use a minimum of 4 .1 uF chip caps for an XC9572 CPLD, I would think the CoolRunner would need more. I place these as close to the pairs of power and ground pins as I can, then couple the ground pins together with .1" thick traces if possible. I haven't had any problems with the chips glitching with this arrangement, but I did make a good effort to make the power, and especially ground pin connections short and wide. As for the micro and ram chips, whatever decoupling and ground bus connections you made are entirely your own hand work. > Signals going into the CPLD look good. Signals comming out of the > CPLD have noise, I see spikes and ringing on those signals. This seems to be a pretty good indication that a signal which is used to clock a latch or FF is acting as if edges are ocurring when they shouldn't. You might look at some data sheets to check the logic thresholds - does the CoolRunner have a logic threshold selection for the input pin? (Some Xilinx chips allow you to select this, but I think it is global to the whole chip.) JonArticle: 41378
Handel C and SystemC are targetted at different device. Handel C is for FPGA and can give computing engineering guys faster processor, and integrate with their CPU... SystemC is intended for ASIC...if I am not wrong...none of the computing people would make an ASIC only to make his signal processing faster. If you are designing a chip, HandelC is the wrong choice. Email: qijun@okigrp.com.sg "Jeanan Del" <go_stock_boy@yahoo.com> wrote in message news:5e59ca1f.0203261002.5fb42c34@posting.google.com... > When is Celoxica going to kill of this useless proprietary Handel-C > language in favor of moving to the industry standard SystemC ?? I've > done a couple of experiments with DK1 3.0 and the language is painful > to use, doesn't leverage C++ and once I do soemthing in Handel-C, I > can't use with any other design or verification tools, like I can with > SystemC. There's a germ of value in Celoxica stuff but not while it > is encumbered by a dead-end proprietary language. > > When are these guys going to get real ??Article: 41379
Both specifications are correct. I believe you are mis-interpreting the Philips spec . Let me try and clarify. On 25 Mar 2002 21:27:10 -0800, jaime.aranguren@ieee.org (Jaime Andres Aranguren Cardona) wrote: >Hi, > >On Xilinx' App Note XAP333 is an design of a I2C Master/Slave >peripheral for a uProcessor, which I've used as basis for designing a >slave device. They say on pag 12 that everything (the state machine >and associated counters and shift registers are clocked on the falling >edge of SCL, 'cause on heavy loaded systems the rise time of the SCL >line may be very slow and that is dangerous on a clock a signal, >'cause it can generate noise on it. So stuff changes after the falling SCL edge. If the new data settles fast enough ( in less than 1/2 the cycle time, assuming the clock is symetric 50/50) then the data is stable prior to the next rising edge, and will remain stable at least until the next SCL falling edge. Since nothing is done on the rising edge, there is no setup requirement to it. (But the Philips spec does state a requirement) >However, on Philips I2C bus Specification v2.1 Jan-2000, pag 8 they >say the data on the SDA line must be stable during the HIGH period of >the clock. Read this again. It says "stable while high" which is not a conflict with the Xilinx info. The data could also be stable prior to going high, i.e. went stable while low, remained stable during low to high SCL transition, remained high till after next SCL high to low transition. The full text of the relevant section in the Philips spec is: 6.1 Data validity The data on the SDA line must be stable during the HIGH period of the clock. The HIGH or LOW state of the data line can only change when the clock signal on the SCL line is LOW (see Fig.4). which means that it changes after a SCL high to low transition. On the next page, fig 4 shows data valid prior to a rising SCL transition, stable during SCL high, and changing after a high to low SCL transition. >What would to recommend for an I2C slave on a Xilinx XC4010XL and/or a >XCS05XL? >Sampling on the falling edge (like Xilinx AppNote does) or sampling on >he rising edge (as Philips specification suggests)? As you can see above, Philips does not mandate sampling on the rising edge. If you look at the timing tables on page 32, and the timing diagram Fig 31, you will see that because data must be high before the SCL low to high transition, you could use either edge. Since the falling edge is the cleaner edge, you should use it. In case you are wondering, Philips (the company) does not pay me royalties on this part of their product line. >Thanks a lot. Sure. Philip Freidin Philip Freidin FliptronicsArticle: 41380
Kevin, For 5V PCI, just leave the I/Os in the default state. The 3.3V PCI clamping diodes default to off, so the standard LVCMOS/LVTTL I/O setting is what you need. If you want to verify the setting, you can check though the assignment organizer or the compiler settings menu to see that 3.3V PCI is not selected. If you need 5V clamping diodes, you need to implement them externally. -Pete- Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in message news:a7p9n7$rij$1@newsreader.mailgate.org... > I am wondering how I can activate 5V PCI I/O pads in Altera > FLEX10KE/ACEX1K. ...snip... > Thanks, > > Kevin Brace (In general, don't respond to me directly, and respond > within the newsgroup.)Article: 41381
I am using a 5 meter long cable from the computer to the Byteblaster perhaps this is the cause of my problem. I thought that 5 meters was the longest recommendend cable length and since the table I work on is about 5 meters away from my computer this is what I used. I tried running a thick wire from the chassis of the computer to the circuit power supply but to no avail. To bad I was really hoping that I could have the programmer next to my work table. Anyone know of a way to resolve this other than using a shorter cable? I also checked that the chip I used was a 74HC244 which it should be according to the schematic in the ByteblasterMV manual. Anyway thanks for all the help you have given me. ArbitraryArticle: 41382
You need to shift zeros (or some other initialization) into the SRL16 in order
to get it into a known state. It takes 16 clocks to do that, of course if you
don't use the last taps then you can shift less. A second SRL16 can be used in
the initialization logic to aid in generating that 16 clock long clear pulse.
Kevin Neilson wrote:
> I'm glad this point has been brought up because I wanted to make an
> averaging filter using SRLs but I'm worried about what will happen if the
> Xilinx gets reset. The accumulator will reset to zero, but the values in
> the SRL delay line won't. That means that after a reset, the output of the
> averaging filter will be offset by the sum of all the values in the SRL
> delay lines. How should I clear out all the data after a reset?
> -Kevin
>
> "Ken Chapman" <chapman@xilinx.com> wrote in message
> news:3CA0B2AB.78F52ED6@xilinx.com...
> > Dear Ray,
> >
> > I agree that a really safe design should also consider upsets. My tech
> Xclusive on
> > the subject of resets in designs is very much about safe design
> techniques. The
> > whole concept of a one-hot state machine is an issue if you need to trap
> the cases
> > of 'n-hot' and 'cold states'. In these cases I would favour an encoded
> state machine
> > (not that many people carry out full illegal state analysis on those
> either).
> >
> > In my design for a UART state machine described in part 2 of my TechX, I
> > deliberately design the state machine to go 'cold' at the end of
> processing a
> > character. The next start bit on the serial line is then used to inject
> the next
> > 'hot' state. In this way, any induced error can be made to be short lived.
> >
> > The efficiency offered by the SRL16E could also be exploited to provide
> redundancy.
> > 3 state machines working in parallel with a majority voting system for
> each output
> > control bit (a LUT3) would be nice. In this way, we do not have to
> tolerate the
> > error condition at all.
> >
> > Seems like we have got away from LFSR counters a bit, but a good thread
> anyway.
> >
> > Regards,
> >
> > Ken
> >
> >
> >
> > Ray Andraka wrote:
> >
> > > I agree, the SRL16 is a wonder drug. I don't however like to use it as
> a closed
> > > loop state machine as described by Ken because such a design will not
> self
> > > recover in the event of an upset. The SRL16 only gets initialized on
> > > configuration, so if for some reason you get an upset (and in the .15
> micron it
> > > does sometimes happen), your state machine carries that upset state bit
> until
> > > the device is reconfigured. In my book, that is poor design practice.
> As soon
> > > as you add the logic to detect the illegal states, the size gets
> considerably
> > > larger (it may be more advantageous to use TMR here).
> >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 41383Better is subjective. For some applications, the skew on the clock is not an issue, so there is no need to route the clock through a global buffer. For other applications, if there is a very high fanout on the low-speed clock, skew may become an issue if the low speed clock is used as an enable. General rules are for general cases; for each design, one has to weigh the trade-offs (sometimes this takes 0 ps, sometimes hours or ....) Jason Ray Andraka wrote: > A better way to handle those slow clocks is to bring them in on regular I/O > through a register clocked by your local master clock (typically many times > faster than the slow clock), then detect the edges of the slow clock > synchronously to create clock enables for the data 'clocked' by the slow clock. > > Niv wrote: > > > I have a design with more than 4 clocks, the Virtex max., (but some are very > > slow, < 1MHz). > > > > LeoSpec insists on putting BUFG's on all the clocks, which causes Xilinx PAR > > to throw a wobbler. > > > > The design now has a 40MHz master clk into a CLKDLL, which produces 2 > > internal clocks with BUFG's, which is wanted, and 4 other clocks, only 2 of > > which need BUFG's. The other 2 clocks are low freq. and low fanout. > > > > The old design worked fine with 6 external clks; LeoSpec just sorted it out > > somehow; But now with 5 external clks, the master one to a DLL, it all goes > > to pot! > > > > Anyone got any bright ideas please? > > > > i.e. How do I force some of my clocks NOT to use BUFG's & IBUFG's, just use > > IBUF's instead? > > > > TIA, Niv. > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759Article: 41384
Jeanan Del wrote: > When is Celoxica going to kill of this useless proprietary Handel-C > language in favor of moving to the industry standard SystemC ?? I've > done a couple of experiments with DK1 3.0 and the language is painful > to use, doesn't leverage C++ and once I do soemthing in Handel-C, I > can't use with any other design or verification tools, like I can with > SystemC. There's a germ of value in Celoxica stuff but not while it > is encumbered by a dead-end proprietary language. Should Celoxica try to make the language into a standard (like Verilog went from proprietary to IEEE STD)? Is there a SystemC synthesis tool that gives as good of results? Or is it whole idea hopeless? I'm in the process of evaluating these sorts of tools, and would like to hear as many opinions as I can, especially if you have used the tools you are talking about for something real. -- Phil HaysArticle: 41385
Cypress makes several chips that will output a 200 MHz clock using a PLL based on a clock at any standard low speed. You can use a 10 MHz crystal and generate several clocks of different frequencies using a CY22393, for example. The frequency can be programmed in the one time EPROM and can be changed (in volatile memory) after power up via a two wire serial interface (I2C). I am using two of these on my board to generate several different clocks from one crystal. "Sławomir Balon" wrote: > > Hi! > I'm looking for fast clock source (200MHz) for epm7032b, it will produce > four phase shifted by 90 degree 50MHz clocks. What oscilator should i use? > Crystal oscilators offer ends at 120MHz, i didn't ever use any plls at that > high freq's. I'm open for any ideas... > BTW how they make lets say: 1GSPS in oscilloscopes (i know that on > repetitions but how they get those phase shifts for ADCs? - ECL??) > > thanx > Slawek -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 41386
The speed of the clock rising edge vs the falling edge is a red herring. The problem with the slow edge is not that noise will cause double clocking if you use the rising edge, but that noise will cause double clocking PERIOD! Even if you use the falling edge to clock the register, any noise during the slow rising edge will still cause a falling clock edge and double clock your data. The only advantage of using the falling edge to clock your data has to do with noise generation. The logic that changes states on either edge will generate some noise. If that is on a slow edge, it will be more likely to double clock. But if you have other things going on in your CPLD or FPGA, then you will be making noise at all times and you will still be sensitive to the noise on the rising edge. Your real problem is the slow rising edge, PERIOD. Do something with it, like buffering it so it is not slow going into the FPGA and use hysteresis in the buffer so it will not be sensitive to the noise. Do any of the Xilinx Spartan inputs have hysteresis? If so, you won't need a buffer. BTW, stable data on the high phase means you either have to clock data on the rising edge with 0 setup time, or you have to clock data on the falling edge with 0 hold time. 0 hold time can be accomodated in the Xilinx parts with an added internal delay element. At least this was true of the XC4000 series. I assume the Spartan parts still have it since they are based on the XC4000 chips. But as Philip observed, it would be hard to change data at any time other than following the falling edge which would imply lots of setup time on the rising edge. Go figure... Jaime Andres Aranguren Cardona wrote: > > Hi, > > On Xilinx' App Note XAP333 is an design of a I2C Master/Slave > peripheral for a uProcessor, which I've used as basis for designing a > slave device. They say on pag 12 that everything (the state machine > and associated counters and shift registers are clocked on the falling > edge of SCL, 'cause on heavy loaded systems the rise time of the SCL > line may be very slow and that is dangerous on a clock a signal, > 'cause it can generate noise on it. > > However, on Philips I2C bus Specification v2.1 Jan-2000, pag 8 they > say the data on the SDA line must be stable during the HIGH period of > the clock. > > What would to recommend for an I2C slave on a Xilinx XC4010XL and/or a > XCS05XL? > Sampling on the falling edge (like Xilinx AppNote does) or sampling on > he rising edge (as Philips specification suggests)? > > Thanks a lot. > > PS/ I would appreciate your replies also be sent to > jaime.aranguren@ieee.org -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 41387
"sunny" <sunshine@sunrise.at> wrote in message news:ee75d1e.1@WebX.sUN8CHnE... > altera's byteblaster did include the 74hc244. the byteblastermv consists of an 74ls244. the schematic should be ok and it should work fine with the ls part. I assume that your cable is more than 20cm in length. shorten the cable and it will work fine. Sorry, Sunny, I just open and check my original ByteBlaster (not MV). There is 74LS244 in original ByteBlaster... -- Tuomo AuerArticle: 41388
I have 3 meter extension cord between PC and original 5V ByteBlaster. It has worked well. Check that there are no ground current flowing between PC and your power supply supplying your circuit board. You can test this connecting a multimeter in AC amps mode between the case of your PC and ground of your circuit board (systems powered and no cables between computer and your system). There can easily be ac-current between units 1) if you have ungrounded PC (outlet without safety ground) and if there is a connection between the ground your circuit board and safety ground (the case) of PSU supplying your board. This because of leakage current from the live of mains to ungrounded computer case thru EMI filter capacitors in the power supply of the computer. 2) if both PC and your circuit board have a connection to safety ground but electrical system in your building uses only two wires (live and neutral, safety connected to neutral in outlets). In this case use single outlet (or an extension ac-cord to split one outlet) to power both the PC and your circuit board. In all cases use grounding wire between your computer and ground of your circuit board. And connect this wire before connecting the programming cable and remove this cord after disconnectind the programming cable. -- Tuomo AuerArticle: 41389
Thank you very much . Best regards, Vladislav Vasilenko . Peter Alfke wrote: > > There is a 200+ page reliability report on the web at > > http://www.xilinx.com/products/qa_data/relreprt.pdf > > start by looking at pages 10 and 19 > Happy reading :-) > > BTW, I found this by going to the public Xilinx website and using its > search facility to look for "reliability report". Simple, isn't it. > > Peter Alfke, Xilinx Applications > ======================================= > vlad@comsys.ntu-kpi.kiev.ua wrote: > > > Hi All , > > Where can I find information about numerical characteristic of > > failure > > rate of Xilinx ?hips(Spartan2, Virtex series)? This information is > > needed for calculation reliability index of entire device. > > > > -- > > Best regards, > > Vladislav Vasilenko > > Hardware engineer. National Technical University of Ukraine > > > > mailto:vlad@comsys.ntu-kpi.kiev.uaArticle: 41390
I have been working on a PCI IP core for a year or so. I do realize that spending one year sounds like a lot of time, but it is a hobby project where I started from not knowing anything about how an FPGA works. Regardless, I now know a lot more about FPGAs and PCI than a year ago, and the PCI IP core seems to work okay, although I haven't fully debugged it yet. Are you saying that Spartan-II is too expensive to be used in an MP3 player? I heard that Actel's eX FPGA is used in some MP3 players, so I guess it is not impossible to use an FPGA in cost sensitive products. Kevin Brace (In general, don't respond to me directly, and respond within the newsgroup.) Kelvin Hsu wrote: > > Hi, Kevin: > > I am not sure what kind of hobby project do you do? Do you have any > facilities to fabricate them out? I tend to like making some mp3 player or > motor control toys out of an FPGA chip but it seems impossible to make > into hardware as it's a lot of money when converted to my currency. I am > using ISE Webpack from Xilinx. Its really a great tool anyway. > > -- > Best Regards, > ----------------------------------------------------------------- > Xu Qijun > Engineer > OKI Techno Centre (S) Pte Ltd > Tel: 770-7049 Fax: 779-1621 > Email: qijun@okigrp.com.sgArticle: 41391
"Tuomo Auer" <tuomo.auer@removethis.hut.fi> schrieb: > I have 3 meter extension cord between PC and original 5V ByteBlaster. It has > worked well. I am using a self-made extension of about 2 meter. I had problems programming 5V devices although with 3.3V devices it worked perfectly. Now that I changed computers, it works fine with 5V devices. IMHO cable length matters depending also on the type of parallel port used.Article: 41392
"Jon Schneider" <jon@axisREmilMOVEton.ltd.uk> wrote in message news:memo.20020326164009.35965A@xxx.cix.co.uk... > David, > > It sounds a bit like a machine problem. I suggest you at least run > memtest86 (http://www.memtest86.com/) on it. > > Jon > You may very well be right. My machine is an 800MHz Athlon processor and I notice some of the known problems with the Xilinx software are about problems running on Athlon processors. What puzzles me is how I can run 4.1i through with no problems and yet the exact same input files on 4.2i break ngdbuild. I think there is some conflict between the 4.2i software and some dll that needs updating. Regarding the comment about completing a project in the same version of software - that's what I do normally. This was a simple test to see how much better 4.2i works on a known design. Unfortunately it's failed the test :-) :-( Thanks for all your help. DavidArticle: 41393
Hi, I am working on a design in a Virtex 2. It is a FIR filter and uses the emebedded multipliers. I have used the Xpwr batch program on this design with a VCD file generated by my testbench running in ModelSim. I think I have included all the nets in the design as I have used the "vcd add -r /i0/*" which should recurse into the blocks and looking at the VCD file it seems OK. The testbench runs test data through the filter. XPwr give me an estimated power value for this. I have also got hold of the Excel spreadsheet Power Estimator for the V2. I have filled this out, maybe not as accurately as possible but should be roughly correct, and this gives me a value but it seems to be much higher. As anyone else done a comparison? Know which value to use? Or am I just missing the point? Any help would be gratefully received. Thanks Andy DowArticle: 41394
Internally : Dont do it! Externally : Take a look on IDT´s or Cypress' web pages.Article: 41395
I want to implement a counter of 160Mhz internal clock.The clock of external is 80Mhz and doubled by the DLL of Xilinx SpartanII.After I implemented it I found the maxium frenquency reported by ISE4.1 is about 140 MHz.In this instance, can I implement 160MHz counter?If no,how can I add constrains to my design.Which is more important the constrain before synthesis or after synthesis? -- _________________________________________ Deerlux White ICQ#:147863330 SMS: (Send an SMS message to my ICQ): +2783142147863330 More ways to contact me: http://wwp.icq.com/147863330 _________________________________________Article: 41396
Hi, I am doing gate level simulation and I realized that it is so difficult to probe internal signals since they are all changed into a strange format and the format is also keeping changing everytime I re-run the simulation. Is there any method so that I can have the internal signal names to be fixed in the simulation( I mean the registers)...I think in Synopsys I can see the format they write netlists. But Xilinx is lot of messy. Thanks. module whatever( ); input clk_12m; output buffer_full2; input rxd; output clk_out; wire IO33_OBUF; wire rxd_out_OBUF; wire rxd_1_OBUF; wire rst_n_IBUF; wire \clockrecovery/beta_tmp_0 ; wire \clockrecovery/x_0 ; wire \clockrecovery/x_1 ; // This is the result my definition of reg [7:0] x; wire \clockrecovery/beta_tmp_1 ; wire \clockrecovery/Mmult_beta_X_x_inst_lut2_20 ; wire \clockrecovery/N1682 ; wire \clockrecovery/Mmult_beta_X_x_inst_cy_88 ; wire \clockrecovery/x_2 ;Article: 41397
I confirm - this solution is right. My LS crashed in the same way and I received such advice directly from Altera support. Now everything works fine. > as far as I know, LeonardoSpectrum 2002a crashing after startup has to do > with the windows versions you're using, international or US. > > Try to set the following Windows environment variable: > > Name of the variable: TZ > Value of the variable: GST-1GDT > > Regards > WolfgangArticle: 41398
Hi all, I am using a XC2V1000 in my design.I am trying to achieve a 30 MHz clk from a 20 MHz one, using CLKFX. I have tried the code below.The LOCKED pin of the DCM stays always at '0' and at CLKFX I see the default x4 clkin signal. Neither Leonardo S. nor Xilinx D.Mgr gave error message.I have also investigated DCM with FPGA Editor, everything seemed normal. So far I could not understand the problem. I would like to hear your comments or advices. Regards, Serkan Dinmez The VHDL code is as below: library IEEE; use IEEE.std_logic_1164.all; library UNISIM; use UNISIM.VCOMPONENTS.all; entity DCM_TOP is port ( clock_in : in std_logic; clock_out : out std_logic; LOCKED: out std_logic ); end DCM_TOP; architecture XILINX of DCM_TOP is signal low, high : std_logic; signal clock : std_logic; signal clk1: std_logic; signal clk1_buf: std_logic; signal READ_CLK: std_logic; attribute DLL_FREQUENCY_MODE : string; attribute DUTY_CYCLE_CORRECTION : string; attribute STARTUP_WAIT : string; attribute DFS_FREQUENCY_MODE : string; attribute CLKFX_DIVIDE : string; attribute CLKFX_MULTIPLY : string; attribute CLK_FEEDBACK : string; attribute CLKOUT_PHASE_SHIFT : string; attribute PHASE_SHIFT : string; attribute DLL_FREQUENCY_MODE of dcm1: label is "LOW"; attribute DUTY_CYCLE_CORRECTION of dcm1: label is "TRUE"; attribute STARTUP_WAIT of dcm1: label is "TRUE"; attribute DFS_FREQUENCY_MODE of dcm1: label is "LOW"; attribute CLKFX_DIVIDE of dcm1: label is "2"; attribute CLKFX_MULTIPLY of dcm1: label is "3"; attribute CLK_FEEDBACK of dcm1: label is "1X"; attribute CLKOUT_PHASE_SHIFT of dcm1 : label is "FIXED"; attribute PHASE_SHIFT of dcm1: label is "0"; component IBUFG port ( I : in std_logic; O : out std_logic ); end component; component BUFG port ( I : in std_logic; O : out std_logic ); end component; component DCM port ( CLKFB : in std_logic; CLKIN : in std_logic; DSSEN : in std_logic; PSCLK : in std_logic; PSEN : in std_logic; PSINCDEC : in std_logic; RST : in std_logic; CLK0 : out std_logic; CLK90 : out std_logic; CLK180 : out std_logic; CLK270 : out std_logic; CLK2X : out std_logic; CLK2X180 : out std_logic; CLKDV : out std_logic; CLKFX : out std_logic; CLKFX180 : out std_logic; LOCKED : out std_logic; PSDONE : out std_logic; STATUS : out std_logic_vector (7 downto 0)); end component; begin low<='0'; high<='1'; clock_out <= READ_CLK; U1 : IBUFG port map ( I => clock_in, O => clock); dcm1: DCM port map ( CLKFB => clk1_buf, CLKIN => clock, DSSEN => low, PSCLK => low, PSEN => low, PSINCDEC => low, RST=> low, CLK0 => clk1, CLKFX=>READ_CLK, LOCKED => LOCKED ); U2:BUFG port map (I => clk1 , O => clk1_buf ); end XILINX;Article: 41399
Dear Kevin, The trick is to tell the accumulator to ignore what is coming out of the shift register for a number of cycles following the release of your reset. The masking AND gates to do this should be absorbed into the LUTs forming the accumulator ( effectively performs A + [B.mask] in each LUT). An SRL16 can be used to remember how long it is since the reset was released. In this way you don't need to 'flush' the shift register. The control logic would set a flip-flop driving the 'mask' input on the start of reset (active high). The reset signal would also enter an SRL16 adjusted to a suitable length. The flip-flop would only be reset when it sees a high to low transition come out of the SRL16. The only cause for concern would be if you applied a reset whilst midway through the previous reset. A real flip-flop based shift register with the first D input connected to GND and all flip-flops forced to SET with the applied reset signal would be an easier design to control the 'mask' signal. See last diagram in the following TechX about resets..... http://www.xilinx.com/support/techxclusives/global-techX19.htm This also avoids any reset issues. It will probably be larger, but as it is only 1-bit wide it still means that your data path offers the major saving in area via those wonderful SRL16E's. Hope this helps. Ken
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